Bob Summerwill @ DEVCON8 🇮🇳

PLEASE STOP FUCKING WITH ETHEREUM WITHOUT ASKING THE PEOPLE WHO BUILD ON IT: FIVE REASONS I AM TIRED [feat. Wildcat Labs, a company that is filled with Ethereum die-hards and works exclusively on code that has originated over a billion dollars of economic activity for the chain, but these are my opinions not that of Labs itself etc] --- REASON ONE: Our entire market deployment flow breaks on day one of Glamsterdam Wildcat's core product involves a borrower creating a market that they've specified the way that they determine is best for them. That includes the core market itself (interest rate, underlying asset, debt token name), and a separate configuration (through hooks) granting access to the market and its functions (i.e. who can deposit, can debt be transferred, are withdrawal requests subject to a fixed-term tenor and so on). In our currently deployed, immutable V2 code, what used to be a single transaction bundling those things together goes from 8.6M gas to ~62-71M, which means we can't fit it into a 60M block (don't you dare 'but ackshually' me, I am coming back to this). Nothing in our contracts changed: the chain reprices bytecode deposits by 7.65x underneath already-audited code. We only have a workaround because our factory happens to expose the two halves separately, so we need to boot out an SDK and frontend release, plus pray folk are using a wallet that will sign a 35M gas field. Every borrower's first market to date used a call that will no longer fit in a block as-is (I said I'm coming back to it). The reason I am starting to... express opinions, is that this is the second time in a year that the execution layer has changed what a deployed contract costs to use (EIP-7825's cap in Fusaka, now state gas), and each time the burden of discovering it lands on us, the teams developing applications that drive economic activity on the chain, and we have to do it by replaying our own history on a testnet. [This is going to be a long post. I am Not Pleased.] --- REASON TWO: We are relying on social consensus for any hope of relief The repricing aspect is consensus: at the fork, every validator must enforce it. The gas limit - the thing that would make a ~70M transaction possible post-Glamsterdam - is a validator-set preference with no mainnet schedule. Sepolia was handed 200M, and things look fine over there. Hoodi had its 200M yeeted out the airlock the day the fork was postponed. So, the testnet that "proves" the fork works runs with over three times the headroom of mainnet, but the fork's own design assumes a headroom that nobody has committed to. For a protocol that needs to tell institutional borrowers what a market costs to open, Wildcat's honest answer after Glamsterdam has to be "it depends on a social campaign to change validator config files," and that isn't a dependency that a credit product should carry. We are engineers, not lobbyists. It also means Wildcat's capacity planning is hostage to the same ACD calls that are currently stalled on a security review of the very EIP that created the problem. You know what, Ameen, you are a core dev now. Why not. --- REASON THREE: As-is, Safe App deployments of mainnet Wildcat markets fail after the fork Safes are the default custody mechanism for exactly the borrowers Wildcat wants, and just over a third of V2 markets (29 of 82) were deployed via one. Under EIP-8037, the GAS opcode no longer reports the reservoir, so a Safe's execution check (GS010) can never be satisfied for a transaction that needs more than the execution cap. On either deploy entrypoint: the core market itself or its hooks. Historical Wildcat Safe deployments set safeTxGas to zero and survive. The Safe App and safe-apps-provider path set it from the estimate... and die. :) We can patch our own route (send safeTxGas 0, which our testnet branch already does), and we will. What nobody owns is the default: every Safe App on Ethereum that lets the provider fill safeTxGas from an estimate above ~16.4M dies in the same way. This is not Wildcat's bug, nor is it Safe's in any useful sense. It is a consensus change that silently invalidates a safety check in the most widely deployed smart-contract wallet on Ethereum, with no deprecation path, and as of today nobody owns fixing it. Building on a platform where our users' wallets can be broken by a gas-accounting EIP is something that every single protocol team should be screaming things that would get us put on trial in The Hague about. --- REASON FOUR: Every single part of the tooling stack currently assumes tx.gas stops before the reservoir Fusaka taught Ethereum developers that a transaction cannot exceed 16.78M, and so tooling calcified around that number because... why wouldn't it? It's not even a year old yet! As it stands, geth's default 50M RPC cap can't estimate the combined deploy of a Wildcat V2 market, and public nodes cap eth_call the same way. Even our own release ceremony prices contract deployments statically at 200 gas per byte against the 1,530 already live on Sepolia (our simulation gate catches it, the planner doesn't). Glamsterdam now says the gas field can be 4.29 billion, with the part above 16.78M living in a reservoir that neither GAS nor most estimators nor any wallet UI understands yet. When our V2.5 audit is done and it's time for us to deploy the necessary factories, the install is sixteen transactions and about six blocks' worth of gas, at most one big creation per block, and every wallet and integrator that Wildcat touches has to re-learn gas at the same time. With no shared reference implementation. None of this is Wildcat's code, all of it is Wildcat's outage, and the execution layer will have shipped two contradictory gas models in consecutive forks. Masterful gambit. [and this last one's just me being me about my most hated and well-known bugbear] --- REASON FIVE: Code bytes are now 96 percent of what one of our markets costs to deploy, but the spec is still moving I have spent coming up ten years - near enough since its introduction - begging for the death of EIP-170, and I genuinely don't know why I dared to believe that anything except a monkey's paw would answer me. At 1,530 gas per byte, the cost of deploying a V2.5 market (when it launches) is almost entirely the price of copying 23 KB of bytecode into state. A lender’s first deposit to a Wildcat market costs about 3x the gas it would pre-Glamsterdam, because every fresh storage slot went from 22,100 gas to 110,020. EIP-7954's promised 64 KB contracts are capped in practice at about 38 KB by a 60M block, so the one concession to builders in this fork - the one I have been asking for since my age first started leading with a 3 - is muted on mainnet until the aforementioned social campaign gets the gas limit bumped to 200M. Which we have to take on faith right now. Meanwhile, the refill and reservoir semantics of EIP-8037 are under review, Hoodi is unscheduled and mainnet has no date, which means that Wildcat Labs just paid six figures to get Wildcat V2.5 into external audit against gas semantics that may change before it ships. The cost - and the apparent lesson - of being an early, careful team on Ethereum is that you run the risk of needing to audit twice: once against the chain you deploy to, and once against the chain it becomes. --- WHAT WE ARE DOING ABOUT THIS: Upcoming SDK and frontend releases will, defensively and until we can safely revert to type, split market creation into two transactions and send safeTxGas 0 on the Safe App route. Existing markets will keep running. Lenders will be affected in cost only: first touches (first deposit, opening a withdrawal request, first approval) about 2-3x, everything else 1.1-1.6x. What we cannot do is make a 65M transaction fit in a 60M block. That part is on you lot, the social layer. Further to the above, Wildcat Labs will happily send an invoice for an audit rebate to anyone willing to provide it if we end up having to re-check things for V2.5 once semantics are finalised. Mind you, we'd provide an EOA, as we're a bit wary of anything contract-based right now. Enjoy your Sundays.