Рецензия · 15. Концептуальные пределы блокчейн-управления

15. Conceptual Limits of Blockchain Governance

15.1 Preliminaries

So far, we have focused on the promising aspects of blockchain governance. We discussed how it might work and what it might accomplish. However, no technology is without limitations. There are, of course, technical limitations to getting it up and running – fixing bugs and whatnot. However, there are also conceptual limitations to what it can accomplish, and it is important that we address some of them. Blockchain governance is supposed to be ‘trustless’, but as we will see, there are limits to how trustless a crypto protocol, or really anything, can be. At some point, everything bottoms out with human beings. Second, there is the issue of centralisation and whether anything can be fully decentralised. Nothing really can, nor is it clear that it would be desirable, even if possible. Third, there is the issue of transparency. We have spoken about how information on the blockchain is visible to all, but there are important caveats that need to be added. The information is certainly there, but how many people actually have the ability to interpret it? We take these and other issues up in the following sections.

15.2 Nothing is 100% trustless

On 20 July 2016, about a year after Ethereum launched, Vitalik Buterin announced a hard fork of the protocol. By making that announcement, Buterin shattered certain tightly held assumptions about the future of trust. He also incensed many people.

To understand how, we first need to discuss trust and its place in the fabric of our lives. Trust might be in short supply these days, but we have no choice but to rely on it. We trust schools and babysitters to look after our children. Some still trust banks to hold our money and to transfer it safely for us. We trust insurance companies to pay us should we encounter some disaster. When we make a large purchase – such as a house – we trust our solicitors or an escrow company to hold the funds until the transaction is complete. We trust regulators and governments to make sure these institutions are doing what they are supposed to be doing.

Sometimes, however, our system of trust fails us. There are runs on banks. People lose faith in currencies issued by nation states. People stop trusting their political institutions because of the chicanery, shortsightedness and general incompetence of the self-interested people running the show.

Blockchain technology is often characterised as being ‘trustless’, meaning that we no longer need to trust fellow humans – we can trust the algorithm. However, when viewed on a conceptual level, this is not accurate. An example alluded to in this section’s opening can help us understand why.

In April 2016, the first DAO was created. It was called simply ‘The DAO’, and about 11,000 people contributed a total of $150 million to take part. Contributors to The DAO believed they had bought a share in a virtual hedge fund that would invest in other companies and ventures. Anyone wanting to receive funding from The DAO had to submit a proposal online in the form of a self-executing contract that DAO shareholders would then vote upon. If approved, The DAO was programmed to automatically transfer the agreed allocation of ETH. In theory, shareholders did not have to worry about the good intentions of The DAO’s employees, for this was the type of DAO that had no employees; nor need they have to worry about the competence of supervisors or executives because there were none; nor did they have to ask lawyers to go over the fine print, for there was no fine print to go over. They would have no need to trust courts and police and attorneys to enforce the contracts because the contracts did it themselves. All they had to do was look at the software code in the smart contracts, see what the program (that is, the organisation) would do and choose whether or not to buy in.

On paper, the scheme appeared to be flawless. However, it quickly transpired that it was not. On 17 June 2016, someone – we still do not know who – successfully hacked The DAO. The hacker syphoned off the equivalent of $50 million into a second DAO contract that they had deployed, which subsequently became known as the ‘Dark DAO’. When this flaw in the code was detected, other stakeholders used the same exploit to move the remaining ETH into a third DAO, known as the ‘White Hat DAO’. Then, all the existing accounts in the three DAOs were frozen.

But what to do with the money in the Dark DAO and the White Hat DAO? Some argued that, as the hacker was only doing what the software allowed, the ETH in the Dark DAO rightfully belonged to the hacker. And why was one DAO called ‘Dark’ and the other ‘White Hat’ – were both hacks not undertaken using the same code? And was the code not the law?

This brings us, finally, to what infuriated people – the fork (actually, the forks, for there were two forking options: a soft fork and a hard fork). A soft fork would be backwards compatible, meaning that the nodes that did not upgrade their software would still be able to operate. However, the hard fork option was another matter entirely. Among other things, it would undo previous transactions (reverse them, in effect). In this case, it would take the money back from the Dark DAO and the White Hat DAO and put it back in the hands of the hoodwinked investors.

But in a trustless universe, who decides if the fork happens? This is where the miners enter the story. At the time, Ethereum was still a proof-of-work protocol, and miners did the grunt work of sealing transaction data into blocks. While Buterin and the Ethereum Foundation could propose a fork, ultimately, the decision was in the hands of the Ethereum miners. They were the ones who had to mine the revamped Ethereum code and keep the whole system running.

On 20 July 2016, Buterin announced that the miners had accepted the hard fork and were now mining with the updated code. The reality was that most of them had. A number of holdout miners and Ethereum users were outraged by the decision to hard fork the protocol. In their view, the hard fork undermined the core principle of Ethereum, which was, after all, to bypass all the meddling humans – the corrupt bureaucrats and politicians and board directors and CEOs and lawyers. Code was supposed to be law. If you did not see the weakness in the software, that was your problem since the software and all its code were publicly available.

