How to Design Privacy Into the Internet Using Blockchain

This chapter sets the stage to unfold various elements of blockchains throughout the book.

Let these flash cards (in Figure 2-1) circulate around in your head, and we will see how real-world applications bind them to a successful blockchain implementation.

Figure 2-1

Flash cards for aspects of blockchains

These flash cards are arranged top to bottom in the sequence in which they are to be considered when building a blockchain.

For this chapter, the real-life blockchain platform making literal waves across the ocean is BBChain—Blackbox on Blockchains, which brings a very interesting use case for blockchains from which we can learn. We will decode each element of the blockchain and see how it is embedded into the platform, changing the way maritime data moves across the globe. Highlights of this chapter are as follows:

• Purpose and principle behind the blockchain—consensus and protocols

• Transforming a centralized platform into a decentralized blockchain—shared ledgers

• Securing data throughout the chain—encryption

• Valuing the chain and its utility to stakeholders—tokens

• The end picture—decentralized applications (DApps)

• Setting up blockchain environments on Azure

Consensus and Protocols

Every decade, several ships on the ocean and aircraft in the expanse of the sky disappear. Lives are lost, and no traces are left to be found.

These lives count, and so does the data related to these accidents. Therefore, BBChain attempts to handle the voyage data recorder (VDR) data over blockchains through decentralization. The conventional black boxes or VDRs on the ships record all the goings on onboard the ship. However, it sinks with the lost ship, nowhere to be found in some cases.

While several technologies came and went over the decades, the latest era of technologists formulated to store VDR data on the cloud. VDR providers would sync the box data to a centralized cloud server, to which the black box would transmit at various time intervals.

By revolutionizing the black box with BBChain's protocol that uses blockchains, we will learn how consensus plays a very important role in enhancing the credibility of the black box (Figure 2-2).

Figure 2-2

Illustration of the BBChain public ledger

As seen in Figure 2-2, the main stakeholders involved in the shipping trade include the following:

• Blackbox on Blockchain as Node (IoT device): This device enters all on-ship measurements, sensory data, and travel data in real-time to the blockchain node syncing with the entire network.

• Ship Owners: These users are able to transparently see the real-time situation of the ship and can keep tabs.

• Manufacturer: Ship manufacturers maintain service contracts for the ship for years. Being on the chain lets them be in the loop of the nautical miles traveled and required maintenance done.

• Insurance Companies: During audits, insurance companies require the complete audit trail of records of the state of the ship throughout its history. Connecting on-chain enables immutable records.

• Ship Brokers: On-chain history provides credibility for ship brokers to recommend ships.

• Port and Flag State: Port state is the location where the vessel/ship enters the water, whereas the flag state is where the ship is registered. These records can be onboarded credibly by these entities on the chain.

• Classification Societies: Organization that establishes and maintains technical standards for the construction and operation of ships and offshore structures

• Vetting Bodies: These organizations evaluate the ship's structural integrity and performance, and perform audits and quality checks to form a standardized grading system.

The chain of all these stakeholders of the maritime industry forms the nodes of the blockchain for the public ledger. For any change made to this public ledger, all stakeholders must be in consensus given the pre-defined protocol of that blockchain. Currently, the interaction of these stakeholders is entirely paper based—or is transitioning to being cloud based with digital documents.

Before we dive into the form of consensus used by BBChain, let us review what consensus means in simple terms:

Consensus—A generally accepted opinion or decision among a group of people

—Cambridge Dictionary

The core of any blockchain lies in its consensus. On a blockchain, a group of nodes (servers/peer instances representing users) participating in the chain reaches an agreement on a base principle that is coded into a set of rules for every single piece of data or state across the network. This is achieved through a distributed process across all nodes. Every blockchain may or may not be governed by different consensus mechanisms.

For example, Bitcoin and Ethereum work on the proof of work consensus mechanism. Every time a block equation is solved (work), tokens are awarded to the individuals validating the transaction.

Further, Ethereum is pursuing a shift to the proof of stake consensus mechanism, where, instead of work, the stake (ownership value) takes precedence in forming an agreement.

Here's a view of different types of consensus governing various blockchains.

Blockchain Name	Consensus Mechanism	Description
Bitshares	Delegated Proof of Stake	Mechanism where nodes can delegate the responsibility of having a stake to another node to validate a transaction
NEM	Proof of Importance	Important nodes have high transactional control
Stellar	Federated Byzantine Agreement	Quorum slices chosen at random form intersections to validate a transaction on behalf of all nodes
Corda	Consensus over State Validity Uniqueness	Nodes reach certainty based on the validity of the contract over input and output states as well as the uniqueness of the output, such that the input was never consumed before
EOS	Byzantine Fault Tolerance—Delegated Proof of Stake	Selection of block producers through a continuous approval voting system that runs with a fault-tolerant mechanism

