Looking for the Soul in Satoshi’s work

So much of the current conversation, debate, and decisions that are to shape the future of our much-loved modality of life we like to call blockchains suffers from intellectual myopia.

It seems that many folks want to view blockchain as just i̵n̵f̵o̵r̵m̵a̵t̵i̵o̵n̵ technology, without embracing broader implications. These views end up being tribal, limited and fall short of realizing blockchain’s full potential.

By learning from other older disciplines, we can help each other toward a more expansive and nuanced vision for the future of blockchains. This paper is an attempt — a heartfelt search for “Satoshi’s” [socio-legal] soul.

1. Soul-Searching

Let us start by outlining several premises and intuitions.

Contracts aim to secure us from counterparty risks. But legal texts mean different things to different people,¹ thereby leaving room for the parties to act on it in their own way. This is unlike the computer code that executes the same way for the same set of inputs on the same kind of computer.

Code is objective, human language is not.

Imagine contracts written in computer code that are executed automatically under the conditions set in the contract. That is the promise of smart contracts.

Smart contracts are self-executing programs that run on blockchains and accept digital signatures to record the agreement between stakeholders.

• Car Sales Contract — “Transfer the title of the car” only if “the asked amount has been paid”.
• Fish Sales Contract — “Allow this fish to be sold” only if “it is an organic and fair trade in the supply chain”.
• Crowdfunding Contract — “Transfer a part of the fund to a project owner” only if ”the supermajority of backers have approved to do so”.

A network of computers periodically checks whether the conditions of any of these programs are ripe for execution. If most of the computers approve that it is so, the program is executed without needing the parties to do anything.

2. The Case of the DAO

Now, let’s consider one of the most pivotal smart contracts in the Ethereum blockchain, The Decentralized Autonomous Organization, or The DAO. It was basically a decentralized crowdfunding application, as conceived in May 2016.

On June 17, 2016, someone was able to draw out a sizeable portion of the fund in a highly unexpected way. It was beyond the expectations of the creators and the funders of the contract. They claimed it to be a “hack”, thereby demanding that it be rolled back or blacklisted.

But for the “unexpected” transaction to have been executed in the first place, it had to get approved by the majority of the network as is the case with all programs in a blockchain. The code, devoid of human interpretation, was executed correctly by the computing machines.

There is an open letter claiming to be from the “hacker”, where his interpretation of the contract was described:

I have carefully examined the code of The DAO and decided to participate after finding the feature where splitting is rewarded with additional ether. I have made use of this feature and have rightfully claimed 3,641,694 ether, and would like to thank the DAO for this reward. It is my understanding that the DAO code contains this feature to promote decentralization and encourage the creation of “child DAOs”.

Finally, the interpretation of the creators and the funders of the contract, as backed by the Ethereum foundation, won over that of the so-called hacker: the transaction was rolled back.² This was a controversial decision leading to a part of the network breaking off to create their own blockchain where the transaction was not rolled back.

Is correctness of code execution the final arbiter of a contract dispute, or are we to interpret the intentions behind the code over its correct execution? In the same spirit, is code more important than its execution?

3. Key Confusions Around Smart Contracts

3.1. Self-executing programs

The claim to fame for smart contracts is that it is the only means to execute programs securely that suffer from counterparty risks. Think of a Delivery-versus-Payment scenario, such as the car sales agreement from above.

The buyer and the seller can execute their sale program on the blockchain, with the guarantee that neither would be able to take advantage of it in any way.

But this is not because of anything specific that smart contracts bring to blockchains. Rather it is the opposite — blockchains provide objective code execution infrastructures.

This is because the code is executed in blockchains only if it is approved by a majority of computing nodes that it follows the protocol. This ensures that none less than the majority of computing members own or control the execution of code running on it. Neither the developers of our car sales contract codebase nor the parties of the contract (buyer and seller) will be able to influence the contract execution to their advantage.

In fact, we can implement escrows, like the one above, using scripts in Bitcoin³ irrespective of the fact that Bitcoin does not offer an expressive computing language⁴ like that of Ethereum. All we need is an objective code execution infrastructure (i.e., the Bitcoin blockchain), and a programming language with the conditional operators to verify if the amount asked has been paid at the same time as the car title has been given for exchange.

Therefore, we need only a limited set of operations in a blockchain-based code to guard against counterparty risks. Smart contracts are overkill for the job at hand.

This is the source of the first confusion — smart contracts introduce self-executing programs to blockchains. The truth is the opposite. Smart Contracts are more like trust-minimized stored procedures or programmable transactions.

3.2. The Inevitability of Human Intervention

The inevitability of human intervention to resolve disputes is not because there were bugs in the smart contract code. This was about language and reality.⁵

Even if a smart contract code is bug-free and does exactly what it is written to do, there is no way to ascertain that it is doing exactly what the stakeholders intended it to do as described in its specification.

The best we can get is specifying the software in formal terms, and then deducing the code from it. There is currently a lot of research by Ethereum developers to apply this approach. However, formal methods are difficult to specify complex business processes.

