You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The TIP provides the zero-knowledge proof verification functions in shielded contract, which can be used in shielded token transactions.
15
+
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.
16
16
17
17
## Abstract
18
18
19
-
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.
19
+
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.
20
20
21
21
## Motivation
22
22
23
-
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.
23
+
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.
24
24
25
25
## Specification
26
26
27
-
The following define the methods implementation for shielded token contract.
27
+
The following defines the implementation of the methods for the shielded token contract.
28
28
29
29
### Preliminaries
30
30
**NoteCommitment**
31
31
32
-
The TRC-20 token is tranformed into shielded token in the form of commitment by cryptographic method, which is defined as:
32
+
The TRC-20 token is transformed into shielded token in the form of commitment by cryptographic method, which is defined as:
The `v` value is hided by `note_commitment` with the blinding factor `r`.
36
+
The `v` value is hidden by `note_commitment` with the blinding factor `r`.
37
37
38
38
**SpendDescription**
39
39
40
-
The `SpendDescription` includes zk-SNARK proof related data, which is used as the input of shielded token transaction.
40
+
The `SpendDescription` includes zk-SNARK proof related data, which is used as the input of the shielded token transaction.
41
41
42
42
```text
43
43
message SpendDescription {
@@ -52,7 +52,7 @@ message SpendDescription {
52
52
53
53
**ReceiveDescription**
54
54
55
-
The `ReceiveDescrion` also includes zk-SNARK proof related data, which is used as the output of shielded token transaction.
55
+
The `ReceiveDescrion` also includes zk-SNARK proof related data, which is used as the output of the shielded token transaction.
56
56
57
57
```text
58
58
message ReceiveDescription {
@@ -117,32 +117,32 @@ The total input length of `verifyTransferProof` is variable. According to the in
117
117
[320 bytes for input][288 bytes for output][64 bytes for spend_authority_signature]
118
118
```
119
119
120
-
The total input lengh of `verifyTransferProof` is 1856 bytes.
120
+
The total input length of `verifyTransferProof` is 1856 bytes.
121
121
122
122
- one input and two output
123
123
124
124
```
125
125
[320 bytes for input][576 bytes for output][64 bytes for spend_authority_signature]
126
126
```
127
-
The total input lengh of `verifyTransferProof` is 2144 bytes.
127
+
The total input length of `verifyTransferProof` is 2144 bytes.
128
128
129
129
- two input and one output
130
130
131
131
```
132
132
[640 bytes for input][288 bytes for output][128 bytes for spend_authority_signature]
133
133
```
134
134
135
-
The total input lengh of `verifyTransferProof` is 2240 bytes.
135
+
The total input length of `verifyTransferProof` is 2240 bytes.
136
136
137
137
- Two input and two output
138
138
139
139
```
140
140
[640 bytes for input][576 bytes for output][128 bytes for spend_authority_signature]
141
141
```
142
142
143
-
The total input lengh of `verifyTransferProof` is 2528 bytes.
143
+
The total input length of `verifyTransferProof` is 2528 bytes.
144
144
145
-
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.
145
+
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.
0 commit comments