Charting the Stateless Future

A Deep Dive into Beerus, Starknet’s New Client

Tl;dr

• Beerus, a stateless client for Starknet, is built on Ethereum’s Helios light client, requiring no state information.
• Starknet’s cryptographic proofs enable trustless state verification, a feature absent in Ethereum.
• Beerus verifies Starknet storage proofs against Ethereum STARK proofs, converting untrusted data into trusted data.
• Developers can contribute to Beerus, contributing to a secure, decentralized Starknet ecosystem.

Ethereum’s state is a comprehensive record of all Ethereum accounts, their respective balances, deployed smart contracts, and associated storage. As new accounts are continuously created, and new smart contracts are deployed, the Ethereum state keeps expanding indefinitely.

While various solutions aim to mitigate the impact of this state growth, the overall trend remains upward. This design feature results in the unbounded growth of Ethereum’s state size, which has several implications. It’s crucial for network participants to be able to verify that everything on Ethereum is happening correctly, and as operators and users, we must ensure we’re interacting with valid information.

This issue was first recognized in 2017 and the concept of stateless Ethereum was introduced. Unlike its literal meaning, the term “stateless” in the context of Ethereum doesn’t imply the absence of state. As Ben Edginton puts it, it means that you have delegated the responsibility of provisioning and storing Ethereum’s state to another participant within the network. Put simply, a stateless Ethereum client chooses the state it wants to maintain.

Light Clients and Stateless Clients

While light clients and stateless clients both aim to tackle the problem of Ethereum’s growing state size, there is a subtle difference between the two: light clients need some information about Ethereum’s state, whereas stateless clients like Beerus don’t.

Beerus is a stateless client for Starknet built using the Helios light client for Ethereum.

Starknet’s integration of cryptographic proofs within its protocol is what enables light clients and stateless clients to shine, a feature not found in Ethereum. They enable network participants to trustlessly verify the validity of the state, not only the consensus.

Light Future

Light clients and stateless clients have the potential to be a game-changer in the world of blockchains.

• A new infrastructure paradigm: With low resource requirements, light clients could help to decentralize web3 infrastructure, making it more democratic and open to a broader range of participants.
• Trustless bridges: Currently, most cross-chain transactions require multi-sig wallets to facilitate the transfer of assets. By using light clients, it could be possible to create trustless bridges that do not rely on centralized intermediaries.
• Wallets with greater security: Currently, most cryptocurrency wallets require communication with centralized servers to function correctly. By using light clients, it will be possible to create wallets that operate entirely in a decentralized manner, providing users with more control and security over their assets.
• Better or no oracles: By combining light clients with cryptographic proofs, there could be a secure way to verify external data.
• IoT: Light clients are lightweight, which makes them a perfect fit for devices with restricted processing power and memory, consequently opening up new possibilities with IoT.
• Light clients as smart contracts: By implementing the light client protocol of another chain as a smart contract, you can make decisions based on the state of the other chain with stronger security guarantees.

The Way A Light Client Works

A simplification of the way light clients work:

1. The light client downloads Ethereum block headers, which contain the Merkle tree root for each block.
2. The light client uses these block headers to verify the validity of consensus in Ethereum, without having to download the full contents of each block. (In Starknet, where cryptographic proofs are built into the protocol, light clients can verify the validity of state and consensus.)
3. When a user wants to transact or interact with a smart contract, the light client sends a request to a full node. The full node then responds with the information needed to complete the transaction.
4. The light client uses the block headers it had downloaded to ensure that the information returned by the full node is valid.
5. Once the transaction is done, the light client updates its own copy of the blockchain by downloading any new block headers that have been added to the network.

Getting the Root Hash

In Ethereum, each block contains a Merkle tree of all the transactions included in the block. The Merkle tree is a data structure that allows for efficient verification of individual transactions without having to verify the entire block. The Merkle tree root hash is the cryptographic hash of the entire Merkle tree, and it is included in the block header of each block. This root hash represents the entire state of the blockchain up to the latest block.

An Ethereum light client needs this root hash to verify the authenticity and state of the latest block on the blockchain. By verifying the Merkle tree root hash, the light client can ensure that the latest block has not been tampered with or modified by a malicious actor.