Thus, some Ethereum miners refused to run the updated software and instead stayed with the original Ethereum protocol, which they redubbed Ethereum Classic. You would think that would be the end of it, but no. Shortly after the hard fork of Ethereum and the network split that created Ethereum Classic and what we now call simply Ethereum, a further round of technical problems were identified with the Classic protocol. Soon, there was a counter-proposal to hard fork Ethereum Classic, which led to the inevitable threat by the true believers that they would respond with an Ethereum Classic Classic.

Such are the perils of supposedly trust-free technology. It might make for good marketing copy, but as we have seen throughout this book, blockchain technology incorporates many components that involve trust. First, you need to trust the protocol of the cryptocurrency and DAO. This is not as simple as saying, ‘I trust the maths’, for some actual human (or humans) wrote the code and hopefully debugged it, and are we not at least trusting them to get it right? Well, in the timeframe leading up to The DAO, maybe they did not get it right.

Second, one has to trust the stakeholders (whether miners or validator nodes) not to destabilise the protocol with a hard fork. One of the objections to the hard fork was that it would create a precedent that the code would be changeable. However, this objection exposes an unmentioned universal truth – it was always changeable: the immutability of the blockchain is entirely a matter of trusting other humans not to fork it. Ethereum Classic Classic would be no more immutable than Ethereum Classic, which was no more immutable than Ethereum. At best, the stakeholders – all humans – were showing that they were more trustworthy about not forking the blockchain. At the same time, they obviously could change their minds about forking at any time. In other words, if Ethereum Classic is more trustworthy, it is only because the humans behind it are more trustworthy.

Third, if you are a non-technical individual buying into Ethereum or The DAO or any other DAO, you are being asked to trust the people who review the algorithm and tell you what it does and whether it is secure. However, those people – computer scientists, say – are hardly incorruptible. Just as you can bribe an accountant to say that the books are clean, so too can you bribe a computer scientist to say that the code is clean. Moreover, you are putting your trust in whatever filters you apply to select that computer scientist. Was it university or professional qualifications? A network of friends? The testimonials of satisfied customers? – which is to say, the same method by which people selected Bernie Madoff as their financial advisor.

Finally, even if you had it on divine authority that the code of a DAO was bug free and immutable, there are necessary gateways of trust at the boundaries of the system. For example, suppose you wrote a smart contract to place bets on sporting events. You still have to trust the news feed that tells you who won the match to determine the winner of the bet. Or suppose you wrote a smart contract, the terms of which stated you were to be delivered a truck full of orange juice concentrate. The smart contract cannot control whether or not the product is polluted by lemons or some other substance. You have to trust the humans in the logistics chain and the humans at the manufacturing end to ensure your juice arrives unadulterated.

Can these gateways to the system not be trustless as well? Can smart contracts not someday be written to contain code to call for robotic orange pickers and robotic juice concentrate makers who would summon their robotically driven trucks to deliver the orange juice concentrate straight to our door? Yes – in theory. However, imagine the task of reviewing the code to ensure that every step in the process had not been corrupted by a bug that uses security failures to hijack trucks or that gives false approvals to adulterated orange juice. Perhaps we could write second-order programs to automate the testing of the first-order programs – but why do we trust those? Do we ultimately need automated program-tester testers? Where does it end?

By now, the answer should be obvious: it ends with other humans. Blockchains do not offer us a trustless system but rather a reassignment of trust. Instead of trusting our laws and institutions, we are being asked to trust stakeholders and miners and programmers and those with sufficient programming skills to be able to verify the code. We are not actually trusting the blockchain technology; at the foundational level, we are trusting the people who support the blockchain. In the end, we have to trust people. Therefore, blockchain technology is not trustless; it is rather a kind of distributed trust. We do not trust a single centralised organisation, but we trust a large network of individuals to continue to do the right thing.

15.3 Nothing is 100% decentralised

In the previous section, we talked about trust and the Ethereum protocol. Let us stay with the example of Ethereum while we pursue another question: Can any blockchain network be truly decentralised?

Ethereum is now a proof-of-stake protocol. The greater the value of assets staked on a validating node, the greater the chances of that node being permitted to select the next block. But who exactly is assembling those blocks? And how does that process actually work? And is Ethereum actually decentralised? As we will see, decentralisation comes in degrees.

Let us start by getting into the nitty gritty of the Ethereum protocol. What happens when you engage in a transaction on the Ethereum network? Let us say you are sending ETH to a friend or you are buying ETH with DAI or you are depositing ETH and DAI into a smart contract – maybe you want to contribute it to the liquidity pool on a decentralised exchange like Uniswap. The first step is that you confirm your transaction in your wallet. Maybe at that point, you visit a blockchain explorer like Etherscan to get an idea of how long your transaction will take. Maybe you are waiting to see the green message ‘Success!’ What is going on while you are waiting for that to happen?

As it turns out, a lot is going on. If you have made transactions on Ethereum, you have probably noticed that sometimes your transaction resolves quickly and sometimes it seems like an eternity. Maybe, in your frustration, you increased the gas fee (the transaction fee) you were willing to pay to make it happen. While you were sitting there, waiting for your transaction to process, a lot was going on. For starters, your proposed transaction was sitting in the ‘mempool’ (short for memory pool).

