A design for decentralized organisations: part 3

In part 2 of this series, I discussed methods to scale communication in decentralized organisations, and recommended the use of a sybil-resistant voting system, prediction markets, and groups smaller than 8 in order to achieve scalable, verifiable finality. Now on their own, these methods would not necessarily function well unless data required for reaching finality was made available transparently. Hence, this part introduces the challenges that transparency presents to scalability, and proposes self-sovereignty as a way to achieve both transparency and scalability.

Principle 3: either be transparent…

In the absence of provably aligned interests, opacity is the enemy of consensus, and, by extension, is the enemy of trust. After all, if relevant parties cannot obtain information about some scenario, how can they be expected to make good decisions or reach finality? Moreover, if information is required for some decision, yet is not provided, it is easy to mistrust the motives of those you’re expecting the information from. As such, for every decision, it is optimal for all significant information to be provided to all stakeholders, and in a “trustless” manner.

…or don’t make something other people’s problem

If it is feasible for less than everyone to be involved in a decision, then it is usually performant to reduce the size of participants, as sketched above. For example, if some code needs to be written, it is seldom feasible for a large crypto community to collectively decide how to write it; instead they typically aim to employ a skilled coder to do the work. More generally speaking, decisions might be made by a team of experts, or by the leader of some team, and wherever this is workable, the requirement of transparency is radically simplified, because it is no longer necessary to ensure information is accessible to everyone in a transparent manner. This brings down administrative workloads, and helps organisations avoid bureaucratising.

Now this sort of optimisation can go far deeper and be quite radically effective not only at avoiding performance penalties, but also in actively achieving transparency. “Not making things other people’s problem” is the larger part of how decentralized designs are actually achievable. Take Bitcoin for example. It achieves a 100% transparent transaction history, but in order to do so, it does not require block verifiers to perform complex, bloated auditing of amounts sent, time of transaction, receiver and sender IDs, etc. Instead, it effectively requires them to collectively agree on only time of block solution, which is why a blockchain is also known as a timestamp server. Think about how incredibly efficient this is: collectively validating one datum per block provides double-spend protection for every single transaction, which then secures all the other properties listed above. Block verifiers just don’t have to worry about the indeterminate number of other potential checks and balances that could conceivably be required in order for transactions/contracts to be valid. That task is offloaded to each individual peer’s instantiation of the rules of Script. Now that’s a good engineering solution.

Decentralization without consensus: self-sovereign action

In the context of governance, it’s obvious that similar efficiency techniques are required, since possibly the most common malaise of corporate bureaucracy today is the incremental bloating of “process,” rule after rule, requiring employee after employee, until the cost and complexity of “safe,” “fair,” or “compliant” operations consumes a vast proportion of resources. This is the case, for example, with the Oxford County Council, or, more egregiously, with the Gauteng government — and these are sadly not exceptions, but standout instances of the norm. Now while a general strategy like decentralization does not directly afford efficiency-gains for organisations, and, worse still, directly multiplies the intercommunication load (see above), it can nonetheless afford a design pattern that, wherever it is practicable, can radically improve efficiency in the same manner that it does for Bitcoin. Let’s term it self-sovereignty: the decentralization of decisions without requiring consensus between participants. Just as every full node on the Bitcoin network runs Script locally and can thus determine for itself the validity of a transaction independently of other nodes’ judgements, people in a decentralized organisation may permissionlessly market a project, maintain websites, contact potential adopters and partners, create funding proposals, do due diligence on a funding proposal, write code, and so forth.

The limit on self-sovereignty is, of course, the extent to which any given state change (e.g. an action, a process…) must inescapably be subject to either consensus or be dependent on other forces outside the self-sovereign actor. Now one self-evident, albeit ideal, corollary of self-sovereignty is that in order for each actor (whether a person or a team tasked with a given output) to be self-sovereign, it must be in a position do its work without dependency on other actors. Typically, this is a matter of electing team members who can jointly reach the team’s goals self-sufficiently; in other cases it may be a matter of merely reducing the risk of third parties compromising the operation in various ways (e.g. on a p2p network, forming connections with many nodes in case some of them give poor service); otherwise it may be a matter of reducing scope of the work itself so that it is immune from such potential compromises. Either way, unless work is done in a self-sovereign manner, governance problems will arise — and this is what accounts for the majority of the costs and inter-departmental friction of a modern corporation. Corporations typically set up work process as a series of “deliverables” between several teams or departments. It quickly becomes the norm for the state of a process to be contested, with reports, “deliverables,” or other “output” sent back and forth between departments — often for mere technicalities, or even reasons having little to do with the actual work being handed over (e.g. workload in the downstream team is already too high). One way or another, poorly aligned incentives and insufficient recognition of the importance of self-sovereignty create an organisational hazard. Such is the requirement internal to each team in a decentralized (or centralized) organisation: to be performant, it must preserve its sovereignty.

Beyond each team’s sovereignty, at an organisational level a scalable decentralized organisation should limit as far as possible the types of state changes requiring consensus. The way Bitcoin accomplishes this is to make all state changes depend indirectly upon a fundamental type of state change — one that can function as the foundation of the security of all the others — the determination of valid blocks (mining). In the next section, I will explore this in some detail, noting how the scalability of a decentralized organisation depends critically on how few attributes it needs to obtain consensus about, and then devoting the bulk of the remainder of this series to identifying the fundamental attributes of a decentralized organisation, which alone require consensus, and upon which every other process can be built.

Continued in part 4.