As evidenced in The DAO dispute, programmers are the mediators for smart contract disputes, just as lawyers are for legal contracts. Reddit and Twitter have become the arbitration forums for smart contracts, but there are no formalized rules and precedence on these kinds of mediation.

Bugs (or theft) are not the most important factor behind disputes, the limits of language and understanding are. This is the source of the second confusion affecting smart contract proponents — Irrespective of bugs or theft, human intervention is inevitable to ascertain if the code is what the software aimed to do in the first place.

3.3. Humans over Machines

In a techno-utopian world, machines interact with each other executing code when the conditions for business are ripe without having to wait for pesky humans. This is prevalent beyond the world of blockchains, as can be seen in IoT networks.

Machines are predictable, humans are not.

But machines execute code on behalf of or at the command of humans. If machines could be self-sovereign to the extent that they never need any humans, there will be no kill switch⁶ when things go very wrong.

The “no kill switch” dilemma is faced when the human members of a blockchain have to decide whether to change the history of a blockchain to handle disputes. This turns into a highly political process since blockchains are supposed to respect the immutability of non-living machines over the changing nature of the humans operating them.

This is the source of the third confusion — blockchain designs typically over-value mechanistic execution and under appreciate human creativity and change.

3.4. Law over Code

Smart contracts enthusiasts often tout the famous line by Lawrence Lessig, “Code is Law”. This is problematic.

• Code can be deterministic or not, it is the former in the case of blockchains. This means the same code produces the same out under similar execution environments, which is crucial and necessary for the blockchain network as a whole to agree on the correct execution of every piece of code as run by hundreds and millions of computers.
• Law could be any of the two modalities for which we use the word: the law of physics (scientific laws), and the law of a legal system. The former is deterministic and [relatively] immutable, while the later is mutable under a due process (legislation, deliberation, etc.) as well as contextually variant being tied to human and socio-political factors.

Blockchain-based code and the scientific law are similar in terms of determinism but not so in terms of immutability as code can be upgraded. If a scientific law gets updated, the old one is not considered a law anymore but was a mistake until we knew better as scientific laws are supposed to be eternal.

Blockchain-based code and the law of legal systems are similar in terms of mutability. However, this focus on determinism, or our emotional need for one as computer scientists designing these systems, leads us to project the immutability of scientific laws to that of code as well. This is what philosophers refer to as a category mistake. To quote its Wiki entry

A category mistake, or category error, or categorical mistake, or mistake of category, is a semantic or ontological error in which things belonging to a particular category are presented as if they belong to a different category, or, alternatively, a property is ascribed to a thing that could not possibly have that property. An example is the metaphor “time crawled”, which if taken literally is not just false but a category mistake.

Code is deterministic like the laws of physics, much more than the laws of a legal system, but code is malleable as well in regards to upgrades, much like the laws of a legal system.

However, when that network-wide agreement on the correct execution of the code gets questioned due to a difference of interpretation⁷ between groups of stakeholders, there is no explicit higher authority to appeal to. This is because Reddit, Twitter, and the Ethereum Foundation do not equal the institutional intermediaries that legal systems operate under.

Here, we saw the source of the fourth confusion — the two meanings of law (contract versus physics) are considered gets conflated to bestow the property of immutability to code via a category mistake.

3.5. Summary of the key confusions

As Lawrence Lessig puts it in his Open Code and Open Societies:

Now I’ve made something of a career telling the world that code is law. […] I meant that originally as a metaphor. Code is not literally law; code, I argued, was like law.

It is time to rethink this code-law metaphor and homology. Reflecting more broadly on code vis-a-vis law— is code like:

1. the laws of physics? Or,
2. the laws of a legal system? Or,
3. some weird mix-n’-match of the above two? Or,
4. none of the above, i.e., a wholly different modality of law, let’s say, the “laws of computation”’ — ?

4. On the Immutability of X: Beyond the Code-Law Confusion

4.1. The Soul of Software

Questions of immutability are really questions about the soul of particular human relational forms, processes, and/or set of institutions. “Soul” is a useful category, for it is that which gets defined as the changeless, that which is eternal, and stays the same from the first block and forever.

(Editor’s Note: Allusion to, and invocation of, a category like “soul” may seem abstract, but we should recall that totalizing standards and tests like these abound in different legal traditions, including in contract law. Consider legal fictions like the “predominant thrust test” (in choice of law inquiries); “object and purpose” tests in good faith, interpretation, and various defense contexts; “materiality” and “totality” inquiries in the doctrine of breach. All of these are legal heuristics for talking about the “gist” or “essence” (e.g., the “soul”) of a given agreement, term, and/or set of agreements.)

In terms of the question of the soul, instead of focusing on the immutability of only “code,” we should rather look at the larger context code is in, that being the piece of the software it represents.

First and foremost, we must ask: What is the soul of a piece of software, or, what is that one thing that makes it what it is? Additionally and/or alternatively, where doth the soul lie in a piece of software?

