a16z: 8 Challenges in Blockchain Mechanism Design

Original Title: “8 reasons why blockchain mechanism design is hard”

Author: Tim Roughgarden, Head of Research at a16z crypto

Translated by: 0xxz, Jinse Finance

An in-depth study of a field teaches you to recognize that the problems that arise in the real world are merely poor disguises of those that have been properly solved. For example, when I teach the fundamentals of algorithms, students learn how to identify problems that reduce to shortest path calculations or linear programming.

This pattern matching is equally effective in mechanism design, which is a form of "reverse game theory" that uses incentives to achieve desired outcomes. The tools and lessons of mechanism design are particularly useful in auction theory, market design, and social choice theory.

Crypto and web3 are rife with mechanism design problems. One might think that many issues can be solved by applying textbook content and making new adjustments to old ideas. However, the unique challenges and constraints of permissionless blockchain protocols often force people to rethink the fundamental principles of seemingly resolved issues. This complexity makes mechanism design in web3 fascinating.

In this article, I will explore some of the challenges faced by mechanism design in web3. These challenges may be familiar to crypto-native users, but a deeper understanding of mechanism design should provide all builders with a new perspective on why solving these problems is so difficult. For mechanism designers, if you are thinking about new applications, you may be interested in the challenges posed by permissionless environments.

But first, we need to know: what is mechanism design?

The field of mechanism design can be traced back at least to 1961, when Columbia University economist and later Nobel laureate William Vickrey formally proposed the second-price sealed-bid auction. This auction format had been used as early as 1797 when author Johann Wolfgang von Goethe sold the manuscript of his epic "Hermann and Dorothea," and it was widely used by philatelists in the 19th century, but it wasn't formally proposed by Vickrey until 1961, now commonly referred to as the "Vickrey auction." In the Vickrey auction model, the highest bidder wins but pays the second-highest bid. This auction format elicits bidders' true preferences and delivers the item to the highest-valued bidder.

The Vickrey auction is an elegant and efficient design that has been applied in the real world, adjusting and updating according to new circumstances, with practice informing theory and vice versa. Like the Vickrey auction, the development of mechanism design as a formal discipline is a history interwoven with theory and practice, both profound and beautiful.

In contrast to game theory—which establishes the dimension of strategic interaction and explores the most rational outcomes of behavior—the field of mechanism design does not start with games but with desired outcomes. The goal of mechanism design is to reverse-engineer some form of game to achieve the desired outcome (characterized perhaps by efficiency, fairness, or certain behaviors). In the case of the Vickrey auction, the ultimate goal is to attract participants to pay the maximum amount they are willing to pay without punishing them.

There are many opportunities for applying mechanism design in web3. For example, a blockchain protocol may wish to achieve outcomes where protocol participants behave honestly (without deviating from expected behavior). Alternatively, the protocol may want to obtain accurate information about transaction values to effectively allocate block space to the most valuable transactions.

Such mechanism design problems are always challenging, and the challenges in a blockchain environment are even more unique.

1. Lack of Trust

Without a trusted party to enforce the mechanism, design in the blockchain space becomes more difficult.

The whole point of using permissionless blockchain protocols is that you do not have to trust any single entity or individual; you only need an "average level" trust assumption that there are enough honest nodes among those running the protocol.

But the irony of many blockchain architectures is that every batch of transactions added to the chain's history, which must be executed in the virtual machine maintained by the protocol, is the product of unilateral decisions made by individual nodes.

You cannot be sure whether you can trust this node.

This is why Vickrey auctions are rarely seen in the blockchain space. Implementing a Vickrey auction naively will quickly encounter the problem of untrusted block producers manipulating the auction. The issue is that a block producer can create a "shill bid," a fake bid slightly lower than the bid that is about to win, forcing the winner to pay nearly their entire bid (rather than the true second-highest bid).

The fake bids from untrusted block producers effectively revert the Vickrey auction back to a first-price auction model, which is one reason why first-price auctions are so prevalent in web3. (A recent branch of traditional mechanism design literature concerning "trusted mechanisms" also considers auction design with untrusted auctioneers, but from a different angle.)

2. Occasional Collusion

Another reason mechanism design is difficult in blockchain is that participants may collude with each other. For instance, second-price auctions can easily be colluded with compensation payments. The reasoning is simple: since the winner pays the second-highest bid, bidders can bribe the second-highest bidder to bid much lower.

The academic literature on mechanism design has not overly concerned itself with this issue. One reason may be that collusion (especially collusion with compensation payments) is difficult to achieve in the real world. After colluding, the winner can simply refuse to pay the bribe, making it hard to obtain credible compensation payments. (As the saying goes, "There is no honor among thieves.")

