Discussion: add zero-knowledge proof verification functions for shielded token contract

[Federico2014]

Background

In order to implement shielded transaction for TRC-20 token, We plan to develop the shielded token contract. The contract has three core modules: mint, transfer and burn. mint is used to transform the public TRC-20 tokens into shielded tokens. transfer is used for shielded token transactions. burn is used to transform the shielded tokens back to public TRC-20 tokens. The shielded contract will be implemented based on zero-knowledge proof, so it needs the complex zero-knowledge proof verification in mint, transfer and burn methods.

Motivation

In order to accelerate the speed for zero-knowledge proof verification shielded token transactions. We want to introduces three new functions: verifyMintProof, verifyTransferProof, and verifyBurnProof, which can accelerate the zero-knowledge verification for the mint, transfer and burn processing in shielded token contract. The proof verificaton function can be implemented in precompiled contract form.

[shydesky]

#135

[Federico2014]

Are there three functions a must for the shielded contract? how to verify zero-knowledge proof without these 3 functions?

If you implement the functions completely by solidity code, it may be possible, but it's quite complex and difficult to implement.

[shydesky]

Are there three functions a must for the shielded contract? how to verify zero-knowledge proof without these 3 functions?

If you implement the functions completely by solidity code, it may be possible, but it's quite complex and difficult to implement.

are there some query/update database operations in these functions? I worry about the performance issues.

[Federico2014]

Are there three functions a must for the shielded contract? how to verify zero-knowledge proof without these 3 functions?

If you implement the functions completely by solidity code, it may be possible, but it's quite complex and difficult to implement.

are there some query/update database operations in these functions? I worry about the performance issues.

The functions will be implemented in stateless manner without the query/update database operations. They just need to get some input parameters and return the result.

[shydesky]

This TIP should be classified as the VM because an extra compiled contract is added in the VM and it must be implemented by all clients.

[taihaofu]

I like the idea to implement it using precompile contract, similar as ecrecover. We should consider to give a proper energy cost for these functions.

[btcbear89]

The total input length of verifyTransferProof is variable. There are four scenarios:

• one input and one output

[320 bytes for input][288 bytes for output][64 bytes for spend_authority_signature]

The total input lengh of verifyTransferProof is 1856 bytes.

From the file tip-137.md, I find the description of the length of verifyTransferProof, I can not calculate the 1856 bytes according to the input\output\spend_authority_signature. can you explain it in detail?

[btcbear89]

precompile contract, similar as ecrecover. We should consider to give a proper energy cost for these functions.

what's the advantage of using the precompiled contract's way? Why should we not implement it by allocating an OPCODE, like PUSH, DUMP?

[taihaofu]

precompile contract, similar as ecrecover. We should consider to give a proper energy cost for these functions.

what's the advantage of using the precompiled contract's way? Why should we not implement it by allocating an OPCODE, like PUSH, DUMP?

Actually we can use OPCODE. However, OPCODE should be more general, and focusing on vm level operation rather than complex computation. Precompile contract seems a better way, not touch db and also packs complex logic into single contract.

[Federico2014]

The total input length of verifyTransferProof is variable. There are four scenarios:

• one input and one output

[320 bytes for input][288 bytes for output][64 bytes for spend_authority_signature]

The total input lengh of verifyTransferProof is 1856 bytes.

From the file tip-137.md, I find the description of the length of verifyTransferProof, I can not calculate the 1856 bytes according to the input\output\spend_authority_signature. can you explain it in detail?

It's the total length of verifyTransferProof, which includes input, spend_authority_signature, output, bindingSignature, signHash, frontier, leafCount.

(bool result, bytes memory msg) = verifyTransferProof(abi.encode(input, spend_authority_signature, output, bindingSignature, signHash, frontier, leafCount));

[btcbear89]

precompile contract, similar as ecrecover. We should consider to give a proper energy cost for these functions.

what's the advantage of using the precompiled contract's way? Why should we not implement it by allocating an OPCODE, like PUSH, DUMP?

Actually we can use OPCODE. However, OPCODE should be more general, and focusing on vm level operation rather than complex computation. Precompile contract seems a better way, not touch db and also packs complex logic into single contract.

The total input length of verifyTransferProof is variable. There are four scenarios:

• one input and one output

[320 bytes for input][288 bytes for output][64 bytes for spend_authority_signature]

The total input lengh of verifyTransferProof is 1856 bytes.

From the file tip-137.md, I find the description of the length of verifyTransferProof, I can not calculate the 1856 bytes according to the input\output\spend_authority_signature. can you explain it in detail?

precompile contract, similar as ecrecover. We should consider to give a proper energy cost for these functions.

what's the advantage of using the precompiled contract's way? Why should we not implement it by allocating an OPCODE, like PUSH, DUMP?

Actually we can use OPCODE. However, OPCODE should be more general, and focusing on vm level operation rather than complex computation. Precompile contract seems a better way, not touch db and also packs complex logic into single contract.

How do you determine the address of the precompiled contract？Will we have a conflict with Ethereum?

[btcbear89]

length of verifyTransferProof, which includes

I know your means and verify it successfully. One more question, you mentioned four scenarios with different numbers of input and output. What do the input and output represent?