Ethereum vs. Hyperledger - A tech report for the common questions
Ethereum is the permissionless public Blockchain. And Hyperledger Fabric is the permissioned private blockchain. You can achieve permissioning in Ethereum with developing a new layer on top of it and you can achieve permissionless architecture in Hyperledger Fabric by opening it up to the public. Further, as ethereum deployment would be simple, we could also just deploy multiple networks to get the same effect as private channels of the Fabric architecture. However, you don’t want to use one over the other where it is not the forte of that blockchain unless you have very strong business and technical reasons to do so which we cannot discuss in this paper. In this blog, we will rather concentrate on the architecture and technical differences between the two.
So, the big difference is the programming model, with Ethereum, you must write for the virtual machine, and generate the byte codes for that virtual machine, assuming that most would program in Solidity today, but, could be other options later. With Hyperledger you can program with Javascript, Go, and Java, though, I imagine that Javascript will be the go-to language.
With Hyperledger, you first create a model, queries, ACLs, etc, then write chaincode to read/write the things in the model. In the model, you can declare assets, participants and transactions. So, IBM provides data structures outside of the chaincode.
In Hyperledger, a transaction is a single function that can be called, but, with Ethereum, we talk about “contracts” which have multiple functions. So, really a Business Network Application that has assets, participants, transaction (implemented in chaincode), queries, ACLs, is the rough equivalent of a set of contracts in Ethereum that work together.
Thus, Hyperledger Fabric has a simple, separate, queryable database that the chaincode connects to so that you can CRUD operations assets and participants. With Ethereum, there is no such database, and, the equivalent is all of the data structures that you can declare inside of a contract, and the simple indexing supported by Ethereum. Some things in Ethereum would not likely scale very well.
Also, with Ethereum, you would be likely to do more “token” oriented programming, using fungible and non-fungible tokens for your program model rather than an architecture centered around reading and writing to a database. Thus, in Ethereum, you would very likely use token transfers to implement programing logic. Now, using assets and chaincode in Hyperledger, you could mimic the token concept that Ethereum has, but, you would be more likely to just program to the asset model in Hyperledger.
Finally, Ethereum has a much simpler authentication system based just on private and public keys, and no internal concept of participants that are mapped to a public key. In Hyperledger, you create certificates which are fancy public/private key sets with some more information, and associate each one to a participant.
With Ethereum, to restrict access to the network, you would need to create an external add-on to keep track of authorized users and their public keys, and also modify Ethereum so you could set the set of permissible public keys that would have access.
With either Ethereum or Hyperledger, you have the issue of the common users not understanding the significance of the private keys and being able to securely create them and then store them. Though, Ethereum probably has the edge here with all of the tools developed around this. With Hyperledger, it is most likely that individual users would not keep their private keys, but, would depend on an “authority” to secure the private keys and authenticate them in another way.