The mempool is where proposed transactions wait, hoping to be selected to be put into blocks. Picture it this way. Think of proposed transactions as people hoping to get on the blockchain train. Let us say that there are several train station employees tasked with selecting bundles of people to load into a train car, but only if they have been chosen to load passengers onto the next train. For each train, only one of those bundlers is awarded the job, and different bundlers may have different strategies for selecting groups of people to load onto the train.¹

Obviously, the bundlers want to make as much money as they can, and one obvious way to go about it is to load the people who are waving the most money at them. If you are not offering money, you are probably going to have to wait until a loader selects you to board the next train or the next one or the one after that. However, it is not only about who waves the most money. Sometimes, you can gain a different kind of edge.

The train loaders know more than just who wants to get on the train; they also know their intended destinations. This opens up new opportunities to profit. If you notice that a lot of people are trying to buy passage to Albany, for example, then you now have a piece of valuable information. Maybe a lucrative business deal will occur there. With that information, you can buy up some of the tickets in advance and sell them at a scalper’s markup – that is, you can ‘front run’ the transactions people are trying to make.

In the parlance of Ethereum, this is called ‘maximum extractable value’, or MEV. Now, we can argue about whether there is something wrong with trying to capture MEV. On the one hand, we want people to be incentivised to do the work of forming blocks. On the other hand, it would be preferable if people did not front run our intended transactions. However, in the case of Ethereum, two things must be noted. First, as matters stand, there are not that many people constructing blocks for Ethereum (just a few thousand). Second, those who do it have a tremendous amount of power. This leads one to question just how decentralised things actually are.

To sharpen our discussion, let us move from our metaphor to a description of what exactly is occurring on Ethereum. The train loaders in our metaphor are nodes on the Ethereum network. We have mentioned them extensively in this book, but what exactly are nodes? As of this writing, approximately 6,500 Ethereum nodes are scattered around the world.² They play the role that our Byzantine generals and our scattered rulers of Paxos did. However, to understand them more deeply, let us start with Ethereum client software. There are several varieties of this software, but let us say you download a client software called ‘go-ethereum’ – or more commonly, ‘Geth’ – install that client on your computer and use it to connect your computer to the Ethereum network. Now, you have a node up and running. Therefore, the node can be thought of as an operational instance of the Ethereum client software.

Digging a little deeper, we should point out that there are different kinds of nodes: full nodes, light nodes and archive nodes. Full nodes download all blocks from the blockchain, storing them on their hard drive. This permits users to verify transactions directly. Light nodes only download those blocks pertaining to their own account balance and, as such, might be used as user wallets. Archive nodes store all data from every block ever created and build an archive of past blockchain states. These are used by blockchain explorers like Etherscan.

Each full node has approximately twenty peers on the network with which they are directly connected. When your proposed transaction arrives at a node, the node propagates it to its peer nodes, and those nodes propagate to their peers until your proposed transaction is scattered across the network. However, the transaction is not yet on the blockchain. It is still in the mempool. Or more accurately, it is in the mempools because, technically, each full node has its own mempool, and the composition of each mempool will vary from node to node.

The work of the nodes is to package transactions together into blocks. In the days of proof of work, these nodes would involve miners that would compete for the prize of getting to submit the official block. Today, because of proof of stake, you assemble the blocks in the hope that it will be your turn to propose the next official block.

The problem is that each of these nodes is a potential point of failure. Now, of course, that is to be expected because, theoretically, blockchain technology is designed to be Byzantine fault tolerant. However, what if some centralised authority were to identify each of those 6,500 nodes and apply pressure to their operators? For example, suppose that the centralised authority demanded that they censor certain transactions from their mempool and pressured nodes into censoring blocks that contained those unwanted transactions (for example, payments to WikiLeaks). That is, what if the nodes were forced to never assemble blocks that contained the undesirable transactions?

We do not need to speculate about such a possibility because it is happening right now as we write. The United States government recently sanctioned Tornado Cash, a protocol that inputs several crypto transactions from different sources and ‘mixes’ them so that the flow of money cannot be tied to a particular wallet. When the US government cracked down on Tornado Cash and arrested its principal developer (on the grounds that it was a money laundering tool), it was able to take individual Tornado Cash servers offline and, obviously, detain the people running those servers.³ As for Ethereum nodes, 6,500 is not an impossibly large number of targets for a nation state like the United States. For example, the FBI, in partnership with local and state law enforcement, arrested approximately 6,000 alleged violent criminals and gang members between 1 May and 2 September 2022.⁴ Of course, any such operation would be international in scope, but there is little to constrain the United States from organising such an enforcement operation on a global scale (the Tornado Cash action shows that the United States can and will act outside its borders in collaboration with the law enforcement agencies of other countries).

To be clear, we are not saying that governmental actions against the Ethereum network are inevitable or even likely. Given our proximity to the crypto sector, we hope they are highly unlikely. However, our goal here is to explore the conceptual limits of decentralisation, and it cannot be denied that conceptual limits exist. In the ideal world, perhaps everyone would be running a node on their smartphone so that there would be billions of nodes scattered around the world. That would certainly be close to being safely decentralised. However, it needs to be asked if a hyper-decentralised network like that would even be optimal.

