“Autonomous Self-Regulating Governance” Myth-conceptions

Confusing Blockchain, Chapter 3-2: Blockchain Myth-conceptions Part 2—“Autonomous Self-Regulating Governance” Myth-conceptions;

2/9/2018

Revised on February 16, 2018

In the ocean of blockchain topics in the web space, we frequently encounter blockchain-idealists’ mantras: popular ones are often associated with disintermediation (elimination of middlemen) and peer-to-peer system. It casts a radical notion that a blockchain-base distributed system can eliminate rent-seeking middlemen and, as a result, deter, or even eliminate an abuse of system by monopolist and oligarchs.

However, the reality of blockchain as of today is far from, is even contrary to, such radical notions. The gap between the popular blockchain-idealist’s mantras and reality has caused confusions about blockchain.

Despite the gap, their beautiful mantras continue to echo and have strong influence in shaping our collective perception about and our collective behaviour toward blockchain.
Are they hypnotising us with those deceptive mantras? Or, are we in the middle of a long journey to realise such a radical revolution in the way we organize transactions?

This series explores causes for the confusion. As a recap, the earlier blogs contemplated three suspects behind the confusion:

Here is a takeaway of this section:

Popular fundamentalistic blockchain mantras portray blockchain as a P2P system that can eliminate central governing authorities and rent-seeking middlemen; and, as a result, it shall deter, or even eliminate, the possibility of an abuse of the system by rent-seekers, such as monopolists and/or oligarchs. It casts a notion of a pure P2P paradigm that realises an autonomous self-regulating governance.

However, the reality of blockchain is far from this revolutionary notion. The Chapter 3-2 (this fourth blog) continues to explore “myth-conceptions”—myth arising from misconceptions—existing in blockchain space. It covers the following three myth-conceptions about “autonomous self-regulating governance” of P2P system:

Smart Contract Security Myth-Conception;
Immutability Myth-Conception;
Byzantine Fault Tolerant Myth-Conception

All these topics share one common source of reference: that is Dr. Gideon Greenspan, CEO and an Architect of Coin Science Ltd. In order to share a “super realism” view of Dr. Gideon Greenspan, this blog refers to three of his existing essays:

“Beware the impossible smart contract” (Greenspan, 2016);
“The Blockchain Immutability Myth” (Greenspan, 2017);
“Smart contracts: The good, the bad and the lazy” (Greenspan, 2015):

1. Smart Contract Security Myth-conceptions:

Smart contract is one of the particular features of Ethereum’s PoS. What is a “smart contract”? It is not simple to find THE definition of “smart contract.” And three examples of definitions of “smart contract” were presented in the previous blog: a copy is presented below in the appendix as well.

Wikipedia goes:

A smart contract is a computer protocol intended to digitally facilitate, verify, or enforce the negotiation or performance of a contract. (Wikipedia, N.D.)

That said, here, we see linguistic ambiguity in the term “smart contract.” “Smart contract” is a blanket term that covers two sub-categories: “smart contract code” and “smart legal contracts.”

“The term “smart contract” has no clear and settled definition. (…)
The different definitions usually fall into one of two categories. Sometimes the term is used to identify a specific technology – code that is stored, verified and executed on a blockchain. Let’s call this type of definition “smart contract code”.
Other times, the term is used to refer to a specific application of that technology: as a complement, or substitute, for legal contracts. Let’s name these “smart legal contracts”.
Using the same term to refer to distinct concepts makes answering even simple questions impossible. For instance, one question I’m often asked is simply: what are the capabilities of a smart contract?” (Stark, 2016)

Now, let’s focus on “smart contract code.” From now on, when we see the word “smart contract,” it refers to “smart contract code.”

“when smart people hear the term “smart contracts”, their imaginations tend to run wild. They conjure up dreams of autonomous intelligent software, going off into the world, taking its data along for the ride.

Unfortunately the reality of smart contracts is far more mundane than all that:
A smart contract is a piece of code which is stored on an blockchain, triggered by blockchain transactions, and which reads and writes data in that blockchain’s database.
That’s it. Really.”
(Greenspan, 2016)

Smart contracts of Ethereum applications have been attacked a few times in the past and revealed the poor integrity of its security.

Here is a list of empirical incidences that revealed the lack of integrity of smart contract applications:

