The document proposes that:
1, a scheme to protect user balance and transaction amount under smart contract, can be proved to be safe under the stochastic forecasting model.
2. An efficient zero-knowledge proof scheme Nizk (non-interactive zero-knowledge) improves the time efficiency of generating proof at the expense of generating proof size.
Contrast: ZK- snake (zero cash)&; Nitzke (DSC)
Homomorphic encryption HE (homomorphic encryption): allows users to update the account balance directly in the form of ciphertext.
ZK (zero knowledge): Prove the correctness of the transaction. Ensure equivalence and sufficiency. If the sender reduces V, the receiver should receive V, which proves that the sender has an account balance exceeding V and sends it to the receiver.
Related blockchain privacy protection work: Monero (Monroe coin), RingCT (ring signature), Zerocoin, Zerocash.
1, bilinear mapping
2. Homomorphic encryption
You can ensure that the balance can be updated in ciphertext state. E( 1)+E(2)=E(3)
This is a variant of ElGamal scheme, but I don't know why H is introduced, perhaps for better security. The balance is numerical, which is smaller than plaintext space, so we can solve plaintext M.
3. Problems based on
This is also a variant of the discrete logarithm problem.
4.Boneh-Boyen signature scheme
6. Zero knowledge proves Nizke.
In this paper, non-interactive zero-knowledge proof is used, and a trusted third party is used to generate the model of CRS (Common Reference String), but the proof key PK and verification key VK are not used.
CRS can only be generated once and used to generate multiple proofs.
7. Transaction form of sending T coins from Party A to Party B:
The verification program is directly deployed on the blockchain in the form of smart contracts, which can automatically verify and transfer assets.
1, settings
Input security parameter n, and generate system common parameter PP, in which Boneh-Boyen signature scheme is used, and PP already contains CRS in zero knowledge proof.
Initialization of each participant: encrypt your own balance with the homomorphic encryption scheme mentioned above, and only store the ciphertext of the balance in the account model.
The size of the plaintext space considered here is [0,2030]
For people with private keys, it is easy to decrypt plaintext, that is, the account balance value.
3. Transfer
A sends T coins to B:
X stands for transmission statement, which contains public keys of A and B, ciphertext generated by homomorphic encryption of account balance of A, and ciphertext generated by homomorphic encryption of public keys of A and B of T respectively.
W stands for witness, including A's private key, random number used when generating ciphertext, A's account balance and transmission amount.
π is the proof of generation.
(x, PP, π) is uploaded to the blockchain and verified by the verification program.
4. Redemption
The verification program is deployed on the blockchain, and its validity is verified after receiving the corresponding input: if it is invalid, it will be ignored; If it is valid, the transaction is disclosed (the transaction amount is encrypted) and the account balance of the sender and receiver is updated.
5. Safety