The Future of Data Networks: Decentralization

In the past 20 years, with the rapid development of the Internet economy, Internet giants represented by FAANG and BAT have monopolized a vast amount of user data, leveraging cutting-edge technologies such as big data and AI computation to explore and exploit the value of data.

However, users, who are the actual stakeholders of the data, not only fail to benefit from the data dividend but also bear the risk of personal privacy breaches and misuse of personal data.

Nowadays, with the rise of the decentralized blockchain movement, people are realizing that the next generation of the Internet should be a serverless and decentralized network. In this network, users can have complete ownership of their data. No one, without the user's permission, can access or utilize others' data. However, this undoubtedly brings about some challenges:

1.     In a decentralized model, a single entity usually only possesses a subset of the data collection, and no single entity has access to the entire dataset. Therefore, the data owned by each participant is insufficient to reflect the characteristics of the complete dataset.

2.     Participants have weak or even no trust among each other, making it impossible to collect and verify the validity of data through a "trusted third party," let alone share value, information, and assets.

To address these issues, many Web3 builders have been contributing their ideas and solutions. Today, we will introduce PlatON, a protocol dedicated to building the next-generation privacy computing architecture and data exchange network. It enables collaborative computation and verification of result integrity without relying on third parties, while ensuring the privacy and security of user data.

PlatON: A Privacy Computing Protocol without Third-Party Dependence

PlatON is a next-generation internet foundational protocol initiated and promoted by the LatticeX Foundation, with "computational interoperability" as its core feature. It is supported by a privacy computing network based on blockchain's fundamental attributes.

PlatON aims to provide a public infrastructure under an open-source architecture for global artificial intelligence, distributed application developers, data providers, and various institutions, communities, and individuals with computational needs. It achieves this by building a computational system composed of cryptographic algorithms such as verifiable computation, secure multiparty computation, zero-knowledge proofs, and homomorphic encryption, combined with blockchain technology.

PlatON utilizes modern cryptographic algorithms, including but not limited to zero-knowledge proofs (ZKP), verifiable computation (VC), homomorphic encryption (HE), secure multiparty computation (MPC), and secret sharing (SS), to implement non-interactive proof-based computation scaling solutions. This addresses the dilemma of scalability and privacy. Let's delve into the specifics of PlatON's approach.

1.     Scalability

PlatON believes that the existing issues in blockchain architecture are largely due to the tight coupling between consensus and computation. To address this, PlatON proposes a verifiable computation scheme that weakens the inherent binding relationship between the two through mathematically provable cryptographic algorithms. This fundamentally separates the two aspects, allowing for separate solutions to these two problems.

2.     Privacy

PlatON attempts to achieve true privacy computing by combining homomorphic encryption (HE) and secure multiparty computation (MPC) to protect the privacy of input data and the computation logic itself. Unlike relying on trusted hardware or TEEs provided by third-party manufacturers for computing integrity, PlatON's trustless computation relies only on provable cryptographic assumptions. This ensures the security of private data throughout its lifecycle while eliminating trust boundaries.

PlatON's overall structures.

1.     Overall Logical Structure

In addition to providing the underlying blockchain, PlatON also offers open-source implementations of wallets, block explorers, and node tools.

2.     Underlying Logical Structure

In PlatON's architecture, it modifies the Layer1 consensus network within the technical framework of Ethereum and rewrites the core components.

Regarding Layer2, PlatON extends complex computations off-chain and achieves privacy computing through off-chain secure multiparty computation protocols.

3.     Network Structure

PlatON's underlying blockchain network consists of several types of nodes that connect through P2P:

4.     Deployment Structure of Validation Nodes

To protect the normal communication and operation of validation nodes and ensure stable block production, the following security measures are recommended:

Economic Model

LAT is the native token of PlatON, which can be sent and used on the PlatON network and its applications. Currently, users can obtain LAT through participation in the Grants program by the LatticeX Foundation and future community development programs.

When users send LAT or use PlatON applications, a small amount of LAT is required as a fee, which incentivizes nodes to process and verify user transactions.

In the PPOS mechanism, LAT plays a crucial role in the network. It is used for delegating to nodes or staking as a validator node to maintain the security of the PlatON network and receive LAT rewards.

LAT serves as the payment medium for the future data and computing power circulation market on PlatON. Participants in the PlatON network can earn LAT by providing data usage, computing power, and algorithms.

PlatON will support the development of DApps and DeFi by introducing economic coupling designs. For example, DApps can issue their own tokens, but these tokens must be backed by LAT reserves. PlatON will also support the development of stablecoins collateralized by LAT.