Case 1: $50 Mil value was hacked at the DAO, a decentralised “autonomous investment fund in (July, 2016).
Case 2: $31 Mil value was stolen from Parity’s wallets. (July, 2016)
Case 3: Ethereum in a range of its value from $150 to $300 was permanently trapped or frozen in the system. (Nov, 2017)

Especially, the second case has a serious implication. Parity was founded by Gavin Wood, one of Ethereum co-founders. This tells us that peer-reviews done by the co-founder’s Parity and its developers (and possibly Ethereum Foundation) were not enough and could not guarantee the system.
These cases revealed the vulnerability of smart contract applications and raised a question about the necessity of third-party auditing. That would lead another involvement of the third party intermediary and question disintermediation myth.

Dr. Gideon Greenspan (2016) emphasises a limitation of “smart contracts”:

“smart contracts are simply one method for restricting the transactions performed in a database. This is undoubtedly a useful thing, and is essential to making that database safe for sharing. But smart contracts cannot do anything else, and they certainly cannot escape the boundaries of the database in which they reside.” (Greenspan, 2016)

Cut it short, the security of smart contract is guaranteed as long as its applications operate within the architecture of Ethereum, in which smart contracts are embedded. In a way, when smart contracts need to work with external systems, their integrity can be significantly compromised. Designing safe interfaces to guarantee secure interactions between a smart contract and external systems is a challenging work. Overall, a smart contract is prone to attacks. Thus, its security can be easily compromised. (Greenspan, 2016)

Dr. Greenspan stresses that smart contract is not capable of completing the following three actions by itself: 1) Interacting with external services; 2) Enforcing on-chain payments;
3) Hiding confidential data.

1) Interacting with external services:
Smart contract is not designed to coordinate consistent communications between internal nodes and external sources.

In handing the verification and validation process of one single transaction with an external service, independent multiple peer-review communications from internal nodes with the external source might suffer from inconsistent information about the particular transaction, depending on the given temporal conditions at the external source. It would cause confusion among nodes, thus, result in a failure to achieve consensus.
When the system needs to signal some information from the system to external data sources, it might face consensus issues among internal nodes.

2) Enforcing on-chain payments:
A smart bond case, a bond/loan application of smart contract, reveals one inherent constraint of smart contract. Dr. Greenspan summarises the constraints:

“in a blockchain-driven shared database, transactions can be created by any of that blockchain’s users. And since these users do not fully trust each other, the database has to contain rules which restrict the transactions performed. For example, in a peer-to-peer financial ledger, each transaction must preserve the total quantity of funds, otherwise participants could freely give themselves as much money as they liked.”

“A smart bond is directly issued onto a blockchain, with the blockchain ensuring that coupon payments are made to the bond holders at the appropriate times. All well and good. But what happens if the bond issuer has insufficient funds in their blockchain account to cover a payment which is due? The blockchain can certainly set a flag to say that something is amiss, but it can’t do anything else. We still need an army of lawyers and accountants to sort the whole mess out, whether by a haircut, debt restructuring, forfeiture or outright bankruptcy. In short: If smart contracts can’t deliver their promise, why are we paying their price?”

(Greenspan, 2015)

Since the viability of a smart contract is guaranteed within the boundary of the architecture of the blockchain that it is embedded. The total quantity of funds needs to be preserved in the blockchain system. To enable smart contract to execute a series of interest payments and principal repayment(s), all the fund needs to be trapped in the system. This would simply kill the purpose of the loan: the borrower cannot use the borrowed fund outside the architecture of the blockchain system.

3) Hiding confidential data.
Given the radical transparency of distributed ledger, it makes impossible for smart contract to guarantee confidentiality. Radical transparency and confidentiality face difficulties to co-exist together without external complementary workaround, which might compromise the blockchain system. There are workarounds to interface between smart contract codes and external systems beyond the boundary of the blockchain system. Nevertheless, such workarounds could compromise the integrity of the system’ security.

2. Immutability Myth:

Conditional Immutability

Recalling his statement in the white paper of Bitcoin, Satoshi Nakamoto clearly expressed that the immutability of the historical transaction records is CONDITIONAL:

“The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power.” 　(Nakamoto, N.D., p. 1)

In other words, if redoing of the proof of work does not take place, the historical transaction records cannot be changed. This condition is tautologically true.

