tl;dr: Meet Platåberget: Glamsterdam’s (Gloas + Amsterdam) early testing ground open to public participation. This upgrade comes with breaking changes for application developers. Notably, any tool that relies on a hardcapped maximum gas limit (think wallets, indexers and gas estimators) will break and needs to be updated. Please use this early opportunity to test!
Platåberget is a short-term testnet aimed for testing changes by the community. Unlike the short-lived devnets before it, Platåberget is intended to run for a few months, giving the community a stable place to experiment with post-Glamsterdam Ethereum, and an opportunity to test and break things before Glamsterdam goes live on Ethereum’s longer-lived testnets, Sepolia and Hoodi.
What’s in the Glamsterdam fork
The Glamsterdam upgrade brings significant changes to both the consensus and execution layers. Highlights include:
- Enshrined Proposer-Builder Separation: a major change to how blocks are built, proposed and validated, including a new builder API flow and PTC (payload-timeliness) checks. Infrastructure which depends on the block production and validation pipeline should expect to be affected.
- Block-Level Access Lists: introduces enforced block-level access lists that record accessed state locations and post-transaction changes. BALs are stored separately from the block body and can be exchanged between execution-layer peers through eth/71.
- Gas repricings: a coordinated bundle of gas cost changes aimed at a ~200M gas floor. Any tooling that hardcodes a maximum gas limit will be affected.
- Larger contracts and initcode: increases the maximum deployed contract size from 24KiB to 64KiB and the maximum initcode size from 48KiB to 128KiB.
- Forward-compatible consensus data structures
Platåberget has a relatively small but publically joinable validator set. This allows anyone to deposit a new
validator and test out their validator and builder deposit workflows. ePBS is a major change to the consensus
layer and we want to ensure that all the solo stakers, DVT projects, custom software and large scale operators have
ample chances to test their infrastructure. The Glamsterdam fork on the testnet is scheduled for 20th August, allowing ample time to make deposits and prepare for the fork transition.
Another major change in Glamsterdam is the gas repricings. These changes will affect a far larger group, since they touch every wallet, indexer, and gas estimator on the network. Please use this opportunity to understand what tooling or assumptions break in your system before the fork goes live in Mainnet.
The full list of included EIPs is tracked in the Glamsterdam meta EIP-7773.
Using Platåberget
Check out the Platåberget resources page for a summary of the included EIPs, client support and launch status, and the devnet-8 specification for network settings, config values, bootnodes and client release information.
The Platåberget page offers a one-click Add Network flow
to configure your EL and CL clients, and a faucet provides testnet ETH to cover deposits and gas.
A few things to keep in mind when running a node:
- The public will be able to submit validator or builder deposits via the Dora explorer
- Rather than pre-allocating automatic stake to a handful of entities, the genesis validator set will be bootstrapped from public deposits, with some ETH allocated at genesis to help get things started.
- Client releases: releases for each client are optional, please check your client of choice if they have
included it
Client images
For the time being, use our ethPandaOps container images below while client teams prepare tagged releases.
Consensus Layer
lighthouse: ethpandaops/lighthouse:glamsterdam-devnet-8 lodestar: ethpandaops/lodestar:unstable nimbus: ethpandaops/nimbus-eth2:unstable prysm: ethpandaops/prysm-beacon-chain:glamsterdam-devnet-8 prysm_validator: ethpandaops/prysm-validator:glamsterdam-devnet-8 teku: ethpandaops/teku:glamsterdam-devnet-8 grandine: ethpandaops/grandine:glamsterdam-devnet-8
Execution Layer
besu: ethpandaops/besu:glamsterdam-devnet-8 geth: ethpandaops/geth:glamsterdam-devnet-8 erigon: ethpandaops/erigon:glamsterdam-devnet-8 nethermind: ethpandaops/nethermind:glamsterdam-devnet-8 reth: ethpandaops/reth:glamsterdam-devnet-8 nimbusel: ethpandaops/nimbus-eth1:glamsterdam-devnet-8 ethrex: ethpandaops/ethrex:glamsterdam-devnet-8
Support & Feedback
If you identify bugs or issues with the specification, the best place to raise these is in the Ethereum R&D Discord server. If you’d rather not use Discord, other venues to raise such issues are the specification repositories: consensus, execution, execution-apis, builder-specs and beacon-APIs.
Next Steps
Platåberget gives the community an opportunity to experiment with post-Glamsterdam Ethereum and begin identifying issues.
The gas repricing is especially important for application developers: any tool that relies on a hardcapped maximum gas limit (think wallets, indexers and gas estimators) will break and needs to be updated. We’d love to see dApp and wallet developers testing against Platåberget alongside infra operators — this is the class of change most likely to catch downstream tooling off guard.
The repricing is not only about the block gas limit: individual operations change price too, and EIP-8037 introduces a separate state gas dimension for operations that create new state. Creating an account, deploying code or writing a fresh storage slot is now metered at a fixed cost per state byte (CPSB), charged at runtime rather than up front. The practical consequence is that a plain ETH transfer is no longer always flat 21,000 gas: transfers to an account that already exists still cost 21,000 (now decomposed into TX_BASE_COST + COLD_ACCOUNT_ACCESS + TX_VALUE_COST), but sending funds to an account that does not exist yet additionally incurs STATE_BYTES_PER_NEW_ACCOUNT × CPSB state gas at runtime. Anything that assumes 21,000 covers every transfer, or assumes a single gas dimension when estimating, needs revisiting — see EIP-2780 for the decomposed intrinsic cost and EIP-8038 for the state-access increases.
Once feedback has been incorporated into client software and the specifications, a non-finality devnet will follow within the month to test pathological consensus scenarios.
After these devnets have been stable for some time, the existing long-lived testnets (Sepolia, Hoodi) will run through the Glamsterdam fork. Once those have upgraded and are stable, next up is Ethereum mainnet’s transition to Glamsterdam 🎊.
For those eager to follow the progress at a more granular level, the best venues are the Ethereum R&D Discord server, the All Core Dev calls, the Glamsterdam upgrade tracker, or the EthPandaOps Glamsterdam devnets Github repo.
See you on Platåberget 🐻❄️!
Credit: Source link
