plonky2/src/gadgets/mod.rs

pub mod arithmetic;
pub mod arithmetic_extension;
pub mod hash;
pub mod insert;
pub mod interpolation;
pub mod polynomial;
pub mod random_access;
pub mod range_check;
pub mod select;
pub mod split_base;
pub(crate) mod split_join;
Misc fixes to get tests green again 2021-04-09 11:40:51 -07:00			`pub mod arithmetic;`
Rearrange files 2021-06-25 16:45:02 +02:00			`pub mod arithmetic_extension;`
Misc fixes to get tests green again 2021-04-09 11:40:51 -07:00			`pub mod hash;`
Add `insert` gadget to insert inferred leaf in FRI query rounds 2021-06-14 15:15:22 +02:00			`pub mod insert;`
Interpolation of two points 2021-06-07 21:24:41 +02:00			`pub mod interpolation;`
Recursive evaluation for interpolation gate. 2021-05-24 17:31:55 +02:00			`pub mod polynomial;`
added random access gadget 2021-08-04 10:58:07 -07:00			`pub mod random_access;`
Add low-high split 2021-06-10 15:55:29 +02:00			`pub mod range_check;`
- Remove useless rotation gadgets - rotate.rs -> select.rs - Added `select()` and `select_ext` - Optimize to use just one gate 2021-07-22 11:58:29 +02:00			`pub mod select;`
Recursive PoW 2021-06-04 16:02:48 +02:00			`pub mod split_base;`
Candidate API for Merkle proof data Does this make sense? I think other libraries tend to include the leaf's index (either as an integer, or a series of bits indicating left/right turns) as part of a "proof". In FRI, the leaf indices are chosen by the verifier, so I thought that approach might be sort of redundant. Let me know what you think though. 2021-04-06 19:11:21 -07:00			`pub(crate) mod split_join;`