Tokenization - Token engineering Methodology, patterns and tools.

1. Engineering, Game Theory, and More
   This section relates token design to other fields.
   1.1 The Tacoma Narrows Bridge
   In the first week of my engineering studies, our solemn-faced professor showed us this:

How did the bridge collapse? The designers did anticipate for wind, after all. However, they failed to anticipate that the particular wind patterns would set up resonance with the bridge itself. When you have an appropriately timed force applied to a system in resonance, the amplitude of the resonance grows over time. The figure below illustrates, where green = non-resonant and red = resonant = disaster.

The video was to teach about responsibility. The designers of the bridge could have prevented the disaster by being thorough, and applying appropriate theory, practice, and tools. Other professors showed that video several times over the years during my studies. Those viewings culminated in a ceremony to receive iron rings upon graduation. All Canadian engineers have these rings. According to legend, the rings are forged from the metal of a collapsed bridge.

1.2 Game Theory and Mechanism Design
Game Theory is a scientific field that analyzes incentives, from an economic standpoint. It has a counterpart in economics for designing (synthesizing)incentivized systems, called Mechanism Design. In fact Mechanism Design is really the field for design of tokenized ecosystem, in theory. Researchers in that field have come up with a lot of great theory over the years, at literally Nobel prize levels of quality. Closely related is Economic Game Theory.
However, traditionally there hasn’t been a good way to reconcile that theory with practice. After all, how often does an academic economist (or anyone, really) get a chance to deploy an economy? Yet this is the exact problem we are confronted with in designing tokenized ecosystems. The closest are likely video game economies and public policy design.
However, it turns out that if you zoom in on Mechanism Design with a few practical constraints, you end up with Optimization Design! People doing Optimization Design have a tremendous amount of practical experience deploying optimizer systems over the years. Myself included: my first and second startups (ADA, Solido) did exactly that, for use in industrial-grade circuit design.

1.3 Other Related Fields
Many other fields have something to say about token design as well; at the very least in the sense that experts from those fields will find that many of their skills translate well to token design. These include everything from electrical engineering to complex systems, from economics to AI. I list a few below. And of course many of them have roots in good ol’ cybernetics.

1.4 Engineering and Token Design
What should we be calling this field in which we design tokenized ecosystems? I list some options below.

The first four terms are economics-biased. That’s fine; it makes sense for analyzing price movement, valuations, and so on.
I’m trained as an electrical engineer (EE). EEs doing circuit design have theory, have practice, and build systems that just work, such as the screen you’re reading and the chips that power it, to the lights over your head.
Engineering is about rigorous analysis, design, and verification of systems; all assisted by tools that reconcile theory with practice. Engineering is also a discipline of responsibility: being ethically and professionally accountable to the machines that you build, as illustrated by the Tacoma Narrows Bridge viewings and iron rings.
I saw the rise of the discipline of software engineering in the 90s; that made sense as it encouraged rigor and responsibility.
I’d love to see token ecosystem design become an engineering discipline, side-by-side with electrical engineering, software engineering, civil engineering, aerospace engineering, and so on. This implies that token ecosystem design would also become a field of rigorous analysis, design, and verification. It would have tools that reconcile theory with practice. It would be guided by a sense of responsibility. It would be token engineering.
[Note: As for “token” vs “incentive”, “token” is shorter and easier to compare to its economics counterpart “Tokenomics”.]
The image below shows how these fields relate. The goal is a practice of token engineering.

1. Token Design as Optimization Design
   Token design is like optimization design: at a high level, you encode intent with a block rewards function aka objective function, and you let it fly. As is often the case, Simon de la Rouviere saw this one first.
   It gets more specific than that. Token design is especially like evolutionary algorithms (EAs), where there are many agents “searching” at once and there is no top-down control of what each agent does. Agents live and die by their block reward or fitness. The table below summarizes the relation.
   With such similarities, we can use best practices from optimization / EA to when doing token design. This is great news, because many people are Jedis in designing EAs and optimization systems.

