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
|`compliance_circuit`|| A specific feature for compliance circuit |
76
-
|`transaction (default)`|`compliance_circuit`, `client`| It provides full transaction processing capabilities and will be in the Anoma SDK and validator with a selected prover feature. Succinct prover is used by default. |
76
+
|`transaction (default)`|`compliance_circuit`, `client`| It provides full transaction processing capabilities and supports Succinct(STARK) and Groth16 proof types. Groth16 proofs require x86_64 machines. |
77
77
|`prove`|| Enables RISC0 proving capabilities (required for actual proof generation) |
78
78
|`bonsai`|| Enables RISC0 bonsai sdk |
79
79
|`client`|| Enables RISC0 client sdk |
80
80
|`cuda`|| Enables CUDA GPU acceleration for the prover. Requires CUDA toolkit to be installed. |
81
-
|`fast_prover`|| Fastest option producing linear-size proofs, and does not support compression via recursion |
82
-
|`composite_prover`|| Fastest option producing linear-size proofs, and supports compression via recursion |
If a single transaction bundles too many resources, it is possible to aggregate all compliance and logic proofs into a single aggregation proof, attesting to the validity of them all. This reduces overall verification time and transaction size.
128
+
If a single transaction bundles too many resources, it is possible to aggregate all compliance and logic proofs into a single aggregation proof, attesting to the validity of them all. This reduces overall verification time and transaction size.
141
129
142
130
### Before aggregation
143
-
Generate the transaction in the normal way in your workflow. But note that succinct proofs will yield faster aggregation.
131
+
Generate the transaction in the normal way in your workflow. But note that succinct proofs will yield faster aggregation.
144
132
145
-
**Warning:**Bonsai does not support in-circuit verification of Groth16 proofs. You would need to generate succinct compliance and logic proofs instead.
133
+
**Warning:**It does not support in-circuit verification of Groth16 proofs. You would need to generate succinct compliance and logic proofs instead.
146
134
147
135
148
136
### Prove aggregations
149
-
You need to enable the `aggregation` feature to be able to prove or verify aggregations.
137
+
You need to enable the `aggregation` feature to be able to prove or verify aggregations.
150
138
151
-
The type of the aggregation proof is selected via a feature. It defaults to succinct stark proofs. For on-chain verification, you probably want to aggregate with the `groth16_aggregation` feature enabled. See the features table above for more information.
139
+
The aggregation proof type is specified by the ProofType argument. The inner proofs must be Succinct.
152
140
153
141
We currently support two different aggregation strategies. The _batch_ strategy aggregates all proofs in the transaction in a single run. It is the default aggregation.
154
142
155
143
```rust
156
144
usearm::transaction;
157
145
158
-
letmuttx=generate_test_transaction(1); // Just a dummy tx, for illustration.
146
+
// Just a dummy tx, for illustration. The inner proofs must be Succinct.
**Warning:** Once again, aggregation erases all the individual proofs from `tx` and replaces them with the (single) aggregation proof in a dedicated field. This is why the transaction must be `mut`. This is true independently of the strategy used.
0 commit comments