Original title: "8 Reasons Why Blockchain Mechanism Design Is Hard"

Original author: Tim Roughgarden, a16z

Original translation: Ladyfinger, BlockBeats

Editor's note:

With the rise of blockchain technology, we have witnessed the birth and flourishing of a whole new field. As the head of research at a16z, Tim Roughgarden explores the complexity and challenges of blockchain mechanism design in depth, revealing the importance and difficulty of mechanism design in the Web3 world.

When we learn deeply enough in a subject or field, we are able to identify and understand various problems that arise in the real world. Although these problems seem complex and novel on the surface, they are usually variants of problems we have already solved or have been slightly adjusted. For example, when teaching the basics of algorithms, students will learn how to find problems that can be solved using known methods such as "shortest path" or "linear programming."

This learning model is equally powerful in the design of mechanisms, which is a kind of "reverse game theory" that uses incentives to achieve desired outcomes. Tools and courses in mechanism design are particularly useful in auction theory, market design, and social choice theory.

In the world of cryptocurrency and Web3, there are many problems in designing mechanisms. You might think that these problems can be solved by simply applying the old methods we know, but the reality is that due to the peculiarities of blockchain technology, we often need to fundamentally rethink and design solutions. This makes mechanism design in Web3 complex and challenging, but also very interesting and attractive.

In this article, I explore some of the challenges facing Web3 mechanism design. These challenges are not unfamiliar to those familiar with cryptocurrency. However, a deeper understanding of mechanism design may provide all developers with new perspectives to help them understand why these problems are difficult to overcome. For mechanism designers, if you are looking for new application scenarios, you may be curious about the challenges posed by a permissionless environment.

What is mechanism design?

The formation of the field of mechanism design dates back to 1961, when William Vickrey, an economist at Columbia University and future Nobel laureate, formalized a sealed second-price auction. This style of auction had been used as early as 1797, when the writer Johann Wolfgang von Goethe sold the manuscript of his epic poem Hermann and Dorothea. It was also commonly used by stamp collectors in the 19th century, but until Vickrey described it, it is now commonly known as the "Vickrey auction."

In a Vickrey auction, the winner is the highest bidder, but they pay the second-highest bid. This auction reveals the true preferences of the bidders and gives the item to those who value it most. The Vickrey auction is an elegant and efficient design that has been used in the real world, modified and updated for new situations, and practice has guided theory and vice versa. Like the Vickrey auction, mechanism design as a formal discipline has a history of interweaving theory and practice that is both profound and beautiful.

Unlike game theory, which identifies the dimensions of strategic interactions and explores the most plausible outcomes, the field of mechanism design does not start with a game, but with a desired outcome. The goal of mechanism design is to reverse-engineer a game so that this desired outcome, which may be characterized by efficiency, fairness, or some set of behaviors, is an equilibrium state. In the case of a Vickrey auction, the goal is to reveal the maximum amount a participant is willing to pay while not penalizing them for doing so.

The opportunities for applying mechanism design in Web3 are numerous. For example, a blockchain protocol may want to enforce good faith in the behavior of participants running the protocol, without deviating from the expected behavior. Or, a protocol may want to reveal accurate information about transaction values in order to efficiently allocate block space to the most valuable transactions. Such mechanism design problems are always challenging, but the challenges are unique in the blockchain context.

Lack of Trust

Design work in the blockchain space becomes even more difficult without the assumption of a trusted third party to enforce the mechanism.

The whole point of using a permissionless blockchain protocol is that you don’t have to trust any one entity or person, just the “average” assumption that a large enough percentage of the nodes running the protocol are running correctly.

But the irony of many blockchain architectures is that every batch of transactions added to the chain’s history is the product of a unilateral decision by a single node in order to be executed in the virtual machine maintained by the protocol.

You have no way of knowing whether you can trust this node.

This is why you rarely see Vickrey auctions in a blockchain context. Naively implementing Vickrey auctions quickly runs into the problem of manipulation by untrusted block producers. The problem is that a block producer can create a "shill bid", a fake bid that is slightly lower than the winning bid, thereby forcing the winner to pay closer to their full bid, rather than the second-highest true bid.

Untrusted block producers, by submitting fake lower bids, or "shill bids", effectively turn the Vickrey auction into a mechanism equivalent to a first-price auction. This behavior is one of the reasons why first-price auctions have become common in Web3. In addition, recent research on "trusted mechanisms" in the traditional mechanism design literature also explores how to deal with the problem of untrusted auctioneers in auction design, although from a different perspective than what we discuss here.

Collusion

Another reason that makes mechanism design in blockchains difficult is collusion between blockchain participants. For example, second-price auctions are susceptible to collusion with side payments. The reason is simple: the winning bidder pays the second-highest bid, so that bidder can simply bribe the second-highest bidder to bid lower.

