a16z: 8 challenges to explore Blockchain mechanism design

Original author: Tim Roughgarden, Research Lead at a16z crypto

Original compilation: 0x xz, Golden Finance

An in-depth study of an area will teach you to realize that real-world problems are nothing more than a poor disguise for problems that have been properly solved. For example, when I taught Algorithm Basics, students learned how to identify problems that boiled down to shortest path calculations or linear programming.

This pattern matching is also valid in mechanism design, which is an “inverse game theory” that uses incentives to achieve desirable outcomes. The tools and lessons learned 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 longing of the problems could be solved by applying textbook content and readjusting old ideas. However, the unique challenges and limitations of permissionless Blockchain protocol often force a rethinking of the underlying principles of seemingly resolved issues. This complicates the design of mechanisms in web3. But it’s these challenges that make web3 mechanism design fascinating.

In this article, I’ll explore some of the challenges of designing web3 mechanisms. These challenges may be familiar to encryption native users, but a deeper understanding of mechanism design should provide all builders with a new perspective on why solving these problems is so hard. For mechanism designers, if you’re thinking about a new application, you might be interested in the challenges that come with a permissionless environment.

But first, what we need to know is, what is mechanic design?

The formation of the field of mechanism design dates back at least to 1961, when Columbia University economist and later Nobel laureate William Vickrey formally proposed a second-price sealed auction. As early as 1797, this auction method was used when author Johann Wolfgang von Goethe sold the manuscript of his epic poem Hermann and Longing Rothea, and was commonly used by stamp collectors in the 19th century, but was not officially proposed by Vickrey until 1961, and is now often referred to as the “Vickrey auction”. In Vickery auction mode, the highest bidder wins, but pays the second highest bid. This kind of auction stimulates the real preference of the bidder and delivers the lot to the person with the highest appraisal.

Vickery Auction is an elegant and efficient design that has been applied to the real world, adapting and updating according to new situations, and practice informs theory and vice versa. Like Vickery Auctions, the history of mechanism design as a formal discipline is a history of interweaving theory and practice, which is both deep and beautiful.

Contrary to game theory, which establishes a dimension of strategic interaction and explores the most plausible outcomes of behavior, the field of mechanism design does not begin with the game, but with the desired outcome. The purpose of mechanical design is to reverse-engineer some form of game so that the desired outcome (which may be characterized by efficiency, fairness, or certain behaviors) is balanced. In the case of Vickery Auctions, the ultimate goal is to entice participants to pay the maximum amount they are willing to pay without penalizing them.

There are longest opportunities for mechanism design applications in Web3. For example, Blockchain protocol may want to achieve the outcome of protocol participant’s honest behavior without deviating from the expected behavior. Alternatively, protocol may want to get accurate information about the value of a transaction in order to effectively allocate the Block short to the most valuable deals.

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, the design of the Blockchain space becomes more difficult.

The whole point of using permissionless Blockchain protocol is that you don’t have to trust any one entity or individual, just the “average” trust assumption that enough long Node in the Node running the protocol are honest.

But the irony of the Xu long Blockchain architecture is that every batch of transactions added to the chain’s history to be executed in a Virtual Machine maintained by the protocol is the product of a single Node unilateral decision.

You don’t know if you can trust this Node.

This is why Vickery auctions are rarely seen in the Blockchain space. A naïve implementation of Vickery auctions will soon run into problems of not being manipulated by trusted block producers. The problem is that a Block Producer can create a fake “shill bid” that is slightly lower than the soon-to-be winner, forcing the winner to pay almost all of their bid (instead of the actual next highest bid).

Fake bids from untrustworthy block producers effectively caused Vickery auctions to fall back to the 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. There is collusion from time to time

Another reason why the Blockchain mechanism is difficult to design is the collusion between Blockchain participants. For example, second-price auctions can easily collude with compensation payments. The rationale is simple: since the winning bidder pays the second-highest bid, the bidder can bribe the second-highest bidder to bid longest lower.

The academic literature on mechanism design does not worry longing about this issue. One reason for this 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 way among thieves.”) ）

However, in the context of Blockchain, potential colluders can often use smart contracts to provide reliable commitments for collusion to really work. The second reason is the lack of a mechanism to discourage collusion with compensation payments – the “price disclosure” mechanism, which only provides quotations and nothing else.