There are two ways by which a light client can obtain the root hash: relying on a full node or a sync committee.

Full node verification

In this method, the light client relies on a full node to obtain the latest block with the root hash. The full node follows all signatures and verifies them up to the latest block. However, this method is resource-intensive and requires the light client to rely on a centralized authority to obtain the latest block, defeating the purpose of running a light client.

Sync committee

In Ethereum’s Consensus Layer, a sync committee is a randomly selected group of 512 validators. A new committee is chosen every 256 epochs (roughly 27 hours). This committee is responsible for signing block headers for each new slot. If more than 2/3rds of a sync committee agrees on the same state, the light client can trust it to be correct.

Sync committees work in conjunction with light clients to simplify the validation process. The light client only needs to know a previously validated block header, and have information about the previous, current and next sync committee members to authenticate Ethereum’s state. This way, the light client can verify the accuracy of validated blocks without needing to access the entire validator set or state history. This approach significantly reduces the computational power needed to validate a header.

Weak Subjectivity Checkpoint

To find the current sync committee, a light client needs to acquire the weak subjectivity checkpoint. A weak subjectivity checkpoint is akin to a genesis block, but it is located at a non-genesis position in the blockchain. It simply denotes a block that the entire network acknowledges as a permanent part of the canonical chain.

A weak subjectivity checkpoint is different from the concept of a “finalized” block. When a node encounters two conflicting finalized blocks, a consensus failure has occurred, and the node cannot determine a canonical fork. However, if a node encounters a block that conflicts with a weak subjectivity checkpoint, it will instantly reject it. In terms of nodes’ fork choice, the most recent weak subjectivity checkpoint serves as the network’s new genesis block.

Helios

Helios is a Rust-based Ethereum light client developed by a16z. It syncs in around two seconds, requires very little storage, and provides fully trustless access to Ethereum. Helios works with centralized RPC providers to verify their authenticity without running a full node. It is also easily embeddable and allows users to access secure chain data from any device.

Unlike most other Ethereum clients, Helios tightly couples the Execution Layer and the Consensus Layer. This way, Helios users only need to install and run a single piece of software.

Beerus

A Starknet Stateless Client inspired by and using Helios. The goal is to provide a simple and easy-to-use client to query Starknet state and interact with contracts using the aforementioned merkle proofs.

The Beerus Core is a crucial component that does all the heavy lifting. By running Beerus Core, you gain access to all Ethereum endpoints by communicating with two untrusted RPC sources — the Helios light client’s execution layer and the Starknet full node. This is where the magical part comes in: Beerus transforms this untrusted data into trusted data.

How Beerus Works

Let’s get an overview of how Beerus works by taking the example of querying a storage value of a Starknet contract:

1. Beerus synchronizes with Helios, which in turn synchronizes with the sync committee using a weak subjectivity checkpoint. This checkpoint ensures the reliability of the root hash that Helios receives.
2. Next, we query Starknet to check whether the storage key for the given contract is present.
3. A storage proof is then received from a Starknet full node at the last proven block. This storage proof verifies the existence of the storage contract at the last proven block.
4. Beerus Core proceeds to request the Starknet state root from Helios, which fetches and verifies the STARK proof posted on Ethereum.
5. The proof received from Ethereum is compared with the storage proof received from the Starknet full node. If the proofs match, we can confirm that the data has been validated on Ethereum and is therefore accurate.
6. Finally, the verified data is returned to the user in a trustless manner.

Conclusion

Beerus is a stateless client for Starknet, built using the Helio light client for Ethereum, that enables trustless state verification. Light clients and stateless clients have the potential to decentralize web3 infrastructure and unlock various use cases that weren’t possible earlier.

By eliminating the need for extensive state information, Beerus only needs to verify Starknet storage proofs against the STARK proofs posted on Ethereum. This way, Beerus converts untrusted data into trusted data, allowing even resource-constrained devices to operate securely without relying on a full node.

Getting Involved

Interested in contributing to the development of a secure and decentralized Starknet ecosystem? Beerus is a great place to start. Developers can get involved by contributing to the project on Github and joining the discussion on Telegram.