As we noted in the previous chapter, recent work on the science of networks suggests that the most efficient networks are so-called ‘scale-free’ networks, which are networks in which not everything is equally interconnected but in which there are certain important hubs that have many network connections. As we highlighted, this is the design of air traffic routes, for example, in which there is a group of heavily interconnected airline hubs. Your brain is organised this way, too. And it is because of this network architecture that we get phenomena like six degrees of separation.⁵

If the Ethereum network (or any network, for that matter) was completely flat and every node connected to the same number of local nodes with no node being more densely connected, we would be looking at a very inefficient network – so inefficient, one might wonder if it was even functional. To illustrate this problem, imagine that airlines eliminated their hubs so that there were no direct flights from New York to Chicago or to Atlanta, but that each flight had to be to the nearest commercial airport. A flight from New York to Los Angeles would be a nightmarish experience with dozens of stops. It is much better to have some degree of centralisation in the form of heavily connected hubs.

Another way to decentralise would be to connect every airport with every other airport. However, this would generate inefficiencies of its own. Again, it would be an absolute nightmare to have every single airport in the country having direct flights to Los Angeles and, for that matter, to Sioux Falls, South Dakota. Therefore, the most efficient network needs to allow some degree of centralisation. This example illustrates the tradeoff between decentralisation and efficiency. On the one hand, complete decentralisation eliminates points of vulnerability but, on the other hand, too much decentralisation can make a network functionally useless.

We might decide that some degree of network centralisation is a good thing or perhaps even a necessary thing, but there is another kind of centralisation that we need to consider – the power and influence of founders and leading figures. We could call this ‘social centralisation’, and the concept deserves further discussion.

15.4 Social centralisation

We have been talking about blockchain technologies as though they offered a level playing field in which everyone, in the abstract, had the same power and influence. Of course, this cannot be the case in practice. Leaders do emerge, and by their very nature, leaders have more power than others. Do we, therefore, end up with a kind of oligarchy of technological elites?

An example will help illustrate this concern. When Status released its token back in 2017, the event generated so much traffic on Ethereum that it ground the network to a halt. In the midst of the network congestion, Vitalik Buterin directly contacted the founders of Status (one of whom coauthored this book) to find out what they were doing and to see if the problem could be mitigated.

Today, Buterin does not have much in the way of direct control over the Ethereum protocol, but he has plenty of indirect control simply by virtue of the credibility he has established by being the network’s founder and by virtue of the proposals and ideas he continues to put forward. He plays a huge role in the direction of Ethereum. It is doubtful – impossible to believe, really – that Ethereum could have converted to proof of stake had Buterin not wished it. Of course, the case of Buterin and Ethereum is not unique. Important and charismatic founders can be found throughout the crypto sector, and to some degree or other, every founder has a huge influence on their protocol. Examples include Charles Hoskinson (Cardano), Andre Cronje (Yearn Finance, Fantom), Hayden Adams (Uniswap), and the list could go on and on. It is doubtful that a DAO would work against the wishes of one of these founders if they had stated a clear preference for a decision.

One might think that Bitcoin is an exception to this phenomenon because its founder, Satoshi, appears to have vanished, but there are still important Bitcoin developers and stakeholders that carry enormous clout. Famous examples include Gavin Andresen, Wladimir J. van der Laan, Pieter Wuille, Cory Fields and, of course, the Bitcoin gadfly Luke Dashjr. Indeed, as we write this, Luke Dashjr is involved in a campaign against ordinal inscriptions, claiming they are a ‘bug’ and a ‘fraud’ and an ‘exploit’,⁶ and some observers have complained that he is using his clout as a developer to lobby against a Bitcoin feature has become reasonably popular (particularly with Bitcoin miners).

Again, to be clear, we are not saying that Luke Dashjr or any of these other figures are steering Bitcoin in a bad direction. We are simply saying that they have a lot of social clout in the Bitcoin world and that, conceptually speaking, a cult of personality is possible, and one can see how such a cult of personality might form.

According to some accounts, every attempt to organise humans has this element of hidden oligarchy. Back in Chapter 2, we mentioned Bertrand de Jouvenel’s concerns about the power and violence of nation states. However, he also observed that there was typically an oligarchy – perhaps hidden – exercising control in such states.⁷ The notorious German political theorist Carl Schmitt made a similar observation about groups that purported to be egalitarian. During periods of stability, it may appear that the group is free of hierarchy, but then, in times of crisis, we see power brokers emerge and take charge. In Schmitt’s view, they were always there, and they always had the power.⁸ Like Buterin contacting the founders of Status, the hidden leaders only show their hand when things have fallen into disarray.

Our point here is that there may be a practical, if not entirely conceptual, limit to how egalitarian a protocol can actually be. Even on online message boards, there tend to emerge board ‘leaders’ that carry a lot of clout.⁹ The same could be said for crypto influencers on online platforms like X (formerly Twitter). The political landscape is not entirely flat in blockchain communities.

It is an interesting question as to whether such new oligarchies are a good thing or a bad thing. Human organisation seems to require leaders, and good leaders do lead to successful communities. Furthermore, some people are natural leaders and some people look for leaders. That will be true in the blockchain world, just as it is in the traditional world of centralised authorities. However, there are important differences between leadership in the blockchain world and leadership in the centralised world.

