Based articles
One of the main reasons we use blockchain is the lack of trust. This property promises to give us independent access to our values and data. For the most part, a blockchain like Ethereum delivers on this promise—our assets truly belong to us.
However, there are also factors that we went for for the sake of convenience. One of these things is the use of centralized RPC (Remote Command Invocation) servers. Users typically access Ethereum through centralized providers such as Alchemy. These companies run high-performance nodes on cloud servers so that others can easily access the chain data. When a wallet queries the balance of its tokens or checks whether a pending transaction was included in a block, it almost always does so through one of these centralized providers.
The problem with the current system is that users must trust providers and there is no way to verify that their requests are correct.
Introduced Helios, a developed lightweight Ethereum client based on Rust that provides completely trustless access to Ethereum. Helios - which uses the Ethereum light client protocol made possible by recent transition on proof of stake — converts data from an untrusted centralized RPC provider into verified secure local RPC. Helios works alongside centralized RPCs, allowing you to verify their authenticity without running a full node.
The trade-off between convenience and decentralization is a common pain point, but our client—which we've made available to the public for further development—syncs in about two seconds, requires no data storage, and allows users to access secure blockchain data from any device (including mobile phones and browser-based extensions). But what are the potential downsides of a centralized infrastructure? This article will explain how they can manifest themselves, show design solutions, and also provide some ideas for others to contribute to. code base.
Pitfalls of centralized infrastructure: theoretical creations in the “dark forest” of Ethereum
IN dark forest a (theoretical) creation is hidden. It does not hunt for its prey in the Ethereum mempool, but rather sets its traps, mimicking the centralized infrastructure we have come to rely on. Users who fall into this trap make no mistakes: They visit their favorite decentralized exchange, set a reasonable slippage price allowance, buy and sell tokens as usual... They do everything right, but still fall victim to a new kind of sandwich attack, a trap, carefully placed at the very entrance to the dark forest of Ethereum: RPC providers.
Before going into more detail, let's take a look at how trades work on decentralized exchanges. When users submit a swap transaction, they provide the smart contract with several parameters - which tokens need to be swapped, the amount of the swap, and most importantly, the minimum number of tokens the user must receive for the transaction to go through. The last parameter specifies that the swap must satisfy the “minimum yield”, or reversal. This parameter is often referred to as “tolerable slippage” because it effectively sets the maximum price change that can occur between the time a transaction is submitted to the mempool and the time it is included in a block. If this parameter is set too low, the user agrees to the possibility of receiving fewer tokens. This situation can also lead to a sandwich attack, where the attacker effectively sandwiches the bet between two malicious swaps. These swaps increase the spot price and force the user to trade at a less favorable price. The attacker then immediately sells to make a small profit.
As long as this minimum output parameter is set close to a fair value, you are protected from sandwich attacks. But what if your RPC provider doesn't provide an accurate price quote from the decentralized exchange smart contract? The user can then be tricked into signing a swap transaction with a lower minimum output parameter, and, even worse, sending the transaction directly to a malicious RPC provider. Instead of broadcasting this transaction to the public mempool, where dozens of bots compete to perform the sandwich attack, the provider can hide it and send a batch of attack transactions directly to Flashbots, securing a profit for themselves.
The main reason for this attack is to trust someone else to obtain information about the state of the blockchain. Experienced users have traditionally solved this problem by running their own Ethereum nodes—a labor- and resource-intensive undertaking that, at a minimum, requires an always-on machine, hundreds of gigabytes of memory, and about a day to sync from scratch. The process is certainly easier than before; groups like Ethereum on ARM, are working tirelessly to make it possible to run nodes on inexpensive hardware (such as a Raspberry Pi with an external hard drive connected to it). But even with these relatively minimal requirements, running a node is still difficult for most users, especially those using mobile devices.
It is important to note that attacks against centralized RPC providers, while plausible, are usually simple phishing attacks - and the incident we described has not yet occurred. While the track record of major providers like Alchemy gives us no reason to doubt them, it's worth doing more research before adding unfamiliar RPC providers to your wallet.
Introducing Helios: Completely Trustless Access to Ethereum
By introducing a light client protocol (made possible by the recent move to Proof of Stake), Ethereum has opened up exciting new possibilities for fast blockchain interaction and RPC endpoint verification with minimal hardware requirements. In the month since The Merge, we saw a new series of light clients appear independently of each other (Lodestar, Nimbus And Kevlar JavaScript-based) that used different approaches to achieve the same goal: efficient and reliable access without using a full node.
Our solution, Helios, is a lightweight Ethereum client that syncs in approximately two seconds, requires no data storage, and provides completely trustless access to Ethereum. Like all Ethereum clients, Helios consists of an execution layer and a consensus layer. Unlike most other clients, Helios tightly couples both layers so that users only need to install and run one piece of software. (Erigon is also moving in this direction by adding a lightweight consensus layer client built directly into their archive node).
So how does it work? The Helios consensus layer uses a previously known beacon chain blockchain and a connection with an untrusted RPC for verified synchronization with the current block. The Helios execution layer uses these authenticated beacon chain blocks in tandem with the untrusted execution layer RPC to validate arbitrary chain state information such as account balances, contract storage, transaction receipts, and the results of smart contract calls. These components work together to provide users with completely untrusted RPC, without the need to run a full node.
...At the level of consensus
Light client consensus level compliant specifics light client beacon chain and uses beacon chain synchronization committees (introduced before Merge in the Altair hard fork). The sync committee is a randomly selected number of 512 validators who work for ~27 hours.
When a validator enters the sync committee, it signs the header of every beacon chain block it sees. If more than two-thirds of the committee members sign the header of a given block, it is very likely that the block is in the canonical beacon chain. If Helios knows the composition of the current sync committee, it can confidently track down the head of the chain by asking the untrusted RPC for the latest sync committee signature.
Thanks to aggregation signatures BLS requires only one check to confirm a new block. If the signature is valid and has been signed by more than two-thirds of the committee, the block can be considered to have been included on the chain (of course, it can be re-formed from the chain, but tracking the completion of the block can provide stronger guarantees).
However, there is an obvious flaw in this strategy: how to find the current synchronization committee. This starts with gaining a source of trust called control point of weak subjectivity. Don't be intimidated by the name - it refers to an old blockchain that we can guarantee was included on the chain at some point in the past. There is some interesting math behind how old a reference point can be; worst-case analysis suggests about two weeks, while more precise estimates suggest many months.
If the reference point is too old, there are theoretical attacks, which can trick nodes into following the wrong chain. Acquiring a weak control point of subjectivity is beyond the scope of the protocol. The Helios approach provides an initial checkpoint hard-coded into the codebase (which can be easily undone); it then stores the last completed blockchain locally to use as a reference point in the future when the node is synchronized.
Conveniently, blocks of the beacon chain can be hashed to create a unique beacon blockhash. This means that you can easily query a node for a full beacon block, and then prove the validity of the block's contents by hashing and comparing it to a known blockhash. Helios uses this property to retrieve and validate certain fields within a weak subjectivity checkpoint block, including two very important fields: the current sync committee and the next sync committee. It is very important that this mechanism allows light clients to quickly view the history of the blockchain.
Now that we have a weak subjectivity checkpoint, we can get and check the current and next synchronization committees. If the current top of the chain is within the same sync committee period as the checkpoint, then we immediately begin validating new blocks with signed sync committee headers. If our checkpoint is several sync committees behind, we can:
1. Use the next sync committee after our checkpoint to receive and validate a block that occurs one sync committee in the future.
2. Using this new block, get a new next synchronization committee.
3. If you are still behind, go back to step 1.
Each iteration of this process allows us to fast forward 27 hours of chain history, start from any blockchain in the past, and synchronize with the current blockchain.
...At the execution level
The job of the runtime client is to take beacon block headers verified by the consensus layer and use them in conjunction with the untrusted RPC to the runtime to provide verified runtime data. This data can then be accessed through an RPC server hosted locally on Helios.
Here's a simple example of getting your account balance, starting with a quick overview of how information is stored in Ethereum. Each invoice contains several fields such as project code hash, nonce, storage hash, and balance. These accounts are kept in a large modified tree Merkle-Patricia, which is called a state tree. If we know the root of the state tree, we can use merkle proof to confirm the existence (or exclusion) of any account in the tree. These confirmations are virtually impossible to fake.
Helios has an authenticated state root from the consensus layer. Using this root and merkle proof requests to the untrusted runtime RPC, Helios can locally verify all data stored on Ethereum.
We use various techniques to validate all kinds of data used by the runtime layer; Together they allow us to verify the authenticity of all data received from an untrusted RPC. Although an untrusted RPC can deny access to data, it can no longer provide us with incorrect results.
Using Helios in the wild
The trade-off between portability and decentralization is a common pain point - but because Helios is so lightweight, users can access secure blockchain data from any device (including mobile phones and browser extensions). The ability to run Helios anywhere allows more people to access reliable Ethereum data regardless of their hardware. This means that users can use Helios as an RPC provider in MetaMask and access dapps securely without any other changes.
Additionally, Rust's support for WebAssembly allows application developers to easily embed Helios into Javascript applications (such as wallets and dapps). These integrations will make Ethereum more secure and reduce our need to trust a centralized infrastructure.
We are waiting to see what the team comes up with. In the meantime, there are plenty of ways to contribute to Helios—if you're not interested in contributing to the codebase, you can also create software integrated with Helios to take advantage of its benefits. These are just some of the ideas that can be implemented:
- Support for retrieving light client data directly from the P2P network rather than via RPC
- Implement some of the missing RPC methods
- Create a version of Helios that compiles to WebAssembly
- Helios integration directly into wallet software
- Create a web dashboard to view token balances that pulls data from Helios embedded in the website using WebAssembly
- Implement the API mechanism in such a way that the Helios consensus layer can be connected to an existing full node
To get started, check out code base — The team welcomes your bug reports, feature requests and code requests.
Contact the team: Twitter, Telegram or Farcaster @a16zcrypto.
Translation author harecrypta
VC | Telegram | Twitter | Youtube | VK | Website
