The Mekong devnet was meant to be a playground for wallet developers to experiment with UX changes and for stakers to gain confidence in the upcoming Pectra changes. The Pectra network upgrade has been activated on the Ethereum Sepolia and Holesky testnets. These networks can now be used to test the Pectra upgrade features. In light of this, we'd like to announce the deprecation of the Mekong testnet on 7th March, 2025. Application and tooling developers are encouraged to use Sepolia to test applications, smart contracts, and other EVM functionality. Its permissioned validator set provides a stable test environment. Alternatively, many local development environments allow for testing against copies of the Ethereum mainnet state. Stakers and infrastructure providers concerned with protocol-level testing are encouraged to wait for the Holesky testnet to finalize, or to await an announcement on the Ethereum R&D discord for an alternate testing location. For validator setup testing, stakers should also consider the Ephemery testnet. This network resets weekly and enables lightweight end-to-end testing of the validator lifecycle.
3/6/2025Introduction: shadowfork Theory: General info: A chain consists of an Execution layer(EL) and a Consensus layer(CL) The EL is responsible for state (transactions, history, etc) and the CL is responsible for consensus (agreement on chain head) at a high level The EL is driven by the CL. i.e, The CL decides what the head of the chain is and the EL must accept that decision (mostly) The CL asks the EL to produce blocks, these blocks are placed in the EL chain as well as execution_payloads in the CL slot. This links the CL slot to the EL chain (leaving out caveats here) When the CL sends the request to produce a block, it also sends information about the block to build on top of
3/5/2025Considerations Resource use: CPU, Disk, Cost, I/O Syncing and Sync complexity increase Complexity of Implimentation and Testing Time for conversion to take place Ideological Methods Overview
1/18/2024Thanks to Barnabé, Andrew, Sam and Marius for the review and discussions Introduction As the topic of Gas limit increase has surfaced recently, I thought I'd spend some time compiling thoughts from various places and try to enumerate a path forward to increase the limit safely. In its current form, Ethereum consists of 2 layers, the Execution Layer (EL) that is responsible for handling transactions, state, history, building blocks and the Consensus Layer (CL) that is responsible for consensus. The CL consensus engine is currently a combination of Casper the Friendly Finality Gadget (Casper FFG) and the LMD-GHOST fork choice algorithm. This consensus engine is strictly time dependent and introduces a concept of Slots and Epochs, there are tasks that need to be completed at certain periodic intervals by the validators. Two such tasks that we will consider are called Block proposals and Attestations. A block proposal specifies what the assigned validator thinks the canonical slot needs to be and the attestation specifies the vote of each validator for said proposed slot. Each interval (slot) is 12 seconds long and the specification says that the validator must attest as soon as they see a valid block or at the 4s mark into the slot. This introduces the concept of a deadline for the attestation task, i.e, under ideal conditions we'd want every validator on the network to attest to the canonical slot with a valid block before the 4s mark. On receiving information about the proposed block, the CL triggers a engineAPI call called forkchoiceUpdated(fcu). If the EL has all the data it requires, then it verifies the block and responds with VALID. Until this verification is complete, the CL cannot proceed with its duties, implying that the verification needs to ideally be complete within the 4s mark. There are a couple of variables at play with regards to this verification time: It depends on when the CL sends it the fcu, how big the block being verified is and if the EL already has all the data required for verification. A higher gas limit would be one factor that affects this verification time. The presence of Blobs also adds some complexity to this systems as a slot isn't valid until all the blobs proposed in it are fetched from the network and verified. The CLs do this in parallel, i.e once the block is received the fcu is issued, the block is then imported into forkchoice once the blobs have been deemed valid and available. The trigger for both tasks are handled by the CL, since they are done in parallel we would need to analyze which aspect takes the longest. If the blob fetch and verification takes longer, then the assumption is that on this one metric we can potentially afford to increase the EL gas limit. If the block verification takes longer, then on this one metric alone we can potentially increase the blob count. However, we do need to ensure that in any case the tasks are complete (ideally) in under 4s across the network.
1/18/2024