Depends on who you ask:

1. For programmers, the soul is often to be found in either the underlying code or the executable binary;
2. For algo and UX designers, the soul may be in the specifications (be it, the Functional, as in EIPs, or the UX spec) that define that software;
3. For customers, the soul may be a collection of expectation interests — the requirements they signed up to when asking for the software to be built and run in the first place;
4. For end-users, the soul may be formalized in the T&Cs they agreed to when signing up for a given product and/or service;
5. For the founder behind the idea, it’s the initial insight and intuition that called for its making —

And so on and so forth (to each her own; like for regulators, capital providers, the media, et al).

Since so much of the current discourse is mostly dominated by programmers, it centers on the immutability of… “code”.

Please note that how we view the soul influences how we act. Protocol programmers may have one view (or, say, a range of views along a similar vector). By contrast, for the creators and curators of The DAO (as was evidenced by history), it was the “requirements” or even the “specifications”, leading to the code being updated to keep it in line with that. But for the “hacker,” the soul of the code was … what the code meant to her (in that time). The problem with The DAO was that the question of the soul was never explicitly and clearly articulated by its stakeholders. Even in the most strident moments of The DAO debates, soul-searching remained largely implicit — which led ETH and ETC to diverge based on their identification of competing soul(s — ?) of Ethereum.

Charles Hoskinson, one of the founders of Ethereum, was asked by ethnews of his decision to leave Ethereum as a result of the DAO fork, and this is what he said about his view of the soul of Ethereum, though he did not explicitly use that language

What unified me with the Ethereum movement, why I wasn’t so bitter or harsh until recently — was that I still believed in the social contract of Ethereum. [I believed in] this idea of a world computer that is censorship resistant and the code is immutable

Thus, “immutability of what” depends on who is asking the question of the soul. It is time we start articulating it loudly and explicitly. We are in the middle of one of the most consequential battles for the soul of software.

4.2. There is no one true soul

The central problem preventing us from making community-wide progress in this battle is using the wrong, and might I saw, outdated, tool. This is the tool of “essentialism” — as if things have a single essence, a single cause, a single determinant. This leads to different camps fighting over whose essence is the one true essence.

History, especially that of religions, has taught us that adopting a pluralistic stance, instead, is the more holistic and future-proof response to resolving these disputes. There is not one true soul or essence inherent to “smart contracts,” to blockchains, or to any other form of social relation.

History teaches that pluralism is a more holistic and viable adaptation posture than one-size-fits-all paradigms.

So to approach the question of “Immutability of X where X = {code, requirements, specs, T&C, …}”, as a community, we need to call for an “it depends”⁸ answer.

4.3 Crypto Soul Searching

These themes need a deeper inquiry on a case-by-case basis.

With time, we will have some common understandings that can be taken as rules of thumb, much like what happened in the history and evolution of legal systems. Entirely new breeds of intellectuals — the crypto lawyers, and crypto theologians —are emerging to tackle these questions.

At the intersection of crypto law and crypto theology, we may find crypto legal theologians. These won’t be “lawyers doing crypto,” or “crypto coders doing law,” or some weird combination of both, but a somewhat novel species of intellectuals. We will introduce crypto theology at the end of this paper.

5. On the Role of Crypto-Lawyers

5.1. Contracts as Trust Vaccinations

When you sign an employment contract, you don’t actually refer to it every second of your work, but only when things don’t go well. Contracts are not instructions, which are executed to do something, but instructions that act as navigational tools for resolving disputes if and when they happen. That is why when you help out your friend for her work, there is no need for a contract as the friendship trumps over possibilities of conflict when it deals with trivial matters. No dispute, or the lack of the possibility of one, no need for contracts.

To put it differently, if I am meeting a friend for dinner and we are splitting the bill, we do not sign a contract to be able to execute the split. However, if the world comes to an end, and our wallets are the last refuge of money, then, of course, a contract might be good to be used for splitting the bill. Only under duress, when stakes are high, or when trust is hard to find in a relationship, does a contract come as the navigational tool to make it work.

Now coming back to the employment contract, you still do need a contract as you might have a high level of trust as you begin your new job (or else, why would you chose this employer even), but you both sign on the contract as vaccination of sorts. The principal utility of contracts is trust vaccination, which allows us to navigate in a low trust situation in an uncertain future.

5.2. Code as a Pedagogical Tool

As a contrast, when you use an app on your phone, say for ordering pizza, you execute the code in the app, irrespective of trusting the app or not.

Pizza, Pizza

Code execution is certainly not about navigating a low trust space of pizza ordering but for making this machine, the smartphone, do what it needs to do. This is because the machine is dumb by itself unless specifically instructed by means of code.

Code exists to instruct dumb machines to do clever things by encoding all the cleverness in language that even the machine can understand. In principle, this is what programming is about. The principal utility of code is pedagogical — instructing (educating) otherwise dumb machines to do clever stuff.