Centralised governance serves to establish moats that protect and reward leaders who do not deserve their elevated position and who do not serve our interests. Part of the problem is that in a world of nation states, where exit is not a realistic option for the vast majority, many people are, by necessity, kettled into spaces with people who do not share their values and with leaders who are not aligned with those values.

However, centralised governance also tends to build moats protecting economic classes. Thanks to the corruptibility of centralised banking and the inevitable debasing of national currencies, many wage earners are frozen out from ever being financially secure. Meanwhile, people who hold physical assets can tolerate the debasing of their national currency just fine. Although it is not impossible for people to turn an hourly wage into vast wealth or simply economic security, that path is far from frictionless. Furthermore, if leaders are drawn from the class of asset holders, then they can hardly be expected to represent the interests of wage earners in the long run. Even if they provide entitlements to wage earners, they typically debase the currency in doing so. Thus, the real winner is the asset-holder class.

There are many more moats than this protecting the interests of our de facto oligarchy in the age of centralised governance. Important economic information can be siloed to the advantage of those in the know. For example, business secrets about things like impending mergers can be kept within a narrow circle. In the decentralised blockchain world that we envision, such moats would be less common. Assets like BTC and ETH provide ways to avoid the debasement of currencies. The transparency they bring to governance means that no one gains an edge by hoarding secrets. And because technological developments in crypto are typically onchain and visible to all, it is easier for people to catch up technologically.

In the end, we cannot say that there will be no leaders in the blockchain world, and if you wish, you can call these leaders the new oligarchy. However, the difference is that now the interests of the oligarchy are better aligned with our own – not just better aligned but demonstrably better aligned because of the transparency of their onchain actions and, in particular, the transparency of the smart contracts and online protocols they deploy.

Finally, we believe that the pathway to being part of the new oligarchy is more frictionless and more merit-based than before. Of course, we recognised that similar claims were made with the emergence of liberalism during the eighteenth century, and there is no doubt that this represented a great step forward. However, to keep advancing towards an egalitarian society, we need to dismantle the information siloes and fill in the moats of the centralised world.

As we said, there are going to be conceptual limits here. There will be a new class of leaders, and leaders will inevitably fail us, and deserving people will inevitably be left out of leadership positions. We cannot solve for this conceptual limit with technology alone, but we can make the situation much better than it is today and perhaps move ever closer to delivering on the egalitarian promises of the eighteenth-century revolutions. As we will see in the next chapters, we will also need a realignment of our values if we want our new technology stack to work with us instead of against us.

15.5 The epistemological limits of oracles

In our discussion of trust at the beginning of this chapter, we briefly glossed over an important issue that deserves more attention. We mentioned the difficulty of ensuring that the data structures in computer code are reliable representations of what is going on in the so-called real world. If you missed the point, we understand; it came up during our discussion of how one might come to trust a smart contract that promised the delivery of orange juice concentrate. The problem, of course, was that oranges grow on trees and are not data structures in a computer. Smart contracts can only act on computational data structures, and this means that at some point in the process, information about real-world physical oranges and real-world orange juice concentrate needs to be reliably recorded onchain.

We described this as an issue about trust, which of course, it is. However, it also reveals a deeper conceptual issue regarding the connection between events in the real world and representations in smart contracts and blockchain ledgers. Humans also have this problem and applied to humans, philosophers refer to it as a problem of our knowledge of the external world. How can we rely on our sense organs to reliably tell us about the external world? In Chapter 6, we introduced oracles, which are like sense organs connecting the blockchain to the external world. As we might expect, this raises all sorts of philosophical issues.

The problem of blockchain oracles is difficult because computations that take place onchain typically (although not always) involve information about the extra-blockchain world. You can have a stablecoin that tracks the value of the US dollar, but it requires an oracle to inform the smart contract as to the actual price of the US dollar relative to that of a specific cryptocurrency. Or you might want to engage with an online betting market to place bets on the outcome of football games or elections. Once again, one relies on there being a reliable source of information offchain and a reliable tool to move that information onchain. There are, of course, organisations that do this, most notably Chainlink, but these organisations raise questions of their own.

The first and most obvious question is really an extension of the conversation that we had in the second section of this chapter – oracles potentially present points of centralisation and, thus, vulnerabilities. To understand the problem, consider this. We could have a perfectly decentralised blockchain (yes, perfectly decentralised is impossible, but this is just a thought experiment); however, if all the offchain information being imported to the chain is coming from a single source, what did your decentralisation actually accomplish? Sure, a perfectly decentralised blockchain ledger would be difficult to tamper with, but if you can take control of the oracle and corrupt the feed of the value of the US dollar or of gold or of the current price of Amazon stock or of the price of orange juice, then the information imported onchain is corrupted.

In this chapter’s opening section, we also saw all of the hoops that one would have to jump through in order to resolve this problem. In effect, one would have to continually make more and more real-world information into onchain information. And how does one do that? To answer that, let us remain with the orange juice example, as it provides a good illustration of the problem and of the obstacles you would have to overcome in order to solve it. Let us say that a smart contract involves the exchange of a certain amount of a US dollar stablecoin for a certain amount of orange juice delivered to your store. How does the smart contract know that the orange juice has been received? Well, someone has to record that information onchain.

