Spike: Blob measurements and questions

Hi Leila's team!

Please could you help answer some Q's and collect some data about block root rollup circuit times, to inform some decisions about blobs?

Perhaps the data could be presented in comments below, or in a hackmd; whatever works for you.

Q1: Would it be possible to have various precomputed "sizes" of block root rollup circuit, for different numbers of blobs (e.g. 1,2,3,4,5,6,...)? How much engineering effort would this be?
Q2: How much engineering pain would it be to enable different blocks to be able to have differing numbers of blobs?
Q3: Currently, can side effects (such as contract bytecode) span a blob boundary?
Q4: how easy would it be to measure versions of the block root rollup circuit with different numbers of blobs?
- Request: please could you create table of values:
  - 1, 2, 3, 4, 5, 6 along one axis ("# blobs in block root rollup") (maybe also 8, 10, 12 if the process of updating constants doesn't take too long)
  - Against categories:
    - Witness generation time
    - Proving time
    - Witness generation time + proving time
    - Gate count
    - Maybe RAM, if it becomes an issue for the bigger circuits.
  - It'll be interesting to see if witgen/proving times grow linearly or worse-than-linearly.
Request: please could you provide an up-to-date approximation of the number of gates that relate to "blob stuff" vs "other stuff" in the block root rollup circuit?
Q5: It would be interesting to understand how we would upgrade the Aztec protocol to support more blobs in future. Would it be feasible after launch? What would it entail? If our current design doesn't support upgrades easily, what should we do to improve it?

@Maddiaa0

Q1 - This should be fine and not too difficult. I made the code generic over the constant BLOBS_PER_BLOCK to ensure it's easy to switch if we ever want to change that number.
Q2 - As above really - if we have seperate circuits for different numbers of blobs, we have achieved this. The most difficult part would be on L1 I think since gathering and storing public inputs for root proof verification is pretty complex and very close to stack too deep. If we have different cases for verifying this proof then we would have to rejig it even more. Not impossible or a bad idea though!
Q3 - Yes, it works today with no problem. ~~The only part of this I'm not aware of is reconstructing blocks over separate blobs as @Maddiaa0 is handling that.~~ EDIT: this works fine on feat: small blob fixes/improvements #11686
Q4 - Yep, I can do this. I do have 4-5 things on my todo list though so not sure when I can get to it. Do remember that in simulation (i.e. all e2e tests) we use an oracle to save time (feat(blobs): Remove ts blob oracle #10323).
Request: Yep, I can make an up to date flamegraph.
Q5 - As above, the circuits would be easy. Just requires changing BLOBS_PER_BLOCK. I'm not sure how reconstructing blocks from blobs in the node would work or whether having the L1 verification custom on this constant would be difficult to maintain though.

Closing.

For the others, we can create new issues if we ever feel the need to have flexible blob circuits.

Navigation Menu