The principal utility is where contracts and code exhibit differing souls: trust vaccination for the former, and pedagogical for the later.

As new crypto lawyers, we must ask the following key questions to direct our inquiry further:

1. When can a code be a contract as well? (We must be able to answer this if the terminology of “smart contract” is to mean anything.)
2. When is a contract a code?

5.3. When can a code be a contract?

If there is a dispute in the pizza ordering from my phone, and we can decompile the app to get its source code, we could then utilize that code to argue and resolve the dispute, provided the resolution is legally complaint for all parties involved.

By legally complaint, I mean that similar to how legal dispute resolution works, the code must allow us to use precedence/precedent (prior code execution history from previous blocks) in increasingly complex jurisdictional webs (including, potentially, novel approaches like shard-based jurisdiction).

Instead of focusing solely on code (as the result of the decompilation and reverse engineering), we could do better by adopting the pluralistic approach: the soul of the app is also in the T&Cs that the end-user signed up to, is also in the requirements that the app maker finalized, is also the specifications that the engineering team defined, and so on and so forth.

As an example, a particular section of the requirements document could be used to resolve the dispute. But for all these pluralistic souls, we, as the community of crypto-lawyers, must embody and encourage the culture of packaging all of the aspects of the soul of software, not just the code, when publishing it so it could always be referred to when need be. We need to develop a system of establishing connections between these aspects and some guidelines (the interpretive grammar of the soul) as to refer to them.

5.4. When does a contract act as the code?

In low trust environments, stakeholders refer to their contractual agreements or, at least, they pretend they do, to each other every step of the way. This is bureaucracy in action. This was the case when an over-codified group tries to coordinate, such as the case of cults, or of certain government offices.

6. Automatic Law: An Oxymoron

6.1. Law is not The Law

Even contractual law is not Law⁹ in itself. Law becomes the law-that-is-enforced only after it is interpreted by human institutions of authority and power. These institutions provide the formalized rules to interpret legal text correctly — which other cases or contracts can be cited, what authority can override it, criteria for applicability of the contract and so on.

If you can not enforce it, it is not the law.

But enforcement only makes sense in the situation of one attempting to not follow the norm of the legal code.

There is a paradox here. If a legal order can e̶nforce compliance on you when you are attempting to break, it is an effective law and is of any use. If not, it is just some rules written in some books or heralded by some of its believers without much effects, such as those who believe in the monarchical legal system in France.

6.2. Execution ≠ Enforcement

If there is no wiggle room for rule bending, the point of e̶nforcement does not even arise.

This is key to understanding why code execution is not the same as enforcement since execution does not leave room for wiggling as the processors will compile what goes in a GIGO fashion. (GIGO = garbage in, garbage out; quality of outputs depends on the quality of inputs.)

This is similar to a dictatorial setup in countries like North Korea, where it does not need enforcement as everyone just does what they are told blindly without any significant resistance.

Force and resistance go together; if you don’t have one, the other does not exist.

In this respect, code execution, from a processor running zeros and one, is a purely dictatorial system. Using this angle¹⁰, one can argue that the so-called Law of North Korea is not legitimate because of the lack of the possibility of resistance vis-a-vis free-will.

Thus, execution does not equal enforcement as in the processors in consort (as part of the consensus of millions of computers) are not forcing onchain transactions to follow the unchangeable (soul?) rules of the blockchain.

Code does not enjoy free will, being just dead bits and bytes. It is only with respect to Byzantine attacks that one can argue that the network level consensus is forcing the attack to not be successful. The attack acts like resistance here, and thus, necessitates e̶nforcement against it.

This can not be said for blockchain bugs or hacks, as it is not a self-debugging and self-correcting system. Thus, it is enforcement only for the Byzantine attacks, which should not be projected out to mean all code execution equals enforcement as it happens in the case of the law.

This shows another case of category mistake: what was true for the category of consensus algorithms in terms of byzantine attacks is certainly not so for the category of code execution in terms of rules enforcement.

6.3. Automatic Law vs. Crypto Punctuated Law

As a result, the term, “automatic law” is an oxymoron, as law necessitates it to be not automatic, i.e, it should not run by itself with no stops or off-switches. Law needs deliberation in its process of legislation, judgment, and enforcement when rules are not followed properly. What can happen at best is punctuated automation of certain aspects of the law.

To state the obvious, a crypto lawyer does not work on the mythical beast of automatic law, but maybe he labors on making punctuated automation work when code could be a contract or when a contract could be (God forbid the bureaucrats) the code.

6.4. Agreements ≠ Contracts

In Western European and North American legal systems, agreements are necessary but not sufficient for the legitimacy of contracts. In order to reach an agreement, there has to be the “meeting of minds”. Here, the parties meet each other to discuss their current and prospective interpretations. Sometimes, these discussions are mediated by lawyers, which adds additional opportunities for m̵i̵s̵-interpretation.

