A Non-Architect’s Guide to Blockchain Architecture

I’m not a technical architect. Are you? If yes, you may find this simplified attempt at explaining blockchain architecture… excruciating. If no, you may find that it helps you better understand the basics. Either way, you will find my jokes excruciating.

Grab a coffee, it’s time to learn about the building blocks of blockchain networks!

If you’re building a blockchain solution, there are two main parts for you to think about: the blockchain network, and the blockchain code. In this article, we’ll explore each part in more detail — including some of the many different names you may hear them referred to by!

In a nutshell, the blockchain network is the infrastructure you need in place for a group of organisations to share data and processes together on a blockchain. The blockchain code runs on the blockchain network, and defines what the organisations who participate in the network can use it for.

Hyperlegendary

There are a bunch of different blockchain implementations, and writing an explanation that covers them all would get super complicated. So I’m going to focus on some technologies that are part of Hyperledger. This open-source blockchain project sits under the Linux Foundation, and is one of the more popular choices for private blockchains (ones where you only need a specific group of businesses involved, not everybody in the world). It’s the technology of choice for many tech companies who are building their own offerings and want to base them on stable, open-standards technology. Full disclosure, it’s the one that IBM (where I work) have chosen to get behind, so obviously I think it’s super awesome ;)

Also note that because we’re talking private rather than public blockchains, you should think more “companies that share a supply chain also sharing a blockchain” than “everyone in the world buying and selling crypto-kitties”.

Pineapples and other precious commodities

Everybody loves examples, right? Say there are 3 organisations that want to track pineapples as they pass along their supply chain; and 3 totally different organisations who want to trade corporate bonds with each other. I’m no expert on either pineapples or corporate bonds, but I think it’s fair to expect the contracts that govern the exchange of these 2 types of asset to be pretty different from each other. So the blockchain code these two groups of organisations use would be very different (we often call such groups “consortiums”, by the way).

The blockchain networks on the other hand may actually be very similar: each consortium has 3 organisations, and whatever type of business they’re doing, they’ll need similar things like an Ordering Service, Peers, Channels, Membership Services… If you don’t know what all those things mean, don’t worry: we’ll come back to that in a moment!

So in this example, blockchain networks: pretty similar. Blockchain code: very different.

Exactly the sort of situation we seek to avoid via a shared, immutable ledger with blockchain ;)

Blockchain Networks

When you form a consortium with other organisations, and agree to “do some blockchain” together, you’re joining a blockchain network. Networks can be looked at in 2 ways: the organisations and people that form them, versus the technology infrastructure that those organisations share.

We’d best pick one of our two example consortiums to run with, and I think we can all agree that pineapples are way more likely to be that elusive “killer application of blockchain technology” than corporate bonds. So we’ll go with that one.

The 3 organisations are as follows:

• Pineapple Farm
• Pineapple Courier
• Pineapple Seller

You may have heard blockchain described as a “shared, immutable ledger”. So we need a Ledger. In fact, we most likely need 3 ledgers: one each for the Farm, Courier and Seller. Typically, each organisation in the blockchain network will have their own copy of the ledger, and they are kept in sync with each other via some clever protocols. These copies of the ledger are stored on servers which are joined together in the technical layer of the blockchain network: we call them Peers.

Next, with everyone having a copy of the ledger, we need some central service to decide what gets written to it. You can’t just have the Farm updating their ledger however they like:

“Oh yeah, we totally sent 500 boxes of pineapples Guv’. Mustv’e been the Courier wot mislaid ‘em!”

(Yes, in this example the Pineapple Farm is located in South London).

Additionally, if two things happen in close succession, you need to agree what order they happened in. That’s why this central service is called the Ordering Service. Typically, the organisations will share one, and it handles deciding what transactions really occurred, and in what order they happened.

Now the Courier doesn’t just have one lorry driver. No, that would never do: the people of South London have a ravenous, unquenchable hunger for pineapples, and one lorry just couldn’t distribute them fast enough! The dozens of lorry drivers all need to make updates to the ledger. To make authenticating multiple users easier, each organisation will typically have its own Membership Services Provider (MSP) — this holds certificates for users that are allowed to access the blockchain network via the Courier’s Peer, and thereby ensures that only people who should be able to access the network can get in. (We won’t cover Peers explicitly here, but think of them as them as servers that are joined to the blockchain network and offer a point of access for the organisation they belong to.)

There’s plenty more to know about blockchain networks, but if you’ve understood this much then you’re off to a good start, and we’re ready to move on and talk about blockchain code.

Diagram from the Hyperledger Fabric docs. Note what is clearly a Pineapple Lorry at the bottom.

Blockchain Code

Once you’ve got your blockchain network up and running, it’s time to agree what sort of business transactions can take place there. In the real world, the organisations would have legal contracts and agreements in place — that’s why blockchain code is sometimes referred to as Smart Contracts. Depending on the blockchain flavour you’re using, it could alternatively be called Chaincode, or in my personal favourite case a Business Network Definition.

That term is my favourite because it comes from Hyperledger Composer — if you’ve read my blog before, you’ll know I contribute extensively to this open source project for creating blockchain code using models and JavaScript functions.

Our Pineapple Consortium are big fans of Composer too, so they’ve written a Business Network Definition to deploy to their blockchain network: it constitutes a shared agreement of the rules by which they will do business on the blockchain. They define their roles on the network as Participants: Farm, Courier and Seller. Next, they define the Assets: Pineapples. Finally, there are some Transactions: things that can happen to update the status of the Assets which are of importance to some or all of the organisations in the network. For example, they might define “load pineapples onto lorry”, “deliver pineapples to seller”, “sell pineapple to customer” etc.

Next comes the fun (if you enjoy JavaScript) part: for each of their Transactions, they write a Transaction Processor Function, which codifies the things which must take place when it is invoked. Again, think of this like a contract: if the Courier wants to say that they’ve “delivered pineapples to seller”, how do they need to prove this, who needs to agree, and what will happen as a result? Most likely there will also be a “receive pineapples from courier” transaction plus access controls to make sure that only the correct Participant can trigger each of these Transactions. So, when some pineapples are delivered, we’d need:

• Courier (Participant) invokes “delivered pineapples to seller” (Transaction)
• Seller (Participant) invokes “received pineapples from courier” (Transaction)
• The ledger (accessible by all) now clearly shows that the pineapples changed hands

Diagram from the Hyperledger Composer docs. Disappointing lack of pineapple references.

Putting it all together

With the blockchain code written, the consortium can deploy it onto their blockchain network. They now have a shared immutable ledger where they can securely update data that they all agree in accordance with processes (contracts) that they all agree on.

So how has business changed for our Pineapple Consortium? Any individual asset can be traced back through the entire supply chain in one place: if some dodgy pineapples make consumers ill, there’s no need to call up multiple companies and check multiple separate records to figure out where they came from: the Seller can just check on the ledger, and know that what they’re seeing matches what the Courier and Farm would see.

And in the case of the the Farm blaming the Courier for losing those 500 boxes of pineapples, blockchain can also help. By checking whether the “give pineapples to Courier” and “receive pineapples from Farm” transactions took place, we know the single truth that the organisations all agree happened. If we’re missing the “receive pineapples from Farm” transaction in the ledger, the blame rest firmly and un-arguably with the Farm: no more “my records say we never received them”, “well my records say you did!”.

All in all, everybody is able to enjoy their pineapple-trading with trust, confidence and responsibility. A big boost for the South London Piña Colada industry.

That’s it for our whirlwind introduction. If you’d like to learn more about these concepts, then I recommend Hyperledger Fabric and Hyperledger Composer as excellent tools to read up on!