What I like about it is that it feels like a consensus algorithm properly designed for blockchain protocols: Leader rotation with chained proposals is integrated into the protocol rather than bolted on as an afterthought. This achieves a beautiful simplicity that has a cleaner feel than many traditional BFT algorithms. The separation of justification and finalization is one of the most difficult things to understand when first approaching BFT literature; and full leader rotation in the case of leader failure is often horribly complicated and incompletely described in papers and buggy in implementations. In Minimmit, it feels much more natural (assuming that you are coming from a blockchain context).

Quick notes on this article

My goal here is mostly to give an intuition for how Minimmit works and why it needs an 80% majority. Whenever I write 2/3rds majority, or 80% majority, it should be read as saying as requiring one extra vote, so 2 out of 3 is not enough to satisfy a 2/3rd majority but 3 out of 4 is and 7 out of 10 is.

The intuition of why an 80% majority is needed

If you want to finalize with a single round of voting, you need 80% of nodes to be honest: formally Minimmit uses \(n \geq 5f+1\), where \(n\) is the total number of nodes and \(f\) the number of byzantine failures tolerated, i.e. the number of nodes that can behave completely adversarially. This means strictly more than 80% of nodes need to be honest. The general tight lower bound for fast Byzantine consensus is actually \(n \geq 5f-1\) ², which applies when proposers are a subset of acceptors. However, FaB Paxos ³ established that \(n \geq 5f+1\) is necessary for a specific class of protocols where proposers and acceptors are distinct sets. For a recent treatment in the blockchain context see Minimmit ¹.

A good way to understand why this is necessary is to understand that the leader, i.e. the block proposer, can be byzantine, and one of the things they can do is to propose several blocks at the same time, so honest nodes disagree on what to vote for. What we want to avoid is the leader being able to put the protocol into any bad state; the worst case would be finalizing two incompatible blocks (blocks that aren’t in the same chain), but we also can’t allow them to put the protocol into an unrecoverable state (i.e. a state where the protocol can’t automatically recover without manual intervention).

Here is an intuition why 2/3rds majority can’t do one round finalization. Assume we finalize a block if it gets 2/3rds of the votes. Let’s start with the easy part: An honest proposer proposes exactly one block. All honest nodes will vote for this. In a partially synchronous network all votes will eventually arrive at all the honest parties, so they will all see that 2/3rds have voted for the block. So far, so good.

However now we have to think about a malicious proposer. One thing they can do is not propose a block. The protocol needs to be able to detect this, so parties have to be able to vote for an empty slot (in Minimmit this is called nullify, so I will call it nullifying from here onward). If 2/3rds of the nodes vote to nullify the block, we can move on.

But unfortunately, the leader can do worse than just not proposing a block: They can also propose two different blocks at the same time. Now we will have a situation where about half the honest nodes vote for each proposal. In addition we have to remember that malicious nodes can vote twice, or not at all, or even withhold their votes until a later time to decide their action after seeing what the honest nodes are doing. Here they could temporarily lend some votes to the proposal with fewer votes to have it appear to have the majority of votes, like this: If the protocol uses the option with more votes to continue the chain it means that the next round is started on an unsound building block, because the malicious nodes would have the power to finalize the other option. The protocol designer faces an impossible choice:

• Never continue until a proposal reaches 2/3rds of votes. In this case, the malicious proposer can stop the chain
• Continue with whichever proposal reaches the most votes. In this case, the malicious nodes may be able to finalize a different proposal with their remaining votes or by equivocating

This is the conundrum that traditional BFT algorithms solve with justification. The first round of voting is to justify a block (which cements that it was properly proposed by a non-equivocating proposer). When a block has been justified (i.e., when f+1 correct nodes have seen a quorum of first-round votes in a timely fashion), honest nodes cannot vote for incompatible blocks in later views in protocols like PBFT ⁴. But this adds an extra round, which is what we want to avoid here.

This is the intuitive explanation why we can’t finalize with a 2/3rds majority in a single round.

Why it works with an 80% majority:

Let’s change this, and require a greater than 80% (4/5ths) majority to finalize. As before, we don’t need to worry about the case where there’s an honest proposer.

Instead let’s look at the case where the proposer splits honest nodes. Let’s say we have the honest nodes about equally split between the two different proposals:

Note an important difference now: The malicious nodes no longer hold the power to finalize either of the two. Adding their votes only gets them to 60% and not to 80%. This is good: It means we can move on with one of these options without risking that the other will be finalized, which would be bad. This lets us formulate more clearly what we want:

• We need the next proposer to be able to infer a safe block to build on – or an empty (nullified) one. What we want is that if they are honest, their block will be finalized (and this can’t be contradicted by a conflicting block from the previous round being finalized)

Minimmit does this using an M-notarization (M for mini), which is a set of more than 40% votes (or nullify votes). The important thing is that an M-notarization is not a finalization (called L-notarization in Minimmit, though I will just call it finalization). That’s because there can be several M-notarizations in the same slot. The best way to think is that it’s a signal by the protocol to the next proposer: “It’s safe to build on this block”:

• It means in the slot of the M-notarization, no other proposal can be finalized
• If an honest proposer builds on an M-notarized proposal (or nullification), then their block will be finalized; in other words, if the next proposer (a) proposes on time and (b) does not equivocate then their proposal will be finalized

The tricky part is now making sure that there always is an M-notarization for each slot; when there are only two options like in my constructed example, this is ok; but what if the proposer sends many different blocks, so there are now more options and none of them gets more than 40% of votes? This is solved by instructing honest nodes to also send a nullify message if they have already voted, but only if they have seen more than 40% votes that are either nullify votes or votes for a block that they didn’t vote for. This is safe because that condition means that the block they voted for can’t be finalized anymore; so they can safely vote to nullify this slot.

This idea is very cool, because it makes the protocol super simple: No special view change algorithms other than the one that is already built into the blockchain. And it’s also doubly fast: It can progress with only 40% of votes, and it can finalize after only one round of voting (with 80%) of votes coming in.

Now, let’s get back to the part why we need specifically more than 80% honest nodes, and not some smaller fraction like 75% (we have already seen that 2/3 is not enough). The key property we have used is that if an M-notarized proposal exists, then no other proposal can get finalized in the given round. Now, 20% of that could be the malicious nodes, so we really only know that more than 20% honest nodes have voted for this proposal. This means another just under 60% of the honest nodes could have voted for a different proposal. This is key: with the malicious nodes double voting for the second proposal, it can still only get to just under 80%, not enough to bring it over the edge and finalize it.

This being very close to the finalization threshold of 80% prevents us from lowering the honesty requirement. If we allowed 21% malicious nodes, the math wouldn’t work out: We now require 79% of votes to finalize (need to be able to finalize without the help of malicious nodes), and we would have to require \(100\% - 79\% + 21\% = 42\%\) to M-notarize. We also need to increase the threshold to send a nullify vote after already voting (the key to moving on with malicious proposers who do multiple proposals) to 42%. Now let’s say the malicious proposer sends two blocks, and the malicious votes don’t vote; there is a possibility they each get 39% of the honest votes. The protocol is now stuck: Neither side of the split votes would be able to nullify their votes, because they can’t see 42% votes for something else (only 39% are on the other side). This shows intuitively why we can only tolerate less than 20% nodes malicious with this protocol.

Description of the protocol

We are ready to give a description of the protocol. We assume a schedule of leaders pre-determined in another way (this is typically given in blockchain protocols, for example they can use a VRF (verifiable random function) to determine a random leader or simply rotate through all nodes).

Definitions:

• A proposal is a block signed by the proposer of the current round. A block also refers to its ancestor, thus creating a chain of blocks.
• A vote is a message signed by a node that includes a hash of the proposal being voted for. It is signed by the voting node
• A nullify message is an alternative vote that says there was no valid proposal, or there are several valid proposals in this round. It only includes the round number and the node signature
• An M-notarization is a collection of more than 40% of the votes for a valid proposal; more than 40% of valid nullify messages for the current round are called a nullification
• A finalization is a collection of more than 80% of votes for a valid proposal
• A proposal is valid if it is a descendant of the last finalized block, all ancestors since the last finalized blocks are M-notarized or valid nullifications, and it bears the signature of the round leader (the blockchain protocol can add additional validity conditions)

In each round:

1. The leader waits until they see an M-notarization for a valid proposal in the previous round (or a nullification)
2. They propose a block based on this
3. All nodes vote for the valid proposal that they see first, or to nullify if they don’t see a proposal within a time specified by the protocol
4. If a node sees 40% of votes that are not for the proposal it voted for, it also votes to nullify the round.
5. Nodes advance to the next round as soon as they see an M-notarization for the current round.

The key is that for each round:

• There is always an M-notarization or a nullification (so the protocol can always progress)
• If there are several options (several M-notarized proposals or an M-notarized proposal and a nullification), then none of these options can be finalized (this means it’s always safe to build on an M-notarization of a nullification)

Is M-notarization similar to dynamic availability?

In Ethereum, the idea of “dynamic availability” is that we can continue building a chain even if less than the consensus majority (in Ethereum’s case, 2/3rds) are online – this dynamically available chain is not safe against reorgs like a finalized chain, although it does provide some guarantees against minority attackers.

Assuming all online nodes are honest and under reasonable synchrony assumptions, Minimmit can build a chain with only 40% of nodes being online, similar to a dynamically available consensus. While it requires 40% of nodes being online (compared to being able to continue even with single-digit percentages in Ethereum), it’s still much better than most BFT protocols which fail as soon as fewer than 2/3rds of all nodes are online. It looks similar to ebb and flow constructions or Ethereum’s FFG+GHOST construction.

Let’s consider what happens when two different chains of M-notarizations are available, which can occur after a network partition. Suppose we have a partition where two sets of nodes (each with sufficient nodes to form M-notarizations) operate independently, with synchrony maintained within each partition but no communication between them. Since Minimmit doesn’t use fixed slot times but instead advances rounds when M-notarizations are seen, the two chains will likely advance at different rates, resulting in different round numbers.

When the partition is resolved and synchrony is restored, the next honest leader (assuming leaders are randomly selected and unknown to the adversary in advance) will see both chains. They can choose which chain to build on, and all honest nodes will vote for their proposal. However, if one chain has reached a higher round number (i.e., has more M-notarized rounds, not counting nullifications), then nodes following the shorter chain will have already advanced to match the longer chain’s round number as they see the missing M-notarizations. In this case, the leader has no choice but to build on the chain with the higher round number, so the partition resolves in favor of the chain that advanced faster.

This is not unlike Ethereum, where proposer boost ⁵ had to be added in order to ensure that chain splits can always be resolved in the presence of an attacker who tries to balance the chains (adds their vote to always keep the votes split). In Minimmit, when chains have similar round numbers, the proposer acts as the arbiter; but when one chain is clearly longer (in terms of round numbers with M-notarizations), the protocol naturally favors it.

References

I’m not a trader. This post is just a summary of my views, not investment advice.

Something interesting has been happening to L1 token valuations: while on-chain activity continues to grow, many tokens have struggled to maintain their previous price levels. This disconnect suggests that the fundamental value proposition of these tokens may have shifted. Here’s my take on what’s going on.

ETH was money

There has been a lot of debate about whether ETH is money, but if we look at the facts, the reality is that ETH was money.

In 2017, the first major product market fit of the Ethereum chain was ICOs. It was a crazy year with a lot of exuberance, but most importantly, ICOs collected their investments in ETH. Since ETH seemed to be up only, people as well as organizations kept large parts of their investments in ETH and even used it as a primary way to value their stashes.

2020/2021 brought another wave of adoption, centered around DeFi and NFTs. Again, ETH was front and center – remember when Christie’s and Sotheby’s started showing prices in ETH?

Retrospectively, this was the highest point of ETH adoption as money. In some aspects, it had achieved the trifecta:

• Unit of Account (mostly for NFTs)
• Store of Value
• Medium of Exchange

The velocity of money equation (MV = PQ, where M is money supply, V is velocity, P is price level, and Q is quantity of goods/services) tells us that when ETH is used as money, its market capitalization (proportional to M) should be proportional to the on-chain GDP (PQ), assuming velocity remains relatively constant. In other words, as the economic activity on Ethereum grows, so should ETH’s valuation if it continues to serve as the primary medium of exchange.

ETH was displaced by stablecoins

Since 2021, time has been less kind to ETH: NFTs lost a lot of their value, and adoption as a medium of exchange has mostly been replaced by stablecoins:

Ethereum is now rarely used as a medium of exchange or unit of account, when compared to the 2017-2021 period. This could be an explanation why appreciation of ETH seems to have stalled, while adoption is still growing.

The path forward

ETH could escape this by:

• Becoming a memetic store of value modeled after gold (and now maybe Bitcoin). However, this largely decouples it from the success of the Ethereum chain itself, and it is unclear if it will be perceived as much better than Bitcoin; the value for memetic stores of value is largely driven by brand and not technical properties
• Driving a massive campaign to re-establish ETH as money in the functions that it has lost
• Focusing on earning revenue and burning fees, aiming to have at least 10s of billions USD in revenue. This will require turning the EF into an effective R&D and BD org, as well as finding ways to continuously fund those efforts

Many L1s will face the same question. While their tokens don’t have a history of being used as money, they mostly attained their valuations by being seen as a potential replacement to Ethereum, with the implied assumption that their tokens would similarly be used as a medium of exchange. Solana did have some short success in this during the memecoin craze in early 2025, but it was even more short lived than the past drivers of Ethereum’s success.

