sourcify.eth

Some thoughts on gas repricings and their impact. Gas costs increasing for state operations does not mean they get proportionally more expensive, because the gas limit is increasing. What is the point of increasing the costs of these operations but then also increasing the gas limit? The point is scaling: many other operations are currently overpriced, and, by keeping their gas costs fixed and increasing the gas limit, the protocol recognizes this and increases the supply *of those operations only*. The state operations get *relatively* more expensive than these, but not necessarily more expensive in absolute terms. The overall story is that Ethereum is scaling: the gas limit is going up to 200M after being stuck at 30M for years, and most operations are benefitting from this increase in the gas supply (their gas cost is not changing). The ones that are not, like writing new state, will be subject to further scaling efforts in the future. This is separate from the question of some smart contracts being affected by the repricings and related changes in the gas mechanism. Largely, the impact is on contracts that in one way or another have hardcoded gas costs or made assumptions about them not changing (e.g. if less than X gas remains then this branch reverts). This is unfortunate but somewhat inevitable when gas costs change, which I think is a fairly inevitable step in scaling Ethereum: the current gas costs are basically a decade old, some operations are much cheaper and some much more expensive than their gas cost implies! It is also unlikely to be the last time they change, because over time gas costs can drift away from being representative of the actual cost of the operations, exactly what brought us to this point. However, this can be the last time that it affects contracts, if it becomes standard practice to not make assumptions about gas costs in the future. Getting this out of the way can be a step towards more immutability, especially if we work to clearly define which invariants should be guaranteed by the execution layer, so that contracts can be written on a solid foundation. That said, the impact on contracts should have been more deeply investigated sooner, and perhaps more importantly communication about the change should have been more frequent and more direct. It has never been easier to run contract scans (I was able to find some affected contracts just with a few agents and the @SourcifyEth database), and I think it should be a standard practice for protocol upgrades in the future to run such scans with the latest spec, and that app developers should also be encouraged and given tooling to do so with their contracts.

We’ve mirrored @SourcifyEth verified mainnet data on [ ARKIV ] ’s testnet. A working pilot you can try today 👇 Live demo at Devcon tomorrow, Booth Core 03.