Crypto and Web3 are filled with mechanism design problems.
Written by: Tim Roughgarden, Head of Research at a16z crypto
Translated by: 0xxz, Golden Finance
In-depth research in a field will teach you to recognize that the problems that arise in the real world are nothing more than poor disguises of problems that have already been properly solved. For example, when I teach basic algorithm knowledge, students learn how to identify problems that can be reduced 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 ideal results. The tools and lessons of mechanism design are particularly useful in auction theory, market design, and social choice theory.
Crypto and Web3 are filled with mechanism design problems. People may think that many problems can be solved by applying the content from textbooks and making adjustments to old ideas. However, the unique challenges and constraints of permissionless blockchain protocols often force people to rethink the basic principles of seemingly solved problems. This complexity makes mechanism design in Web3 challenging, but it is also what 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 native cryptocurrency 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 considering new applications, you may be interested in the challenges posed by permissionless environments.
But first, we need to understand what mechanism design is.
The formation of the field of mechanism design can be traced back to at least 1961, when William Vickrey, an economist at Columbia University and later a Nobel laureate, formally proposed the second-price sealed-bid auction. This auction method had been in use since 1797 when Johann Wolfgang von Goethe sold the manuscript of his epic "Hermann and Dorothea," and it was widely used by stamp collectors in the 19th century. However, it was not formally proposed by Vickrey until 1961, and it is now commonly referred to as the "Vickrey auction." In the Vickrey auction, the highest bidder wins but pays the second-highest bid. This auction inspires genuine preferences among bidders and delivers the item to the bidder with the highest valuation.
The Vickrey auction is an elegant and efficient design that has been applied in the real world, adjusted and updated according to new situations, providing information to theory and vice versa. Like the Vickrey auction, the development history of mechanism design as a formal discipline is a history of the interweaving of theory and practice, both deep and beautiful.
In contrast to game theory, which establishes dimensions of strategic interaction to explore the most rational behavior, the field of mechanism design does not start from games but from desired outcomes. The purpose of mechanism design is to reverse-engineer a form of game to achieve a balanced expected outcome, possibly characterized 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, blockchain protocols may want to achieve honest behavior among protocol participants (without deviating from expected behavior). Alternatively, the 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 they are even more unique in the blockchain environment.
1. Lack of Trust
Designing in the blockchain space becomes more difficult without a trusted party to enforce mechanisms.
The whole point of using permissionless blockchain protocols is that you do not need to trust any entity or individual, only a "reasonable level" of trust assumption, meaning that there are enough honest nodes among the nodes running the protocol.
However, the irony of many blockchain architectures is that every batch of transactions added to the chain's history is the result of unilateral decisions made by individual nodes in the protocol's maintenance virtual machine.
You are not sure if you can trust this node.
This is why we rarely see Vickrey auctions in the blockchain space. Naively implementing Vickrey auctions quickly encounters the problem of manipulation by untrusted block producers. The issue is that a block producer can create a "shill bid," a false bid slightly lower than the soon-to-be winner's bid, forcing the winner to pay almost their entire bid (rather than the true second-highest bid).
The false bids by untrusted block producers effectively revert the Vickrey auction to a first-price auction, which is one of the reasons why first-price auctions are so common in Web3. (The latest branch of traditional mechanism design literature on "trusted mechanisms" also considers auction design with untrusted auctioneers, but from a different perspective.)
2. Collusion
Another reason for the difficulty of blockchain mechanism design is collusion among blockchain participants. For example, second-price auctions are easily colluded with compensation payments. The reasoning is simple: since the winning bidder pays the second-highest bid, bidders 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 colluding, the winner can simply refuse to pay the bribe, making it difficult to obtain reliable compensation payments. (As the saying goes, "there is no honor among thieves.")
However, in the context of blockchain, potential colluders can often use smart contracts to provide reliable commitments, making collusion effective. The second reason is the lack of a mechanism to suppress collusion with compensation payments - a "price disclosure" mechanism that only provides quotes and nothing else.
What's worse, protocol users may collude with (untrusted) block producers, similar to bidders colluding with auctioneers in traditional auctions.
The resistance to the latter type 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 withholding these revenues from block producers in other ways), block producers and end users can collude with compensation payments and evade any reserve prices that the mechanism attempts to impose.
3. Cannot Rely Solely on Legal Systems
Collusion problems are obviously not new. For centuries, it has plagued various mechanisms in real life, but if you look at the literature on mechanism design, you may be surprised to find that it has almost not addressed this issue. These papers do discuss the unilateral manipulation of mechanisms by individual participants, but they often leave the problem to some unmodeled concept of "legal systems." For example, participants in the mechanism may sign a legal contract that stipulates they will not collude. If collusion is found, it will be dealt with through legal channels. Mechanism designers can help by creating a mechanism that relatively easily detects collusion.
There is an unspoken secret in much of the mechanism design literature: reliance on legal systems. Although we cannot say that there is no legal system in the field of permissionless blockchain protocols - we often see law enforcement successfully prosecuting criminal activities on permissionless blockchains - the degree of legal system is much less than in traditional mechanism design applications.
If you cannot rely on legal systems outside the mechanism, then designers have a responsibility to solve problems within the mechanism. This approach is prevalent in the decision-making of mechanism design in the blockchain space. Especially in the Ethereum protocol, from burning base fee revenue in EIP-1559 to penalizing misbehaving validators in its consensus protocol, there are numerous examples.
4. Greater 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, and in traditional mechanism design applications, these payments are made in fiat currencies such as the US dollar. Many blockchain protocols have their own native currencies, and the mechanisms within these protocols can manipulate these currencies.
Imagine if you were writing an article on traditional mechanism design, and part of your mechanism description was: "Print a bunch of new currency and distribute it to a group of participants." Looking at it from outside the blockchain context, this seems absurd. But when discussing mechanism design in the context of blockchain protocols, you can completely do this. The protocol controls the currency, so the protocol's mechanisms can mint or burn tokens.
This means that some designs that are not possible without native currencies become possible. For example, how do you incentivize Bitcoin miners to execute the protocol as expected? Through inflation rewards: minting new coins (Bitcoins) to incentivize these block producers. Such a design would not be possible without a native currency.
5. Native currencies may bring other problems
The previous point emphasizes the power of native currencies. You can do two things with native currencies: "minting" (the Bitcoin protocol mints new Bitcoins to incentivize miners) and "burning tokens" (the Ethereum EIP-1559 transaction fee mechanism burns ETH to resist collusion). Native currencies harbor risks that do 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 auction methods do not have a meaningful impact on the US money supply or inflation rate. This is a new challenge for Web3 design. What problems might arise? Let me tell you two examples, one about minting Bitcoin and one about burning ETH.
Due to the use of block rewards - incentivizing miners by minting new coins - Bitcoin is forced to experience inflation. Therefore, it must also have a corresponding monetary policy to determine the inflation rate and how the inflation rate evolves over time. Satoshi Nakamoto also set a hard supply limit of 21 million Bitcoins. Since Bitcoin 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 hoped that transaction fees could 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, the Bitcoin protocol will suffer significant security issues.
Princeton computer scientists Miles Carlston, Harry Kalodner, Matthew Weinberg, and Arvind Narayanan pointed out another difference between transaction fees and block rewards. While the block reward for each block is the same (at least between consecutive "halvings" of the block reward), transaction fees can vary by orders of magnitude - introducing new game-theoretic instabilities to the protocol. In this sense, macroeconomic decisions with a fixed supply limit have negative microeconomic consequences for the protocol and its participants.
Just as minting block rewards is an inflationary force for Bitcoin, burning transaction fees in EIP-1559 is a deflationary force for Ethereum. In the Ethereum protocol (which does indeed use inflationary validator rewards), these two forces engage in a tug-of-war, with deflation often winning. ETH is now a net deflationary currency, a macroeconomic consequence of microeconomic design decisions in the protocol's transaction fee mechanism.
Is deflation good or bad for the Ethereum protocol? ETH holders like deflation because, under otherwise equal conditions, their tokens become more valuable over time. (In fact, this may be the ultimate reason that public opinion supported the transition to the EIP-1559 transaction fee mechanism.) However, the term "deflation" makes traditional macroeconomists hesitant, reminiscent of Japan's economic stagnation in the 1990s.
Who is right? Personally, I do not believe that sovereign fiat currencies are the correct analogy for cryptocurrencies like ETH. So, what is the correct analogy? This is still an unresolved question that blockchain researchers need to further explore: why can deflationary currencies work as cryptocurrencies supporting blockchain protocols, but not as fiat currencies supporting sovereign nations?
6. Cannot Ignore the Underlying Stack
In computer science, one of the things we strive to achieve is modularity and clean abstraction, which gives us the ability to trust a part of the system. When designing and analyzing a part of the system, you may need to know the functionality output of other parts of the system. But ideally, you do not need to know how this functionality is implemented at the lower 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 of untrusted block producers responsible for transaction ordering. Or, when designing a transaction fee mechanism for a (L2) rollup, you must not only pay for the resource consumption of L2 but also for all the 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 the other layer. Perhaps, as blockchain technology matures, we will have clear separations between different layers. But we certainly have not reached that level yet.
7. Working in a Computationally Constrained Environment
The "computer in the sky" implemented by blockchain protocols is a computationally constrained environment. Traditional mechanism design only focuses on economic incentives, ignoring computational issues (e.g., the famous 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 do need some form of computational tractability to make mechanisms meaningful in the real world. Therefore, they suggested focusing on mechanisms that extend computation and communication using a polynomial (rather than exponential) function of a certain amount as problem parameters.
Because the computational power of blockchain protocol virtual machines is very limited, on-chain mechanisms must be highly 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. Still in the Early Stages
Usually, when people say that Web3 is still in the early stages, they are referring to either investment opportunities or adoption. But from a scientific perspective, we are even earlier than that. This only makes things more difficult - although the opportunities are enormous.
The benefits of working in a mature research field are taken for granted by everyone. There are recognized models and definitions. There is consensus on the most important issues. There is also critical coordination in measuring progress. There is a common vocabulary and a vast shared knowledge base. There are also fast tracks, including rigorously reviewed textbooks, online courses, and other resources.
At the same time, in many aspects of the blockchain field, we do not yet know the "correct" models and definitions, cannot think clearly and make progress on important issues. For example, in the context of blockchain protocols, what is the most important concept for compatibility incentives? What are the layers 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 in the application layer of the internet - such as real-time ad auctions, or the bilateral market design that is prevalent in most online consumer applications today, from e-commerce to group buying.
But in Web3, mechanism design also provides information for the design decisions of the infrastructure itself.
Looking back to the 1970s and 1980s, when internet routing protocols were still under discussion and design, as far as I know, there were no professionals in incentives and mechanism design involved. In hindsight, we now realize that such individuals could have provided useful information for the design. At the same time, in Web3, with the initial release of the Bitcoin whitepaper, incentive mechanisms have been part of the discussion from the beginning.
The confusion around the "correct" 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, as we have 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, there will be someday, and the content described in these books will be the work we are doing now.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