Conclusion

The challenge facing L1 tokens is that their historical valuations were largely predicated on their use as money – specifically as a medium of exchange. The velocity of money equation suggests that when a token serves this function, its valuation will track on-chain economic activity. However, the shift to stablecoins has broken this link for most L1 tokens.

This creates a valuation problem: if tokens are no longer used as money, what drives their value? The options are: either recapture the monetary functions, pivot to a store-of-value narrative (competing with Bitcoin), or fundamentally change the value proposition by generating substantial revenue through fees and burns. The latter path requires a different kind of organization: one focused on business development and sustainable revenue generation rather than just protocol development.

Blockchains are a lot of things to different people, but I think most fundamentally they can be seen as:

1. A place where you can post stuff so that anyone can see it and it has a canonical order and
2. An interpretation of the posted stuff

To illustrate this further, when Alice sends Bob some coins, she has to put a transaction on chain (1) and this transaction is then interpreted as being a transfer of her coins to Bob (2). We can also say (1) is data availability and (2) is execution.

What do we care about

A lot of us talk about security and hardness. So let’s get deeper into the properties that we would want from such a system:

1. How do you post a transaction to be processed (this is censorship resistance and ordering)
2. How predictable is the interpretation of this data (this is security)
3. How will the interpretation of the data change in the future (this is hardness)

The difference between security and hardness is that security refers to the code as it is now, and hardness to future changes. Let’s say that there is a bug in the EVM that allows anyone to create any number of ERC20 tokens; this is clearly against the expectation we have on these smart contracts, and so it would constitute a major security bug.

If instead, say, all Ethereum core devs decided it is a good idea to change the code so that anyone can create any number of ERC20 tokens, and announced this to everyone, and the node operators simply decided to install this update instead of protesting this violation of core principles, this would not violate the predictability of the current code; but it would violate past expectations that the behaviour would not change, and would therefore violate hardness.

Censorship resistance, ordering and hardness are all important properties of blockchains. However, with new learning over the last few years, I think we have to reassess how we prioritize different properties, because the tradeoffs are not free.

Bitcoin established hardness

• 21 million cap central tenet

Smart contract blockchains are becoming money APIs

• RWAs don’t require as much hardness
• issuer always provides security of last resort
• stability still good but no more central value proposition

Ordering and censorship resistance should become new focus

• Ethereum so far has taken a very long term view
• Censorship resistance is seen as a long term property (see, inclusion into blocks with )

Security and hardness still matter

• security is important for everything that happens on chain
• hardness should be seen like the stability of the money API
• predictable, long term changes are ok
• it’s not about making commitments for decades

Summary – refocus on

I won’t delve deeply into its introduction here, but the SUMCHECK protocol (Carsten Lund, Lance Fortnow, Howard J. Karloff, and Noam Nisan. “Algebraic Methods for Interactive Proof Systems”, 1992) serves as a foundation for many “verifiable computation” primitives. If you’re reading this, you likely already know its significance.

Let \(\mathbb{F}\) be a finite field and \(f(X_1, X_2, \ldots, X_n)\) be a multivariate polynomial of degree \(d\) over \(\mathbb{F}\). Consider the sum \(S\) defined as:

The SUMCHECK protocol provides an \(n\) round interactive protocol to verify the correctness of \(S\), using only a single evaluation of \(f\) (i.e. the verifier only has to evaluate \(f(X)\) once, rather than \(2^n\) times).

The protocol advances through \(n\) rounds. In each round, the prover sends a univariate polynomial to the verifier. In response, the verifier conducts a check and responds by sending a single field element challenge.

Round 1

The prover computes and shares the univariate polynomial:

The verifier ensures that the degree of \(f_1\) is less than \(d\), checks if \(f_1(0) + f_1(1) = S\), and issues the challenge \(r_1 \in \mathbb{F}\).

Round 2

The prover computes and shares the univariate polynomial:

The verifier ensures that the degree of \(f_2\) is less than \(d\), checks if \(f_2(0) + f_2(1) = f_1(r_1)\), and issues the challenge \(r_2 \in \mathbb{F}\).

Round \(i\)

The prover computes and shares the univariate polynomial:

The verifier ensures that the degree of \(f_i\) is less than \(d\), checks if \(f_i(0) + f_i(1) = f_{i-1}(r_{i-1})\), and issues the challenge \(r_i \in \mathbb{F}\).

Round \(n\)

The prover computes and shares the univariate polynomial:

The verifier ensures that the degree of \(f_n\) is less than \(d\), checks if \(f_n(0) + f_n(1) = f_{n-1}(r_{n-1})\), and issues the challenge \(r_n \in \mathbb{F}\).

Final check

The verifier evaluates \(f(r_1, \ldots, r_n)\) and confirms that it equals \(f_n(r_n)\).

Why does it work

Below, I present an intuitive proof for the efficacy of the SUMCHECK protocol, assuming a large field \(\mathbb{F}\). For this explanation, the Schwartz-Zippel lemma is essential.

The Schwartz-Zippel Lemma

The Schwartz-Zippel lemma states: For a non-zero multivariate polynomial \(P(X_1, \ldots, X_n)\) with a total degree of at most \(d\) over the field \(\mathbb{F}\), when evaluating \(P\) at random points \(r_1, \ldots, r_n\) from \(\mathbb{F}\), the likelihood of \(P(r_1, \ldots, r_n)\) being zero is less than \(\frac{d}{\lvert\mathbb{F}\rvert}\).

In large fields (like the scalar fields of elliptic curves often, which are cryptographically secure with field sizes around \(2^{256}\)), this probability is minuscule. This is because a polynomial can only have a limited number of zeros. For a univariate polynomial, this is immediately evident from the “factor theorem”: Every zero of the polynomial corresponds to a linear factor, so a degree \(d\) polynomial can have up to \(d\) zeros.

A common application of the Schwartz-Zippel lemma is comparing two univariate polynomials, \(f(X)\) and \(g(X)\), to determine their identity. By generating a random number \(r \in \mathbb{F}\) and checking if \(f(r) = g(r)\), we can determine if they are the same. This method is correct, but is it also sound? What’s the likelihood of erroneously claiming \(f(X)\) and \(g(X)\) are identical when they aren’t?

Claim: If \(f(X) \not= g(X)\), then the probability of the check being successful is at most \(\frac{d}{\lvert\mathbb{F}\rvert}\).

Proof: Let’s set \(P(X) = f(X) - g(X)\). Given that \(f(X) \not= g(X)\), \(P(X)\) isn’t the zero polynomial. As per Schwartz-Zippel, the chance of \(P(r) = f(r) - g(r) = 0\) is at most \(\frac{d}{\lvert\mathbb{F}\rvert}\).

A succinct takeaway from Schwartz-Zippel is: Over large fields, two “low-degree” polynomials are either identical or different almost everywhere.

SUMCHECK protocol proof

The SUMCHECK protocol harnesses this property to convert a sum with a potentially large number of terms into a singular evaluation. Let’s see why it works, by trying to create a prover that attempts to cheat the protocol, attempting to prove a sum \(\tilde S \not= S\).

Round 1

The prover needs to send a polynomial \(\tilde f_1(X)\) with the property \(\tilde f_1(0) + \tilde f_1(1) = \tilde S\). Any other choice would make the first check fail immediately, so there would be no point.

Since \(\tilde S \not= S\), the prover cannot send the honest polynomial \(f_1(X)\). Recall that this means that the polynomial they will be sending is different almost everywhere from \(f_1(X)\); more precisely, it is the same as \(f_1\) on at most \(d\) points.

The verifier then sends the challenge \(r_1\).

Round 2

In round 2, the prover needs to send a polynomial \(\tilde f_2(X)\) with the property that \(\tilde f_2(0) + \tilde f_2(1) = \tilde f_1(r_1)\).

Now there are two possibilities:

• \(\tilde f_1(r_1)= f_1(r_1)\). In this case the prover has hit the jackpot: He can simply send \(f_2(X)\) (the “honest” answer) and continue the protocol honestly to the end. He will succeed at cheating. However, the probability for this happening is only \(\frac{d}{\lvert\mathbb{F}\rvert}\).
• \(\tilde f_1(r_1) \not= f_1(r_1)\) (which is overwhelmingly likely). In this case, the prover is in the same situation as before: He cannot send the honest \(f_2(X)\), but only a malicious \(\tilde f_2(X)\) with \(\tilde f_2(0) + \tilde f_2(1) = \tilde f_1(r_1)\), which can coincide with the honest answer on at most \(d\) points.

This repeats every round:

Round \(i\)

In round \(i\), the prover needs to send a polynomial \(\tilde f_i(X)\) with the property that \(\tilde f_i(0) + \tilde f_i(1) = \tilde f_{i-1}(r_{i-1})\).

Again, two possibilities:

• \(\tilde f_{i-1}(r_{i-1}) = f_{i-1}(r_{i-1})\). Prover wins (probability of this happening \(\frac{d}{\lvert\mathbb{F}\rvert}\)).
• \(\tilde f_{i-1}(r_{i-1}) \not= f_{i-1}(r_{i-1})\). Prover needs to send \(\tilde f_i(X)\) with \(\tilde f_i(0) + \tilde f_i(1) = \tilde f_{i-1}(r_{i-1})\)

Final check

Finally, in the last round, the verifier checks if \(f(r_1, \ldots, r_n)=f_n(r_n)\). Assuming the prover didn’t “win” in one of the rounds before, he sends a malicious \(\tilde f_n(X)\) which coincides with the honest \(f_n(r_n)\) on at most \(d\) points, so the probability that the final check will pass is \(\frac{d}{\lvert\mathbb{F}\rvert}\).

As you can see from the above analysis, the prover has a small probability of “winning” and cheating the verifier in each round: If his polynomial happens to have the same evaluation on the challenge field element as the honest version, the prover can continue the protocol like an honest prover and the verification will succeed.

However, assuming that the field \(\mathbb{F}\) is large, the probability for this is small. Since there are \(n\) rounds, at best, the prover can succeed with probability \(\frac{nd}{\lvert\mathbb{F}\rvert}\).

Note (2025): Reflexer Labs, the team behind RAI, has wound down active development. The RAI smart contracts remain immutable and operational on-chain, but the project is no longer actively maintained. MakerDAO has also undergone major changes, rebranding to “Sky” and introducing USDS alongside DAI.

RAI – one of the coolest experiments in crypto

I think RAI is one of the coolest experiments in crypto right now. So I thought I’d write my version of an explainer for it, from the perspective that I have introduced in my previous article on Supply and demand for stablecoins. Back when I wrote it, my understanding of RAI was poor. The version of DAI it describes (single-collateral DAI, before the introduction of custodial stablecoins as collateral) is actually very close to RAI, however there is an interesting difference: Instead of applying an interest rate to balances, like DAI does, RAI directly manipulates the redemption price (which is always 1 USD for DAI). I think it’s nice to directly describe this mechanism. If you want to understand more on how Collateralized Debt Positions (CDPs) work to maintain stability, then I still recommend reading my previous article!

Why is RAI floating, and not tracking one currency?

In the past, the goal of creating stablecoins was seen as creating an asset that is always worth 1 USD (or some other currency). But as Vitalik remarked in his thought experiments on automated stablecoins, if you can create a coin that is always worth 1 USD, why can’t you use the same mechanism to create one that is worth 1 USD plus 20% interest per year (i.e. 1.00 USD in year 1, 1.20 USD in year 2, 1.44 USD in year 3, and so on)? After all, the only way the blockchain knows about prices is through oracles, and it’s an easy change to the oracle to make it return the value of the coin priced in this new unit (USD appreciating by 20% per year) instead of USD.

Clearly there is something missing in the picture. As we will see below, in order to balance supply and demand, a fully decentralized stablecoin needs to be able to give incentives to those going long (using the stablecoin) and going short (supplying the stablecoin) in some form. This is true whether it tracks USD, USD+20% interest or USD-5% interest.

One way of doing this is to add a mechanism rate that charges interest on debt (the suppliers of the stablecoin) and credits it to the holders (the users of the stablecoin). The interest rate can however be negative when there is more demand for holding than there is for stablecoin debt.

In March 2020, DAI first depegged upward (the market price increased to more than 1 USD) and only repegged after USDC (a custodial, centralized stablecoin pegged to 1 USD) was added as one of the forms of collateral to mint DAI, otherwise it would have required a negative interest rate. Since its inception, RAI has mostly had negative interest rates. For now, it seems like decentralized stablecoin require negative interest rates most of the time.

When interest rates are negative, instead of having your balance change from 1 to 0.99 to 0.98, RAI keeps the balance the same and changes the actual price target of the stablecoin instead. This means that RAI looks like a floating currency, but with the property that it is much less volatile than cryptos like Ether and Bitcoin.

The stablecoin problem

Cryptocurrencies are volatile. Apart from scaling, this is probably still the largest barrier to adoption. This is why there have been many attempts to create a coin that is less volatile.

Like any commodity, the price of a stablecoin is determined by supply and demand. At any instant, some people want to buy and sell the coin, and these inflows and outflows must be matched, so the price will adjust until they do (the price where they match is the market price). Market makers will try to cover short term spikes in supply or demand, but will adjust their quote prices if they see consistent pressure in one direction.

So if you want to keep a coin stable, you have to be able to somehow manipulate supply and demand such that they cross at a desired price. If the current price is too high, it’s easy to create more supply and push the price down. The trouble comes when the coin falls below the desired price (more outflows than inflows): We need to either decrease supply or increase demand, but how do we do that if the supply comes from independent holders wanting to sell?