The recent rise in popularity of this technology and the large flow of funds toward it are mainly due to the consensus-regulated nature of such platforms. The quantification of effort, value, and processes has increased tenfold in this era that has a growing digital footprint.

Thus, as a software architect, how do we decide on the suitability of a principle for a blockchain platform?

1. 1.

   Start with understanding the application

2. 2.

   Break down and understand the existing digital form of the application at hand.

3. 3.

   Identify the limitations of the current setup that one is aiming to solve.

4. 4.

   Question which aspect of the application requires decentralization, tokenization, or encryption.

5. 5.

   Segment the audience for the application—random open users or restricted invite-only users?

6. 6.

   Analyze the audience dynamics.

With BBChain, the answers to the preceding questions were as follows:

1. 1.

   A platform for voyage data to be shared across stakeholders

2. 2.

   Existing solutions are on ship or on centralized cloud servers

3. 3.

   Data can be manipulated or lost, leading to conspiracies over lost ships and aircraft in existing solutions

4. 4.

   Data on a shared decentralized ledger, with the value of the data quantified with tokens and secured channels of operations, such that data cannot be manipulated or modified without the agreement of the stakeholders involved

5. 5.

   Audiences of the maritime industry, such as ship owners, port owners, manufacturers, port and flag states, insurance companies, and private users

6. 6.

   The users may be the stakeholders of the public ledger that enlists the data of the ship voyages, vessel names, type of data, locations, ports, and routes. Further users like insurers may want to know more than the information on the shared public ledger. Thus, one must require that the insurer subscribes to private data on the private ledger.

Thus, the following configuration of a hybrid network that has a combination of public and private ledgers would work (Figure 2-3):

• Public Ledger: A chain of nodes where data is shared publicly with all nodes, and every transaction is validated publicly across the chain via a commonly agreed upon consensus of that chain. Anyone can openly invite new members to such a chain and add blocks transparently.

• Private Ledger: A chain of selective nodes that exclusively have access to private data and selective validating rights to form consensus internally with a permissioned set of capacities.

Figure 2-3

Visual representation of a hybrid network of various stakeholders

The BBChain protocol provides a way to reach consensus for the maritime peer-to-peer network of stakeholders for voyage data. The chain is a hybrid blockchain of private chains involving the BBChain node, ship owner, and the IoT devices on the ship, and a public chain that includes all maritime stakeholders, as shown in Figure 2-3. Private chains can be formed on the fly when there are private transactions on the chain. Several such private chains are called side chains and form out of public chains.

Consensus in this protocol can only be reached with a blend of the following:

• Federated Byzantine Agreement

• Proof of stake

• Proof of importance

The foundation of the protocol uses the Federated Byzantine Agreement on the public ledger, which includes all peers of the maritime industry, consisting of manufacturers, port and flag states, ship owners, and other stakeholders. Hence, let's deep dive into the protocol and understand it better, using Figure 2-3.

Federated Byzantine Agreement

As shown in Figure 2-3, the public ledger in yellow connects everyone in the chain. The data distribution for public data is entirely contained on this ledger configuration. This consensus encompasses the principles of FBA (Federated Byzantine Agreement , explained later in this book), with its fault-tolerant capabilities. So, all the ship voyage data that are publicly open to all stakeholders, such as ship routes, locations, and voyage schedules, are openly shared across the ledger. Any stakeholder interested in knowing more about any voyage can then initiate the contract request to join the private ledger to know more about that ship voyage.

Figure 2-4 shows the append-only feature of BBChain, which shows every state of data on the blockchain ledger. Every transaction on the public chain is witnessed by all stakeholders.

Figure 2-4

Public ledger records

Similarly transparency over Voyage Statuses (Figure 2-5), type of purchases of voyage data & other actions are witnessed & validated by Public Chain Nodes.

Figure 2-5

Public ledger records—where legit data can be purchased transparently

The platform allows one to purchase voyage data transparently and benefits the rightful stakeholders, including the ship owner and data owner.

You can think of this as a listing of air ticket options on travel websites.

Now, the question here is, if that's what a public ledger on a blockchain is, then why not just have the old-school website listings on the internet that are already there?