Now, we must question whether the information is reliable and one way to make it more reliable is to expand the scope of the information imported to the blockchain. For example, we might include shipping information about orange juice as it leaves the factory. However, the problem does not end there. How do we know that it was orange juice that left the factory?

It is not like there is nothing to be said about the orange juice leaving the factory. We certainly would have quality control people entering information about the purity of the orange juice in the factory, but how do we trust those human points of failure? We can keep expanding the amount of onchain information. We can input the information onchain at each step in the manufacturing process, beginning with taking oranges into inventory and sending them to the juicers. To assure ourselves that those records are also reliable, we can track the orange shipment from the orange groves, and we can presumably also record information from the harvesting equipment – if desired, modern harvesting equipment can record the GPS location for every orange that it picks down to the very tree from which it picked it. However, that information could also be corrupted because any recording of information can be corrupted. We could utilise an army of bots and drones to verify the authenticity of the information being recorded at harvest and perform audits on the quality control equipment. However, then we might need drones to audit the drones and so on. It plays out just as it did in our discussion of trust above.

While we never arrive at a completely secure foundation of Cartesian certainty, at each iteration of the process, we make it progressively less likely that our information is corrupted. Maybe you can get the store delivery service to lie about receiving orange juice, but you also have to get the trucking service to lie about the delivery and the initial factory to lie about loading the trucks. And you need the factory to lie about producing the orange juice and the quality control people to lie about the measurements they took. And you have to get the shipping service to lie about the delivery of the oranges to the factory and the farm to lie about picking the trees and loading the trucks, and have someone to lie about the AI drones that audit various parts in that whole process. In other words, it would take an epic conspiracy to successfully execute such a scheme.

Now, of course, we recognise that there are points of weakness in this process. Maybe one dishonest trucker can disable his GPS, deliver quality orange juice to a different customer, and deliver inferior orange juice or convince those overseeing the shipping and receiving processes to say that the orange juice was received and record it in inventory. However, it is not trivial business because the audit trail is massive. At the end of the day, it is highly probable that the oranges were harvested, delivered to the factory, shipped out of the factory and delivered to the store, with information recorded onchain at every step of the audit trail. As noted above, we also have to trust fellow humans at many points of that audit trail. However, the longer the audit trail, the more reliable the information that ends up being fed into the smart contract. This is because a smart contract oracle does not need to merely input the record of receipt of orange juice; a good oracle will peer as deeply into the audit trail as necessary to mitigate financial risks.

Earlier, we mentioned Chainlink, which is an oracle network. It is worth noting that it uses a different strategy from the one outlined above. Chainlink oracles are actually more like small networks of individuals who are tasked with providing reliable information. People participating in these oracle networks need to stake assets, which can be forfeited if they provide incorrect information. However, we can take this general idea and expand on it.

For example, if you wanted an especially secure node for football game scores for a high-stakes gambling service, you might want more than a news feed from a service like the BBC because you might worry that a single feed could be hacked. You might also want more than one pair of eyes reporting to your oracle. Therefore, someone in your oracle network might go to the games, someone might monitor the news service and someone else might query the league office for scores. Each of these individuals would operate a node, and each of them would stake resources which would be forfeited if they reported an incorrect score. If each of our human observers operates a node, then the oracle is actually a network of these nodes. Engineered correctly, such an oracle will be decentralised and will survive individual points of failure. It may well be an organised blockchain community itself.

With oracles like those following the Chainlink model, we are back in the business of trusting other humans, but we have somewhat decentralised that trust, and we have made sure that there is a penalty for providing false information. Therefore, it is a peculiar kind of ‘trust’ in which a Sword of Damocles hangs over the person we trust (they could lose their stake if they fail to report accurate information), and we are also distributing that trust among others in the oracle network, each with a Sword of Damocles hanging over their heads. Furthermore, incentives encourage nodes to perform reliably, and nodes that report accurate information are rewarded (oracles are a service for pay, after all).

What is the upshot of all this? The conceptual limit is that there cannot be absolute certainty about the information that is being fed into the blockchain via oracles, but by putting more and more information from the audit trail onto the blockchain, we gradually increase the probability that the information is reliable. Similarly, as oracles add more nodes, they become more robust – ideally, they become Byzantine-fault-tolerant networks themselves. These protocols are not vapourware but are being brought online today as we write this. To be sure, there is a conceptual limit to the reliability of oracles, but it seems to be one with which we can live if networks and oracles are correctly designed. The blockchain cannot have perfect knowledge of the external world. However, robust decentralised networks can achieve a level of veridicality that centralised information aggregators cannot.

15.6 Freedom and conservatorship

On 1 February 2008, American pop singer Britney Spears was involuntarily placed under a conservatorship with her father, Jamie Spears, and attorney Andrew M. Wallet as the conservators. The conservatorship lasted until November 2021 and raised questions over conservatorship laws in the United States and more than a few cries of ‘Free Britney’ from her fans. At its core, the idea behind a conservatorship is that the law can determine if an individual, for reasons of age or deteriorated mental health, cannot take care of their person or finances. In Britney’s case, the concern was both for her person and her finances. The results of the conservatorship were perhaps predictably troubling, as Britney brought a lawsuit with charges of mistreatment, coercion and conflict of interest. On 7 September 2021, Jamie Spears filed to terminate his conservatorship, although Britney’s fans will tell you that this was not out of respect for Britney so much as to avoid discovery, depositions and, potentially, a trial involving Mr. Spears.¹⁰

