Repository navigation
feat(acir)!: BrilligCall opcode - #5709
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. 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.
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
Transaction processing duration by data writes.
|
left a comment
•
There was a problem hiding this comment.
Looks good to me, although I agree that we could make it so BrilligPointer looks more like acir calls (no intermediate struct, rename to BrilligCall). I think we should do it now since it will be another serialization breaking change.
Co-authored-by: Tom French <15848336+TomAFrench@users.noreply.github.com>
This starts work towards noir-lang/noir#3907 but is only the breaking serialization change.
Codegen and evaluation will come in a follow-up. This PR is purely additive and does not remove the current way we do Brillig gen during ACIR gen. Codegen for normal Brillig functions is working in my follow-up, however, removing the existing Brillig opcode will most likely have to come once we settle on how to handle the brillig std lib as we are currently generating code such as calculating a quotient during ACIR gen.