Staking and Delegation

Staking and delegation are core functionalities of the PlatON network, where the higher the proportion of LAT staked and delegated, the higher the security of the network. The selection of active validating nodes is primarily based on the total staking ranking of the validating nodes, which includes the LAT staked by the validating node itself and the LAT delegated to the node. Only the top 201 candidate nodes in the staking ranking become active validating nodes.

1.     Staking

In the PlatON network, staking refers to the act of nodes locking a certain amount of LAT to participate in the network. PlatON adopts the PPoS consensus mechanism to select validating nodes, and the nodes that join the network are ranked based on the amount of LAT staked. Each consensus round randomly selects 43 nodes from the top 201 nodes in the ranking as validating nodes to produce blocks.

2.     Delegation

Delegation allows token holders to delegate their LAT to a specific node and indirectly participate in the network's construction. Delegation can enhance the security of the network, and delegators can earn rewards during this process.

Delegation is similar to an election, where users exercise their voting rights through delegation and elect nodes that are more supportive of the network's development to become validating nodes, aligning with the community's collective expectations. Increased participation from delegators can help hold validating nodes accountable and prevent malicious behavior, promoting the healthy and sustainable development of the PlatON ecosystem while enhancing the value of PlatON.

Delegated LAT takes effect in the next settlement period (i.e., enters a locked state). If the delegated LAT remains locked for a full settlement period and the delegated node receives rewards, the delegator will receive delegation rewards in the corresponding settlement block.

If a delegated node is forcibly ejected, all delegations under that node will become invalid, and there will be no delegation rewards for the current and subsequent settlement periods.

PlatON Governance Mechanism

PlatON believes that decision-making power should belong to the "stakeholders," meaning that power should reside with the people. However, conducting a nationwide referendum needs to consider implementation costs, as well as issues such as voter turnout, expertise, governance efficiency, etc. Therefore, referendums should not be the norm in governance but rather a way to address major differences.

In PlatON's PPoS design, the selection of candidate nodes itself is a form of election, and the interests of the nodes are closely related to the prosperity or decline of the public chain ecosystem. They should bear more governance responsibilities and have more governance rights. Therefore, in PlatON's governance, a combination of direct and indirect democracy is adopted. The core principle is as follows: Under normal circumstances, governance is conducted through voting by candidate nodes, which represents indirect democracy. In the case of major differences, community-wide open voting is used, which represents direct democracy.

1.     Participating Roles

a.   Candidate Nodes: Nodes become candidates by staking a certain amount of tokens. Other users can delegate their tokens to candidates. The system ranks candidates based on their total stake (staking + delegation). The top 201 candidates are elected as candidate nodes.

b.   Token Holders: All holders of the token.

c.   Core Developers: Core developers who contribute to the construction of the PlatON public chain and community.

2.     Allocation of Rights

a.   Candidate Nodes: Initiate proposals, vote on referendum proposals, vote on non-referendum proposals, and second proposals.

b.   Token Holders: Initiate referendum proposals, vote on referendum proposals, and second proposals.

c.   Developers: GitHub code control, proposal review, proposal implementation.

3.     Proposal of Categories

a.   Referendum Proposals: Referendum proposals are triggered in highly controversial scenarios. Any token holder can initiate a referendum proposal, which requires a nationwide referendum to determine the outcome. The following scenarios may lead to a referendum:

a)      Modification of the basic law.

b)      Major forks, similar to The DAO fork.

c)       Termination of the chain's operation.

b.   Non-Referendum Proposals: Non-referendum proposals are ordinary proposals voted on by candidate nodes. They can be categorized as follows:

a)      Text Proposals: Used for decisions that do not require implementation.

b)      Software Upgrade Proposals: Used for on-chain upgrade voting to achieve smooth upgrades.

c)       Parameter Modification Proposals: Used to modify system parameters and other governable parameters.

d)      Account Proposals: Used to freeze or unfreeze accounts (including contracts).

e)      Incentive Proposals: Used to allocate balances in the governance fund account.

f)       Cancelation Proposals: Used to cancel software upgrade proposals currently under voting on the chain.

4.       Governance Process

a.   Proposal Initiation

Referendum proposals can be initiated by anyone, while non-referendum proposals are initiated by candidate nodes. Each proposal should have corresponding text documentation, which is stored in the PIP repository on GitHub and managed by core developers, similar to EIPs (Ethereum Improvement Proposals).

