So this would initially just be a complicated pricing change but wouldn’t decrease load for the clients?
Makes sense to start with EIP-7907 as the simpler pricing change to allow for larger contracts; then revisit EIP-2926 as the pricing reduction and zk friendliness later? (or would be under charging for work done/memory used etc)
Don’t see how they are incompatible both make the exact same change to the account (i.e. length)
So this would initially just be a complicated pricing change but wouldn’t decrease load for the clients?
It would reduce the load for clients, that is the whole point of the EIP. Only load pages with a smaller granularity, closer to what your really use. In the worst case, meaning if no optimization taking advantage of the chunking is made, then you have the same performance (i.e. lack thereof) as 7907.
Makes sense to start with EIP-7907 as the simpler pricing change to allow for larger contracts; then revisit EIP-2926 as the pricing reduction and zk friendliness later? (or would be under charging for work done/memory used etc)
I would say that the risk is that people will keep saying “7907 is good enough, we just need to raise the limit again” and so the “temporary solution” will stick forever. Except it’s not a risk, it’s a guarantee.
zk friendliness is a shortcut here: it’s friendly to witness size. something that is used today. zk inherits this issue, as it needs small witnesses to work cheaper. But even without zk, there are stateless applications that benefit from that approach.
Don’t see how they are incompatible both make the exact same change to the account (i.e. length)
So they’re not incompatible per se, but once 7907 makes it in, it’s either instant tech debt, or actively preventing something very useful from being shipped.