Many listings, such as Monster Jobs, Expedia, and, for that matter, Amazon, are all out there, providing a great amount of information publicly.

However, many times, the data on such platforms is purely controlled by only the companies running them. Thus, the democracy of real users is entirely ignored in such cases. Every time a Terms and Conditions pop-up appears, many online users are forced to sign it and use the centralized platform. Many times, fraudulent activities that are difficult to trace for the centralized platforms themselves cause several inconveniences, such as fake jobs, false offers, or improper products. The access control to manipulate the displayed data on centralized platforms is far more liberal as it does not need all validators to validate many times. Also, if no proper notification system is designed on such centralized platforms, users may not even know the change, thereby making the data highly mutable and less reliable.

That's where the blockchain over a public ledger brings full transparency to all its users to trace every data addition or transaction, knowing the source of such additions and approving allowing the data to pass in the first place.

However, let's not mistake transparency for having no privacy. That's another strong aspect of blockchain that involves the encryption of data that's distributed across the ledger (explained in the coming subsections).

Trivia

Name three applications that can be decentralized onto a public ledger.

Proof of Stake

The BBChain on a ship transmits data to the ledger network. However, not all of it is publicly available due to the data's sensitivity and the ownership of the data. Thus, such data is an asset to the ship owner, who is a high-level stakeholder. They can decide to extend their data to the stakeholders they wish to share it with. For example, the ship owner needs to claim insurance for the ship. Here, the ship owner, who has a high stake in the data, can decide to create an internal private ledger in the form a side chain (highlighted in aqua blue in Figure 2-3).

Challenge

Similarly, think how your stock exchange would work over a blockchain.

• Enlist which datapoints go onto the public ledger and private ledger.

• Identify all stakeholders crucial to using this blockchain.

• Identify the operations required on-chain and off-chain.

• Enlist the on-chain operations and define the mandatory principles.

• Draw out the structure, operations, and stakeholders, as in Figures 2-3, 2-4, and 2-5.

BBChain's side chain will share private information across the contracted stakeholders. The contract will be a digital contract that programmatically allows users to agree on certain points, such as the quantity of data, type, price of subscription, and expiry. This internal chain works on proof of stake, as only the ones who have significant stakes can access the chain, contribute data, and view the data and transactions. At the start, the ship owner will have the maximum stake for their ship's data, for obvious reasons, which will be distributed based on the subscriptions through the initial contract to other stakeholders. The ship owner—the block producer—delegates certain stakes to other producers when they contribute in the private chain so they become subscribers that receive private data (such as insurance reports, audits, etc.).

Proof of Importance

After the first two configurations are set up, the proof of importance method is used for the transfer of data across the chain and the priority access, which is based on the cumulative value of transactions on the ledger for that node. This helps to handle high-demand traffic scenarios in the event of interest from several stakeholders at the same time. The nodes may gain importance, or the transaction may gain importance based on the amount of tokens, size of data, and traction of data.

With the blend of these three mechanisms, we formed the BBChain Protocol.

Challenge

Design a consensus mechanism for the following applications:

1. 1.

   Housing Society activities, such as electing members, approval of NOCs (No Objection Certificates), etc.

2. 2.

   Food raw materials ledger with quality control

Shared Ledgers

The traditional centralized cloud-based servers from the last era are everywhere, be it e-commerce platforms or media channels or the television industry. The ads we see and the programs that are hosted have a more centralized, commercial approach.

Trivia

Identify the highly centralized platforms that show dominance on large markets:

• Is highly mutable (can be manipulated by anyone—hackers, jammers, etc.)

• Can be lost due to faults, write failures, and server downtimes

• Vulnerable to data leaks and privacy

• Low access control and is in control of the solution provider

This has led to several conspiracies about lost ships and aircraft.

The concept of BBChain revamps the old-school storage and hosting options with new-age decentralized transparent shared ledgers. The append-only data on the ledgers can be truly trusted as the sole source of truth, be secured, and have a direct connection and reliability with the correct stakeholders.

Let's come back to the same question: Why blockchain? Why decentralize to a shared ledger?

In the olden days, when democracy wasn't fully matured, the dominance of some influential individuals or companies was more prevalent. From getting a telephone line to applying for a visa, things were entirely dependent on centralized authorities. As society progressed, democracy's structure improved among the individuals, and a larger group of people was involved in decision-making, laws and rights, and the way we work.