The academic literature on mechanism design has not been very worried about this problem. One reason may be that in the real world, collusion is hard to pull off. It is hard to make credible side payments after some collusive action is over, because the winner can simply refuse to pay the bribe. However, in a blockchain environment, potential colluders can often use smart contracts to credibly promise the side payments needed to make the collusion work.

The second reason is that there are few mechanisms to prevent collusion with side payments—“post a price” mechanisms that only offer an acceptance or rejection offer and nothing more. Worse, users of the protocol may collude not only with each other, but also with untrusted block producers, the equivalent of bidders colluding with the auctioneer in a real-world auction.

Resilience to this last type of collusion is one of the main motivations for burning a portion of the transaction fee in Ethereum’s EIP-1559 transaction fee mechanism. Absent a “burn” mechanism, or some other way of withholding these revenues, preventing block producers from receiving them, it is possible for block producers and end users to circumvent any reserve price the mechanism attempts to set by making side payments.

Can’t Rely Alone on the Rule of Law

Collusion is clearly not a new problem. It has plagued various real-life mechanisms for centuries, yet if you examine the mechanism design literature, you may be surprised to find how little it discusses collusion. The literature does directly discuss the incentives for unilateral manipulation by individual participants of a mechanism — but collusion is usually left alone, leaving it to some unmodeled notion of the “rule of law.” For example, participants in a mechanism might sign a legal contract stipulating that they will not collude. If collusion is discovered, it is left to the legal channels to resolve.

Mechanism designers can help by creating a mechanism where collusion is relatively easy to detect. This is the unspoken secret of much of the mechanism design literature: rely on the rule of law. While it’s not true that there is no rule of law around permissionless blockchain protocols — we often see law enforcement agencies successfully prosecute crimes on permissionless blockchains — it’s much less common than in traditional mechanism design applications.

If you can’t rely on the rule of law outside the mechanism, then it’s the designer’s responsibility to deal with it within the mechanism. This approach is ubiquitous in mechanism design decisions in the blockchain space. In the Ethereum protocol in particular, examples range from burning base fee revenue in EIP-1559 to slashing misbehaving validators in its consensus protocol.

The Design Space Is Larger

The design space in Web3 is larger than mechanism designers are used to. As a result, they have to rethink any given problem. For example, many mechanisms involve payments, and in traditional mechanism design applications, these payments would be made in some fiat currency, such as the US dollar. Many blockchain protocols have their own native currency, and mechanisms within that protocol are able to manipulate that currency.

Imagine if you wrote a traditional mechanism design paper, and part of your mechanism description was: “Print a bunch of new money, and give that money to some participants.” Outside of a blockchain context, this would look ridiculous. But when you’re talking about mechanism design in the context of a blockchain protocol, you can totally do that.

The protocol controls the currency, so mechanisms that are part of that protocol can mint or burn it. This means that some designs that would be impossible without access to a native currency become possible. For example, how do you incentivize Bitcoin miners to execute the protocol as intended? Through inflationary rewards: printing new Bitcoins to incentivize these block producers. Without access to a native currency, such a design would be impossible.

Native tokens can bring other problems

The previous reason highlights the power of native currencies. There are two things you can do with native money: “minting” (the way the Bitcoin protocol mints new Bitcoins to incentivize miners) and “burning tokens” (the way Ethereum’s EIP-1559 transaction fee mechanism burns ETH to defend against collusion). Native money lurks with dangers that don’t 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. No traditional auction has had a meaningful impact on the U.S. money supply or inflation rate. This challenge is brand new in the Web3 design space. What could go wrong? Let me tell you two examples, one about the minting of Bitcoin and one about the burning of Ethereum.

Because of the use of block rewards to incentivize miners by printing new coins, Bitcoin is forced to have inflation. Therefore, it must also have a monetary policy that determines the inflation rate and how that rate evolves over time. Satoshi also created a hard supply cap of 21 million Bitcoins. Since there is a hard cap on the number of Bitcoins, the inflation rate must go to zero. If it did go to zero, what would incentivize miners to continue running the protocol and providing security for Bitcoin? It has been hoped that transaction fees would make up for the missing block rewards, although the evidence that this would happen is fairly weak. It has always been a known issue that the Bitcoin protocol would face significant security issues if transaction fees remained close to zero.

Another difference between transaction fees and block rewards was pointed out in a paper written by Princeton computer scientists Miles Carlston, Harry Kalodner, Matthew Weinberg, and Arvind Narayanan. While the block reward is the same for every block (at least between “halvings” of the block reward, which occur every four years), transaction fees can vary by orders of magnitude — which in turn introduces new game-theoretic instabilities into the protocol.

