So this thread isn’t dead, that’s good. Are my concerns about GASLIMIT opcode valid? Is the changed meaning of GASLIMIT manifesting itself in the wild? Is there a plan to fix it?
This actually would royally screw a lot of the work I’ve been doing to build a trustless L2 state channel privacy layer with fully trustless sequencing - I need to keccak a bunch of inputs before they’re checked in ZK in order to avoid trusting anything in the chain before it feeds into the verifier. My submitted blocks/batched can contain a lot of public inputs and obviously the goal is to save gas by batching these transactions, but they end up over 5M on the L1 anyway (and can contain hundreds of “L2-like” txs within).
What is the proposed way I should be doing things? How are existing L2s getting away with this? I cannot use blobs yet because my proving system + language combo (noir) is not yet compatible / nobody has an efficient way to open blobs in noir. Feels like this takes a serious step towards biasing the crypto we should use - is this intentional with this EIP?
There have also been discussions happening in this thread.
To be clear, every transaction that pays the market price for inclusion should be included - nothing spam about it. However, this doesn’t mean we can be marginally more opinionated improve security and scaling.
In your example - the spammer creating multiple transactions - we achieved what we wanted, not blocking a single thread for some extensive time, guaranteeing a certain level of parallelization.
I agree that sentences in the EIP are poorly formulated but the rational for that change seemed clear to me.
People are well aware that there are affected users but after weighting the pros and cons, it’s a trade-off well worth it.