This era of millennials wouldn't entirely be aware of the pain it took to access certain opportunities before the internet. Now that we are in this digital age where the internet is a common commodity, structuring the software applications we use is important. For example, on a social media platform, where one uploads a photo and chooses to delete it, the data authority of the photo is entirely lost by the individual when he uploads it to this centralized platform (this might get changed with the GDPR Regulations; however, enforcement and checks may be manual). So, with the comparison of the age when we didn't have democracy with the current era, blockchain brings that opportunity to give every identity a voice to structure, vote, and contribute to this digital era. In technical terms, every device becomes an access control touchpoint, every computer becomes a storage point, every user exercises voting rights, and every policy that can be automated across the shared ledger brings in transparency, data decentralization, privacy, security, immutability, and validity of every transaction and action on such platforms. This is what this book envisions educating all its readers about.

Examples of blockchains—i.e., shared ledgers—that are bringing about social impact are as follows:

• UN World Food Programme (WFP) started a program called Building Blocks in 2016, which uses the Ethereum blockchain to make "WFP's growing cash-based transfer operations faster, cheaper, and more secure," according to the project's website. This was piloted to track assistance to Syrian refugees.

• Invested in by the UNICEF Innovations Fund, the blockchain platform Amply and IXO provide transparency for funding transactions for charities helping with South African education.

• The Brooklyn Microgrid is changing the way we choose our electricity source, such as solar yielded at private homes, transmissioned energy, etc., driving an economy that is truly decentralized for production and consumption with direct demand and supply connectivity through a shared ledger.

• M-Vision is a decentralized incubator that runs on blockchains and quantifies remote research efforts and brings them closer to commercialization through the ledger network of researchers, professionals, and industrialists.

Coming back to BBChain, we shared public data, showcased in Figures 2-4 and 2-5, on the shared ledger by using the principles of BigChainDB and Cassandra to store data in a distributed manner.

Here is a storage simulation of financial data in a centralized platform versus decentralization:

• Centralized/Normal Platform:

  X = "Confidential Info: 1 Million USD Transferred to Dr. John Doe"

  • Stored as an encrypted record in a database stored on a single server

• Decentralized Platform/Blockchain:

  Y = Encrypt (X), break X into pieces and store in N number of nodes on the ledger

  • Making it difficult for any fraudulent user or network jammer to decrypt and retrieve X, as first the hacker would require the complete form of the encrypted sentence and then the decryption key, which also may be distributed across the chain.

BBChain distributes and locks data securely on-chain over the shared ledger.

Challenge

From the preceding information, identify which aspect of dominance of an online platform can be restructured on a distributed ledger.

For example , in trade finance, financial institutions are the dominant authorities that can issue the letters of credit and bank guarantees for large-scale import-export activities. The dominance aspect here is for the issuance, which is democratized with the rules and checks defined by the authorities. However, this issuance can have human biases and influences at times, causing defaulters. This aspect of trust and authority when automated over a smart contract on a shared ledger brings a better chance of avoiding trade defaults. So, this challenge asks the readers to identify which part of dominance one wishes to reprogram, and this book will help you construct and program the same.

Encryption

When we log in to a bank portal or a Social Security system, the sense of security and trust is perceived, whereas on open platforms for photo sharing and social media, data is a lot more open than one's bank account details.

Trivia

Spot the top three differences in perceived security between your social media accounts and your digital bank accounts.

Now, where does this link to the aspects of blockchain where we call it transparent, shared, and secure? There are several blockchain platforms for various purposes, like there are several existing online applications for social media as well as financial transactions. The underlying concept that embeds trust on a blockchain is the end-to-end encryption of the data such that the immutable data can only be decrypted when the consensus is formed among the participating nodes. Here, we use Shamir's secret sharing algorithm for distributed split-key management. Different blockchain platforms can engage different mechanisms of key management depending on the criticality of the data. Using split-key management on the distributed ledger makes it difficult for a hacker to hack externally, unless a 51% mining attack (where major nodes/users are fraudulent ones) occurs among the chain stakeholders.

The very famous and the oldest Blockchain Cryptocurrency Bitcoin is a digital currency known as electronic cash where transactions were made across the network nodes cryptographically with SHA256. Each block contains a SHA256 cryptographic hash of the previous block thus linking it to the previous block and giving the blockchain its name. To be accepted by the rest of the network, a new block must contain the Proof of Work. Miners rely on computing the "SHA256 Hash Function" for a lot of inputs until they find the nonce for a given block before adding it to the blockchain.

In Figure 2-4, we saw that the encryption and chunking of the data across the ledger makes it difficult for hackers or external users to retrieve any relevant information.

