Blockchain DAPP Reference Architecture

When I first started learning about blockchain (BC) development I took all my normal steps to increase my skills. I searched the web to understand the 50-thousand-foot view. I read the whitepapers and sought out relevant use cases. I poured through GitHub and all the tutorials I could get my hands on.

I still found myself disappointed. No matter how much I searched I couldn’t find a simple but effective reference architecture showcasing the main considerations one should design for to get a viable application running against a BC. So, I decided to create one.

Now let me preface this by saying that this is not THE reference architecture for a blockchain enabled application, it’s just how I would design it to meet needs as I see them. There are probably dozens of ways to do this. Heck, I may even be wrong on some of this, but I figured I’d rather get something remotely thoughtful out there are hopefully get people talking and improve upon it.

My Guiding Principles

Before we dive into the architecture let’s cover a few fundamentals that guided the design.

1. Ethereum would be the blockchain of choice
2. Must leverage a RESTful API
3. Must be highly available and loosely coupled
4. Must account for both on and off chain data store
5. Must account for trust of off chain data
6. Designed for low transaction (gas) costs
7. Must protect application IP

If we bear these principles in mind the architecture below should provide an effective starting point.

Let’s dig into some of these components. I’d like to highlight a few.

REST API

For me this is node.js or C# running on an Azure App Service API. You could also create an Azure Mobile App and would allow you to take advantage of the “sign-in with”, offline mode, and mobile notification capabilities specific to this service.

Services

For scalability and resiliency reasons I would split a some of our functionality out into their own service domains. These are broken down further into traditional services and Blockchain services and could be implemented as a combination of microservices and Azure functions.

Traditional Services

• Search service will ensure a consistent and delightful search experience.
• Notifications service will handle all email, SMS, and web notifications.
• Billing service ensures transaction integrity and provides plug and play capabilities for multiple payment gateways such as Stripe.

Blockchain Services

• Transact service is responsible for submitting transactions to the Blockchain.
• Query service is different from Search; it is solely responsible for reading from the Blockchain.
• Trust service is responsible for evaluating data read from and written to the Blockchain. It’s main goal it to ensure consistency between off and on-chain data.

Storage Queues

I used a combination of Azure Storage (message) Queues and WebJobs to decouple our application. This level of fault tolerance will come in handy as we scale.

Redis Cache

I couldn’t imagine developing a production ready application without Redis Cache these days, so this is a must have.

Persistent Storage

This consists of a combination of SQL and NoSQL data stores as well as Blob storage fronted with an Azure CDN. We could even bring in distributed file storage solutions such as IPFS or Storj but I would keep it simple to start and go with Azure SQL for relational data and/or Cosmos DB for NoSQL.

Ethereum Blockchain

Lastly our application wouldn’t be a Decentralized Application (DAPP) without the Ethereum Blockchain and Smart Contracts. Our contracts could do any number of things but remember my guiding principles above. We want to do as little processing and writing to the BC as possible to avoid paying higher than needed gas costs.

We also want to protect our IP. Smart Contract code is compiled byte code deployed directly to the BC. Since everything on-chain is visible someone could take our code and decompile it and steal our IP. Just another reason to keep Smart Contracts as thin as possible and perform very little business logic, if any.

For these reasons I recommend recording hashed pointers to our off-chain datasets. Then our Trust service can be used to validate the authenticity of this data. This way we use the blockchain as it was intended, an immutable public ledger. We track transactions and keep other data in normal data stores.

I hope this provides one possible overview of how you can design a real-world application to run against the Blockchain. I also believe the true value of something like this is not in its implementation but in the conversations born as a result. If you have ideas, feedback, or even criticism please comment below and let’s iterate a better solution together.

#blockchain #crypto #cryptocurrencies #altcoin #solidity