Skip to content

TIP-137: add the link #144

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Apr 7, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 16 additions & 15 deletions tip-137.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
```
tip: 137
title: Zero-knowledeg Proof Verification functions
title: Zero-knowledge Proof Verification functions
author: federico<federico.zhen@tron.network>
discussions-to: https://github.com/tronprotocol/tips/issues/137
status: draft
Expand All @@ -12,32 +12,32 @@ created: 2020-03-09

## Simple Summary

The TIP provides the zero-knowledge proof verification functions in shielded contract, which can be used in shielded token transactions.
The TIP provides the zero-knowledge proof verification functions in the shielded contract ([TIP-135](https://github.com/tronprotocol/tips/blob/master/tip-135.md)), which can be used in shielded token transactions.

## Abstract

The TIP introduces three new functions: `verifyMintProof`, `verifyTransferProof`, and `verifyBurnProof`, which are implemented in the form of precompiled contract, and can accelerate the zero-knowledge verification for the `mint`, `transfer` and `burn` operations in shielded token contract.
The TIP introduces three new functions: `verifyMintProof`, `verifyTransferProof`, and `verifyBurnProof`, which are implemented in the form of the precompiled contract, and can accelerate the zero-knowledge verification for the `mint`, `transfer` and `burn` operations in the shielded token contract.

## Motivation

In order to implement shielded transaction for [TRC-20](https://github.com/tronprotocol/TIPs/blob/master/tip-20.md) token, We have developed 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 is implemented based on zero-knowledge proof, so it needs the complex zero-knowledge proof verification in `mint`, `transfer` and `burn` methods. In order to accelerate the speed, we will make use of the new functions in the contract to implement the verification process.
To implement the shielded transactions for [TRC-20](https://github.com/tronprotocol/TIPs/blob/master/tip-20.md) token, We have developed the shielded token contract ([TIP-135](https://github.com/tronprotocol/tips/blob/master/tip-135.md)). 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 is implemented based on zero-knowledge proof, so it needs the complex zero-knowledge proof verification in `mint`, `transfer` and `burn` methods. To accelerate the speed, we will make use of the new functions in the contract to implement the verification process.

## Specification

The following define the methods implementation for shielded token contract.
The following defines the implementation of the methods for the shielded token contract.

### Preliminaries
**NoteCommitment**

The TRC-20 token is tranformed into shielded token in the form of commitment by cryptographic method, which is defined as:
The TRC-20 token is transformed into shielded token in the form of commitment by cryptographic method, which is defined as:

*note<sub>-</sub>commitment = NoteCommitment<sub>r</sub>(v)*

The `v` value is hided by `note_commitment` with the blinding factor `r`.
The `v` value is hidden by `note_commitment` with the blinding factor `r`.

**SpendDescription**

The `SpendDescription` includes zk-SNARK proof related data, which is used as the input of shielded token transaction.
The `SpendDescription` includes zk-SNARK proof related data, which is used as the input of the shielded token transaction.

```text
message SpendDescription {
Expand All @@ -52,7 +52,7 @@ message SpendDescription {

**ReceiveDescription**

The `ReceiveDescrion` also includes zk-SNARK proof related data, which is used as the output of shielded token transaction.
The `ReceiveDescrion` also includes zk-SNARK proof related data, which is used as the output of the shielded token transaction.

```text
message ReceiveDescription {
Expand Down Expand Up @@ -117,32 +117,32 @@ The total input length of `verifyTransferProof` is variable. According to the in
[320 bytes for input][288 bytes for output][64 bytes for spend_authority_signature]
```

The total input lengh of `verifyTransferProof` is 1856 bytes.
The total input length of `verifyTransferProof` is 1856 bytes.

- one input and two output

```
[320 bytes for input][576 bytes for output][64 bytes for spend_authority_signature]
```
The total input lengh of `verifyTransferProof` is 2144 bytes.
The total input length of `verifyTransferProof` is 2144 bytes.

- two input and one output

```
[640 bytes for input][288 bytes for output][128 bytes for spend_authority_signature]
```

The total input lengh of `verifyTransferProof` is 2240 bytes.
The total input length of `verifyTransferProof` is 2240 bytes.

- Two input and two output

```
[640 bytes for input][576 bytes for output][128 bytes for spend_authority_signature]
```

The total input lengh of `verifyTransferProof` is 2528 bytes.
The total input length of `verifyTransferProof` is 2528 bytes.

For the output, `result` is a bool value to indicate whether the proof verification succeeds. The length of `msg` is 66~1058 bytes. , and the other bytes return the node value to construct the Merkle tree. The time cost of `verifyTransferProof` function takes about 10~15ms in parallel mode.
For the output, `result` is a bool value to indicate whether the proof verification succeeds. The length of `msg` is 66 ~ 1058 bytes, which returns the node value to construct the Merkle tree. The time cost of `verifyTransferProof` function takes about 10~15 ms in parallel mode.

(3)`verifyBurnProof`

Expand All @@ -153,7 +153,7 @@ bytes32[10] input = abi.encode(nullifier, anchor, value_commitment, rk, zkproof)
(bool result, bytes memory msg) = verifyBurnProof(abi.encode(input, spend_authority_signature, value, bindingSignature, signHash));
```

- `value` - the amout of shielded tokens to be made public
- `value` - the amount of shielded tokens to be made public

The other parameters are specified as above.

Expand Down Expand Up @@ -276,4 +276,5 @@ Output:
## Implementation

* https://github.com/tronprotocol/java-tron/blob/feature/shielded_TRC20_contract/actuator/src/main/java/org/tron/core/vm/PrecompiledContracts.java
* https://github.com/tronprotocol/java-tron/blob/feature/shieldedUSDT/deploy/PrivateUSDT.sol