Bitcoin -> Ethereum -> HyperLedger

Post navigation

Bitcoin was the first large-scale application of blockchain. It’s a system for payment — the vast majority of its transactions are payments between two parties concluded at a single moment in time.

As Bitcoin started to take off, people dusted off the idea of “smart contracts” from the ’70s — blockchain seemed to be the missing ingredient. Smart contracts are not simple payments: they take place over time, they have conditions, and they often have more than 2 parties. Bitcoin supports limited forms of smart contracts through a mechanism called “scripts,” but it’s intentionally constrained.

In 2014, Ethereum took up the smart contract banner: they included critical support for smart contracts, and even developed a language called “Solidity” designed especially for writing smart contracts. Solidity is far more powerful than Bitcoin scripts. It was still developed within the conceptual framework of contracts–parties engaging in some kind of transaction–but a big step forward.

Ethereum advanced one of the key challenges: how to run the contracts. Any software program–including a Solidity contract–needs a computer to run it. That computer has to have an interpreter for the programming language used: Javascript, Python, GoLang, or in this case, Solidity.

How many computers had an interpreter to run Solidity when Ethereum launched in 2015? Zero. To address this, Ethereum constructed a “virtual machine.” That’s a bundle of software that pretends to be a fully functional computer, only it runs “on top of” one or more actual computers. The actual machine may be running the Windows, Mac, Linux, or other operating systems. The virtual machine runs as a program within that framework, harnessing the underlying operating system to actually move the bits.

This virtual machine–called the Ethereum Virtual Machine–is how Ethereum could make it possible for their smart contracts written in Solidity to be read and executed. A blockchain like Ethereum runs on multiple host computers, called “peers.” Each peer carries a complete copy of the blockchain transaction log — that’s the “ledger” recording every transaction. Whenever a new transaction comes in, a quorum of the peers have to agree on the transaction and every peer gets a copy, so all copies of the ledger are identical — that’s one of the central features of any blockchain.

So whenever the Ethereum adds a new peer, the peer gets a copy of the ledger. But they also get a copy of the Ethereum Virtual Machine. Therefore, all peers can process smart contracts written in Solidity. There’s no worry about o/s compatibility or version skew — the virtual machine is a self-contained package that pretty much lands on its feet on any major platform.

The next major jump was with Hyperledger. This is a blockchain dedicated to building “enterprise-grade blockchain“– managed by the Linux Foundation as a consortium of private enterprises. Private enterprise sometimes has particular requirements–for one thing, they sometimes don’t like storing private data on a gigantic public blockchain. Indeed, medical and other private applications are often mandated to keep data “on premises.”

With regard to smart contracts, Hyperledger took Ethereum’s basic direction and expanded on it:

Instead of developing a new programming language, they opened the door to existing general-purpose languages. They started with JavaScript and GoLang. Both are well-known, powerful languages commonly used to develop full-scale web applications;

Instead of a full virtual machine, they used “container” technology to distribute the code (Docker, to be precise). The containerized contracts and other application software can be digitally signed and distributed to the peers using the same technology used in developing cloud-based distributed web applications;

Equally important, they separated code execution — the running-of-the-code — from the management-of-the-blockchain. This means that every peer does not need to have a copy of every “contract,” and every peer is not responsible for running every bit of code. This has important implications for both privacy and scalability.

There are many other changes, and advances from one day to the next. Indeed, earlier this month Ethereum and Hyperledger formally joined hands.

Our goal is not to claim that any of these blockchain systems is “better” than any other. We’re looking at these 3 successive generations of blockchain to point out an overall evolutionary trend, characterized in the specific changes mentioned above.

These point the way toward blockchain-based virtualization; that is, using blockchain to further pry applications away from the web of dependencies that bind them into centralized infrastructure. It means software applications are easier to distribute globally through stronger authentication and a cleaner separation from the computer infrastructure used to deliver them.

This is where we take our direction.

At GeoCertify, we know that addressing the needs of a global supply chain like coffee will take more than a digital wallet and cryptocurrency.

The coffee supply chain involves tens of millions of independent farmers in remote regions. It involves massive logistics and international organizations. Large organizations have tended to use large centralized software applications. These need to be migrated to a distributed environment backed by blockchain authentication.

At GeoCertify, we happen to be building on Hyperledger — data sovereignty is a very real issue in the world of coffee.

In our case, we already have a distributed application for the coffee supply chain–built over the past 10 years. We’ve already traced over 50 million pounds of coffee from 22 origins worldwide. From that foundation, the move to blockchain is an incremental change–we’re not starting out with a walking stick and a whistle.

Our first phase was to establish GeoLedger on our cloud infrastructure and write simple transactions into the chain — when farmers sell coffee cherry to a cooperative weigh-in station, we capture it; when a cooperative sells coffee parchment to an exporter, we capture it; when an exporter ships coffee to an importer, we capture it; and when an importer sells coffee to a roaster, we capture it. The ins and outs and challenges are for another post.

For now, looking beyond this first step, we have a growth path toward distribution and the eventual virtualization of GeoCertify services. More on that later.