However, in the blockchain context, potential colluders can often use smart contracts to provide credible commitments, allowing collusion to work effectively. A second reason is the lack of mechanisms to deter collusion with compensation payments—such as a "price announcement" mechanism that only provides bids and nothing else.

Worse still, protocol users may not only collude with each other but also with (untrusted) block producers (analogous to collusion between bidders and auctioneers in real-world auctions).

Resistance to this last form of collusion is one of the main motivations behind the burn portion of the Ethereum EIP-1559 transaction fee mechanism. Without "burning" (or otherwise withholding these revenues from block producers), block producers and end users could collude through compensation payments and evade any reserve prices that the mechanism attempts to impose.

3. Cannot Rely Solely on the Rule of Law

The collusion problem is clearly not a new one. It has plagued various mechanisms in real life for centuries, but if you look at the mechanism design literature, you may be surprised to find that it has hardly addressed this issue. These literatures do discuss the motivations for individual participants to unilaterally manipulate mechanisms, but they often leave the problem to some unmanifested concept of "the rule of law." For example, participants in the mechanism might sign a legal contract stipulating that they will not collude. If collusion is discovered, it would be referred to legal channels. Mechanism designers can help by creating mechanisms that make collusion relatively easy to detect.

There is an unspoken secret in much of the mechanism design literature: reliance on the rule of law. While we cannot say that there is no rule of law in the realm of permissionless blockchain protocols—we often see law enforcement successfully prosecuting criminal behavior on permissionless blockchains—the degree of rule of law is much less than in traditional mechanism design applications.

If you cannot rely on the rule of law outside the mechanism, then designers have the responsibility to solve the problem within the mechanism. This approach is prevalent in the decision-making of mechanism design in the blockchain space. Particularly in the Ethereum protocol, examples abound, from the EIP-1559 burning of base fee revenues to penalizing validators for misconduct in its consensus protocol.

4. Larger Design Space

The design space in web3 is larger than what mechanism designers are accustomed to. Therefore, designers must rethink all given problems. For example, many mechanisms involve payments, which in traditional mechanism design applications would be made in fiat currencies like dollars. Many blockchain protocols have their own native currencies, and the mechanisms within these protocols can manipulate these currencies.

Imagine if you wrote a traditional mechanism design paper where part of your mechanism description was: "Mint a bunch of new currency and distribute it to a group of participants." Outside the context of blockchain, this seems absurd. But when discussing mechanism design in the context of a blockchain protocol, you can do just that. The protocol controls the currency, so part of the mechanism can mint or burn tokens.

This means that some designs that would be impossible without a native currency become possible. For example, how do you incentivize Bitcoin miners to execute the protocol as expected? Through inflationary rewards: minting new coins (Bitcoin) to incentivize these block producers. Such designs would not be feasible without a native currency.

5. Native Currency May Bring Other Issues

The previous point emphasizes the power of native currencies. You can do two things with native currencies: "minting" (as in the Bitcoin protocol minting new bitcoins to incentivize miners) and "burning tokens" (as in the Ethereum EIP-1559 transaction fee mechanism burning ETH to deter collusion). Native currencies harbor dangers that do not exist in traditional mechanism design: microeconomic design decisions can have macroeconomic consequences.

In traditional mechanism design, there is no reason to worry about macroeconomic forces. Traditional auction methods do not have meaningful impacts on the money supply or inflation rate in the U.S. This presents a new challenge for the web3 design space. What problems might arise? Let me tell you two examples, one about Bitcoin minting and one about ETH burning.

Due to the use of block rewards—motivating miners through minting new coins—Bitcoin is forced to experience inflation. Therefore, it must also have corresponding monetary policies to determine the inflation rate and how that rate evolves over time. Satoshi Nakamoto also set a hard supply cap of 21 million bitcoins. Since the number of bitcoins has a hard cap, the inflation rate must approach zero.

If the inflation rate is truly zero, what should be used to incentivize miners to continue running the protocol and securing Bitcoin? People have long hoped that transaction fees could compensate for the missing block rewards, although the chances of this happening are quite slim. It is well known that if transaction fees approach zero, the Bitcoin protocol will suffer significant security issues.

Princeton University computer scientists Miles Carlston, Harry Kalodner, Matthew Weinberg, and Arvind Narayanan pointed out another distinction between transaction fees and block rewards in a paper. While the block reward for each block is the same (at least between two consecutive "halvings"), transaction fees can vary by orders of magnitude—introducing new game-theoretic instabilities into the protocol. In this sense, macroeconomic decisions regarding fixed supply caps have negative microeconomic consequences for the protocol and its participants.

