Altair & its Impact for Light Clients

# Altair & its Impact for Light Clients This article provides a (semi-technical) overview of the Ethereum Altair release and its relationship to light clients – resource-constrained devices that wish to participate in the Ethereum network. ## Introduction Altair is the second major consensus-related release toward the new Ethereum paradigm, often mislabeled as "Eth2.0," and is, perhaps, the most important Ethereum upgrade that occurred in 2021. It extends "Phase 0" (Dec. 2020), which brought the Beacon Chain: the primary PoS blockchain that will replace the existing PoW mining model with "virtual mining" (staking, validating, etc.) and will, eventually, enable greater scalability through sharding, among other things. While the PoS chain is currently just validating empty blocks, the impending "Merge" will fully replace the Ethereum PoW chain, making it a shard on the PoS Beacon Chain. So, if the Beacon Chain has already gone live(-ish), why is Altair so important? ## Background ### Light Clients Both a blessing and a curse, one of the greatest challenges with blockchains is determinism, which requires state to be shared, processed, and saved. Any machine running software that implements Ethereum ("node" or "client") must perform these actions in their entirety such that there's a high barrier-to-entry (hundreds of USD per month to run a full node). Put differently, if you want to use Ethereum, you need to store the global database with many gigabytes and high computing requirements to participate. In fact, "light clients" (e.g., phones, laptops, IoT devices) cannot handle this, thus, they cannot even participate in the network. For example, in the current-state Ethereum, let’s say a transaction is made on a phone (e.g., using the Metamask mobile app & Uniswap). What’s actually happening is that the app connects to a full Ethereum node, which is almost always via a centralized resource, like Infura or Alchemy. Without enabling light clients, Ethereum is only a semi-decentralized network in the sense that participating requires *centralized* connections to *underlying decentralized* software. Censor Infura or Alchemy, and not only does mobile access disappear but also the thousands of dApps that use these services instead of maintaining their own node. Altair implements the initial pieces needed for a light client to exist where a connection to a centralized resource is no longer needed – for a very specific operation subset; subsequent protocol developments will bring a much fuller suite of capabilities. Before understanding this initial light client feature set, it’s important to understand where Ethereum is headed. ### A Brief on Ethereum's Future Ethereum is a monolith that is being overhauled. Many changes will take place as it transitions to a "stateless" model; a simplified view is three primary functions: consensus, execution, and networking. Note that this is where the "Eth2.0" nomenclature is often inserted. Namely, there is no "second" Ethereum but, rather, a major redesign in the software that completely changes the existing model (hence, why it was initially labeled as such). It’s still the same protocol, but instead of a single piece of software that handles all components at once, the software will be optimized through separation of duties. Pieces of software will handle each responsibility and can then interact with each other, allowing the "full" client to exist. Consensus is brought by PoS and the Beacon Chain, which will go *fully* live by replacing the PoW chain upon the Merge. And with the PoW chain being eventually sunset (into its own shard), the remaining execution-related parts from the "original" Ethereum (i.e., EVM) will exist as the execution layer. In terms of networking, the [Portal Network](https://github.com/ethereum/portal-network-specs/) is in development and focuses on redesigning how data is gossiped around the network in a way where light clients can participate, which isn't (really) possible today. And lastly, statelessness as a whole is a vital concept toward a true light client. It touches all of these functions wherein state is no longer a hard requirement for every node. Instead, mathematical proofs called "witnesses" are provided with blocks, allowing a future light client to participate in the network in a much greater capacity (i.e., can't propose blocks since this requires access to full state, but could validate them). ## The Light Client ### Consensus Committees With PoS, validators are introduced to the network wherein votes are casted at specific intervals. To ensure validators cannot game the system, "random" selections (nothing is truly random in a deterministic world...but random enough to make it near impossible to game) occur where validators are divided into many *beacon chain* committees to vote on & propose blocks. Namely, validators vote on one slot (12 seconds) per epoch (32 slots aka ~6.4 mins.). This is the foundation of PoS consensus. Basically, validators within the committees are attesting to their view of correct the Beacon Chain; block proposers use this information to decide what to propose (e.g., the most votes) and broadcast this information to the network in hopes the block is included (for ensuing rewards). The concept of a committee is repurposed in Altair as a new type of committee – a "*sync"* committee. This is a different, single subset of validators that are serving a reduced dataset to light clients over a much longer "period" (256 epochs aka ~27 hours). ### Venturing into the Light Altair enables light clients to interact *at the consensus layer*. In the pre-Altair design, it would be impossible for any device to interact with the Ethereum protocol in a "light" (resource constrained) way. With Altair, the many gigabytes of state and computing power is no longer needed through the use of sync committees. A typical full client needs to continually stay up-to-date with changes happening in the network (layman's — if the database changes, you need to know changes occurred, otherwise, the data you currently have is rather useless). For the first time by way of sync committees, there is now a resource-constrained way to access part of the overall state in the form of block headers (e.g., the slot, who the block proposer was, encoded full block, etc.) as well as reducing the burden to sync state. In general, syncing requires a both time and computation power to get a node updated. Sync committees help expedite this process since a light client needs only to sync once per period (every ~27 hours) instead of at a slot (every 12 seconds). Thus, there is a significant reduction in both computing power and device storage required. ### What's Next? The consensus-focused light client lays the foundation for an open Ethereum wherein any device can participate without using any centralized resource. Altair brings the light client foundation, but the associated functionality it comes with isn't all that useful. Light clients can request for updated data (as block headers verified by the sync committee, plus some other data) — it's, basically, just a way to query for block data at different slots. There's not much else currently possible. However, as new features are released within the stateless Ethereum roadmap, there will eventually be a light client wherein the common person can use Ethereum in an entirely decentralized fashion. As an example, the redesigned execution layer will enable the next wave of functionality that allows a light client to make a transaction on a phone (e.g., using the Metamask mobile app & Uniswap) through a direct network connection rather than via a centralized resource. With these future releases, a truly decentralized world can exist. --- ### Sources - [The winding road to functional light clients](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/) - [Applying the "Five Why’s" to our client diversity problem](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08) - [Why it's so important to go stateless](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html) - [Altair -- Minimal Light Client](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/sync-protocol.md)