Let's come back to the topic of social media, where we enjoy social attention from our network of friends and families upon sharing posts, photos, and personal views. When such data is directly uploaded to a server, the network and the server are susceptible to attacks or being accessed by any other unauthorized user knowingly or unknowingly. This can cause data leaks to land in the wrong hands at times.

Now, imagine the scenario of using blockchains for social media. The functionalities would be the same. But how data is stored and managed is different. On a blockchain, the user's node encrypts the data and uploads it to the ledger. Based on the consensus mechanism of that chain, data is tokenized and distributed among stakeholders with whom the user wishes to share. For any node or user to read this data, it must decrypt the entire sequence of distributed data stored across several nodes, making it highly secure and requiring more computations to crack.

There are various techniques of encryption used in distributed ledgers. One can decide based on the application and type of blockchain.

BBChain uses ED25519 for end-to-end encryption, especially for the private ledger side chains where more confidential data is shared. In a hybrid network such as BBChain, where users are on both private and public ledgers, key-sharing mechanisms are used to encrypt and decrypt data that is shared on the blockchain.

Several cryptographic mechanisms , such as the SHA 2 Family, Shamir's Secret Sharing, and EdDSA techniques, are widely used in blockchains. Imagine a user who is acquainted with setting up passwords—how will we enable them to encrypt their data securely on a blockchain? One way could be by using a pre-defined set of encryption rules on the blockchain or giving them the capability to choose their set of encryption techniques. In technical terms, the user on a blockchain may be a node/server dispatching data (to add a block). Thus, the encryption is set on this server where the data is originating through his private key. On-chain users may retrieve data using the public key and further decrypt it using the private key. Such combinations of encryption options are provided by the mechanisms mentioned here.

Challenge

Prepare three encryption packages that may be utilized on your social media data such as photographs, posts, and location.

Tokens

Across centuries, nations, tribes, and humans in general have been attempting to quantify efforts to trade, be it the age-old barter systems or the modern era of financial transactions. The right quantification of time, space, and economies has been volatile throughout.

Bitcoin utilizes the proof of work method, which helps to quantify the value of the token. The computing power to make one transaction across all nodes translates to the value of the Bitcoin by solving the equation. Thus, transacting in this digital currency has enabled trade over such cryptocurrencies.

A cryptocurrency is a digital or virtual currency that uses cryptography for security.

—Investopedia

Several blockchains have successfully quantified the value of the tokens through their ability to scale, operate, and impact in the form of security tokens or utility tokens.

Security tokens are usually the famously listed ICOs, or cryptocurrencies, that receive investments through stakeholders that value the concept and operations of the decentralized blockchain platform.

Utility tokens are the ones that are valued purely for their usage. The usage is quantified with the mechanism of the blockchain, like the value generated by proof of work, as explained earlier.

With BBChain, the utility of the tokens generates the security value. The users of the chain transact with using this utility token on BBChain, to view, subscribe, and buy maritime ship data from other users.

Now the question is, in the world of existing economies of different nations, how does one trust the so-called true value of the chain?

The value of the chain is decided based on the pre-designed nature of the chain, which is based on the consensus and its protocol.

Let's see how BBChain does it.

BBChain Protocol encapsulates a blend of three consensus mechanisms; i.e., Federated Byzantine Agreement (FBA), proof of stake (POS), and proof of importance (POI). The public ledger is governed with FBA. The private ledger is regulated by the POS. POI governs universally across both public and private chains.

Consider N nodes on the public ledger as n1, n2, n3, n4 . . . nN. The movements on the blockchain are drawn with the validations from the quorum intersections for the public data for transactions and decisions, thus using the principle of FBA to form consensus on public ledger activities.

Under the BBChain Protocol, data producers gain stakes in a private chain with the BBChain Genesis Node. Further, these data producers (ship owners, port owners, manufacturers) may subcontract their stakes to other users in this private side chain. Based on the smart contract, stakes are redistributed. While exchanging stakes, the value of the importance of every node and state is recalculated in the private as well as the public chain on the basis of the following:

1. 1.

   Stake value of the nodes at a given time in private ledgers

2. 2.

   Comparative/relative value of stake across all private ledgers

3. 3.

   All-time stake average throughout the year

4. 4.

   Threshold calculation of the vesting amount to become a stake owner

5. 5.

   Threshold calculation for a stake owner to initiate the side ledger

6. 6.

   Threshold calculations for anyone to join a side ledger

7. 7.

   Value of block and number of blocks

8. 8.

   Age of the block and size of group of blocks

9. 9.

   State of block (data traction and freshness)

