This chapter helps to validate the learning curve over Blockchains and enables to design blockchain implementations. Attempt the challenges presented here hands-on to develop your skill. Refer back to the chapters relevant to the question. As the vision of this book is to enable readers from technical as well as non-technical backgrounds to be a part of the blockchain ecosystem, attempting this chapter is one of the validators as well as a catalyst to innovate further.
Terminology
Consensus algorithms
Design challenges
Blockchain or not?
IoT with blockchain
Smart contracts
Mind maps
Remember: These exercises may have more than one correct answer. Also, as this is a field of innovation, the facts may evolve to a different form of existence. However, the fundamentals of decentralization, transparency, encryption, and immutability will remain the same. One may reflect upon the past chapters in different ways on every iteration of study.
Throughout the book, we have examined various use cases across different industries. Before you start the exercises, choose one of the roles and view the challenges from that user’s lens.
For example, if you read this book as a business developer, look at the infrastructure impact around the platform, the kind of people to interact with on-chain, and the policies that will have to be formed off-chain as well as on-chain. The challenges with respect to design will help you identify the right stakeholders to facilitate such a decentralized ecosystem.
If you read as a solution architect, draw out the variables internal to the platform. Analyze the changes in these variables. Focus on the pros and cons of each variable from your standpoint. Identify various technology stack options for every use case and its maturity for each use case.
If you read as a developer, focus on the tangibility of existing solutions with respect to the problem definitions at hand. To ensure building capabilities for better consensus algorithms and smart contracts, practice flow charts of execution, pseudo codes of business conditions, and user stories, and finally form it in the code. This code syntax may evolve from platform to platform; however, the fundamental logic will remain the same.
Attempt these challenges with the focus and vision that you are working for. If you are working in a team comprising a business developer, a solution architect, and a developer, the book encourages you to solve the challenges individually and exchange notes to have a broader understanding from different perspectives and roles.
Solutions are provided at the end of the chapter.
Getting Terminologies and Definitions Right
Crossword 1
Crossword 2
Crossword 3
Crossword 4
Choose the Suitable Form of Consensus
Consensus Mechanisms | Blockchain Platform | Features |
|---|---|---|
1. Proof of Work | a. NEM |
|
2. Proof of Importance | b. EOS |
|
3. Federated Byzantine Agreement | c. Ethereum |
|
4. Delegated Proof of Stake | d. Stellar |
|
Use Case Design Challenge
A farm of one acre is purchased by four friends in the percentage of stake as shown in the pie chart.
They agree to run a farming business together on the land. John does not live close to the land, thereby would not be around to work on it; he wants to rent or sell parts of the land. Tom has a full-time job and will work after his working hours. Ron lives beside the farm, but has no knowledge of farming. Joe is fully available to work on the farm as well and has complete knowledge and experience.
They decide to gain consensus of all involved to make every decision. Therefore, you have to design a blockchain platform for all activities that are going to be conducted on-chain. In the following sections, write the advantages and drawbacks of each type of consensus for its suitability to this situation. List the activities that can work under each type of consensus.
Example Solution
Proof of Work
Land registry and underwritings
Ownership and sectoring of land
Adding users on submission of documents and validation by peers
Request for join budgets and cost claims on upload of receipts such as property tax, electricity, and water
Profit share can be initiated when revenue crosses 2x of investments as per smart contract
On-chain decisions have tamper-proof records of all activities for new users to preview.
Paper trail of all transactions can be found on-chain.
John cannot sell the land to any random user till he has all the conditions of the smart contract fulfilled and validated by peers.
Tom, who works after hours for the farm, does not get profit-share returns until the consensus clause is fulfilled.
Ron wants to expand his courtyard for parties and weddings but cannot do so until validation across the chain is met.
Joe, who works full time, wishes to hire more people on the farm but cannot do so until he gains validation from all.
Now that we have evaluated one form of consensus for this set of activities, list out activities and their suitability to the mentioned form of consensus. Remember, as a part of studying, developing, and forming blockchains, one is free to design as required with the choice best suited to the scenario.
Proof of Stake
Activities using this form of consensus are purely based on the stake of ownership in the unsectored land. It requires the block proposer to gain validation from the high-stake holders through the voting mechanism based on the weight of stakes.
If validator nodes based on their weight form the majority, the block transaction is allowed.
For example:
If
W1 x1 + W2 x2 + W3 x3 + W4 x4 + W5 x5 > 60%
Allow block transaction activities
where weights are proportional to the actual stakes.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Delegated Proof of Stake
This consensus algorithm tries to decentralize further from PoS to enable a fairer voting mechanism. The algorithm delegates and reassigns weights for various activities at random. This can be pre-defined or chosen at random or delegated every cycle by the owner of stake.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Directed Acyclic Graphs (DAG)
In the traditional forms of consensus observed in Bitcoin and Ethereum blockchains, the scalability and the latency time have been of increasing concern with the increase of their popularity and adoption. Therefore Directed Acyclic Graphs , a well-known graph data structure, can provide a method for a common consensus policy to maintain the shared ledger in a acyclic, low-latency, non-mining-dependent, pruned, lightweight-transactions manner on-chain.
Several blockchains generate variants of DAG based on the activity on-chain. For example, if there are 25 retailers on-chain selling different items in different sectors with entirely unique customer profiles, the blockchain ledger could be a DAG, where each transaction entry for every retailer is independent of the other retailers. This could be viewed as a side-chain activity that runs in a silo. However, the data needs to be tamper-proof, locked onto a decentralized chain.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Federated Byzantine Agreement (FBA)
Remember: John is not always online to be involved in all activities for the farm. However, the group wants to ensure fair decisions that are transparent and agreeable to the chain node members. John, being a major stakeholder, becomes a bottleneck validator in the case of other mechanisms of consensus. FBA provides a fault-tolerant method to validate transactions on-chain. Identify the activities that require such a mechanism.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Proof of Importance
Importance could be a metric on-chain over which decisions can be made. For example, a real-time surgery in a hospital might be of higher importance than a dental check-up; therefore the hospital policies for these scenarios are graded accordingly. Similarly, in this use case of farmland, a hazardous situation in the field might require faster decision-making. Or the most active member on-chain might get the authority to validate the transaction. So, this mechanism is not merely limited to the definition by NEM, but may be defined as required.
After defining the activities and node types, analyze the suitable token mechanics to govern the laws of the chain.
Similarly, one can define their own scoring formulae.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Note that the consensus might not be a single mechanism but rather a synergistic design of methods that enforce a common policy across the chain to provide attack resistance and asynchronous race conditions.
Now we have considered different scenarios with different forms of consensus. One can always build a hybrid network of blockchains for different purposes with different types of users. For example, a simple landowner registry might not require consensus validation from every node and may be relevant to just the owner if the land is entirely independent. However, if it is shared land, one can choose to agree on a common consensus for various activities on a traceable ledger of records of every action.
Hybrid Chain
Your task is to fill in the public nodes in the above hybrid chain for the landowner registry use case.
Data and Transactions
Energy Allocation
Energy allocation inside a huge plant of 25 factories requires a blockchain to enable a shared ledger of data to trace electricity requirements.
Now that you have identified the exact case where it is required, identify the peer nodes that are required to be on-chain and off-chain.
Peer nodes may or may not be end users. They can be users, machinery, sensors, and so forth.
Gadgets
Identify five gadgets around you that need to be in consensus to work.
Identify five gadgets around you that need to be in consensus to work for a chemical factory.
Transparent Updates and Fair Trade
Identify a use case where IoT, blockchains, and human interventions can form a decentralized ecosystem of transparent updates and fair trade with smart contracts.
Having understood the design thought process for IoT integrations with blockchain, one can structure the platform with Azure components. Azure provides an array of options to configure the choice of blockchain with its workbench to connect with IoT devices along with other logic apps.
Depending on the design architected, one can decide to invoke the blockchain based on the integrations and the pre-defined conditions. For example, every time the sensor crosses a threshold, the blockchain would want to record it for audit purposes. So, when the sensor data crosses the threshold, the API to the blockchain is called. The DLT services ensure the hashing and generation of blocks is processed on the piece of data and it is added to the blockchain ledger.
However, it must be made clear that for a direct monitoring and alarm system that connects to the IoT, a blockchain may not be required. Therefore the Power BI can directly be connected to the off-chain DB as shown. The purpose of the blockchain ledger would be to maintain immutable records, enable an audit to trace all states of the sensory data, to ensure consensus is maintained in a forwarding system dependent on the sensory data, and so on.
One such example could be oxygen cylinders’ sensor data that may be connected to life support, incubation centers, child care, and so on. With a requirement to maintain such information for hospital audits, such sensor data can be stored on this tamper-proof blockchain ledger, which is linked to a chain of devices. The level of supply can be continuously checked for its state at all nodes.
JSON Preparation
- 1.
Define the user types.
- 2.
Define the states.
- 3.
Draw the processes/steps to the ideal condition.
- 4.
Decide the states on user activity.
Fixing Pain Points
The elements of this supply chain are highly disconnected from each other as far as understanding the supply demand in terms of cost of inventory, stocking, and runout. This is because the communication between all stakeholders is limited and there is zero transparency of the end user’s order. Most of these small-scale entities predict the demand flow in a silo, causing costs when not computed based on the entire chain’s movements.
To understand more, play the game here: https://beergame.masystem.se/
- 1.
Choose stakeholders and roles.
- 2.
Choose the blockchain configuration and linkages.
- 3.
Choose the consensus type.
- 4.
Choose the platform based on Step 3.
- 5.
Measure the scalability requirements.
- 6.
Define the token economics if required.
- 7.
Set up the states and conditions of the smart contracts.
- 8.
Draw the chain view of the consortium blockchain.
So, now that you have learned to choose the correct form of consensus for a real-life scenario, identified off-chain and on-chain activities, and selected the right set of peer nodes, validator nodes, and blockchain configuration in the consortium, let’s see the solutions in the following sections.
Solutions
Crossword 1
Crossword 2
Crossword 3
Crossword 4
Matched Ordering Sequence
1 – C – Chart 4
2 – A – Chart 2
3 – D – Chart 1
4 – B – Chart 3
Proof of Stake Design Challenge
Sale/lease of the land
Addition of new stakeholders
Approval of budget proposals
Allocation of funds
Immovable asset building
Control among high-stake holders
Chance to gather together to form majority even for a small stakeholder
Raise proposal requests on chain transparently
Track fund allocations based on consensus
Transparent investment decisions
Low control for minority voters and stakeholders
Concentrated power by a group of nodes
Rigidity and influence of majority stakeholders
No avenue for decision-making for very low-stake holder groups
Cannot be expanded to other users, third parties who do not have a stake to be a part of any decision-making or services on chain
On studying the yellow paper, one could construct such a blockchain configuration either with the Azure Workbench or simply by utilizing a group of Ubuntu servers on Azure, with emulation of the nodes done through the docker files. Each server may be a node or a group of nodes on the virtual instances inside a server. Once the role allocation of the server allocation is clear, the user can connect the end points of each server to the event register, which can invoke the smart contract on top of it.
Delegated Proof of Stake
Nomination of stake responsibility
Task allocation and ownership
Inclusion of third-party nodes, users, services
Delegation to new farming professionals to work actively on behalf of stake owner
Tenants on farm may be delegated some stake for certain activities
Shared decentralized balanced forms of responsibility
Avenue for low-stake holders to gain delegated stakes for various transactions/activity
Failsafe method to avoid concentration of power based on pre-defined stakes
Inclusion of new nodes can be onboarded based on random consensus of on-chain delegated nodes.
Allows expansion of on-chain activities with decentralization and inclusion
Low energy consumption
Low latency periods
Vulnerable to centralization and biases
Fake consensus by delegated nodes to create false transaction, which may not be in the best interests of the original stakeholder
Exclusion of non-delegated stakeholders
One example of a variant of Proof of Stake is Harmony. Harmony enables an adaptive threshold mechanism for various stake requirements for various activities. Nodes that qualify for the value of stake may participate. Harmony maintains its scalability and decentralization by sharding the network, data, and the states of transaction entirely. The sharding mechanism is non-uniform, scalable, and secure throughout. The consensus combines the Adaptive PoS with FBFT (Fast Byzantine Fault Tolerance), making it fault tolerant, distributed, and able to support high-speed transactions.
Directed Acyclic Graphs (DAG)
- 1.
Daily video feeds of the farms
- 2.
Sensor based IoT feeds
- 3.
Internal micro-transactions between Joe and Ron
- 4.
Localized validations
- 5.
Easily expandable to other nodes external to the core stakeholders for activities such as plumbing, electricity, notarization, etc.
- 6.
Export of farming produce
- 7.
Import and inventory management of seeds, farming material, etc.
- 8.
Third-party integration triggers for security, fire hazards, etc.
- 1.
Validation responsibility is a natural progression by later block producers.
- 2.
Shared ledger information management does not require manual validation every time, thereby allowing IoT data to be appended to the immutable ledger seamlessly.
- 3.
Allows offline status of nodes for transactions that may be irrelevant to someone like John and still maintains records for later awareness for such stakeholders.
- 4.
Allows high-speed data transmission
- 1.
Disconnect from snoozed nodes
- 2.
A one-way street of data ingestion and validation
- 3.
Vulnerable to attacks
- 4.
Prone to centralization
Federated Byzantine Agreement
- 1.
Approval for micro-budget transactions
- 2.
Addition of family nominees or trusted known node users
- 3.
Fixing of maintenance items on-field
- 4.
Upload of bills and receipts
- 5.
Regular activities on-field
- 1.
Highly fault tolerant
- 2.
Enables faster decision-making
- 3.
Allows transactions
- 4.
Allows non-trivial information to be added with curated validation of random nodes
- 1.
Suited only for a certain set of activities that are limited to non-trivial decisions
- 2.
Fault tolerance assumes bypassing crucial node members is fine
Proof of Importance
John, Ron, Tom, and Joe decide to rank all the preceding listed activities and decide that based on the work they do, importance scores will be earned on-chain. For example, John ensured all paperwork regarding the land was perfect and was uploaded on the ledger. So, apart from being a high-stake holder of land, he contributed to crucial activities, incentivizing him on-chain. Similarly, others are enabled to complete tasks and gain importance. However, a high importance score holder can allow the next task assignment. The scores are reviewed every seven days, and the validators shift based on the score. This is the agreement that was locked in under Proof of Importance.
- 1.
Incentivizing employees for contributions and actions
- 2.
Incentivizing third-party entities that interact with this chain
- 3.
Incentivizing a highly active member who works for the farm
- 4.
Linkage of performance to importance
- 1.
Provides an avenue for a low-stake holder like Joe to gain importance as well as value based on his contribution
- 2.
Allows shift of authority based on engagement and involvement
- 1.
Hoarding of power, value generated on chain
- 2.
High dependency on network-driven activities
- 3.
Decentralization may cause complete loss of control in some situations where governance is required.
- 4.
May require revision or a hard fork to change policies
Hybrid Chain
Data and Transactions
Public Chain | Private Chain | ||
|---|---|---|---|
Data | Transaction Activity | Data | Transaction Activity |
General demographics | Pathology lab audits | Detailed blood reports | Doctor patient transactions |
BMI | Hospital inspection checks | Surgery records | Hospital patient transactions |
Anonymous Names | Doctor education and work experience history | Therapy session details | Pharmacy patient transactions |
Area of Diagnostics | Purchase of general medical items | Family history | Insurance claim transactions |
Blood Group | Purchase of medical instruments and quality | X-rays, sonography | Financial transactions |
General Blood Reports | Blood donation | Genetic trace and DNA | |
Doctors Records | Organ donation with anonymous donors | Biometrics | |
Hospital Records | |||
Insurance Certificates | |||
Energy Allocation
Required | Not Required |
|---|---|
When one factory proportionately increases or decreases consumption for other 24 based on its operations. | When 25 factories have no dependency on each other over electricity consumption. |
When Smart Meters are everywhere and data can be integrated seamlessly | When this data is populated purely by manual intervention and meter readings |
When this data affects the costs of the produce, must be highly sensitive. | When this data does not affect overall operations and the requirements are highly stable every year. |
On-Chain Entities | Off-Chain Entities |
|---|---|
Records of electricity consumption data from Smart Meters | Aggregation of one-time data of machinery that are not connected to the main line, but use batteries |
Operation managers, which manage the electricity usage | Forecast of further electricity consumption |
Bill invoices to 25 factories | M&A of factories |
Disbursement and payments of bills | Faulty meter checks |
Transfer of stakeholders |
Gadgets
Transparent Updates and Fair Trade
Consider a scenario where organs for transplant have to be transported. The hospital patient who subscribes to the service as well as the doctor gets to see the quality of the transfer throughout the transport.
This private chain has a bound smart contract that has all conditions of a proper transplant requirement. If the IOT nodes satisfy, it finally requires the doctor’s on-chain signature along with the patient’s multi-sign on the acknowledgment. This permissioned chain enables a transparent process that may be tamper-proof on a decentralized system. Therefore, blockchains here make ideal sense.
JSON Preparation
State Diagram
Fixing Pain Points
The solution is open to numerous alternatives; left to the reader’s interpretation.
References to our version of implementation can be derived from the previous chapters, such as the BBChain View.