EIP-7928: Block-level Access Lists: The Case for Glamsterdam

[Nerolation]

@gballet

This is lacking a proper analysis of how often the worst case really happens. Looking at dependency.pics, it doesn’t seem it’s happening that often (at all, really). Is it really worth the bandwidth costs, so that a few block, from time to time, are not super optimal? I would like to see this addressed.

I did some initial analysis on Execution Dependencies and the main findings were that “most blocks are highly parallelizable. On average, 60–80% of transactions are completely independent, and dependency chains are shallow. However, a small number of blocks have heavy entanglement and long critical paths, limiting parallelism — especially near the top-of-block (ToB), where MEV searchers compete for order.”

This was the design exploration with some concrete numbers:
I agree with your point and further analysis are needed (which are in the pipeline).

I agree that bandwidth is a key constraint in here. Currently, the size of a BAL is around 40–50 KiB, and this does not scale linearly with the gas limit. Eliminating the storage location fields could reduce their size by roughly half, but it’s unclear whether that trade-off is desirable.

@gballet

There are 5 different designs, and some of the touted properties of BALs are only available in some of these designs.

Right now, the discussions settled on storage locations + post-tx state diffs, with the storage locations TBD. Removing them saves space but also removes some functionality.

@gballet

I suggest also running a perfnet and a bloatnet, in order to find out how they really perform on a network.

Agreed. I also think we’ll need state diffs regardless of any performance gains, since zk nodes that want to maintain state will require them anyway. The real question is whether to go with post-transaction diffs or post-block diffs. Their worst-case sizes are basically the same, and while post-block diffs are slightly smaller on average, most transactions are independent, so the difference in size is very small on average. If the parallelization benefits don’t play out in prototypes, we can switch to post-block diffs. But I expect the gains from fully parallelizable blocks to make post-tx diffs clearly worth it.

@gballet

This would have to be trusted, though: You would need some kind of extra mechanism to validate that the BAL is correct, which partial stateless designs can’t. Verkle can do this, binary trees can do this, zkvms can do this, each with many trade-offs. I don’t see how that would be true with BALs.

Yeah, you’re right, in order to trustlessly stay at the tip of the chain you’d need witnesses coming alongside the state diff and thus you wouldn’t be able to use it for validating but there are other use cases for it. Every full node user that just cares about having access to an RPC could run a partial statelessness node. Every node that wants to quickly sync and accepts the “risk” to not have merkle proofs alongside with state diffs since it finds out about the correctness of the syncing process if arriving at the correct head.
The problem I see with witnesses are just their size.