Automatically select FRI reduction arities (#282)
* Automatically select FRI reduction arities
This way when a proof's degree changes, we won't need to manually update the `FriConfig`s of any recursive proofs on top of it.
For now I've added two methods of selecting arities. The first, `ConstantArityBits`, just applies a fixed reduciton arity until the degree has shrunk below a certain threshold. The second, `MinSize`, searches for the sequence of arities that minimizes proof size.
Note that this optimization is approximate -- e.g. it doesn't account for the effect of compression, and doesn't count some minor contributions to proof size, like the Merkle roots from the commit phase. It also assumes we're not using Merkle caps in serialized proofs, and that we're inferring one of the evaluations, even though we haven't made those changes yet.
I think we should generally use `ConstantArityBits` for proofs that we will recurse on, since using a single arity tends to be more recursion-friendly. We could use `MinSize` for generating final bridge proofs, since we won't do further recursion on top of those.
* Fix tests
* Feedback
2021-10-04 13:52:05 -07:00
|
|
|
use crate::fri::reduction_strategies::FriReductionStrategy;
|
|
|
|
|
|
2021-07-29 22:00:29 -07:00
|
|
|
pub mod commitment;
|
|
|
|
|
pub mod proof;
|
2021-05-05 18:23:59 +02:00
|
|
|
pub mod prover;
|
2021-07-29 22:00:29 -07:00
|
|
|
pub mod recursive_verifier;
|
Automatically select FRI reduction arities (#282)
* Automatically select FRI reduction arities
This way when a proof's degree changes, we won't need to manually update the `FriConfig`s of any recursive proofs on top of it.
For now I've added two methods of selecting arities. The first, `ConstantArityBits`, just applies a fixed reduciton arity until the degree has shrunk below a certain threshold. The second, `MinSize`, searches for the sequence of arities that minimizes proof size.
Note that this optimization is approximate -- e.g. it doesn't account for the effect of compression, and doesn't count some minor contributions to proof size, like the Merkle roots from the commit phase. It also assumes we're not using Merkle caps in serialized proofs, and that we're inferring one of the evaluations, even though we haven't made those changes yet.
I think we should generally use `ConstantArityBits` for proofs that we will recurse on, since using a single arity tends to be more recursion-friendly. We could use `MinSize` for generating final bridge proofs, since we won't do further recursion on top of those.
* Fix tests
* Feedback
2021-10-04 13:52:05 -07:00
|
|
|
pub mod reduction_strategies;
|
2021-05-05 18:23:59 +02:00
|
|
|
pub mod verifier;
|
|
|
|
|
|
2021-05-06 17:09:55 +02:00
|
|
|
#[derive(Debug, Clone, Eq, PartialEq)]
|
2021-05-05 18:23:59 +02:00
|
|
|
pub struct FriConfig {
|
|
|
|
|
pub proof_of_work_bits: u32,
|
|
|
|
|
|
Automatically select FRI reduction arities (#282)
* Automatically select FRI reduction arities
This way when a proof's degree changes, we won't need to manually update the `FriConfig`s of any recursive proofs on top of it.
For now I've added two methods of selecting arities. The first, `ConstantArityBits`, just applies a fixed reduciton arity until the degree has shrunk below a certain threshold. The second, `MinSize`, searches for the sequence of arities that minimizes proof size.
Note that this optimization is approximate -- e.g. it doesn't account for the effect of compression, and doesn't count some minor contributions to proof size, like the Merkle roots from the commit phase. It also assumes we're not using Merkle caps in serialized proofs, and that we're inferring one of the evaluations, even though we haven't made those changes yet.
I think we should generally use `ConstantArityBits` for proofs that we will recurse on, since using a single arity tends to be more recursion-friendly. We could use `MinSize` for generating final bridge proofs, since we won't do further recursion on top of those.
* Fix tests
* Feedback
2021-10-04 13:52:05 -07:00
|
|
|
pub reduction_strategy: FriReductionStrategy,
|
|
|
|
|
|
|
|
|
|
/// Number of query rounds to perform.
|
|
|
|
|
pub num_query_rounds: usize,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Parameters which are generated during preprocessing, in contrast to `FriConfig` which is
|
|
|
|
|
/// user-specified.
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
|
pub(crate) struct FriParams {
|
|
|
|
|
/// The arity of each FRI reduction step, expressed as the log2 of the actual arity.
|
2021-05-05 18:23:59 +02:00
|
|
|
/// For example, `[3, 2, 1]` would describe a FRI reduction tree with 8-to-1 reduction, then
|
|
|
|
|
/// a 4-to-1 reduction, then a 2-to-1 reduction. After these reductions, the reduced polynomial
|
|
|
|
|
/// is sent directly.
|
|
|
|
|
pub reduction_arity_bits: Vec<usize>,
|
2021-06-01 19:13:22 -07:00
|
|
|
}
|
2021-10-02 10:46:02 +02:00
|
|
|
|
Automatically select FRI reduction arities (#282)
* Automatically select FRI reduction arities
This way when a proof's degree changes, we won't need to manually update the `FriConfig`s of any recursive proofs on top of it.
For now I've added two methods of selecting arities. The first, `ConstantArityBits`, just applies a fixed reduciton arity until the degree has shrunk below a certain threshold. The second, `MinSize`, searches for the sequence of arities that minimizes proof size.
Note that this optimization is approximate -- e.g. it doesn't account for the effect of compression, and doesn't count some minor contributions to proof size, like the Merkle roots from the commit phase. It also assumes we're not using Merkle caps in serialized proofs, and that we're inferring one of the evaluations, even though we haven't made those changes yet.
I think we should generally use `ConstantArityBits` for proofs that we will recurse on, since using a single arity tends to be more recursion-friendly. We could use `MinSize` for generating final bridge proofs, since we won't do further recursion on top of those.
* Fix tests
* Feedback
2021-10-04 13:52:05 -07:00
|
|
|
impl FriParams {
|
2021-10-02 10:46:02 +02:00
|
|
|
pub(crate) fn total_arities(&self) -> usize {
|
|
|
|
|
self.reduction_arity_bits.iter().sum()
|
|
|
|
|
}
|
2021-10-05 23:28:04 -07:00
|
|
|
|
|
|
|
|
pub(crate) fn max_arity_bits(&self) -> Option<usize> {
|
|
|
|
|
self.reduction_arity_bits.iter().copied().max()
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub(crate) fn max_arity(&self) -> Option<usize> {
|
|
|
|
|
self.max_arity_bits().map(|bits| 1 << bits)
|
|
|
|
|
}
|
2021-10-02 10:46:02 +02:00
|
|
|
}
|