Tuesday, May 29, 2018

Hard-forks and governance on the Bitcoin blockchain

By Jeffery Atik
The recent experience of forks and potential forks in response to the various Segregated Witness and blocksize increase proposals highlights the nature of governance on the Bitcoin blockchain. The result of the SegWit / blocksize controversies has been a so-called hard fork on the Bitcoin blockchain, producing two varieties of Bitcoin with a common history but now distinct technical characteristics: Bitcoin and Bitcoin Cash.

The Bitcoin blockchain marks a novel form of social organization. There is no central node in the network, no center of authority directing or coordinating internal or external action. Rather, the constituent autonomous nodes operate the Bitcoin blockchain following a downloaded open-source protocol that Bitcoin’s mysterious founders initially developed and which is quite resistant to change. When change does come to the Bitcoin blockchain, it emerges from loose and informal constellations of various stakeholders. Bitcoin users and the sponsors of the Bitcoin network nodes (known as ‘miners’) are formal stakeholders. Indirect stakeholders include Bitcoin developers and businesses that service the Bitcoin ecosystem (systems operators and equipment manufacturers, as well as Bitcoin exchanges). Still we can draw a black box around the Bitcoin blockchain and examine it as a finite social space, an organization set apart from surrounding players and institutions.

The Bitcoin blockchain resorts to “Nakamoto consensus” as its ultimate form of governance. Nakamoto consensus is an emergent and diffuse consensus arising among the active Bitcoin miners, each pursuing its own advantage while collectively engaged in maintaining, verifying and expanding the blockchain. Nakamoto consensus is the ultimate source, and hence authority, as to the canonical state of the Bitcoin blockchain; this consensus is the Truth as far as the Bitcoin blockchain is concerned, and once reached, it cannot readily be disturbed. More considered consensus engages on those occasions when the Bitcoin blockchain community makes a constitutional decision as to changes to its basic rules.
Miners are essential stakeholders in the Bitcoin blockchain; without them, the system would freeze or collapse. The miners toil, with their racks of specialized computers, and earn Bitcoin in return. The effective compensation for their efforts, which yield Bitcoin over time, depends on Bitcoin retaining or increasing its external value. Only if Bitcoin is valued will the work of the miner pencil out.

Users - the holders of Bitcoin who transact on the blockchain - are another essential constituency. Users do not 'vote' or otherwise engage in the formation of Nakamoto consensus, yet their aggregate demand for Bitcoin drive its market price. A Bitcoin has no intrinsic value - but it does have attributes (scarcity and transferability) that attract users. Bitcoin and the Bitcoin blockchain are one seamless invention: one does not exist without the other, and from a functional perspective, it is not meaningful to speak of a point where one stops and the other starts. Without an adequately inviting price for Bitcoin, the miners in turn would lose interest and depart the Bitcoin blockchain.

Thus, two groups of stakeholders, miners and users, are essential to the health of the Bitcoin blockchain ecosystem. There are in fact two forms of consensus maintained: one formed by the miners about the 'state’ and ‘rules' of the blockchain, and one formed by the market of users about the external value of Bitcoin. A feedback loop links these two forms of consensus: the market value of Bitcoin, established by users, and the state of the blockchain (including its rules) implemented by the miners. Users derive utility from – and support the value of – Bitcoin, which in turn incentivizes the miners. The miners construct the secure, decentralized and tamper-proof blockchain (through the exercise of Nakamoto consensus), earning the users esteem.

A third set of stakeholders design and improve the functioning of the Bitcoin ecosystem. The blockchain developers by prestige and persuasion guide the evolution of Bitcoin infrastructure – and contribute the hard work of developing implementable solutions. Only developers actively code. Developers do not formally touch the blockchain, but their influence is profound. Despite the open-source, decentralized ethos that surrounds Bitcoin, developers (some more than others) wield impressive power in implementing their ideas. These constitutional amendments are called Bitcoin Improvement Proposals (“BIPs”) and are intensely studied, tested and debated.

Yet the developer community can only propose. Implementation of BIPs requires consensus of the other players. Formally, miners implement Bitcoin Improvement Proposals by Nakamoto consensus. Each miner weighs the consequences of the decision to adopt a change, with an eye on divining what the broader community is thinking. It is generally in a miner’s best interest to join the camp it projects will command an enduring consensus, even when the miner does not share the belief that the consensus determination – to implement a BIP or not – is either best for the miner or best for the overall blockchain. We can better understand a miner’s ‘vote’ as a prediction of the behavior of others rather than an expression of the miner’s individualized preferences. Whether a particular change sticks or not depends, in the end, on its effect on the price of Bitcoin, a price that is determined by the aggregate of Bitcoin users, present and prospective.

Changes to the Bitcoin blockchain protocol often proceed smoothly. Developers present Bitcoin Improvement Proposals, which are then debated and refined. Once a BIP commands the support of the technocracy, it is put before the miners. Miners signal their support for proposals by raising ‘flags,’ that is, by including expressions of support in an available field found in header of every block. These flags can be seen and registered upon the revelation of each new block; as individual miners sporadically succeed in sponsoring a new block, they use these opportunities to raise their own ‘flag’ on a particular proposal. Over a period of time, as more and more miners raise flags of support (or fail to do so), a group position emerges. The process is a form of rolling election, although no miner raising a flag is bound to follow through with its declared intention when time comes to give effect to the decision.

Miners truly ‘vote’ by choosing where to build new blocks onto the blockchain. They can build on either an implementing or non-implementing block (this is how forks come about at decision points in blockchain history). Until consensus forms (through the building out of new chain growth, indicating the relative command of hashing power applied to each alternative), flagging is simply predictive - like a voter’s response to a pre-election poll. Further, the observation of a flagging by a broad (or at least representative) sample of miners has no binding effect. Still, strong signals of support for a particular reform permits spontaneous coordination among the otherwise independent miners.

The press and others tally these flags to measure the prospects for a consensus. At a certain point - predestined informally - enough signals have been registered to enable the otherwise uncoordinated system to shift smoothly to the new rule. The raising of flags over a period of time as various miners promote new blocks unto the blockchain functions as a kind of pre-election polling, gauging sentiment and promoting the formation of a common understanding of what will come to pass.

Things do not always work out so smoothly. Some proposals generate division within the community. When the community divides, either temporarily or persistently, we describe the event as a ‘fork.’ A fork results in two blockchains, each branch commanding the efforts of a sufficient amount of hashing power (provided by adhering miners) to be viable. Forks come in various flavors (depending in large part on their technological backward compatibility), but they give rise of the cleavage of what had been one blockchain into two. Each forks shares the same pre-fork history, but each progresses on its own way with no regard to the distinctive unfolding history of the other. The vast majority of forks are transitory – one breach is abandoned and the entire community re-aligns around the surviving branch when then forms the canonical blockchain.

George Gerro and I recently posted an account of the SegWit hard fork saga on MEDIUM at:


No comments:

Post a Comment