Our concern here is not with Britney per se (although we are happy she has been subsequently freed) so much as it is with all the other people put in this position and also with the very unclear line between people who need conservatorship and those who do not. Finally and most importantly, we are concerned with the conceptual issue of when blockchain communities are entitled to permit conservatorship over their citizens. Here, we are returning to an issue raised much earlier – the rights individuals within blockchain communities have to know about external communities, the rights they have to exit their community and so on. Do blockchain communities have the right to deny the rights of seventeen-year-old citizens to explore other communities? Do they have the right to deny exit? And if the age of liberation is not seventeen, when is it? Is age the only reason to insist on this sort of conservatorship, or should other considerations like emotional health be factored in, too? Can a blockchain community restrict the right of exit and access to individuals like Britney Spears?

Now, obviously, this is not really an issue about blockchain technology, but it certainly is an issue about the rights of community members, and whatever the technology grounding a community, there is an issue to be addressed here. The issue cannot really be escaped by blockchain communities. The question is, do blockchain communities have something to contribute to discussions about conservatorship? Do they add a new factor to be considered? Is there hope for future Britneys in the form of blockchain communities? Maybe.

In the first place, as noted throughout this book, decentralised blockchain technology offers us more transparency, and presumably, this sort of transparency could only help people like Britney by ensuring that the details of their conservatorship are kept secure and accessible to the relevant auditors. It should not be necessary to go through a lengthy and expensive discovery process to investigate whether a conservatorship is being handled correctly. Recall that Britney’s father released her from her conservatorship when faced with the fact that he might have to be deposed in a court of law and have his records subpoenaed – in other words, he was concerned that his actions would become transparent, at least to the court.

Once again, we can see the importance of transparent, immutable records. One feature of such records is that they allow the entire community to understand the consequences of decisions being made with respect to conservatorship. The community’s decisions about conservatorship can be better informed, whether those decisions are being made on behalf of a pop star or an entire age group of children. Although decisions can be better informed, there is no guarantee that bad decisions cannot be made. It will be up to the communities to make these decisions for better or worse, and here we see the conceptual limits for blockchain communities; bad decisions can always be made by fellow humans. The best that blockchain technology can do is help these decisions be better informed and their consequences better understood.

15.7 The conceptual limits of transparency

In previous chapters, we carved out a broad class of things that citizens have a right to know about the conduct of their blockchain communities, but there are limits to what can and should be accomplished with respect to transparency. Total transparency may not be viable, for it is reasonable to think that community governments have to keep certain information secret – either for reasons of citizen privacy or security or economic strategy. For example, consider strategies for negotiating trade agreements – you do not want your maximum offer price to be public knowledge. Here, we get into interesting and difficult territory. If there are to be secrets, who will classify them as secret? And whoever it is, we seem to be back with a central authority and the consequent abuses that extrude from a central authority keeping something secret.

The dangers of allowing centralised secrets should be obvious. There have been countless examples of politically embarrassing facts, moral failures and politically damaging facts being classified as state secrets. In one of the most famous examples, the Pentagon Papers, US military analyst Daniel Ellsberg leaked confidential internal documents that acknowledged that the war in Vietnam was not winnable by the US.¹¹

However, perhaps a blockchain community can maintain secrets without centralising them. We naturally suppose that state secrets must be determined by a central authority because otherwise, how are they kept secret? If everyone knows it, it is hardly a secret. Therefore, it seems fair to assume that there must be a single official secret keeper. However, maybe this is not the case. Perhaps decentralised secret keeping is a possibility. One way to achieve this is via a protocol known as ‘Shamir’s Secret Sharing’, named after a 1979 paper titled ‘How to Share a Secret’ by Adi Shamir.¹²

Shamir’s Secret Sharing involves breaking encryption keys into pieces and distributing them to different members of a community. It then takes a specified number of community members to reconstruct the key. The theory is that the key will only be reconstructed for a specific purpose and only with the approval of a large enough group of community members.

One issue that Shamir’s Secret Sharing does not resolve is the problem of classifying secrets. Can that process be distributed as well? One idea is that we can decentralise the classification process if we, as a community, publicly identify the kind of information that we think should be classified and then leverage smart contracts and discreet oracles to gather that information and keep it secret until the community agrees to release it. This, in turn, requires that the information being gathered is offchain since any onchain information is, by its very nature, very public. Thus, we would need smart contracts that could access black box oracles and store the relevant information in their own black box, only to be accessed upon some community-agreed-upon actionable purpose.

There are all kinds of challenges that flow from such a strategy. Firstly, we have already talked about the fact that oracles tend to be points of centralisation. However, the other issue is that the strategy requires that certain crucial state secrets be entirely in the hands of black box oracles in which no human knows their contents. We can use zero-knowledge proof strategies to ensure that the oracles are behaving correctly in their classification of secrets, but even if we know enough about the oracles to be satisfied that they are good actors, they may still be vulnerable to attack.