10. 10.

    Total value of tokens in a chain and the minimum vested value on a node

Data Flow Sequencing

Since the prime element that moves across BBChain is the maritime data, let us understand the flow of data & the impacting factors based on the consensus algorithms & the transactions on chain as per the following sequence:

1. 1.

   On prioritizing transactions, states, and data across the chain, the value of importance is calculated on the preceding factors and will have calculated thresholds for every node to be able to perform some activities.

2. 2.

   This calculation takes precedence for data rendering mainly when we have high concurrency and data congestion in a limited node and hardware/network bandwidth scenario.

3. 3.

   Other actions, such as creating a side ledger, distributing data for subscriptions, and generating data requests for internal (highly private data), require the nodes to cross a certain value of importance to join the consensus (like joining a side ledger).

4. 4.

   Nodes with data that are obsolete (decided by the factor of age of block, e.g., > 5 years, or highly redundant to no traction for a large set of data blocks) can be removed from the chain as a rule under the protocol, with an option to centralize and store.

5. 5.

   Nodes can raise a request from the public ledger to access that data, and high-importance nodes can perform consensus using the FBA mechanism to allow/validate the request.

Decentralized Applications

After understanding all the building blocks of the blockchain, we saw how every fundamental element weaves into an application to form the decentralized ledger to a completely running blockchain. This does not form just a software but also a very powerful ecosystem that can drive economies of this digital age.

Every blockchain signifies a strong aspect of quantification and consensus. There have been several existing distributed databases, ledgers, processes, and systems, so what makes blockchains so crucial and different is the right time, ecosystem, and the ability to monetize the true value system behind the blockchain.

Coming back to BBChain, which brings a highly credible data source to its stakeholders from maritime voyages, the standards set for its value are simply generated by the parameters mentioned in the previous section.

Questions that formulate around such a decentralized application are as follows:

• What is the core digital asset of your chain?

• What are the key stakeholders doing with the digital asset?

• How does one maintain the security of the digital asset?

• How are the contracts and consensus maintained to honor the digital transaction for the asset?

• Which technologies fall in line with the requirements of the blockchain application?

• Is scalability required? How is scalability maintained?

Answers for BBChain are as follows, respectively:

• Voyage data is the key digital asset.

• Stakeholders such as block producers (ship owners, port owners) generate data, whereas insurers and shipping authorities subscribe/buy such data. Data as blocks are transferred in various side chains and on the public ledger.

• As the complete encrypted digital asset (by the public key) is broken down and distributed with a fault-tolerant consensus among different nodes, upon the rightful consensus, the location of the data packet is revealed to the correct stakeholder. On accumulating all the data packets in the right sequence, the decryption will be valid with the use of the private key by the correct stakeholder.

• The rightful stakeholder has a contract in place with the block producer/buyer. On creation of the contract, the public key and the private key are generated based on the expiry of the contract. The key expires along with the contract. The consensus among the private ledger is governed by the proof of stake. This is validated by all the stakeholders of that side chain who shared the distributed data on their servers in encrypted form.

• The architecture supports the technologies required to suit the conditions of the chain (Figure 2-6).

  

  Figure 2-6

  Architecture for BBChain components

• As the voyage data of a ship records every moment of the voyage, scalability is required on the ledger. This is managed by the storage mechanisms provided by BigChainDB and IPFS.

Challenge

Provide your version of answers to the preceding questions as if you were to export goods and transact over a blockchain. Jot down thoughts and compare notes with the use case provided in the upcoming chapters.

Setting Blockchain Environments

By now, we have covered all fundamentals of blockchains, in theory. Now, let's head to the practical implementation to set up a blockchain infrastructure.

For this section, we will deploy a blockchain on the Azure Blockchain Workbench. Think of this as a package suite of infrastructural elements that contribute to building a blockchain, like IKEA assembly instructions for making a bed or a wardrobe. Azure makes the deployment a lot more accelerated, as the infrastructure elements are taken care of in a packaged form. Plus, deployment on cloud makes the connectivity across all nodes/users faster for business processes to connect and collaborate.

Azure Blockchain Workbench provides a set of Azure cloud components, along with the core elements of blockchains, encased in various architecture alternatives in the form of templates. It allows businesses to focus on the purpose and design requirements of the blockchain by supporting the other infrastructure elements out of the box.

1. 1.

   Start with setting up your Azure Account if you don't have one already. One can refer to https://bit.ly/2Gd6TLk to get a detailed walkthrough of the process mentioned here. In this chapter, we focus on the implementation and its usage for our application.

