-
Notifications
You must be signed in to change notification settings - Fork 268
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
chore: reproduce bug for duplicate lagrange_first commitment #6577
Conversation
Benchmark resultsNo metrics with a significant change found. Detailed resultsAll benchmarks are run on txs on the This benchmark source data is available in JSON format on S3 here. Proof generationEach column represents the number of threads used in proof generation.
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 kernel circuit run across all benchmarks.
Stats on running time collected for app circuits
Tree insertion statsThe duration to insert a fixed batch of leaves into each tree type.
MiscellaneousTransaction sizes based on how many contract classes are registered in the tx.
Transaction size based on fee payment method | Metric | | |
d5520f4
to
2cf58f6
Compare
When making an update to the DataBus, I ran into an issue where one of the new databus related polynomials that I added was identical to lagrange_first (and thus has the same commitment) which seemingly leads to failure in the Ultra arithmetized biggroup. This PR minimally reproduces this issue by adding a fake new polynomial that's not actually used in any relations but is otherwise treated as any other polynomial in the proving system. If this polynomial is set to be equal to L_1, we get failures. If not, there is no issue.