In-depth analysis of the new Starknet client Beerus: How to achieve trustless state verification?

Analyzing the new Starknet client Beerus: Trustless state verification.

Original: Charting the Stateless Future

Translation and proofreading: “StarkNet Chinese Community”

Overview

  • Beerus, as a stateless client of Starknet, is built on Ethereum’s Helios light client and requires no state information.
  • StarkNet’s cryptographic proof enables trustless state verification, a function Ethereum lacks.
  • Beerus verifies Ethereum STARK proofs through StarkNet’s storage proof and transforms untrusted data into trusted data.
  • Developers can join Beerus development and contribute to building a secure and decentralized StarkNet ecosystem.

The Ethereum state is a comprehensive record of all Ethereum accounts, recording information such as each account’s balance, deployed smart contracts, and related storage. As new accounts are added and new smart contracts are deployed, the Ethereum state will continue to grow indefinitely.

Despite various scaling solutions aimed at mitigating the impact of Ethereum state growth, the overall trend remains upward. The design characteristics described above lead to the endless growth of the Ethereum state scale, which can have various impacts. For network participants, it is essential to verify that all data on Ethereum is accurate, as operators and users need to be sure that they are interacting with valid information.

In 2017, the community first became aware of this problem and proposed the concept of a stateless Ethereum. Contrary to the literal meaning, “stateless” in Ethereum does not mean without state. As Ben Edginton puts it, “stateless” means delegating the responsibility of providing and storing the Ethereum state to another participant in the network. In short, stateless Ethereum clients choose the state they want to maintain.

Light clients and stateless clients

Although both light clients and stateless clients are dedicated to solving the problem of Ethereum state scaling without limit, the subtle difference between the two is that light clients require some Ethereum state-related information, while stateless clients like Beerus require no Ethereum state information.

Beerus is the stateless client of Starknet, built using the Ethereum light client Helios.

Starknet has integrated cryptographic proofs into its protocol, resulting in impressive performance for both light and stateless clients, as well as capabilities that Ethereum lacks. They not only allow network participants to verify consensus, but also to verify state validity without trust.

Future of Light Clients

Light and stateless clients have the potential to change the game rules in the blockchain industry.

  • New Infrastructure Paradigm: Due to their low resource requirements, light clients help make decentralized Web3 infrastructure more democratic, attracting more participants.
  • Trustless Cross-Chain: Today, most cross-chain transactions require a multisig wallet to transfer assets. Using light clients, trustless cross-chain protocols can be built without relying on centralized intermediaries.
  • More Secure Wallets: Most cryptocurrency wallets today need to communicate with centralized service providers to function properly. Using light clients, fully decentralized wallets can be built, giving users more asset control and security.
  • Better oracles, or no oracles needed: Using cryptographic proofs in combination with light clients to create a secure way to verify external data.
  • IoT: Light clients are very lightweight and can perfectly adapt to devices with limited processing power and memory, opening up new possibilities for the IoT.
  • Light Clients as Smart Contracts: Deploying a light client from another chain as a smart contract, users can make decisions based on the status of another chain while also gaining higher security.

How Light Clients Work

The simplified process of how light clients work:

  1. Light clients download Ethereum block headers, which include the Merkle tree root for each block.
  2. Light clients use these block headers to verify the validity of Ethereum consensus without downloading the full content of each block. (In Starknet, cryptographic proofs are built into the protocol, allowing light clients to verify the validity of both state and consensus.)
  3. When a user wants to transact or interact with a smart contract, the light client sends a request to the full node. The full node then feedbacks the information needed to complete the transaction.
  4. The light client uses the downloaded block headers to ensure that the information feedbacked by the full node is valid.
  5. After the transaction is completed, the light client downloads the block headers that have been added to the network to update the blockchain replica.

Get Root Hash

In Ethereum, each block includes a Merkle tree of all the transactions in that 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 is included in the block header of each block. This root hash represents the entire state of the blockchain up to the latest block.

Ethereum light clients require this root hash value in order to verify the authenticity and state of the latest block on the blockchain. By verifying the Merkle tree root hash, a light client can ensure that the latest block has not been maliciously tampered with.

There are two ways for a light client to obtain the root hash: rely on a full node or sync with a committee.

Full Node Verification

A light client relies on a full node to obtain the latest block with the root hash value. The full node tracks all the signatures of the latest block and verifies them. However, this resource-intensive method requires a light client to rely on a centralized authority to obtain the latest block, which goes against the purpose of running a light client.

Sync with Committee

In the Ethereum consensus layer, a sync committee is a randomly selected group of 512 validators. A new committee is selected every 256 epochs (approximately 27 hours). The committee is responsible for signing the block header of each new slot. If over two-thirds of the sync committee approves the state, a light client can assume that the state is correct.

