A commonplace meme these days is that building and launching a cryptonetwork is more like manufacturing hardware (or a rocket) than it is like building a web 2.0 product. So how should we go about building them?
Tackle the monkey first.
The comparison to rockets may well be an exaggeration, but it’s true that––as with hardware and rockets––cryptonetworks cannot be changed as readily as websites can once they are launched.
The stakes are also much higher. As the DAO hack showcased, even a single bug can prove to be catastrophic and cost users tens of millions of dollars. So, moving fast and breaking things simply doesn’t work.
@astroteller at GoogleX likes to say that if your task is to teach a monkey to recite Shakespeare while standing on a pedestal, you should tackle the monkey part first and spend zero time on the pedestal.
In other words, de-risk the riskiest parts of your endeavor first. Front-load the work that will lead to the greatest rate of learning about whether what you’re trying to build is even possible. For decentralized networks, tackling the monkey tends to mean that you have to:
Specify the protocol at the level of specific messages sent by each type of node. If you think of your protocol as a state machine, what are all of the possible states that it can enter as a system? How will react in each one of them?
For an excellent example of a great specification, look at Signal’s breakdown of their Double Ratchet Algorithm.
Formalize your thinking about the network’s threat model and security guarantees. What are the primary attack vectors? What assumptions have to hold true for the system to remain secure? How should we reason about the cost of attacking the system?
Provide a rigorous argument that justifies the network’s economic model. How should we reason about the network’s incentive structures? Are they economically viable?
Provide a rigorous argument that the protocol is incentive compatible––that is, that the rational equilibrium for all participants is to behave according to the protocol’s rules.
Finally, it’s never possible to write a full specification for a complex system without also writing code. So, in tandem with the above, also work toward implementing a basic prototype. Use it in simulations of the network to test your assumptions about security and performance.