Then post-execution of a contract, in cases of disputes, the differences in individual interpretation are discussed, as mediated by the respective lawyers in a court of law, or via arbitration, or other dispute resolution modality. (A temporary resolution may be secured, but even in the case of a formal settlement agreement following, say, trial, the outcome is never 100% certain. Parties can always challenge a formal settlement agreement that tries to resolve an earlier contract dispute.)

Contracting is a process of deliberation with complete acknowledgment of the free will of the parties to deliberate and deny it in any of the following steps: Meeting of Minds → Agreement (signatures) → Execution on conditions being met → Dispute resolution if needed.

We are not arguing here whether free will exists in reality beyond the mere concept, for that is beyond the scope of this paper. Rather, the moot point is that as a concept, it is an oppositional one, and as long as its presence is acknowledged in the semiotic space of a contract, the contract does not lose legitimacy to be considered beyond being only an “agreement” in an extra-legal sense.

All contracts are agreements, not the other way round. Thus, ironically, blockchain based code execution is effective at trust-minimized digital agreements at scale, but not at true enforcement due to the lack of its opposite (free will to deter).

Hence, punctuated automation of law-leveraging digital agreements is the great gift that crypto lawyers are here to bestow upon us. To make the most of this gift, we must study the operating manual — alongside writing it.

7. Crypto Theology: Back to Basics

Nodes collect new transactions into a block, hash them into a hash tree, and scan through nonce values to make the block’s hash satisfy proof-of-work
requirements. When they solve the proof-of-work, they broadcast the block
to everyone and the block is added to the timechain. The first transaction
in the block is a special one that creates a new coin owned by the creator of the block.

— Satoshi Nakamoto [Source]

[Emphasis added by this author, not Nakamoto]

7.1. Blockchain as the Computational Watchmaker

Computing machines are automatons. Many epistemic systems view nature as an automaton as well. How we think about the latter should help us pluralize the former.

The laws of nature, the ones that form the foundation of our natural sciences (physics et al) are modelled as being “immutable” that is, eternally true. So it makes sense that the word “law” has its etymological and theological roots in, “being laid down by God.”

Yet if a computing machine ran code that was eternally true, our only proper relationship to it would be to let it run uninterrupted—to respect its immutable nature.

The first time humans got close to such a machine that ran an eternally true code was with the invention of the first precision clock by Pierre Le Roy in Paris in the 18th century. Once installed, it made sense to let the clock be, run its hands without tampering it. Time is eternal, once passed, we never go back and turn back the clock. Immutable time-keeping at work. Ius machina!

As a cultural influence, the person who was more than anyone responsible for the development and our idea of the scientific laws of nature, Isaac Newton described God as the “watchmaker.” Even Descartes and Darwin were of the same view.

The high priesthood’s fascination with time-keeping continues to the present day. In the blockchain world, the time-keepers even have special privileges and honorary titles: core devs.

7.2 Devs as Time-Keepers & Time-Cops¹¹

Those who claim that blockchains should run like the cosmic watchmaker (read: core devs, Nakamoto, Eth Foundation) broadly intend that we must respect blockchain immutability: once an on-chain event occurs, there is no turning back time. Yet in so doing, are we just making subconscious theological arguments?

These positions above reflect a broader mainstream trend to view the universe as not only some cosmic clock but as a cosmic computer. Even the human brain is increasingly viewed as a neural computer. The horrors!

When entering the world of crypto, we see a big red disclaimer on the gates:

Blockchain transactions, once executed, are the manifestations of pure time itself as a binary string. Do not even think of changing this protocol except of course for ensuring the accuracy of the time-keeping mechanism (read: except of course for technical reasons only).

You don’t want to vex the Gods¹² of Time after all.

This special relationship with time is particularly pivotal in designing distributed systems. These themes lie at the heart of the blockchain revolution. Leslie Lamport’s 1978 seminal paper — “Time, Clocks, and the Ordering of Events in a Distributed System” — later led to his own development work on Byzantine Fault Tolerant systems with Marshall C. Pease and Robert E. Shostak.

This gets especially weird¹³ when you notice that Nakamoto modeled his PoW to act as “a peer-to-peer distributed timestamp server”, and timestamping is so key to that paper that its mentioned fourteen times in its nine pages. Blockchains offer novel utility because of their unique approaches to managing age-old time-coordination problems. Beyond the narratives of #CodeIsLaw/#CodeAsLaw, the ability to control transactional space-time gives today’s blockchain time-keepers immense power, a la #CodeIsTime > #CodeIsLaw.

Of course, code is not pure time, as is claimed in the couched rhetoric of “math at work” so commonly deployed in defense of immutability. But understanding time is a key prerequisite for understanding power.

In this respect, the predominant confusion is manifested in the incorrect use of the term, “self-execution” to refer to automatic or even autonomous execution but there is no self that is executing. As an alternative, the term, “clockwork execution” is more accurate and appropriate for blockchain based code execution. This is a better way of clarifying § 3.1.