There is only one decentralized and sustainable option that I know of. It requires saving during the good times in order to be able to create demand in the bad times: In order for new stablecoins to be created, enough collateral for has to be added to the protocol, so that when demand decreases, this collateral can be used to generate new demand.

Collateralized debt positions

Creating stablecoins by means of Collateralized Debt Positions (CDPs) is a way in which this can be implemented. A CDP is a position where a holder of a volatile currency, such as Ether, takes out a loan in the stablecoin. The CDP represents this position. It can also be seen as a leverage position in the collateral. For example, this graph represents a CDP that has 200 RAI borrowed against 1 ETH, where the value of 1 ETH is currently 1400 USD and 1 RAI is 3 USD; the holder of the CDP gets the “equity” value of this position (currently 1400-600=800 USD, but it can fluctuate with the price), and the RAI holder the debt (which is independent of the current price of Ether).

How can CDPs create demand? Some protocols do this directly by allowing stablecoin holders to redeem against the collateral, this is for example how Liquity works. However, RAI follows MakerDAO’s original DAI in not integrating such a mechanism. But CDPs can still generate demand:

1. While the CDP is well collateralized, charging an interest rate to the debt holder can incentivize them to take action in relation to their CDP. For example, if the interest rate on debt increases, a CDP holder may decide that holding on to the position is no longer worth it, and that it’s better to repay the debt. When they do this, they have to buy the stablecoin on the market, which creates demand.
2. Once the CDP gets close to the liquidation ratio, the holder is incentivized to close the position to avoid the liquidation penalty, unless they can add more collateral. If the position gets liquidated, the liquidator will also have to buy stablecoins in order to bid for the collateral.

By only ever issuing new stablecoins in the form of debt when a CDP is created, the protocol has all the collateral in the CDPs to prop up the coin when other demand for stablecoin collapses.

This construction comes with a counterintuitive downside: New coins can only be created when someone is willing to take out a CDP. This requires someone who wants to take a leveraged position in the collateral.

This demand is currently the limiting factor for stablecoins based on this construction. In order to stop the stablecoin from increasing in value due to limited supply of willing CDP holders (in other words, demand for leverage), we will have to do one of two things:

1. Make the leveraged position more attractive to the CDP holders
2. Make holding the stablecoin less attractive

What we can do is that we charge the stablecoin holders a negative interest rate, which is paid out to the CDP holders. This actually does both: It increases the attractiveness of leveraged positions, and makes holding the stablecoin less attractive.

Margin exchanges have done this for a while: They too have to find this balance, as every long position has to be matched to a short position, so that the net exposure is equal to the deposited assets. They use the same mechanism to balance the books: The funding rate is paid by the type of position for which there is more demand to the side that for which there is less.

How RAI balances supply and demand

We have just learned that one mechanism to achieve the balance between CDPs (stablecoin shorts) and holders (stablecoin longs) is an interest rate transfer between the two. DAI implements this mechanism using the DAI savings rate: you can put your DAI into the savings contract and you get paid an interest.

Things become more awkward when the interest rate is negative, i.e. DAI holders are paying to CDP holders. In this regime, DAI balances would have to be slowly decreasing. Implementing it in this way has the advantage that your balance always represents the value in USD, and 1 DAI remains worth 1 USD. It’s less good for smart contract developers who now have to deal with the fact that balances in an account can decrease.

Instead, RAI goes a different way: Adjust the “redemption price” to represent the interest rate. What’s the redemption price? It’s the target value of 1 RAI. In particular it is used

1. To borrow RAI in CDPs and to repay debt, as well as determine whether a position is underwater and should be liquidated
2. As the value at which all debts and deposits are settled when global settlement is triggered.

Since the interest rate is applied to the redemption price, it is called redemption rate. As an example, if the redemption rate is -3% and the redemption price is currently 1.00 USD, then in 1 year the redemption price will be 0.97 USD (RAI actually started with a redemption price of 3.14 USD).

Now when such a negative redemption rate is applied, two things will happen:

1. RAI holders will expect to have 3% less value when compared to holding USD after one year
2. RAI borrowers (who buy RAI back on the market) will expect their debt to decrease in value by 3% after one year

How does RAI determine the redemption rate

Another cool component of RAI is that the redemption rate is actually automatically computed by the protocol. The protocol detects the supply and demand imbalance by tracking the deviation of the market price from the redemption price. If the market price is higher than the redemption price, it means there is more demand for RAI than there is for CDPs – and so a negative redemption rate has to be applied. Conversely, if the market price is lower than the redemption price, the redemption rate needs to be be positive.

So a very simple design could look like this: Find the current difference between the redemption price and the market price, multiply it by some number – for simplicitly say 1, and make that the redemption rate. Say the current redemption price is 4% under market, then the redemption rate will be -4%. If it is 10% above, the redemption rate will be +10%.

If we did this, it would constitute a P controller (P for proportional), which is actually what RAI did initially. RAI’s adjustment mechanism was later updated to use a PI controller that takes the difference between market and redemption prices (the error) as an input. A PI controller, in addition to the current value, also uses the integral (I), so takes into consideration how much the value has deviated in the past. This makes the system more stable and means interest rates fluctuate a bit less with short term price changes.

The RAI website shows the history of RAI redemption price and market price, as well as the interest rates, which can be a nice demonstration of how this mechanism works

On top, you can see the market (red) and redemption prices (grey). The market price is typically above the redemption price, representing excess demand for RAI over CDPs, which the protocol compensates by applying a negative redemption rate – this is why the redemption price is slowly decreasing.

The lower graph shows how the redemption rate is computed. the blue curve (p_rate) is the P part of the PI controller. It is proportional to the error and indeed, the graph looks like the inverted difference between the red and grey curves in the upper graph. The orange curve (i_rate) is much smoother and represents the I part (integral) of the controller, which reacts to past deviations. The sum of the p_rate and the i_rate is the redemption rate and is how fast the redemption price is going down at any given time.

The higher the market price is above the redemption price, the faster the redemption price thus decreases – rebalancing supply and demand as the expected value of holding RAI decreases (and RAI debt becomes more attractive).

But what pulls RAI back to the redemption price

There’s one thing we skipped over. The redemption price represents the target value of RAI in the protocol, and we’ve just been taking it for granted that lowering the price will make long RAI positions less attractive and short positions more attractive. But this assumes that market participants have some expectation of being able to use RAI at or near the redemption price – which requires some force that pulls the market at least in the direction of the redemption price, so that lowering the redemption price has a meaning.

Of course, we can expect “global settlement” will solve this: There is a mechanism in the protocol, which can be triggered by governance, that settles all deposits and debts according to the current redemption price. It is expected that this mechanism will be triggered when the deviations become too extreme. So maybe that’s the reason why the redemption price matters?

Actually, the global settlement is a cool emergency feature, but it is not necessary to explain why the market price will track the redemption price, assuming (some) rational market participants (with enough capital).

Let’s assume that market participants just ignore the redemption price entirely. What would happen?

1. The current minimal collateralization for CDPs is 135%. What that means is that if the market price is more than 35% above the redemption price, anyone can just mint RAI for Ether and “forget” about their CDP – just sell the RAI, buy more Ether with it and take the arbitrage profit. RAI can’t trade significantly more than 35% above redemption price for this reason.
2. There is no strict bound like this from below – but we can do a thought experiment: Let’s say that RAI trades consistently 10% below redemption price. Note that this would lead to an enormous redemption rate of something like 240% per year (in the long term, when the integral term has had enough time to accumulate). CDP holders have to take this redemption rate into account – eventually they will get liquidated, when their collateralization ratio (which is computed using redemption price) reaches 135%. They thus have a strong incentive to buy RAI before this happens.
3. Similarly, we can find that if RAI trades 10% above the redemption price, the negative interest rate will reach something crazy like -70% (again in the long term, when the integral term has had enough time to accumulate this), which means there is a very strong incentive for RAI holders to get out before this happens. If they don’t, lots of newly minted RAI from new CDPs will eventually be available at the much lower redemption price.

Combined, these forces mean that while the market price can deviate, it cannot deviate too far and too long from the redemption price.

How does tracking another currency change RAI?

An interesting question is: How would RAI be different if instead of tracking USD, it had been set up to track the Euro, the Chinese Yuan, or maybe the 6 months moving average of the Ether price?

To start with, we will do a thought experiment (one proposed by Vitalik): What if RAI was set up to track USD + 20% (a version of the USD that comes with a 20% interest rate)? Let’s call this asset RAI-PONZI.

Obviously holding this asset seems really attractive and having debt in that asset much less so. The price of RAI-PONZI will keep rising as buyers want the high interest rates and there are few people available wanting to take out CDPs in RAI-PONZI.

As RAI-PONZI rises above the redemption price, the redemption rate will get more and more negative. It will reach -20%, which makes RAI-PONZI equivalent to USD. From there, it will likely go even further: Currently RAI’s redemption rate is about -10%, so I would expect RAI-PONZI to settle at -30% in current market conditions. At that point, it becomes equivalent to current RAI, so it makes sense that market participants would behave in this way, assuming the same risk tolerance of market participants.

This is actually nothing else than creating an “offset” in the redemption rate of +20%, and an equivalent price offset.

What can we learn from this? The long-term expected gains or losses of a currency do not impact how RAI behaves. If RAI were pegged to Turkish Lira, which seems to lose about 25% of its value compared to the USD every year, it would probably not behave too differently on long timescales. Let’s call this asset RAI-TRY.

Where RAI-TRY is different is on short timescales and unexpected shocks. If the Lira suddenly drops 20%, due to a black swan, then RAI-TRY will do so, too. The same goes for a sudden increase.

What exact currency is used as an input to the RAI oracles therefore probably does not matter that much. It is likely that most major currencies like EUR or GBP will result in a very similar asset, except that it will react slightly differently under market shocks. This is because any expectation in different performance will just be corrected by market participants (so if they expect that GBP will lose 1% per year vs USD, they will just correct for it by picking a different redemption rate).

Why do I think RAI is such a cool experiment?

There have been many attempts to solve the decentralized stablecoin problem. MakerDAO with DAI was probably the first that solved a major part of the puzzle – how to stop it from crashing to zero in a confidence crisis. However, it turned out that they had still missed one part, which is how to stop it from going up.

Finally, RAI came and added this missing piece in a slightly unexpected way – whilst many had been expecting a DAI with negative interest rate, doing it via the redemption rate adjustment is much more elegant. And at the same time, it allows us to learn a lot:

First and foremost, the point of a stablecoin is not to be pegged to USD. It is to provide an asset with low volatility. RAI does indeed solve this task, and has much lower volatility than the underlying collateral, Ether.

RAI therefore is something like a new currency, which is underlined by the fact that it doesn’t really matter that much which fiat currency is used for the oracles, as long as it is reasonably stable. In fact you can change the reference asset while the system is working without much of a problem.

Secondly, the current market structure dictates that if users want a decentralized stablecoin, they have to pay a “price for stability”, in the form of a slowly decaying price of RAI (vs the USD). This is because there is a lot of demand for stablecoins, and limited demand for leverage on decentralized assets like Ether. While it currently feels like this might be an eternal truth, it does not have to be. It could be that this balance tips in the favour of stablecoins again in a bull market, as demand for leverage increases. However, before that happens, it is likely that we would have to see MakerDAO shrug off all of its custodial stablecoin exposure (in order to get their funding rates off zero), which currently seems a long way off.

What I love about RAI is that it is a completely fair way to determine the “price of stability”, and also much cleaner than others. I have posited in my past article on stablecoins that the price of stability isn’t currently fairly determined – and that if it were, it may well be a negative interest rate. Many see inflation as a scourge, but the reality is that having a “guaranteed stable asset” as we implicitly expect currencies to be has to be paid for by someone. If that price were determined using a market like it is in RAI, what would it be?

At least in the decentralized world, we now have an answer, that the price is typically higher than the 2% inflation allowed for by many central banks. Obviously, the number of assets that can be used as collateral in decentralized stablecoins is small, and the result in the real world may well be different. After all, there are 100s of trillions of collateral available, compared to currently less than one trillion in crypto assets.

RAI is, in many ways, central banking in a pure form. We will probably learn many things from this experiment, and that already makes it a worthwhile project.

Note (2025): This post was written before The Merge (September 2022). The Merge has since happened successfully. The Ethereum community has made significant progress on client diversity: Prysm no longer holds a 2/3 supermajority on the consensus side, and the execution client landscape has diversified beyond Go-ethereum. The analysis and incentive arguments in this post remain valid, and client diversity continues to be important.

TL;DR: For reasons of both safety and liveness, Ethereum has chosen a multi-client architecture. In order to encourage stakers to diversify their setups, penalties are higher for correlated failures. A staker running a minority client will thus typically only lose moderate amounts should their client have a bug, but running a majority client can incur a total loss. Responsible stakers should therefore look at the client landscape and choose a less popular client.

Why do we need multiple clients?

There are arguments why a single client architecture would be preferable. Developing multiple clients incurs a substantial overhead, which is the reason why we haven’t seen any other blockchain network seriously pursue the multi-client option.

