The primary focus of these weeks was to deepen my understanding of Elixir and the intricacies of an Ethereum consensus client. Activities included completing the "Elixir in Action" book, reviewing articles related to Elixir and Erlang, and commencing the reading of Eth2Book by Ben Edgington.
The past weeks have been full of discoveries, diving deep into the intricate workings of the Erlang VM (BEAM). This journey was filled with excitement, learning, and revelations. Elixir, a functional programming language, is built atop the Erlang VM, just as Erlang is. Both, upon compilation, become bytecode interpretable by the VM.
Elixir's objective is to provide an abstraction layer over Erlang, a language known for its complexity and low-level programming. Elixir introduces syntactic sugar and enhancements over Erlang, making it simpler and quicker to deploy applications while retaining the characteristics of the Erlang VM.
Why Choose the Erlang VM?
Erlang and its VM were developed by Ericsson in 1986, thanks to its co-creators Joe Armstrong, Robert Virding, and Mike Williams. The principal intent behind Erlang's creation was to advance the development of telephony applications. This demanded a language equipped with particular properties:
The Erlang VM is distinguished from many modern programming languages. Rather than vying for hyperbolic labels like the "fastest" or the most "powerful," its mission is to offer predictable service for complex systems—systems designed for endless operation.
Many of these attributes make Elixir an apt choice for constructing a new consensus client, leading to our project: Lambda Consensus Client.
Ethereum has undergone significant evolution, morphing into the colossal protocol recognized today. It is intricate, sophisticated, and understanding its mechanisms demands time and patience, necessitating deep dives into its construction reasons and deciding which to replicate.
My recent research has been largely concentrated on the Engine API segment of the consensus layer.
The Engine API consists of methods implemented by execution clients, which are consumed by consensus clients to facilitate secure and efficient inter-client communication (EL <> CL) Engine API specs. This communication happens via the Engine API, using RPC methods authenticated by JWT tokens. These tokens must be generated with a 256-bit encoded secret created by the EL and provided to the CL during initialization. This ensures secure EL <> CL communication, preventing unauthorized interference.
This week, I successfully initiated a first PR that introduces an Elixir HTTP wrapper. This allows the use of internal functions to invoke Engine API methods for execution clients (tested Reth and Geth). We have established communication! Currently, I have integrated:
Future plans include secret import via the command line interface (currently hardcoded), comprehensive support for all engine_ methods, additional testing, improving understanding of inner workings.
Elixir
Ethereum
Engine API image taken from Ethereum.org