-
Notifications
You must be signed in to change notification settings - Fork 265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Generic Lookup Relations for AVM #3774
Conversation
Benchmark resultsMetrics with a significant change:
Detailed resultsAll benchmarks are run on txs on the This benchmark source data is available in JSON format on S3 here. Values are compared against data from master at commit L2 block published to L1Each column represents the number of txs on an L2 block published to L1.
L2 chain processingEach column represents the number of blocks on the L2 chain where each block has 16 txs.
Circuits statsStats on running time and I/O sizes collected for every circuit run across all benchmarks.
MiscellaneousTransaction sizes based on how many contracts are deployed in the tx.
|
f3fbf69
to
c2ba5ee
Compare
// 2) WRITE_TERMS number of polynomials representing how much each write term has been read | ||
// 3) READ_TERMS number of polynomials enabling the addition of a particular read term in this row (should we lookup | ||
// or not) | ||
// 4) WRITE_TERMS number of polynomials enabling a particular write term in this row (should we add it to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are 2 and 4 meant to be labelled the same?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are not labels, this is how many polynomials there are of each type (WRITE_TERMS) is how many table entries can be added per row
@@ -52,6 +52,12 @@ template <typename Flavor> class ToyAVMCircuitBuilder { | |||
const auto num_gates_log2 = static_cast<size_t>(numeric::get_msb64(num_gates)); | |||
size_t num_gates_pow2 = 1UL << (num_gates_log2 + (1UL << num_gates_log2 == num_gates ? 0 : 1)); | |||
|
|||
// We need at least 256 values for the range constraint |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is this? do we have precomputed columns that have a minimum size of 256?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just that in this implementation we add a table from 0-255 in compute_polynomials. It is not relation-generic, just for this concrete example.
* + READ - the action of looking up the value in the table | ||
* + WRITE - the action of adding the value to the lookup table | ||
* | ||
* TODO(@Rumata888): Talk to Zac why "lookup_read_count" refers to the count of the looked up element in the multiset. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The relation evaluates the following (with X replaced by a random challenge):
_
\ ____1____ - ____read_count[I]____
/ X + reads[I] X + writes[I]
¯
The reason why we multiple lookup_read_count
by the write predicate, is because we are also multiplying lookup_read_count
with (1 / X + writes[i]) from the above equation.
Does that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understood the formula, it was more the semantics that confused me, because we were using read count for the number of times we wrote
polys.lookup_xor_argument_1[i] = wires[6][i]; | ||
polys.lookup_xor_argument_2[i] = wires[7][i]; | ||
polys.lookup_xor_result[i] = wires[8][i]; | ||
polys.lookup_xor_accumulated_argument_1[i] = wires[9][i]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do lookup_xor_accumulated_argument_1
and lookup_xor_accumulated_argument_2
represent?
How many columns are we adding per distinct lookup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are trying to prove that lookup_xor_accumulated_argument_1 ^ lookup_xor_accumulated_argument_2 = lookup_xor_accumulated_result
. However they are 8-bit, so we decompose them. The top 4 bits of lookup_xor_accumulated_argument_1 will be in lookup_xor_argument_1.
For this particular case we added 6 columns for arguments. 2 3-element tuples.
@@ -0,0 +1,469 @@ | |||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One potential problem with defining lookups as independent relations is the very large number of inverse polynomials that are going to be created.
This will be expensive
Important question: does the relation algebra ensure that, if a given row is NOT performing a lookup, the value of the inverse polynomial is 0? If not, I think this will be needed or committing to 1 inverse polynomial per lookup column will be very painful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked, the polynomial should be zero when we are not performing lookups
Merged as a part of #3880 |
Adds generic lookup relation with range constraint and toy examples.
The relation is base on logderivative and can be parametrised for most of the common usecases
Checklist:
Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.