Typefully

Ethereum Upgrade: EIP-6110

Avatar

Share

 • 

A year ago

 • 

View on X

(1/18) @ethereum Upgrades: EIP-6110 Ethereum's Merge was incredible, but it left us with some glaring technical debt. EIP-6110 is a direct response to deprecate the complicated and brittle process of communicating deposits from the execution to consensus layer.
(2/18) Ethereum is the World Computer, a single, globally shared computing platform that exists in the space between a network of 1,000s of computers (nodes). These nodes are real computers in the real world, communicating directly from peer to peer. x.com/LogarithmicRex/status/1592309373732151296
(3/18) To understand the current state of Ethereum, you must understand how we got here. In particular, it's important to understand how the Merge not only switched Ethereum from Proof of Work to Proof of Stake, but defined the current architecture of the World Computer. x.com/LogarithmicRex/status/1861070198918545700
(4/18) Tl;dr: Ethereum merged its original (Proof of Work) blockchain with the new (Proof of Stake) Beacon Chain, forming today’s Ethereum. The original chain is now the execution layer (forming the EVM), and the Beacon Chain serves as the consensus layer (operating PoS).
(5/18) Under the hood, this is incredibly apparent - the easiest way to see the legacy of the Merge is to look at an Ethereum node. To be a full node, a computer most operate two pieces of software: an execution client and a consensus client. x.com/LogarithmicRex/status/1589807499804176384
(6/18) Sure, these two pieces of software are in near-constant communication, but the communication that exists today is indirect and inefficient. Instead of a direct channel, these two clients communicate via a JSON-RPC interface - the same interface used by external parties.
(7/18) To drive the point home: One of the legacies of the Merge is that despite the consensus and execution layer being managed within a single computer, they must communicate via the same method (and with the same overhead) as a party communicating from outside the node.
(8/18) While this isn't a fatal flaw, it creates some major headaches when developing even simple functionality that implicates both layers. Both in terms of implementation complexity and user experience. For example, let's look at validator deposits.
(9/18) Here's how things work today: A prospective validator sends 32 $ETH to the deposit contract on the execution layer. Every ~8 hours, the consensus layer checks the deposit contract. The consensus layer votes (off-chain, ~3 hours) and, if valid, deploys a new validator.
(10/18) Because the execution and consensus layer cannot communicate directly, we've had to build this workaround. The result: implementation is complicated/clunky and the user experience sucks (takes hours). The Merge was 2+ years ago - it's time to upgrade Ethereum.
(11/18) EIP-7685 provides a general purpose communication channel between the execution and consensus layer - but it doesn't add new functionality. However, when EIP-7685 ships (in the next upgrade/hard fork), it will be joined with other EIPs which do add functionality... x.com/LogarithmicRex/status/1863613708855107654
(12/18) ...like EIP-6110! EIP-6110 allows the execution layer to directly communicate validator deposits to the consensus layer. eips.ethereum.org/EIPS/eip-6110
(13/18) By moving from the (externally facing) JSON-RPC API to the (exclusively internal) Engine API, the entire process becomes simpler, quicker and easier to audit. The first benefit: we can collapse the validator deposit/creation process from ~11 hrs to ~13 mins.
(14/18) But, more importantly, EIP-6110 is about replacing a particularly complicated and brittle part of how Ethereum works. Less complicated is not just about better performance, it's also about simpler, cleaner and therefore safer code.
(15/18) And, perhaps even more importantly, EIP-6110 eliminates the off-chain voting step that is necessary in today's configuration. By recreating the functionality via EIP-7685, the process now fully inherits the full security of Ethereum.
(16/18) For reference, EIP-4881 is the specification used for the pre-EIP-6110 process. If you're feeling brave, take a look at just how complicated implementing validator deposits was. EIP-6110 cleans up the messy legacy left by the Merge. eips.ethereum.org/EIPS/eip-4881
(17/18) If you want to learn more about EIP-6110, I suggest watching @stefanbr93's presentation from Devcon 2024. As a bonus, you can also hear @lucascrsaldanha walk us through EIP-7002, another upgrade leveraging EIP-7685 youtube.com/watch?v=EyDChjFQEkQ
(18/18) In summary, EIP-6110 is one of many upgrades built on the new communication channel created by EIP-7685. EIP-6110 allows Ethereum's execution layer to directly communicate validator deposits to the execution layer, replacing today's clunky, inefficient method.
Avatar

Logarithmic Rex

@LogarithmicRex