2. 2.

   Once you have signed up and are on the dashboard, click on + Create a resource on the left panel (Figure 2-7).

   

   Figure 2-7

   Showcase of the Azure Marketplace

3. 3.

   Further , search for the Azure Blockchain Workbench, which will help you set up the required number of elements, such as the encryption key vaults, databases, application layers and namespaces (Figure 2-8).

   

   Figure 2-8

   Set up the Azure Blockchain Workbench

4. 4.

   On selection of the Azure Blockchain Workbench, fill in the fields for your use case. We have filled in the following for BBChain (Figure 2-9). This step sets the naming conventions for the resource group and its virtual machines.

   

   Figure 2-9

   Setup of the Azure Blockchain Workbench

5. 5.

   After the basic credentials are defined in the first step, the second step covers the specifications of the devices that are required; for example, the validation node specifications (Figure 2-10).

   

   Figure 2-10

   Setup of the Azure Blockchain Workbench

6. 6.

   Since this is a prototype tutorial to understand the setup process, here we selected a validator node with F1s server with 2GB RAM and 4GB Local SSD (Figure 2-11).

   

   Figure 2-11

   Selection of instances

7. 7.

   Now, check out the summary (Figure 2-12).

   

   Figure 2-12

   Generated summary of the BBChain resource group

8. 8.

   On initiation to buy in step 4, the deployment process to create the list of elements begins. The resource group is generated, and the elements are initialized with the specified choices. This may take some time, as virtual devices are being set up.

9. 9.

   You may receive a notification when the deployment is complete. Alternatively, one can access the same by using the resource group on the sidebar.

10. 10.

    Further, on the resource group screen, select the blockchain name—in my case, BBChain.

11. 11.

    Once the deployment is complete, open the resource group. You will find all server elements and other infrastructure elements are deployed, as shown in Figure 2-13.

    

    Figure 2-13

    Showcases a list of infra elements to build a blockchain template

The resource group has the set of elements shown in Figure 2-14 initiated for use.

Figure 2-14

Azure Event Grid elements

Here are more details:

• One Event Grid Topic

  • In a decentralized platform, where there are multiple users behind different servers, certain event triggers appear based on the smart contract or based on the protocol/consensus mechanism. Thus, Azure provides a utility system as an event grid to manage various event triggers and handlers on the chain. The Event Grid Topic provides an endpoint for the event publisher to create and send event triggers.

  • The subscriber can choose to connect to an Event Grid Topic based on the type of touchpoint.

  • The Event Grid Topic extends its connectivity endpoints to Azure as well as to non-Azure components such that on-chain online and offline elements can subscribe to the event triggers.

  • Think of this as a connector for event triggers and listeners.

• Two virtual network resource groups (each with load balancer, network security group, public IP address, virtual network)

  • Load balancers that assist in load balancing user requests and other event-triggered requests to the servers.

  • Log analytics workspace that maintains the activity logs of all systems.

• App services are for the business application logic and REST-based and Message based API layers

On clicking the first app service shown, it will open the configuration details of the service, where one can find the public URL allotted for the blockchain network. Also, the public URL can be configured to any domain that is required. For the scope of this introduction, we shall access the default link provided.

• App Service Plan is simply a record of all the services that are running, encompassing the app services, which are nothing but services on Linux servers.

• Application Insights for the App Service provides the stats of the service usage, number of user visits, server requests, number of unique users, server response time, etc., as shown in Figure 2-15.

  

  Figure 2-15

  Application Insights dashboard

• One Availability Set

  • An availability set is a logical grouping capability that you can use in Azure to ensure that the VM resources you place within it are isolated from each other when they are deployed within an Azure datacenter.

• Two Availability Tests

  • The test validates the availability of the app services for the app service bb-hofiog-api as shown in Figure 2-16.

  • Here we have two test sets, one for the API app service and the other for the UI layer.

    

    Figure 2-16

    Availability test sets

• Two SQL Databases (Standard S0)

  • These are simply storage servers of 30GiB SSD running on Ubuntu.

• Two Azure Key Vaults for the app services

  • Key vaults, as the name suggests, help to create, store, manage, and comply with FIPS 140-2 Level 2, and enable SSL/TLS certificates. In short, they are a tool to handle most security-related aspects of the app services and other encryption keys. They are a one-stop security center without reinventing the wheel from scratch. The features of the Azure Key Vault provide all mandatory aspects for any enterprise development and production deployment procedures.

  • However, this does not mean that using it will make it secure. The tool has to be correctly configured inside the app services, complying with the encryption standards defined/designed for your blockchain. Azure Key Vault ensures the key is never released out of the vault. We will cover the encryption aspects in detail in the next chapter.

