Key Points
Enterprise blockchains include: Fabric, Ethereum, Corda, Quorum, Sawtooth
References
Session Overview
• Content - Different Blockchain Technologies like Hyperledger,Ethereum,R3 Corda,Multichain etc
• Summary - Key message to be delivered at the end of the session
Enterprise Blockchain solutions are a strategic investment for an organization. Different Enterprise Blockchain platforms implement unique features and provide some support for common concepts and features as well.
The session defines a set of criteria for comparison ( development, runtime environments and application use case fit ) and then compares some of the more popular Enterprise Blockchain frameworks against the criteria ( Hyperledger Fabric, Enterprise Ethereum, Corda, Quorum, Hyperledger Sawtooth ).
For each platform, a common application use case is referenced and evaluated for fit.
Finally, a set of questions to ask on selection of an Enterprise Blockchain for candidate use cases is reviewed.
Summary - Key message to be delivered at the end of the session
Key Takeaway 1
Identify criteria for blockchain criteria that may be relevant for your use case
Key Takeaway 2
Learn some of the key features and differences between the major Enterprise Blockchain platforms
Key Takeaway 3
Get a set of questions that can help select an Enterprise Blockchain platform for your use case
Enterprise Blockchains key features
Enterprise Blockchains reviewed
Comparison criteria
Ethereum
Corda
Hyperledger Sawtooth
Hyperledger Fabric
Quorum
Review options for your use case
Some have made significant penetration of specific industries
Your use case drives selection criteria
Internal solution vs Consortium solution
Existing organization skill sets
Production environment – single target or multi-platform capable
Integration requirements
Next steps -
industry blockchain strategies and solutions
relevant standards and regulations
opportunity assessment
Key Concepts
Fabric v Corda - 2018
fabric-v-corda-2018-features-medium.com-Hyperledger Fabric vs R3 Corda.pdf
corda v fabric feature compare
tokens c??? fabtoken delayed
privacy b
scale f???
finality b
batch proc ????
admin ????
languages f
interoperability b
open platform b
identity tools b???
pluggable f???
wide use cases f???
did support ????
multi cloud ????
consensus ????
default net b hyperchain, aws, ibm, azure
Enterprise Blockchain Protocols: A Technical Analysis of Ethereum vs Fabric vs Corda
https://kaleido.io/a-technical-analysis-of-ethereum-vs-fabric-vs-corda/
kaleido.io-Enterprise Blockchain Protocols A Technical Analysis of Ethereum vs Fabric vs Corda.pdf
| Enterprise Ethereum | Fabric | Corda | |
| Node Permissioning | Smart contract based rules, with file-based per-node rules as local overrides. | Configurable on node, channel and consortium levels. | Trusted network map service complemented by file-based configurations on each node. Corda networks are partitioned into compatibility zones that are governed by separate Certificate Authorities. |
| Identity | Public keys – distributed, and interoperable between Ethereum based chains. Coupled to PKI via proofs. | Based on PKI with native organizational identity. Organizational identity rather than individual identities used throughout in consensus, and permissioning. | Based on PKI with both individual and organizational identity. |
| Cryptography | secp256k1 | Pluggable (ECDSA with secp256r1 and secp384r1 built-in). | ed25519 secp256r1 secp256k1 RSA (3072bit) PKCS#1 SPHINCS-256 (experimental) |
| Transaction Consensus | Order -> Execute/Validate | Execute -> Order -> Validate | Execute/Validate -> Order/Notarize |
| Application Responsibility | Sending signed transactions to one node in the network. | Coordinating directly with all required participants to obtain endorsement, checking for consistent execution results, signature, and submission. | CorDapps use the flow framework to coordinate with transaction counter-parties to negotiate proposed updates, obtain signatures, and to finalize with the notary service. |
| Applied Consensus Algorithms | Proof-of-Authority (BFT). Raft (CFT with trusted leader). Istanbul BFT (BFT with deterministic leader rotation). Tendermint | Kafka/Zab (CFT with trusted leader). Raft (CFT with trusted leader). | Raft (CFT with trusted leader) BFT |
| Smart Contract Engine | EVM, in-process sandbox | Docker isolation by default, pluggable in v2.0 | Deterministic JVM |
| Smart Contract Languages | DSL (Solidity, Serpent), guaranteed deterministic. | Full languages (Go, Node.js, Java), non-determinism is tolerated. | Java, Kotlin, deterministic by using recommended libraries |
| Smart Contract Lifecycle | Immutable. Easy to deploy. Stored on-chain. | Requires elaborate process to deploy/change. Stored off-chain. | Requires node-level administrative operations to deploy/update. Stored off-chain. Ongoing work to split consensus-critical code vs. non-consensus-critical code for different storage strategy (on-chain vs. off-chain respectively) |
| Smart Contract Upgrade | Programming patterns to extend/migrate code & data. | Replacing off-chain code via administrative procedure and upgrade transactions. | Contracts with hash-based constraints are explicitly upgraded via node-level administrative procedures and coordinated flow to authorize and upgrade. Contracts with signature constraints automatically allow new versions to execute, as long as signed according to the constraints and the hash matches. |
| Tokenization of Assets | Native feature Many token standards: ERC20/ERC721/ERC777 etc. | Possible with custom solution. | Possible with custom solution. Corda Token SDK makes it easier to build. |
| Multi-chains | Each chain is unique, and requires separate node runtimes (min or 3 or 4 depending on consensus). | Native feature (channels) with shared peer runtime, and shared orderer. Built-in governance for creating side-chains with isolated state. | No concept of a chain (shared ledger). Transactions always explicitly target specific nodes. States are scoped to the designated notary which can be retargeted to a different notary. |
| Private Transactions | Public hash represents input. | Public hash represents input and private end state. | Inherently all transactions are private. The entire transaction is visible to a validating notary. |
| Community of Contributors (as of writing) | Go-Ethereum: 429 Quorum: 383 Besu: 60 Autonity: 360 | Fabric: 185 | Corda: 146 |
| Community Pulse (Month of Nov. 2019) | Go-Ethereum: 15 authors, 98 PRs Quorum: 9 authors, 13 PRs Besu: 23 authors, 66 PRs Autonity: 6 authors, 6 PRs | Fabric: 31 authors, 220 PRs | Corda: 33 authors, 91 PRs |
Ethereum Enterprise Blockchain implementations
| EE Client | Modified From | Developer | Open Source License |
| Quorum | go-ethereum | JPMorgan Chase | LGPL |
| Besu | New implementation in Java | PegaSys | Apache 2.0 |
| Autonity | go-ethereum | Clearmatics | LGPL |
| Strato | Haskell Ethereum | BlockApps | Closed-source |
Consensus Models Compared
All blockchain systems need a consensus mechanism to ensure all nodes have the same view of the transactions input and order. Almost all existing protocols utilize consensus algorithms designed around the “order-and-execute” architecture. First all nodes agree on the transactions order inside a block, then the transactions are independently executed by each node to calculate the resulting state.
Fabric consensus model is different - order > execute > commit
Fabric achieves transaction finality differently.
It has a faster consensus model: execute > order > commit
option to listen for transaction commit completion event ensures finality
At a high level, a configurable number of organizations must come to consensus on the execution results, where the “endorsement policy” is defined at the chaincode level, private data collection level (starting in v2.0), or key level.
Corda consensus design is very similar to Fabric. First the nodes involved in the transaction coordinate among them to process the transaction by executing the target contract and signing the execution result. Once the required signatures are collected, the initiator node is responsible for sending the transaction to the notary service for consensus signature. The notary service maintains a full history of all the transactions that have been submitted and is able to determine if a double spending situation is happening. Once the notary service approves the transaction and signs of on the proposed result, the transaction is finalized and committed by all the parties. This makes it effectively the same execute-order-validate design that Fabric follows.
| Transaction Execution | Ordering (double-spend detection) | |
| Ethereum | Ethereum Node (all nodes) | Ethereum Node (block proposer) |
| Fabric | Endorsing Peer | Orderer |
| Corda | Corda Node | Notary |
Multiversion Concurrency Control for execute > order > commit flows
“execute first and order next” design implies that some kind of concurrency version control is necessary, otherwise when multiple transactions are trying to modify the same state value in parallel, the later one will overwrite the earlier one and wipe out the state transfer from the earlier transaction, instead of building on the result of the earlier transaction. Fabric employs a multiversion concurrency control (MVCC) technique borrowed from database design. Under the cover, the chaincode engine keeps track of what state values are being viewed (in readset) and updated (in writeset) when the smart contract is executed. During the validation phase, where each transaction contained inside a block is validated and state transfer is applied, if a transaction’s state value versions in its readset do not match the current versions, typically because they have been updated by an earlier transaction in the block, then the transaction is marked as invalid.
implication is that if a series of transactions need to modify the same state value, they must be regulated such that no more than one transaction lands inside a single block. Otherwise the application will observe a lot of invalid transactions due to concurrent modifications.
Techniques exist to program around this limitation, such as utilizing the composite key capability to assemble unique keys for each transaction while having the ability to group together keys targeting the same underlying state variable. The high-throughput sample application demonstrates how this can be done. Note, though, that not all scenarios can take advantage of this technique.
Potential Value Opportunities
Potential Challenges
Candidate Solutions
Quorum
Quorum adds permissionless POS consensus
Quorum Control and presented by Quorum Control's Founder and CEO, Topper Bowers.
The title of their presentation is "Topper Talks Tupelo: Introducing the Future of DLT". In the presentation, Topper will give an overview of Tupelo. Tupelo is a permissionless proof of stake DLT platform purpose-built to model individual asset ownership and provenance as the base layer (rather than token exchange). Tupelo introduces a completely unique infrastructure to better support scalable adoption outside of currency-oriented blockchain circles and deliver concrete benefits to users, from enhanced data security to more accurate and transparent record-keeping.
About Topper Bowers:
Topper Bowers is an entrepreneur and engineer with 20+ years focused on building tech that betters people’s lives. Whether he’s designing user interfaces, managing world class teams, or
building high volume distributed systems for large nonprofits and Fortune 50 companies, he’s committed to making the kind of software that can change the world. He’s a former Y-Combinator founder (Summer 2012) with deep knowledge of distributed systems and distributed ledger technology.
Quorum Control is a VC-backed Berlin-based technology company building Tupelo, a permissionless proof-of-stake DLT platform purpose-built to model individual objects. After securing $2.9mm in traditional seed equity investment (lead by Initialized Capital) the team launched its first TestNet in November of 2018.
Step-by-step guide for Example
sample code block