# Key Concepts

We'll now run through a brief summary of the various core theoretical components that define Eth2 as a novel and unique system. This section acts somewhat like an introduction and overview of the remaining chapters of this text. Certain topics, such as Eth2's networking layer, are given their own chapters but not discussed here as they form less of Eth2's identity. We try to remain relatively brief in these summaries given that significantly more detailed explorations are to follow. We've attempted to provide readers of this section with a bird's-eye view of Eth2 so that one can more easily understand individual components as parts of a whole.

# Proof-of-Stake

Eth2 moves away from Proof-of-Work consensus mechanisms and instead introduces a "Proof-of-Stake" protocol. At a high level, Proof-of-Stake mechanisms judge the relative "voting power" of each participant not by their ability to expend physical resources, but by their ownership of digital tokens. Token balances of consensus participants are tracked within the blockchain itself. This class of constructions differs fundamentally from Proof-of-Work systems in that active participants are explicitly identified as such. This is not to say, however, that users are unable to enter or exit the set of consensus participants. Many Proof-of-Stake designs support movement of this sort given that users meet certain requirement, perhaps a minimum token deposit to act as the user's "stake."

The addition of an internal list of participants gives Proof-of-Stake some interesting advantages over Proof-of-Work. Most obvious is the elimination of resource waste central to Proof-of-Work mechanisms. A minimized carbon footprint is clearly desirable in the context of modern events. Explicit balances also give protocol designers the ability to carefully construct rewards and, crucially, penalties for certain behaviors. The power to penalize malicious activity makes it possible for Proof-of-Stake mechanisms to significantly increase the cost of an attack and as a result reduce the cost to adequately secure the system. Lower barriers to entry that naturally stem from the elimination of expensive and short-lived mining hardware only further boosts participation and security.

Token balances carry additional secondary benefits for Proof-of-Stake. One such benefit of great value is the newfound relevance of traditional BFT systems research. Much of the divide between early blockchain protocols and more established BFT mechanisms can be attributed to the desire to remove lists of participants. By including this feature without sacrificing user mobility, Proof-of-Stake systems can reap most of the benefits of newer and older designs. Research carried out in the realm of BFT consensus can now be more directly applied to the Ethereum ecosystem. Crucially, proofs of correctness established more than three decades ago carry over to Eth2 with little additional effort.

Like any significant change, Proof-of-Stake brings with it new territory, some familiar and some not. Core principles discussed in our examination of BFT mechanisms essentially underpin Proof-of-Stake. However, we must also introduce new concepts in order to adapt these earlier principles to a blockchain setting. Terminology is introduced or modified as to better reflect the functionality of Proof-of-Stake. Consensus participant activity differs from that in Proof-of-Work, though its final purpose remains relatively the same at the outset. Even so, Proof-of-Stake shares many more similarities than differences with the various consensus mechanisms discussed thus far.

# The Beacon Chain

Eth2 takes a large step away from its colleagues with regard to the structure of the blockchain itself. Whereas most blockchain systems execute consensus logic and application logic within the same blocks. Eth2 splits these responsibilities across different chains. Any activity relating to the Eth2 consensus process is carried out on the so-called "beacon chain." Some researchers describe this chain as Eth2's "system chain," a space dedicated entirely to ensuring the proper operation of all other activities in the network. The beacon chain gives Eth2 a cleaner separation between the very distinct functionality required by the consensus process and the applications that process supports.

It's difficult to provide analogies for this design in other blockchain systems, primarily because no major blockchain has yet to make a similar separation. We can partly ascribe this fact to the ubiquity of Proof-of-Work. Without the need to maintain a list of active consensus participants, Proof-of-Work is only required to attach a minimal amount of consensus-related information to each block. Most of this information consists of the actual "proof of work" that validates a block along with an identifier for the block's creator. Proof-of-Stake, on the other hand, carries out significantly more consensus-level logic within the blockchain itself. For instance, Eth2 must keep track of users who wish to enter or exit the consensus process. Given this abundance of on-chain activity, it's simply easier to handle consensus in a separate space.

