Written by Michael Zargham·
On decision making under uncertainty and with respect paid to complexity
The ideation stage of a blockchain project is intoxicating. Raw creative power is thrown against the wall in the form of whiteboard drawings and essays. Narratives around these ideas crystalize into Descriptive Models that capture the imaginations of investors and future users alike.
Let us suppose you’ve already started core development and raised an appropriate sum of money that you can follow through on getting the job done right. As I have expressed several times in my articles, Token Engineering has a lot in common with Swarm Robotics, Operations Research and Control Engineering — all of which share a heavy dependence on the mathematics of optimization and decision making, which due to the social nature of these networks brings us to the mechanism and market design subfields of economics, as well as behavioral psychology.
All of the above are tools, but none of them are a process for achieving the goal of bringing something into the world that matches your narrative. I highlight something because at this point all you have is some hardware and a story about what it can do. I used the term hardware because in robotics and more generally in engineering the hardware is comparably immutable, and you need to have some before you can start trying to make it do anything. So setting your network, your nodes or developing the core contracts that will provide the plant of your system can be thought of as the hardware of your economic robot.
For exploratory purposes, lets think of our blockchain network as a business robot. After all, it should be facilitating some real exchange of value, likely in the manner of a two sided marketplace, but instead of a platform provided by a centralized business (managing a bunch of employees and infrastructure, etc), an arbitrary time varying pool of agents (human or bot)coordinating via a peer to peer protocol designed to provide the same enabling service as a centralized platform might. Under this definition, designing a blockchain economy is literally a swarm intelligence design problem.
https://en.wikipedia.org/wiki/Swarm_intelligence
Now that we have established that we’re solving a Swarm Business Intelligence problem, potentially at society scale. How do we proceed?
In the software industry, particularly in the consumer facing internet products, the mantra is “build it, break it, fix it.” This is a very effective strategy for comparatively low complexity systems with high tolerances to error, but awful for high complexity systems with high cost of failure.
Let’s reduce this to a game:
There is one player: the card drawer, who pays X per draw.
The deck has N numbers and S suits.
There are W watchers, and each watcher has a set of cards for which they are willing to pay $1, but the each individual watchers preference maybe any member of the super set of the N x S total cards.
The card drawer then draws a card and reveals it, and each watcher reveals whether they want that card. The drawer then has the choice of taking the payout for that card, or forgoing that payout to pay for another draw either restricting the draw to the same suit or to the same number.
The player may effectively work through the deck, iterating somewhat systematically but completely non-deterministically, always making a decision with incomplete information. Stop and take the payout of the current card or pay to draw again?
The interesting thing about this game, is that if W is relative large, X is small and if you’re deck has good watcher fit (the watchers preferred sets are on the same order as the deck and there is a lot of overlap in their preferences) then it is a good idea to play this game, and you probably won’t need to draw too many times before getting a pretty good payout. This is the case for a internet based application developed against a good idea.
However, as complexity rises X starts to get larger, and even if you are playing with the same size deck (which you probably are not), the preferred sets are getting a lot smaller because most cards don’t work at all, and even the cards some people like are less likely to be liked by many. This is the case for more traditional engineering tasks and the profit maximizing solution becomes ‘don’t play the game’ under high complexity conditions.
Yet we accomplish high complexity engineering marvels across our society from suspension bridges, to satellites, to mine-sweeping hovercraft. If the high complexity version of this innovation game is so hard, how did we win so many times.
Engineering process recodes the rules of the game — in stead of “build it, break it, fix it” there are Requirements, Design and Testing of Systems, subsystems, and components. At each layer goals, interfaces and limitations are captured in requirements so that they can be designed and testing in parallel, then integrated into a working whole which is only then presented to the crowd for consideration.
Sure, this costs 10X or even 100X, but for a high complexity system the probability of getting a working solution, much less a preferred solution has fallen off exponentially. Corrected for the risk (and cost) of failure, this game is made worth playing long after the “build it, break it, fix it” game becomes un-win-able.
It is my firm belief Swarm Business Intelligence problems, are of the latter type and that engineering practice on the order of robotics rather than software development practices are required to make the game worth playing.
At BlockScience, we are developing and practicing the engineering process as it is applied to blockchain-enabled economies.
This series is intended to help flesh out core concepts of Token Engineering. This is the preliminaries of what will eventually be a one semester course working through these topics. Fair warning I may not write these in order.
Token Engineering 101:
0) Why Engineering is Necessary
1) Requirements, Design and Testing
2) System Scope, Component Definitions and User Roles
3) Visual Modeling Syntax for Economic Systems
4) Action Spaces, Invariants and Attribution
5) Mechanism Design
6) Model Testing and Design Validation
7) From Design to Development
8) Data Engineering for Testing Apparatus
9) Benchmark Testing Components
10) Integration and System Testing
11) Public and Private Operational Analytics
12) Engineering Ethics, Stewardship and Governance
About BlockScience
BlockScience® is a complex systems engineering, R&D, and analytics firm. Our goal is to combine academic-grade research with advanced mathematical and computational engineering to design safe and resilient socio-technical systems. We provide engineering, design, and analytics services to a wide range of clients, including for-profit, non-profit, academic, and government organizations, and contribute to open-source research and software development.
