In this chapter, we focus on three new technologies that have significantly advanced our understanding of blockchain-enabled applications and opened up several new avenues for research. We begin our discussion with EOS, an Ethereum competitor built with an OS inspired architecture and platform-support design philosophy. It uses a new consensus mechanism called delegated proof-of-stake to enable rapid transaction verification and a continuous cycle of voting for delegates that support the network. The message passing protocols implemented in EOS are very advanced, allowing automated response handlers and action triggers on message delivery. They make up most of the smart contract system. There is also support for parallel lockless execution of smart contract instructions across the network, massively reducing latency in communication and state updates.
The second technology we present is a contract-oriented programming language called Chain-core. On the Chain network, all value is concentrated within assets that can be issued and controlled by users. Chain provides developers with a very powerful API to manage and transfer assets in the blockchain. In a similar regard to Aragon, Chain provides a visual interface to manage assets on a blockchain. We do a walkthrough of Chain’s graphical interface, covering all the basic features available for asset management. Chain recently announced a new development language to simplify the work of writing contracts for assets called Ivy Playground, and we end the section by talking about the new updates in Ivy.
The final technology that we talk about is Quorum, an enterprise-grade fork of Ethereum built by the Ethereum Enterprise Alliance (EEA) to handle high-volume requirements of businesses using the blockchain. It features numerous upgrades, such as a public–private split on the blockchain (to allow completely private transactions), private smart contracts, and the QuorumChain consensus mechanism.
In addition, zero-knowledge proofs will be coming to Quorum in the near future. We end this section with an overview of Quorum given by JPMorgan and EEA.
EOS Blockchain
EOS.IO is a new architectural approach to building a blockchain that resembles an OS. The design considerations allow for core infrastructure that can be scaled with ease for decentralized applications.
Here, scalability refers more generally to a set of principles that make blockchain applications competitive with their traditional nonblockchain counterparts. In this section, we focus on the potential for large-scale
© Vikram Dhillon, David Metcalf, and Max Hooper 2017
151
V. Dhillon et al., Blockchain Enabled Applications, https://doi.org/10.1007/978-1-4842-3081-7_11
Chapter 11 ■ reCent Developments in BloCkChain
adoption made possible due to three major technical innovations behind EOS: advanced permissions system, a new method for consensus called delegated proof-of-stake (DPoS), and parallel processing in the EOS blockchain. Let’s begin our discussion with a few principles of scalability embodied by EOS.
• User base: A disruptive EOS blockchain application should be able to support millions of users and user accounts. The underlying architecture needs to be
designed such that a distributed ledger can handle accounts as the fundamental
unit (as opposed to transactions). Supporting services can provide synchronous
modification of accounts and the blockchain global state.
• Free access: The services or applications built on a blockchain should not pass on any execution costs to the users. Large nonblockchain services are essentially free and the end user is monetized based on data generated from their usage. To enable widespread adoption, blockchain-based apps would have to eliminate user fees, amortize service
costs, and generate revenue from new accounts signing up for the app.
•
Updates and forks: The integration of new components or features to a service should not require any downtime. Blockchain-based services have to deal with consensus
at some level, and disagreements might lead to forks in the chain. These forks create chains with different lengths and are normally resolved very rapidly with the creation of the next block; however, the more serious problems arise with software updates. Bugs in the network should be fixed easily and seamlessly, without the need for a type of hard fork whereby some portion of the network is no longer compatible. The decentralized
nature of blockchain services creates a network without a single point of failure and combined with redundancy, it can provide a unique no-downtime experience.
• Low latency : The Bitcoin blockchain currently suffers from high latency and incredibly long verification delays. A pragmatic service used by thousands of users
is unsustainable with long wait periods, therefore, services on EOS must provide an
incredibly rapid verification and confirmation method where applicable. There are
some interesting new features such as parallel processing that could alleviate the
pain of slow confirmations on transactions.
Let’s start with how EOS handles accounts and user permissions. In EOS, all the accounts can be created with unique human-readable references. Additionally, EOS provides a well-defined message passing protocol between accounts with handlers and automation rules. Every account on the network can send structured programmatic messages to other accounts, and define rules and scripts to handle incoming messages when received. The scripts used to handle messages can also send messages in response to a specific incoming action. Each account also has private storage that can be accessed by the message handlers to modify the account state. The message handling scripts along with rules comprise the smart contract system deployed by EOS. The design principles behind EOS smart contracts are analogous to well-researched message passing protocols describing how an OS communicates with peripherals and other hardware components. The contracts will be executed on a virtual machine similar to an EVM. Existing smart contracts written in Solidity or other contract-oriented language can be ported and adapted to work with a container on the EOS blockchain. The contracts will also inherit some EOS-specific functions that allow communication with other EOS components.
152
Chapter 11 ■ reCent Developments in BloCkChain
■ Note another advanced feature in eos is the ability to communicate between eos blockchain and external blockchains compatible with merkle proofs. this takes place on the client side by using the same fundamental cryptographic principles (proof of message existence and proof of message sequence) to verify messages transferring in and out of the blockchains.
Let’s return to understanding how user permissions work. In EOS, the application structure is such that the authentication and permission modules are kept separate from the business logic. This allows developers to design tools specific for permission management and streamline apps to only contain code relevant to app-directed actions. EOS allows the user to define the keys used to sign outgoing messages and the different keys used for each separate service accessed by the user. For instance, a user can have one key to sign messages sent to other users and a different key to access social media accounts. It is possible to provide other accounts permission to act on a user’s behalf without assigning any keys. This type of limited access can give someone post-only permissions to your social media (with prior permission), but the posts will retain their unique signature. This is accomplished by a concept called permission mapping that we discuss next. A key idea in permission mapping is multiuser control of a single account. This is considered a high-level security measure for decentralized apps, and in EOS, it is implemented to reduce the risk of password or currency theft.
■ Note eos can be considered a generalized evolution of the blockchain-based social network called steem created by Dan larimer. steem was built on the Graphene blockchain and permission mapping was originally implemented as a feature, but it was very limited. Whereas steem was designed as a decentralized social platform, eos is an application development platform with a turing-complete blockchain analogous to ethereum.
To understand permission mapping, let’s look at an example involving three user roles: the account owner, an active user, and a social media user. The social media permission allows only specific actions by the user such as voting and posting. On the other hand, active user permission allows almost any action except for removing the owner. The owner can perform all available actions, including withdrawal. In this example, permission mapping refers to an account owner defining roles and mapping the associated permissions to other accounts. EOS generalizes this example by allowing custom roles, custom actions that can be mapped to different accounts. For instance, an account holder can map the permissions for a social media app to a Friend user group. Now any account added to the permission group (by the account holder) instantly has access to the social media app. They can post, vote, and perform any other actions available to the permission group but their unique keys would be recorded. Therefore, it will always be possible to identify which user performed an action. The concept of permission mapping is illustrated in Figure 11-1.
153
Chapter 11 ■ reCent Developments in BloCkChain
Figure 11-1. Structure of custom permission mapping
We can divide this representation into two components, the ownership and the message itself. The ownership portion contains keys from the account holder, who can perform all account functions including withdrawal of tokens. It also contains keys from active users that act on the behalf of the owner. The second portion of this structure is the message, and here we continue to use an example of social media. There are three social users mapped to this account by the owner and each user has a unique key. When a message is posted to the social media, the posting user signs the message with his or her own unique key, so any actions performed by the mapped users can be tracked. The message module here can be replaced by other applications, with the account holder mapping custom permissions to the app, providing limited functionality to the mapped users.
Delegated Proof-of-Stake
EOS uses a new consensus mechanism called DPoS. It is a variant of the proof-of-stake (PoS) algorithm with a focus on efficiency and fair access, giving smaller wallets or accounts a candid chance to produce blocks and earn the reward. The difference between a traditional PoS algorithm and DPoS can be compared to direct vs. representative democracy. In traditional PoS algorithms, any user with a wallet can participate in the process of validating transactions, forming consensus and earning a part of the mining reward. However, 154
Chapter 11 ■ reCent Developments in BloCkChain
it might be unprofitable for users with small wallets, or a smaller stake. In DPoS, every wallet across the network with any amount of coins can vote for delegates who perform the functions of validation and appending blocks to the blockchain. Ultimately, there are two main players in a DPoS network.
• Stakeholders: These entities have an account in the EOS network that holds a wallet with a balance. Having tokens allows you to vote for block producers.
• Block producers: Also known as delegates, these entities drive the consensus mechanism of DPoS. Block producers are the DPoS equivalent of traditional miners.
They validate transactions on the network, sign blocks, and earn a reward for adding a block to the blockchain.
Let’s briefly review the mechanism of consensus and the need for global state updates before diving deep into DPoS. Recall that a blockchain can be modeled as a state machine with a consistent history of updates. This state machine is acted on by transactions and consensus is the process of network-wide agreement on the order in which transactions will update the global state. The updates occur at specific increments as new transactions are included in blocks, and the rapid frequency of updates filters out invalid or double spend transactions. The goal of DPoS is to make block production evenly distributed among the most people and to have a democratic, fair process that elects the block producers. Regular PoS
networks require full consensus to validate, whereas in a DPoS system a limited number of delegated nodes (delegates) can probably validate transactions and reach consensus.
■ Note in the current schedule, eos allows blocks to be produced every three seconds by a singular block producer. By default, the blocks are produced in multiple series, with each series containing 21 block producers.
The DPoS algorithm has two major operational roles: electing a group of block producers and scheduling production of blocks. Each account on the network is allowed at least one vote per delegate (miner) in a process known as approval voting. However, accounts with a larger stake in the network follow the principle of one vote per delegate per token, and can vote for more than one delegate. The block producers (delegates) are considered a minimally trusted party on the blockchain, being elected through a real-time voting process. The delegates can take turns (in a series) adding transactions to a block and signing blocks to be added to the blockchain. As such, the use of a trusted party prohibits malicious parties adding invalid transactions to the blockchain. It should be noted that delegates don’t have the ability to change transaction or block details; they are only able to either add or not add a transaction to a block. This group of delegates are randomly assigned for block production based on some variation of a weighted fair queueing algorithm. The goal is to efficiently schedule block producers based on two criteria: the number of votes they received and the time a delegate has been waiting to produce a block. Delegates with more votes are more likely to be scheduled next to produce a block. On the other hand, delegates acting badly can be voted out quickly without affecting any significant transaction volume. Let’s summarize the main roles of delegates.
• Block production: The most important function of delegates is to create blocks at a fixed schedule of every three seconds. This involves validating transactions and
signing blocks across multiple series.
• Network support: Each time delegates produce a block, they are paid a reward for forging the block. The pay rate is set by the stakeholders, but some delegates might accept a lower pay rate to get more votes from the network. Additionally, instead of taking lower pay rates, delegates might offer additional services, such as marketing and legal work, to the stakeholders.
155
Chapter 11 ■ reCent Developments in BloCkChain
Figure 11-2 shows representative block production used in DPoS consensus algorithms.
Figure 11-2. Block production in DPoS
As mentioned previously, stakeholders on the network vote and elect delegates, who in turn validate transactions and produce blocks. From the highest voted delegates, 21 are elected to participate in multiple series and produce blocks. The delegates are assigned to a schedule for producing blocks, and this assignment is made using a round-robin algorithm. A block is considered invalid if a block producer forged outside of their scheduled time slot. After a block has been signed by the delegate, the final block can be appended to the blockchain, as seen on the right side of Figure 11-2. If a block producer fails to be on schedule, the next delegate’s block will be larger and include the previous transactions. At the same time, a block producer that fails repeatedly will be voted out of the series.
156
Chapter 11 ■ reCent Developments in BloCkChain
■ Tip it is interesting to note that Dpos blockchains do not have a tendency to fork. this is because block producers cooperate to produce blocks, rather than competing in a poW system. in the event that a fork does occur, the consensus automatically switches to the longest chain.
Parallel Execution
In Ethereum, execution of instructions (e.g., from a smart contract) is done in a deterministic and synchronous manner across the network. EOS offers a very interesting upgrade for parallel execution of applications without the use of any locking primitives. In this case, there must be a mechanism inherent to the blockchain ensuring that each account only updates its own database. Incoming instructions update the account state; therefore, they must be applied sequentially such that the n + 1 instruction updates the account only after nth instruction. There is an exception to this general rule in the case of pass–fail binary instructions. Some account handlers can process binary instructions as read-only and reply back without any changes to their internal state.
Fundamentally, parallel execution in EOS relies on messages generated from different sources within an account, delivered through independent threads, so they can be executed in parallel. Ultimately, the final state of an account only depends on the messages delivered to it. A block producer organizes the delivery of messages to independent threads. Even though a block producer is on schedule for validating blocks, message delivery is done on a more rapid and custom schedule to take advantage of parallelism.
Often the source of these messages is scripts running on the blockchain or automatic account handlers sending messages. Due to the parallel nature of EOS, when a message is generated, it doesn’t get delivered immediately. Instead, there is a period of delay between message generation and delivery referred to as latency. The rationale behind introducing latency is that instantaneous delivery could interfere with a receiver already modifying its internal state due to a previous message. Lockless messaging is achieved by scheduling the message to be delivered in the following cycle.
So what is a cycle? Under normal circumstances, to avoid message collision, an account would have to wait until the next block to send a second message or to receive a reply. A block is created every three seconds, therefore accounts can expect at least a three-second wait between sending more messages. To remove this wait time between messages, EOS divides a block into multiple cycles and further subdivides those cycles as follows:
• Each cycle is divided into threads.
• Each thread contains a list of transactions.
• Each transaction contains a set of messages that will be delivered.
157
Chapter 11 ■ reCent Developments in BloCkChain
Figure 11-3 shows the subdivisions and structure of a cycle within a block. Block producers keep adding new cycles to a block until a time limit or no new transactions have been generated.
Figure 11-3. Block structure for messages in EOS
158
Chapter 11 ■ reCent Developments in BloCkChain
Each block is divided into a cycle that forms the basis of rapid communication within a single block.
If no two transactions within a block modify the same account, all the transactions from one cycle can be executed in parallel. For each transaction that takes place between users, any automated handlers preset by the receiver are notified of incoming instructions.
Transactions generated during the time window of one cycle can also be added to a subsequent cycle or the next block. Once a block is finalized, we can ask this question: Given a block cycle, are there two threads that contain transactions that modify the same account? If not, then any given block can be processed by executing all the threads in parallel. An exchange application developer runs full nodes for the purpose of displaying the exchange state to its users. This exchange application has no need for the state associated with social media applications. EOS.IO software allows any full node to pick any subset of applications to run. Messages delivered to other applications are safely ignored because an application’s state is derived entirely from the messages that are delivered to it. There are two important take-home points that need to be reiterated from this section:
• An application’s internal state is derived from the messages delivered specifically to that app.
• Any changes to an account’s internal state happen via messages passed between
accounts and included in transactions on the blockchain.
Dan Larimer commented on the parallel nature of EOS as a massive advantage for building applications on the blockchain:
Parallel processing capabilities bring continuous scalability and a reliable high performance foundation for your applications. Existing single threaded capabilities force every application to share the capacity and performance of one single-threaded blockchain, create hard scaling limits, and eventually suffer from network congestion that may result in platform-wide downtime.
■ Note eos.io recently had an iCo to raise funds for development, and Cryptoportfolio reviewed the iCo, making a few points worth considering for us. the first point is that profit generation comes from the value appreciation of eos tokens. the more users and developers, the more valuation. the second point is that there are no transaction fees on eos, so accounts and Dapps need tokens to work. holding certain amount of tokens is like having bought a percentage in eos computational power. the third point is there is going to be free usage of the platform; you only need tokens in your balance to operate on this blockchain. Finally, the last point is that users demand fast response from services they use, so eos will try to make transaction confirmation in less than 1.5 seconds.
Scheduling
The last topic that we want to tackle in this section is that of best effort scheduling. Recall from our previous discussion of computational marketplaces that a virtual machine (EVM) on the blockchain determines the cost of execution for the instructions contained in a contract. The customer requesting a given task paid for each step of the instruction with gas, and if the number of steps exceeded the EVM limit, the task would not execute. In EOS, the delegates take over the role of making global decisions about eligibility to 159
Chapter 11 ■ reCent Developments in BloCkChain
execute, instead of a virtual machine. The block producer (delegates) makes a subjective measurement of the complexity (number of instruction steps) and time required to process the instructions contained within a transaction and deliver a message. This subjective measurement of processing costs is analogous to gas in an Ethereum system. A delegate-based instruction counting and cost-determining mechanism simplifies the addition of new features and optimizations to the blockchain, without any concern about breaking the cost calculations. It also allows us to categorize the network functionally: blockchain and virtual machines for execution and nodes or block producers for calculating resource allocation and management.
Each block producer calculates resource utilization using its customizations to the EOS algorithms.
Across the network, each step has an execution time limit and is charged a fixed bandwidth-usage cost regardless of whether the computation took a millisecond or the full time limit. A crucial point to note is that in EOS all resource usage constraints are subjective and ultimately enforced by block producers.
As a collective, the block producers have agreed on the following criteria on the EOS network:
• For a block producer, there are two options available: include a transaction (a set of instructions) or reject it from being included in a block.
• If a block producer concludes that a given account has consumed an unreasonable
amount of the computational bandwidth, they simply reject transactions from that
account when producing their own block.
• As long as one block producer considers a transaction valid, and under the resource usage limits, all other block producers will also accept it. However, this transaction will take longer to confirm on the network.
•
If a block producer includes transactions that are well beyond the limits of resources, another producer might reject the block and a third producer will be needed as the tie-breaker.
There would be a delay in propagation of the tie-breaker block, giving the stakeholders and other delegates ample time to pinpoint the source of resource violation. Over time, if a malicious block producer keeps approving blocks that are over the limits, that producer will be voted out from the list of delegates.
The block producers perform the role of a best-effort scheduler in EOS: fair scheduling of tasks for maximum throughput or rejecting tasks from being executed on the network.
■ Note an initial release of eos containing the sDk has been made available on eos Github. this release is called Dawn 1.0 and according to the release announcement, it contains a standalone eosd node that produces blocks and adds them to the blockchain, a command line client called eosc, a client wallet and a utility to create a local testnet. it also contains an app for smart contract developers to write contracts.
Chain Core
Chain is a contract-oriented programming language designed to manage assets on a blockchain. The following is an excellent summary of the Chain platform by its team:
The key characteristic that makes a Chain blockchain a shared ledger, rather than simply a distributed database, is that it is designed to track and control value—i.e., units of one or more assets. Unlike data, value is scarce: once issued, it cannot be copied, only transferred.
We gain new capabilities when the underlying format of a financial instrument becomes a cryptographically-issued digital asset, one of the most notable of which is the ability to write programs that control the asset. These programs are known as contracts.
160
Chapter 11 ■ reCent Developments in BloCkChain
All value on a Chain blockchain is secured by such contracts. Each contract controls, or locks, some specific value—i.e., some number of units of an asset—and enforces the conditions that must be satisfied before that value can be unlocked. From the simplest custodial account to the most complex derivative instrument, contracts define the rules for asset movement on a Chain blockchain network. And Ivy lets you compose those rules.
When designing Ivy we had a single goal: making it easy to write safe, secure, and simple programs to control the movement of value on a blockchain. Nothing more, nothing less.
At Consensus 2017, a major blockchain development conference, Chain announced a set of more sophisticated upgrades to the core programming language making it easier to write contracts that manage assets. Ivy Playground was the result of this effort to make the developer experience as smooth as possible.
A core concept that Chain and Ivy have embraced in designing contracts is to limit the amount of information in the blockchain to only state-updating logic and consensus-maintaining variables. This design rationale was explained by the Chain team as follows:
As much as possible, the business logic of blockchain solutions should be executed off-chain, in the “application layer”—programs written in traditional languages, that interact with Chain Core through its SDK. The only logic that needs to be part of the “smart contract”
layer is the set of rules that secure and transfer assets.
Some blockchain platforms are marketed as workflow automation tools, as a global database for shared state, or as a platform for building software-as-a-service applications.
We believe that these goals make the wrong trade-off, by effectively shifting computation and logic from traditional servers, where computation is cheap and information is private, to the blockchain, where every computation must be redundantly executed on every node in the network.
The key to understanding Chain’s design is that traditional services cannot be transitioned to a blockchain; instead they need to be redesigned for a new architecture. For starters, additional parameteres involving consensus are introduced in an application. The programmatic routines need to distinguish between the business logic that should remain outside of the blockchain and state variables that need to be updated on the blockchain. Therefore, new design decisions are needed. Additionally, traditional services have some inherent redundancies that are normally not a problem for servers in a data center, but become amplified in a decentralized network where each node must update the state of accounts in the same order for every step of computation (replicated state machines). To illustrate how Chain works, we do a walkthrough of Chain Core with Ivy. The main objectives of this walkthrough are to understand how to create hardware security module (HSM) keys, how to create accounts, and how to trade assets. The layout will be very similar to Aragon, which we covered previously. Begin by downloading the Chain Core with Ivy Playground (https://chain.com/docs/1.2/ivy-playground/install) from the Chain web site. Once it is installed, begin by configuring Chain Core, as shown in Figure 11-4.
161
Chapter 11 ■ reCent Developments in BloCkChain
Figure 11-4. Configuring Chain Core
For our walkthrough, we will be joining a testnet that behaves like a blockchain, but all the data is reset weekly. The testnet helps in understanding how to interact with a blockchain properly and how to manage assets in Chain.
Click Join Network to open the dashboard of Chain Core. Here, you are presented with an option to perform a tutorial. We cover the basics of that tutorial here, adding more information about the main concepts in Chain. To the left of the dashboard is a navigation menu, shown in Figure 11-5, that we will be using frequently throughout the walkthrough. The navigation menu is split into three parts: The top part deals with data related to accounts, assets, and transactions. The middle part deals with private–public keys required to interact with the blockchain. The bottom part provides some developer services, and we will be talking about Ivy Playground later in our walkthrough. To begin interacting with the testnet, we first need to create keys. Chain uses HSM-backed key management and this key becomes your gateway to the network.
To create a key, go to the navigation menu and click MockHSM under Services.
162
Chapter 11 ■ reCent Developments in BloCkChain
Figure 11-5. Naviation menu layout on Chain dashboard
The navigation menu is split into three pieces: Core Data, which includes accounts, assets, and transactions; Services, where we can create HSM keys; and finally Developers, which includes a few developer tools. We will be using the MockHSM tab to create a key pair.
Why do we need a HSM key pair? This key pair will be used to create new classes of assets, issue new assets, and create new accounts. The default view for the Chain dashboard is that of transactions. Click MockHSM and you will see a message saying, “There are no MockHSM keys,” which stands to reason, given that we haven’t made any keys. Let’s start by clicking New MockHSM keys. You should see the screen shown in Figure 11-6. Type an alias for the key and that name will be used throughout Chain.
Figure 11-6. Creating a new HSM key. On the testnet, the key data will be erased in a week 163
Chapter 11 ■ reCent Developments in BloCkChain
After clicking Submit, you should see a confirmation for the key that you just created, shown in Figure 11-7.
Figure 11-7. Confirmation from key creation with an alias Vik
Now that we have a key pair, we can use it to create assets. Click the Assets tab under Core Data and you should see some default assets (at the time of writing, Chain Core had two defaults), shown in Figure 11-8.
Figure 11-8. Default assets available in Chain. We will be creating new assets by clicking New Asset at the top-right corner of the screen.
164
Chapter 11 ■ reCent Developments in BloCkChain
You should see the New Asset screen shown in Figure 11-9.
Figure 11-9. Asset creation and signing
The process requires two steps. First is inputting the asset information, including any identifiers or definitions assigned to an asset in JSON format. The second step is signing the asset with your public key.
Here, we are naming the asset Silver.
Once you have completed the asset information, you need to scroll down and sign the asset with the HSM key that we just created. Figure 11-10 shows the signing process. The Chain documentation provides an example of why a user might want multikey authentication (shown in Figure 11-10): In simple cases, an asset or an account will define a single key required for issuance or for transfers. But it’s possible to define multiple keys for different usage patterns or to achieve different levels of security. For example, a high-value asset may be defined with two signing keys, requiring two separate parties to sign each issuance transaction. A joint account may also be defined with two signing keys, requiring only one, from either party, to sign each transfer. The threshold number of signatures required is called a quorum.
165
Chapter 11 ■ reCent Developments in BloCkChain
Figure 11-10. Signing an asset
There are a few parameters to consider here. By default, a new asset can be created with signature from one key. The number of signatures required to approve the new asset are referred to as Quorum, and we use the defaults here. Finally, we have to sign the asset using the key we created. After you click Submit, you should see a confirmation screen with the Silver asset created on the testnet.
166
Chapter 11 ■ reCent Developments in BloCkChain
Now that we have an asset, we need to issue it. In Chain, all assets are managed and controlled by users; therefore, the asset we issue would have to be controlled by an account. We don’t yet have any accounts on the network, so let’s take care of that by clicking Accounts on the navigation menu. This brings us to the account view. There might be some sample accounts on the testnet such as Alice or Bob, but in the right corner of the Accounts screen is the option to create a new account. Click that to open an interface very similar to the one used for creating an asset. In fact, most of the steps are exactly the same here, such as filling out the account information, and then providing an HSM key to sign it. The account creation view is presented in Figure 11-11.
Figure 11-11. Creating a new account
There are two steps for creating an account: providing account information and key signing. The first step is shown in Figure 11-11 and the second step is exactly the same as signing an asset.
Once you have provided the account information, sign the account using your HSM key. A confirmation screen will open for the account that you just created. Now, to illustrate trading between accounts, we need two accounts. Create a second account with the alias Team Rocket, and the final result should look like Figure 11-12.
Figure 11-12. Account summary. Two accounts on our testnet will allow us to show trading, locking, and unlocking.
167
Chapter 11 ■ reCent Developments in BloCkChain
Now that we have two accounts, we can start to trade assets between them. It should be noted that in Chain Core, assets can only have four actions performed on them: An asset can be issued, spent, transferred (controlled), or removed (retired). Usually, a combination of these actions allows for transactions between users. We look at two types of transactions here; one is simply issuing new asset to an account, and the second one involves trading that asset to the second account we created. Finally, we end the walkthrough by looking at how these actions have evolved in the Ivy Playground. To begin, navigate to the Transactions tab, and click New Transaction. This should take you to the New Transaction screen shown in Figure 11-13.
Figure 11-13. New Transaction screen
A transaction can only be carried out in terms of one of the four actions we mentioned earlier. Each action has a set of associated parameters that need to be given to complete a transaction. Here, we want to issue a new asset, so we select Issue.
Once you slect Issue, another screen opens, asking you the parameters of the asset that you want to issue, as shown in Figure 11-14.
Figure 11-14. Creating an asset. The issue action first asks for the name of the asset we want to create and finally the amount that we want to issue.
168
Chapter 11 ■ reCent Developments in BloCkChain
Recall that in Chain, assets cannot just be issued in a void. Creation of a new asset is coupled with control of the asset by an account. Once an asset has been issued, we will assign it to the first account we created. Figure 11-15 shows the control of an asset being passed to the new account.
Figure 11-15. Assigning an asset to an account
This is also referred to as control with account in Chain. The 100 units of Silver are transferred to the first account that we created.
Once the assignment is filled out, you can submit this transaction. It will be added to the testnet, and the confirmation is shown in Figure 11-16.
Figure 11-16. Transaction verification
This summary shows 100 Silver assets issued and then assigned to the Vikram account. Put differently, the assets were issued and then controlled by the first account we created.
169
Chapter 11 ■ reCent Developments in BloCkChain
This is the simplest transaction we can do on Chain. Now let’s move to the next transaction involving a trade between two users. This time around, we will have to use the spend action to make assets available, and control action to transfer them. Go back to the Transactions tab from the navigation menu, and click New Transaction. This time, instead of using the issue action, select Spend From Account, as shown in Figure 11-17.
Figure 11-17. Use the Spend From Account action to initiate a trade
To start the trade, select Spend From Account. Next, specify how much Silver you want to transfer (Figure 11-18). This first step only makes the asset available; it still needs to be claimed.
Figure 11-18. Making 10 units of Silver available for trade from the Vikram account 170
Chapter 11 ■ reCent Developments in BloCkChain
Now that Silver is available, let’s switch ownership from the first account to the second, as shown in Figure 11-19.
Figure 11-19. Transferring ownership from one account to the second (Team Rocket in this case) Just as we did while issuing assets, trading assets involves one account making assets available, and the second account taking control of the freed assets.
To confirm that the transaction took place, we can go back to the Transactions view, and then look at the most recent transaction. Clicking it will expand the transaction (see Figure 11-20).
Figure 11-20. Summary of the most recent transaction
Notice that 10 assets were spent by the first account (Vikram) and 10 assets were then controlled by the second account (Team Rocket), completing our trade.
171
Chapter 11 ■ reCent Developments in BloCkChain
So far, we have discussed two transactions that are key to Chain Core. There are a few more options available, such as retiring assets, which simply means taking a given amount of assets out of circulation.
This has the effect of increasing scarcity for the network. Now that we understand the concept of actions, what more can we do in Chain? Writing sophisticated scripts to manage and move assets in Chain becomes a little complicated. Ivy Playground was introduced to develop a formal scripting language around locking and unlocking assets on the blockchain. Developers can add conditions to a script and write more complex contracts to secure value and assets. The main objective of Ivy is to lock the value of an asset with a set of clauses that describe conditions under which the asset can be unlocked. The Chain team talks about how contracts are different in Chain as compared to other distributed computational platforms such as Ethereum:
Contracts on a Chain blockchain are immutable. A contract cannot be updated, only spent—i.e., removed from the blockchain and replaced with one or more new contracts that lock the same value.
This immutable state model distinguishes our approach from that of (for example) Ethereum and Fabric. In Ethereum, contracts can send messages and value to each other and can update their own state in response to these messages.
Most current smart contract approaches provide the freedom to write programs that execute arbitrary logic on a blockchain, but make it essentially impossible to provide the kind of safety assurances that Ivy is designed to give. While other platforms have the goal of making it easy to build anything, Ivy’s goal is to make it difficult to build anything wrong.
Let’s finish our walkthrough by looking at a simple example of using a public key pair to lock assets and then unlock them. To begin, click Ivy Playground on the navigation menu. This should bring you to the Playground with a default contract loaded that locks assets using a key. The idea is very straightforward: You choose the values to lock; for instance, in the case of an asset, we can lock the units of silver, and then specify the account the asset is coming from. Then we provide arguments to the contract, and here, the only argument is that the asset is locked using a key pair. This idea is shown in Figure 11-21. After locking an asset, we would see a confirmation of that locking, as shown in Figure 11-22.
■ Note the default contract loaded on ivy is also the simplest contract. Your public key is used to lock the contract, and your signature is required to unlock the asset. it contains one clause called spend that verifies the public key and signature of the user to unlock assets.
172
Chapter 11 ■ reCent Developments in BloCkChain
Figure 11-21. Selecting asset parameters and contract arguments to lock an asset on the blockchain
Figure 11-22. Confirmation of asset locking using a key pair on the blockchain 173
Chapter 11 ■ reCent Developments in BloCkChain
We presented how locking works in Ivy, now let’s take a look at how to unlock this asset. Recall that we need a public key signature to unlock it and the key must match the account that locked it. Then, we can provide an unlock destination, as shown in Figure 11-23.
Figure 11-23. Unlocking an asset using Ivy Playground
174
Chapter 11 ■ reCent Developments in BloCkChain
Here, the unlocking is being done in conjunction with the spend clause to transfer the asset. We first have to provide the signature as an argument and then the destination for the unlocked value. This destination will control the amount of assets unlocked. Notice that this process is very similar to the trade we performed earlier.
This concludes our walkthrough of Chain Core and Ivy. We focused on how to create an HSM key, how to create new accounts, and the different modes of transactions available in Chain. Finally, we talked about using Ivy to add clauses in smart contracts that allow more sophisticated management of assets on the blockchain. Let’s continue our journey with the next topic, Quorum blockchain.
Ethereum Enterprise Alliance
After the recent DAO hack (covered in Chapter 9), corporations such as JPMorgan, Microsoft, and Accenture formed a consortium called the EEA to make an enterprise-class Ethereum blockchain capable of handling high-volume transactions and business applications. JPMorgan has contributed massive development resources, providing the EEA with Quorum, an enterprise-grade permissioned version of Ethereum.
■ Note What is a permissioned ledger? a permissioned blockchain restricts the parties that can be block producers or miners, ultimately limiting who can contribute to consensus of the global state. in the financial world, this kind of verification might become necessary to scale a product for the masses.
Quorum’s dev page on GitHub lists the following features that are an improvement over Ethereum:
• Privacy: A key innovation to make Quorum suitable for enterprise work is the introduction of privacy through private transactions and private contracts. This is
accomplished using Constellation, a peer-to-peer messaging daemon that can direct
the flow of private information to the appropriate network participants.
• Alternative consensus: Quorum does not rely on PoW/PoS for the permissioned ledger; instead, there are two consensus mechanisms better suited for enterprise-grade blockchains:
•
QuorumChain: A new smart-contract-based model that relies on voting by
nodes to achieve consensus.
•
Raft-based Consensus: A consensus model suitable for closed-membership
consortium settings, with very fast block-generation times.
• Node permissioning: A feature in Quorum that only allows connections to and from nodes that hold the appropriate identification keys, and have been registered to
participate in the permissioned network.
• Higher performance: Quorum has to offer significantly higher performance than Ethereum to be used in a high-volume environment such as the one required to
power bank-level transaction volume.
Let’s dive into the features. We begin by talking about the key concepts behind the two consensus mechanisms available in Quorum. Then, we cover what modifications have made nodes capable of handling private transactions. Finally, we discuss Constellation and how it works to facilitate transfer of data in the 175
Chapter 11 ■ reCent Developments in BloCkChain
permissioned network. A summary of Quorum’s features and private transactions created by JPMorgan follows our technical discussion. Let’s begin with the consensus mechanisms.
• QuorumChain: This is a majority-voting consensus mechanism where a smart
contract dictates which parties (nodes) can vote toward accepting or rejecting a
block. The participating nodes on Quorum can either be maker nodes that actually
construct a block or voter nodes that vote on the validity of a block. QuorumChain
uses a signature verification method from Ethereum such as ecrecover to validate
the votes received from maker nodes and voter nodes. Once the votes from voter
nodes have reached a threshold, the block is accepted into the network.
• Raft-based consensus: The fundamental unit of work in a Raft-based system is a log entry. A log is an ordered sequence of events and it is considered consistent if all members of the network agree on the entries and their order. In Raft, a node can
either be a leader or a follower; all nodes start out as followers. Eventually, through a peer-election process, one node emerges as the leader. Compare that to Ethereum
where any node can mine a new block, or become the leader for that particular
round. In Raft, only the leader can “forge” a block in the true sense, but the leader does not need to present any PoW. Instead, the leader proposes a block that the
followers vote on. Once it receives a quorum (majority vote) of votes, it is accepted as the next block to extend the blockchain. The followers also send an acknowledgment
to the leader, and now the block is committed to the log entry. Once the leader has
received the acknowledgments, it notifies every node that this new entry (block) has been committed to the log.
Now that we have talked about consensus, let’s look at what makes nodes accept private transactions.
In Ethereum, all transactions are public, and by default, nodes only accept transactions that are broadcast publicly. For Quorum to work, the following changes have to be made:
• PoW consensus algorithms have been replaced by QuorumChain, which is voting—
based. The ultimate goal is to have multiple consensus algorithms running on the
blockchain in a model called pluggable consensus.
• There is a modified connection layer where nodes connected to the permissioned
ledgers are identified and registered.
• The state tree has been split into two trees: a public state tree and a private state tree.
• Blocks can be validated with new logic containing private transactions.
• Transactions can be created with some data replaced with encrypted hashes to
preserve privacy where required.
What propagates private transactions and contracts through the network and how is the flow of private data handled? For starters, there is a new optional parameter in the ETM called privateFor, and it can take multiple addresses. Quorum treats the addresses from this parameter as private in the network. A new transaction type, IsPrivate, has been introduced to mark certain transactions as private. However, the main tool making the propagation of private transactions possible is Constellation: a peer-to-peer encrypted message exchange. Here are the basics of how Constellation works within Quorum to provide privacy: Before a private transaction is propagated to the Quorum network, the message (contained within the transaction) and headers are replaced by the hash of an encrypted payload received from Constellation.
Some participants in the network have had their public key included in the payload by Constellation. When those users receive the payload, they can decrypt it using their own instance of Constellation. Every other participant will only see an encrypted hash, and skip the transaction. The participants who are involved will decrypt the payload and send it to an EVM for execution, updating their internal state as a result. There 176
Chapter 11 ■ reCent Developments in BloCkChain
are two components in Constellation that play an important role in maintaining privacy: the transaction manager and the enclave.
The transaction manager stores encrypted transaction data, facilitates the exchange of encrypted payloads between participants, and manages the propagation of private transactions if the satisfying conditions have been met. It also makes function calls to other modules in Quorum, especially the enclave for cryptographic functions. In many ways, the transaction manager behaves like a central hub controlling the flow of messages from one component of Quorum to another. Enclave is the cryptographic core of Quorum. The transaction manager itself does not have access to any sensitive information or the keys, and it delegates cryptographic tasks such as symmetric key generation and data encryption and decryption to the enclave. It also holds the private keys for accounts in the network. Both the transaction manager and enclave are isolated from other components to enhance security.
zk-SNARKs
Zero-knowledge proofs, or Zero Knowledge Succinct Noninteractive Arguments of Knowledge (zk-SNARKs) are a new technology native to ZCash in which privacy and anonymity are maintained throughout the transactions happening on the blockchain. Recently, the EEA announced that the team behind ZCash will be helping implement a zk-SNARK layer for Quorum to enhance privacy and security of transactions on the blockchain. How do-zero knowledge proofs work? zk-SNARK technology is usually employed in complex payout situations. Let’s look at an example. Say that Alice receives money from a smart contract if either X, Y, or Z happens. Now any of those situations (X, Y, Z) might be sensitive to Alice’s health, or perhaps a business decision that she does not want to reveal to the public. This is where zk-SNARK can shine: It can create a proof to the smart contract that one of the three conditions (X, Y, Z) occurred, but not reveal which exact condition occurred. More formally, Christian Lundkvist from ConsenSys described zero-knowledge proofs as follows:
The goal of zero-knowledge proofs is for a verifier to be able to convince herself that a prover possesses knowledge of a secret parameter, called a witness, satisfying some relation, without revealing the witness to the verifier or anyone else.
In our previous example, the three choices for Alice constitute a witness, and she had to prove that one of those occurred to the smart contract, but did not need to reveal the specific circumstances. Paige Peterson from ZCash confirmed that zk-SNARK would be coming to Quorum as a settlement layer, providing enhanced privacy and security to transactions. The eventual goal (described at Consensus 2017) is to make zero-knowledge proofs blockchain agnostic, and implement a settlement layer as a service. The future of integration with zero-knowledge proofs can be a paradigm shift for permissioned ledgers to carry out enterprise-level transactions. With some lessons learned, and a better settlement layer, there are some incredible opportunities for applications in health care to protect patient data and maintain privacy.
■ Note at the time of writing, a very interesting new development in the zk-snarks world was announced.
Zokrates is a higher-level programming language that can be used to write zero knowledge proofs (Zkps) that compile to ethereum-compatible Zkps and executed on-chain.
Review of Quorum
Figures 11-24 and 11-25 are slides taken from a presentation by JPMorgan (with permission) and provide a high-level summary of Quorum given to the Hyperledger Project by David Voell.
177
Chapter 11 ■ reCent Developments in BloCkChain
s
vationno
ey in
d its kn
um a
uor
f Q
view o
ver
O
e 11-24.ur