To control spam proposals, a proposal fee is required for the initiation of all types of proposals as a cost of the proposal.

b.   Proposal Screening

a)     Referendum Proposals: Since referendums are not the norm, multiple referendum proposals can be active simultaneously. These proposals are sorted based on the bond amount, and the proposal with the highest bond is selected for the voting phase each month.

b)    Non-Referendum Proposals: Once a proposal is successfully initiated, it enters the voting period. Multiple proposals can be voted on concurrently.

c.   Proposal Voting

a)      Referendum Proposals:

Referendum proposals involve the most critical stakeholder voting. The voting period lasts for two weeks and offers three voting options: "Support," "Oppose," and "Abstain." Only tokens that are staked or delegated can participate in voting.

The voting mechanism follows a combination of candidate nodes' delegated voting and individual voting coverage. In this mechanism, the voting weight of a candidate node is the sum of its own staked tokens and delegated tokens. If a delegator has a different opinion from the candidate node they delegate to, the delegator can vote independently, with the voting weight corresponding to their delegated tokens overriding the candidate node's vote. All votes are locked until the end of the voting period.

To mitigate the centralization of voting power in the hands of a few nodes, a sufficient number of candidate nodes should participate in the voting process. If the majority of candidate nodes disagree or do not participate in the vote, the proposal will not pass.

b)      Non-Referendum Proposals:

Non-referendum proposal voting is primarily driven by candidate nodes. Only candidate nodes elected during the proposal voting period can vote. The voting period is generally two weeks, although the voting period for software upgrade proposals can be determined by the proposal initiator. The voting mechanism follows a one-node-one-vote system, and the staked tokens of candidate nodes are locked until the end of the voting period. For non-software upgrade proposals, there are three voting options: "Yes," "No," and "Abstain." In the case of software upgrade proposals, there is no explicit option selection, and candidate nodes can indicate their voting stance by upgrading their local nodes or not.

d.   Calculation of Voting Results

a)      Referendum Proposals: The calculation of the referendum proposal results is based on the following three dimensions:

1)      Candidate Node Support Rate: The ratio of the number of candidate nodes that support the proposal to the total number of candidate nodes eligible to vote.

2)      Token Support Rate: The ratio of the number of supporting tokens to the total number of tokens participating in the vote.

3)      Token Participation Rate: The ratio of the total number of tokens participating in the vote to the total number of staked tokens.

4)      If the following conditions are met simultaneously: Candidate Node Support Rate > P%, Token Support Rate > Q%, and Token Participation Rate > K%, the proposal vote passes; otherwise, the proposal vote does not pass.

b)      Non-Referendum Proposals: The calculation of non-referendum proposal results is based on the following two dimensions:

1)      Candidate Node Support Rate: The ratio of the number of candidate nodes that support the proposal to the total number of candidate nodes eligible to vote.

2)      Candidate Node Participation Rate: The ratio of the number of candidate nodes participating in the vote to the total number of candidate nodes eligible to vote.

3)      If the following conditions are met simultaneously: Candidate Node Support Rate > M% and Candidate Node Participation Rate > N%, the proposal vote passes; otherwise, the proposal vote does not pass.

The support rate and participation rate for different types of proposals are as follows:

The Binary Opposition of Scalability and Privacy

In a broader sense, existing blockchain architectures are essentially consensus-based computations. To ensure the correctness of computations, each operation needs to be redundantly processed by a majority of nodes to verify its correctness. This leads to an inherent contradiction between efficiency and trust within the blockchain system.

Furthermore, the conflict between scalability and privacy is also a widely recognized issue in the industry.

Scalability is acknowledged as the biggest challenge for blockchain. Current mainstream blockchains, such as Ethereum, have a limited transaction throughput per second. The throughput is significantly lower than what is required to support the processing capacity needed for mainstream financial markets. Although the industry has been contributing various solutions, the improvement in scalability often comes at the cost of sacrificing the decentralization or security of the blockchain. Additionally, the consensus-based computing model of blockchain limits the processing capability of smart contracts for complex computations.

In addition, privacy is another major problem that blockchain currently faces. Despite the excellent features of blockchain, such as immutability, decentralization, and trustlessness, it encounters challenges in accessing data, similar to big data and AI technologies. Both companies and individuals are unwilling to publish their private information on public ledgers because these ledgers can be freely accessed by governments, family members, colleagues, and business competitors. This becomes a significant obstacle that restricts the development and widespread adoption of blockchain technology.