Original title: "8 reasons why blockchain mechanism design is hard"
Author : Tim Roughgarden, head of a16z crypto research
Compiled by: 0xxz, Golden Finance
to one In-depth study of the field will teach you to realize that the problems that arise in the real world are just poor disguises for problems that have been solved well. For example, when I teach Algorithm Basics, students learn how to identify problems that boil down to shortest path calculations or linear programming.
This kind of pattern matching is also effective in mechanism design. This is an "inverse game theory" that uses incentives to achieve desired results. Tools and lessons from mechanism design are particularly useful in auction theory, market design, and social choice theory.
Crypto and web3 are riddled with mechanism design issues. One might think that many problems can be solved by applying material from textbooks, putting a new spin on old ideas. However, the unique challenges and limitations of permissionless blockchain protocols often force a rethinking of the fundamental principles of a seemingly settled problem. This complicates the design of mechanisms in web3. But it’s these challenges that make web3 mechanism design so fascinating.
In this article I will explore some of the challenges faced by 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 a permissionless environment.
But first, what we need to know is, what is mechanism design?
The formation of the field of mechanism design can be traced back to at least 1961, when Columbia University economist and future Nobel Laureate William Vickrey The second price sealed auction method was formally proposed. This auction method was used as early as 1797 when author Johann Wolfgang von Goethe sold the manuscript of his epic poem Hermann and Dorothea, and It was widely used by stamp collectors in the 19th century, but it was not officially proposed by Vickrey until 1961, and is now often called "Vickrey auction". In the Vickery auction model, the highest bidder wins, but pays the second-highest bid. This type of auction inspires true preference among bidders and delivers the lot to the highest estimate.
The Vickery Auction is an elegant and efficient design that has been applied to the real world, adapting and updating to new situations, where practice informs theory and vice versa . Like Vickery Auction, the history of mechanism design as a formal discipline is a history of intertwined theory and practice, which is both profound and beautiful.
Contrary to game theory - which establishes the dimension of strategic interaction and explores the most reasonable results of behavior - the field of mechanism design does not start with the game, but with the desired results. The purpose of mechanism design is to reverse engineer some form of game so that a desired outcome (perhaps characterized by efficiency, fairness, or certain behaviors) is balanced. In the case of Vickery Auctions, the ultimate goal is to induce participants to pay the maximum amount they are willing to pay without penalizing them.
There are many application opportunities for mechanism design in Web3. For example, a blockchain protocol may wish to achieve outcomes where protocol participants behave with integrity (without deviating from expected behavior). Alternatively, a protocol may wish to obtain accurate information about transaction values 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 a blockchain environment.
If there is no trusted party to execute the mechanism, the design of the blockchain field will become more difficult. .
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” assumption of trust among the nodes running the protocol There are enough nodes that 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 a single node. product of decision-making.
You don't know whether you can trust this node.
This is why Vickery auctions are rarely seen in the blockchain field. A naive implementation of Vickery auctions will quickly encounter the problem of manipulation by untrusted block producers. The problem is that a block producer can create a "shill bid" fake bid that is slightly lower than the soon-to-be winner's bid, thus forcing the winner to pay almost their entire bid (instead of the true second-highest bid).
Fake bids from untrusted block producers effectively caused Vickery Auctions to revert to first-price auction mode, which is why first-price auctions are so common in web3 one of the reasons. (The latest branch of traditional mechanism design literature on "trusted mechanisms" also considers the auction design of untrusted auctioneers, but from a different perspective.)
Another reason why it is difficult to design a blockchain mechanism is that there will be collusion among blockchain participants. For example, second-price auctions can easily be colluded with compensation payments. The idea is simple: since the winning bidder pays the second-highest bid, the bidder can bribe the second-highest bidder to bid much lower.
The academic literature on mechanism design does not worry too much about this issue. One reason may be that collusion, especially with compensation payments, is difficult to achieve in the real world. After collusion, the winner can 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 blockchain, potential colluders can often use smart contracts to provide reliable commitments, allowing collusion to truly take effect. effect. The second reason is the lack of a mechanism to inhibit collusion with compensation payments - the "price disclosure" mechanism, which only provides quotations and nothing else.
Even worse, protocol users may collude not only with each other, but also with (untrusted) block producers (the equivalent of bidders and auctioneers in real-world auctions) collusion).
Resistance against this last type of collusion is one of the main motivations for the burn 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 escape any reservation price the mechanism attempts to impose.
The issue of collusion is obviously not a new one. It's been plaguing real-life mechanics for centuries, but if you look at the mechanism design literature, you might be surprised to see how little it addresses. This literature does address head-on the motivations of individual actors to unilaterally manipulate mechanisms, but generally leaves the question to some yet-to-be-formulated concept of “rule of law.” For example, participants in the mechanism might sign a legal contract that stipulates that they will not collude. If collusion is discovered, it will be referred 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: reliance on the rule of law. While we can’t say that there is no rule of law in the realm of permissionless blockchain protocols—we often see law enforcement successfully prosecute crimes on permissionless blockchains—the degree of rule of law is 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 fix the problem within the mechanism. This approach is prevalent in mechanism design decisions in the blockchain field. In the Ethereum protocol specifically, examples abound, from EIP-1559 burning base fee earnings to slashing validators for misbehaving in their consensus protocol.
The design space in web3 is larger than what mechanism designers are used to. Therefore, designers must rethink any given problem. For example, many mechanisms involve payments that, in traditional mechanism design applications, would be made in fiat currencies such as U.S. dollars. Many blockchain protocols have their own native currency, and mechanisms within the protocol are capable of manipulating these currencies.
Imagine if you wrote an article about traditional mechanism design, and part of your mechanism description was: "Print a bunch of new currencies and then distribute them to a group of participants." Beyond the blockchain Viewed in context, this is ridiculous. But when you talk about mechanism design in the context of a blockchain protocol, you can definitely do that. The protocol controls the currency, so parts of the protocol’s mechanics can mint tokens or burn tokens.
This means that some designs that would be impossible without native currency become possible. For example, how do you incentivize Bitcoin miners to perform the protocol as intended? These block producers are incentivized through inflationary rewards: printing new coins (Bitcoins). Without a native currency, such a design would be impossible.
The previous reason emphasizes the power of native currency. You can do two things with native currency: “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 resist collusion). Native currencies lurk a danger that does 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 auctions have had no meaningful impact on the U.S. money supply or inflation rate. This is a completely new challenge in the world of web3 design. What could go wrong? Let me tell you two examples, one about the minting of Bitcoin and the other about the burning of ETH.
Due to the use of block rewards—incentivizing miners by printing new coins—Bitcoin is forced to experience inflation. Therefore, it must also have a corresponding monetary policy that determines the inflation rate and how it evolves over time. Satoshi Nakamoto 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 really zero, what should be used to incentivize miners to continue running the protocol and provide security for Bitcoin? It has been hoped that transaction fees would make up for missing block rewards, although the chances of this happening are rather slim. It is known that if transaction fees approach zero, the Bitcoin protocol will suffer from significant security issues.
Princeton University computer scientists Miles Carlston, Harry Kalodner, Matthew Weinberg and Arvind Narayanan pointed out another difference between transaction fees and block rewards in an article. While the block reward is the same for every block (at least between two consecutive block reward “halvings”), transaction fees can vary by orders of magnitude — which in turn gives The protocol introduces new game-theoretic instability. In this sense, the macroeconomic decision to fix a supply cap has negative microeconomic consequences for the protocol and its participants.
Just like block reward minting was an inflationary force for Bitcoin, the burning of transaction fees in EIP-1559 was 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 decisions in the protocol’s transaction fee mechanism.
Is deflation good or bad for the Ethereum protocol? ETH holders love deflation because, all else being equal, their tokens become more valuable over time. (Indeed, this by-product may be what finally drove public opinion in favor of moving to EIP-1559’s transaction fee regime.) However, the term deflation daunts traditionally trained macroeconomists, recalling Japan’s 1990s Economic stagflation.
Who is right? Personally, I don’t think sovereign fiat currencies are the right analogy for cryptocurrencies like ETH. So what's the right analogy? This remains an open question that requires further exploration by blockchain researchers: Why can a deflationary currency function as a cryptocurrency supporting a blockchain protocol, but not a fiat currency supporting a sovereign state?
In computer science, one of the things we strive to achieve is modularity and clean abstraction , which gives us the ability to trust certain parts of the system. When designing and analyzing one part of a system, you may need to know the functionality of the output from other parts of the system. But ideally, you don't need to know how this functionality is implemented under the hood.
In blockchain protocols, we have not yet reached this ideal state. While builders and mechanism designers may like 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. Alternatively, when you consider designing a transaction fee mechanism for a (L2) rollup, you not only have to pay for L2 resource consumption, but also for all costs incurred by the underlying L1 protocol (e.g., storing calldata).
In both examples, effective mechanism design at one layer requires detailed knowledge of the other layers. Perhaps, as blockchain technology becomes more mature, we will have a clear separation of different layers. But we're certainly not there yet.
The "computer in sky" implemented by the blockchain protocol is a computing subject restricted environment. Traditional mechanism design only focuses on economic incentives and ignores computational issues (for example, the famous Vickery-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 really needed some kind of computational traceability to make the mechanism meaningful in the real world. Therefore, they recommend limiting attention to mechanisms for computation and communication that use certain quantities as polynomial (rather than exponential) function extensions as problem parameters.
Since the computational load of the blockchain protocol virtual machine is very small, the on-chain mechanism 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.
Typically, when people say web3 is in the early stages, they are referring to either investment opportunities or adoption. But from a scientific perspective, we're even earlier than that. It will only get harder—even though the opportunities are huge.
The benefits of working in an established research field are taken for granted by all. There are generally accepted models and definitions. Consensus was reached on the most important issues. Key coordination also developed around progress measurement. There exists a common vocabulary and a vast public knowledge base. There are also ways to speed up, including rigorously vetted textbooks, online courses, and other resources.
At the same time, in many aspects of the blockchain space, we don’t yet know the “right” models and definitions to think clearly and make progress on important issues. For example, what are the most important concepts 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 unanswered questions.
For those interested in blockchain science, the immaturity of the field is indeed a challenge. But getting involved early — now — can also lead to unique opportunities.
Mechanism design has always been a useful tool at the Internet application layer - such as real-time advertising auctions, or the two-sided market that is ubiquitous in most online consumer applications today, from e-commerce to group buying. design.
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 in the discussion and design stage. As far as I know, no professional in incentive and mechanism design has 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, with the release of the original Bitcoin white paper, incentives were part of the discussion from the beginning.
The confusion surrounding the “correct” model, definition, 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 that we were 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 area, one day there will be, and what will be described in these books is what we are doing now.
The above is the detailed content of a16z: 8 challenges in blockchain mechanism design. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
