* calculate MainPod id in a dynamic-friendly way
The MainPod id is now calculated with front padding and a fixed size
independent of max_public_statements so that introduction gadgets can be
verified by a MainPod while paying only for the number of statements
they use. This is because with front padding of none-statements we can
precompute the poseidon state corresponding to absorbing all the padding
statements and only pay constraints for the non-padding statements.
The id is calculated as follows:
`id = hash(serialize(reverse(statements || none-statements)))`
* fix test
* Add RecursiveCircuit
The RecursiveCircuit verifies N proofs of itself (N=arity), together with
the logic defined at the InnerCircuit (in our case, used for the
MainPodCircuit logic).
The arity defines the maximum amount of proofs of itself that the
RecursiveCircuit verifies. When arity>1, using the RecursiveCircuit has the
shape of a tree of the same arity.
π_root
▲
┌───────┴────────┐
│RecursiveCircuit│
└─▲───▲───▲────▲─┘
┌───────┘ ┌┘ └┐ └──────┐
│π''_1 │ ... │ π''_N│
┌────────┴───────┐ ┌┴┐┌─┐┌┴┐ ┌───────┴────────┐
│RecursiveCircuit│ │.││.││.│ │RecursiveCircuit│
└──▲─────────▲───┘ └─┘└─┘└─┘ └──▲─────────▲───┘
│ │ │ │
π_1 ... π_N π'_1 ... π'_N
where
N: arity of the RecursiveCircuit
π_i: plonky2 proof of the RecursiveCircuit
* add different inner-circuits in the test, reusing the same verifier_data; polish recursion interfaces
* add InnerCircuit::Params
* rm non_base_node
* WIP refactor RecursiveCircuit
* wip. change approach on verifier_data of circuits used in recursivecircuit. arity=1 works
* recursion works fine without registering verifierdatas as publicinputs
* add hashing of verifier_data (out & in-circuit) methods with test
* connect previous and current verifier_datas hashes
* polish
* add InnerCircuit's public_inputs to the RecursiveCircuit
* extend recursive test
* polish & review suggestions
* WIP
* WIP
* Working serialization for both Mock and Plonky2 versions of Signed and Main Pods
* Restore useful comment about serialized_proof()
* Use plonky2 serialization for signatures and proofs
* Add schema renames for Serialized SignedPod/MainPod types
* Break out utility function for generating common circuit data
* Review feedback fixes
* Implement Gt and GtEq as syntactic sugar
* Update src/backends/plonky2/circuits/mainpod.rs
Co-authored-by: Eduard S. <eduardsanou@posteo.net>
* Op verification circuit refactor
* Code review
* Add range check to Eq case of LtEq
* Style
* Factor out ValueOf statement argument type checks
* Formatting
* Clean-up
* Safety
* Take sign into account
* Simplify sign check
---------
Co-authored-by: Eduard S. <eduardsanou@posteo.net>
* migrate from anyhow to thiserror (#190). pending polish error msgs
* Add backtrace and compartmentalize errors
- Include backtraces in the errors we generate. To get this we can't
just return a literal enum, because the backtrace requires a call.
- Related to the previous point: add methods to create errors so
we can include the backtrace conveniently without changing too much
the syntax. So instead of `Err(Error::KeyNotFound(key))` (literal
enum) it will be `Err(Error::key_not_found(key))` (method call)
- Each error should be local to its scope, and each scope should
only return its own error.
- The merkle tree should return `TreeError` and not Error
- The middleware should return `MiddlewareError` and not Error
- With a global Error we can't easily include backend/frontend types in
the error fields, so declare a `BackendError` and a `FrontendError`
and follow the pattern from the previous point
- The Pod traits should be able to return backend errors and will be
used in the frontend; for that we change them to use trait object
Error: `dyn std::error::Error`
* fix error
* apply suggestions from @arnaucube
* rename XError and XResult to Error and Result
* reorg signature
* make frontend custom error more ergonomic
* remove unnecessary feature
---------
Co-authored-by: Eduard S. <eduardsanou@posteo.net>
* Serialization tests now pass again
* Tidy up and test more edge-cases
* Use attributes rather than custom serializer for arrays
* Add JSON Schema support
* Tests for JSON Schema generation and validation
* Add comments
* Support custom predicates
* Clippy fixes
* Make deserialization/constructor functions pub(crate)
* unify fe/be NativeOp and NativePred
* remove Origin in favour of PodId
* Combine string and hash in Key
* use middleware::AnchoredKey in frontend
* merge frontend/middleware types
* refactor custom predicates
* clean up a bit
* fix middleware custom tests
* clean up
* clean up 2
* add acronyms in typos list
* All test pass on middleware->frontend type refactor
* Convert frontend CustomPredicateRef to a named field struct
* Minor serialization improvements
* Set appropriate titles in JSON schemas
* Add names for custom predicates
* Remove PodClass from front-end Origin type
* Simplify value conversion
---------
Co-authored-by: Ahmad <root@ahmadafuni.com>
* add boolean selector to the MerkleProofGadget, to allow skipping proof verifications when all the slots are not used (eg. in the SignedPod circuit)
* move existing signedpod's circuits draft to its own file
* implement SignedPodVerify circuit
* implement circuit to verify signature (proof-based signature), ie. a 1-level recursion verification
* as agreed in the call, rename Gate -> Gadget when it's not a 'gate'
* make SignatureVerifyGadget conditional on the selector input
* small naming polish
* sigverifygadget: add s computation in-circuit, connect pk,msg,s to internalproof's public_inputs
* optimize signature verify
---------
Co-authored-by: Eduard S. <eduardsanou@posteo.net>
* Contains should take three arguments (root, key, value)
* Add a test for frontend Dictionaries
* Separate frontend and middleware operations
* Make tests pass: add arg to contains
* Cargo fmt
* Merkleproof verify circuit (#143)
* merkletree: add keypath circuit
* merkletree-circuit: implement proof of existence verification in-circuit
* parametrize max_depth at the tree circuit
* Constrain selectors in-circuit
* implement merketree nonexistence proof circuit, and add edgecase tests
* add non-existence proofs documentation in the mdbook, mv EMPTY->EMPTY_VALUE & NULL->EMPTY_HASH, dependency clean and public exposure methods
* review comments, some extra polishing and add a test that expects wrong proofs to fail
* Add circuit to check only merkleproofs-of-existence
With this, the merkletree_circuit module offers two different circuits:
- `MerkleProofCircuit`: allows to verify both proofs of existence and proofs
non-existence with the same circuit.
- `MerkleProofExistenceCircuit`: allows to verify proofs of existence only.
In this way, if only proofs of existence are needed,
`MerkleProofExistenceCircuit` should be used, which requires less amount
of constraints than `MerkleProofCircuit`.
* Code review
---------
Co-authored-by: Ahmad <root@ahmadafuni.com>
* Towards Contains/NotContains in middleware and backend
* Fix build
* Adding error handling to deal with op compile introduce extra ops
* Incorporate Merkle proofs into MockMainPod
* Merkleproof verify circuit (#143)
* merkletree: add keypath circuit
* merkletree-circuit: implement proof of existence verification in-circuit
* parametrize max_depth at the tree circuit
* Constrain selectors in-circuit
* implement merketree nonexistence proof circuit, and add edgecase tests
* add non-existence proofs documentation in the mdbook, mv EMPTY->EMPTY_VALUE & NULL->EMPTY_HASH, dependency clean and public exposure methods
* review comments, some extra polishing and add a test that expects wrong proofs to fail
* Add circuit to check only merkleproofs-of-existence
With this, the merkletree_circuit module offers two different circuits:
- `MerkleProofCircuit`: allows to verify both proofs of existence and proofs
non-existence with the same circuit.
- `MerkleProofExistenceCircuit`: allows to verify proofs of existence only.
In this way, if only proofs of existence are needed,
`MerkleProofExistenceCircuit` should be used, which requires less amount
of constraints than `MerkleProofCircuit`.
* Code review
---------
Co-authored-by: Ahmad <root@ahmadafuni.com>
* Towards Contains/NotContains in middleware and backend
* Frontend compound types -- allow one frontend operation to produce multiple middleware statements (in progress)
* Incorporate Merkle proofs into MockMainPod
* Incorporate Merkle proof op arg into frontend
* Compile one statement to many, in progress
* Fix remaining tests
* Minor clean-up
* Oops I did a bunch of work in the middle of a rebase, committing
* Incorporate Merkle proof op arg into frontend
* still working on frontend compound types, refactor compile() to output multiple statements
* Contains statements for frontend types: code compiles
* Tests pass
* Examples use front-end compound types
* Remove old Contains and NotContains from frontend
* Add nin to typos
* Code review
---------
Co-authored-by: arnaucube <git@arnaucube.com>
Co-authored-by: Ahmad <root@ahmadafuni.com>
* feat: add MainPod circuit skeleton
* feat: use ValueTarget in mt, verify SignedPod type
* wip
* feat: match structure with mock
* apply feedback from @arnaucube
* add 2 operations
* fix test compilation
* Add missing todo
* merkletree: add keypath circuit
* merkletree-circuit: implement proof of existence verification in-circuit
* parametrize max_depth at the tree circuit
* Constrain selectors in-circuit
* implement merketree nonexistence proof circuit, and add edgecase tests
* add non-existence proofs documentation in the mdbook, mv EMPTY->EMPTY_VALUE & NULL->EMPTY_HASH, dependency clean and public exposure methods
* review comments, some extra polishing and add a test that expects wrong proofs to fail
* Add circuit to check only merkleproofs-of-existence
With this, the merkletree_circuit module offers two different circuits:
- `MerkleProofCircuit`: allows to verify both proofs of existence and proofs
non-existence with the same circuit.
- `MerkleProofExistenceCircuit`: allows to verify proofs of existence only.
In this way, if only proofs of existence are needed,
`MerkleProofExistenceCircuit` should be used, which requires less amount
of constraints than `MerkleProofCircuit`.
* Code review
---------
Co-authored-by: Ahmad <root@ahmadafuni.com>
* add initial counter setup
We can extend it to also count the POD operations or other kind of logic
that we might want to count.
Co-authored-by: Ahmad Afuni <root@ahmadafuni.com>
---------
Co-authored-by: Ahmad Afuni <root@ahmadafuni.com>