# Shard Chains

The beacon chain manages consensus logic and "shard chains," sometimes called "shards," manage application logic. Eth2 is one of the first blockchain systems to dedicate not one but many different functionally-identical chains to applications. Each shard chain is, in some respects, analogous in purpose to the current Eth1 chain. Users deploy and interact with applications on these shard chains. Shards act independently of one another and, as a result, vastly expand total transaction throughput in comparison to Eth1. Through some clever mathematical tricks, Eth2 can guarantee the validity of all shards without requiring consensus participants to execute every transaction. In effect this "sharded" system opens the door to highly scalable blockchain constructions without a corresponding shift towards centralization.

Sharding provides users with additional benefits over other scalability approaches. Users of a single shard chain can ascertain the validity of their shard without downloading or processing any other shard. Therefore, even though total system throughput has greatly increased, user storage and processing requirements are mostly fixed. Individuals or applications can even interact with those on other shards via "cross-shard transactions." These special transactions are made possible by a continuous process of "cross-linking," in which shards data is regularly inserted into the beacon chain in the form of a cryptographic commitment. Though they introduce many improvements and possibilities, shard chains are fundamentally akin the primary chain of most modern blockchains.

# Ewasm

Revamped application chains in Eth2 are accompanied by a new and improved model for executing application logic. Eth1's EVM was designed at a point in time when few adequate alternatives existed. The EVM's custom-built nature was crucial to flexible application behavior without exposing many potential security risks. However, this same nature introduced quirks and complexities that all but prevented the use of widely used programming languages and tools. Instead, an ecosystem of Ethereum-specific languages and tooling was, and continues to be, built out over the course of Eth1's lifetime. It'll be sorely missed, or perhaps not so sorely by some, but it's time to move away from the EVM in Eth2.

The EVM is responsible for managing two closely related but fundamentally different activities. Most of this responsibility falls on acting as a virtual machine -- executing programs and returning any relevant output results. This functionality is not specific to the EVM. Of course, our phones, laptops, and other computerized machines must also be capable of executing programs and returning results. The EVM is distinct from these computers in that it is also responsible for natively understanding the structure of Eth1's state. This is unusual as most computers have no built-in knowledge of the applications they execute. It's much more frequently the case that the data structures of an application are managed by the application itself.

It should once again be noted that and the designers of the EVM can hardly be faulted for this decision. Few other options were available for consideration and, at the end of the day, the final product worked. Fortunately, we now have mature alternatives that can resolve this quirk. Eth2 takes the step of decoupling program execution and state representation. In place of the EVM, Eth2 introduces "Ewasm" a slightly modified version of the web assembly, or "wasm," virtual machine. Originally designed as a way for developers to build web applications in languages other than JavaScript, wasm is a powerful and, importantly, light-weight virtual machine. Wasm must be modified to fit the context of Ethereum, but wide-spread tech industry support invariably extends to Ewasm.

# Execution Environments

Ewasm manages program execution in Eth2, but has no native concept of "accounts" or "transactions." Instead, these concepts are shifted onto a layer called the "execution environment." Unlike Eth1, Eth2 allows multiple execution environments to operate at the same time. Each environment defines its own representation of state and the way in which that state can be manipulated by applications within that environment. This model essentially converts the fixed structure of state in Eth1 into a more flexible middleware layer. Execution environments would, for instance, make it possible for UTXO- and account-based applications to coexist and even interact.

At the time of writing, the exact process by which new execution environments will be introduced to Eth2 is unclear. It seems most likely that the platform will launch with several well-vetted environments but eventually allow any user to deploy an environment for a large fee. Given that the mechanism is intended to spur innovation in state representation, Eth2 will almost certainly make deployments openly accessible at some point in time. However, environments of questionable quality may hamper the platform's initial release. Moving into production with a few environments that have faced sufficient scrutiny should provide short-term utility and security without limiting the potential for future improvement.