To make matters worse, protocol users may collude not only with each other, but also with (untrusted) Block producers (equivalent to bidder-auctioneer collusion in real-world auctions).

Defending against this last collusion is one of the main motivations for the burn portion of Ethereum’s EIP-1559 transaction fee mechanism. Without “burning” (or otherwise withholding these revenues from Block Producers), Block Producers and End Users can collude with compensation payments and evade any reserve prices that the mechanism is trying to impose.

3. You can’t rely on the rule of law alone

The problem of collusion is clearly not new. It has plagued various real-life mechanics for centuries, but if you look at the mechanic design literature, you might be surprised to see that it barely solves this problem. While the literature does positively discuss the motivations of individual actors for unilateral manipulation of mechanisms, it often leaves the question to undocumented notions of the “rule of law”. For example, participants in the mechanism may sign a legal contract that stipulates that they will not collude. If collusion is found, it will be brought to legal channels. Mechanism designers can help by creating a mechanism that is relatively easy to detect collusion.

There’s a tacit secret in much of long institutional design literature: reliance on the rule of law. While we can’t say that there is no rule of law in Blockchain protocol areas where there is no license—we often see law enforcement successfully prosecute crimes on licenseless Blockchain—the degree of rule of law is long than in traditional mechanism design applications.

If you can’t rely on the rule of law outside the mechanism, then the designer has a responsibility to solve the problem within the mechanism. This approach is ubiquitous in mechanism design decisions in the Blockchain space. In Ethereum protocol in particular, examples abound from EIP-1559 burning base fee benefits to validators slashing misconduct in its Consensus protocol.

4. The design shorter is larger

The design shorts in Web3 are larger than mechanism designers are used to. As a result, designers must rethink all given problems. For example, the long mechanism involves payments, and in traditional mechanism design applications, these payments will be made in fiat coin such as US dollars. Xu long Blockchain protocol have their own native coin, and this mechanism within the protocol is capable of manipulating these coin.

Imagine if you wrote an article about traditional mechanic design, and part of your mechanic description was: “Print a bunch of new coins and distribute them to a group of participants.” Outside the context of Blockchain, this is ridiculous. But when you’re talking about mechanic design in the context of Blockchain protocol, you can do that. protocol control coin, so some of the mechanisms protocol can minting Token or burn Token.

This means that designs that would not have been possible without native coins have become possible. For example, how do you motivate Bitcoin Miner to perform protocol as intended? These Block producers are incentivized through inflation rewards: printing new coins (Bitcoin). Such a design would not have been possible without a native coin.

5. Native coins may cause other problems

The previous reason underscores the power of native coins. There are two things you can do with native coin: “coin minting” (Bitcoin protocol minting new Bitcoin in a way that incentivizes Miner) and “Token burning” (Ethereum EIP-1559 transaction fee mechanism to burn ETH a way to defend against collusion). Native coins lurk dangers that don’t exist in traditional mechanism design: microeconomic design decisions can have macroeconomic consequences.

In the traditional design of mechanisms, there is no reason to worry about macroeconomic forces. Traditional auction methods have not had a meaningful impact on coin supply or inflation rates in the United States. This is a new challenge for the web3 design landscape. What can go wrong? I’ll tell you two examples, one about the minting of Bitcoin and the other about the burning of ETH.

As a result of the use of Block Rewards – incentivizing Miners by printing new coins – Bitcoin has been forced into Inflation. Therefore, it must also have a corresponding monetary policy to determine the rate of inflation and how it will evolve over time. Satoshi Nakamoto also set a hard supply cap of 21 million Bitcoin. Since there is a hard cap on the amount of Bitcoin, inflation must be close to zero.

If inflation is really zero, what should be used to incentivize Miner to keep running protocol and provide security for Bitcoin? There has been hope that transaction fees will make up for the missing Block Reward, although the chances of that happening are rather slim. As we all know, if the transaction fee is close to zero, then Bitcoin protocol will suffer from major security issues.

Princeton University computer scientists Miles Carlston, Harry Kalodner, Matthew Weinberg, and Arvind Narayanan point out another difference between transaction fees and block rewards in an article. While the Block Reward is the same for each Block (at least between two consecutive “Halving” Block Reward), Money Laundering can change by orders of magnitude – which in turn introduces new game-theoretic instability to the protocol. Protocol to this sense, macroeconomic decisions to fix supply ceilings have negative microeconomic consequences for the agreement and its participants.

