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.
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 below.
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 the unlinkability of transactions, the anonymity of users, and the confidentiality of transactions.
There are some compromises to be had here as it is not possible to delete data from the 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, and 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.
Further reading:
One process per container best practice (hard in reality).
https://cloud.google.com/architecture/best-practices-for-building-containers
Getting started with AWS Managed Blockchain.
Hyperledger.
https://hyperledger-fabric.readthedocs.io/en/latest/architecture.html
https://chainstack.com/protocols/fabric/
Scaling hyperledger out in the wild.
https://medium.com/debutinfotech/deploying-hyperledger-fabric-v1-2-on-kubernetes-cluster-94a4c8032f3
Norwegian University of Science and Technology — Research paper on Blockchain Healthcare records and GDPR — just to prove you can tackle difficult use cases with the technology.