• One Service Bus Namespace

• Two Azure Storage accounts (Standard LRS)

• Two Virtual Machine scale sets (ledger nodes and workbench microservices)

• Optional: Azure Monitor

NAME	TYPE	LOCATION
bb-eg-hofiog	Event Grid Topic	Southeast Asia
bb-hofiog	Application Insights	Southeast Asia
bb-hofiog	Key vault	Southeast Asia
Bb-hofiog, bb-hofiog-api	App Service	Southeast Asia
Bb-lb, ethbb4vow-vlLb-reg1	Load balancer	Southeast Asia
bb-lb-public-ip	Public IP address	Southeast Asia
bb-plan	App Service plan	Southeast Asia
bb-sb-hofiog	Service Bus Namespace	Southeast Asia
bb-subnet-workers-nsg	Network security group	Southeast Asia
Bb-vnet, ethbb4vow-vnet-reg1	Virtual network	Southeast Asia
bb-worker-n	Virtual machine scale set	Southeast Asia
db-hofiog-bb	SQL server	Southeast Asia
hofiog-bb (db-hofiog-bb/hofiog-bb)	SQL database	Southeast Asia
ethbb4vow-akv	Key vault	Southeast Asia
ethbb4vow-lbpip-reg1	Public IP address	Southeast Asia
ethbb4vow-oms	Log Analytics workspace	Southeast Asia
ethbb4vowstore, hofiogbb	Storage account	Southeast Asia
ethbb4vow-vlNsg-reg1	Network security group	Southeast Asia
poaAvailabilitySet-reg1	Availability set	Southeast Asia
Vl-ethbb4vow-reg1-0, vl-ethbb4vow-reg1-1	Virtual machine	Southeast Asia
vl-ethbb4vow-reg1-0_OsDisk_1_d972feafdb584e318578647a023d402c, vl-ethbb4vow-reg1-1_OsDisk_1_40add67153dd4fa8b9a8a18fc30c24b7	Disk	Southeast Asia
vl-nic0-reg1, vl-nic1-reg1	Network interface	Southeast Asia
Website-api-test, website-ui-test	Availability test	Southeast Asia

As you can see in the preceding table, all infrastructure elements are created, configured, and appropriately interlinked for facilitating the blockchain network. Column 1 shows the assigned element name, column 2 provides the type of element, and column 3 mentions the region of the element.

On clicking the public URL provided by the Azure Blockchain Workbench via the app service, one can open the link to see this page (see Figure 2-17).

Figure 2-17

App Service panel

Copy and paste it into PowerShell, and it will ask you to add your Active AD Tenant (Figure 2-18).

Figure 2-18

Powershell commands

I found my Azure AD Tenant here at supportmyraatechnologies.onmicrosoft.com (Figure 2-19).

Figure 2-19

Active Directory

Once the information is entered, it will provide a URL and an OTP to register, as given in Figure 2-20.

Figure 2-20

OTP registration for the device

This step successfully registers the use of PowerShell with my device, thereby creating a relational linkage of my device with the process to initiate the blockchain elements, as shown in Figure 2-21.

Figure 2-21

Processing app registration

On a successful provision, it provides the app service link. Click and allow permission for the app service. This initiates the Azure Blockchain Workbench successfully.

Your app service is set up, as shown on the screen in Figure 2-22.

The environment set up to develop BBChain on a Azure Blockchain Workbench is ready in a couple of clicks.

Figure 2-22

Azure Blockchain Workbench is initialized and deployed

The conventional development for such a complex architecture that has 37 elements would have taken way more time. With Azure's Workbench, setting up the infrastructure elements, configuring them, wiring them, and appropriately linking them with each other is taken care by Azure Workbench.

Note that in advanced stages of learning and implementation, one can go and manually configure the elements whenever required and wire it to a custom domain name.

Challenge

Based on all the examples and challenges in this chapter, pick a blockchain application goal in your mind while initiating the setup. For us it is BBChain, a blockchain ledger to decentralize data distributions across maritime. For the readers, it could be Housing Society blockchains, voting blockchains, or any other decentralization you envision. Implement the preceding steps for your own blockchain project.

How to Design Privacy Into the Internet Using Blockchain

Source: http://devguis.com/2-decoding-a-real-life-blockchain-unlocking-blockchain-on-azure-design-and-develop-decentralized-applications.html

Share this post