So why does Ethereum aim to be multi-client? Clients are very complex pieces of code and likely contain bugs. The worst of these are so called “consensus bugs”, bugs in the core state transition logic of the blockchain. One often quoted example of this is the so-called “infinite money supply” bug, in which a buggy client accepts a transaction printing arbitrary amounts of Ether. If someone finds such a bug and isn’t stopped before they get to the exit doors (i.e. making use of the funds by sending them through a mixer or to an exchange), it would massively crash the value of Ether.

If everyone runs the same client, stopping this requires manual intervention, because the chain, all smart contracts and exchanges will keep running as usual. Even a few minutes could be enough to execute a successful attack and sufficiently disperse the funds to make it impossible to roll back only the attacker’s transactions. Depending on the amount of ETH printed, the community would likely coordinate on rolling back the chain to before the exploit (after having identified and fixed the bug).

Now let’s have a look at what happens when we have multiple clients. There are two possible cases:

1. The client with the bug represents less than 50% of the stake. The client will produce a block with the transaction exploiting the bug, printing ETH. Let’s call this chain A.

   However, the majority of stake running a non-faulty client will ignore this block, because it is invalid (to them the printing ETH operation is simply invalid). They will build an alternative chain B that does not contain the invalid block.

   Since the correct clients are in the majority, chain B will accumulate more attestations. Hence, even the buggy client will vote for chain B; as a result chain B will accumulate 100% of the votes and chain A will die. The chain will continue as if the bug never happened.

2. The majority of stake uses the buggy client. In this case, chain A will accumulate the majority of votes. But since B has less than 50% of all attestations, the offending client will never see a reason to switch from chain A to chain B. We will thus see a chain split.

Case 1 is the ideal case. It would most likely lead to a single orphaned block which most users wouldn’t even notice. Devs can debug the client, fix the bug, and everything is great. Case 2 is clearly less than ideal, but still a better outcome than if there’s only a single client – most people would very quickly detect that there is a chain split (you can do this automatically by running several clients), exchanges would quickly suspend deposits, Defi users could tread carefully while the split is resolved. Basically, compared to the single client architecture, this still gives us a big flashing red warning light that allows to protect against the worst outcomes.

Case 2 will be much worse if the buggy client is run by more than 2/3 of the stake, in which case it would be finalizing the invalid chain. More on that later.

Some people think a chain split is so catastrophic that in itself it is an argument for a single-client architecture. But note that the chain split only happened because of a bug in the client. With a single client, if you wanted to fix this and return the chain back to status quo ante, you would have to roll back to the block before the bug happened – that’s just as bad as the chain split! So as bad as a chain split sounds, in the case where there is a critical bug in a client, it’s actually a feature, not a bug. At least you can see that something is seriously wrong.

Incentivising client diversity: anti-correlation penalties

It is clearly good for the network if the stake is split across multiple clients, with the best case being each client owning less than 1/3 of the total stake. This will make it resilient against a bug in any individual client. But why would stakers care? If there aren’t any incentives by the network, it’s unlikely that they will take on the cost of switching to a minority client.

Unfortunately we can’t make rewards directly dependent on what client a validator runs. There is no objective way to measure this that can’t be spoofed.

However, you can’t hide when your client has a bug. And this is where anti-correlation penalties come in: The idea is that if your validator does something bad, then the penalty is higher if more validators make a mistake around the same time. In other words, you get punished for correlated failures.

In Ethereum, you can currently get slashed for two behaviours:

1. Signing two blocks at the same height
2. Creating a pair of slashable attestations (surround or double votes)

When you get slashed, you don’t usually lose all your funds. At the time of this writing (Altair fork), the default penalty is actually quite small: You would only lose 0.5 ETH, or about 1.5% of your staked Ether (ultimately this will be increased to 1 ETH or 3%).

However, there is a catch: There is an additional penalty that is dependent on all other slashings that occur during the 4096 epochs (18 days) before and after your validator was slashed. You are further penalized by an amount that is proportional to the total amount slashed during this period.

This can be a much larger penalty than the initial penalty. Currently (Altair fork) it is set so that if more than half of the full staking balance got slashed during this period, then you will lose all your funds. Ultimately this will be set so that you will lose all of your stake if 1/3 of other validators got slashed. 1/3 was chosen because this is the minimum amount of the stake that has to equivocate in order to create a consensus failure.

The other anti-correlation penalty: The quadratic inactivity leak

Another way a validator can fail is by being offline. Again there is a penalty for it, but its mechanism is very different. We do not call it slashing, and it’s usually small: Under normal operation, a validator that is offline is penalized by the same amount that they would be gaining if they were validating perfectly. At the time of this writing, this is 4.8% per year. It is probably not worth breaking a sweat if your validator is offline for a few hours or days, for example due to a temporary internet outage.

It becomes very different when more than 1/3 of all validators are offline. Then the beacon chain cannot finalize, which threatens a fundamental property of the consensus protocol, namely liveness.

To restore liveness in a scenario like this the so-called “quadratic inactivity leak” kicks in. The total penalty amount raises quadratically with time if a validator continues being offline while the chain is not finalizing. Initially it is very low; after ~4.5 days, the offline validators will lose 1% of their stake. However, it increases to 5% after ~10 days and to 20% after ~21 days (these are Altair values, they will be doubled in the future).

This mechanism is designed so that in the case of a catastrophic event that annihilates a large number of validator operations, the chain will eventually be able to finalize again. As the offline validators lose larger and larger parts of their stake, they will make up a smaller and smaller share of the total, and as their stake drops below 1/3, the remaining online validators gain the required 2/3-majority, allowing them to finalize the chain.

However, there is another case where this becomes relevant: In certain cases, validators cannot vote for the valid chain anymore because they accidentally locked themselves into an invalid chain. More on this below.

How bad is it to run the majority client?

In order to understand what the dangers are, let’s take a look at three failure types:

1. Mass slashing event: Due to a bug, majority-client validators sign slashable attestations
2. Mass offline event: Due to a bug, all majority-client validators go offline
3. Invalid block event: Due to a bug, majority-client validators all attest to an invalid block

There are other kinds of mass failures and slashings that can happen, but I’m restricting myself to those related to client bugs (the ones you should consider when choosing which client to run).

Scenario 1: Double signing

This is probably the most feared scenario by most validator operators: A bug leading the validator client to sign slashable attestations. One example would be two attestations voting for the same target epoch, but with different payloads. Because it is a client bug, it’s not just one staker that is concerned, but all stakers that run this particular client. When the equivocations are detected, the slashings will be a bloodbath: All concerned stakers will lose 100% of their staked funds. This is because we are considering a majority client: If the stake of the concerned client were only 10%, then “only” about 20% of their stake would be slashed (in Altair; 30% with the final penalty parameters in place).

The damage in this case is clearly extreme, but I also think it is extremely unlikely. The conditions for slashable attestations are simple, and that’s why validator clients (VCs) were built to enforce them. The validator client is a small, well audited piece of software. A bug of this magnitude is unlikely.

We have seen some slashings so far, but as far as I know all of them where due to operator failures – almost all of them resulting from an operator running the same validator in several locations. Since these aren’t correlated, the slashing amounts are small.

Scenario 2: Mass offline event

For this scenario, we assume that the majority client has a bug, which when triggered, leads to a crash of the client. An offending block has been integrated into the chain, and whenever the client encounters that block, it goes offline, leaving it unable to participate any further in consensus. The majority client is now offline, so the inactivity leak kicks in.

Client developers will scramble to get things back together. Realistically within hours, at most in a few days, they will release a bug fix that will remove the crash.

In the meantime, stakers also have the option to simply switch to another client. As long as enough do this to get more than 2/3 of all validators online, the quadratic inactivity leak will stop. It is not unlikely that this will happen before there is a fix for the buggy client.

This scenario is not unlikely (bugs that lead to crashes are one of the most common types), but the total penalty would probably be less than 1% of the stake affected.

Scenario 3: Invalid block

For this scenario, we consider the case where the majority client has a bug that produces an invalid block, and also accepts it as valid – i.e. when other validators using the same client see the invalid block, they will consider it as valid, and hence attest to it.

Let’s call the chain that includes the invalid block chain A. As soon as the invalid block is produced, two things will happen:

1. All correctly functioning clients will ignore the invalid block and instead build on the latest valid head producing a separate chain B. All correctly working clients will vote and build on chain B.
2. The faulty client considers both chain A and B valid. It will thus vote for whichever of the two it currently sees as the heaviest chain.

We need to distinguish three cases:

1. The buggy client has less than 1/2 of total stake. In this case, all correct clients vote and build on chain B eventually making it the heaviest chain. At this point even the buggy client will switch to chain B. Other than one or a few orphaned blocks, nothing bad will happen. This is the happy case, and why it is great to only have sub-majority clients.

2. The buggy client has more than 1/2 and less than 2/3 of the stake. In this case, we will see two chains being built – A by the buggy client, and B by all other clients. Neither chain has a 2/3-majority and therefore they cannot finalize. As this happens, developers will scramble to understand why there are two chains. As they figure out that there is an invalid block in chain A, they can proceed to fix the buggy client. Once it is fixed, it will recognize chain A as invalid. It will thus start building on chain B, which will allow it to finalize. This is very disruptive for users. While hopefully the confusion between which chain is valid will be short and less than an hour, the chain probably won’t finalize for many hours, potentially even a day. But for stakers, even the ones running the buggy client, the penalties would still be relatively light. They will receive the “inactivity leak” penalty for not participating in chain B while they were building the invalid chain A. However, since this is likely less than a day, we are talking of a penalty that’s less than 1% of the stake.

3. The buggy client has more than 2/3 of the stake. In this case, the buggy client will not just build chain A – it will actually have enough stake to “finalize” it. Note that it will be the only client that will think that chain A is finalized. One of the conditions of finalization is that the chain is valid, and to all other correctly operating clients, chain A will be invalid. However, due to how the Casper FFG protocol works, when a validator has finalized chain A, they can never take part in another chain that is in conflict with A without getting slashed, unless that chain is finalized (for anyone interested in the details, see Appendix 2). So once chain A has been finalized, the validators running the buggy client are in a terrible bind: They have committed to chain A, but chain A is invalid. They cannot contribute to B because it hasn’t finalized yet. Even the bugfix to their validator software won’t help them – they have already sent the offending votes. What will happen now is very painful: Chain B, which is not finalizing, will go into the quadratic inactivity leak. Over several weeks, the offending validators will leak their stake until enough has been lost so that B will finalize again. Let’s say they started off with 70% of the stake – then they would lose 79% of their stake, because this is how much they would need to lose in order to represent less than 1/3 of the total stake. At this point, chain B will finalize again and all stakers can switch to it. The chain will be healthy again, but the disruption will have lasted weeks, and millions of ETH were destroyed in the process.

Clearly, case 3 is nothing short of a catastrophe. This is why we are extremely keen not to have any client with more than 2/3 of the stake. Then no invalid block can ever be finalized, and this can never happen.

Risk analysis

So how do we evaluate these scenarios? A typical risk analysis strategy is to evaluate the likelihood of an event happening (1 – extremely unlikely, 5 – quite likely) as well as the impact (1 – very low, 5 – catastrophic). The most important risks to focus on are those that score high on both metrics, represented by the product of impact and likelihood.

Looking at this, by far the highest priority is scenario 3. The impact when one client is in a 2/3 supermajority is quite catastrophic, and it is also a relatively likely scenario. To highlight how easily such a bug can happen, a bug of this sort happened recently on the Kiln testnet (see Kiln testnet block proposal failure). In this case, Prysm did detect that the block was faulty after proposing it, and did not attest to it. Had Prysm considered that block as valid, and this had happened on mainnet, then we would be in the catastrophic case described in case 3 of scenario 3 – because Prysm currently has a 2/3 majority in mainnet. So if you are currently running Prysm, there is a very real risk that you could lose all your funds and you should consider switching clients.

Scenario 1, which people are probably most worried about, received a relatively low rating. The reason for this is that I consider the likelihood of it happening to be quite low, because I think that the Validator Client software is very well implemented in all clients and it is unlikely to produce slashable attestations or blocks.

What are my options, if I currently run the majority client and I’m worried about switching?

Switching clients can be a major undertaking. It also comes with some risks. What if the slashing database is not properly migrated to the new setup? There might be a risk of getting slashed, which completely defeats the purpose.

There is another option that I would suggest to anyone who is worried about this. It is also possible to leave your validator setup exactly as it is (no need to take those keys out etc.) and only switch the beacon node. This is extremely low risk because as long as the validator client is working as intended, it will never double sign and thus cannot be slashed. Especially if you have large operations, where changing the validator client (or remote signer) infrastructure would be very expensive and might require audits, this may be a good option. Should the setup perform less well than expected, it can also be easily switched back to the original client or another minority client can be tried.

The nice thing is that you have very little to worry about when switching your beacon node: The worst thing it can do to you is to be temporarily offline. That’s because the beacon node itself can never produce a slashable message on its own. And you can’t end up in scenario 3 if you’re running a minority client, because even if you would vote for an invalid block, that block would not get enough votes to be finalized.

How about the execution clients?

What I have written above applies to the Consensus clients – Prysm, Lighthouse, Nimbus, Lodestar and Teku, of which at the time of writing, Prysm likely has a 2/3 majority on the network.

All of this applies in the same way to the execution client. Should Go-ethereum, likely to be the majority execution client after the merge, produce an invalid block, it could get finalized and thus cause the catastrophic failure described in scenario 3.

Luckily, we now have three other execution clients ready for production – Nethermind, Besu and Erigon. If you are a staker, I highly recommend running one of these. If you are running a minority client, the risks are very low! But if you run the majority client, you are at serious risk of losing all your funds.

