Klaytn Improvement Reserve
ZKlay : Zero knowledge based Klay to preserve privacy with verifiability for Klay transfer
Date: 2021.05.14
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 will provide a technical report, and a software for the proposed ZKlay project.
This progress report contains the details on the progress at milestone 2. Especially this 2nd report includes the Zklay protocol design and the security analysis. We define the security properties of ledger indistinguishability, transaction unlinkability and transaction non-malleability. We prove that the proposed Zklay satisfies the security properties.
Project Milestones and Schedule
ZKlay’s scheme is as following:
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 constructeddifferent 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 next final report, we will include the implementation details.
Key Deliverables
At milestone 2, we write this technical report and a technical paper explaining the Zklay protocol and the security analysis which is available at ZklayTechPaper.pdf - Google Drive.
Budget
The table below contains the status of invested resources.
Table 1: Resource investment (USD)