Fork

The following descriptions illustrate “fork,” one example of a breach of the “no redoing” condition that is contemplated above.

“two different validator nodes might simultaneously generate conflicting blocks, both of which point to the same previous one. When such a “fork” happens, different nodes in the network will see different blocks first, leading them to have different opinions about the chain’s recent history. These forks are automatically resolved by the blockchain software, with consensus regained once a new block arrives on one of the branches. Nodes that were on the shorter branch automatically rewind their last block and replay the two blocks on the longer one. If we’re really unlucky and both branches are extended simultaneously, the conflict will be resolved after the third block on one branch, or the one after that, and so on. In practice, the probability of a fork persisting drops exponentially as its length increases. In private chains with a limited set of validators, the likelihood can be reduced to zero after a small number of blocks.” (Greenspan, 2017)

It seems to be a mis-design of the proof of work that does not have a built-in mechanism to prevent simultaneous validations from happening, then allow fork, which is the reason why to breach the “no redoing “ condition for the immutability.

Dr. Gideon Greenspan further goes:

“[I]t’s important to remember that each node is running on a computer system owned and controlled by a particular person or organization, so the blockchain cannot force it to do anything. The purpose of the chain is to help honest nodes to stay in sync, but if enough of its participants choose to change the rules, no earthly power can stop them. That’s why we need to stop asking whether a particular blockchain is truly and absolutely immutable, because the answer will always be no. Instead, we should consider the conditions under which a particular blockchain can be modified, and then check if we’re comfortable with those conditions for the use case we have in mind.”

Further, a more fundamental premise might be compromising the immutability of blockchain.

3. Byzantine Fault Tolerance Myth-conceptions:

Nakamoto imposes on the integrity of the blockchain system the third condition: the majority of CPU-power has no will to cooperate with a malicious party to attack the system. This is emphasised in the abstract:

“As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers.” 　(Nakamoto, N.D., p. 1)

Here is a background of this majority condition, Byzantine General’s Problem.

“Imagine a Byzantine army surrounding an enemy city. The army consists of divisions, each headed up by a general, and they need to establish a consensus about when exactly to launch their attack on the city.

Centralised command is out of the question. No individual general has line of sight to all the generals — or the authority to impose consensus on the whole army at once. They can only communicate by messenger.

So there’s an information problem. The generals need a system — an algorithm — that allows all generals to agree on a consensus.

The problem is made even harder because it’s not certain that all generals are loyal. Some have been paid off by the enemy, and are actively trying to disrupt the plan. The traitorous generals don’t want the loyal generals to come to a consensus.

Thus Byzantine Generals’ Problem describes the challenge of a) achieving consensus in distributed, decentralised systems b) when information flows imperfectly, and c) in the presence of adversaries.” (Berg, Davidson, & Potts, 2017).

Then, the solution of Proof of Work for the Byzantine General’s Problem is Byzantine Fault Tolerance:

Blockchains achieve Byzantine fault tolerance in part by treating it as an incentive problem. The Bitcoin proof-of-work mechanism incentivises good behaviour, makes it extremely expensive to attack the network, and reduces the payoffs for a successful attack.
The so-called ’51 per cent’ attack on Bitcoin — the possibility that a majority of hashing power could coordinate and then undermine the network — is what would happen if more than half the generals were traitors. (Of course, that itself would be hard to coordinate.)” (Berg, Davidson, & Potts, 2017).

Does Byzantine Fault Tolerance guarantee the integrity of the blockchain system’s security?

The premise of this Byzantine fault tolerance framework is the assumption that the chief general and a majority of his generals have unquestionable interest in sustaining the soundness of the system. What would it be, if the situation does not meet the premise?

The bitcoin blockchain and its ilk are not immutable in any perfect or absolute sense. Rather, they are immutable so long as nobody big enough and rich enough decides to destroy them. (Greenspan, 2017)

The Byzantine fault tolerance is not necessarily a perfect solution, when the majority of actors have interest outside of the system. Here comes with the “51% attack”: when a majority gain some benefit from the outside of the system by impairing its integrity. In this perspective, the premise of the Byzantine Fault Tolerant framework failed to meditate potential risks of a dictatorship, or even oligopolistic, abuse of power, which can hijack and compromise the system. The integrity of P2P systems could be significantly impaired.