Appendix

A1: Why is there no slashing for invalid blocks?

In Scenario 3, we have to rely on the quadratic inactivity leak to punish validators for proposing and voting for an invalid block. That’s strange – why don’t we just punish them directly? It would be faster and less painful to watch.

There are actually two reasons why we don’t do this – one is that we currently can’t, but even if we could, we may well not do it:

1. Currently, it is practically impossible to introduce a penalty (“slashing”) for invalid blocks. The reason for this is that neither the beacon chain nor the execution chain are currently “stateless” – i.e. in order to check whether a block is valid, you need a context (the “state”) that is 100s of MB (beacon chain) or GB (execution chain) large. This means there is no “concise proof” that a block is invalid. We need such a proof to slash a validator: The block that “slashes” a validator needs to include a proof that the validator has made an offence. There are ways around this without having a stateless consensus, however it would involve much more complex constructions such as multi-round fraud proofs, such as Arbitrum is currently using for their rollup.

2. The second reason why we might not be that eager to introduce this type of slashing even if we could, is because producing invalid blocks is a much harder thing to protect against than the current slashing conditions. The current conditions are extremely simple and can be validated easily in a few lines of code by validator clients. This is why I consider scenario 1 above so unlikely – slashable messages have so far only been produced by operator failures, and I think that’s likely to remain the case. Adding slashing for producing invalid blocks (or attesting to them) raises the risks for stakers. Now even those running minority clients could risk serious penalties.

In summary, we are unlikely to see direct penalties for invalid blocks and/or attestations to them for the next few years.

A2: Why can’t the buggy client switch to chain B once it has finalized chain A?

This section is for anyone who wants to understand in more detail why the buggy client can’t just switch back and has to suffer the horrendous inactivity leak. For this we have to look how Casper FFG finalization works.

Each attestation contains a source and a target checkpoint. A checkpoint is the first block of an epoch. If there is a link from one epoch to another which has a total of >2/3 of all stake voting for it (i.e., there are this many attestations with the first checkpoint as the “source” and the second checkpoint as the “target”), then we call this a “supermajority link”.

An epoch can be “justified” and “finalized”. These are defined as follows:

1. Epoch 0 is justified
2. An epoch is justified if there is a supermajority link from a justified epoch.
3. An epoch X is finalized if (1) the epoch X is justified and (2) the next epoch is also justified, with the source of the supermajority link being epoch X

Rule 3 is slightly simplified (there are more conditions under which an epoch can be finalized, but they aren’t important for this discussion). Now let’s come to the slashing conditions. There are two rules for slashing attestations. Both compare a pair of attestations V and W:

1. They are slashable if the target of V and W is the same epoch (i.e. the same height), but they don’t vote for the same checkpoint (double vote)
2. They are slashable if V “jumps over” W. What this means as that (1) the source of V is earlier than the source of W and (2) the target of V is later than the target of W (surround vote)

The first condition is obvious: It prevents simply voting for two different chains at the same height. But what does the second condition do?

Its function is to slash all validators that take part in finalizing two conflicting chains (which should never happen). To see why, let’s look at our scenario 3 again, in the worst case where the buggy client is in a supermajority (>2/3 of the stake). As it continues voting for the faulty chain, it will finalize the epoch with the invalid block, like this:

The rounded boxes in this picture represent epochs, not blocks. The green arrow is the last supermajority link created by all validators. The red arrows are supermajority links that were only supported by the buggy client. Correctly working clients ignore the epoch with the invalid block (red). The first red arrow will justify the invalid epoch, and the second one finalizes it.

Now let’s assume that the bug has been fixed and the validators that finalized the invalid epoch would like to rejoin the correct chain B. In order to be able to finalize the chain, a first step is to justify epoch X:

However, in order to participate in the justification of epoch X (which needs a supermajority link as indicated by the dashed green arrow), they would have to “jump over” the second red arrow – the one that finalized the invalid epoch. Voting for both of these links is a slashable offense.

This continues to be true for any later epoch. The only way it will get fixed is through the quadratic inactivity leak: As chain B grows, the locked out validators will leak their funds until chain B can be justified and finalized by the correctly working clients.

In this blog post I will try to help understand how the exponential version of EIP-1559 works – the one that was suggested for the Shard Blob EIP.

I’m not going to try to explain how the EIP-1559 mechanism works – good explainers already exist, for example by Barnabé Monnot.

Linear EIP-1559 mechanics (“original version”)

I will call the current implementation of EIP-1559 the “linear version” of EIP-1559.

In the linear version, we define the constants

Each block \(B_i\) has a base fee of \(b_i\) and total gas consumed in the block of \(g_i\). There is an update rule for the Basefee:

There is also a constraint that the maximum amount of gas per block can’t be more than \(2 T\). However, this limit is not important in the scope of this post so I will ignore it.

Exponential EIP-1559

One way to understand this “linear EIP-1559” better is to compute what happens after many updates. In particular, how does \(b_n\) depend on \(b_0\)? By substituting the equation into itself many times, we get

Now let’s say that \(A\) is a large number, so that all the terms of the form \(\frac{1}{A}\frac{g_i - T}{T}\) are small? Let’s call \(x_i = \frac{g_i - T}{T}\).

If we assume this, we can use an approximation: The exponential function \(e^x \approx 1+x\) for small \(x\). We use this approximation in the inverse to replace \(1+\frac{x_i}{A} = e^{\frac{x_i}{A}}\) to get

For the last step, we have used the property that \(e^x \cdot e^y = e^{x+y}\). Note that

so we get this new formula for \(b_n\)

where we used \(G_n = \sum_{i=0}^{n-1}g_i\) for the total gas used since block 0 and \(T_n = nT\) the cumulative gas target.

This is the exponential form of EIP-1559. The only thing we need to keep track of to compute the basefee current \(b_n\) is (1) the total gas used, which is \(G_n = \sum_{i=0}^{n-1}g_i\), and the total gas target, which is represented by \(T_n = nT\) (so it’s enough to just count the number of blocks).

Analyzing the exponential form

Here is a question I have heard many times about exponential EIP-1559: Isn’t the goal of EIP-1559 that in the long term, the total gas used \(G_n\) equals to the gas target \(T_n\)?

And if so, if you evaluate the equation for \(G_n = T_n\), the exponential becomes one and thus \(b_n = b_0\). So if the target is achieved, then the basefee would always be \(b_0\) (which is typically very low)?

Here I will explain why this is not the case. Let’s see how this happens in linear EIP-1559 first. Here is a very simple economic model: Let’s assume a there is a “fair price” for gas at price \(p\). For simplicity assume that below \(p\), demand is infinite: All blocks will be filled. Above \(p\), blocks will be empty. And when the base fee is equal to \(p\), then there will be exactly enough demand to fill the blocks to half.

So what will happen in this model in linear EIP-1559?

• We assume that the base fee starts of low with \(b_0 < p\).
• Then there will be a number of \(n_0\) blocks where the basefee is lower than \(p\), which will be completely full by our assumption.
• When the basefee reaches \(p\) at \(n_0\), all futher blocks will be filled to target.

To keep things simple, say the max block size is exactly \(2T\). Then how much gas has been used at any block \(n>n_0\)? It would be \(G_n = 2 n_0 T + (n - n_0) T = n_0 T + n T = T_n + n_0 T\). So it is actually not exactly the target, despite the EIP-1559 mechanism now being in equilibrium.

What happened? Note that it is still correct to say that EIP-1559 will ensure \(G_n \approx T_n\); for example, if you take the fraction \(\frac{G_n}{T_n}\), it will tend to \(1\) so in asymptotic notation we would write \(G_n \sim T_n\).

But there is a constant difference between \(G_n\) and \(T_n\), which is the amount of gas that was needed to shift the basefee from \(b_0\) to \(p\).

More generally, the current difference between \(G_n\) and \(T_n\) is a constant determined by the current basefee. In the linear version, this is approximately true; in the exponential version, it is exactly true (it follows directly from the definition \(b_{n} = b_0 \exp\left(\frac{1}{TA}\left(G_n - T_n\right)\right)\))

Graphical illustration

First let’s look at our simplified example. The following graph illustrates what is happening: Above you see the relation between total gas used and the basefee (an exponential function). Once in equilibrium, the basefee is at \(p\) which means that \(G_n-T_n = n_0 T\). Below we see how this adds up. The green shaded area of gas used is the blocks filled up to the target, and the orange area is the gas used above the target that sums up to \(n_0 T\).

Next we look at a generic example, where some blocks are filled with more than target gas and some blocks are below. In this case, we need to sum up all the gas consumed by each block above the target (marked in green) and substract the gas that was below the target in underfull blocks (marked with red and white diagonal stripes). We can then read the sum on the \(x\) axis of the basefee relation to determine the basefee \(b_n\).

Appendix: Using differential equations to derive the exponential form

Here is another way of deriving the exponential form, using differential equations:

Let’s start from the update rule of linear EIP-1559

We can rewrite this as

This is mathematically a difference equation. This is similar to a differential equation, but for finite differences. However, we can “approximate” it as a differential equation, by changing \(i\) into a continuous variable and writing

