Tracking the Glamsterdam discussion
Tldr:
- We recommend no decision on Glamsterdam until clarity is achieved, and detail the steps we are taking towards achieving clarity in this post.
- Ethlabs has been actively monitoring, triaging and analysing reports (formal or informal, eg, posted on X) regarding possible impacts of EIP-8037/8038 on deployed smart contracts, for more than 2 weeks. We thank all developers for their time.
- External audits were commissioned by the Ethereum Foundation (EF). These audits are expected to lead to more public discussion next week regarding their findings. The steps of this discussion are detailed below.
- Call-to-actions:
- Run the EF-provided self-check tool for application developers.
- Reach out publicly or privately to glamsterdam@ethereum.org to disclose possible issues with EIP-8037 and EIP-8038.
- Join an AMA hosted during ACD Testing on Monday, November 16th.
Glamsterdam is a powerful upgrade that has recently come under some scrutiny. We believe this type of engagement is essential in shipping a decentralised network, and wanted to provide some of our views. In our view, the onus remains on protocol developers to convince application developers of the safety of the upgrade.
To situate, Glamsterdam intends to ship a package of upgrades allowing the network to scale significantly: move from 60M gas limit per block to 200M gas, i.e., 3.33x scaling.
- For users, that means more room in each block, less congestion when the network is busy and lower fees during demand spikes.
- For developers, it means room to build more directly on Ethereum mainnet, with apps that were too costly to run onchain becoming possible.
To do this safely, some operations need to be repriced to match their real cost to the network. That is one part builders have raised questions about, and what the audits are now checking. In particular, repricing basic operations executed by all nodes of the network is necessary to achieve this scale. Contracts relying on the absolute value of these operation prices are affected.
The scaling benefits of Glamsterdam do not come for free, but should not come at any cost either. In this case, we’ve seen three types of impacts:
- Repricing changes the economics of gas, making some resources such as state relatively more expensive, vs others such as compute. This is mitigated by the increased total gas available, from 60M to 200M, but remains an impact.
- Contracts or tooling with hard-coded assumptions about the fixed cost (in gas) of operations are impacted.
- Finally, gas accounting updates have raised unexpected behaviour from some deployed contracts. This accounting is a mechanism change, and is separate from a parameter update.
Note that none of these are currently exploitable, and only relate to the possible deployment of Glamsterdam according to its current specifications.
Security remains our first concern for shipping Ethereum upgrades. We’re engaged and will continue to engage in both internal and external consultations to clarify the decisions that are to be made and contribute.
This post clarifies both the data that was received until now, the data that will be received from now on, and the timeline that leads to eventual decisions.
There is time for the community to come together and discuss extensively the results that will be received, and we hope this post helps to clarify the current state of this discussion.
#What happened so far
- February 18th: Design of 8037 solidified in Repricings breakout #2.
- June 5th: Chain Security post on ethereum-magicians. Warn that an attacker can force an inner call to run out of gas, and the try/catch path still has enough gas to finish its state changes, because most of the cost of a new storage slot now comes from the reservoir.
- June 18th: ACDE introduction of two changes, unrelated to the June 5th disclosure: state-gas refunds go back first to the call's remaining gas, then to the reservoir, and Create is now charged unconditionally with a refill at the end of execution. Both were merged that day for devnet-6. In hindsight, returning that gas to the caller is what lets
gasleft()go up after a reverted call. - October 13th: Chain Security blog post “When Spent Gas Comes Back”. Under 8037/8038 as specified at that date, state gas spent before a revert can be refunded, so
gasleft()can go up. That breaks out-of-gas detection in general, not just try/catch. - October 21st: pcaversaccio raises issue to ACD.
- October 22nd: Hoodi fork set for Oct. 26th is cancelled indefinitely.
- Start of review process.
- Internal audit (using autoresearch, read more here) including EF, Ethlabs, core developers and auditors, evaluating invariants and transactions against contracts from the Sourcify database.
- Two external audits commissioned, from Chain Security and Dedaub. Publication expected by Monday, November 16th.
- EF-released invariants repo for app devs self-check.
- Tracking public reports, thanks to Banteg, functi0nzer0, Atis Elsts, me_jango and others—keep them coming!
#The decision to make, eventually
Ultimately, the decision to make is: Are spec changes required or not? If not, when should we move forward with Hoodi?
- The decision rests with All Core Devs (ACD), and we are only providing a view into the ACD calendar here to frame the timeline.
- Our recommendation: Do not proceed with spec changes or Hoodi scheduling until publication of findings and until findings lead to a clear position.
- Forthcoming ACD sessions:
- November 12th: ACDConsensus not planned to discuss the topic, expected to provide a minimal update referring to future ACDs for discussion.
- November 16th: ACDTesting featuring an open AMA between application developers, core devs, EF, Ethlabs and auditors.
- November 19th: ACDExecution likely to opine on findings, including possible decision to proceed with specification changes, i.e., to not proceed with the fork as-is.
#Our current perspective on findings
We consider the distinction between “simple” repricings vs accounting changes.
It is expected that simple repricings break contracts that have hard-coded parameters. These parameters meter the work that a node must perform to execute some operation. Scaling is achieved by repricing these parameters, e.g., increasing the cost of certain operations, so that different operations that are not interfering can be more plentiful. Coupled with a gas limit increase, the net effect is mixed, e.g., state creation becomes relatively more expensive, but compute becomes much less so. In aggregate, this allows nodes to schedule more work than they otherwise would, because they are guaranteed to not overschedule work in some dimensions, e.g., create new state. This obtains scaling.
In our view, there is no other way around these simple repricings, and they are legitimate to do as application developers were broadly expected not to condition on the fixed cost of these operations in order to derive their contract execution. This does not mean that the impacts we’ve seen so far are small, and we’ve also seen appropriate mitigations discussed with teams facing this issue. We note that some dispute the legitimacy of simple repricings, and we expect this conversation to take place.
On the other hand, beyond these simple repricings, accounting changes were also proposed as part of Glamsterdam. Some of these changes led to genuine, unforeseen problems. The task is to understand the magnitude of these issues.
We’re grateful for all reports and perspectives, and we are logging everything we see on X or disclosed to us to support the effort. If the findings reveal unacceptable magnitude of the issue, Ethlabs is prepared to consider spec changes or stronger proposals, such as significantly reviewing the scope of Glamsterdam.
There will be time to ensure that any decision is made with conviction. For the time being, we remain focused on collecting and analysing all the data produced by our internal work, external collaborations, and reports from the community. We plan to share our opinion on the matter of next steps for Glamsterdam as soon as we internally reach a high threshold of confidence.