# Project Philosophy

We now turn our attention to some of the guiding philosophies behind Eth2. The design goals described in this section heavily influence the specifications for Eth1 as a whole. It's often easier to understand the decisions made in the construction of Eth2 through the lens of these philosophies. Several authors have published slightly differing goals for the development of Eth2. We focus specifically on the points highlighted by Danny Ryan of the Ethereum Foundation. However, we derive additional context from Vitalik Buterin's design rationale document and other older publications.

Eth2 development is directed primarily by adherence to five high-level design principles: decentralization, resilience, security simplicity, and longevity. Although their names are descriptive, each goal corresponds to a particular set of well-reasoned target properties for Eth2. These principles therefore act as concrete requirements and more general guidelines. We'll take a look at both on sides of each principle and provide some intuition as to how these principles play into the construction of Eth2.

# Decentralization

Decentralization as a term of art is somewhat over-utilized within the blockchain ecosystem. This fact has, unfortunately, reduced the term's ability to describe specific properties of a blockchain system. In a vague sense, "decentralization" in a system refers to a reduction in the ability for a group of actors to hold undue influence in some aspect of the system. Given that a system may enable a multitude of interactions, we're typically required to consider the extent of decentralization of specific system sub-components. Within the context of Eth2, we're most interested in decentralizing the consensus mechanism that determines the blocks processed by the network.

We've already acknowledged that certain methods for improving system throughput, like supernodes, tend to increase centralization in various ways. Proof-of-Work additionally produces a centralizing effect due to its high barriers to entry and strong susceptibility to economies of scale. Eth2 moves to reduce entry costs much further and, under the target of decentralization, aims to enable consensus participation from even consumer laptops. Such a goal clearly demands shift away from costly Proof-of-Work consensus. However, it also demands a completely new super-linear scaling mechanism. If users can participate in Eth2's consensus protocol from a laptop, Eth2 must not be limited by the processing power of an individual laptop.

So, to this end of decentralization, Eth2 makes use of a sharding technique, which we've briefly touched on, and a novel Proof-of-Stake consensus protocol, which we explore in detail within the next chapter. These advancements account for most improvements in decentralization found in Eth2. Other upgrades to Ethereum's networking and application layers serve to additionally expand and diversify the potential set of participants and use-cases in the ecosystem. One could even consider educational resources such as this book to have a decentralizing impact on the Ethereum research and development community. All this is to say that, although "decentralization" may in part refer to technical details, it also permeates Eth2 on almost every imaginable level.

# Resilience

Eth2's second stated goal is towards greater resilience against catastrophic events. Ethereum, like any platform responsible for critical applications, must be able to guarantee relatively stable operation under a wide range of conditions. It's unlikely that many users would be willing to conduct important interactions on Eth2, financial or otherwise, if there were any significant risk of system failure. Massive economic platforms like Eth2 should remain functional in even the most extreme circumstances along the lines of natural disasters or warfare. Eth2 designers must therefore consider a vast number of potential failure modes on various levels of the protocol.

As with decentralization, many of the "practical" approaches to resilience in Eth2 are centered around its consensus protocol. For instance, Eth2's Proof-of-Stake mechanism supports active participation by hundreds of thousands of users. In tandem with lower entry costs, this property both improves decentralization and decreases the impact of regional events on the system as a whole. Eth2 further solidifies this resilience through design decisions that allow the system to progress even if a massive percentage of participants suddenly go offline. These features, amongst others, help to ensure against even large-scale catastrophic scenarios.

Of course, Eth2's resilience also extends to the networking and application layers. Eth1 made use of a custom-built networking technology that has since been supplanted by more robust and flexible offerings. Eth2's networking layer represents a significant leap over that of its predecessor. These improvements should extend the Ethereum platform to a wider range of devices and reduce the overall frequency of connectivity issues. With regards to its application layer, Eth2 introduces a variety of changes that give users and developers more freedom of choice. In particular, Eth2 allows for custom state representations, as opposed to the fixed account model of Eth1. Flaws or inefficiencies in one representation can therefore be mitigated by redundancies not feasible in Eth1.

# Security

Eth2 explicitly lists security as a design goal. As a more general term, "security" can be related quite closely to both decentralization and resilience. In essence, the phrase here refers to the security of the consensus protocol against malicious behavior from its participants. This security boils down to maximizing the cost of malicious activity while also minimizing the activity's potential impact. Eth2 aims to provide markedly better guarantees than can be provided by earlier Proof-of-Work-based protocols.

Concretely, Eth2 is constructed such that an attack on its consensus protocol is much more costly than the 51% attack permitted by Proof-of-Work. Eth2 attains this property through a combination of several design choices. Primarily, the system drives up attack costs by harshly punishing malicious behavior. Unlike Proof-of-Work mechanisms, Proof-of-Stake protocols explicitly store the voting power of each participant. Eth2 can thereby reduce the voting power of some participant upon receiving evidence of foul play. An attack on Eth1 is costly, but the system cannot destroy the attacker's mining hardware for doing so. An attack on Eth2, on the other hand, can be met with a response akin to torching the attacker's entire mining operation.

