Casper’s History – Chapter 2

This chapter describes the game theory and economic security modeling we conducted in the fall of 2014. We explain how the “bribe attacker model” led our research directly to a radical solution to the long-range attack problem.

Chapter 2: Bribery Attackers, Economic Security, and Long-Range Attack Issues

Since Vitalik and I had each reasoned about incentives as part of our research before we met, the proposition that “getting incentives right” is important in proof-of-stake has never been controversial. We were not willing to accept “half the coins are honest” as a security assumption. (I put it in bold because it’s important.) We knew we needed some kind of “incentive compatibility” between the combined node incentives and protocol security guarantees.

Our view has always been that the protocol can easily be viewed as a game that can lead to “bad outcomes” if the protocol’s incentives encourage such behavior. We considered this a potential security issue. Bonds provided a clear way to punish bad behavior. The slashing condition is basically a program that determines whether or not to destroy the deposit.

We have long observed that the higher the price of Bitcoin, the more secure Bitcoin is, and the lower the price, the less secure Bitcoin is. We now know that deposits provide more economic efficiency than slashers that only reward slashers. It was clear to us that economic security existed and we made it a top priority.

bribe attacker

I’m not sure how much background Vitalik has in game theory (although it was clear he had more knowledge than me). My own knowledge of game theory at the beginning of the story was much more minimal than at the end. But I knew how to recognize and calculate Nash equilibria. If you haven’t learned about Nash Equilibrium yet, the following paragraphs may be helpful.

A Nash equilibrium is a strategy profile (player’s strategy choice) with a corresponding payoff (offer). $ETH or taking$ETH away) No player has any incentive to leave individually. “Incentive to deviate” means “if they somehow change what they are doing, they get more $ETH.” If you remember that and thought “there’s no point in changing individual strategies” every time you heard “Nash Equilibrium”, you’ll have it.

I first encountered the “bribe attacker model” one day in the late summer of 2014, when Vitalik gave an off-the-cuff answer to an economic security question he had asked me on a Skype call (“If you bribe them, they can do it”). I don’t know where he got the idea from. Vitalik then asked me about it again a week or two later so I could develop it further.

You can modify the outcome of the game by bribing the players, and this action changes the Nash equilibrium. It will look like this:

A bribe attack changes the Nash equilibrium of the Prisoner’s Dilemma game from (top, left) to (bottom, right). In this example, the bribing attacker costs 6 if (below, right) is played.

The bribing attacker was our first useful model for economic security.

Before bribery attacks, we typically thought of economic attacks as hostile takeovers by out-of-protocol buyers of tokens or mining power. Attacking a blockchain would require massive amounts of external capital to enter the system. Bribery attacks raise the question, “What is the cost of bribing an existing node to achieve a desired outcome?”

We were hoping that a bribery attack in an as-yet-undefined proof-of-stake protocol would force us to spend a lot of money to compensate for lost deposits.

Debates about “rationality” aside, this was the first step in learning how to reason about economic security. Using an attacker to bribe someone was fun and simple. It lets the attacker know how much he has to pay the player to do what he wants. And we have already established that an attacker would have to pay a deposit-sized bribe to revert the chain in a double-spend attempt. We knew we could recognize “double signatures.” We were therefore confident that this would provide a quantifiable economic and security advantage for Proof-of-Stake over the Proof-of-Work protocols faced by bribery attackers.

Bribe Economics of Long-Range Attacks

Vitalik and I applied bribery attackers to our proof-of-stake study. We discovered that deposit-free PoS protocols can be easily broken by small bribes. Simply pay the coin holder to move your coins to a new address and provide them with the key to the currently empty address. (It’s unclear who originally came up with this idea.) Our insistence on using a bribery model easily ruled out all proof-of-stake protocols we know of. I liked it. (At the time, we hadn’t yet heard of Jae Kwon’s Tendermint, Dominic William’s now-defunct Pebble, or Nick Williamson’s Credits).

This bribery attack also raised questions about deposit-based proof-of-stake. After the deposit was returned to its original owner, the briber could purchase the keys to the collateral stakeholder’s address at minimal cost.

This attack is identical to a ranged attack. Obtaining old keys to control the blockchain. This meant that attackers could create “false records” at will. However, this is only the case if you start from a high where all deposits expire.

Therefore, the long-range attack problem had to be addressed before establishing incentives for proof-of-stake protocols. Without addressing long-range attacks, it will be impossible for customers to know with certainty who actually holds their deposit.

We knew we could use developer checkpoints to deal with the long-range attack problem. We thought this was too centralized.

While staying at Stephan Tual’s house outside London for a few weeks after switching to proof-of-stake, I discovered that there were natural rules to customer reasoning about deposits. A signed promise is only meaningful if it is sent by the sender. today There is a deposit. This means that after the deposit is withdrawn, the node’s signature is no longer meaningful. Why would I trust you after you withdraw your deposit?

The bribe attack model called for this. Breaking a promise after the deposit has been withdrawn costs the bribe attacker very little.

This means that the client holds a combined list of nodes and stops the block at the statement if one of these nodes does not sign. Consensus messages from nodes that do not are ignored. today have a deposit solve Bypasses the long-range attack issue. Rather than authenticating the current status based on history starting from the genesis block, it is authenticated based on a list of people who currently hold deposits.

This is fundamentally different from proof-of-work.

In PoW, a block is valid if it is linked to a genesis block and the block hash meets the difficulty requirements of that chain. In this deposit-based model, a block is valid if it was created by a stakeholder who currently holds a deposit. This meant that authenticating the blockchain required up-to-date information. This subjectivity has raised many concerns, and deposit-based proof-of-stake is essential to be safe from bribery attackers.

This realization made it very clear that the proof-of-work and proof-of-stake security models are fundamentally incompatible. Therefore, I have given up on any serious use of “hybrid” PoW/PoS solutions. Attempts to authenticate a proof-of-stake blockchain from the beginning now seem quite obviously wrong.

But in addition to changing the authentication model, we needed to provide a way to manage these deposit lists. Managing changes to the bonding node list required using the bonding node’s signature, and this had to be done after the bonding nodes had agreed on these changes. Otherwise, clients will have different lists of validators and will not be able to agree on the Ethereum state.

We had to make the bonding time long so that the customer had time to learn about the new set of bonding stakeholders. As long as your clients are online enough, you can keep them up to date. I was thinking I would use Twitter to share the combined node list, or at least the hash, so that the new client and the hibernate client can be synced after the user enters the hash into the UI.

If you have a bad list of validators you can get: meson. But it’s actually not that bad. That argument was (and still is!) You only need to trust one external source for this information.. After that, you can update the list yourself. At least, if you can get online regularly enough to avoid “long-distance” deposit withdrawals.

I know it may take some getting used to. But we can only rely on new deposits. Vitalik was initially a little uncomfortable with this argument and tried to maintain the ability to authenticate from the beginning, but eventually became convinced that this kind of subjectivity was necessary in a proof-of-stake protocol. Vitalik independently came up with his own idea. Weakly Subjective Grading RulesThis seemed like a perfectly reasonable alternative to my thinking at the time, which was basically “get every deposit signed every Nth block to update the list of bonded nodes.”

With the undead and ranged attacks nailed down, we are ready to choose our slash conditions.

In the next chapter, we will document what we learned from our first effort to define a consensus protocol by specifying slashing conditions. I’ll also tell you about what I’ve learned from talking to great people in our space about our research. The game theory and economic modeling story presented here will continue to develop in Chapter 4.

Note: The views expressed here are solely my own and do not represent the views of the Ethereum Foundation. I am solely responsible for what I write and do not act as a spokesperson for the Foundation.