Mobility Needs More Than Blockchain. Here’s Why. Part 2 of 3
Why Trust Took So Much Time to Scale
A recent development in this area of computer science is the invention of a data structure called a blockchain. It was the first example of a class of solutions loosely categorized as distributed ledger technologies–or DLTs–that provided some very strong guarantees around dealing with the time synchronization and the authoritative truth of the state of the system. However, it did not address the scalability needs of large complex systems, nor dealing with the creation of fake participants–known as the Sybil attack/problem. And, the first blockchain implementation as described in the Bitcoin whitepaper actually posed new challenges–specifically with the method through which authoritative trust was established–through this concept of “mining”–otherwise known as proof-of-work.
Since the first implementation of a blockchain dealt specifically with creating a digital–“crypto”–currency, the establishment of historical ledger entries as “transactions” has emerged as the common descriptor. It’s important to note that though these first-generation DLTs were very cryptocurrency focused, there is no reason that a DLT cannot be used for establishing an authoritative state of any data–not just financial obligations and rights as would be seen in the development of a currency like Bitcoin.
We’ll call this the first-generation DLT–the Bitcoin blockchain and its derivatives, like Litecoin. It was designed to be run by anyone, with very rudimentary rules around validation of state of the system. Another byproduct of this implementation was that the privacy of transactions was nonexistent, due to the requirement that all transactions were visible so that all transactions could be verified, and the authoritative state of the system could be established. There was no attempt to address privacy at all in this first generation, other than using unique addresses for each transaction.
A Second Look at Scalability
Then the next generation of DLTs emerged–with platforms like Ethereum, Fabric, Sawtooth, Quorum, and Corda. Many of these projects attempted to address some of the more glaring limitations inherent in the first generation DLTs. One area of research within the DLT space was to address the scalability issue through exploring a field of study called consensus algorithms. Consensus algorithms are the means by which DLTs establish agreement upon the authoritative state of the system. There are many clever attempts that trade off scalability for centralization, and several have emerged as good next-generation candidates.
Another area of research in the second-generation DLT space is to establish additional privacy guarantees for participants working within the state of the system. Specific attempts have been made to use novel cryptographic approaches to creating privacy, while still providing verifiability, with concepts like zero-knowledge proofs and bullet-proofs. While these do address the privacy issues to some degree, they introduce additional complexities such as requiring significant computing resources, or further reducing the ability to scale to millions of participants.
More work being done in the second-generation DLT space was to trade off a bit of true decentralization for approving a predetermined set of participants to join the network, and in return see significant gains on the scalability of the system. This is considered a “permissioned” network, rather than a “public” network. Some decentralized purists have criticized this effort as not actually being decentralized. However, distributed systems theory makes no claim or requirement that any participant may join as a first-class party without permission, only that those participants who are participating may do so without coercion, and with the minimization of limitations as to what each participant may do within the system, and have the ability to leave and join alternative networks freely as they so choose.
Yet another area of work that has been done in second-generation DLTs is the area of executable code, called “smart contracts”. This evolved from the availability of an extremely simplistic scripting language included in the original Bitcoin implementation, that allowed for rudimentary logic to be applied to transactions. Through a financial lens, these simple code snippets could be considered as contracts. Just like paper contracts, except they were self-enforcing and self-executing based on the authoritative state of the system. This self-enforcing, self-executing contract is what makes it “smart”. Ethereum is an example of taking the opportunity of having access to a global state of a system, and adding a more robust programming language to implement smart contracts, and a virtual machine to execute these contracts.
Click here to read Part 3: Today. Pragmatic Protections in a Production Environment.
Click here to learn how Blocklet Mobility Platform scales.