Just as block reward minting is an inflationary force for Bitcoin, the burning of transaction fees in EIP-1559 is a deflationary force for Ethereum. In the Ethereum protocol (which indeed uses inflationary validator rewards), there will be a tug-of-war between these two forces, with deflation often winning. ETH is now a net deflationary currency, which is a macroeconomic consequence of microeconomic incentive design decisions in the protocol's transaction fee mechanism.

Is deflation good or bad for the Ethereum protocol? ETH holders like deflation because, all else being equal, their tokens become more valuable over time. (In fact, this side effect may be what ultimately swayed public opinion to support the shift to the EIP-1559 transaction fee mechanism.) However, the term deflation makes traditionally trained macroeconomists wary, evoking memories of Japan's economic stagnation in the 1990s.

Who is right? Personally, I do not think that sovereign fiat currency is the correct analogy for cryptocurrencies like ETH. So what is the correct analogy? This remains an open question that blockchain researchers need to explore further: why can deflationary currencies serve as cryptocurrencies supporting blockchain protocols but cannot serve as fiat currencies supporting sovereign nations?

6. Cannot Ignore the Underlying Stack

In computer science, one of the goals we pursue is modularity and clean abstractions, which empower us to trust certain parts of a system. When designing and analyzing part of a system, you may need to know the functionality of outputs from other parts of the system. But ideally, you do not need to know how that functionality is implemented at the underlying level.

In blockchain protocols, we have not yet reached this ideal state. While builders and mechanism designers may prefer to focus on the application layer, they cannot ignore how the infrastructure layer operates and its details.

For example, if you are designing an automated market maker, you must consider the possibility that untrusted block producers are responsible for transaction ordering. Or, when considering designing a transaction fee mechanism for a (L2) rollup, you must pay not only for L2's resource consumption but also for all costs incurred by the underlying L1 protocol (e.g., storing calldata).

In both of these examples, effective mechanism design at one layer requires a detailed understanding of other layers. Perhaps, as blockchain technology matures, we will achieve clearer separations between different layers. But we certainly have not reached that point yet.

7. Requires Working in a Computation-Constrained Environment

The "computer in the sky" realized by blockchain protocols is a computation-constrained environment. Traditional mechanism design focuses solely on economic incentives while neglecting computational issues (for example, the well-known Vickrey-Clarke-Groves mechanism is infeasible for highly complex allocation problems).

When Nisan and Ronen proposed algorithmic mechanism design in 1999, they pointed out that we indeed need some form of computational traceability to make mechanisms practically meaningful in the real world. Therefore, they suggested limiting attention to mechanisms that extend polynomial (rather than exponential) functions using a certain amount as problem parameters for computation and communication.

Due to the very limited computation of blockchain protocol virtual machines, on-chain mechanisms must be highly lightweight—polynomial time and communication are necessary but not sufficient. For example, scarcity is the main reason automated market makers completely dominate Ethereum DeFi, rather than more traditional solutions like limit order books.

8. Still in Early Stages

Typically, when people say that web3 is still in its early stages, they refer either to investment opportunities or adoption situations. But from a scientific perspective, we are even earlier than that. This only makes things more difficult—despite the enormous opportunities.

The benefits of working in a mature research field are taken for granted by everyone. There are established models and definitions. Consensus has been reached on the most important issues. Key coordination has also formed in terms of measuring progress. There exists a common vocabulary and a vast public knowledge base. There are also acceleration pathways, including rigorously reviewed textbooks, online courses, and other resources.

Meanwhile, in many aspects of the blockchain space, we still do not know what the "correct" models and definitions are, making it difficult to think clearly and make progress on important issues. For example, what is the most important concept of compatibility incentives in the context of blockchain protocols? What layers are there in the web3 stack? What are the components of maximum extractable value (MEV)? These are all unresolved questions.

For those interested in blockchain science, the immaturity of the field is indeed a challenge. However, getting involved early—right now—also presents unique opportunities.

Mechanism design has always been a useful tool at the application layer of the internet—such as real-time ad auctions or the bilateral market designs that are prevalent in most online consumer applications today, from e-commerce to group buying.

But in web3, mechanism design also informs the design decisions of the infrastructure itself.

Reflecting back to the 1970s and 1980s, when internet routing protocols were still in discussion and design phases, to my knowledge, there was not a single expert in incentives and mechanism design involved. In hindsight, we now realize that such individuals could have provided useful insights for the design. Meanwhile, in web3, with the initial release of the Bitcoin white paper, incentive mechanisms have been part of the discussion from the very beginning.

The confusion surrounding the "correct" models, definitions, and success metrics for web3 is actually telling us that we are in a golden age. Future students and scientists will envy us for having the opportunity to shape the trajectory of this technology at the right time and in the right place. Therefore, while there may not be many textbooks in this field yet, there will be one day, and the content of those books will describe the work we are doing now.