where we use that \(b(i)-b(i+1) \approx b'(i)\). You could say that this form comes about naturally if you assume that we are making the blocks smaller and smaller, scaling the target as well. As the size of the blocks goes towards zero, we get the differential equation.

This is a linear ordinary differential equation of first order that can be solved by moving the terms depending on \(b\) to one side:

Integrating on both sides yields:

This is because

So we can exponentiate and get

Since we want \(b(0)=b_0\) we get \(C=\ln b_0\) and so

This looks almost the same that we derived above – except we now have an integral instead of a sum, because we are working with the continuous form.

The exponential version thus arises naturally when you consider very small blocks and update the basefee each time. From this perspective, it is the most natural way of implementing EIP-1559.

翻译：Star.LI @ Trapdoor Tech

介绍

你也许听说过“BulletProofs”：它是一种零知识证明算法，不要求可信设置。比如，门罗币（Monero）就用了这个算法。这种证明系统的核心是内积证明¹，一个能让证明者向验证者证明“内积“正确性的小技巧。内积，即是计算两个向量中每个分量的乘积和：

其中 \(\vec a = (a_0, a_1, \ldots, a_{n-1})\), \(\vec b = (b_0, b_1, \ldots, b_{n-1})\)。

一个比较有趣的例子就是当我们设置向量 \(\vec b\) 为某个 \(z\) 的幂，即 \(\vec b = (1, z, z^2, \ldots, z^{n-1})\)，那么它的内积就变成了多项式

在 \(z\) 点的取值。

内积证明采用Pedersen承诺。我之前写过一篇文章介绍KZG承诺，Pedersen承诺与其类似，承诺值也是在椭圆曲线上的，不同的是它不需要可信设置。下面比较这两个多项式承诺方案(PCS)，KZG承诺方案 和 Pedersen承诺与内积证明相结合的方案:

说到底，和KZG承诺相比，我们这个承诺方案的效率要低一些。证明大小更大（\(O(\log n)\)），不过对数本身还是挺小的，所以不至于太糟。但可惜的是验证者需要做的计算是线性的, 这失去了简洁性。这些局限使得 Pedersen 承诺对于某些应用来说不太现实，但在一些情况下这些缺点可以被规避。

• 其中一个例子我在之前的文章多重打开中曾经提到过。这里的诀窍是你可以将多个打开聚合成一个。
• Halo2 ², 其中多个打开的线性成本可以被聚合。

在以上这两个例子中，特点就是多个打开的成本被分摊了。如果你只想打开一个多项式，那就比较困难了，你需要承担整个打开的运算成本。

但是，Pedersen 承诺与内积证明结合的方案，很大的好处是较少的安全假设。也就是，不需要配对，并且不需要可信设置。

Pedersen 承诺

在我们讨论内积证明之前，我们要先看一下依赖的结构：Pedersen承诺。为了使用Pedersen承诺，我们需要一个椭圆曲线 \(G\)。让我们首先回顾一下我们使用椭圆曲线可以做到哪些事情（在这里我会使用加法符号表示，看起来更自然一些）：

1. 你可以将两个椭圆曲线点 \(g_0 \in G\) 和 \(g_1 \in G\) 相加: \(h = g_0 + g_1\)
2. 你可以将元素\(g \in G\)与一个标量\(a \in \mathbb F_p\)相乘，其中\(p\)是\(G\)椭圆曲线的阶 (即元素数量): \(h=ag\)

无法计算两个曲线元素的“乘积”：“\(h * h\)”运算是未定义的，所以你没办法计算“\(h * h = a g * a g = a^2 g\)”；与此相反，与标量相乘是很容易计算的，比如 \(2 h = 2 a g\)。

另一个重要的性质就是不存在有效的计算“离散对数”的算法，这意味着对于满足\(h = a g\)的给定的\(h\)和\(g\)，如果你不知道\(a\)，\(a\)是不可计算的，我们称\(a\)为\(h\)对于\(g\)的离散对数。

Pedersen承诺则利用该不可计算性来构造承诺方案。假设有两个点\(g_0\)和\(g_1\)，它们的离散对数(比如存在\(x \in \mathbb F_p\)使得\(g_1 = x g_0\))并不可知，那么我们可以向两个数\(a_0, a_1 \in \mathbb F_p\)提交承诺:

\(C\)为椭圆曲线\(G\)的一个元素。

为打开一个承诺，证明者给验证者\(a_0\)和\(a_1\)，然后验证者计算\(C\)，如果相等的话就被接受。

承诺方案的中心性质在于它是不是绑定（binding）。给定\(C=a_0 g_0 + a_1 g_1\)，一个试图作弊的证明者是否能够生成\(b_0, b_1 \in \mathbb F_p\)并使验证者接受它们，即同时满足\(C = b_0 g_0 + b_1 g_1\) 且\(b_0, b_1 \not= a_0, a_1\)。

如果有人能做到上述行为的话，那么它们也可以找出离散对数。为什么呢？我们知道\(a_0 g_0 + a_1 g_1 = b_0 g_0 + b_1 g_1\)，整理后可得

所以\(a_0 − b_0\)和\(b_1 − a_1\)不可同时为0。假说\(a_0 − b_0\)不为零，我们得到：

对于\(x = \frac{b_1 - a_1}{a_0 - b_0}\)。这样我们就找到了\(x\)的值。我们知道该问题是难题，所以在现实中没有攻击者能够做到。

这意味着对于攻击者来说找到另外的\(b_0 , b_1\)来打开承诺\(C\)在计算性上是不可能的。（它们的确存在，只是无法通过计算获得 – 就像哈希碰撞）。

我们可以扩展一个向量的承诺，比如说一个标量列表\(a_0, a_1, \ldots, a_{n-1} \in \mathbb F_p\)。我们只是需要一个“基”，即一个相等数量的互相未知离散对数的群元素，然后我们就可以计算承诺了：

这给了我们一个向量承诺，尽管这个承诺相对复杂：为了打开任意元素，必须打开所有的元素。但这里有一个重要的性质：这个承诺方案是加同态的，这意味着如果我们有另外一个承诺\(D = b_0 g_0 + b_1 g_1 + b_2 g_2 + \ldots + b_{n-1} g_{n-1}\)，那么我们可能可以通过添加两个承诺得到两个向量\(\vec a\) 和 \(\vec b\)的和:

因为有了加同态的性质，这个向量承诺就变得有用了。

内积证明

内积证明的基本策略是“分治法”：将一个问题规约成多个同类型的子问题，而不是试图一步完全解决它。当子问题规约到一定程度的时候，就可以简单解决。

在这当中每一步，问题的大小都会减半。这保证了\(\log n\)步后，问题大小会减少到1，可以通过简单证明解决。

假设我们需要证明的承诺 \(C\) 具有以下形式：

其中 \(\vec g = (g_0, g_1, \ldots, g_{n-1}), \vec h = (h_0, h_1, \ldots, h_{n-1})\) ，且 \(q\) 是我们的“基”，即：它们是群 \(G\) 中的元素，并且它们之间对于任意一方的离散对数都未知。同时介绍一种新的表示方法：\(\vec a \cdot \vec g\)，一个由标量组成的向量（\(\vec a\)）和另一个由群元素组成的向量（\(\vec g\)）的乘积，我们将其定义为

也就是说，我们要证明 \(C\) 是以下元素的承诺

• 基为 \(\vec g\) 的向量 \(\vec a\)
• 基为 \(\vec h\) 的向量 \(\vec b\)
• 基为 \(q\) 的内积 \(\vec a \cdot \vec b\) 。

单看本身似乎并不是很有用 – 在大多数应用中我们想让验证者知道 \(\vec a \cdot \vec b\)，而不是仅仅将这个结果藏在一个承诺里。这可以通过我后面要讲到的一个小技巧来解决。

证明

我们想让证明者向验证者证明 \(C\) 的确具有形式 \(C = \vec a \cdot \vec g + \vec b \cdot \vec h + (\vec a \cdot \vec b) q\)。就像之前提到的，不是直接证明，而是要把这个问题规约成，如果这一性质对于另一个承诺 \(C′\) 成立，则 \(C\) 也满足该性质。

接下来证明者就要和验证者玩一个小游戏了。证明者提交一些信息，然后验证者发起一个挑战，从而引出下一个承诺 \(C′\)。将它称作一个游戏不代表这个证明必须是交互的：Fiat-Shamir算法允许我们通过将挑战换成一个承诺的抗碰撞哈希值，从而将交互式的证明转化成非交互式的。

证明描述

承诺 \(C\) 符合 \(C = \vec a \cdot \vec g + \vec b \cdot \vec h + (\vec a \cdot \vec b) q\) 的形式，并且以\(\vec g, \vec h, q\)为基。我们将符合这样形式的 \(C\) 称为拥有“内积性质”。

规约步骤

假设 \(m = \frac{n}{2}\), 证明者计算

这里我们定义 \(\vec a_L\) 为向量 \(\vec a\) 的“左半部”，\(\vec a_R\) 为“右半部”，向量 \(\vec b\) 类似。

然后证明者计算如下的承诺：

并发送给验证者。然后验证者发送挑战 \(x \in \mathbb F_p\) (通过使用Fiat-Shamir将它变成非交互式的，这意味着 \(x\) 是 \(C_L\) 和 \(C_R\) 的哈希)。证明者以此来计算更新的向量：

长度为原向量的一半。

现在，验证者计算新的承诺：

还有更新的基：

现在，如果新的承诺 \(C′\) 符合了 \(C' = \vec a' \cdot \vec g' +\vec b' \cdot \vec h' + \vec a' \cdot \vec b' q\)的形式 - 那么承诺\(C\)就遵从最初的假设，拥有“内积性质”。

所有的向量大小都减半 – 这让我们离成功又近一步。在这里我们替换 \(C:=C'\), \(\vec g := \vec g'\)，\(\vec h := \vec h'\) 并重复以上步骤。

接下来我解释这个方法可行的数学原理，同时推荐你们去看看 Vitalik 所做的一个漂亮的可视化展示 以得到一些直观的感受。

最终步骤

当我们一直重复以上步骤，n每次降低一半。最终我们会到达\(n=1\)，然后就可以停下了。这时证明者发送\(\vec a\)和\(\vec b\)两个向量，事实上就是两个标量，然后验证者就可以非常直观地计算：

如果等于 \(C\) 就接受，反之则拒绝。

正确性(correctness) 及合理性(soundness)

在之前我假设 \(C′\) 为我们所需要的形式，然后以此证明 \(C\)也成立。现在我要证明为什么该逻辑成立。我们需要验证以下两点：

• 正确性 – 即当证明者遵从相应操作的时候，它们可以达到说服验证者该结论为正确的目的；
• 合理性 – 即试图作弊的证明者不能使用错误的证明通过验证者验证，或者成功率低至可忽略不计。

让我们从正确性证起，假设证明者依照操作进行每一个步骤。既然如此，我们知道给定 \(\vec g, \vec h, q\) 为基，\(C = \vec a \cdot \vec g + \vec b \cdot \vec h + (\vec a \cdot \vec b) q\)，同时 \(C'= \vec a' \cdot \vec g' +\vec b' \cdot \vec h' + \vec a' \cdot \vec b' q\)。

验证者计算\(C' = x C_L + C + x^{-1} C_R\)。

为了使承诺具有内积属性，我们需要验证 \((x \vec a_R + \vec a_L) \cdot (\vec b_L + x^{-1} \vec b_R) = x z_L + \vec a \cdot \vec b + x^{-1} z_R\)。这个等式成立，因为

这样正确性就证明了。为证明合理性，我们需要证明，证明者的初始承诺 \(C\) 不具有内积属性，那么通过规约步骤，是无法产生一个具有内积属性的承诺 \(C'\)。

假设证明者提交了 \(C=\vec a \cdot \vec g + \vec b \cdot \vec h + r q\)，其中 \(r \neq \vec a \cdot \vec b\)。如果我们走一遍如上的规约步骤，我们会得到

所以现在我们假设证明者成功作弊，那么 \(C′\) 就满足了内积属性，则有：

展开左侧可得

注意证明者可以自由选择 \(z_L\) 和 \(z_R\)，所以我们不能直接假设它们会遵从以上定义。

同时乘以 \(x\) 并移到同一边，我们得到 \(x\) 的二次方程式：

除非所有项都为零，该等式至多会有两个解 \(x \in \mathbb F_p\)，但是验证者是在证明者已经承诺了他们的 \(r\), \(z_L\) 和 \(z_R\)值后选择 \(x\)值，证明者能够成功作弊的概率非常小；我们通常选择域 \(\mathbb F_p\) 大小约为 \(2^{256}\)。因此，当证明者不按照协议选择正确值时，验证者选择到一个让等式能够成立的 \(x\) 值的概率微乎其微。

这就完成了我们的合理性证明。

仅在最后计算基变化

验证者在每一轮都需要做两件事：计算挑战 \(x\)，并计算更新的基 \(\vec g'\) 和 \(\vec h'\)。但是在每一轮都更新 \(g\) 效率很低，验证者可以简单地保存他们在 \(k\) 轮中遇到的挑战值 \(x_1 , x_2 \dots x_k\)。

假设\(k\)轮后，这些基为 \(\vec g_k, \vec h_k\)。元素\(g_\ell\)和\(h_\ell\)是标量（或者长度为1的向量），因为长度到达1的时候我们会终止协议。通过\(\vec g_0\)计算\(\vec g_\ell\)，是一个长度为n的椭圆曲线上的多标量点乘（MSM）。\(\vec g_0\)的标量因子是下面多项式的系数

且\(\vec h_0\)的标量因子由以下多项式给定

使用内积证明来验证多项式值

针对我们的主要应用 – 验证 \(f(x) = \sum_{i=0}^{n-1} a_i x^i\)在\(z\)处的取值 – 我们需要对协议做一些小的扩充。

• 最重要的一点是，我们想要验证 \(f(z) = \vec a \cdot \vec b\) 的结果，而不仅是承诺 \(C\) 拥有“内积属性”。
• \(\vec b = (1, z, z^2, ..., z^{n-1})\) 对于验证者来说是已知的。因此我们可以把这部分从承诺中移除来简化协议。

如何构造承诺

如果我们想要验证多项式\(f(x) = \sum_{i=0}^{n-1} a_i x^i\)，我们通常需要从承诺\(F = \vec a \cdot \vec g\)开始进行构造。证明者可以将\(y=f(z)\)的计算发送给验证者。

那么貌似验证者可以计算最初的承诺\(C=\vec a \cdot \vec g + \vec b \cdot \vec h + \vec a \cdot \vec b q = F + \vec b \cdot \vec h + f(z) q\)，因为他们已知\(\vec b = (1, z, z^2, ..., z^{n-1})\)，然后开始证明流程。

但稍等一下。大多数情况下，\(F\)是证明者生成的承诺，一个恶意的证明者可以在这里作弊，比如说提交一个\(F = \vec a \cdot \vec g + tq\)。在这种情况下，因为证明者生成的承诺有一个偏移，他们能够证明\(f(z) = y - t\)。

为了避免这种情况，我们需要在证明流程中进行一点改变。 收到承诺\(F\)和计算结果\(y\)后，验证者生成一个向量\(w\)并且重新选择基\(q:=wq\)，之后证明继续。因为证明者不能预判\(w\)的取值，它们就无法成功操控除了\(f(z)\)之外的结果（或者说概率极小）。

注意如果想要得到一个通用的内积，我们还要防止证明者操控向量\(\vec b\) – 但在多项式取值的应用中，\(\vec b\)的部分可以完全去掉不用考虑，因此这里略过细节。

如何去掉第二个向量

注意，如果我们想要进行多项式计算，验证者已知向量\(\vec b = (1, z, z^2, ..., z^{n-1})\)。给定挑战\(x_0, x_1, \ldots, x_\ell\)，他们可以通过在“仅在最终计算基变化”一节中提到的技巧简单地得到\(b_\ell\)。

因此，我们可以从所有承诺中移除第二个向量并且只计算\(b_\ell\)。这意味着验证者必须要能够从初始向量\(\vec b_0 = (1, z, z^2, ..., z^{n-1})\)中计算最终的\(b_\ell\)。因为\(\vec b\)的规约过程与基向量\(\vec g\)相同，线性组合也由之前定义的多项式\(f_g\)的系数定义，也就是说\(b_\ell=f_g(z)\)。

针对点值形式多项式的IPA

目前为止，我们用一个内积证明计算了使用它的系数提交的多项式，即一个由\(f(X) = \sum_{i=0}^{n-1} f_i X^i\)定义的多项式中的\(f_i\)。然而，多数情况下我们想要一个在给定定义域\(x_0, x_1, \ldots, x_{n-1}\)计算值定义的多项式。因为任何阶低于\(n−1\)的多项式都是由\(f(x_0), f(x_1), \ldots, f(x_{n-1})\)的计算结果定义的独一无二的多项式，所以这两者是完全相等的。但是这两者之间的转换在计算上非常费时，如果定义域适用快速傅立叶转换的话需要花费\(O(n \log n)\)次计算，否则就是\(O(n^2)\)次。

为了避免这项开销，我们尝试避免使用多项式系数形式。这可以通过提交多项式值\(f\)的承诺的而不是系数的承诺来实现：

这表示我们IPA的向量\(\vec a\)形式为\(\vec a = (f(x_0), f(x_1), \ldots, f(x_{n-1}))\)：

重心公式 使我们现在可以计算这个新的承诺多项式的取值，记作：

如果我们选择向量\(\vec b\)

我们可以得到\(\vec a \cdot \vec b = f(z)\)，因此采用这种向量的IPA可以被用作证明点值多项式的取值。除了这一点差异之外，其他的证明过程是完全相同的。

翻译：Star.LI @ Trapdoor Tech

简介

今天我想向你们介绍一下Kate，Zaverucha和Goldberg发表的多项式承诺方案 ¹。这篇文章并不涉及复杂的数学及密码学理论知识，仅作为一篇简介。

该方案通常被称作卡特（Kate，读作kah-tay）多项式承诺方案。在一个多项式承诺方案中，证明者计算一个多项式的承诺（commitment）, 并可以在多项式的任意一个点进行打开（opening）：该承诺方案能证明多项式在特定位置的值与指定的数值一致。

之所以被称为承诺，是因为当一个承诺值（椭圆曲线上的一个点）发送给某对象（ 验证者），证明者不可以改变当前计算的多项式。它们只能够对一个多项式提供有效的证明；当试图作弊时，它们要不无法提供证明，要不证明被验证者拒绝。

预备知识

如果你对有限域，椭圆曲线和配对这几个话题不是很熟悉的话，非常推荐去读一读Vitalik Buterin的博客：椭圆曲线配对这篇文章。

默克尔树对比

如果你已经熟知默克尔树，我想在此之上和卡特承诺进行对比。默克尔树即是密码学家所说的矢量承诺：运用一个深度为\(d\)的默克尔树，你可以计算一个矢量的承诺（矢量为一个固定长度的列表\(a_0, \ldots, a_{2^d-1}\)）。运用熟知的默克尔证明，你可以用\(d\)个哈希来提供证明元素\(a_i\)存在于这个矢量的位置\(i\)。

事实上，我们可以用默克尔树来构造多项式承诺：回忆一下，一个\(n\)次的多项式\(p(X)\)，无非是一个函数 \(p(X) = \sum_{i=0}^{n} p_i X^i\)，其中\(p_i\)是该多项式的系数。

通过设置\(a_i=p_i\)，我们可以计算这一系列系数的默克尔树根，从而比较容易地对一个\(n=2^{d}-1\)次的多项式进行承诺。证明一个取值，意味着证明者想要向验证者展示对于某个值z，\(p(z)=y\)。为达到这个目的，证明者可以向验证者发送所有的\(p_i\)，然后验证者计算p(z)是否等于y。

当然，这是一个极度简单化的多项式承诺，但它能帮助我们理解真实的多项式承诺的益处。让我们一起回顾多项式承诺的性质：

1. 承诺的大小是一个单一哈希（默克尔树根）。一个足够安全的加密散列一般需要256位，即32字节。
2. 为了证明一个取值，证明者需要发送所有的\(p_i\)，所以证明的大小和多项式次数是线性相关的。同时，验证者需要做同等的线性量级的计算（他们需要计算多项式在\(z\)点的取值，即计算\(p(z)=\sum_{i=0}^{n} p_i z^i\)）。
3. 该方案不隐藏多项式的任何部分 - 证明者一个系数接一个系数地发送完整的多项式。

现在让我们一起来看看卡特方案是如何达成以上要求的：

1. 承诺大小是一个支持配对的椭圆曲线群元素。比如说对于BLS12_381曲线，大小应是48字节。
2. 证明大小独立于多项式大小，永远是一个群元素。验证，同样独立于多项式大小，无论多项式次数为多少都只要两次群乘法和两次配对。
3. 大多数时候该方案隐藏多项式 - 事实上，无限多的多项式将会拥有完全一样的卡特承诺。但是这并不是完美隐藏：如果你能猜多项式（比如说该多项式过于简单，或者它存在于一个很小的多项式集合中），你就可以找到这个被承诺的多项式。

还有一点，在一个承诺中合并任意数量的取值证明是可行的。这些性质使得卡特方案对于零知识证明系统来说非常具有吸引力，例如PLONK和SONIC。同时对于一些更日常的目的，或者简单的作为一个矢量承诺来使用也是非常有趣的场景，接下来的文章中我们就会看到。

椭圆曲线以及配对

正如之前所提到的预备知识所说，我强烈推荐Vitalik Buterin的博客：椭圆曲线配对。本文包含了本文所需的背景知识：特别是有限域，椭圆曲线和配对相关知识。

假设\(\mathbb G_1\)和\(\mathbb G_2\)是两条满足\(e: \mathbb G_1 \times \mathbb G_2 \rightarrow \mathbb G_T\)的配对，假设p是\(\mathbb G_1\)和\(\mathbb G_2\)的阶，同时G和H是\(\mathbb G_1\)和\(\mathbb G_2\)的生成元。接下来，我们定义一个非常有效的速记符号：对于任意\(x \in \mathbb F_p\) \(\displaystyle [x]_1 = x G \in \mathbb G_1 \text{ and } [x]_2 = x H \in \mathbb G_2\)

可信设置

假设我们已有一个可信设置，使得对于一个秘密s，其子元素\([s^i]_1\)和\([s^i]_2\)都对于任意\(i=0, \ldots, n-1\)的证明者和验证者有效。

有一种方法能够达到这种可信设置：我们用离线计算机生成一个随机数\(s\)，计算所有的群元素\([s^i]_x\)，并通过电线传输出去（不包括\(s\)）,然后烧掉这部计算机。当然这并不是一个好的解决方案，你必须相信计算机的操纵者没有通过其他渠道泄露这个秘密\(s\)。

在实际应用中，这种设置通常采用安全多方计算（MPC），使用一组计算机来创建这个群元素，而没有任何单一计算机知道秘密s，这样只有挟持了整组计算机才能知道s。

注意这里有一件事是不可能的：你不能仅仅选择一个随机群元素\([s]_1\)（其中\(s\)是未知的）然后通过它计算其他的群元素。不知道\(s\)是无法计算\([s^2]_1\)的。

好了，椭圆曲线密码学基础告诉我们通过可信设置的群元素是无法破解\(s\)的，它是有限域\(\mathbb F_p\)中的一个数字，但证明者无法找出它的具体数值。他们只能在给定的元素上做一些特定的计算。举个例子，他们可以用椭圆曲线乘法轻易地计算\(c [s^i]_1 = c s^i G = [cs^i]_1\)，或者说将椭圆曲线点值相加算出\(c [s^i]_1 + d [s^j]_1 = (c s^i + d s^j) G = [cs^i + d s^j]_1\)。实际上如果\(p(X) = \sum_{i=0}^{n} p_i X^i\)是一个多项式，证明者可以计算 \(\displaystyle [p(s)]_1 = [\sum_{i=0}^{n} p_i s^i]_1 = \sum_{i=0}^{n} p_i [s^i]_1\)

这就显得非常有趣 – 通过使用这套可信设置，任何人都可以计算出一个多项式在一个谁也不知道的秘密点s上的值。只是他们得到的输出值不是一个自然数，而是一个椭圆曲线点\([p(s)]_1 = p(s) G\)，这已经足够有用。

卡特承诺

在卡特承诺方案中，元素\(C = [p(s)]_1\)是多项式\(p(X)\)的承诺。

这样你可能会问了，证明者是不是在不知道\(s\)的情况下找到另一个有相同承诺的多项式\(q(X) \neq p(X)\)，使得\([p(s)]_1 = [q(s)]_1\)？我们假设这个推理成立，那么就是说\([p(s) - q(s)]_1=[0]_1\)，即\(p(s)-q(s)=0\)。

\(r(X) = p(X)-q(X)\)本身就是一个多项式。我们知道它不是常数，因为\(p(X) \neq q(X)\)。有一个非常著名的定理，即是任意非常数的\(n\)次多项式至多可以有\(n\)个零点，这是因为如果\(r(z)=0\)，\(r(X)\)就可以被线性因子\(X−z\)整除；因为每一个零点都意味着可以被一个线性因子整除，同时每经过一次除法会降低一阶，所以推理可知至多存在\(n\)个零点²。

因为证明者不知道\(s\)，他们只能通过在尽可能多的地方让\(p(X)−q(X)=0\)来使得\(p(s)−q(s)=0\)。如上所证，他们只能在至多\(n\)个点上使\(p(s)−q(s)=0\)，那么成功的可能性就很小，因为\(n\)比起曲线的次数\(p\)要小很多，\(s\)被选中成为\(p(X)=q(X)\)成立点的概率是微乎其微的。来感受一下这个概率的大小，假设我们采用现有最大的可信设置，当\(n = 2^{28}\)，把它来和曲线顺序\(p \approx 2^{256}\)对比：攻击者设立的多项式\(q(X)\)来与\(p(X)\)尽可能多的重合，\(n=2^{28}\)个点，得到相同承诺（p(s)=q(s)）的概率是\(2^{28}/2^{256} = 2^{28-256} \approx 2 \cdot 10^{-69}\)。这是一个非常低的概率，在现实中意味着攻击者没有办法施行该攻击。

多项式相乘

目前为止我们学习了在一个秘密\(s\)的多项式取值是可计算的，这就使得我们可以对一个独一无二的多项式进行承诺 - 对于同一个承诺\(C=[p(s)]_1\)存在多个多项式，但是在实践中它们其实是无法计算的（这就是密码学家所说的绑定 （computationally binding））。

但是，我们仍缺少在不发送给验证者完整多项式的情况下“打开”这个承诺的能力。为了达到这个目的，我们需要用到配对。如上所述，我们可以对这个秘密进行线性操作；举个例子，我们可以计算\(p(X)\)的承诺\([p(s)]_1\)，还可以通过两个承诺\(p(X)\)和\(q(X)\)来计算\(p(X)+q(X)\)的联合承诺：\([p(s)]_1+[q(s)]_1=[p(s)+q(s)]_1\)。

现在我们所缺少的就是两个多项式的乘法。如果我们做到乘法，就能利用多项式的性质打开更多酷炫玩法的大门。尽管椭圆曲线本身不允许作乘法，幸运的事我们可以通过配对解决这个问题：我们有

\(\displaystyle e([a]_1, [b]_2) = e(G, H)^{(ab)} = [ab]_T\) 在这里介绍一个新的标识方法：\([x]_T = e(G, H)^x\)。这样，尽管我们不能直接在椭圆曲线上直接将两个元素相乘得到它们的乘积，一个椭圆曲线元素（这就是所谓全同态加密/FHE的一个性质；椭圆曲线仅是加同态)。如果是在不同的曲线上（比如一个在\(\mathbb G1\)，另一个在\(\mathbb G2\)上）提交承诺，我们可以将两个字段元素相乘，这样所得到的输出就是一个\(\mathbb G_T\)元素。

这里我们就看到了卡特证明的核心。记得我们之前提到的线性因子：如果一个多项式在\(z\)处有零点，那么它就可以被\(X−z\)整除。同理反向可证 - 如果多项式可以被\(X−z\)整除，那么它必在\(z\)处有零点。可被\(X−z\)整除，意味着对于某个多项式\(q(X)\)我们可得\(p(X)=(X−z)⋅q(X)\)，并且很明显在\(X=z\)处得到零点。

举个例子，我们想要证明\(p(z)=y\)，使用多项式\(p(X)−y\) – 明显该多项式在\(z\)处达到零点，这样我们就可以应用线性因子的知识。取多项式\(q(X)\)，\(p(X)−y\)被线性因子\(X−z\)除，即：

这就等同于\(q(X)(X-z) = p(X)-y\)。

卡特证明

定义\(p(z)=y\)的卡特证明为\(π=[q(s)]_1\)，记得多项式\(p(X)\)的承诺是\(C=[p(s)]_1\).

验证者用如下等式来确认这个证明：

\(\displaystyle e(\pi,[s-z]_2) = e(C-[y]_1, H)\) 注意验证者可以计算\([s−z]_2\)，因为这仅是可信设置的元素\([s]_2\)和多项式被计算的点\(z\)的一个组合。同样的，验证者已知了\(y\)是取值\(p(z)\)，所以他们也可以计算\([y]_1\)。那么为什么上述证明能向验证者证明\(p(z)=y\)，或者更准确地说，\(C\)所提交的多项式在\(z\)点的取值是\(y\)？

这里我们需要考证两个性质：正确性 和 可靠性。 正确性 指的是如果证明者遵循我们定义的步骤，他们就可以产出一个能被验证的证明。这个通常难度不大。还有就是可靠性，这个性质是指证明者不会产出一个“不正确”的证明 – 比如说，他们不会欺骗验证者对于某个\(y′≠y\)，\(p(z)=y′\)。

接下来我们先写出配对组的对应等式： \(\displaystyle [q(s) \cdot (s-z)]_T = [p(s) - y]_T\) 正确性非常一目了然 – 这就是等式\(q(X)(X−z)=p(X)−y\)在一个没人知道的随机点\(s\)的取值。

那么，我们怎么才能知道它的可靠性，证明者不会创建假的证明呢？让我们从多项式的角度来看待这个问题。如果证明者想依循我们的方法来构建一个证明，他们就需要用\(X−z\)来除\(p(X)−y′\)。但是\(p(z)−y′\)并不为零，无论怎么除都会有一个余数，所以他们就无法进行这个多项式除法。这样一来，证明者就无法用这个方法进行伪造了。

剩下的就只能直接在椭圆群中想办法了：如果说对于某个承诺\(C\)，他们可以计算椭圆群元素

\(\displaystyle \pi_\text{Fake} = \frac{1}{s-z} (C-[y']_1)\) 一旦成立，那证明者就可以为所欲为了。感觉上这是很难做到的，你必须用和s相关的什么东西来求幂，但s又是未知的。为了严格证明，你需要针对证明和配对的一个密码学假设，即所谓的\(q\)-strong SDH假设 ³。

多重证明

为这里为止我们已经看到了如何在一个单点上证明一个多项式取值，这是已经是非常了不起的一件事：你可以仅靠发送单个的群元素（可以是48字节大小，例如BLS12_381）来证明任何次数的多项式 - 比如说\(2^{28}\)次 – 在任意点的取值。作为对比，在一个简单的把默克尔树用作多项式承诺的例子中，我们需要发送\(2^{28}\)个元素，即这个多项式所有的系数。

更进一步，我们来看看如何仅使用一个群元素，来计算并证明一个多项式在任意多个点 的取值。首先我们需要了解一个新概念：插值多项式。有一个包含k个点的列表\((z_0, y_0), (z_1, y_1), \ldots, (z_{k-1}, y_{k-1})\)，我们随时都可以找到一个次数小于\(k\)的多项式来经过这些点。其中一个方法是利用拉格朗日插值，这样我们可以得到该多项式的公式I(X)：

\(I(X) = \sum_{i=0}^{k-1} y_i \prod_{j=0 \atop j \neq i}^{k-1} \frac{X-z_j}{z_i-z_j}\) 现在我们假设已知\(p(X)\)经过了所有的点，那么多项式\(z_0, z_1, \ldots, z_{k-1}\)都是零点。这就意味着多项式可被所有的线性因子：\((X-z_0), (X-z_1), \ldots (X-z_{k-1})\)整除，我们将它们组合在一起，称为零多项式：

\(\displaystyle Z(X) = (X-z_0) \cdot (X-z_1) \cdots (X-z_{k-1})\) 我们可以计算商值

\(\displaystyle q(X) = \frac{p(X) - I(X)}{Z(X)}\) 注意，因为\(p(X)−I(X)\)能被\(Z(X)\)所有的线性因子整除，所以它能被\(Z(X)\)本身整除。

现在我们可以定义这个计算\((z_0, y_0), (z_1, y_1), \ldots, (z_{k-1}, y_{k-1})\)的卡特证明：\(\pi=[q(s)]_1\) – 这仍然仅是一个群元素。

为了验证这个证明，验证者同样需要计算插值多项式\(I(X)\)和零多项式\(Z(X)\)，使用这些结果他们可以计算\([Z(s)]_2\)和\([I(s)]_1\)，然后就可以确认配对等式：

\(\displaystyle e(\pi,[Z(s)]_2) = e(C-[I(s)]_1, H)\) 将该等式写成配对，我们可以像单点上的卡特证明一样简单地确认它是否能够成立：

\(\displaystyle [q(s)\cdot Z(s)]_T = [p(s)-I(s)]_T\) 这就非常酷炫了：仅仅提供一个群元素，你就能证明任何数量的计算，甚至是百万个！这相当于通过48个字节来证明海量的计算。

将卡特作为矢量承诺来使用

尽管卡特承诺被设计成多项式承诺，但它作为矢量承诺来使用也大有用处。回忆一下，一个矢量承诺是针对矢量\(a_0, \ldots, a_{n-1}\)的承诺，并且允许你证明任意位置\(i\)对应\(a_i\)。我们可以使用卡特承诺的方案来重现这一场景：使\(p(X)\)为对所有的\(i\)计算 \(p(i)=a_i\)的一个多项式，我们知道这样一个多项式存在，并且可以通过拉格朗日插值来计算它：

\(\displaystyle p(X) = \sum_{i=0}^{n-1} a_i \prod_{j=0 \atop j \neq i}^{n-1} \frac{X-j}{i-j}\) 使用这个多项式，我们可以就可以利用一个单一群元素来证明这个矢量中任意数量的元素！注意到比起默克尔树（在证明大小方面）这个方案更加高效：仅证明一个元素，默克尔证明就需要花费\(\log n\)大小的哈希！

延伸阅读

为了得到一个无状态版本的以太坊，我们正在积极探索卡特承诺的应用。在这里我强烈建议在ethresearch论坛中使用关键字Kate来搜索你感兴趣的话题。

另一篇很赞的博文是Vitalik的introduction to PLONK，其中大量运用到了多项式承诺，其中卡特方案就是多项式承诺实现的主要方案。

A proof of custody is a construction that helps against the “lazy validator” problem. A lazy validator is a validator that instead of doing the work they are supposed to do – for example, ensuring that some data is available (relevant for data sharding) or that some execution was performed correctly (for execution chains) – they pretend that they’ve done it and sign the result, for example an attestations that claims the data is available anyway.

The proof of custody construction is a cryptoeconomic primitive that changes the game theory so that lazy validating simply isn’t an interesting strategy anymore.

Lazy validators – the game theory

Let’s assume there is a well-running Ethereum 2.0 chain (insert your favourite alternative PoS blockchain if you prefer). We don’t usually expect that bad things – data being withheld, invalid blocks being produced happens. In fact, you are likely to not see them ever happen, because as long as the system is run by a majority of honest validators there is no point in even trying to attack it in one of these ways. Since the attack is pretty much guaranteed to fail, there is no point in even doing it.

Now assume you run a validator. This comes with different kinds of costs – obviously the staking captial, but also hardware costs, electricity and internet bandwidth, which you might pay for directly (your provider charges you per GB) or indirectly (when your validator is running, your netflix lags). The lower you can make this cost, the more net profits you make from running your validator.

One of the tasks you do as a validator in sharded Eth2, is to assure the availability of shard data. Each attestation committee is assigned one blob of data to check, which is around 512 kB to 1 MB. The task of each validator is to download it and store it for around 90 days.

But what happens if you simply sign all attestations for shard blobs, without actually downloading the data? You would still get your full rewards, but your costs have suddently decreased. We are assuming the network is in a good state, so your laziness isn’t going to do anything to the network immediately. Let’s say your profit of running a validator was $1 per attestation, and the cost of downloading all the blocks was $0.10 per year. Now your profit has increased to $1.10.

This problem is called the verifier’s dilemma and was introduced in Demystifying Incentives in the Consensus Computer by Luu et al.

But I would never do this! Who would cheat like that?

It often seems obvious to us that in games like this, surely you would not succumb to bribery and stay with the honest behaviour. But it’s often more subtle than that.

Let’s assume that after having run a validator for years, a new client comes out that claims to be 10% more cost effective. People run it and see that it works, and it seems to be safe. The way it actually does this is by not downloading the shard blocks.

This could even happen by accident. Someone cut some corners in the development process, everything looks normal, it’s just that it doesn’t join the right shard subnet and nobody missed this, because it does not cause any faults in normal operation.

Some people will probably run this client.

Something else that could happen is that a service could step in to do the downloading for you. For $0.01 per shard blob, they will download the data, store it for 90 days, and send you a message that the data is available and you can sign the attestation. How bad is this?

It’s also quite bad. Because as many people start using this service, it becomes a single point of failure. Or even worse, it could be part of an attack. If it can make more than 50% of validators vote for the availability of a shard blob, without ever publishing the blob, that would be a withholding attack.

As it is often the case, dishonesty can come in many disguises, so our best bet is to work on the equilibrium to make the honest strategy rational.

A proof of custody and an update to the game theory

The proof of custody works like this: Imagine we can put a “bomb” in a shard blob: If you sign this blob, you get a large penalty (you get slashed), of $3,000. You definitely don’t want to sign this blob.

Does that make you want to download it? That is certainly one way to avoid signing the bomb. But if anyone can detect the bomb, then someone can simply write a service that warns you before signing an attestation if it’s a bomb. So the bomb needs to be specific to an individual validator, and noone else can compute whether a shard blob is a bomb.

OK, now we have the essential ingredients for the proof of custody. We need

1. An ephemeral secret, that is recomputed every custody epoch (ca. 90 days), individual to each validator, and then revealed when it has expired (so that other validators have a chance to check the proof of custody)
2. A function that takes the whole shard blob data, as well as the ephemeral key, and outputs 0 (not a bomb), or, with very small probability, 1 (this blob is a bomb)

It is essential that the ephemeral secret isn’t made available to anyone else, so there are three slashing conditions:

1. A validator can get slashed if anyone knows its current ephemeral secret
2. The ephemeral secret has to be published after the custody period, and failing to do so also leads to slashing
3. Signing a bomb leads to slashing

How can we create this function? A simple construction works like this. Compute a Merkle tree of leaves (data0, secret, data1, secret, data2, secret, ...) as illustrated here:

Then take the logical AND of the first 10 bits. This gives you a single bit that’s 1 in an expected 1 in 1024 times.

This function cannot be computed without knowing both the secret and the data.

(Because we do want to enable secret shared validators, a lot of work has gone into optimizing this function so that it can be efficiently computed in an MPC, which a Merkle tree cannot. For this we are suggesting a construction based on a Universal Hash Function and the Legendre symbol: https://ethresear.ch/t/using-the-legendre-symbol-as-a-prf-for-the-proof-of-custody/5169)

New game theory

All right, so with the proof of custody, any shard blob has a 1/1,024 chance of being a bomb, and you don’t know which one it is without downloading it.

The lazy validator does just fine when the blob is not a bomb. However, when it is a bomb, we see the big difference: The honest validator simply skips this attestation, which is very minor an simply sets the profit to zero. However, the lazy validator signs it and will get slashed, making a huge loss. The payoff matrix now looks like this:

In the third column, we see that the expected profit for the lazy validator is now negative. Since the whole reason for being lazy was increased profits from lower costs, this means that the lazy validator is not an interesting strategy anymore.

Proof of custody for execution

Another task of validators will be verifying the correct execution of blocks. This means verifying that the new stateroot that is part of a block is the correct one that results from applying all the transactions. The proof of custody idea can also be applied to this: The validator will have to compute the proof of custody in the same way as described above, however the data is the execution trace. The execution trace is some output generated by the step by step execution of the block. It does not have to be complete in any sense; what we want from it is just two properties:

1. It should be difficult to guess the execution trace without actually executing the block.
2. The total size of the execution trace should be large enough that simply distributing it in addition to normal blocks is unattractive.

There are some easy options of doing this; for example simply outputting every single instruction byte that the EVM executes would probably result in an execution trace of a few MB per execution block. Another option would be to use the top of the stack.

With fraud proofs, do we still need the proof of custody for execution?

When we upgrade the execution chain to statelessness, which means that blocks can be verified without having the current state, fraud proofs become easy. (Without statelessness, they are hard: Fraud proofs always have to be included on a chain different from the one where the fraud happened, and thus the actual pre-state would not be available when they have to be verified.)

This means that it will be possible to slash a validator who has produced an invalid execution block. Furthermore we can also penalize any validator that has attested to this block. Would that mean that the proof of custody is no longer necessary?

It does certainly shift the balance. But even with this penalty present, lazy validation can still be a rational strategy. It would probably be a bad idea for a validator to simply sign every block without verifying execution, as an attacker only needs to sacrifice a single validator of their own to get you slashed.

However, you can employ the following strategy: On each new block, you wait for some small percentage of other validators to sign it before you sign it yourself. Those who sign it first are unlikely to be lazy validators, as they would be employing the same strategy. This would get you quite good protection in most situations, but at a systemic level it would still leave the chain vulnerable in extreme cases.

The case with fraud proofs is thus improved, but a proof of custody remains superior for ensuring that lazy validation can’t be a rational strategy.

How is it different from data availability checks?

I wrote a primer on data availability checks here. It looks like the proof of custody for shard blobs tries to solve a very similar problem: Ensuring that data that is committed to in shard blob headers is actually available on the network.

So we may wonder: Do we need both a proof of custody and data availability checks?

There is an important difference between the two constructions, though:

• Data availability checks ensure the availability of the data independent of the honest majority assumption. Even a powerful attacker controlling the entirety of the stake can’t trick full nodes into accepting data is available that is actually withheld
• In contrast, a proof of custody does not help if the majority of the stake is performing an attack. The majority can compute the proof of custody without ever releasing the data to anyone else.

So in a theoretical sense, data availability checks are strictly superior to proof of custody for shard data: They hold unconditionally, whereas the latter only serve to keep rational validators honest, making an attack less likely.

Why do we still need a proof of custody for shard blobs? It might not necessarily be needed. There are however some practical problems with data availability checks that make it desirable to have a “first line of defence” against missing data:

The reason for this is that data availability checks work by excluding unavailable blocks from the fork choice rule. However, this cannot be permanent: data availability checks only ensure that eventually, everyone will see the same result, but not immediately.

The reason for this is that publishing a partially available block, might result in some nodes seeing it as available (they are seeing all their samples) and some other nodes as unavailable (missing some of the samples). Data availability checks ensure that in this situation, the data can always be reconstructed. However, this needs some node to first get enough samples to reconstruct the data, and then re-seed the samples so everyone can see them; this process can take a few slots.

In order to avoid a minority attacker (with less than 1/3 of the stake) to cause such a disruption, we only want to apply data availability checks when the chain is finalized and not immediately. In the meantime, the proof of custody can ensure that an honest majority will only ever build an available chain, where the shard data is already seeded in committees; since the committees are ready to re-seed all samples even if the original blob producer doesn’t, an attacker can’t easily force a partially available block.

In this construction, the proof of custody and data availability checks have two orthogonal functions:

1. The proof of custody for shard data ensures that an honest majority of validators will only ever build a chain in which all shard data is available and well seeded across committees. A minority attacker cannot easily cause disruption to this.
2. Data availability checks will guarantee that even if the majority of stake is attacking, they will not be able to get the remaining full nodes to consider a chain with withheld data as finalized.