This might explain why the ex-president of Zimbabwe, Mr. Mugabe, had no problem in impairing the monetary system of his country.

Besides abuse of power, here is another perspective, governance. Dr. Greenspan raises a hypothetical situation, where China, the second largest economy of the world, decide to intervene the Bitcoin operation as a state: to intervene the capital outflow through Bitcoin transaction. He illustrated that this hypothetical situation is economically feasible for the economic size of Chinese government, by providing an estimate of the economic cost of an intervention with some assumptions. In conducting state governance, Chinese government can afford waging the 51% attack to annihilate the Bitcoin blockchain system. (Greenspan, 2017)

Conditional Security 2 (Trustable Majority CPU-power Condition):

Recalling the abstract of Bitcoin white paper, Satoshi Nakamoto contemplated a guarantee of the security of a peer-to-peer paradigm CONDITIONAL on that the majority of CPU-power has no will to cooperate with a malicious party to attack the system:

“As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers.” 　(Nakamoto, N.D., p. 1)

Satoshi Nakamoto imposed the trustable majority as a necessary condition. But, the question is that this necessary condition might not be a practical one sometimes. Overall, it is a conditional integrity of the system’s security, but not an absolute one.

Implication

In a way, Proof of Work, a Byzantine Fault Tolerant protocol, is vulnerable to an abuse of power by an overwhelming power such as a dictatorship.

Overall, the notion that Byzantine fault tolerance framework is a secure system is a myth. The premise of the Byzantine fault tolerance framework did not contemplate a risk that the chief general, together with the majority of his subordinate generals, has a desire to impair the integrity of the system in the pursuit of their interest outside of the system.

Tentative Perspective of the Series:

This series covered three categories of the source of confusion regarding blockchains:
·       Linguistic ambiguity;
·       Tri-lemma (current technical barriers);
·       Myth-conceptions.

Satoshi Nakamoto imposed a certain set of realistic conditions on his peer-to-peer system. Basically, he promised a conditional, not an absolute, integrity of his P2P system. And the type of blockchain that can theoretically operate Nakamoto’s P2P system is “permission-less, public blockchain.”

That said, in his plan he seems to have failed to capture economic and technical asymmetries inherent in the eco-system. The asymmetries, together with the trilemma, give rise to concentrations of intermediaries. As a result, “permission-less, public blockchains” today are in the hands of intermediaries and reinforce their power of control. Disintermediation, one of Nakamoto’s assumption, is far from reality. In the presence of these asymmetries, distributed intermediation is the reality as of today and his plan is an unattainable dream for now.

This paradoxical situation reduces his P2P framework to be a prisoner of its self-contradiction on one hand. On the other, the beautiful fundamentalistic notions about blockchain still shape myth-conceptions about blockchains among our collective perception and influence our collective behaviour toward blockchain.

In this setting, if we want to shape a realistic approach to blockchain uses, we need to narrow down our target within a feasible territory.

While Nakamoto’s P2P paradigm contemplated cryptographic proof-based algorithmic governance, therefore, “permission-less, public blockchain.” Nevertheless, due to all these constraints we covered in the series so far, cryptographic proof-based algorithmic governance, on a stand-alone basis, does not seem to yield a viable solution to enable a scalable, secure P2P application yet as of today.

Furthermore, the viability of Byzantine Fault Tolerance, a common foundation of consensus protocols, is also CONDITIONAL. It by itself, or unconditionally, does not really guarantee the integrity of the system’s security. The premise of the Byzantine fault tolerance framework excludes the risk of 51% attack: a risk that the chief general, together with the majority of his subordinate generals, has a desire to impair the integrity of the system in the pursuit of their interest outside of the system.

After all those efforts, are we creating a convenient tool for dictators? Despite all the effort to design, execute, and secure the system, it ends up involving intermediaries that are conducted by human governance, which it intended to eliminate in the first place. The P2P reality today is trapped in a “full-circle loop” chain of human control. (Esposito, 2017)

We might need to reframe the design of consensus protocols at the fundamental level. The notion about “autonomous self-regulating governance” is a misleading one at least as of today.
Given these limitations, what’s the point of choosing a “permission-less, public blockchain,” while paying so much economic and technical cost? Ultimately, after all the attempts to build up a pure P2P system, it ends up depending on trust-base human governance and compromises the goal. Then, why not choose a trust-base human governance from the beginning: “permissioned, private blockchain” or “permissioned, federated/consortium blockchain”? Would that be more cost effective? This is a legitimate question.