Let’s elaborate on each row in the table.
2.1 Goals
Both tokenized ecosystems and EAs have goals, in the form of objectives (things to maximize or minimize) and constraints (things that must be met). To get fancy, this can even be stochastic.
The tokenized ecosystem might give block rewards for an objective function of “maximize hash rate” whereas an EA objective might be “minimize error” in training a deep net. Constraints might be “must have stake ≥ threshold to participate” or “deep network layers=100” respectively.
Variants include single-objective optimization (1 objective, 0 constraints), constraint satisfaction (0 objectives, ≥1 constraints), and multi-objective constrained optimization (≥2 objectives, ≥1 constraints).
2.2 Measurement & Test
To test / measure success against the goals (objectives & constraints), a tokenized ecosystem relies on proofs and an optimizer measures fitness using e.g. a simulator.
For example, a Bitcoin node proves that a user was hashing by verifying that the user’s supplied nonce solves the the cryptographic puzzle.
An optimizer might test the goodness of a circuit by running a SPICE simulation of the circuit’s differential equations; simulation results can be verified by testing whether they indeed solved Kirchoff’s Current and Voltage Laws.
2.3 System Agents
In both systems, agents run about “doing things”.
In a tokenized ecosystem, network stakeholders such as miners (or users more generally) do whatever it takes to earn block rewards. They jostle about, doing what it takes to get more token rewards. For example, in Bitcoin some agents might design, build, and run ASIC chips to get higher hash rate. Other agents might pool their existing compute resources. The system does not need to explicitly model all stakeholders in the ecosystem. For example, Bitcoin doesn’t have specific roles for banks or nations or companies; it’s mostly all about the miners.
In an EA, you have individuals in a population. If they’re “good” they have higher fitness. For example, an individual may be a vector of 10,000 weights for a neural network. “Actions” of individuals are basically when they survive and have variants made of them, via operators like crossover (e.g. interpolation) or mutation (e.g. randomly perturbing each parameter).
2.4 System Clock
Each system has a clock, implying a time dimension by which progress is made / convergence is happening.
Batches. Typically, agents are processed in batches or epochs. A tokenized ecosystem periodically generates a new block and gives block rewards. The new block points to the old block; and new work in the system will add to the new block; and so on. This linked list of blocks implies a Lamport-style logical clock. In EAs, each batch is a generation where a whole population of individuals gets updated at once. Each generational loop might include: evaluate individuals, select the best, let them make children, repeat.
Continuous. In some systems, agents are processed more continuously rather than batches. These systems usually takes a bit more work to conceptualize, but may lead to better properties for some problems. For example in tokenized ecosystems, a Stellar transaction only needs validation from quorum slice participants, or another node gets added to a DAG (directed acyclic graph) like in Iota. In EAs, we have steady-state evolution where one individual at a time is replaced.
2.5 Incentives & Disincentives
The system itself cannot control how the agents behave. (Or at the very least, it shouldn’t need to control them.) As such, top-level behavior must be an emergent property of bottom-up actions by agents. This is necessary for tokenized ecosystems; otherwise they’d be centralized! It’s not an absolute must for EAs, but nonetheless a broad set of EAs take this approach for simplicity / elegance or meeting other design goals.
This means the system can only reward or punish behavior, aka carrots or sticks, aka incentives and disincentives. In designing the system, we design what rewards or punishments to give, and how to give them.
In tokenized ecosystems, rewards take the form of block rewards, and punishments by slashing stake. The former is typically the objective function; the latter is some (but not all) constraints.
In EAs, reward and punishment both come down to which individuals are selected to be parents for the next generation. Examples: randomly choose two individuals and keep the best, repeating until full (tournament selection); and chance of selection is proportional to fitness (roulette wheel selection). Crucially, the EA does not need to steer the individuals by e.g. providing a derivative. This is why a tokenized ecosystem is most like an EA, versus gradient-based optimizers that give top-down directives (using gradients to choose new individuals).

1. From Optimization Methodology to Token Methodology
   3.1 Introduction
   This section is some initial notes towards treating token design like the engineering discipline it deserves to grow into.
   First, I describe a structured methodology for optimization design. Then I describe how a similar methodology could be applied for incentive design.
   Next, I describe key tools used in circuit design: simulators and CAD tools; and how they might be applied for circuit design.
   Finally, I start to enumerate some design patterns.