The sync committee and light clients simplify the verification process. A light client only needs to know the previously verified block headers, and has information about the previous, current, and next sync committee members to verify the Ethereum state. This way, a light client can verify the accuracy of the verified blocks without accessing the entire set of validators or historical states. This method greatly reduces the computational power required to verify block headers.

Weak Subjectivity Checkpoints

To find the current sync committee, a light client needs to obtain a weak subjectivity checkpoint. A weak subjectivity checkpoint is similar to a genesis block, but it does not reside at the genesis position of the blockchain. It simply represents a block that the entire network agrees on, as a permanent part of the canonical chain.

A weak subjectivity checkpoint differs from the concept of a finalized block. When a node encounters two conflicting finalized blocks, a consensus failure occurs, and the node cannot decide on the canonical fork. However, if a node encounters a block that conflicts with a weak subjectivity checkpoint, it immediately rejects it. The most recent weak subjectivity checkpoint serves as the new genesis block of the network in terms of fork selection for a node.

Helios

Helios is an Ethereum light client based on Rust developed by a16z. It can sync in two seconds and requires very little storage, fully guaranteeing access to Ethereum without trust. Helios does not require running a full node and can verify the authenticity of Ethereum state with centralized RPC providers. Helios is easy to use and users can securely access on-chain data from any device.

Unlike most other Ethereum clients, Helios tightly integrates the execution layer and consensus layer. This means that Helios users only need to install and run one software.

Beerus

Beerus is inspired by Helios and uses Helios’s Starknet stateless client. Its 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 component is very important and handles all the tedious operations. By running Beerus Core, it communicates with two untrusted RPC sources, the execution layer of the Helios light client and the Starknet full node, to gain access to all Ethereum endpoints. This is where the magic happens, as Beerus transforms this untrusted data into trusted data.

How Beerus Works

Let’s take querying the storage value of a Starknet contract as an example to outline how Beerus works:

  1. Beerus synchronizes with Helios, which in turn synchronizes with the synchronization committee through a weak subjective checkpoint that ensures the reliability of the root hash values received by Helios.
  2. Next, query Starknet to check if the given contract storage key exists.
  3. Then receive the most recently verified block storage proof from the Starknet full node. This storage proof verifies the existence of the stored contract in the most recently verified block.
  4. Beerus Core then continues to request the Starknet state root from Helios, obtaining and verifying the STARK proof published on Ethereum.
  5. Compare the proof received from Ethereum with the storage proof received from the Starknet full node. If the proofs match, it can be confirmed that the data has been verified on Ethereum and is therefore accurate.
  6. Finally, the verified data is returned to the user in a trustless manner.

Summary

Beerus is a Starknet’s stateless client built using Ethereum’s Helio light client, enabling trustless state verification. Light and stateless clients have the potential to decentralize Web3 infrastructure and unlock various use cases that were previously infeasible.

Beerus requires minimal state information and only needs to verify the storage proofs of Starknet based on STARK proofs published on Ethereum. This way, Beerus turns untrusted data into trusted data, and even enables resource-constrained devices to operate securely without relying on full nodes.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!

Share:

Was this article helpful?

93 out of 132 found this helpful

Discover more

Opinion

Web3 Legal Education | How can GameFi games that make money while playing stay away from the gambling red line?

Under the policy and regulatory environment in our country, blockchain game entrepreneurs, from a compliance perspect...

News

Exclusive Interview with Solv Co-founder Meng Yan DeFi and Public Chains Still Have Huge Development Potential, Perfecting Infrastructure is the Key to Mainstream Adoption

I have high expectations for the DeFi and public chain tracks. In particular, L2 and ZK have tremendous prospects at ...

Opinion

Q2 2023 Investment and Financing Report Total investment amount decreases quarter-on-quarter, with the United States taking the lead.

Venture capital in the field of encryption has not yet bottomed out. Although the number of transactions in the secon...

Opinion

Cryptocurrency Market Weekly Review (10.28-11.03) Cryptocurrency Market Outperforms US Stocks, Solana's Popularity Exceeds Expectations.

This week, BTC made a strong comeback and altcoins caught up. The hot topics revolve around BTC and SOL. Part of the ...

Finance

With no pre-mining and a fair launch, how did the FairERC20 protocol become so popular overnight?

FERC20 caused a huge response within the community just a few days after its launch, because its appearance allowed t...

Opinion

DeBank plans to launch Layer2, and the wool party has already taken action?

The opening of the DeBankChain testnet has also allowed the wool party to see the potential for wealth. However, in r...