This chapter will look at designing various constructs of blockchains and distributed ledgers in different use cases. After walking through an array of technological tools, the software architects, solution architects, and product design engineers have to generate architectures of blockchain elements either from scratch or on top of existing technology tools. This decision is usually based on the business requirements, technology choices, and developers’ skills.
Architecture design of a software/application/platform or a network can be done at macro to micro levels based on the definition of the business use case. We shall divide the chapter based on the scale of the use case, starting with the macro level, moving to a domain-specific use case, and going to a micro-level design for automating smart contracts. Highlights of this chapter are as follows:
Designing: In the first section, we will review the macroeconomics of the use case first, then define the business impact, and finally select the technology stack for assembling a blockchain for trade finance.
Defining: In the second section, the wide frame from the last section will be reduced to a narrower use case, one specific to a particular function and not the entire economy and ecosystem. The stakeholders are finite, and the functional dependency is highly reduced.
Implementing: In the third section, we will examine the technology stacks for smart contracts, including the legal frameworks for various geographical locations that recognize them and the requirements to adhere to the conditions of the smart contracts.
Core fundamental process of designing architectures for a blockchain platform
The core fundamental process of developing architectures for a successful blockchain platform is an iterative process, as shown in Figure 8-1. It requires continuous review of the design based on the feedback of implementations.
Measure of scales with respect to user base, locations, entities, objects, etc.
Functional density and coverage
Functionality and scalability (depth-wise and breadthwise)
Computation complexity plus hardware dependencies
Core decisions toward implementations
Tools to support scale and maintenance
Frameworks
On-chain and off-chain combinations of architecture design
Let’s call these the 8D factors of architecture .
Designing a Blockchain Solution Architecture for Trade Finance
Exporter/seller
Importer/buyer
Issuing bank
Nominated bank
Advising bank
Chain of banks/branches involved in the verification process
Intermediaries such as shipper, customs, procurement companies
Global trade players
This may vary case to case. Here, we look at it in the crudest form that a beginner would view and understand. From there on, it is an iterative process to refine the architecture design based on the maturity of the platform, the stakeholders, and the positioning of the core functions of the chain.
In trade finance, let’s identify a challenge that really may need a blockchain. We must consider the credibility of the trade players. Many large-value trades default, either in payments or in delivery of the trade items. Trade finance brings letters of credit and bank guarantees by financial institutions to be catalysts for credible trade.
First Challenge
Usual Process of Letter of Credit generation across institutions
Traditionally, financial institutions were the centralized source of trust, therefore the concept of LoCs. However, in recent times, there have been cases of default despite such documents due to hackers being able to hack into bank systems, or manual intervention being undertaken by staff/contractual third-party collaborations, and so forth.
This centralized trust can surely be scaled up with the more secure practices of blockchains. When a bank commissions and outsources the development of its digital systems to a company, if on a blockchain, the trust and transparency are maintained regarding the inclusion of said company. Many may disagree that such transparency allows for better practices. Therefore, during the design of a blockchain for the trade finance chain, one may choose the type of blockchain and its activities.
However, one element of security is ensured, for a hacker to hack into a centralized server is lot less computationally intensive than to hack into a whole decentralized blockchain network. So with blockchains, we do not directly call for the removal of intermediaries. Many times blockchains facilitate more transparent and credible practices.
Now that the design is established, we shall dissect the use case for blockchains in trade finance for letters of credit. Starting with who initiates the onboarding of other players among the listed set of trade players? Why would anyone agree to join a transparent blockchain ledger? How many businesses still avoid having an online presence?
Therefore, the first challenge of design is onboarding mechanisms.
Since a bank or a financial institute is deemed to be a credible source by all majority trade players, it may be logistically easier to initiate onboarding with banks. However, this is not a hard and fast rule. One may initiate onboarding industry-wise; for example, one can start with the onboarding of farmers and consumers and plug other players in gradually. so based on the players involved in a transaction for a business, the decentralized platform may choose the onboarding mechanism.
Consensus required for onboarding?
Onboarding user and onboarding node the same?
Pre-requisites required for onboarding of member?
Who is enabled to onboard after the initial onboarding?
All the answers to the preceding questions entirely depend on the business, challenge, and purpose of the chain. In our siloed case of consideration, we allow the financial institute to onboard an initial set of members. Members can further onboard other trade players that satisfy the on-chain consensus conditions. Every user is a node, making it truly decentralized end to end.
Second Challenge
Once the onboarding mechanism is chosen, but before onboarding the members, the solution architect needs to ensure all activities/transactions follow the common rule of consensus defined before any onboarding. For example, when a set of smart contract rules are validated, only then can the defined activity take place, or can be the proof of stake where the majority of stakeholders decide the activity to execute or to decline. In a consortium of private and public blockchains, there can be more than one form of consensus in the blockchain, each pertaining to the private or public blockchain.
Therefore, the second challenge of design is choice of consensus mechanisms.
One of the original reasons for forming the blockchain was credibility; therefore, the consensus mechanism needs to ensure that the credibility of the trade players is transparently tracked and maintained on-chain. Points of consideration may be identified throughout the book where consensus mechanisms are defined, or one can develop one’s own mechanism.
For the current use case, we chose a combination of proof of work and proof of stake, along with the conditions of the smart contract that create the value of credibility that will govern the overall trade trust.
Once consensus is defined in the blockchain, onboarding to private/public blockchain consortiums can begin. The public blockchain may host all peer nodes that trade or are involved in trade. The private blockchain may be formed ad-hoc or synced whenever trade is initiated, and only those trade players may be included.
Third Challenge
During onboarding, the Know-Your-Customer (KYC) may be required as per the design, along with the peer node validation. This is similar to a referral from friends/family or a validation from a bank.
Post-onboarding of trade players, one has to assign the role they will undertake on chain.
The third challenge of design is assignment of roles to nodes .
Client Nodes – End users that onboard when they require a service on the chain. In our current use case, it is the importer and exporter (i.e., buyer and seller).
Peer Nodes – The banks that the end users deal with need to be on-chain permanently. The issuing and nominated bank branches may be identified as peer nodes. Certain peer nodes can be endorser nodes. For example, the issuing bank endorses the exporter’s credibility, initiates a transaction, and maintains the state of his credibility.
Orderer Nodes – These nodes are the conveyers of transactions, validating unbiasedly to ensure the delivery of the transaction activity in a fault-tolerant way. Therefore, by design, the architect needs to ensure the ratio proportion of peer nodes and orderer nodes is appropriate to avoid bias imbalance.
Further, CA nodes could be authorizers of these roles and assign powers associated with these roles. This authority by CA forms consensus by proof of stake to maintain the permissioned ledger aspect.
Assigning the roles to members on-boarding
Fourth Challenge
After the assignment of roles, the platform requires the definition of the data structures and transaction activities.
The fourth design challenge is to define on-chain data structures and transaction activities.
Here, the definition is scoped based on the focus of the letters of credit and the regulations around them.
Document inputs, such as KYC, bill of lading, etc.
Document verification status
Majority voting status
Conditions of the smart contracts
Validation of documents
Transfer of documents
Approval of smart contract conditions
Payment dispatch on majority status
FEATURES | Description |
|---|---|
Node generation, integration, and chain setup | • Creation of nodes (KYC/ AML) • Access control • Link generation • Sequence locking • Document machine translation to smart contracts • Self-authentication |
Smart contracts for letters of credit (LoC) and bank guarantees (BG) | • LoC smart contract request form • BG smart contract request form • Auto-verification of smart contract across nodes • Transfer of documents through chain • Validation and alerts • Smart triggers as per contract |
Transactions and other actionables | • Real-time money dispatch on honoring LoC smart contract • Loss settlement on withholding bank guarantee • Alert on various document updates • Warning alerts on low credits and fraud detections |
Monitoring panel | • Node view as per access control • Authorization control • Validation controls • Reports and alerts |
Fifth Challenge
To get further clarity and the predictability of a complete design, one must ensure the blockchain covers all cases. So, the next design challenge is ensuring full functional coverage.
The fifth design challenge is to implement a full-coverage blockchain code.
User stories on the buyer side
User stories on the seller side
Validation and transaction activity between banking nodes
Remember: As an architect or a developer or a blockchain platform provider, one has the responsibility to design and develop a full proof so as to avoid any loopholes, bypasses, and centralization opportunities. These issues are entertained in a centralized platform as one can keep updating without any consensus of the subscribers. However, corrections and updates on a blockchain get computationally complicated due to the consensus required to accept the change and update the local nodes. Thus arose the concept of forking.
what happens when a blockchain diverges into two potential paths forward
a change in protocol
a situation that occurs when two or more blocks have the same block height
a situation where contradictory loopholes are found or race condition–like situations occur
For example, when the number of users in the trustless network of Ethereum Classic (proof of work) increased, vulnerability increased, leading to a 51 percent attack. It is an attack that is possible on a blockchain that uses a PoW algorithm for consensus if the attackers have over 50 percent control of the network hash rate. That means the majority of the network is filled with attackers that validate and allow fraudulent transactions, causing the attack. Such loopholes are to be pre-envisioned to avoid security breaches.
Solution: user stories for all cases
Fill in the following table for a decentralized inventory system such that it avoids high inventory costs and minimizes stock-out loss.
Centralized conventional flow of trade finance
Decentralized flow of trade finance
Note that this arrangement is a consortium of various blockchains. Some between organizations, some within organizations. For example, the public chain across all stakeholders will be inter-organization, where multiple parties are involved in the trade. Many times, a node representative will be an organization representative that requires internal consensus to perform an action on the public chain. So, whenever the private chain in an internal organization is forming consensus, that is when the node representative validates the transaction on the public chain, thereby maintaining full end-to-end transparency and connectivity.
Sixth Challenge
The final design challenge is to arrange the elements in the architecture based on decisions identified in Chapter 7 and in the preceding pain points.
The sixth design challenge is to draw out the consolidated architecture stack.
A consolidated architecture stack with all components
The consolidated stack comprises the end-to-end touchpoints, ranging from edge devices such as IoT integrations to the event grid that triggers events based on the smart contract or consensus (Figure 8-11).
Enterprise positioning of financial institutions involved in global trade finance
system architecture
enterprise architecture
application architecture
Refer to Figures 8-13 and 8-14 for sample architecture flows typically in a financial services environment.
System architecture lets you place the physical and virtual components of the blockchain across the network with respect to hardware (such as virtual machines on cloud, computers, servers, mobile phones, smart devices) as well as its integration with the software service layers hosted.
Process flow for setup of blockchain in financial institutions
Application set up in a financial services environment
Now that we have learned the different types of architecture and their application-based designs, let us look into the 8D Factors of Technical Architecture defined at the start of this chapter.
Measure of Scale with Respect to User Base, Locations, Entities, and Objects
User Base and Locations
In trade finance, the user base includes a global canvas of people ranging from traders, buyers, exporters, and international agencies, to customs, regulatory bodies, countries, financial institutions, vetting bodies, and so on. At the same time, it includes local micro-chains of producers, transport companies, cooperative banks, agro distributors, packaging companies, financial micro lenders, local governmental schemes and bodies, and so forth that work around the local environment. As a blockchain platform, one may cover local or global areas—it depends on the problem that the platform wishes to solve.
For example, if financial inclusion is the focus of the chain, it must start locally and spread to remote areas to which access is limited. When global financial inclusion is the focus, the blockchain platform must connect all remote areas globally and include trade aggregators to accelerate outreach. One may incentivize these peer nodes to onboard remote trade players. The question that may arise is, why include all such players while considering trade finance? When the end-to-end players are completely connected by a decentralized platform, information is a lot more credible than when you have biased sources of information offline or on centralized online platforms. With such credible information on this immutable ledger, better-informed decisions and predictive factors can be calculated. The proof of credit can be tangibly measured; you’ll have not just the validation of one node or a group of nodes but also the tamper-proof history on the blockchain ledger.
An architect developing the design for such a platform needs to factor in the scale of the user base based on the short-term and long-term goals of the business service. Similarly, the locations of global, local, and remote entities have to be decided in order to shape the technology stack around them. Further, with the consideration of location, one has to factor in the socioeconomic status of the user’s locale. For example, places without proper internet access might need to be part of fault-tolerant networks so that if validation does not get approved by every user due to a lack of internet, operations could still continue. The architect has to maintain the right ratio of validator nodes, peer nodes, and orderer nodes for a functional network with the right forms of consensus mechanisms. Also, the architect must choose the device form based on location; for example, field specialists such as farmers and fishermen might not have computer access, and therefore those nodes might have to be on a virtual cloud server node or mobile device node or a camera node that could be an IoT device connected to the blockchain.
Entities and Objects
With platform of several entities involved in a trade finance blockchain, the regulations, IT policies, and access control may differ from entity to entity. If it is a collaborative network, to have appropriate consensus, all factors of the various entity policies have to be covered. For example, a cooperative bank or a financial institution needs to maintain its Azure Active Directory in a particular way; the format has to remain as is. Azure provides a mapping between the enterprise’s Active Directory to the blockchain’s user directory. A blockchain integration may run over multiple Azure accounts with their independent AD policies. This mapping to the blockchain’s directory is crucial to the design. At the same time, a node from one entity must not be able to access other entities’ ADs in any way.
Objects may be assets, contracts, data structures, off-chain reports, and so forth. However, there have been several fintech hacks in the cryptocurrency markets resulting from improper security of off-chain wallets. So, in a trade finance network, if the validation circuit is on-chain, and the downloadable report can be modified off-line without a hash address trace, then the entire point of having such a validation on-chain is invalid. So, the architect must question whether a blockchain is truly required while constructing every object, both on-chain and off-chain. Azure securely maintains monitoring systems, event triggers, and off-chain stores to trace objects.
The measure of scale could be as small as a three-entity local blockchain network for trade finance or as large as a million-entity global blockchain network for global trade finance. However, maintaining the decentralization and consensus along with the core fundamentals of the blockchain is extremely crucial at every stage. At the same time, once established and processes are set up on-chain, one can expand the transaction activity from one object to several objects (assets) and scale functionalities.
Functional Density and Coverage
Functional density could be based on adding more players to the chain for a particular function or increasing functional responsibility for a few players in the chain. At the same time, certain functions may be irrelevant to the core challenge of credibility and may be taken offline.
To be exact, letters of credit process validation may go through several internal processes within an entity. So, does one add all players in the same chain or create a separate private chain for this internal process? Similarly, when user inclusion is decided for the trade finance blockchain service, is the selection of users wider or highly niche? This defines the type of users in the coverage.
Functionality and Scalability (Depth-wise and Breadthwise)
Once the definitions of the first two factors are clear, one has to map the technical aspects based on the defined functionality and scalability. For example, when there are thousands of features on a blockchain, with limited scalability, the time-lags are well adjusted. However, would the same source code for the blockchain suffice for a billion-user base? The vision of functional depth and breadth with respect to user-base scalability has to be clear so as to avoid several hard forks. When Azure components form parts of the blockchain, such as event grids, compute servers, and AD-based authentications, the scalability issues are modularized and can be easily taken care of in silos.
Computation Complexity Plus Hardware Dependencies
The form of consensus method chosen has a crucial impact on the hardware computation and memory. Every node has to be active for a blockchain, which causes an expectation of high up-time from all nodes, leading to an eventual bottleneck. The selection of a consensus algorithm based on the scale definitions helps to identify the hardware dependencies.
Alternatively, businesses may start with planning for hardware limitations before doing the platform design, which is the step where consensus algorithms have to be selected. Based on this step and the affordability of the majority user base.
Core Decisions for Implementations
When certain limitations are discovered—for example, the proof of work reduced a stakeholder’s influence on decisions—such decisions have to be a hard rule on-chain. When a chain is governed by proof of stake, one has to decide to ensure all transaction activity follows that very standard set of procedures.
Tools to Support Scale and Maintenance
Azure components speed deployments and node inclusion in most cases. The maintenance of services on-chain is taken care of by the cloud service provider. At the same time, one must carefully measure the computation versus tool costs to enable blockchain services.
Frameworks
Blockchain frameworks such as Ethereum, Hyperledger, Corda, and Ripple can be easily integrable with the Azure components, making sure deployment is faster and scalable. Based on the choice of scale, locale, and form of consensus, one can choose the desired framework.
On-chain and Off-chain Combinations of Architecture Design
Since the trade finance blockchain network traverses through several organizations and entities, certain elements will always be off-chain. For example, the core AD values of authentication will be centrally controlled only by the organization owning it. Democratizing those elements on-chain is irrelevant in this blockchain. Similarly, SAP or other existing ERP data where the intermediate state of data is irrelevant do not have to be hosted over blockchains. Therefore, identifying elements, data structures, and assets both on-chain and off-chain is one of the most crucial aspects of design.
Defining a Content Distribution Blockchain Architecture for Content Tracking, Licensing, and Royalties
Getty Images and Shutterstock deliver image content with their licenses and use rights. Similarly, Spotify ensures connectivity to independent artists’ content that is catered to end users. These centralized platforms provision accessibility. However, the problem of piracy remains a large concern. Many movie scripts and screenplays have been plagiarized, with no order or control. Such data leaks were often not traceable, as the storage of machine addresses was not a common practice. Now, in this era, when global places are getting closer, a copied film script from one country is easily identifiable in a faraway country. However, such traceability is partly done online and partly offline due to the manual intervention involved.
Similar to the case of fake news, fraudulent data contributors make it hard to identify fake patterns due to mismanagement of the data’s traceability. This does not mean centralized platforms do not have traceability, but it was never a prime concern. The traceability can be maintained in centralized platforms. However, it is highly tamperable. Enter blockchains.
This makes it an interesting use case, where genuine data sharing is of true value and there is equal contribution throughput and returns for such data. So, content providers are directly incentivized based on the data’s value. This is even seen in many of today’s content platforms, such as YouTube, Instagram, and so forth. However, as the platform scales, it becomes very difficult to identify the genuineness of the platform content. The effort to identify fake content on such platforms costs platform providers time & resources as well as a case of mis-identity for genuine content creators.
Blockchains maintain traceability from source to destination with every digital copy. Think of it as a digital signature of the artist/content creator that moves with the asset. When a document of data is shared with someone over Google Drive, one could create a copy, modify, tamper with it, and share it further. The original ownership and data about royalties are lost with such forms of sharing. Also, such centralized services expose the content over the network, as there is no upfront assurance of end-to-end encryption in such cases. So, we need blockchains.
With end-to-end encryption and the transfer of assets with the digital signatures of the content creators, traceability can always be maintained with blockchains. Apart from traceability, it is the access to incentives that could happen in real time or more transparently and fairly on blockchains that makes them appealing. For example, in a centralized content-management platform like Twitch, where gamers who stream their game videos get paid between one cent and one dollar an hour based on popularity and viability for advertisements, the incentives are paid when certain conditions as per the rules of the platform are fulfilled and the disbursements are made as per company policy at the sole discretion of the company. In such situations, the content-hosting company has full ownership of the authority and incentives and may regulate value and policy as they wish without taking consensus or agreement from the content creators. Now, imagine if there were a blockchain-based content-sharing platform that distributed hosting and content-creation responsibilities to client nodes, orderer nodes for host sharing and load balancing, and validation nodes to validate the content distributions. On such a platform, sharing, distribution, and incentive-sharing would be based on true blockchain consensus. Only then would the action of viewing, redistribution, and payments be triggered. Also, the value of the incentives could be more transparent with respect to profit-sharing and the agreed upon value, as per consensus.
Content-distribution platform architecture powered with AI on blockchains
Quizzycash: a content-distribution platform that measures proof of engagement on blockchains
So, a blockchain company called QuizzyCash runs on the consensus of proof of customer engagement. Every content value is incentivized based on its measure of customer/user engagement. In simpler terms, if there is an important English Premier League match coming up and the latest quiz has relevant content, the traction of customer engagement may be high, yielding high advertisement values and thereby incentivizing the creator proportionally. This was developed based on NEM’s framework of proof of importance. The token mechanics are generated based on the desired measure and distribution.
Technical architectures of existing frameworks can always be modified to fit the application, enterprise, and system architectures.
Factor | Impact |
|---|---|
1. Measure of scale with respect to user base, locations, entities, objects, etc. | User base could largely vary based on geolocations and the market size. For example, Netflix has a huge consumer base in India; therefore, the value return for content targeted toward a location could become more transparent to the content creator directly. Similarly, when content agencies are involved in deals with content distributors, many times payments are stuck in spite of profitable deliveries. Here, blockchains enable entities to be involved in fair trade based on auto-executing smart contracts. Similar types of content can be stored on the blockchain ledgers, such as movies, artworks, books, etc. |
2. Functional density and coverage | Functional density could be based on the content generators’ impact which measures beyond mere advertisement fees and subscription rates. It may extend to neuroscience impact in a region or a country as well as the coverage of impact from various demographics. |
3. Functionality + scalability (depth-wise and breadthwise) | A blockchain architect for such a platform has to decide the direction of breadth of features or its depth based on the user base during its initial phase through the growth phase. Similarly, scalability is to be decided. |
4. Computation complexity plus hardware dependencies | Once functionality and scalability are locked, the computational complexity of passing content is to be calculated. Is it entirely the content itself on the blockchain, or just a pointer reference of the content? For example, having movies or art pieces on a blockchain would makes it storage-wise intensive, as several copies make it bulky. Complexity calculations enable one to forecast the node server’s running costs, and so the incentive plans of distribution must fairly account for it. |
5. Core decisions toward implementations | Core decisions are similar to rules that the platform as a whole must abide by. For example, the blockchain ledger does not allow free ticket content to be added on the platform. |
6. Tools to support scale and maintenance | Once identified that the gradual scale and functional coverage may change, one has to plan the hard and soft forks of updates or include them in the consensus agreements during onboarding. |
7. Frameworks | The current example was built on top of NEM. |
8. On-chain and off-chain combinations of architecture design | On-chain – Content uploads, redistributions, third-party integrations Off-chain – Storage of large-scale content repository |
Implementing Architectures for Legal Smart Contracts
This section does not educate on the legal aspect for any country in particular for smart contracts; it mainly targets the logical flows and the enablers.
Detailed flow of PoW in Ethereum
Further understanding the Ethereum technical architecture and how to make it adaptive to the system, enterprise, and application architectures is highly crucial. The puzzle-solving in Ethereum generally enables the proof of work. Similarly, the legal framework of trade transactions or dealerships requires a well-defined smart contract for all cases, as well as consensus.
Here, the application of auto-enforceable and -executable smart contracts may vary from land ownerships, leases, and real estate dealerships, to insurance claims and financial proceedings. Smart contracts may execute different slabs of insurance premiums based on the style of driving a person may have, rather than based on standard values.
So, the design of an architecture can include the Ethereum/ Hyperledger framework along with the Truffle integrations for wallets and the Solidity execution for smart contracts.
Similar to the learnings for the first two sections, compute the 8D Factors of Architecture for automobile service contract management.