A Lodestar for Consensus 2024

2024 brought a lot of updates and reflections as we continue to support the development of the Ethereum protocol through our TypeScript consensus client. Let's reflect and plan for our journey ahead in 2025.

A year for performance gains

One of our main goals in 2024 was to ensure that our client implementation performs at similar levels as other consensus clients. Client diversity is essential for network health when considering the unlikely event of client bugs leading to non-finality. However, performance regression is not a sacrifice most validators would accept for the health of the network. It's important that we demonstrate the trivial differences (if any) when using Lodestar as an alternative consensus client.

Attestation performance

Attestations are the most frequent duties expected when running an Ethereum validator. When evaluating performance, we want to guarantee we aren't missing attestations by being timely and accurate about the blockchain's state.

Utilizing a script developed by Lodestar engineer Nico, his debug attestations repository helps us analyze the performance of our validators within the last 100 epochs. In earlier versions of Lodestar, we had a higher tendency of missing attestations, especially when there was a preceding missed block.

In June of 2023, we evaluated a sample of ChainSafe's Lido validators using Lodestar v1.8.0 with the following results:

And then, in July of 2024, we evaluated a sample of ChainSafe's validators using Lodestar v1.19.0 with the following results:

Using Total Attestations as a baseline, we're able to evaluate how Lodestar's sample size performs in relation to validator effectiveness. Recent tests show similar improvements with v1.23.0.

State regeneration and N-Historical states

One of the notable improvements made this year allows Lodestar to regenerate historical states. Lodestar previously persisted finalized states very sparsely. Some of our users required this information for some of their use cases, including those utilizing the light client protocol to verify block headers. In addition, this allowed us to regenerate from checkpoint states and helped with synchronization to the head of the blockchain.

This upgrade opens up improvements such as n-historical states, allowing Lodestar a higher tolerance for dealing with unstable network conditions with long periods of unfinality. We had to handle state management in a memory-efficient way to ensure it didn't create negative ripple effects in other performance metrics due to garbage collection duties. These types of incremental upgrades help unlock other demands that require us to improve our network performance.

Increasing peers by default

Having good network peers ensures the best connectivity for important tasks like validator attestations. In the future, it will become even more critical with features like PeerDAS, where there is a need to connect to a large set of peers with diverse data custodies for availability sampling.

Previously, Lodestar would struggle as peers increased due to the additional overhead of information from a larger set of peers. With our performance improvements, we've ensured that we can handle higher peer counts by default from 50 to 100 without significant performance degradation as we scale the network.

Improvements in the usage of native bindings

A new method of experimentation in 2024, which led to great results, includes our implementation of native Rust bindings to Lodestar via the Node API. As a few examples, utilizing NAPI-rs, we saw improvements from leveraging Rust code in BLST, the pubkey-index map and shuffling computation for multithreading. Our process was to identify what resource-intensive tasks we could do better with native code. We then utilized lower-level languages like Rust in Lodestar to achieve benefits similar to the native implementation. These experiments generally showed promising results better than some artificial multithreading via worker threads on our current NodeJS runtime.

User/developer experience improvements

One of our other main goals in 2024 was to improve the experience of using and developing Lodestar. Some of our goals here were to help with the key goal of increasing adoption and demonstrating that Lodestar is a capable, production-grade consensus client on mainnet. According to various sources on clientdiversity.org, Lodestar can be seen on mainnet up to 2.67% of validators, potentially double what we saw last year. In addition, ProbeLabs crawls the Discv5 distributed hash table for seen beacon nodes on the network by tracking UserAgent identifiers from their peers. In the latest reports, approximately 2.3% of beacon nodes on Ethereum mainnet may run Lodestar.

Docusaurus docs update

You may have noticed some visual and contextual differences with our documentation this year as we migrated from MKdocs to Docusaurus. We've reorganized information and made finding what you're looking for in our docs easier. We're still improving the docs, adding more details as we continue to learn what's important to our users.

We appreciate your feedback on improving the documents, and you can easily contribute by following our contribution guidelines.

Binaries and script

We've made strides to ensure we can support as many methods of running Lodestar as possible. By publishing both amd64 and arm64 binaries, we've streamlined the process required to get Lodestar running on your bare metal machine.

Since v1.19, users have been able to unpack and run the Lodestar binary, which now gets published in every release. In addition, there is now a binary installation script that allows you to instantly download, unpack, and configure Lodestar for use, all within one command line. We're also continuing to maintain the Lodestar Quickstart scripts, which allow you to bootstrap Lodestar with an execution client as Docker images with minimal configuration on new networks.

Providing first class SSZ support on beacon APIs

We made an effort to support SSZ as first-class encoding for sending and receiving data on the majority of our routes. This push introduces performance improvements, with SSZ being the more efficient standard than JSON, alongside friendlier handling of requests between the server and client. If you're running a beacon node and validator with Lodestar, you can also benefit from faster API connectivity by transmitting SSZ instead of JSON utilizing --http.requestWireFormat ssz on your Lodestar validator client.