We might be able to see a realistic approach in the middle. Something like this, editing a Dr. Greenspan’s statement:

“the real question is: What are conditions under which a particular blockchain can and cannot” enable a viable (secure and scalable) P2P paradigm, if not a pure one. “And do those conditions match the problem we’re trying to solve?” (Greenspan, 2017)[i]

Nevertheless, suspicions about human trust might prevail. The urge for a P2P paradigm rests on our distrust within ourselves. If we can trust one another, we would not need a P2P paradigm.

For now, let’s maintain our hope in the future evolution of blockchain. Who knows!

Indefinite Pause:

This series shares a part of my journey in understanding confusing aspects of blockchain— the gap between practices and fundamentalistic ideals of blockchains. Although it does not aim to cover a comprehensive list of issues, it intends to promote a better understanding about confusion.

On a piecemeal basis, I might extend this series in the future to cover a wider range of relevant issues. For now, this series has come to an open, indefinite pause.

Michio Suginoo

Note

[i] His original statement refers to blockchain’s immutability.
“In blockchains, there is no such thing as perfect immutability. The real question is: What are the conditions under which a particular blockchain can and cannot be changed? And do those conditions match the problem we’re trying to solve?” (Greenspan, 2017)

Reference

·       Berg, C., Davidson, S., & Potts, J. (2017, 10 25). Byzantine political economy. Retrieved from Cryptoeconomics: http://cryptoeconomics.com.au/2017/10/byzantine-political-economy/
·       BTC.com. (ND). Pool Distribution. Retrieved from BTC.com: https://btc.com/stats/pool
·       Digiconomist. (2014, 7 7). Understanding Economies of Scale. Retrieved from Digiconomist: https://digiconomist.net/understanding_economies_of_scale/
·       Digiconomist. (2016, 2 26). How Limited Block Size May Centralize The Use Of Bitcoin. Retrieved from Digiconomist: https://digiconomist.net/how-limited-block-size-may-centralize-the-use-of-bitcoin
·       Digiconomist. (2017, 4 17). Bitcoin Electricity Consumption: An Economic Approach. Retrieved from Digiconomist.net: https://digiconomist.net/bitcoin-electricity-consumption
·       Esposito, O. (2017, 5 24). The new intermediaries at work behind the blockchain. Retrieved 1 18, 2018, from L'Atelier BNP Paribas: https://atelier.bnpparibas/en/fintech/article/intermediaries-work-blockchain
·       Greenspan, G. (2015, 11 2). Smart contracts: The good, the bad and the lazy. Retrieved from Multichain.com: https://www.multichain.com/blog/2015/11/smart-contracts-good-bad-lazy/
·       Greenspan, G. (2016, 4 12). Beware impossible smart contract. Retrieved from multichain.com: https://www.multichain.com/blog/2016/04/beware-impossible-smart-contract/
·       Greenspan, G. (2017, 5 4). The Blockchain Immutability Myth. Retrieved from www.multichain.com: https://www.multichain.com/blog/2017/05/blockchain-immutability-myth/
·       Kasireddy, P. (2017, 12 11). Fundamental challenges with public blockchains. Retrieved from Medium: https://medium.com/@preethikasireddy/fundamental-challenges-with-public-blockchains-253c800e9428
·       MaasTijs. (2017, 11 9). Yes, this kid really just deleted $300 MILLION by messing around with Ethereum’s smart contracts. Retrieved from: Hackernoon: https://hackernoon.com/yes-this-kid-really-just-deleted-150-million-dollar-by-messing-around-with-ethereums-smart-2d6bb6750bb9
·       Nakamoto, S. (N.D.). Bitcoin: A Peer-to-Peer Electronic Cash System. NA: www.bitcom.org. Retrieved 1 31, 2018, from http://www.bitcoingroup.com.au/satoshi-whitepaper/
·       Stark, J. (2016, 6 4). Making Sense of Blockchain Smart Contracts. Retrieved from Coindesk.com: https://www.coindesk.com/making-sense-smart-contracts/

1 Comment