a16z: 8 major challenges in blockchain mechanism design

Original title: 8 reasons why blockchain mechanism design is hard

Original author: Tim Roughgarden, head of crypto research at a16z

Original translation: Ladyfinger, BlockBeats

In-depth study of a field teaches you to recognize that problems that arise in the real world are just poor disguises of problems that have been well solved. For example, when I taught the basics of algorithms, students learned how to identify problems that boil down to shortest path calculations or linear programming.

This pattern matching is equally effective in mechanism design, a kind of "inverse 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 problems can be solved by applying what is in the textbook, making new adjustments to old ideas. However, the unique challenges and limitations of permissionless blockchain protocols often force a rethinking of the fundamentals of seemingly solved problems. This makes mechanism design in Web3 complex. But it is also these challenges that make web3 mechanism design fascinating.

In this article, I will explore some of the challenges facing Web3 mechanism design. 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, what is mechanism design?

The formation of the mechanism design field can be traced back to at least 1961, when William Vickrey, an economist at Columbia University and later Nobel laureate, formalized the second-price sealed auction method. This auction format was used as early as 1797 when author Johann Wolfgang von Goethe sold the manuscript of his epic poem "Hermann and Dorothea" and was commonly used by stamp collectors in the 19th century, but it was not formally proposed by Vickrey until 1961 and is now often called a "Vickrey auction." In the Vickrey auction model, the highest bidder wins, but pays the second highest bid. This auction inspires the true preferences of bidders and delivers the item to the person with the highest estimated bid.

The Vickrey auction is an elegant and efficient design that has been applied in the real world, adapted and updated to new situations, with practice informing theory and vice versa. Like the Vickrey auction, the history of mechanism design as a formal discipline is one of deep and beautiful interweaving of theory and practice.

In contrast to game theory—which establishes dimensions of strategic interaction and explores the most plausible 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 so that a desired outcome (which may be characterized by efficiency, fairness, or certain behaviors) is balanced. In the case of the Vickrey auction, the ultimate goal is to induce participants to pay the maximum amount they are willing to pay without penalizing them.

The opportunities for mechanism design in Web3 are numerous. For example, a blockchain protocol may want to achieve an outcome where protocol participants behave in good faith (without deviating from the expected behavior). Or, a protocol may want to obtain accurate information about the value of transactions in order to efficiently allocate block space to the most valuable transactions.

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

1. Lack of Trust

Design in the blockchain space becomes even more difficult when there is no trusted 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 an “average” trust assumption that enough of the nodes running the protocol are honest.

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

It’s not clear whether you can trust this node.

This is why Vickrey auctions are rarely seen in the blockchain space. 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 fake bid called a "shill bid" that is slightly lower than the bid of the would-be winner, forcing the winner to pay almost their entire bid (rather than the true second-highest bid).

Fake bids from untrusted block producers effectively cause the Vickrey auction to revert to a first-price auction model, which is one of the reasons why first-price auctions are so common in web3. (The latest branch of the traditional mechanism design literature on "trusted mechanisms" also considers auction design for untrusted auctioneers, but from a different perspective.)

2. Collusion sometimes

Another reason why blockchain mechanism design is difficult is that there is collusion between blockchain participants. For example, second-price auctions can easily be colluded with compensation payments. The reason is simple: since the winning bidder pays the second-highest bid, a bidder can bribe the second-highest bidder to bid much lower.

The academic literature on mechanism design has not worried too much about this problem. One reason may be that collusion (especially collusion with compensation payments) is difficult to achieve in the real world. After collusion, the winner can simply refuse to pay the bribe, so it is difficult to obtain credible compensation payments. (As the saying goes: "There is no justice among thieves.")

However, in the context of blockchains, potential colluders can usually use smart contracts to provide reliable commitments to make collusion work. The second reason is the lack of a mechanism to inhibit collusion with compensation payments - a "price disclosure" mechanism that only provides quotes and nothing else.