Since the blockchain runs no code that is eternally true, we should not make a virtue out of immutability. In fact, figuring out which code stands true over time is to decide the soul of the blockchain based software. These will be the eternal pieces of code execution that make it into a high precision clockwork.

7.3. Soul as the Timeless and Immutable in Every Watch

You can see a parallel to this in legal systems, where some constitutions, such as the Bangladeshi one, have Eternal Clauses¹⁴, like the clause that specifies how to make amendments cannot be amended itself.

This is part of the Constitution’s ‘basic structure’ — the preamble, being a Republic, fundamental principles of state policy, etc. The Eternal Clauses prevent the ultimate demise of the constitutional system from a slippery slope of amendments amending itself to a state of irrecoverable chaos. In this regard, these special clauses act as Schelling fences which is a kind of a hard line (“no more amendments beyond this point”) to stop slippage along the proverbial slope.

Similarly, it will be fascinating to see if a blockchain community comes up with eternal pieces of code as well. This could include code that, say, determines the supply of the protocol’s coin. Today, there are already many eternal pieces of code in the collective unconscious of the community that operate as Schelling fences. However, many of these are implicit. Thus, the location of the fence(s) depends on who you ask and when (before a crisis, whose crisis, etc.).

Adopting a pluralistic vision of blockchain soul as argued in § 4.2 allows our search for eternality to go well beyond just pieces of code that “stand the test of time.” The fantasy of control over time fuels the promise of eternal growth. Seeing the fragility and artificial scarcity of time is key to internal growth. The two are not mutually exclusive.

What is soulful, and hence, eternal to you depends on where you are looking at the software as much who you are in the community. For the Bitcoin community, this came to the fore with the contention around the eternality of the block size. For the Ethereum community, blockchain time travel played out most dramatically in The DAO crisis. The main questions— “till when do we allow to make changes, when do we say enough, as a hard line?” —are far from answered.

It’s time for us as communities to raise our theological awareness around matters of the plurality of the soul of software, and push ourselves beyond the myopic debates on immutability. Immutability is ultimately a question of one’s time horizons. There’s a clear need to push our time horizons further.

There is no singular soul and thus, the Schelling fences for time, for mutability, for enforceability, etc. are not even linear. Blockchain’s Schelling fences and scaling fences are multi-dimensional as well as multi-perspectival. Here’s an interesting list to get started thinking on these by Vitalik.

7.4. Freeing Us From the Capture of Our Souls

Calling for legal minimization¹⁵ is like back in the day when the Catholic Churches were the only ones owning the one true clock of the village (and thus, the bell every hour). Geographically (and politically), the Church used to be the center of the town. Without wall clocks of their own, everyone defers to the centralized keeper of time and social order.

Calling for political minimization is like treating the lay people as lay only, instead of calling for the Lutheran slogan, “every man his own priest.” That slogan did result in the somewhat decentralization of the Christian faith through the proliferation of a million Protestant denominations. (We should also recall that the decentralization of the Christian church went hand in hand with the decentralization in the means of production of core technologies of social control: the democratization of the printing press and … watch-making. That Switzerland, even with its crypto valley, remains a constant locus in this history is a fascinating socio-political story in its own way, beyond the scope here).

8. Crypto-Cultism: Camps for the Soul

As we think about the emancipatory potential of new consensus protocols for time, law, and knowledge production, we should be mindful of the power of crypto denominationalism. Crypto pluralism is great. But crypto-cultism that forces adherents into oppositional camps is poison.

Today there are many camps for one’s blockchain soul. Some of the ostensibly strongest turn out to be some of the weakest. We should resist the temptation to classify ourselves as members of this or that blockchain cult.

For example, there is a clearly identifiable stream of Ultra-Conservative (read: Orthodox) Blockchainism. Its high priests (read: “time cops”) espouse the following mantra:

Do not implement changes to the blockchain protocol unless the changes are required for the purpose of technical maintenance.

In this mantra, it is the part starting from the word, “unless” that introduces the Schelling fence. It’s like saying, “Do not amend the constitution unless it relates to the non-eternal clauses”.

Ironically, this mantra suffers from its own slippery slope where one could argue that all changes to be not technical enough. Even without that self-contradiction, the eventual words, “technical maintenance” would only make sense if code existed for code sake, which is absurd¹⁶.

As we saw above, code always already exists in the milieu of everyday problems being solved through software. Software code is just one aspect of [software] code-based relations, alongside requirements, specs, T&Cs, etc. Thus, from this pluralistic alternative, there really is no binary divide between the technical and the non-technical.

Even from the perspective of employing language carefully, the word, “technical” has been hollowed out of its meaning in our current times with software eating up the world ever more so, leaving fewer and fewer things that can still be called “non-technical”. Hence, the irrelevance behind using such binaries. It is as if we still used the terms, “horseless carriage” or “electrical light bulbs”, or if anyone still used the word, “smart” as a qualifier for a device (e.g., smart phone, smart fridge, smart car) in the year 2030.

