Dissensus protocol?

I was recently asked by Elias Haase at B9Lab in London to write the equivalent of a “hippocratic oath” for blockchain developers, which would form part of their developers training program. A hippocratic oath might not be the most suitable format for developers in a field that is working intensively on decentralised cryptographic and game theory security models. In other words, appealing to a moral and ethical position might seem pretty feeble and pointless in the face of serious infrastructural security questions.

But this is not a hippocratic oath. It is  a set of questions to understand better the relationship between code and the unknown in a messy world of only partially conceivable and unquantifiable relations – all those things that cannot just be turned into a self-executing law. It is some considerations for a dissensus protocol as an important complement to the consensus protocol. Here is my introduction to the Satoshi Oath (originally published on the B9Lab blog):

 

Proposing the Satoshi Oath for developers

In a time that is rife with corruption scandals and disillusionment in existing financial and political institutions the blockchain has a set of properties that has made it so attractive for so many people across industries as well as across the political spectrum: decentralisation, immutability and neutrality. But in the messy real world that we inhabit, these properties are only a set of ideal values that people might strive towards or use to their advantage rather than features that are always and fully guaranteed by the architecture.

This much can be learned from the past few years of governance crises across the major blockchain projects (see for example the DAO / Ethereum hack and Bitcoin block size conflict). Somewhere along the line, someone is making decisions and writing code, somewhere there is someone with a different idea or version of decentralisation or neutrality, and not everybody has the same types of capacities to engage with and act in the system. That is not necessarily a bad thing. Disagreement and differences should not be repressed. But what this does mean is that the problem of governance, of power and authority is not simply resolved through technical architecture, it has just radically changed shape and character to include algorithmic processes and cryptographic proof.

The Satoshi Oath for developers is designed to draw out the edges and limitations of the technical architecture in guaranteeing these values and to help each person clarify what exactly they mean for each given project they might work on. It is a tool to think through how a project might relate to the people and environments that it affects and to think beyond code.

To do this, it takes each of these three central properties of the blockchain and adds two helpful concepts to start questioning how values like immutability, neutrality and decentralisation relate to the social contexts where they are being applied: Power, Change, Delegation, Disclosure, Dissensus and Exodus.

– Immutability is a central attribute of the blockchain to ensure trust in the system and integrity of the data. But not every situation can be anticipated: the world changes, systems need to adapt and data might be incorrect and even hurt someone (take the example of medical records, credit ratings or identity systems). There might be situations where the rule of immutability needs to be flexible, where the protocol or the data in fact does need to be changed. Ask yourself, who (or what) has the power to change the protocol in such a situation? What are the processes for this? What is the full range of people and environments that might be affected by this change? How will a non-technical user be made aware of changes that might affect them? In what ways can they influence this?

– Neutrality is an ideal that should be strived for but is never fully realised because all systems operate on a set of assumptions about how the world works, what people want and how they behave. A design is usually open for negotiation in the early days, before one version wins out over another and becomes normalised and possibly made into a standard. When these assumptions are encoded into a system they become automatically reinforced, invisible and harder to change. Ask yourself, what are the assumptions and behaviours that are delegated to the infrastructure to automatically reinforce? What needs to be disclosed in order for people to be able to understand, influence and possibly even change the assumptions of the system down the line? What languages (code or human-based) are needed for such explanations to make it understandable to those affected?

– Decentralisation could be said to be the most fundamental principle of blockchain technology. But in practice, one version of decentralisation might clash with another, and if it becomes compulsory to take part in a decentralised system, the system itself becomes an oppressive authority in its own right. — The only difference being that it is less obvious than centralised authorities of the past because power is executed across multiple actors in the network. Ask yourself, how does the system deal with dissensus?  — Is it possible to disagree with the development of/changes to a system? How can it be expressed, by whom and with what consequences? Is exodus possible? — To leave the system entirely? And what are the different consequences for different types of users and contributors for disagreeing or leaving?

The Satoshi Oath for developers is a tool to make visible the informal social processes that are part of the infrastructure, to consider who or what benefits or who or what is left behind by different design decisions. A decentralised computer network does not guarantee decentralised power, transparency does not guarantee legibility and finally, code and cryptography does not guarantee neutrality.

You can read and sign the Oath on the Ethereum Blockchain. The text is hosted on IPFS.

http://ipfs.b9lab.com:8080/ipfs/QmXysWEAexXQqYZhTGpECvksnaBkSEWHdGhM7vNeHxue2g/

Save