Klaytn Improvement Reserve
Zklay : Zero knowledge based Klay to preserve privacy with verifiability for Klay transfer
Date: 2021.06.30
Summary
Along with the rapid growth of the blockchain market, digital assets using blockchain are emerging one after another. Thus, privacy and security issues for users’ digital assets are becoming more crucial. However, in Klaytn which is an account-based public blockchain, all activities and assets of users are available publicly. It not only reveals user privacy but also violates the privacy regulation like EU GDPR. Although the simple encryption of accounts and transactions can preserve privacy, it triggers two issues: how to ensure the correctness of the transactions and the accounts, and how to meet the other regulation of anti money laundering. It is important for Klaytn to meet the regulations which require privacy and verifiability.
This proposal aims to tackle the privacy and verifiability issue on Klaytn environment. To solve the problem, we propose a zero-knowledge proof based project called Zklay. In the proposed Zklay, the user account values are encrypted called zklay account (ZA). To transfer coins among ZA and external owned account (EOA), an anon_transfer function is called between the account model and the utxo model. A user can transfer the encrypted coins between the account model and the utxo model in an encrypted form while the correctness is guaranteed by the zero-knowledge proof. In the utxo model, the asset transfers are performed anonymously, in which the transfer is not traceable in public. Nonetheless, the proposed scheme allows an authorized auditing entity to trace the transactions if it is required.
We define the security properties of ledger indistinguishability, transaction unlinkability and transaction non-malleability. We prove that the proposed Zklay satisfies the security properties. We implement the proposed Zklay using zk-SNARKs and experiment it on Ethereum (Ganache) blockchain environment and Klaytn blockchain (baobob). The experimental results show that the proof generation time is only 2.7 seconds and the gas consumption is 1.6M to verify the anonymous transfer transaction in Zklay while it takes 16 seconds to generate a proof and the gas consumption is 1.3M in Zeth.
Since standard secure hash functions such as SHA are inappropriate to zk-SNARKs due to the large zk-SNARK circuit, MiMC hash function is utilized in Zklay to accelerate the proof generation. However, since MiMC hash function is not available as a native instruction while SHA is supported as a native instruction in Klaytn and Ethereum, the smart contract which computes the hash operation requires high gas consumption. So we are going to propose a KIP to support zk-SNARK friendly hash instruction such MiMC and Poseidon. If they are supported then the gas consumption will decrease dramatically. Furthermore, due to the operation limitation in Klaytn while there is no limitation in Ethereum, the current Zklay only supports the small anonymity while it provides the full anonymity in Ethereum if no MiMC hash native instruction is supported. In the next round, we will improve the membership (merkle tree computation) to eliminate the hash operation and improve the performance, and commercialize the Zklay to develop android and iOS apps.
Project Milestones and Schedule
Zklay’s scheme is as following:
Fig 1. Overview of Zklay
Fig 2. Architecture of Zklay smart contract
Entities
Auditor
• Auditor publishes its pk
•Using auditor’s private key, a ciphertext in a transaction can be decrypted
Encrypted Account (ZA)
•User account
•Each user has a private key and a public key
•The public key includes keys for auditing
•Account is a ciphertext of <u,v> where u is random and v is a value
Dapp
•KeyGenaudit
•KeyGenuser
•TriggerTransfer (sk,pk,pk′,dv′,pv,pv′,toEOA)
•dv’ : amount sent to a mixer
•pv : amount received from EOA (self)
•pv’ : amount sent to EOA (toEOA)
•Create a Tx = (π,rt,nf,addr,c′,ct′,pv,pv′,K′u,K′a,T′,CT′,toEOA)
Smart contract
•registerAuditor
•registerUser
•AnonTransfer(π,rt,nf,addr,c′,ct′,pv,pv′,K′u,K′a,T′,CT′,toEOA)
•Verify a proof
•Manage root, nf, and account list
•Call transferFrom(self, this, pv) and transferFrom(this,toEOA, pv’)
Auditing
•For a given transaction of (π,rt,sn,addr,c′,ct′,K′u,K′a,T′,CT′,toEOA)
•Compute k = K’aask
• <du’, dv’, addr’> = Dec(k, CT)
• The transaction reveals that dv’ amount is transferred from addr to addr’
##Security analysis
Similarly to the security models in zerocash [BCG+14] and BlockMaze [GWY+20],we define the security properties such as ledger indistinguishability, transaction unlinkability, and transaction non-malleability.
Ledger Indistinguishability : A ledger is indistinguishable if no information is leaked from a ciphertext in each transaction
Transaction Unlinkability: A transaction unlinkability is defined as an indistinguishability problem in which a PPT adversary cannot extract any information about receiver and value from a given transaction.
Transaction Non-malleability: A transaction is non-malleable if no new transaction can be constructed different from the previous transactions without knowing private data (witness)such as secret keys.
Our Zklay satisfies the security properties. First, since a ciphertext in a transaction is encrypted and a zero-knowledge proof in the transaction does not reveal any plaintext information because it is zero-knowledge, no information is leaked from the ciphertext. Therefore ledger indistinguishability holds.
Second, the transaction does not include a receiver information. For a receiver to know that the given transaction is sent to itself, it is required to decrypt the transaction by the receiver’s private key which is not available publicly. In addition, the amount sent is encrypted, it is unknown to 3rd parties. Consequently Zklay holds transaction unlinkability.
Finally, since Zklay utilizes simulation extractable zk-SNARKs in which it is not allowed to generate a new proof, a new transaction cannot be created without knowing secret information (witness) such as a sender’s private key.
Even if the technical paper does not define auditability currently, Zklay allows an auditor to trace transactions since the auditor can decrypt all ciphertexts since it is guaranteed by zk-SNAKRs that all ciphertexts are correctly encrypted.
In the technical report, we include the implementation details and experimental results.
Zklay experiment
Zklay consists of three S/W modules: client (python), proof generator (C++) and a blockchain (ganache, solidity). In the experiment, a client builds a transaction and calls the proof generator with witness (secret input) to generate a proof. The generated proof with the transaction is sent to the blockchain, and the smart contract code checks the validity of the transaction using the zk-SNARKs verification algorithm. The detailed explanation is available in the technical paper.
Key Deliverables
We successfully implement the proposed Zklay. The detailed information is available on the technical paper (Zklay.pdf - Google Drive ) including Zklay experiment. And we are providing the demo video ( zklay demo - YouTube ).
Budget
The table below contains the status of invested resources.
Table 1: Resource investment (USD)
