Defference Ethereum vs Hyperledger vs Corda
It looks like it's time to compare the aforementioned blockchain-based solutions. As for Fabric and Corda, they were developed for concrete use. Corda is cut out for the financial services industry.
Hyperledger Fabric platform provides a modular architecture in blockchain to a wide range of various industries that care seriously about their supply chains (banking, healthcare, etc.).
Solutions offered by Ethereum can be applied in many spheres, as well. Still, in contrast to Fabric, it is not modularity that stands out but the provision of a generic platform for all kinds of transactions and applications.
Network peers participation
When it comes to a traditional (centralized) network or data storage, there's only one entity that keeps a copy of the database. Usually it's known as a database keeper/owner. As a result, the owner controls what data is contributed and what other users are permitted to contribute.
DLT change the picture completely in favor of a distributed data storage where multiple entities hold lots of database copies and have permissions to contribute. All users participating in the distributed data storage build a network of nodes/peers.
On the other hand, there's and issue: as far as the data storage is distributed, an urge need arises to ensure that all peers agree upon a common truth, e.g. the correctness of a ledger, as changes made by one node have to be propagated to all other peer nodes in the network. The result of arriving at a common truth is called consensus among nodes/peers.
Regarding to the consensus, there are two operation modes: permissioned and permissionless. If consensus participation is permissionless, any user can become a part of the network. This model is true for Ethereum as a public blockchain.
In turn, if participation is permissioned, peers are selected in advance and no one else can access the network. Permissioned model is true for both Hyperledger Fabric and R3 Corda.
With Ethereum, all peers need to reach consensus over the order of all transactions that have taken place, irrespectively of whether a user has taken part in a particular transaction. That system is vital for the ledger existence. If there's no chance to establish a transaction, there is a chance that double-spends might have occurred. In other words, there's an opportunity of making coins out of thin air!
- Luckily, the current implementation of Ethereum has a fraud protection mechanism established by mining based on the proof-of-work (PoW) scheme. All nods have to agree upon a common ledger and all nodes have access to all entries ever recorded. It's worth noting that such an approach is problematic for apps that require a higher degree of privacy.
Unlike Ethereum, consensus interpretations of Hyperledger Fabric or Corda are more refined. As far as both frameworks deal with permissioned participation model, they provide a more fine-grained access control to records and thus better privacy.
- Fabric’s understanding of consensus covers the whole transaction flow, starting from proposing a transaction to network community. And not only that! Peers assume different roles and tasks in the process of reaching consensus. This contrasts to Ethereum where all nodes need to perform the identical tasks.
With Fabric, peers actions depend on the roles they play: clients, peers or orderers. A client acts on behalf of an end-user and creates and thereby invokes transactions. They interact with both peers and orderers.
Peers maintain the ledger and receive ordered update messages from orderers for committing fresh transactions.
Orderers, in turn, provide a communication channel to both clients and peers making it possible to send messages containing transactions. The only issue here is that there might occur faults in the delivery of messages when many mutually untrusting orderers are employed.
Without going further into detail, Fabric provides fine-grained control over consensus and restricted access to transactions which results in improved performance scalability and privacy.
- Consensus-building pattern of R3 Corda resembles of one used by Hyperledger Fabric. With Corda, transaction validity and transaction uniqueness make subject to consensus. The validity is ensured by running a smart contract code related to a specific transaction, by checking for all required signatures and by assuring that any transactions that are referred to are also valid.
Transaction uniqueness means that every single transaction refers to a unique consumer. In other words, there are no more transactions of that kind. The reason is to get rid of double-spends. Consensus over uniqueness is reached among peers called notary nodes.
Ethereum Smart contract
Perhaps, it's worth recalling that in terms of DLT a smart contract is a piece of software written in a specific programming language. Generally, it's developed to act as a software agent or represent the party using the smart contract to fulfill certain obligations, exercise rights and control a range of assets within a distributed ledger. All the aforementioned DLTs use the advantage of smart contracts. Ethereum's contract code is written in Solidity; Hyperledger Fabric uses Java; R3 Corda prefers Java or Kotlin. Moreover, in Fabric, the term “Chaincode” can be used as a synonym for a smart contract.