Recently a post from Manuel Oretga in the blog Las Indias in English titled “The
blockchain is a threat to the distributed future of the Internet” attacked what he sees as thinly veiled corporate centralization of the internet through it’s current darling the blockchain . Bitcoin, the initial target, is a mechanism by which those interested in centralizing power, control, access & wealth wield economic might. Big banks and those aligned with them, entities he refers to as “centralizers” (with a link to IBM’s blockchain finance work as an illustration of the definition) are building dependence on heavy weight infrastructure, a synonym for centralized industrial/corporate activity. Dependence on industrial infrastructure thwarts those seeking in the internet independence and autonomy.
The initial evidence of a centralizing control property of blockchains is the Bitcoin reliance on mining functions, primarily taking place in China, that create the coins that are the currency of Bitcoin exchange.
This is easy to verify when you look at the way that two Chinese “mines,” Antpool and DiscusFish/F2Pool, hoard more than half of the blocks created by the bitcoin blockchain
That this has emerged in the Bitcoin environment means that this method of financial exchange is controlled by those who have large amounts of capital and can invest in the infrastructure required by Bitcoin transactions. The permissionless distribution of blockchain transaction records to all participants masks the reality that it is just another centrally controlled system directed by those with the capital to create the currency.
The use case that is explored to validate these assertions is an application called Twister, a P2P microblogging platform that uses Bitcoin’s blockchain infrastructure. There is a odd lead paragraph that introduced Ethereum and with it the notion of ‘smart contracts‘, but it’s only tangentially related to the arguments that follow which instead focus on Twister which is using native Bitcoin software. Apparently because they both use some form of blockchain that’s enough to tie them together and impugn Ethereum based on the Twister critique. That’s like criticizing Oracle based on critical analysis of MySQL because they are both using some variant of relational databases. It’s obfuscation that isn’t germane to the argument. That happens quite a bit in looking at the citations offered (e.g., the aside below).
ASIDE – A quirky reference to ‘corporate developments’ leads the paragraph introducing Twister. The aside looks at that but it’s tangential to Ortega’s primary argument so you can skip it if you wish by not clicking on the link.
It’s important to recognize how Twister is using the blockchain. It’s not what you might initially think. Twister is an alternative to Twitter. The blockchain is focused on establishing an immutable user name. Why? Because of a concern that people can masquerade as someone. The developer of Twister writes in an FAQ entry
“Therefore this other peer may try to deceive you by providing forged posts from other genuine users or to refuse to store or forward your own posts.”
The mechanism it prevent the forged posts concern is making the twister client check if each post is properly signed by the sender. And that is role cryptographic feature of the block he’s leveraging.
Ortega’s main concern, however, is that Twister’s use of this method requires that the blockchain ledger be transferred to your machine, since Bitcoin’s blockchain is permissionless, and every users gets the full history of transactions – in this case the full list of Twister users, encrypted of course. Ortega’s concern is that his requires a lot of bandwidth (well, not now as the service is small, but if it took off it could). The assumption is that having both the storage required to support this as well as the bandwidth to engage are both requirements that are “insurmoutable barriers”, barriers high enough to disenfranchise the average punter but trivial for the corporate giants of the likes of Google, Amazon and IBM.
Ortega’s concerns boil down to three points:
- Using blockchains requires bandwidth that is only easily accessible by big corporations, in terms of affordability and physical accessibility to the bandwidth.
- The size of the blockchain places too high a storage burden on the user, whilst being trivial to the corporation players.
- The distributed consensus algorithm of the Bitcoin blockchain is still subject to the 51% attack problem, if not directly in controlling commits then in harboring Bitcoins themselves and thus controlling the function of the transaction environment. It’s also energetically & computationally expensive
I’m less concerned about bandwidth in this instance as this is not specifically a blockchain problem. It’s an overall internet access problem. Of course that doesn’t mean people using the internet and needing bandwidth for whatever they’re doing aren’t affected. It’s also true that bandwidth follows development so poorer areas by and large have less bandwidth.
What it does mean is that one particular usage of bandwidth is not to me the entry point for solving a much larger internet access network issue. There are other directions more likely to motivate changes there – like healthcare. This is an issue in the same area as most inequitable wealth distribution problems. It’s important but requires multi-faceted strategies to address.
Local storage capacity is a major concern for the millions of users and potential users around the world who don’t have inexpensive access to storage at a price that’s affordable.. But like Bandwidth, Blockchains are just on of many hundreds of applications that demand more storage capacity.
The Twister example that Oretga focuses on is a peculiar choice as a use case. The use of the blockchain there is for the purpose of establishing immutable user IDs so that no one can masquerade sending microblogging messages as someone else. The size of the blockchain in this instance is by design small. It’s hard to see this imposing an burden on the users of this P2P microblogging platform.
Ultimately I don’t think you build toward the future by constraining your creative solution space to what are current limitations. Don’t get me wrong. We have to address the forces that are retarding or unwilling to address access, bandwidth, and affordable storage systemically. But leading the charge for that with blockchain storage requirements rather than the hundreds of other storage demands seems like an ill conceived strategy.
What it does question is exactly what we deem as essential to encrypt in the block itself. That’s an important question. I see future blockchain environments as hybrid solutions with the information written into a block guided by a minimalist design guideline, using URIs written into the block to point to secondary locations where information dense artifacts related to the block are stored. That certainly opens up other places where attacks on the integrity of the system might be targeted, but that’s not a new problem.
There are examples from Monegraph & Everledger where data relevant to a block record is stored in places other than the blockchain itself. This is likely to be a smart implementation move even though it does add complexity and opportunities for new points of attack. The goal should be to put in the immutable block only that information sufficient to make a unique record that permanently records the event you’re trying to recognize. Blockchains are not simply a new form of database intending to replace the RDMBS.
3. Distributed Consensus
This is perhaps the most serious criticism of the use of the blockchain in the context of credentialing or recognition of competencies. There is no need for the kind of Proof of Work (PoW) that is an integral part of the bitcoin cryptocurrency environment. Nor is it acceptable to predicate consensus in committing a record to the ledger on enormous expenditures of energy and raw computational power. Whether we limit the number of blockchains and devalue the ‘currency’ in an agreed fashion to bound the range of the investment required to achieve the right to create a block, or more likely we look at some of the emerging algorithms that are based on Proof of Stake (PoS), the current bitcoin PoW is consensus algorithm needs a suitable replacement.
In the UT Austin pilot, development starting this summer, we’re beginning our explorations using the Ethereum environment, but looking at altering the block creation process to limit a block to a ledger record. There is more to our pilot as it involves badges and writing badge metadata into the block ledger, a databases for structured rubrics and a database for rich media (effectively a bag of bits S3 store) to capture different artifacts related to evidence of learning. More on that in another post.