Why Token Engineering is Critical
Taking the time and care to properly design economic systems is an essential part of blockchain projects, including considering possible attack vectors.
Here at Juri we put a lot of time and effort into modelling the economics of the systems we’re building, and take care to design mechanisms which ensure the alignment of incentives between the various actors. Too often we see people or teams jumping into development or launching a token without properly taking the time to understand or design the economics of the underlying system, hoping those elements will fall into place naturally later. Unfortunately, that doesn’t seem to be the way it works!
In this blog post, I will outline some of the key factors to consider when designing a decentralised network. In a later post, I’ll explain some of the things we found during our own exploration.
Why Should I Care?
Economic systems approach an equilibrium, and to take the long view – the outcome which is most strongly incentivised is the outcome which materialises. That’s self evident. Unfortunately, capturing the intent of the what you want that outcome to be is… hard. Very hard.
Nick Bostrom’s paperclip maximiser explains better than I ever could how difficult it is to capture intent.
Suppose we have an AI whose only goal is to make as many paper clips as possible. The AI will realize quickly that it would be much better if there were no humans because humans might decide to switch it off. Because if humans do so, there would be fewer paper clips. Also, human bodies contain a lot of atoms that could be made into paper clips. The future that the AI would be trying to gear towards would be one in which there were a lot of paper clips but no humans.
That sounds absurd, right? Except its not. Humans tend not to behave like this because we have high Kolmogorov Complexity; that is to say we want lots of things. We want money and respect, and family who love us, and we have values which we will not violate (and likely other values we only violate under significant pressure,) and these complexities prevent us from doing things like razing everything to maximise the number of paperclips (mostly). A designed system, like an AI designed to maximise paperclips, or a novel economic system that might be launched alongside a blockchain project are often much simpler. They say things like…
Maintain token price at 1 USD.
Maximise hash rate on the network.
Because these objectives are much simpler, we need to be sure to frame them in the right way, to make sure we’re incentivising what we actually want, not just what we think we want.
Token Engineering, Mechanism Design, and Game Theory
I like to use the term Token Engineering to collectively refer to this field, though it could also be referred to as Mechanism Design (Ocean Protocol describe this much better than I could.) It takes elements of of economic game theory, but importantly, it is far more than theoretical. Traditional game theory is the way mathematicians and economists break complex decision making processes into a series of easy-to-process (usually competitive) elements called games. Games are usually non-deterministic, meaning there is an element of uncertainty involved. Sometimes that element is the actions of other players, and sometimes it is the outcome of some stochastic event.
You’re probably familiar with some popular games – the prisoners dilemma is a common one.
You can probably see how this maps well into blockchains and decentralised networks – we have a set of incentives, and a number of players, and each player is trying their hardest to maximise some variable they care about.
We like to make assumptions like at least 66% of players are honest, or at least 51% of players are honest, but an important part of token engineering and mechanism design is ensuring that the rational outcome of the “games” that we’ve created is for actors to be honest. Like I said in the introductory paragraph, above – if the incentives are aligned such that players profit from cheating, players are going to cheat.
The Importance of Adversarial Thinking
It’s nice for us to be able to think that because we reward people for performing some action, they’re going to perform that action honestly (yay, our incentives are aligned!) but the systems we design aren’t that simple. It’s at times like this it pays for us to be able to put our adversary hat on.
Adversaries aren’t necessarily actors who want to destroy the network, but some are. Sometimes they’re just incentivised to point the network in a slightly different direction. In Latin there is a saying cui bono – who benefits?
Who benefits from an attack? There are some attackers who exist in all tokenised ecosystems. A non-exhaustive list might include…
- Pure trolls (who want to damage a network because it is amusing)
- Agents with a short position in your token (therefore they profit in making it vulnerable)
- Agents with a long position in a competitor token (therefore indirectly profiting from exposed vulnerabilities)
Other attackers might be specific to your use case. Here is another (non-exhaustive) list of agents who might profit from attacking the Juri Network.
- Lazy nodes, who want to be paid fees for doing work they haven’t done (I jokingly refer to this as a High Schooler Attack)
- Participants who have staked a lot of money (who want to make sure they get rewarded)
- Underwriters who are exposed to a large liability
- Competing underwriters, who want to increase costs of operation for their competitors
In all cases, the solution is to align incentives. Rational economic actors should work to maximise their profit, and in most cases, all the agents in a system are rational (or, rational enough.)
The expected value of carrying out an attack should be lower than the expected value of behaving honestly. Sitting down and thinking of all the ways one might attack a network is hard – thinking like an adversary is a skill. Of course, one doesn’t need to reinvent the wheel with every new project.
There are existing building blocks for creating decentralised networks, and combinations of these building blocks can be used to help bootstrap your own design.
Token Engineering and mechanism design is no joke, but in many projects its considered as an after thought. It shouldn’t be – taking the time to carefully consider the economic systems we’re launching into the world should be table stakes for any blockchain project.