Basic Economics and Probability Theory

Mechanism design

Mechanism design theory is a field of economics distinguished by a Nobel Memorial Prize in 2007. It combines probability and game theory in the design of multiplayer systems.

It can be thought of as solving the inverse problem of game theory.

• Game theory studies the outcomes of a given multiplayer game (which could be literal games or, more generally, any situation involving multiple players with conflicting objectives, such as a war or a deal negotiation).

• Mechanism design theory starts from the outcomes (for instance, maximizing the gains of players) and seeks to determine game mechanisms that would achieve them. The idea is to start from the end goal and work backward to design a mechanism (a game) that achieves it.

A key distinction is that game theory thinks in terms of strategy (what players should/shouldn't do), whereas mechanism design thinks in terms of incentives (why players should/shouldn't do things).

It's a powerful way to think about software development in general, which is particularly important in blockchain development. In traditional web development, we may think in terms of features, such as cool graphics and a good story. Allow people to do cool things, and they will come. However, because of their immutability and the high cost of the transaction, smart contracts also need to have the right economic incentives baked in for people to use them (and hence, for the contract owner to achieve their objective).

As the contract owners, we may aim at maximizing our profits, but so does each one of our players, and if they don't have a good chance of achieving their goal, they will simply not enter our game, which would end up going against our own objective!

So, we have to program the right incentives in any function of our smart contracts by asking ourselves the question, “Why would users even click?” and giving it a fair answer. With the transparency of the blockchain discussed in the previous lesson, the rules need to be laid out very clearly. Everyone should know what they're in for.

This is another difference with traditional server-client architectures. In Web2, to some extent, we can pursue our goal of maximizing profits while obfuscating what the true incentives of our players are. We could have a black box system that's unfair to them but attracts users through good marketing or because all their friends already use our platform.

Thinking in incentives

Generally speaking, a P2E has two types of participants:

• The House

• Players

In developing our games, we want to align the incentives of the different ...