To make matters worse, protocol users may collude not only with each other, but also with (untrusted) block producers (equivalent to collusion between bidders and auctioneers in real-world auctions).

Protection against this last kind of collusion is one of the main motivations for burning a portion of transaction fees in Ethereum’s EIP-1559 transaction fee mechanism. Without “burning” (or otherwise withholding these revenues from block producers), block producers and end users can collude through compensation payments and evade any reserve price the mechanism attempts to impose.

3. Can’t rely on the rule of law alone

The collusion problem is obviously not a new one. It has plagued various real-life mechanisms for centuries, but if you look at the mechanism design literature, you may be surprised to see how little it has addressed the problem. The literature does discuss head-on the incentives of individual actors to unilaterally manipulate the mechanism, but usually leaves the problem to some unrealized notion of “rule of law”. For example, participants in the mechanism might sign a legal contract that states they will not engage in collusion. If collusion is detected, it will be taken to legal channels. Mechanism designers can help by creating a mechanism that makes it relatively easy to detect collusion.

There is an unspoken secret in much of the mechanism design literature: a reliance on the rule of law. While we cannot say that there is no rule of law in the world of permissionless blockchain protocols—we often see law enforcement successfully prosecute crimes on permissionless blockchains—the extent of the rule of law is much less than in traditional mechanism design applications.

If you cannot rely on the rule of law outside of the mechanism, then the designer has a responsibility to address the problem within the mechanism. This approach is prevalent in mechanism design decisions in the blockchain space. In the Ethereum protocol in particular, examples abound, from EIP-1559 burning base fee revenue to slashing validators for misbehaving in its consensus protocol.

4. The design space is larger

The design space in web3 is larger than mechanism designers are used to. Therefore, designers have to rethink all given problems. For example, many mechanisms involve payments, and in traditional mechanism design applications, these payments would be made in fiat currencies such as the US dollar. Many blockchain protocols have their own native currencies, and mechanisms within such protocols are able to manipulate these currencies.

Imagine if you wrote a traditional mechanism design article, and part of your mechanism description was: "Print a bunch of new currency and then distribute it to a group of participants." Jumping out of the context of blockchain, this is ridiculous. But when you are talking about mechanism design in the context of blockchain protocols, you can do this. The protocol controls the currency, so part of the mechanism of the protocol can mint tokens or burn tokens.

This means that some designs that would not be possible without a native currency become possible. For example, how do you incentivize Bitcoin miners to execute the protocol as intended? Through inflation rewards: printing new coins (Bitcoins) to incentivize these block producers. Without a native currency, such a design would not be possible.

5. Native Currency May Bring Other Problems

The previous reason highlights the power of native currency. You can do two things with native currency: "coinage" (the way the Bitcoin protocol mints new Bitcoins to incentivize miners) and "burning tokens" (the way Ethereum EIP-1559 transaction fee mechanism burns ETH to resist collusion). Native currency lurks a danger that does not exist in traditional mechanism design: microeconomic design decisions may have macroeconomic consequences.

In traditional mechanism design, there is no reason to worry about macroeconomic forces. Traditional auctions have not had a meaningful impact on the US money supply or inflation rate. This is a completely new challenge for the web3 design field. What problems may occur? Let me tell you two examples, one about the minting of Bitcoin and one about the burning of ETH.

Because of the use of block rewards - incentivizing miners by printing new coins - Bitcoin is forced to have inflation. Therefore, it must also have corresponding monetary policies to determine the inflation rate and how the inflation rate evolves over time. Satoshi also set a hard supply cap of 21 million Bitcoins. Since there is a hard cap on the number of Bitcoins, the inflation rate must approach zero.

If the inflation rate is truly zero, what should incentivize miners to continue running the protocol and providing security for Bitcoin? There has been hope that transaction fees will make up for the missing block rewards, although the chances of this happening are quite slim. It is well known that if transaction fees approach zero, then the Bitcoin protocol will suffer major security issues.