Thus, if we unpack the ultra-conservative mantra, the truthful version hiding underneath would be: “Do not implement changes to the blockchain protocol unless the changes are required for the purpose of t̵e̵c̵h̵n̵i̵c̵a̵l̵ maintenance.” But then this is a tautology, and there is no point in saying an informationally hollow sentence.

Instead of cults and mantras, what could be more useful is if blockchain communities came up with their list of Schelling fences corresponding to real categories and not the hollow one of “technical” — “Implement changes to the blockchain protocol except/till the changes that affect the soul of the blockchain.”, or to put it in its proper religious garb, “Keep blockchains pure.”

9. Reclaiming “Satoshi’s Souls”

Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model. Completely non-reversible transactions are not really possible since financial institutions cannot avoid mediating disputes.

— THE BITCOIN WHITEPAPER, SATOSHI NAKAMOTO

Without a powerful dispute resolution model for our blockchain-based processes where we get to deliberate on who gets to change what for whom under which purposes and interpretations with all who are involved, we will never fully realize Nakamoto’s dreams. Yes, I said it.

Okay, the Table once more, but with more rows than before

Crypto Confusion

(I had published the first part of this paper, till confusion #4 last year)

APPENDIX

(This is where all of the tangential by-the-ways go)

1. Legal Language Errors

All constitutions in the world are riddled with passages that are incorrect from a language construction point of view? This is because they are ratified by legal experts without consenting any literary experts. Take, for example, the one too many commas in the United States Constitution, such as the 2nd Amendment, “A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed.” — it is just wrong English. Or, the case of losing 1 million Canadian dollars for a single comma in a contract in Canada.

2. The DAO Fork Decision

What followed next was debates and discussions outside of the Ethereum blockchain, since it lacks a built-in subjective layer for dispute resolution. It was carried out in centralized websites, such as Reddit, Twitter, Medium, followed by final voting with carbonvote where only 4.5% of the network turned up to cast their vote.

3. Bitcoin Escrow

For examples of escrows written in Bitcoin script
https://github.com/starius/bitcoin-escrow-article/blob/master/article_en.md
https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/

4. BTC versus Ethereum programming paradigms

In regards to choosing between programming languages that run on blockchains, Turing complete or not is beside the point. In fact, if we consider the two most popular ones, Bitcoin and Ethereum, neither offer Turing complete code execution as the code always halts.

Since you pay for computations in Ethereum, the smart contract execution is bound by the economic limit which will run over in case the execution goes on forever. Bitcoin does the same by having no loops in its programming language.

In the spirit of blockchains being platforms to execute code objectively (§3.1), the deeper factor is that of ensuring predictability of code execution over its finality. This is addressed in Bitcoin using a declarative programming language, while in Ethereum with its gas limit to cap execution on its Imperative programming language (Solidity) which gives it more expressibility. The later does come with such corner cases as the 2017 Parity Hack. In this regard, Bitcoin scripts make for better security in terms of knowing what the program will exactly do.

Solving the problem of Halting is necessary but not enough, solving Predictability makes it complete — it has to half it has to predictably halt to be able to agree on the correct execution of code in a distributed network of millions of computers.

5. Code is Text

Code that serves human purposes, as a social network website, is not just instructions for a computing machine, but is set in a human context. There has been a growing trend in reading computer code as if reading a piece of literature. This is inspired by the post-modernist approach to reading a text as it reveals itself in its contextual and cultural milieu.

6. Kill Switch in Regular Contract Law

In regular contract law, the kill switch is enforced under “force majeure” measures, which “is a common clause in contracts that essentially frees both parties from liability or obligation when an extraordinary event or circumstance beyond the control of the parties, such as a war, strike, riot, crime, or an event described by the legal term act of God (hurricane, flood, earthquake, volcanic eruption, etc.), prevents one or both parties from fulfilling their obligations under the contract” [Source: Wikipedia].

7. The Human Reality of Impermanence

As what happened in the case of The DAO, what was one person’s hack, was another’s feature. But that does not mean there are no hackers, it depends on who is asking — it's complicated and needs debates and arbitration to resolve for the time being. There are no permanent resolutions. Any software code that does more than a one-off transfer of value, cannot avoid disputes due to the complexity of changing human relationships.

8. The “it depends” alternatives to Essentialism

Essentializing a piece of software as its code only leads us to ignore all of the other determinants that make it what it is. It is here that we make the mistake of essentialist monopolization, that allowing only one determinant (code) as the soul of software. Essentialism, and its cousins, foundationalism, monotheism always leads to tribalism over time.

Rather, a more holistic approach would be to look for the soul through its multiple determinants (code, spec, requirements etc), instead of one true soul. This approach has a name in philosophical studies, “overdetermination”. To quote its wiki entry

Overdetermination occurs when a single-observed effect is determined by multiple causes, any one of which alone would be sufficient to account for (“determine”) the effect. That is, there are more causes present than are necessary to cause the effect.

Some of its close cousins are Deleuze's Rhizome, Buddhism’s Non-Self, Gayatri’s Strategic Essentialism for the purposes of sub-altern studies.

9. Legal Formalism versus Legal Realism

These are opposing schools of jurisprudence. The former states that the law can be interpreted based on formal rules, thereby, making the interpretation objective and same for all parties and judges. The latter claims that the social context in which the law is applied in instrumental in interpreting the law, thereby making the application of law contextually dependent. Smart contracts seem to naively take on the formalist approach.

To bridge this gap between smart contract code and the legal text, there have been some approaches to link the two explicitly — Ricardian Contract, CommonAccord, Kelsen, Legalese, the Internet of Agreements, — the first of which is used in EOS blockchain, Corda DLT, OpenBazaar, and some others.

10. “Free will”, the concept that does not exist by itself

“Free will”, as introduced to the Western canon by Saint Augustine, is modelled as an oppositional term, as the will of humans against The Logos (that being the will of the God). Here, looking at the word, “enforcement” as an oppositional term as well makes sense as there is no enforcing without a force it is enforcing against, which in the case of jurisprudence, it is the force of the free will. In fact, if the agreement behind a contract lacked the free will of the parties involved, it is no longer a legally binding one. Then once all parties agree to it from their free will, if they can not carry out their side of the agreement from their free (read: unique, individual) arenas of the universe, the contract is nullified. That is why you can not make someone agree to terms that are not equitable, such as giving up your free will.

11. Time Cops

This is the title of a science fiction movie from 1994, as per the Google Movies entry

When mankind perfects time travel, the government establishes the Time Enforcement Commission to thwart criminal attempts to alter the timeline.

The officers working at TEC are referred to as Time Cops.

12. Immutability of the Religious Codes

Religions try to emulate this immutability of its basic principles (e.g., The 10 Commandments) by its claim to eternality and being given by the Eternal God itself. As an example, as Daniel Kronovet points out about the Jewish faith

one of the fundamental rules of Talmudic scholarship is that a recent scholar cannot contradict, reject, or overrule an older scholar. If a recent scholar takes issue with an historical analysis, the only avenue available to them is to reinterpret the intention of the older scholar. This chain of interpretation goes back, in an unbroken chain, to the first commentaries and ultimately to the old testament and the ten commandments.

13. Blockchain Core as a Distributed Clock

Proof of Work works as long as the work behind finding the nonce takes time in a competitive marketplace of other finders, and where this is verifiable, making it into a verifiable elapsed time mechanism. When this works along with the difficulty level adjustment, Bitcoin is able to maintain an average of about 10 minutes. In fact, what matters less is the accuracy of “10” minutes, but the accuracy in “the ordering” (before-after relationship) of the blocks, and that is another measure of time — as Lamport says in his seminal 1978 paper,

We have seen that the concept of “happening before” defines an invariant partial ordering of the events in a distributed multiprocess system.

You can say, every block is a tick in the digital and distributed clock and PoW is the Escapement Mechanism. Here is an interesting post exploring this idea.

14. Gödel’s US Citizenship Test

When the Austrian mathematician and logician, Kurt Gödel gave his US citizenship test, he pointed out to the judge that there is a flaw inherent in the US constitution, using which one could give herself dictatorial powers. It is referred to as “Godel’s Loophole”. To quote Guerra-Pujol’s paper “Gödel’s Loophole” @ http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2010183

the problem with the Constitution is the amending power in Article V and the logical possibility of “self-amendment.” In brief, if the amending clause of the Constitution can itself be amended, then all express and implied limitations on the amending power might be overcome through a constitutional self-amendment.

Later in the same paper

Gödel’s loophole in four logical steps:

(i) the Constitution contains a finite number of legal provisions or “constitutional statements”;

(ii) one of these statements contains an amending-power statement, which permits amendments to the Constitution when certain conditions or procedural steps are met;

(iii) the amending power can be used to amend itself; and

(iv) if the amending clause can amend itself, then all express and implied limitations on the amending power might be overcome through a constitutional amendment.

15. Legal and political minimization

Such a kind of minimization smell of a strange sense of purism that you see in religious fundamentalists keen on maintaining age-old traditions when all evidence is to the contrary. No wonder, in all religious orders, monks live minimalist (e.g., cloistered, basic means) lives, those basics as per their order are their Schelling fence lest they slip into more comfortable lives. For example, here are the eight obligatory items for Buddhist monks:

bowl; a double robe; an upper robe; a lower robe; a belt (to fix the robe around the waist); a sewing needle — with thread (to mend his robes); a razor (to shave the head and the beard); a water filter (to use water without killing living beings, to filter impurities in the water or fruit pulp –which is forbidden after noon).

16. Against the Hubris of Programmers

To reverse Linus Torvald’s “Talk is cheap, show me the code”, from a pluralistic approach, “code is cheap, show me the soul of the software” in all its uses, making, storytelling, cultural significance…