A quick guide to scaling Blockchain architectures.

5 min readFeb 16, 2022

There is this assumption that when we are talking about Blockchain we are also talking about Crypto. Well, there are a lot of other possible use cases for Blockchain. Smart contracts are one of them. But Blockchain is fundamentally a clunky architecture — there is nothing very elegant about it, it is a struggle with compliance and the nature of it being used for Crypto (which facilitates a lot of money laundering) means every fraudster under the sun has some idea of how it works…

David Rosenthal recently dived into this in a bit of detail including all speculative complexities of the regulatory environment as well as the application architecture. Moxie Marlinspike had a similarly revelatory teardown of NFT’s whose architecture was not only really NOT immutable but really perfectly designed to scam. The trouble is the whole conceptual space the Blockchain sits within is a difficult problem within Software Engineering to solve. There are compromises everywhere. But as long as we live within spitting distance of libertarian speculation…. the newly termed “Web3” will continue to be popular.

In principle, it’s a hugely exciting space with a lot of creative and innovative possibilities. For the downside well it needs regulation and you just need to read the aforementioned blogs to really get the gist.

If you’re investing or building in this space do read 👀 this:

David Rosenthal

https://blog.dshr.org/2022/02/ee380-talk.html

And not to forget…Moxie Marlinspike’s post here 👇

https://moxie.org/2022/01/07/web3-first-impressions.html

Some good news 🗞

But what if you just want to build a bonafide blockchain-based solution for some other non-crypto use case? Well, it’s easy to get going on one of the cloud providers solutions for quick product prototyping and consideration of scaling.

AWS is my current comfort zone so this article outlines how to approach that using AWS’s managed services. The information in this article is some months old but still very relevant I believe.

I outline below the key approaches and outline an initially scalable architecture to help you get started.

So let’s say we have our product which we have tested with some of our prospective B2B SaaS customers and now want to scale.

Compliance

First things first — you need to think about compliance. If you have to consider GDPR compliance then you will need a permissioned blockchain.

Permissioned blockchains rely on encryption and pseudonymous identities to take care of requirements such as unlinkability of transactions, the anonymity of users, and confidentiality of transactions.

There are some compromises to be had here as it is not possible to delete data from blockchain only disassociate one source from another. This despite all the hype — and non-engineers who might try telling you otherwise — has scuppered many projects in this space. Rendering blockchain non-compliant. Engineering compromises here can render the technology to be entirely superficial.

Scaling

We have done our little product test on AWS — get it going in around an hour with their managed services and this tutorial.

https://www.youtube.com/watch?v=x-AjS-WuF2Q

The other critical thing to point out here is that the AWS managed service does not require Solidity knowledge. This is critical as the explosion in the crypto market has led to inflated prices for anyone with 10 minutes of experience here. Any way to get around this will be welcomed by whoever controls your budget.

But now we want to scale? So how to approach this? Well, it's not an uncommon approach to containerising your blockchain application and AWS has a good solution for this. I have selected Docker for my architectural approach. Container orchestration will also be necessary Kubernetes seems like a logical choice.

Startups often struggle here as it requires a bit of rethinking around the product and considering it as several co-joined applications. Lack of technical product knowledge leads to a lot of challenges, (UX people are too vaguely design-focused, your developer is a programmer, technical product skills should really be more of a thing). The best practice is one process per container, you shouldn’t have multiple microservices and apps in one container..(I have seen some horrors). But this can be hard to achieve depending on your use case.

Scalable architecture Docker + Kubernetes.

A containerised view…

Dependent on how many nodes and peers you need or wish to run you will need to scale the number of containers accordingly. This will also be hanging on other factors such as fault tolerance and DR. See my other articles regarding forecasting your AWS costs.

AWS Hyperledger Managed Blockchain currently only supports 3 nodes, however additional nodes can be added via AWS API Actions and SDK. Hyperledger peer nodes, orderer and explorer components should be in separate Docker containers(As per the above image). It is also possible to consider Chainstack platform integration here.

Find out more here: https://chainstack.com

Example with sdk > https://docs.aws.amazon.com/managed-blockchain/latest/hyperledger-fabric-dev/get-started-create-peer-node.html

API actions > https://docs.aws.amazon.com/managed-blockchain/latest/APIReference/Welcome.html

(NB: Anyone with experience in architecture, in general, will know how utterly useless most architectural diagrams are. I hope mine is an improvement on many and doesn’t require endless explanation.)

As ever I could go on and on and on here, but this is really an introduction, a starter for ten. If you’re interested in this space and require some further guidance you are welcome to contact me. You can trust me I’m an architect. 👩🏻‍💻

A quick guide to scaling Blockchain architectures.

Some good news 🗞

Compliance

Scaling

Further reading: 📚

Written by Gemma