This chapter outlines the game theory and economic security modeling we conducted in the Autumn of 2014. It narrates how the “bribing attacker model” guided our research towards a groundbreaking solution for the long-range attack dilemma.
Chapter 2: The Bribing Attacker, Economic Security, and the Long Range Attack Dilemma
Vitalik and I had both been contemplating incentives as part of our investigation even before we met, thus the assertion that “aligning the incentives accurately” was essential in proof-of-stake was never up for discussion. We were adamant about not accepting “half of the coins are honest” as a security premise. (It’s highlighted because it’s significant.) We recognized that we required some form of “incentive compatibility” between the bonded node motivations and the protocol’s security assurances.
We consistently viewed the protocol as a game that could potentially lead to “unfavorable outcomes” if the incentives within the protocol promoted such conduct. We considered this a possible security threat. Security deposits provided a clear mechanism to penalize misconduct; slashing conditions, which are essentially protocols that determine whether to confiscate the deposit.
We had long noted that Bitcoin’s security level increased when the bitcoin price soared and diminished when it dropped. We also realized that security deposits offered slashers more economic efficiency than slashing solely based on rewards. It became evident to us that economic security was a reality, and we prioritized it highly.
The Bribing Attacker
I am uncertain about how much background Vitalik possessed in game theory (although it was apparent he had more than I did). My own knowledge of game theory at the beginning of this narrative was even less comprehensive than it is now. However, I understood how to identify and compute Nash Equilibriums. If you haven’t yet been introduced to Nash Equilibriums, this next paragraph is tailored for you.
A Nash Equilibrium is a strategy profile (the players’ strategic choices) with a corresponding payout (offering ETHortakingETH or taking ETH away) such that no players have an individual incentive to change their strategy. “Incentive to change” refers to “they receive more $ETH if they somehow alter their actions.” If you bear that in mind, and whenever you hear “Nash Equilibrium” you think “no rewards for individual strategy alterations,” you will grasp it.
In late summer 2014, I initially encountered “the bribing attacker model” after I made a passing remark to an economic security query posed by Vitalik during a Skype conversation (“I can just bribe them to do it”). I can’t pinpoint where I got the concept. Vitalik then inquired about this again, perhaps a week or two later, pressing me to elaborate on it further.
By incentivizing game participants, you can alter a game’s payoffs and thereby modify its Nash Equilibriums. Here’s how this might manifest:
The bribe attack shifts the Nash Equilibrium of the Prisoner’s Dilemma game from (Up, Left) to (Down, Right). The bribing attacker in this scenario incurs a cost of 6 if (Down, Right) is executed.
The bribing attacker represented our first practical model of economic security.
Prior to the bribing attack, we primarily regarded economic assaults as hostile takeovers executed by external, extra-protocol buyers of tokens or computing power. A massive influx of external funds would need to infiltrate the system to compromise the blockchain. With the bribe attack, the inquiry shifted to “what is the cost of bribing the currently existing nodes to achieve the desired result?”.
We anticipated that the bribing attacks targeting our yet-to-be-defined proof-of-stake protocol would need to allocate significant funds to compensate for the forfeited deposits.
Setting aside debates regarding “reasonableness”, this marked our initial venture into reasoning about economic security. Utilizing a bribing attacker was enjoyable and straightforward. You merely determine how much you must compensate the players to execute the desired actions of the attacker. We were already assured that we could enforce that an attacker would need to provide security-deposit-sized bribes to reverse the chain in an attempted double-spend. We were convinced of our ability to identify “double-signing.” Thus, we were fairly confident that this would furnish proof-of-stake with a measurable economic security edge over a proof-of-work protocol faced with a bribing attacker.
The Bribing Economics of the Long Range Attack
Vitalik and I applied the bribing attacker concept to our proof-of-stake research. We discovered that PoS protocols lacking security deposits could be effortlessly compromised with minimal bribes. You simply compensate token holders to transfer their tokens to new addresses and grant you access to their now vacant addresses. (I am unsure who initially conceived this idea.) Our commitment to employing the briber model effectively dismissed all known proof-of-stake protocols. I appreciated that. (At that point, we had not yet encountered Jae Kwon’s Tendermint, Dominic Williams’s defunct Pebble, or Nick Williamson’s Credits.)
This bribe assault also presented a challenge to security deposit-based proof-of-stake: The instant a security deposit was returned to its original proprietor, the bribing adversary could acquire the keys to their bonded stakeholder address at minimal expense.
This assault mirrors the long-range attack. It involves obtaining old keys to seize control of the blockchain. It indicated that the attacker could fabricate “false histories” at will, albeit only if they initiated from a height where all deposits had lapsed.
Consequently, before proceeding to establish the incentives for our proof-of-stake protocol, we needed to tackle the long-range attack issue. Failing to address the long-range attack concern would render it impossible for clients to accurately determine who truly possessed the security deposits.
We acknowledged that developer checkpoints could be employed to manage the long-range attack dilemma. We believed this was evidently far toocentralized.
In the weeks after my transition to proof-of-stake, while I was residing at Stephan Tual’s residence near London, I realized there was an inherent principle for clients to assess security deposits. Signed commitments become significant only if the sender currently possesses a deposit. In other words, once the deposit is removed, the signatures from these nodes lose their significance. Why would I place my trust in you following the withdrawal of your deposit?
The bribery attack framework necessitated it. It would require the bribing attacker nearly nothing to violate the commitments once the deposit is withdrawn.
This indicated that a client would maintain a roster of bonded nodes, and would halt blocks at the threshold if they were not endorsed by one of these nodes. Disregarding consensus notifications from nodes that do not currently possess security deposits addresses bypasses the long-range attack dilemma. Rather than validating the current state based on the history originating from the genesis block, we verify it based on a list of those who presently have deposits.
This is profoundly distinct from proof-of-work.
In PoW, a block is deemed valid if it is linked to the genesis block, and if the block hash satisfies the difficulty criteria for its chain. Within this security deposit-centric structure, a block is valid if it was produced by a stakeholder with a currently existing deposit. This implied that one would need up-to-date information in order to validate the blockchain. This aspect of subjectivity has instilled considerable concern among many individuals, but it is essential for security deposit-driven proof-of-stake to be safeguarded against the bribing attacker.
This insight made it abundantly clear to me that the proof-of-work security framework and the proof-of-stake security framework are intrinsically incompatible. Consequently, I discarded any earnest consideration of “hybrid” PoW/PoS solutions. Attempting to authenticate a proof-of-stake blockchain from genesis now appeared evidently flawed.
Beyond altering the authentication model, we also had to establish a mechanism for managing these lists of security deposits. We needed to utilize signatures from bonded nodes to handle modifications to the roster of bonded nodes, and we had to execute this after the bonded nodes reach a consensus on these modifications. Otherwise, clients would possess differing lists of bonded validators, and consequently, they would be unable to concur on the state of Ethereum.
Bond durations needed to be extended, allowing clients ample time to familiarize themselves with the new, incoming collection of bonded stakeholders. As long as clients remained online sufficiently, they could stay informed. I envisioned using Twitter to disseminate the bonded node list, or at least a hash, so that both new and dormant clients could synchronize after their user inputs a hash into the UI.
If you possess an incorrect validator list you can be subject to man-in-the-middle attacks. However, it is really not that serious. The rationale was (and remains!) that you only need to trust an external source for this information once. After that singular occurrence, you will be able to update your list independently – provided you are online frequently enough to avoid the “long range” of withdrawn deposits.
I understand that it might require some adaptation. However, we can solely depend on recent security deposits. Vitalik felt somewhat uneasy with this perspective initially, striving to retain the capacity to authenticate from genesis, but ultimately he was persuaded by the necessity of this kind of subjectivity in proof-of-stake protocols. Vitalik independently devised his weak subjectivity scoring rule, which appeared to me as a perfectly sensible alternative to my proposal at the time, which was fundamentally “have all the deposits sign every Nth block to update the bonded node list.”
With the final nails driven into the nothing-at-stake and long-range attack arguments, we were prepared to commence selecting our slashing conditions.
The subsequent chapter will detail our insights from our initial challenges in defining a consensus protocol by delineating slashing conditions. I will also share with you what we learned from discussions with notable individuals in our field regarding our research. The concepts of game theory and economic modeling presented here will continue to evolve in Chapter 4.
NOTE: The opinions expressed here are solely my individual views and do not reflect those of the Ethereum Foundation. I am solely accountable for the content I’ve presented and do not act as a representative for the Foundation.