#54_Permissioned_blockchains

Spike #54 - Permissioned Blockchains

Ahmad Bin Amzah - 04/03/2019

Goals / Deliverables

Find and list the major features of permissioned blockchains.

Including but not limited to:

• Smart contract capabilities
• Adding Nodes
• Consensus

Technologies, Tools and Resources Used

• Documentation

What we found out:

Quorum

• Quorum Node – A lightweight fork of geth intentionally designed to take advantage of the R&D of the ever growing Ethereum. Changes to geth include;
  • P2P layer is modified to only allow connection to and from permissioned nodes.
  • Block generation logic modified to replace 'global state root' check with a new 'global public state root'
  • State Patricia trie has been split into two: public state trie and private state trie
  • Block validation modified to handle private transactions
  • Allow for transaction data to be replaced by encrypted hashes
  • Pricing of Gas has been removed, however Gas itself remains.
• Constellation & Tessera – Haskell and Java implementations of general-purpose system to submit information securely and is comparable to a network of MTA with messages being encrypted with PGP. Can be used for other applications.
• Transaction and contract privacy – Quorum implement smart contracts by using Solidity, an object-oriented language which supports inheritance, libraries, complex user-defined types and is statically typed. Quorum contracts can be set to either public or private meaning Quorum transactions are either visible to everyone on the same Quorum network or participants with a specified public key. Quorum however does not implement transaction privacy through an addition of a new transaction type but through extending the Ethereum Transaction model with a new parameter "privateFor".
• Transaction Manager – Responsible for transaction privacy. It stores and allows access to encrypted transaction data, exchanges encrypted payloads with other participant's Transaction managers. Uses the Enclave for cryptographic functionality.
• Multiple voting-based consensus mechanisms – Quorum offers two consensus mechanisms including;
  • Raft-Based Consensus – Introduces concepts of leaders, followers, and candidates to vanilla Ethereum nodes. There is a single leader for a cluster of follower nodes, in which the leader obtains all log entries. Only the leader node mines new blocks and does not present proof of work. This ensures avoidance of network hops from a node mining blocks to the leader and ensures only one leader exists at a given time. Raft-Based Consensus is used when Byzantine Fault Tolerance is not a requirement and there is a requirement for faster blocktimes and transaction finality.
  • Istanbul BFT (Byzantine Fault Tolerance) Consensus – Based on the Castro-Liskov paper about Practical BFT, PBFT has been changed to suit blockchains. All validators in IBFT are seen as clients instead of having specified clients which send requests. A proposer will continuously be selected to create block proposals for consensus and foreach consensus result, a new verifiable block is generated. All blocks in IBFT are final, meaning there are no forks and any valid block must be on the main chain. To prevent generation of a different chain from the main chain by a faulty node, blocks are self-verifiable and light clients can be supported.
• Network/Peer permissions management – Quorum offers multiple features which relate to the management of nodes and the conservation of privacy;
  • Network Permissioning – A feature which provides control over which nodes can connect with a given node and which nodes the given node is allowed to connect to, through the use of whitelisting.
  • Enclave Encryption – Payloads which are sent to the Enclave from the Transaction manager are encrypted ensuring only the recipient(s) are able to process the payload.
  • Private Key Storage – Private keys are protected through an algorithm using multiple hashing functions such as Argon2i and NaCl secretbox.
• Higher Performance – The Enclave and the Transaction Manager work in unison in order to achieve better performance through parallelisation of crypto-operations, with the cryptographic operations being handled by the Enclave.

MultiChain

• Network Permissions – Multichain provides multiple global permissions that can be granted to addresses, with addresses being either public key hashes or script hashes. These permissions grant the ability to control what nodes can access other nodes and their behaviour within the network. Permissions can be made completely unrestricted, temporary by a specific number of blocks or be made available only to transactions which appear within those blocks. Permissions can be revoked or granted using network transactions containing special metadata.
• Native assets – Assets are supported natively with identifiers and quantities of assets being encoded within each transaction output. Nodes track and verify the quantity of assets in transactions.
• Data streams – Streams can be enabled to allow for the blockchain to be used as a general purpose append-only database, whilst also providing timestamping, notarisation and immutability. Multichain can contain a number of streams with data being stored in full or is referenced by a hash inside of transactions.
• Inline metadata – Multichain supports inline metadata which is metadata included regular transaction outputs. Inline metadata is used to tag assets with special characteristics, which enables smart filters to enforce specialised rules for a transaction.
• Multichain consensus – Multichain utilises the Round Robin mechanism to achieve consensus which requires each block to be digitally signed by the block-adder. Prevention of monopolisation of one participant during the mining process is achieved by constraining the number of blocks created by the same miner within a given window. Multichain implements a parameter known as "mining diversity" which is the strictness of the Round Robin scheme. This enforces the need for permitted miners to collude and create blocks in order to generate a valid blockchain.
• Multichain smart filters (smart contracts) – Code embedded in the blockchain to enforce custom rules regarding the validity of transactions or stream items. Written in JavaScript and runs on Google's V8 JavaScript engine used in Chrome, Node.js and many other platforms.
• Multisignature transactions – Enables the creation of identities managed by multiple parties through the implementation of multisignature addresses and transactions. Implementation of multisignatures is similar to how bitcoin implements multisignatures where one or more addresses from a number of multisignature addresses must approve a transaction for it to be valid.

