PlatON Privacy-Preserving Computation White Paper | Part 3. On-Chain Capabilities

PlatON Privacy-Preserving Computation White Paper | Part 3. On-Chain Capabilities

Continued from the previous article. PlatON Privacy-Preserving Computation White Paper | Part 2. Algorithms

Before reading this article, let’s review the Overall Framework of Privacy-preserving Computation.

PlatON Privacy-Preserving Computation White Paper | Part 3. On-Chain Capabilities
The Overall Framework of Privacy-preserving Computation.

This article will introduce On-Chain Capabilities, including Privacy Payment, Privacy Computation, and Storage.

Part.3 On-Chain Capabilities

Privacy and storage are two important issues in blockchain. LatticeX Foundation focuses on the following aspects.

3.1 Privacy

Payment transaction and smart contract are two basic components of blockchain. The privacy requirements and underlying solutions are different.

3.1.1 Payment

It is worth pointing out that the main tokens in Alaya and PlatON are transparent, only the privacy requirements of sub-tokens based on these two networks are considered. Developers could build their applications based on these basic capabilities.

Confidential Transaction is a widely used notion to hide the amount of a transaction. It involves homomorphic encryptions/commitments to conceal the amount, and combines with a range proof to ensure the validity of the transaction. The underlying solutions are slightly different for account model and UTXO model. Since one could customize the mode using smart contract, solutions for both models will be supported.

Anonymous Transaction hides the payer and payee address in the transaction. Anonymity only makes sense when the number of address in the numbers is sufficiently large. We note that in this type of transaction, the amount of the transfer is public. This is useful to build private decentralized exchange based on automated market maker (AMM). In order to provide anonymity, UTXO model is preferable. This is because in an account model, update of the state will leak the address anyway. We encourage the community to propose efficient solutions for account model.

Private Transaction hides the address and amount simultaneously. Several methods are proposed and a relatively complete solution is presented in ZCash based on ZK-SNARK. Although the performance is still an urgent issue, it provides the best privacy in both aspects. Other solutions based on ring signatures are limited to small anonymity set. We will focus on the solution based on ZK-SNARK, since we believe security and privacy is the first priority.

3.1.2 Computation

Smart contract is designed to be Turing machine that could customize all computable functions. It is a generalization of payment, and the difficulty to solve the privacy problems is much higher.

ZK Compiler and ZKVM.

Since there may be a variety of applications, it is hard to pre-determine which circuit should be used. On the other hand, it is nearly impossible to require all developers to understand the usage and cryptographic background of complicated ZK-SNARK algorithms. This is the main reason to provide ZK compiler and ZKVM to support privacy-preserving applications based on smart contract.

Developers use easy-to-use front-end programming languages to customize their applications, including specify the private inputs. The ZK compiler will automatically transfer this application to suitable circuits or constraints. ZKVM will generate the parameters that used for verification and will be deployed on the blockchain. Meanwhile, ZKVM will automatically generate the zero-knowledge proof when users feed in the private input. This will reduce the bar of use significantly, and several projects are dedicated to this area.

Input and Output Privacy.

In a simplified way, the execution of smart contract could be abstracted as computing y = F(x1,…,xn), where xi’s are the inputs, y is the output and F is the application described in the smart contract. A straightforward requirement is to protect the privacy of xi’s and y. If the inputs belong to a single party, one could use a (fully) homomorphic encryption scheme to encrypt the inputs, and outsource the computation to a third node. Combining with verifiable computation algorithms, it will be easy to verify the result. If the inputs belong to multiple parties, one should apply more powerful multi-key homomorphic encryption schemes. Each party encrypts his input with his public key, any third party evaluates the ciphertexts under different keys homomorphically and provides a proof to ensure the correctness.

Function Privacy.

The most ambitious goal of private computation is to hide the function itself as well as the inputs and outputs. It will be much more difficult to design the solution. One candidate framework is proposed in Zexe. It enables parties with access to a blockchain and execute computations offline and subsequently post privacy-preserving, publicly verifiable transactions that attest to the correctness of these off-chain executions. We will integrate Zexe in the first step.

3.2 Storage

The append-only property of blockchain inherently keeps the data increasing as transactions grow. At the time of writing this manuscript, Bitcoin and Ethereum store hundreds of gigabyte amount of data, and the size is still increasing. It takes days on a typical laptop for a full node to download and verify these historical transactions. Although the storage issue is not urgent in PlatON and Alaya, we should prepare and research feasible solutions.

Stateless Client.

Full node contains all the historical transactions, the size of the data is too large to be stored in lightweight clients, such as IoT terminals or cell phones. Stateless clients contain only the chain of headers without the execution of any transactions or associated states. The size of the headers is much smaller than the transactions, almost less than 5%. Given a transaction or a state, stateless clients will additionally require a witness that proves the validity. Simple Payment Verification (SPV) provides such a witness, which is essentially merkle tree branches, to convince clients without storing all the transactions. The support of stateless clients in PlatON and Alaya will significantly reduce the threshold to get involved in the network. Edge-side devices can also access the network and conduct business transactions, which can greatly expand the network’s reach.

Stateless Chain.

A more ambitious goal is to upgrade PlatON and Alaya into stateless chains. In a stateless blockchain, only succinct information (for instance, a constant-size proof) is stored on-chain instead of state information. Mina is the first of this kind blockchain to achieve statelessness. It involves in using recursive zero-knowledge proofs to prove the validity of states and only keep constant-size data on-chain. In order to solve the data availability issue, the states and transactions need a place to store anyway, we introduce storage services in the next section. It is worth pointing out that upgrading to stateless chain will significantly change the current layer-1 architecture of PlatON and Alaya, thus we leave it as long-time planning.

Publisher:PlatONWorld,Please indicate the source for forwarding:

Like (0)
PlatONWorld's avatarPlatONWorldOfficial
Previous July 15, 2021 23:30
Next July 15, 2021 23:40


Leave a Reply

Please Login to Comment