Releasing a decentralized network isn’t quite the same kettle of fish as releasing a web application. We recently wrote on how we need to start adapting development and release practices to the world of decentralized application development. With that in mind, we wanted to share some details of how we’re approaching the first release of the Keep network client and its associated smart contracts.

Slow and Steady

In structuring our first release, we’ve emphasized care over speed. Software engineering has many practices aimed at ensuring quality that are easy to ignore in a new project in the name of expediency. In decentralized networks, however, the price of ignoring those practices can be much greater — bug fixes are harder to deploy, and in Keep’s case a poorly-placed bug can lead to a significant shift in the security guarantees the network provides. For that reason, we’ve been building the beacon in three high-level phases:

Prototyping From January through April, we worked on a prototype of a simplified threshold relay with the right high-level actions but simple (and not incentive-safe) versions of all of the algorithms that will be used for running the relay in practice. This let us get a feel for what independent pieces were needed and how they fit together. True prototypes are meant to be thrown away, and that’s what we did at the end of April.

From January through April, we worked on a prototype of a simplified threshold relay with the right high-level actions but simple (and not incentive-safe) versions of all of the algorithms that will be used for running the relay in practice. This let us get a feel for what independent pieces were needed and how they fit together. True prototypes are meant to be thrown away, and that’s what we did at the end of April. Reconstruction Taking the lessons we learned from our prototype, we started building a version of the simplified relay that would work roughly the same as the prototype, but with well-isolated components, clearly defined interfaces, good tests, and a solid base layer for our on-chain contracts.

Taking the lessons we learned from our prototype, we started building a version of the simplified relay that would work roughly the same as the prototype, but with well-isolated components, clearly defined interfaces, good tests, and a solid base layer for our on-chain contracts. Elaboration Once the system’s foundation has been laid and tested, we can confidently layer more complex features. Some of these features are nice-to-haves, like staking delegation. Others are required to ensure trustless and secure operation of the beacon.

Parallel Paths

The phased approach above lets us develop the more complex aspects of our protocol design without blocking the forward movement of development. Protocol design, in this case, refers to figuring out the incentives and mitigations needed for the threshold relay to operate within our desired security parameters, and creating a design for how the network will function based on that information.

Promethea Raschke is leading this aspect of the Keep threshold relay, which will be published as a yellowpaper. The high-level blocks that will be involved are more or less decided, but the protocol design work will determine some of the finer aspects of staking, payments, messaging, and the particular algorithms used for distributed key generation, group member selection, and signing.

Audits

One last piece that we need to think about as we approach mainnet launch is code audits. We’re planning on how best to fit audits into our process. In particular, we’ll identify how we can do as much auditing as possible in parallel with our development process. In cases where audits require understanding of the underlying algorithms, we’d like to start auditing the algorithms while development proceeds. In cases audits requires auditing our dependencies, we’d like to start those audits ahead of time, ensuring they provide any guarantees we rely on. Finally, in cases where we cross the finish line on one of the components of the system before others, we plan to prioritize audits for those components.

What’s Next

Our approach to reaching mainnet is twofold: we have given ourselves the time to prototype, while parallelizing everything we can so that this extra time can be made up where possible.

Next, we’ll be sharing the initial fruits of our labor: the results of our first milestone. First, we’ll share a video showing our initial pieces fitting together into a working threshold relay, responding live to requests for random numbers. Then, we’ll be releasing an alpha Solidity API that will allow developers to start building applications against a simulated version of the Keep threshold relay, ready to switch to the real thing once it goes live.

Look out for those posts soon; we’re excited to be sharing a deeper look at our progress!

Thanks to James Prestwich and Brayton Williams for reviewing early drafts of this story.