a16z: Exploring 8 Challenges in Blockchain Mechanism Design

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

Original translation: 0x xz, Golden Finance

Studying a field deeply teaches you to recognize that real-world problems are poor disguises of well-solved problems. For example, when I taught algorithm basics, students learned how to recognize problems that boiled down to shortest path calculations or linear programming.

This kind of pattern matching works just as well 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, putting new spins on old ideas. However, the unique challenges and limitations of permissionless blockch人工智能n protocols often force a rethinking of the fundamentals of seemingly settled 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 field of mechanism design dates back to at least 1961, when William Vickrey, an economist at Columbia University and later Nobel laureate, formalized the second-price sealed-bid auction. 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 formalized by Vickrey until 1961 and is now often called the Vickrey auction. In the Vickrey auction model, the highest bidder wins, but pays the second-highest bid. This auction stimulates the true preferences of bidders and delivers the item to the person who estimates the highest bid.

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

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 a game so that the desired outcome (which may be characterized by efficiency, fairness, or certain behaviors) is balanced. In the case of a 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 (and do not deviate from expected behavior). Or, a protocol may want 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, but the challenges are even more unique in the blockchain context.

1. Lack of trust

Without a trusted party to enforce the mechanisms, designing in the blockchain space becomes much more difficult.

The whole point of using a permissionless blockchain protocol is that you don’t have to trust any one entity or person, you just need 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’s 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 is unclear 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, thus 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, 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

Another reason why blockchain mechanism design is difficult is that there can be 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, the 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 compensatory 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 compensatory 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 actually work. The second reason is the lack of a mechanism to suppress and compensate for payment collusion – a price disclosure mechanism that only provides quotes and nothing else.

Worse, protocol users could potentially collude not only with each other, but also with (untrusted) block producers (equivalent to collusion between bidders and the auctioneer in a real-world auction).

Protection against the 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 compensating payments and evade any reserve price the mechanism attempts to impose.

3. We cannot rely solely on the rule of law

The collusion problem is obviously not new. 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 address head-on the incentives of individual actors to unilaterally manipulate the mechanism, but it usually leaves the problem to some unrecognized notion of the “rule of law.” For example, the participants in the mechanism might sign a legal contract that stipulates that they will not collude. If collusion is detected, it is 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: the reliance on the rule of law. While we cannot 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 extent of the rule of law is much less than in traditional mechanism design applications.

If you can’t rely on the rule of law outside of the mechanism, then it’s the designer’s responsibility to solve 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 who misbehave in its consensus protocol.

4. Larger design space

The design space in web3 is larger than mechanism designers are used to. Therefore, designers must rethink all given problems. For example, many mechanisms involve payments, which in traditional mechanism design applications 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 distribute it to a bunch of participants. Outside of the context of blockchain, this is ridiculous. But when youre talking about mechanism design in the context of a blockchain protocol, you can absolutely do this. The protocol controls the currency, so part of the protocols mechanism can mint tokens or burn tokens.

This means that some designs that would be impossible 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 currencies may bring other problems

The previous reason highlights the power of native currencies. You can do two things with native currencies: 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 currencies lurk with dangers 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 auctions have not had a meaningful impact on the money supply or inflation rate in the United States. 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 a corresponding monetary policy to determine 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 truly 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 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 are close to zero, then the Bitcoin protocol will suffer major security issues.

Princeton 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 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 microeconomically motivated design decisions in the protocols 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 swayed public opinion in favor of a shift to EIP-1559’s transaction fee mechanism.) Yet the term deflation scare classically trained macroeconomists away, bringing to mind Japan’s economic stagflation of the 1990s.

Who is 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 can deflationary currencies 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 output by other parts of the system. But ideally, you dont need to know how this functionality is implemented under the hood.

We have not yet reached this ideal state in blockchain protocols. 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 have to consider the possibility that untrusted block producers are responsible for transaction ordering. Or, if 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. Requires to work in a computationally constrained environment

The computer in the sky implemented by the blockchain protocol is a computationally constrained environment. Traditional mechanism design focuses only on economic incentives and ignores computational issues (for example, 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 for mechanisms to have practical meaning in the real world. They therefore proposed restricting attention to mechanisms for computation and communication that scale with some amount of polynomial (not exponential) function of the problem parameters.

Since blockchain protocol virtual machines perform very little computation, 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. Still in the early stages

Usually when people say web3 is in its early stages, they’re referring to either the investment opportunity or adoption. But from a scientific perspective, we’re even earlier than that. It’s only going to get 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 critical coordination on how to measure progress. There is a common vocabulary and a large public knowledge base. There are also pathways to acceleration, including well-reviewed 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 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 field’s immaturity is a challenge. But getting involved early — now — also presents 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 design that is prevalent in most online consumer applications today, from e-commerce to group buying.

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

Think back to the 1970s and 1980s, when Internet routing protocols were still being discussed and designed. As far as I know, no one with expertise in incentive and mechanism design had a seat at the table. In hindsight, we now realize that such people could have provided useful information for the design. Meanwhile, in web3, with the release of the original Bitcoin whitepaper, incentive mechanisms were part of the discussion from the beginning.

The confusion surrounding the right 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 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.

This article is sourced from the internet: a16z: Exploring 8 Challenges in Blockchain Mechanism Design

Related: Community Ecology | Learn about the four highlights of TRONs first quarter report in 2024 in one article

Messari, a top crypto data research organization, recently released the TRON Q1 report for 2024. The report shows that TRON has performed well in terms of protocol revenue, TRX deflation, DeFi TVL, and stablecoins. In the first quarter, TRON protocol revenue increased by 7.2% month-on-month, reaching a record high of US$128.1 million, ranking third among all blockchain networks, second only to Ethereum and Bitcoin. The protocol revenue comes from the TRX burned by users to obtain resources and pay fees. The report shows that TRX continued to maintain deflation in the first quarter, and its circulation dropped from 88.2 billion to about 87.7 billion. The TRON network is one of the few deflationary L1 networks. In terms of DeFi, TRON also performed well. The report shows that TRON DeFi TVL…