Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
2a91933 to
002a951
Compare
002a951 to
0bbe617
Compare
0bbe617 to
53c3c67
Compare
53c3c67 to
f81364f
Compare
ae110bb to
c4f6397
Compare
| IVerifier epochProofVerifier; | ||
| IInbox inbox; | ||
| IOutbox outbox; | ||
| uint256 version; |
There was a problem hiding this comment.
Unrelated to this PR, but what is this version supposed to represent? Is this supposed to function like our chain ID?
There was a problem hiding this comment.
Currently just to make sure that we can "scope" messages to a specific rollup instance. So the thing gets a bit weird here with chain ids and such.
Normally, you would have that the upgrade keeps the same chainid, and if there is a fork, the non-canonical gotta get a new one. In our case, if the instances are setup to be immutable, it cannot really just update its. So it is there as a version identifier.
So within the same "family", e.g., instances that are added to the same registry, we should also have different versions such that a transaction intended for 4 don't get played on 3. (there are a few updates to do to the registry if we really want to check these things and make the lookup better).
The reason that it is not a huge issue if some other instance deployed "outside" of the family is using the same version mainly comes from how our transactions are proven. As a transaction is referring to some header in the past to prove against, if state varies it won't be there. And if state is the same, is should be on the registry, or it should generally be possible to see it as a "worthless" variant.
On the chainid, it is a more painful thing really, and I don't know the best way forward for us there. Maybe it is just storing it in the registry, and then let the canonical use that 🤷 But users would expect it to move along the newest and to denote the "aztec network"
| rollupStore.blocks[blockNumber] = | ||
| toBlockLog(_args, blockNumber, components.congestionCost, components.provingCost); |
There was a problem hiding this comment.
I'm a little surprised this doesn't occur within the STFLib? In your mind, what lib is responsible for what?
There was a problem hiding this comment.
I think there will be another round of cleaning on top of this later, it is mainly getting the coarse split in place such that it is some of the way, the 80/20.
There was a problem hiding this comment.
Oh, ye, remembered, this was the only place using it, and the only reason that function even existed was to avoid a stack too deep.
| // We are using this library such that we can more easily "link" just a larger external library | ||
| // instead of a few smaller ones. | ||
|
|
||
| library ExtRollupLib { |
There was a problem hiding this comment.
Really nice to have submitEpochRootProof and propose in here.
c4f6397 to
30036b3
Compare
30036b3 to
fc82e91
Compare
|
Needs to update the cheat code used by the anvil watcher here to correctly update the proven storage slot. |
fc82e91 to
9a4b23c
Compare
9a4b23c to
2084d12
Compare

Fixes #12062, to take us part of the way for compartmentalisation. Changes a bunch of libraries to have block and proof submission be in libraries similar to others. Next steps are to split the storage access more, such that a case of ignition with empty blocks can be run while skipping a bunch of the fee computations etc. For that part, we also gotta consider how we should structure the storage for simpler reuse, so it is to be done separate.