Just as Block Reward minting is an inflationary force for Bitcoin, the burning of Money Laundering in EIP-1559 is a deflationary force for Ethereum. In Ethereum protocol (which does use inflation validators rewards), there is a tug-of-war between these two forces, with deflation often winning. ETH is now a net deflationary coin, which is a macroeconomic consequence of microeconomic motivational design decisions in protocol Money Laundering mechanisms.

Is deflation good or bad for Ethereum protocol? ETH holders love deflation because, all else being equal, their Token becomes more valuable over time. (In fact, this by-product may have ultimately driven public opinion to support the move to the EIP-1559 transaction fee mechanism.) However, the term deflation is intimidating to traditionally trained macroeconomists, reminiscent of Japan’s economic stagflation in the '90s.

Who’s right? Personally, I don’t think sovereign fiat coins are the right analogy for Crypto Assets like ETH. So, what is the correct analogy? This is still an open question that needs to be further explored by Blockchain researchers: why can deflationary monetary coin be used as a Crypto Assets to support Blockchain protocol, but not as a legal coin to support sovereign states?

6. The underlying stack cannot be ignored

In computer science, one of the things we aspire to achieve is modularity and clean abstraction, which gives us the ability to trust a part of a system. When designing and analyzing a part of a system, you may need to know the capabilities output by other parts of the system. But ideally, you don’t need to know how this feature is implemented under the hood.

In Blockchain protocol, we have not yet reached this ideal state. While builders and mechanism designers may like to focus on the application layer, they can’t ignore how the infrastructure layer works and its details.

For example, if you are designing an AMM market maker, you must consider the possibility that an untrusted block producer is responsible for the ordering of transactions. Or, when you consider designing a Money Laundering mechanism for a (L2)rollup, you must pay not only 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, the effective mechanism design for one layer requires a detailed understanding of the other layers. Perhaps, as Blockchain technology becomes more and more mature, we will clearly play people for suckers of different layers. But we’re certainly not there yet.

7. It is required to work in a computationally constrained environment

The Blockchain protocol implementation of “Computer in Sky” is a computationally constrained environment. Traditional mechanism design focuses only on economic incentives and ignores computational problems (e.g., the well-known Vickery-Clark-Groves mechanism is not feasible for highly complex distributive problems).

When Nisan and Ronen proposed algorithm mechanism design in 1999, they pointed out that we really needed some kind of computational traceability to make the mechanism practical in the real world. Therefore, they suggest limiting attention to the mechanisms of computation and communication that use a certain amount of longest (rather than exponential) function extensions as a parameter to the problem.

Since the Blockchain protocol Virtual Machine is very computationally intensive, the on-chain mechanism must be highly lightweight – long term time and communication are necessary, but not sufficient. For example, scarcity is the main reason why AMM completely dominate Ethereum Decentralized Finance, rather than more traditional solutions like limit order books.

8. It’s still in its early stages

Often, when people say that web3 is still in its early stages, they’re either referring to an investment opportunity or adoption. But from a scientific point of view, we are even earlier than that. It’s only going to get harder – although the opportunities are huge.

The benefits of working in a mature field of study are taken for granted by all. There are well-established models and definitions. Consensus was reached on the most important issues. Key coordination has also been developed in the measurement of progress. There is a public vocabulary and a large public knowledge base. There are also ways to speed up, including heavily vetted textbooks, online courses, and other resources.

At the same time, in longer of the Blockchain world, we do not yet know the “right” models and definitions 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 protocol? 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 presents unique opportunities.

Mechanism design has always been a useful tool for the Internet application layer – such as real-time advertising auctions, or two-sided market design, which is prevalent in today’s longest online consumer applications, from e-commerce to grouping.

But in Web3, mechanism design also informs design decisions about the infrastructure itself.

Back in the seventies and eighties of the last century, when Internet routing protocols were still in the discussion and design stage. As far as I know, there is not a single professional in incentive and mechanism design who has a place in it. In hindsight, we now realize that such people could have provided useful information for design. Meanwhile, in web3, incentives were part of the discussion from the start with the release of the initial Bitcoin White Paper.

The confusion surrounding 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 that we have the opportunity to shape the trajectory of this technology at the right time and in the right place. So while there may not be longest textbooks in this area, there will be one day, and what these books will describe is what we are doing right now.