The rapid development of the blockchain ecosystem has given rise to a new engineering discipline in the form of token engineering. What makes this discipline particularly complex is that we are dealing with the design of cyber-physical systems. The software (cyber) and social (physical) components in blockchain systems are inextricably linked. They operate on different time scales and interact differently depending on context. It is often assumed that understanding the rules of a system combined with the engineering know-how required to build the software is enough. But automated systems that interact with humans often behave in ways we don’t expect.
So how do we go about engineering these kind of systems?
Understand the whole system
Meddling with a small part of a complex system without first understanding how the whole system works is a recipe for unintended consequences.
When dealing with these complex cyber-physical systems we have to take a systems approach. Systems thinking is a holistic approach to analysis that focuses on the way that a system’s parts interrelate, how systems work over time and how they operate within the context of larger systems. Much like natural systems, cyber-physical systems live in an ecosystem of actors and other systems that all influence each other.
There is a good introduction to systems thinking on the cadCAD community discord. For those who want to dig a bit deeper “Thinking in systems : A Primer” by Donella H Meadows and Diana Wright is a good place to start. Leyla Acaroglu also does a good job of outlining the fundamental concepts of systems thinking.
At this stage of the design process we are trying to do two things. Build stakeholder taxonomies by identifying stakeholder groups, their possible actions, and the form their incentives or individual utilities might take. Secondly we want to lay out the system dynamics and agent goals.
We call this system mapping. During system mapping we are trying to identify what concepts, constructs and stakeholders are relevant to our model and to begin to define their relationships to one another, as well as what the goals are for the system as a whole.
Tools for system mapping
There are a number of tools that help us take a step back and look at the dynamics and interconnections within the system we are trying to model.
When filling out this canvas you are putting the purpose of the system at the centre and lay out the key players, contributors, and/or users in your ecosystem in the concentric circles radiating outwards.
Use the Motivation Matrix to see who creates value and who shares value with whom in the system.
Other useful tools include connected circles maps and brain dump maps.
This article barely scratches the surface of the theory and practice of systems thinking. For those interested in a deeper dive, here are some additional resources:
- Systems Innovation Academy
- New England Complex Systems Institute
- Sante Fe Institute’s Complexity Explorer
Formalising the design
Now that we have a sense for the overall design of the system we can start formalising our insights using causal loop diagrams and stock and flow diagrams.
Causal loop diagrams
A causal loop diagram (CLD) is a causal diagram that aids in visualising how different variables in a system are interrelated. They can be thought of as sentences that are constructed by identifying the key variables in a system (the “nouns”), and indicating the causal relationships between them via links (the “verbs”). By linking together several loops, you can create a concise story about a particular problem or issue.
Stock and flow diagrams
Stock and flow diagrams provide a richer visual language than causal loop diagrams. There are six main elements: stocks, flows, converters, connectors, sources and sinks. Below is an example stock and flow diagram as used by the token engineering community. For an in-depth explanation of this diagram see Abbey Titcomb’s article “Deep Dive : Augmented Bonding Curves”
For a deeper understanding of this part of the process see the following resources:
- MIT OpenCourseware : Introduction to system dynamics
- MIT OpenCourseware : Introduction to modelling and simulation
- Complexity Explorer : Introduction to agent based modeling (paid)
- Mathematical foundations (advanced)
Modularising the logic and building a model
Now that we have a more formal representation of our understanding we can start modelling our problem in cadCAD. cadCAD is an open-source Python package that assists in the processes of designing, testing and validating complex systems through simulation.
The first step in this process is producing a differential specification as in the example below. The differential specification syntax matches very closely with the code structure used in cadCAD models. Producing a specification in this format modularises the logic used to solve the problem. This allows us to swap out strategies and mechanisms easily as our understanding evolves.
Refining the models
Once we have a working model it’s time to refine. Our first model will most likely not be optimal, so we need to do quantitative and qualitative backtesting to refine the model. cadCAD also offers Monte Carlo simulations and parameter sweeping to help identify optimal parameter values and failure modes.
Evaluate and improve the running system
Once a system has been designed and implemented cadCAD can serve as an invaluable tool in Computer Aided Governance (CAG) as proposed by Jeff Emmett and Michael Zargham. CAG is a decision support process that leverages a digital twin (modelled in cadCAD) of a running blockchain system.
Having a digital twin of a running system allows token engineers to :
- evaluate proposed changes to the system
- test parameter sensitivity
- explore success criteria
- explore failure modes
- evaluate behaviours or polices
- make recommendations to governing bodies
This process is just a start and is likely to evolve as the community deepens their understanding and experience. Much of the content for this article has come out of discussions on the cadCAD discord, the commons stack telegram group and personal input from Michal Zargham, Jeff Emmett and Sebnem Rusitschka, among many others.