What's in store for 2025?

Lodestar has always focused on how we can impact the Ethereum protocol ecosystem. There are generally two streams which we support when thinking about how we provide for our users and our community:

• Internal Objectives: These are goals which are specific within our consensus client implementation, such as performance improvements and testing infrastructure
• External Objectives: These are goals we support with the collaboration of the larger Ethereum community as a whole, such as research and ecosystem support

Mission

Collaborate in Ethereum consensus R&D through rapid prototyping and accelerated implementation.

We believe we can provide value to the Ethereum protocol ecosystem by delivering Ethereum faster and better. By increasing our contributions within research and implementation, we can leverage a synergy that can efficiently, accessibly and effectively deliver results on protocol experimentation.

Rethink the Lodestar Toolchain

One of our major objectives in 2025 is to consider where we can provide more value to users of a consensus client. Most of the feedback we received related to why there is hesitation in adopting a minority client, which relates to performance benefits.

Lodestar was built with JavaScript dev tooling in mind to support the initial vision of the beacon chain in 2018, and its relationship with the JSON RPC for the Serenity phased upgrade of Ethereum 2.0. As the specification evolved past Phase 1.5 and having a better understanding of the consensus-execution relationship, the focus shifted away from dev tooling and light client browser-compatible tooling, where JavaScript would have excelled at with the original vision.

For Lodestar to be competitive in the future, we must accept that lower-level programming languages excel at the current and potential roadmap of the Ethereum consensus protocol. The limitations we experience working within a single-threaded, event-driven environment pose issues that require objective revision and re-alignment. Direct control, deterministic performance, and long-term scalability are what we need to support the increasing complexity of Ethereum's consensus in the future.

To understand what makes the most sense for Lodestar, we should embrace the discovery of lower-level programming languages and use empirical evidence from our experiments in 2025 to gauge where to put our efforts in solidifying Lodestar's future. However, one fundamental requirement is supporting WebAssembly so that it can easily be implemented across different runtimes. We aim to have internal objectives where we can utilize native code for resource-intensive operations and have it benefit Lodestar's main codebase.

Bun and Deno runtime experiments

We plan to explore new runtimes and understand the potential upsides of other JavaScript runtimes and engines, such as Deno (JavaScript V8) and Bun (JavaScriptCore). Initial experiments have shown that Bun could potentially lead to 2-3x improvements in components that are heavily dependent upon for critical tasks. Benchmarking these differences will be a key data point we will collect as we continue testing these critical tasks such as hash trees, array iterations and serialization. Bun covers most of the native abstractions for NodeJS, but we'll keep working towards compatibility to benefit from its performance improvements.

Systems level language integrations

The team has explored and is looking quite optimistically at utilizing Zig as a preferred systems language to leverage over others. Rust has plenty of ecosystem support, and we wish to ensure easy compilation for WebAssembly. However, Zig may allow us to benefit from memory efficiency and performance optimizations, interoperate with RISC-V, and benefit from native C libraries. There will be a thorough analysis of how we can further benefit Lodestar and the Ethereum ecosystem with Zig as a potential path forward while maintaining our commitment to supporting the TypeScript ecosystem in the near future.

External objectives

Part of the value we provide to the community is participating in goals that support the development of Ethereum alongside other client teams and researchers. We'll be aiming to lead initiatives we believe are important to us, including EIP-7805: Fork-choice enforced Inclusion Lists (FOCIL). Our other commitments include participating in and shipping objectives to deliver the Electra hard fork and hopefully Fulu shortly afterwards with the anticipated PeerDAS feature.

We also want to explore how we can improve Ethereum's hard fork turnaround cycles and increase the velocity of coordinated output from the wider protocol community with greater consensus assurance for EIP inclusions.

Lodestar has a bright future ahead if we take the steps now to define and work towards addressing internal problems facing a Typescript-based consensus client. We want to continue contributing to an Ethereum that generates incredible value for the world in a decentralized, global settlement layer. Together, as a community, we believe we can deliver better value for the users of Lodestar, its dependents, and the Ethereum community as a whole.

Lodestar

Lodestar is a consensus beacon node and validator client for the Ethereum blockchain. Lodestar's tools and libraries enable Ethereum protocol development for the JavaScript ecosystem.

Contribute to Lodestar! 🌟

At ChainSafe, we constantly seek exceptional talent to join our teams and welcome contributors to the Lodestar consensus client. To any TypeScript developers looking to take on challenges and push the boundaries of the JavaScript ecosystem, get in touch! To get involved, visit our GitHub repository.

If you wish to contact the team, join Chainsafe's Discord in the #lodestar-general channel. Alternatively, you can email us at info@chainsafe.io.

Lodestar is built and maintained by ChainSafe.

Website | Twitter | Install Lodestar | Start contributing