Another distinction between transaction fees and block rewards is pointed out in an article by Princeton University computer scientists Miles Carlston, Harry Kalodner, Matthew Weinberg, and Arvind Narayanan. While the block reward is the same for every block (at least between successive “halvings” of the block reward), 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 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 does use inflationary validator rewards), there is a tug-of-war between these two forces, with deflation often winning. ETH is now a net deflationary currency, a macroeconomic consequence of the microeconomically motivated design decision 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. (Indeed, this byproduct may be what ultimately spurred public opinion to support the shift to EIP-1559’s transaction fee mechanism.) Yet the word deflation is a turnoff for classically trained macroeconomists, bringing to mind Japan’s economic stagflation in the 1990s.

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

6. Don’t Ignore the Underlying Stack

One of the things we strive to achieve in computer science is modularity and clean abstractions, which give us the ability to trust parts of a system. When designing and analyzing one part of a system, you may need to know the functionality that the rest of the system outputs. Ideally, you don’t need to know how that functionality is implemented at the bottom level.

In blockchain protocols, we haven’t reached this ideal yet. While builders and mechanism designers may like to focus on the application layer, they cannot ignore how the infrastructure layer works and its details.

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

In both examples, effective mechanism design for one layer requires detailed knowledge of the other layers. Perhaps, as blockchain technology matures, we will have a clear separation of the different layers. But we are certainly not there yet.

7. Required to work in a computationally constrained environment

The "computer in the sky" implemented by blockchain protocols is a computationally constrained environment. Traditional mechanism design focuses only on economic incentives and ignores computational issues (e.g., the famous Vickrey-Clark-Groves mechanism is infeasible for highly complex allocation problems).

When Nisan and Ronen proposed algorithmic mechanism design in 1999, they pointed out that we do need some kind of computational traceability to make the mechanisms practical in the real world. Therefore, they proposed to restrict attention to mechanisms for computation and communication that scale with some amount of polynomial (rather than exponential) functions of the problem parameters.

Because blockchain protocol virtual machines are so computationally inefficient, on-chain mechanisms must be extremely lightweight — polynomial time and communication are necessary, but not sufficient. For example, scarcity is the main reason why automated market makers completely dominate Ethereum DeFi, rather than more traditional solutions like limit order books.

8. It’s still early days

Usually when people say web3 is still in its early stages, they’re referring to either investment opportunities or adoption. But from a scientific perspective, we’re even earlier than that. It’s only going to be harder — even though the opportunity is huge.

The benefits of working in a mature research field are taken for granted by everyone. There are accepted models and definitions. There is consensus on the most important questions. There is also critical coordination on how to measure progress. There is a common vocabulary and a large public knowledge base. There are also ways to accelerate, including well-reviewed textbooks, online courses, and other resources.

At the same time, there are many aspects of the blockchain space where we don’t yet know the “right” models and definitions to think clearly and make progress on important problems. For example, what is the most important concept of compatibility incentives in the context of blockchain protocols? What are the layers of the web3 stack? What are the components of Maximum Extractable Value (MEV)? These are all open questions.

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

Mechanism design has always been a useful tool at the application layer of the Internet — think real-time advertising auctions, or the two-sided market designs that are prevalent in most online consumer applications today, from e-commerce to group buying.

But in web3, mechanism design also informs design decisions for 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 incentive and mechanism design had a seat at the table. In hindsight, we now realize that such a person could have provided useful information for the design. Meanwhile, in web3, incentives were part of the discussion from the beginning, with the release of the original Bitcoin whitepaper.

The confusion around the “right” models, definitions, and success metrics for web3 is actually telling us that we are in a golden age. Future generations of students and scientists will envy us for being in the right place at the right time with the opportunity to shape the trajectory of this technology. So while there may not be many textbooks in this field, there will be someday, and what those books will describe is the work we are doing now.

Original link

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

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

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

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