Eth2 reinforces this property by taking advantage of novel cryptographic techniques to diminish the efficacy of coordination amongst attackers. As the total number of participants in the consensus process rises, any would-be attacker must generally coordinate their actions with an ever-increasing number of others. This coordination quickly becomes a massive cost in itself in the face of potentially millions of total participants. Collusion is further complicated by a "committee" system in Eth2, whereby large sets of participants are randomly selected to perform important activities. This element of randomness cripples an attacker's ability to organize an action with significant lead time.

# Simplicity

Simplicity is a somewhat self-explanatory design goal, but its implementation may sometimes at first seem counter-intuitive or even counter-productive. At the highest level, simplicity in Eth2 asks designers to reduce complexity in both the theoretical basis for the system and in the specifications used to implement it. The value of simplicity takes many forms, some more obvious than others. Clear and well-reasoned specifications, for instance, reduce the amount of effort required to develop functional node software. Specification clarity can also, as a second-order effect, improve accessibility for potential contributors who may wish to provide valuable feedback. Similarly, simplified theoretical pillars directly serve to increase public confidence, but also indirectly minimize the possibility of confusing and perhaps unnecessary debates.

On the more theoretical side of Eth2, simplicity comes in many shapes and sizes. Eth2 in some cases chooses to push complexity out of its core protocol and into other layers. For instance, it deliberately lacks certain privacy features exposed by other platforms in favor of a more minimal foundation. It's not unusual that Eth2 will make these types of tradeoffs of efficiency or utility for simplicity. Sometimes, designers take a seemingly contrary approach and introduce complexity for the sake of flexibility and simplicity in some other area of the system. We frequently find debates of such decisions with respect to the level of responsibility that should reasonably be shouldered by applications and not the core consensus protocol.

Simplicity is in many ways, a balancing act for protocol designers. A highly featured system may put itself at risk of becoming confusing or, at worst, vulnerable to attack through some unforeseen combination of actions. As is always the case, more moving parts create more opportunities for unexpected errors. An overly simplistic system, however, may fail to provide many of the features necessary for the growth of a thriving application ecosystem. Luckily, observations of Eth1 have provided the Ethereum community with a better understanding of the minimal set of necessary protocol-level considerations. As a result, Eth2 manages to be clear and lean while remaining highly useful.

# Longevity

The fifth and final explicit design goal of Eth2 is longevity. Consensus protocol design is difficult for many reasons, but not always for the reasons one might expect. As a software system, Eth2 is subject to many of the traditional pressures that require critical infrastructure to be robust and run smoothly for long periods of time. However, as a blockchain system, Eth2 faces the unique challenge that system upgrades are almost always accompanied by widespread scrutiny and debate. Upgrades only become increasingly difficult to organize as the number of participants in the system grows. It's therefore necessary to ensure that most major design choices are sustainable for at least the next decade.

Longevity, unlike Eth2's other design goals, is primarily a matter of details on the implementation level. Some considerations with respect to security or simplicity mostly guarantee the correctness and, by extension, the longevity of Eth2's consensus protocol. In a theoretical sense, barriers to longevity are often found in the cryptographic or mathematical tools to used to implement theoretical concepts. For example, Eth2 makes frequent use of hash functions and digital signature schemes to assert the veracity or uniqueness of pieces of information. Existing versions of these tools are thought to be secure against attacks by classical computers, but are commonly weakened or even broken in the face of quantum computers. Though the timeline for quantum computing is uncertain, it's crucial that Eth2 take preemptive steps to mitigate potential disruption.

Unfortunately, the road to longevity contains numerous pitfalls. Some elements necessary for Eth2's operation currently have only very young future proof alternatives or, at least for the moment, have no such alternative at all. Eth2 takes advantage of secure components wherever possible, but must occasionally err on the side of incumbent technology when newer alternatives have yet to face sufficient scrutiny. In these cases, protocol designers aim to show that potentially vulnerable components very likely have quantum-secure counterparts that could be retrofitted into the system if necessary. As a general rule of thumb, any foreseen issues must either be directly mitigated or, if no adequate mitigation exists, must be considered such that a mitigation could be inserted at a later point in time.

# Conclusion

The five aforementioned design goals capture, in a nutshell, the ethos of the Eth2 project. Their essences revolve around the key aspects of any economic system: security and accessibility. If Ethereum is to become a global platform, it must break free of the technological limitations of its predecessors. As a piece of critical human infrastructure, it cannot do so at the expense of security. Security of course, can refer to the validity of the platform's theoretical foundation or the robustness of the software tools necessary for its implementation. However, security can also be derived from the health of Ethereum's community of active contributors or the diversity of its consensus participants. Readers are urged to internalize these principles and, hopefully, find small ways in which these goals can be applied to new corners of the Ethereum ecosystem.