Finally, there is the problem that tensions between the need for governmental transparency and citizen privacy will arise. For example, we often hold that leaders, like presidents, should make their medical conditions and financial holdings public, but in a blockchain world in which potentially anyone can become a leader of importance, the line between leader and citizen is very thin. Perhaps bots can be enlisted to review medical records and financial holdings, but as before, this raises questions about the trustworthiness and safety of the bots.

15.8 The limits of voluntary forfeit

A good case can be made that certain moral rights are voluntarily forfeitable. A Puritan community might forfeit its right to carnal pleasures or even the right to music and other forms of entertainment. After all, during the Reformation, the city of Geneva banned musical instruments and singing in harmony. You can imagine a community banning rock and roll or reggaeton music. However, even here, we get into interesting questions. If music has been effectively banned, how do you know enough about music to fully grasp what it is that you have agreed to forfeit? This seems to suggest that one must have the ability to temporarily step outside of voluntary self-censorship and witness how the rest of the world carries on.

The issues here are perplexing. A community may think it is in its best interest to protect members from outside temptations, and we can concede that such outside threats may, in fact, be threats to the community. On the other hand, intentional communities do survive even while quite obviously surrounded by communities with very different morals. The groups that accomplish this are too many to list exhaustively, but obvious examples include Hassidic Jews, the Mormons, the Quakers and the Mennonites, all of which survive quite successfully even while surrounded by peoples with quite different moral practices.

Thus, while access to the external world (and the visibility of alternative lifestyles) presents a certain level of threat to community survival, it is not a mortal threat, and we would suggest that any threat is trumped by the need for people to intelligently pick the community and system they want to live in. Citizens of North Korea may believe they live in the best country in the world, but this belief is forged with the help of their ignorance of the world around them, thanks to government censorship. They did not enter into those conditions voluntarily, but voluntary or not, no government should keep its population ignorant of the rest of the world. Access to knowledge of other communities is a right that cannot be forfeited because if the right to knowledge of alternatives is forfeit, the right to exit is undermined.

How far does this right to knowledge extend? Must a community provide a fair and balanced picture of the external world to its community members, or is it free to spin the external world as being defective or even depraved? The difficulty, of course, is that there is no fair and balanced picture of the external communities, and even if there was, there would be no neutral authority that could dictate what that picture is. Thus, it seems that while communities cannot restrict access to the outside world, they have the right to spin the merits of the external world as they see fit. Fair-minded communities will strive to be balanced, but individuals must find their own way to navigate through whatever propaganda their community generates. Acquiring knowledge from outside the community is not a frictionless enterprise.

Thus, individuals have the right to exit and the right to government transparency, and they also have the right to peer beyond their communities and sample external communities in a (mostly) unfiltered fashion. These rights cannot be forfeited. But might other rights be forfeitable? To illustrate with a case we discussed earlier, could one join a community in which one is a voluntary slave?

Here again, we bump up against the issue of demands that are generated by the right to exit. Even voluntary slaves cannot surrender their right to knowledge of the external world and their right to knowledge of internal facts about their government. It follows that they cannot forfeit their rights to basic education or to virtually visit other communities as a free person or do anything that might allow them to know what they are missing out on given the choice they have made.

There is also the issue of whether you can forfeit your right to the material resources to exit and start over somewhere else. Maybe volunteer slaves must post a deposit sufficient for them to move on should they choose to do so one day. To some extent, this means that pure voluntary slavery is not an option, given that the capacity for exit must always remain available and may not be surrendered. So too, the knowledge of exit possibilities and alternative life experiences must remain available and may not be surrendered.

To push a little further on this point, let us imagine someone who chooses to be ignorant of alternative life possibilities. They buy into the culture of their community and voluntarily take a pill or engage in mental exercises that steel themselves against acquiring knowledge of alternative cultures and possible life experiences. It is inevitable that we encounter difficult cases on the margins, and quite clearly, these count as difficult cases. Taken to its limit, freedom means freedom to surrender freedoms and freedom to be ignorant. However, we all recognise cases in which we wilfully did not consider options and came to regret those choices. What then of cases where we are never in a position to question those earlier decisions? Does this not make us prisoners of decisions made by our past selves?

This suggests that people should always have the tools and resources to unwind their past choices, and that communities have the responsibility to provide these tools and resources, even when doing so appears to conflict with the integrity of the community. The right to exit trumps community integrity.

This chapter has been about conceptual limits, and accordingly, we are not saying we can solve these conundrums. Hard decisions are coming. As we said, the goal of this chapter is to understand the limitations of what can be accomplished with the deployment of decentralised blockchain protocols.

By now, it should be clear that no technology stack by itself can solve for all of these conceptual problems. The bigger issue is that we can really only expect these technologies to work if community values are correctly aligned. There is no victory in distributed trust if everyone is untrustworthy. Similarly, there is no victory in a decentralised network if every node is left vulnerable. Of course, there is no victory in a fixed monetary supply of 21 million BTC if miners and developers do not defend that maximum supply. Human beings need to be value-aligned with the technology stack. We turn to this issue in the next chapters.