Hyperledger Fabric

• Identity Management – Fabric provides a membership identity service that authenticate participants on network and manages user IDs which enables permissioned networks. Authorisation of participants can be achieved through the use of access control lists, limiting what the user can and cannot do on the chain.
• Privacy and confidentiality – Fabric provides private channels which are restricted messaging paths that ensures transaction privacy and confidentially for specific subsets of network members. All data on a private channel are invisible and inaccessible to any network members which are not explicitly granted access.
• Efficient processing – Fabric allocates specific network roles by node type. This ensures a separation of concerns as transaction execution is separated from transaction ordering and commitment. The concurrency and parallelism allow for an increase in efficiency when processing multiple transactions.
• Chaincode (Smart Contract) functionality – Fabric chaincode encodes logic which is invoked by specific types of transactions on a channel. Chaincode can be used to define operating parameters for an entire channel and these types of chaincode is called System chaincode. System chaincode can be used to define the rules of a channel and the requirements for endorsing and validation. Chaincode is either written in Go, node.js, or Java.
• Modular design – Algorithms for identity, consensus and encryption can be pluggable in any Hyperledger Fabric network resulting in a universal blockchains architecture that any industry or public domain can adopt.
• Fabric Ledger – A sequence, tamper-resistant record of all state transactions which are a result of chaincode transactions made by participants. Each transaction results in a set of key-value pairs which are committed to the ledger. Some features of the ledger include;
  • Query and update using key-based lookups, range queries, and composite key queries
  • Read-only queries using query language
  • Read-only history queries
  • Transactions contain signatures of every peer, submitted to the ordering service
  • Transactions are ordered into blocks and are sent from an ordering service to peers on the channel
  • Peer validate against endorsement policies and enforce policies
  • Version checking performed prior to appending a block, ensuring states of assets that were read have not changed since execution of chaincode
  • Immutability after commitment
  • Configuration block defining policies, access lists, and other information
• Fabric Consensus – Consensus is reached in stages; endorsement, ordering and validation. Endorsement refers to when peers perform checks and simulate the transactions. After endorsement, Orderers will order the transactions, creating blocks and sends those blocks to relevant channels. Peers who receive the blocks start inspecting each transaction within the block, to ensure endorsement has been performed for each transaction. The block will then be marked as valid or invalid.

Corda

• Identity – Each node within a Corda network has a single well-known identity. It is used to represent the node during transactions, such as purchasing an asset. Each network has a network map service which assigns node identity to IP addresses which is used for messaging. Nodes can also generate confidential identities for individual transactions.
• Admission to the network – To join a network, a node must obtain a certificate from the network operator. Network operator enforces rules in regard to information a node must provide before granting access to the network.
• Ledger – Each node maintains a separate database of known facts. Each peer is able to only see a subset of facts on the ledger, with no peer being able to see the ledger in its entirety. Facts shared between multiple nodes will be the same across multiple nodes.
• States – An immutable object representing a fact known by one or more nodes at a given time, with states containing arbitrary data. A state contains a reference to the contract that governs the evolution of the state over time. As states cannot be modified, a new version of the state would need to be created, marking the previous version as historic. Current and historic states of a node is tracked by a database known as the vault.
• Transactions – Used to update the ledger marking previous states as historic and producing new states. Transactions can be referenced by another transaction to form a transaction chain. In order for a transaction to be committed, the transaction requires signatures of all required signers. Signers would only sign a transaction when it meets the following criteria;
  • Transaction validity – All transactions are digitally signed by all required parties and transactions are contractually valid (validated by a smart contract)
  • Transaction uniqueness – No other committed transactions has consumed any inputs from the proposed transaction
• In order for transactions to refer to states without consuming or updating them, states within the reference list of a transaction can be treated as reference states. Transaction commands are used to associate state changes with the affected signers who need to sign the transaction. Attachments refers to data associated with a transaction, which is reference by a hash.
• Contracts – Contract code can be written in any JVM language and has the full capabilities of the language chosen. Contracts cannot access information outside from the transaction and is only used to validate the transaction internally.
• Flows – Provides a sequence of steps which tells a node how to achieve a specific ledger update.
• Consensus – Determining the validity of a proposed transaction involves two types of consensus;
  • Validity consensus – All transactions must be accepted by contracts of every input and output, and all transactions have the required signatures.
  • Uniqueness consensus – Inputs of the proposed transaction has not been consumed by another transaction.
• Notary – A notary cluster is a network service which attest uniqueness of a transaction by signing the proposed transaction if its inputs are not consumed or reject the transaction and flag it. Corda allows for pluggable consensus algorithms. Multiple notary clusters may run on a single network providing privacy, load balancing and lower latency.
• Vault – Contains data extracted from the ledger stored in a relational model that can be easily queried and worked with. The vault keeps track of unconsumed and consumed states. Unconsumed states refer to states available for spending, whilst consumed states represent immutable states for the purpose of transaction reporting, audits, archival, etc.
• Oracles – Network services which provide commands that encapsulate a specific fact and list oracle as a required signer.
• Merkle trees – A cryptographic scheme that strips off certain parts of a transaction which network services such as oracle and notary don't need to see ensuring privacy of data is not compromised or leaked.