A Philosophy of Blockchain: Do You Have Hidden Centralizations?
It’s hard to avoid hidden centralizations, particularly when you’re creating code that’s being used by a network…
written by Shannon Appelcline
There is no doubt that decentralization was one of the core philosophies of Bitcoin (and thus the blockchain). In his original white paper, Satoshi Nakamoto wrote that Bitcoin could enable “any two willing parties to transact directly with each other without the need for a trusted third party”. Over time, this idea has become a touchstone for the blockchain technology: the Nakamoto Consensus protocol ensures that a blockchain is created in a decentralized way, then anyone can validate transactions to ensure that a blockchain remains trusted.
Why is decentralization important to blockchains? Satoshi Nakamoto alludes to the intent in the original Bitcoin white paper, saying that it would be problematic if “the fate of the entire money system depend[ed] on” a centralized authority. This is certainly a crucial, if pragmatic, reason to avoid centralization: if the health and viability of that authority fails, then so does the entire system.
However, the Cypherpunks, who prefigured the creation of Bitcoin, offered more philosophical reasons behind the logic of decentralization. In “A Cypherpunk’s Manifesto”, Eric Hughes discussed how the traditional right of privacy was being eroded as commerce moved into electronic realms, saying: “We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence.” Perhaps more importantly: we can’t depend on the people who run those organizations and corporations to protect our privacy. Even if we trust a centralized authority when we give them our data, we can’t guarantee that we will trust them in five, ten, or fifty years when new executives take over. The cypherpunks saw the need to sidestep those centralizations to ensure that the privacy of the physical world was replicated on the internet, but the mere desire for decentralization doesn’t ensure it.
Despite our best intentions, hidden centralization have crept into blockchains. They take power from the people, which was core to the conception of the blockchain, and instead give it to small and powerful groups of elites. Many people fear the 51% attack, where a majority of miners could take over a blockchain, because any proof-of-work blockchain has a hidden centralization in just 51% of its full mining nodes. However, there are even more insidious possibilities. Protocol designers, code programmers, and even blockchain voters can all be part of small, hidden centralizations, where a small subset of blockchain users suddenly become an authority.
Different blockchains have approached this problem in different ways, either fighting the hidden centralizations of miners, coders, or voters or embracing them.
But even for those of us who believe that these hidden centralizations violates the core philosophies of the blockchain, it’s a difficult battle.
Programmers & Bitcoin
Bitcoin offers the best example of the battle over hidden centralization, both because it’s the largest blockchain and because it’s worked the most with the issue — largely focused on the hidden centralization of Bitcoin protocols and code.
Theoretically, any code that aligns with the Bitcoin consensus protocols can be used to interact with the Bitcoin blockchain, but its technological future is primarily directly by Bitcoin Core — the codebase ultimately derived from the original code of Satoshi Nakamoto, and now used by approximately three-quarters of Bitcoin nodes. This code thus represents Bitcoin’s first hidden centralization.
Though Bitcoin Core has a small number of “core” team members, led by Wladimir van der Laan, the code is maintained on Github to maximize community involvement. This has allowed for hundreds of contributors: theoretically any Bitcoin aficionado can join in. However, even for the most popular and most successful blockchain, reality doesn’t always line up with desire. Just 67 contributors have made more than a dozen commits, just 45 have made more than twenty, just 23 more than a hundred. Only a dozen or so people have full commit permissions on the Bitcoin Github repository.
Fortunately, Bitcoin’s centralization begins to recede when you move away from the Bitcoin Core code to the underlying consensus protocols. Changes are initiated in Bitcoin Improvement Protocols, which support widespread community involvement. They then continue through a process of “rough consensus”, where major objections are heard and resolved. Only afterward are BIPs introduced as actual code.
If this rough consensus was the final word in which BIPs were eventually introduced into code, then the hidden centralizations within Bitcoin’s consensus protocols would be greatly minimized. However, there’s another step: Bitcoin nodes must indicate that they’ve adopted a new protocol element through signaling, as detailed in BIP9. It was never intended to be anything but a marker to show which nodes had adopted the newest protocols … until the great Bitcoin block-size debate. Different interest groups fought over how large blocks on the Bitcoin blockchain should be, and during this conflict, BIP9’s signalling methodology became a de facto voting process for how the debate should be resolved. Essentially, it was “vote-by-work”, since the votes were determined based on the power of miners creating blocks.
In other words: there are hidden centralizations all the way down. Even if “core” coders don’t have ultimate power on the Bitcoin blockchain (and there’s certainly disagreement here), then miners might, because they can limit what consensus protocols go into actual use. They’re both centralizations, and like Eric Hughes said, you can’t expect such authorities to respect the best interests of the rest of a network.
As the block-size debate continued, a User Activated Soft Fork, or UASF, attempted to shift the decision-making power all the way down to the end-user, but was superseded by the adoption of BIP91 before the UASF could come to fruition. Nonetheless, it was an important statement of the power of the people at the foundation of the blockchain (and an important step away from centralization).
The long and bloody debates over block size resulted in the creation of Bitcoin Cash, a variant of the Bitcoin currency. This fundamental and irrevocable disagreement demonstrated that even Bitcoin doesn’t deal perfectly with the problems that can be introduced by centralized code and protocols. But it’s certainly the blockchain that’s done the most to battle its hidden centralizations.
Others of us have further to go.
Programmers & Ethereum
Ethereum is the second most popular blockchain after Bitcoin, focused on distributed computing rather than just cryptocurrency transfer. Like Bitcoin, Ethereum has its own Github, its own BIPs (called ERCs), and a relatively small team of developers — though Ethereum has twice as many regular developers as Bitcoin, according to a Cointelegraph report. So, there’s certainly been care and effort in managing Ethereum’s hidden centralizations of code and protocol. However, unlike Bitcoin, Ethereum has its own non-profit: the Ethereum Foundation. This non-profit is a different sort of hidden centralization that could exert a lot of control over the future of the network — a problematic possibility that blossomed in the 2016 DAO incident.
The DAO, a “decentralized autonomous organization” was a new business model controlled by smart contracts. It allowed investors to place their money into an organization that could then make investments of its own all run from an open and borderless blockchain. It could have been the future of business on the internet.
Unfortunately, the Turing-complete nature of Ethereum’s expansive programming language ultimately spelled the DAO’s doom. Turing-complete languages are either difficult or impossible to logically prove, which means there’s no way to formally say that they will do what they’re supposed to. Or, if you prefer: they can have hidden bugs. And that was the case with The DAO. Participants invested $150 million into the decentralized autonomous organization, and then a hacker used an exploit to transfer out $50 million of that money. The bug, it should be clear, was in the DAO software, not in Ethereum itself.
Blockchains are merciless. There are no take-backs. If you send money to the wrong place, don’t recover your change, mess up a hash … or write a program wrong, that’s on you. The autonomy of decentralization becomes a harsh reality if you make a mistake. So, under the core philosophy of the blockchain, that $50 million should have been gone. As some people said in the wake of the DAO incident: “code is law”.
That’s not what happened. Instead, the Ethereum Foundation proposed a hard fork to wind back time and get the lost money back to the DAO’s contributors. The whole community voted using a brand-new “Carbonvote” system, which was essentially vote-with-stake: yes and no votes were counted based on the amount of cryptocurrency held by the voting address. 89% of voters agreed to roll back the DAO losses, but it still raised the spectre of hidden centralization. How much authority did the Ethereum Foundation exert by making and pushing the proposal? And, would they do it again? In the worst case, Ethereum had revealed a hidden centralization in the small group of people controlling the Foundation, while in the best case they’d merely shown that 51% of voters could make unprecedented changes to the blockchain.
Either way, the centralization was real. The Ethereum Classic blockchain was the result: a new cryptocurrency spun off of Ethereum for people who felt that the DAO rollback had violated the philosophies of the blockchain. (Like the somewhat similar Bitcoin Cash fork, the new cryptocurrency has proven considerably less valuable than its parent.)
Programmers & Bitmark
At Bitmark, we’ve developed our own blockchain for the specific purpose of building a digital property system: the Bitmark blockchain, focused on the registration and management of digital property and assets. It allows users to transfer and license these various properties, controlling and monetizing their digital assets. Much as with the cryptocurrencies of Bitcoin and Ethereum, it’s crucially important that this network be truly decentralized, so that its users can trust the neutrality and openness of the blockchain.
And here we’ve discovered what the creators of Bitcoin and Ethereum already know: it’s hard to avoid hidden centralizations, particularly when you’re creating code that’s being used by a network. As with the other blockchain communities, our code is available on Github. We also have a brand-new Bitmark Upgrade Proposal (BUP) system, where community members can suggest upgrades to the Bitmark Algorithms. But that’s not enough on its own: several external developers have forked our core code, but to date all of the commits are from our own engineering team, while the BUP system is too new to have generated proposals.
Though Bitmark has had strong success with partners like KKBOX (who uses the Bitmark Property System to record rights to digitally streaming music) and Chibitronics (who registers Bitmark certificates to verify the authenticity of their hardware), making additions to a blockchain’s core code (or its algorithms) requires a totally different sort of community. We’ve thus experimented with other methodologies, such as seeding our coding community via a bug bounty program. A few community members have already been paid out for reporting small bugs in our web app. These bug reports aren’t Github commits or BUPs, but they’re a first step toward decentralizing our coding work.
After we’ve welcomed more external coders into our community, we’ll eventually need mechanisms to decide what actually gets added to our code and our protocols. Bitcoin and Ethereum both developed somewhat ad hoc systems to allow voting on contentious protocols: Bitcoin used a signalling system that wasn’t intended for voting, while Ethereum’s Carbonvote was created to resolve an immediate crisis. A more thoughtful system, not created due to immediate exigencies, could more carefully consider the best way to manage collective choice, whether it be rough consensus, work voting, stake voting, or something else.
Unlike the philosophy discussed in our last article, on proof of work vs proof of stake, the blockchain community is much more settled on the advantages of decentralization.
In spite of that, blockchains have big problems with centralized authorities; they’re just somewhat hidden.
The central power of the Ethereum Foundation to pursue a radical reversion of the Ethereum blockchain was an eye opener for many in the blockchain community, but it’s just a singular example of a more endemic problem, one that generates serious questions that we all need to consider.
How can we reduce the centralizations inherent in miners, protocol developers, coders, and blockchain VIPs?
How can we develop protocols of collective choice that maintain the power of the people without subjecting it to the tyranny of the majority?
In other words, how can we truly meet the blockchain’s original goals of decentralization in reality?
Bitcoin. Retrieved June 2019. “Bitcoin Improvement Protocols”. Github. https://github.com/bitcoin/bips.
Bitmark. Retrieved June 2019. “Bitmark Inc. Repos”. Github. https://github.com/bitmark-inc.
Bitmark. Retrieved June 2019. “Bug Bounty Program”. Bitmark. https://docs.bitmark.com/learning-bitmark/contributing-to-bitmark/bug-bounty-program.
Caffyn, Grace. August 2015. “What is the Bitcoin Block Size Debate and Why Does It Matter?” Coindesk. https://www.coindesk.com/what-is-the-bitcoin-block-size-debate-and-why-does-it-matter.
Electric Capital. March 2019. “Dev Report”. Medium. https://medium.com/@ElectricCapital/dev-report-476df4ff1fd2.
Hughes, Eric. March 1993. “A Cypherpunk’s Manifesto”. Cypherpunk Mailing List. Archived on https://github.com/NakamotoInstitute/nakamotoinstitute.org/blob/master/sni/static/docs/cypherpunk-manifesto.txt.
Falkon, Samuel. December 2017. “The Story of the DAO — Its History and Consequences.” Medium. https://medium.com/swlh/the-story-of-the-dao-its-history-and-consequences-71e6a8a551ee.
Hall, Christopher. April 2019. “BUP 001: BUP Process”. Github. https://github.com/bitmark-property-system/bups/blob/master/bup-0001-draft.markdown.
Lapowsky, Issie. September 2017. “The Feds Promised to Protect Dreamer Data. Now What?” Wired. https://www.wired.com/story/daca-trump-dreamer-data/.
Lombrozo, Eric. June 2017. “Forking, Signaling, and Activation”. Medium. https://medium.com/@elombrozo/forks-signaling-and-activation-d60b6abda49a.
Nakamoto, Satoshi. October 2008. “Bitcoin: A Peer-to-Peer Electronic Cash System”. https://bitcoin.org/bitcoin.pdf.
SFOX. April 2019. “Bitcoin Governance: What Are BIPS and How Do They Work?” Medium. https://blog.sfox.com/bitcoin-governance-what-are-bips-and-how-do-they-work-276cbaebb068.
Wilcke, Jeffrey. July 2016. “To Fork or Not to Fork”. Ethereum Blog. https://blog.ethereum.org/2016/07/15/to-fork-or-not-to-fork/.
Zmudzinski, Adrian. March 2019. “Ethereum Has More than Twice as Many Core Devs Per Month as Bitcoin, Report Says”. Cointelegraph. https://cointelegraph.com/news/ethereum-has-more-than-twice-as-many-core-devs-per-month-as-bitcoin-report.