In this sense, the macroeconomic decision to fix a supply cap has negative microeconomic consequences for the protocol and its participants. Just as Bitcoin’s block reward minting acts as an inflationary force, the burning of transaction fees in EIP-1559 acts as a deflationary force for Ethereum. In the Ethereum protocol, which uses inflationary validator rewards, there is a tug-of-war between these two forces, with the deflationary force generally winning. ETH is now a net deflationary currency, a macroeconomic consequence of the protocol’s microeconomic incentive design decisions.

ETH holders like deflation because, all else being equal, it makes their tokens more valuable over time. (Indeed, this side effect may be the factor that ultimately tilts public opinion in favor of EIP-1559’s transaction fee mechanism.) Yet the concept of a deflationary currency makes conventionally trained macroeconomists cringe, recalling Japan’s economic stagflation in the 1990s.

Who’s Right? Personally, I don’t believe sovereign fiat currencies are the right analogy for cryptocurrencies like ETH. But what is the right analogy? This remains an open question that needs further exploration by blockchain researchers: Why is it that deflationary currencies work as cryptocurrencies that support blockchain protocols, but not as fiat currencies that support sovereign states?

The Underlying Stack That Can’t Be Ignored

One of the things we strive for in computer science is modularity and clean abstractions, which allow you to trust parts of a system. When designing and analyzing one part of a system, you certainly need to know the functionality derived by other parts of the system. But ideally, you don’t need to know how those functions are actually implemented at the underlying level.

In blockchain protocols, we have not yet achieved this ideal. While builders and mechanism designers may like to focus on, say, the application layer, they cannot ignore the reality and details of working at the infrastructure layer. For example, if you are designing an automated market maker, you must account for the fact that untrusted block producers are responsible for transaction ordering. Or, when you consider designing a transaction fee mechanism for a Layer 2 rollup, you must pay not only for the resource consumption of Layer 2, but also for any costs incurred by the underlying protocol, e.g., calling data from storage.

In both examples, we can see that effective mechanism design requires not only a deep understanding of a particular layer but also detailed expertise in other layers. Although the maturity of blockchain technology will enable us to more clearly distinguish and focus on its different layers, we must admit that we have not yet reached such a level of maturity.

Required to work in a compute-constrained environment

The "computer in the sky" implemented by blockchain protocols is a compute-constrained environment. Traditional mechanism design focuses only on economic incentives and ignores computational issues. For example, the famous Vickrey-Clarke-Groves mechanism is infeasible for sufficiently complex allocation problems. When Nisan and Ronen introduced algorithmic mechanism design in 1999, they pointed out that we do need some computational feasibility in order for mechanisms to have any practical significance in the real world. Therefore, they proposed to restrict attention to mechanisms whose computation and communication amount scale polynomially with the problem parameters, rather than exponentially.

Since computation in the blockchain protocol’s virtual machine is extremely scarce, on-chain mechanisms must be highly lightweight, and polynomial time and communication are necessary, but not sufficient. For example, this scarcity is the main reason why automated market makers completely dominate Ethereum DeFi, rather than more traditional solutions like limit order books.

Still in the Early Stages

Usually, when people say that Web3 is still in its early stages, they are referring to investment opportunities or adoption numbers. But from a scientific perspective, we are even earlier than that. This fact only makes things more difficult, even though it represents a huge opportunity.

Working in a mature research field offers benefits that everyone takes for granted. There are accepted models and definitions. There is consensus around the most important questions. There is non-trivial coordination on how to measure progress. There is a shared vocabulary and a large common knowledge base. And there are pathways to get on board to get up to speed, including well-reviewed textbooks, online courses, and other resources.

Meanwhile, in many parts of the blockchain space, we still don’t know the “right” models and definitions to think clearly and make progress on important problems. For example, what is the most important concept of incentive compatibility in the context of blockchain protocols? What are the layers of the Web3 stack? What should count toward Maximum Extractable Value (MEV)? These are just some of the open questions.

For those interested in working in blockchain science, the immaturity of the field presents challenges. But joining the field early now also represents a unique opportunity. Mechanism design has always been a useful tool at the application layer of the Internet, taking the example of real-time advertising auctions, or designing the two-sided markets that are ubiquitous in most online consumer applications, from e-commerce to ride-sharing.

But in Web3, mechanism design is also influencing design decisions in the infrastructure itself. Think back to the 1970s and 1980s, when Internet routing protocols were still being discussed and designed. To my knowledge, no one with expertise in incentives and mechanism design sat at that table. In hindsight, we now realize that such people could have usefully informed the design. Meanwhile, in Web3, incentive mechanisms have been part of the discussion from the beginning, with the release of the original Bitcoin whitepaper.

The confusion surrounding the “right” models, definitions, and success metrics for Web3 is actually telling us that we are in a golden age. Later students and scientists will envy us for joining the field at this time and having the opportunity to shape the trajectory of this technology. So while there may not be many textbooks in the field, there will be one day, and the work that will be described in them is the work we are currently doing.

Original link

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia