CHAPTER 4

Protocols and Concepts to Watch for

Protocols are rules and procedures that a system operates on. Networked systems are built on protocols that are agreed on by the participants as a precursor to participate. In the early days of blockchain, protocols meant consensus mechanisms—the rules and algorithms by which transactions were added in a block and how blocks were mined. Over the last few years, the definition of protocol has expanded to include privacy, smart contracts, interoperability, tokenization, and many more. These protocols manifested from the early days of blockchain to expand the use case of blockchain from financial transfer to other types of value transfers.

Protocols are the foundations of blockchain use cases. Hence, it is important for practitioners to keep an eye on revisions of existing protocols and emergence of new ones that might impact the systems you are attempting to build. Development of protocols is dynamic. In Ethereum and other public blockchain ecosystem, anybody can submit proposals to improve one or more underlying protocols. Such openness fosters rapid development, testing, and release of protocols. Nonetheless, I’ve briefly explained a few protocols and concepts that I think have significant importance in the adoption of blockchain technology in the future.

Zero-Knowledge Proofs

In our daily analog lives, when somebody asks you, “Are you a citizen or are you eligible to drive?” we whip out a passport or a driver’s license. Although the person was only verifying your citizenship, you disclose more information than required—passport number, date of birth, etc. Zero-knowledge proof (ZKP) is a mathematical construct to prove to a verifier that a piece of information is correct without revealing details within the information.

Wikipedia has a great definition of ZKP:

“Zero-knowledge proof, or zero-knowledge protocol, is a method by which one party (the prover) can prove to another party (the verifier) that they know the value of x, without conveying any information apart from the fact that they know the value of x. The essence of zero-knowledge proofs is that it’s trivial to prove one possesses knowledge of certain information by simply revealing it; the challenge is to prove such possession without revealing the information itself or any additional information.”

We will not go into the details of the mathematical proof, which is quite complicated; however, zero-knowledge proofs have existed for over 20 years.

Here’s a simple illustration of the concept.1 Alice and Bob want to know if both are earning equal hourly wages without disclosing the actual amount. For simplicity, let’s assume they are making $10, $20, $30, or $40 per hour.

1. Bob gets four lockable boxes and puts a label in each that says $10, $20, $30, and $40. All the boxes have separate keys.

2. Then Bob throws away all the keys except for the key to the box labeled $20.00 per hour (because he is making $20.00 per hour) and leaves with the key. When Alice sees the boxes later, she doesn’t know which key Bob has with him.

3. Bob gives the locked boxes to Alice that have slits to insert pieces of paper. In private, Alice takes four small pieces of paper and writes “yes” on one of them and “no” on the others.

4. Remember, both are using the same set of boxes.

5. Alice slips paper with “yes” into the box labeled $30.00 per hour, because she makes $30.00 per hour, and slips the pieces of paper with “no” into the rest of the boxes and leaves. When Bob returns later, he doesn’t know which box Alice slipped the pieces of paper into.

6. Bob returns and opens the one box he still has the key to — the one that is labeled $20.00 per hour— and sees the piece of paper with “no” written on it.

7. If it had been a “yes,” it would mean Alice makes the same wage as Bob. Because the slip of paper says “no,” it means that they have different wages.

8. We know that Bob makes $20.00 per hour and Alice makes $30.00 per hour. By opening the box and finding the piece of paper with a “no” on it, Bob learns that he and Alice have different wages, but he has no way of finding out the exact amount Alice makes. Alice may be making $10, $20, or $40 per hour.

9. Bob can show the piece of paper with “no” to Alice, and thus she will also know that their wages are different without disclosing the actual amount.

ZKP has evolved into zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK) in the blockchain space to provide privacy and confidentiality of transactions in open blockchain. An algorithmic description of zk-SNARKs is provided here.2 The most prominent blockchain-based systems using ZKPs are ZCash and Monero.3

In an open blockchain, when an asset is sent from one party to another, the details of that transaction are visible to every other party in the network. In such cases, zk-SNARKs can be used to prove that transactions are valid without revealing information about the sender, the receiver, and other details that can be stored off-chain. In verticals such as finance and trade finance, lack of privacy and confidentiality can be undesirable for end users.

Zk-SNARKs are also used in smart contracts4 and can be used to prove that necessary steps or actions have been taken in the smart contract without revealing what they are. For example, smart contracts that release payment after proof of delivery or ownership transfer don’t need to record details of proof of delivery in situations where confidentiality of such information is desired.

Instead of publishing the actual data on the blockchain, we can record mathematical proofs on the blockchain and prove to the smart contract that our transaction respects the business rules of the ecosystem without revealing the actual content of the transaction.5 In our use case, we can change custody of an asset by sending a confidential message to another party. The party can then verify that the sender of the message is the actual custodian of the asset, using mathematical proof on the blockchain, as shown in Figure 4.1.

Figure 4.1 Users interact with blockchain using zk-SNARK protocols

If the proof is verified, the trading partner can complete the transfer by proving to the blockchain that he or she is the intended recipient of the transfer. That person is now the only custodian of the serial number with the ability to generate a mathematical proof to demonstrate the new custody state and designate another trading partner to take ownership.

The zk-SNARK concept is also useful in tracking provenance of transactions between multiple parties without disclosing the entirety of those transactions. This is beneficial in moving high-value goods in complex supply chains such as pharmaceutical and ocean cargo movement. As physical goods and digital information about the goods move between stakeholders in the supply chain via smart contracts, confirmation of transactions and custody of goods can be proven to other parties without revealing the detailed information about the goods. This helps parties to maintain the confidentiality of information in public blockchain.

Identity to Interact with Blockchain Applications

A private key is a randomly generated 32-byte number that is unique to a user and should never be shared with others. A private key is used to generate a public key. A public address is a hashed version of the public key. Public addresses are like our bank account information. We provide public addresses to other parties to send or receive cryptocurrencies and other relevant data.

In public blockchain, there are no usernames or passwords. Identity is simply to create your own private/public key and use those key pairs to authenticate transactions in the smart contract or cryptocurrency transfer. Government-issued identities are not required to send bitcoins or Ether, or to interact with smart contracts on the Ethereum network or other public blockchain infrastructure. The combination of private and public keys is enough for blockchain nodes to verify transactions as described in the earlier chapter. When users are not required to show government-issued identifications, they can use applications like MetaMask or uPort to create private and public keys to interact with smart contracts and dApps.

For dApps and other applications that need government-issued identity verification, third-party decentralized identity solutions are available. Examples include ShoCard, Civic, BitID, and ID.me. These services perform identity proofing of users on the basis of existing trusted credentials, such as a passport or driver’s license. The service will then record identity attestations on a blockchain for later validation by identity requesters, preventing direct storage of government-issued identity by the dApp and application developers. The concept of “self-sovereign identity” is getting much attention because of the spread of private information leaks.

Three kinds of identity architectures exist today:

Centralized Trusted Identity—A traditional identity model by which an identity is owned and controlled by an application provider. Users rely on the provider to create and manage identities with the possibility that their identities can be taken away. In the case of Federated Identity, applications can use single sign-on procedures provided by Google, Facebook, LinkedIn, for example.

Self-sovereign Identity—An identity that is owned and controlled by its owner, or user, without the need to rely on external administrative authority or the possibility that this identity can be taken away. Self-sovereign identity can be enabled by a decentralized identity ecosystem that facilitates the recording and exchange of identity attributes as well as the propagation of trust among participating entities. Examples include Sovrin, uPort, and OneName, to name a few. Self-sovereign identity is like the current model of transacting on Ethereum or Bitcoin, in which anyone can create a public and private key without attestation or revoking authority from a centralized institution.

In general, self-sovereign identity works by anchoring identity, issued by government or other agencies, into a public blockchain. The issuer, in this case the government, submits a claim that an identity for the user exists. The user holds the identity, like a card without personally identifiable information, and countersigns the claim using blockchain. A verifier simply needs to check the existence of the claim in the public blockchain. The verifier, in this case, can be a website. Using the identity anchored in blockchain, users can register or sign in on websites without adding personal information such as date of birth, social security number, or age verification.

Decentralized Trusted Identity—An identity that is provided by a centralized service, performing identity proofing of users based on existing trusted credentials, such as a passport or driver’s license, and records identity attestations on a blockchain for later validation by third parties. Figure 4.2 shows a flow of data requests in this identity model that leverages identity provided by trusted entities such as governments.

Figure 4.2 Decentralized trusted identity that leverages government-issued identity

Examples include ShoCard, CIVIC, BitID, ID.me, and IDchainZ. Decentralized trusted identity is a compromise between the traditional model and the self-sovereign model with a specific realization. Self-sovereign identity is unsuitable for applications that need attestation of government-issued identity, but it does allow the user to create boundaries regarding who uses the identity and in what manner. Decentralized trusted identity is used to prove relationships between individuals within varying companies.

Companies like ShoCard provide a trusted identity that leverages blockchain to bind a user identifier, an existing trusted credential such as a passport or driver’s license, and additional identity attributes together via cryptographic hashes stored in blockchain. The technique uses public blockchain, like Bitcoin, as a time-stamping service for signing cryptographic hashes of the user’s government-provided or employer-provided identity information. The provider, ShoCard, incorporates a central server as an essential part of its scheme that intermediates the exchange of encrypted identity information between a user and a relying party.

Decentralized trusted identity is a compromise between the traditional model, usernames and passwords, and public and private key identity. Public and private key pairs used as an identity are not suitable for applications that require attestation of government-issued identity. Decentralized trusted identity is also used to prove relationships between individuals with companies. Only those individuals can log into applications. It will also fulfill Know Your Customer (KYC) requirements, because trusted credentials are part of the identity.

Stable Cryptocurrencies

Cryptocurrencies are notoriously volatile, at least for the time being. Analyzing reasons for volatility is not within the scope of this book. Businesses desiring to transact in cryptocurrencies run the risk of instant price appreciation or depreciation during the time invoices are received and settled. The only way around this is to settle those transactions immediately and convert to much more stable currency.

Volatility puts a significant burden on businesses to report price appreciation and subject to capital gains taxes or depreciation and report losses in the United States and other countries. When businesses settle invoices or purchases instantly, the risk of volatility may not be that high. However, many other businesses settle invoices in weeks or even months. In that situation, both receivers and payers will be faced with the predicament of not knowing how much they will pay or receive.

Stable coins work around the volatility issue and are designed to be stable by pegging to local fiat currency. Stable coins are simply cryptocurrencies with stable value. The general theory is that fiat currencies fluctuate less than cryptocurrencies and hence pegged stable coins may have more traction among businesses and even individuals who seek stable payment mechanisms. They share most of the features that make Bitcoin and other cryptocurrencies so appealing, yet don’t suffer from the same volatility, making them more usable as a medium of exchange and account.6 According to a report titled “State of Stable Coins,” there are 23 stable coins in circulation at the time of this writing.7 Stable coins generally fall within these three categories8:

Off-chain asset backed—In this model, tokens are “backed” by local fiat in reserve based on 1 to 1 issuance. Stable coin issuers must demonstrate to the public through audits or attestations that they do have adequate collateral amount, in this case fiat, in reserve to guarantee that every token issued is backed by the same amount of fiat. This model is easy to understand for consumers. However, the issuer needs to hold very large, auditable amounts in reserve and to find ways to generate revenue instead of letting it sit in a bank account.

Crypto-asset backed—Tokens are minted in smart contracts by locking high-value cryptocurrencies such as Ether and Bitcoin as collaterals. Users then receive the stable coin as a loan. Once the loan is paid off, the locked cryptocurrency is released back to the user. To de-risk against volatility of cryptocurrencies, stable coins are often overcollateralized when borrowing loans. The price of a stable coin is algorithmically, and to some extent manually, adjusted by the market’s supply and demand of the stable coin. Most stable coin projects in this category are currently built on top of the public Ethereum network.9

Algorithmic central bank or seigniorage shares—Using smart contracts, tokens are automatically issued on the basis of their peg with fiat. Like a central bank, the smart contract issues new tokens if the price of the stable coin is high and burns if the price is too low. This type of stable coin is not common; one of the reasons for this may be that it also involves issuance of bonds that are deemed securities in many jurisdictions.

Stable coins have yet to be ubiquitous in small business transactions and yet to step into large financial transactions such as trade finance and cross-border payments. I believe this is because of several hindrances—regulatory and tax issues, user experience, and liquidity markets.

Protocols to Implement NFTs

We talked about nonfungible assets in the earlier chapter—physical assets, invoices, music rights, and so forth. Among the many innovative, and perhaps game-changing, benefits of blockchain is the creation of digital tokens representing physical assets. These tokens are called nonfungible tokens (NFT), which are unique representations of an asset in the form of a token. Once a digital representation of an asset is created and recorded in blockchain, the token holder can sell and transfer the asset on blockchain to anyone else and, in that process, digitally splice the asset into multiple pieces.

ERC-721 is a free, open standard that defines the minimum interface a smart contract must implement to allow unique tokens to be managed, owned, and traded. It does not mandate a standard for token metadata or restrict adding supplemental functions. ERC-721 describes how to build nonfungible or unique tokens on the Ethereum blockchain. Since each ERC-721 token is unique,10 they are referenced on the blockchain by a unique identification.

The protocol allows on-chain registries to store immutable provenance of asset ownership in case the asset is transferred to another owner(s). The holder of an asset on blockchain is provided a way to prove that the asset belongs to the token holder using private and public keys. An asset’s attributes may be stored in an off-chain database to preserve confidentiality. When an asset is transferred owing to liquidity, the blockchain records the transfer, the token owned by the debtor is destroyed in the smart contract, and a new token is created and provided to a creditor.

I’ll talk about ERC-721 protocol in more detail in Chapter 8 when discussing tokenization of nonfungible assets.

ERC-998 is an extension to the ERC-721 standard that adds the ability for NFTs to own other NFTs and ERC-20 tokens.11 The protocol allows for the creation of composable NFTs. ERC-721 is used to refer to the “parent” asset, while its composable “children” assets will refer to the ERC-721 or the ERC-20 tokens owned by them.12 The standard also allows for strict mapping of the relationship between parent and child tokens, as shown in Figure 4.3. Child tokens are only able to be transferred from the contract if the sender also owns the parent token identification.

Figure 4.3 Parent nonfungible token represented by child tokens

Source: Recreated from Lockeyer and Mudge.13

Layer 2 Protocols and Scalability

Consider the following thought for a moment. Can people use 18-wheeler trucks to deliver a small parcel? Sure, but it is not cost effective. Eighteen-wheelers are designed to carry large parcels, or pallets, which are then broken down into small parcels at a warehouse. From there, those small pallets are carried by a motorbike or a small van and delivered to your home. Layer 2 solutions are like small vans. Can you imagine 18-wheelers delivering small parcels everywhere? It would be slow, clunky, and expensive. That business model would not scale.

The main purpose of Layer 2 solutions is to scale blockchain transaction capacity. Sending microtransactions using Bitcoin or Ethereum’s main blockchain is slow, clunky, and expensive. Hence, such transactions are exchanged within the upper layer without directly issuing transactions on the main chain, otherwise known as Layer 1.

One example of Layer 2 is the Lightning Network solution built on top of Bitcoin.14 The general idea is that if you must make small payments with another party, both parties agree to create a multiparty address using a smart contract, opening a channel between both parties. Parties transact using this smart contract and close the channel whenever they wish. Individual payments in the channel are not sent to the Bitcoin blockchain for confirmations. Only the final balance is then broadcast to the main network, or Layer 1.

Because individual transactions do not need block confirmations, transactions are quick. Hence, Lightning Network can be used at retail point-of-sale terminals, with user device-to-device transactions, or anywhere instant payments are needed. Since January 2018, the number of channels has grown from 0 to 24,000, and capacity has increased to over 600 Bitcoin.15

Neha Narula, of Massachusetts Institute of Technology, says, “A defining feature of Layer 2 is that computation is moved off-chain, either to enable privacy or to save computing resources.16 Rather than having the script of a program executed by every computer in the blockchain network, “[i]t is implemented simply by two or more computers involved in the transaction.” Ms. Narula further says, “You get similar security protections to on-chain transactions because the blockchain acts as the anchor of trust.”

Another example is a concept called sidechains, where a separate blockchain, with a “bridge” to Layer 1, transfers assets back and forth between the two layers. Figure 4.4 shows Layer 2 blockchain writing blocks of hashed transactions to Bitcoin’s blockchain. Block headers, hash, from the sidechain’s blockchain are periodically sent to Layer 1 to leverage the security of the Layer 1 blockchain.

Figure 4.4 Layer 2 blockchain or sidechain adding hashed transactions to Bitcoin blockchain

Sidechains were first proposed by Back in an article titled “Enabling Blockchain Innovations with Pegged Sidechains.”17 In their article, pegged sidechains are defined as a technology that enables Bitcoin and other assets to be transferred between multiple blockchains.

Create a transaction on the first blockchain, or parent chain, locking the assets. Create a transaction on the second blockchain, or sidechain, whose inputs contain a cryptographic proof that the lock was done correctly. A corresponding amount of coins is released on the sidechain. The user is then able to spend the coins on the sidechain. When moving the asset from the sidechain to the parent chain, the user sends the coins from the sidechain to an output address, where they are locked.

In business applications, storing transactions on the main layer might be slow and expensive. Assuming the sidechain is relatively faster than Layer 1, using the upper layer for smart contracts and transactions makes operational sense. Using Bitcoin or Ethereum to store hash from Layer 2 provides additional security and saves on Layer 1 transaction fees.

A sidechain is a separate blockchain that is attached to its parent blockchain using a two-way peg.18 The two-way peg enables interchangeability of assets at a predetermined rate between the parent blockchain and the sidechain. Two-way peg refers to the mechanism by which coins are transferred between the sidechain and the parent chain and back at a fixed or otherwise deterministic exchange rate.

An obvious benefit of sidechains is to create innovative asset classes on a separate blockchain that uses a more secure parent chain such as Bitcoin or Ethereum to maintain security of assets. Sidechains are independent of parent chains in terms of blockchain operation.

Smart Contracts are Judges; Oracles are Attorneys

Smart contracts were designed to be lightweight, computationally speaking, so that transactions can be confirmed quickly without putting a heavy burden on the blockchain infrastructure. The best use of smart contracts is to transfer assets and currencies between counterparty addresses if certain conditions hold true.

Transferring balances between counterparties is easy. The tricky part comes with verifying whether the condition triggering the balance transfer is reliable or not. Oracles are external programs that provide real-world conditional data as input into a smart contract. Examples of external data include current temperature, price of gold in mercantile exchange at 9:00AM CST, proof of payment, and proof of delivery.

It is important to note that oracles are not the source of such data. They are merely the vehicles that provide data to smart contracts. Figure 4.5 shows oracle service in between external data sources (e.g., market information, websites) and smart contracts. The burden of computation to acquire data is on the oracles and not on the smart contract itself.

Figure 4.5 Oracle services provide inputs to smart contracts from external sources

When smart contracts first appeared, their inability to connect to outside information sources such as URLs and data sources quickly became an issue for their practical application.

The issue was aptly labeled “Oracle problem.” In theory, the reliance of smart contracts on centralized data sources seems counterintuitive.19 However, in practice, we must rely on outside sources. It’s a bit difficult to imagine that every data source will be validated by multiple independent entities. So is the oracle problem really a problem?20

Nonetheless, let’s talk about a major issue with oracle utilization, which is ensuring the reliability of the data source. It can be solved using decentralized oracles, in which multiple nodes arrive at consensus independently. For example, a majority among 10 nodes independently verify that the current temperature in Alaska is 60 degrees Fahrenheit. If we label these nodes as “independent validators,” a small number can collude to deliberately falsify data entering smart contracts.

Business operations receive data from sources that are private and are publicly unavailable for multiple nodes and independent entities to validate; for example, truck telematics position, field sensor information, and patient health information. One way to ensure tamperproofing is by the sending device signing the data with a private/public key. The data is then verified by the smart contract or the oracle using the sender’s public key.

Cross-Chain Interoperability

A lot of buzz has surfaced around the need for blockchain interoperability to help serve different industries. Industries such as logistics and supply chain will use a wide array of applications built on open, enterprise blockchain to trade, share, and swap assets. In an interoperable world, users in multiple blockchains can transfer and verify information about assets with little effort.

The value proposition for interoperability between blockchains is clear and significant. It will lower the entry cost to develop applications compatible between systems to the benefit of end users. Let’s look at use cases that blockchain interoperability should support as well as potential strategies. By no means is this an exhaustive list of use cases and solutions.

Use Case 1—Trading or swapping assets between different blockchains

Alice has X asset in Blockchain A and Bob has Y asset in Blockchain B. If they want to swap each other’s asset, then both Alice and Bob must use a trusted intermediary or a notary. If both Blockchain A and B were interoperable, Alice and Bob would be able to trade each other’s assets (a process known as a cross-chain swap) without a trusted intermediary. Swapping assets, especially tokens across chains, requires using the in-house ledger of centralized exchanges and then withdrawing the new token on a new chain. This process is expensive because both Alice and Bob will have to pay transaction fees to the intermediary. Swapping and trading assets is common in bulk logistics and maritime. The ownership of shipments on the way from New York to Hamburg may be traded and swapped many times. If we are to disrupt the industry by tokenizing physical assets on smart contracts, then interoperability is critical for frictionless trading and liquidity.

Use Case 2—Communication between blockchains to verify each other’s transactions

Alice has ownership of a container full of auto parts. The ownership is registered in a private blockchain application (it can be public as well.) The container is transported and delivered to Bob, who is an auto manufacturer. Alice registers Bob as the new owner of the container. Bob’s blockchain needs to verify that Alice’s blockchain has confirmed that the container ownership has been changed to him. Alice’s blockchain needs to do the same on her end. An auto manufacturer like Bob receives parts and orders from hundreds of suppliers spread across the globe. How realistic is it to think that Bob and all his suppliers, who may also supply to other manufacturers, will be on the same blockchain that Alice uses?

Vitalik Buterin, in “Chain Interoperability,” mentioned two other use cases that garnered attention because of their usability in the supply chain. They are combined and summarized next as Use Case 3.

Use Case 3—Portability and encumbrance of invoices

Alice, the carrier, has an invoice anchored in Ethereum and wants to borrow against it from a bank. The bank agrees to provide finance against the invoice, but its smart contract that is in a different blockchain needs to lock the invoice in Ethereum so that Alice doesn’t go to another bank with the same invoice and double spend it. If not utilized on another chain, then the asset can be moved back to the original chain. Also, the asset in the original chain can be locked by another chain to finance it as a collateral. Multiple parties “sharing” a blockchain would reduce the likelihood of fraud in invoices and other trade documents.

Trusted notary mechanism—One obvious solution is to utilize a trusted intermediary that listens to events such as Alice and Bob’s transactions in both or multiple blockchains, providing digital signature of proofs that those transactions have taken place. Mr. Buterin calls it a “notary mechanism.” An obvious flaw, or rather shortcoming, in this approach is the centralized intermediary, which can be improved by creating a decentralized exchange, which would then become a custodian to maintain a proof that an asset transfer has taken place.

Hash lock time contracts—Hash lock time contracts do not require knowledge of what’s happening in the counterparty’s blockchain. These contracts remove the requirement of notaries and transfer tokens after a condition encoded in the smart contract is satisfied. Hash lock time contracts are enforced by the blockchain where the parties transacting only need to trust the blockchain to correctly execute the contract. It also works well in a payment channel environment. The simplest description of hash lock time contract, as described by Mr. Buterin in “Chain Interoperability” is as follows:

1. Alice generates a random secret, s, and computes the hash of the secret, hash(s) = h. Alice sends the hash, h, to Bob.

2. Alice and Bob both lock their assets into a smart contract with the following rules. First off, Alice locks first, Bob locks after seeing Alice’s asset successfully locked. On Alice's side, if the secret is provided within a certain time frame, then the token is transferred to Bob; otherwise, it is sent back to Alice. On Bob’s side, if the correct secret, or the value whose hash is h, is provided, then the token is transferred to Alice; otherwise, it is sent back to Bob.

3. Alice reveals the secret to claim the token from Bob’s contract. However, this ensures that Bob learns the secret, allowing him to claim the asset from Alice’s smart contract.

Cross-chain message relay—Instead of relying on a trusted intermediary to pass information between the two blockchains, one of the blockchains, let’s say Blockchain A, takes the block header of Blockchain B to verify transactions and confirm an event or state in Blockchain A. However, this is more nuanced than it sounds, because both blockchains need to use a similar consensus mechanism and structure of ledger. Fahad Shah described cross-chain messaging as basically a query of belief.21 Mr. Shah questioned how one can design a system to relay messages between blockchains in a situation where one of the chains may be an orphan or forked. It is also conceivable that a message being sent is from a forked or orphan chain.

There are at least a dozen projects in this space attacking the problem of interoperability from multiple angles. For example, Cosmos Network is a project that is creating a hub that connects independent blockchains, called zones.22 Interoperability standards between blockchains will be a long and grueling game because, at present, the market’s focus is to increase the adoption of blockchain applications. However, in the absence of clear interoperable solutions and standards, innovations in interorganizational tokenization, asset trading, and invoice financing will hit a brick wall.

Game-Theoretic Network Incentives

Game theory is the systematic study of strategic interactions among rational individuals. It is the process of modeling strategic interactions between two or more players in a situation containing a set of rules and outcomes.23 Game theory is used in several disciplines but most notably as a tool within the study of economics. Most of us know game theory from the movie Beautiful Mind, which portrays the life and discoveries of mathematician John Nash, played by Russell Crowe.

Use of game theory in the context of blockchain is quite interesting in that all the classical components in a game are available in blockchain, especially open and permissionless blockchain. Miners play the following key roles in blockchain:

Miners are the players who participate in the game. They are also strategic decision makers in validating transactions and creating a correct chain.

Miners use multiple computational strategies, such as acquisition of hash power and automation to mine one crypto versus another based on market prices and difficulty rates.

Miners are awarded with a diminishing rate of coins for their efforts in validating transactions and adding them to a block.

At a given point in time, miners are presented with the current state of blocks, difficulty, coin market prices, and the new block being proposed because of new transactions.

The resulting blockchain is always the longest chain with valid transactions. Underlying protocol and economic incentives encourage miners to stay within the boundaries of the protocol. Steep costs are involved if one attempts to tamper with transactions such as failure to receive block rewards.

Mathew Finestone wrote in Game Theory and Blockchain, “The goal of game theory for cryptocurrency is to model human reasoning to build networks that need no oversight yet have positive outcomes for the greater good. Unfortunately, planning for unpredictable human decisions first requires that we understand what motivates people, which is easier said than done.”24 In open blockchain, finding what motivates people is difficult to predict.

Hopefully, all the miners are economically motivated to keep the mining operation running. However, price collapse of the cryptocurrency may negatively challenge the motivation. We’ve also seen cases where certain groups of miners refused to participate in a hard fork (references) or other cases where they forced hard forks owing to disagreements in long-term sustainability of the cryptocurrency.

Miners have a lot of power in the blockchain system, and if they do choose to cheat for their own personal gain, they can force the community to choose a different chain. To mitigate that, the blockchain uses game theory mechanics to keep the system sustainable in the sense that it is difficult for a single miner to force a new chain, even if the miner possesses over 51 percent hash power.

Mr. Buterin wrote in a Medium post, “… Because proof of work security can only come from block rewards, and incentives to miners can only come from the risk of them losing their future block rewards, proof of work necessarily operates on the logic of massive power incentivized into existence by massive rewards.”25 However, one specific concern has been concentration of hash power among a handful of mining pools. At the time of this writing, four of the largest mining pools control over 50 percent of the total hash power in Bitcoin, 3 pools in the case of Ethereum.26

Mr. Buterin further wrote, “Proof of stake breaks this symmetry by relying not on rewards for security, but rather penalties.” In a future version of Ethereum integrating proof of stake, validators, instead of miners, hold funds as stake and are rewarded for locking up their capital and maintaining nodes. Hence, in comparison with proof of work type consensus, security is achieved by penalizing validators rather than relying on block rewards distributed to miners.

Other blockchain protocols, such as EOS, use a Delegated Proof of Stake consensus mechanism by allowing users to vote on delegates, or block producers. Delegates are the trusted parties responsible for maintaining the network. There are a handful of such producers, and rumors of collusion between producers surfaced in October 2018, rattling the EOS community.27 Even before that, “centralization” and overreach of block producers to freeze accounts of users has been thrown into question.28

_______________

1 C. Gidney. May 7, 2013. “Explain it like I’m Five: The Socialist Millionaire Problem and Secure Multi-Party Computation,” TwistedOakStudios. http://twistedoakstudios.com/blog/Post3724_explain-it-like-im-five-the-socialist-millionaire-problem-and-secure-multi-party-computation.

2 C. Lundkvist. March 27, 2017. “Introduction to zk-SNARKs with Examples,” Medium Corporation. https://media.consensys.net/introduction-to-zksnarks-with-examples-.

3 B. Curran. September 10, 2018. “What Are Zero-Knowledge Proofs? Complete Beginner’s Guide,” Blockonomi. https://blockonomi.com/zero-knowledge-proofs/.

4 S. Wurfel. September 6, 2018. “Zk-SNARKs Explained – Introduction to Privacy Protocol,” CaptainAltCoin. https://captainaltcoin.com/zk-snarks-privacy/.

5 M. Greco. April 10, 2018. “Does Proof of Existence Establish Provenance?”, Medium Corporation. https://blog.chronicled.com/does-proof-of-existence-establish-provenance-5028fbd8c6da.

6 K. Samani. January 17, 2018. “An Overview of Stable Coins,” Multicoin Capital. https://multicoin.capital/2018/01/17/an-overview-of-stablecoins/.

7 “State of Stable Coins,” Blockchain.com. https://www.blockchain.com/ru/static/pdf/StablecoinsReportFinal.pdf, (accessed December 20, 2019).

8 B. Memon. “Guide to Stable Coin: Types of Stable Coins and Its Importance,” Masterthecrypto. https://masterthecrypto.com/guide-to-stablecoin-types-of-stablecoins/, (accessed November 21, 2018).

9 Price Waters Cooper. October 2018. “Stable Coin Evolution and Market Trends,” Price Waters Cooper. https://www.pwc.com.au/pdf/stable-coin-evolution-and-market-trends.pdf.

10 “ERC-721,” http://erc721.org, (accessed December 22, 2018).

11 “Composable Non-Fungible Token Standard,” http://erc998.org, (accessed December 19, 2019).

12 M. Lockyer. April 14, 2018. “Introducing Crypto Composables,” Medium Corporation. https://medium.com/coinmonks/introducing-crypto-composables-ee5701fde217.

13 M. Luckeyer and N. Mudge. April 15, 2018. “ERC-998 Composable Non-Fungible Token Standard #998,” GitHub. https://github.com/ethereum/eips/issues/998.

14 “Lightning Network: Scalable, Instant Bitcoin/Blockchain Transactions,” Lightning Network, https://lightning.network, (accessed January 11, 2019).

15 “Real-Time Lightning Network Statistics,” https://1ml.com/statistics.

16 M. Casey. May 30, 2018. “Layer 2 Blockchain Tech Is an Even Bigger Deal Than You Think,” CoinDesk. https://www.coindesk.com/layer-2-blockchain-tech-even-bigger-deal-think.

17 A. Back. October 22, 2014. “Blockchain Innovations with Pegged Sidechains,” Blockstream. https://blockstream.com/sidechains.pdf.

18 S. Ray. January 22, 2018. “What are Sidechains?”, Hackernoon. https://hackernoon.com/what-are-sidechains-1c45ea2daf3.

19 M. Orcutt. November 19, 2018. “Blockchain Smart Contracts are Finally Good for Something in the Real World,” MIT Technology Review.

20 A. Tsankov. June 21, 2018. “The ‘Oracle Problem’ isn’t a Problem, and Why Smart Contracts Make Insurance Better for Everyone,” Medium Corporation. https://medium.com/@antsankov/the-oracle-problem-isnt-a-problem-and-why-smart-contracts-makes-insurance-better-for-everyone-8c979f09851c.

21 K. Samani. January 27, 2018. “The Opportunity for Interoperable Chains of Chains,” Coindesk. https://www.coindesk.com/opportunity-interoperable-chains-chains.

22 “What is Cosmos?”, Tendermint Inc., https://cosmos.network/intro.

23 D. McNulty. November 13, 2019. “The Basics of Game Theory,” Investopedia. https://www.investopedia.com/articles/financial-theory/08/game-theory-basics.asp.

24 M. Finestone. January 5, 2018. “Game Theory and Blockchain,” Medium Corporation. https://medium.com/@matthewfinestone/game-theory-and-blockchain-db46e67933d7.

25 V. Buterin. December 30, 2016. “A Proof of Stake Design Philosophy,” Medium Corporation. https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51.

26 J. Hagermann. May 12, 2018. “Proof of Stake (Casper Ethereum) Explained,” Medium Corporation. https://medium.com/@johanneshage97/proof-of-stake-casper-ethereum-explained-682d663440d5.

27 A. Berman. October 2, 2018. “EOS Developer Acknowledges Claims of Collusion and Mutual Voting Between Nodes,” CoinTelegraph. https://cointelegraph.com/news/eos-developer-acknowledges-claims-of-collusion-and-mutual-voting-between-nodes.

28 S. Miah. July 6, 2018. “EOS: Trouble on the Horizon? State of Current Governance Explained,” Medium Corporation. https://medium.com/datadriveninvestor/eos-trouble-on-the-horizon-state-of-current-governance-explained-4b4f16bd6a41.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
44.192.93.109