Ethereum vs. Hyperledger: The Epilogue

I was very excited to work with Hyperledger when I first did a comparison between Ethereum vs. Hyperledger [1]. The ability to write chaincode in javascript was especially appealing to me. However after more than a month of spending time in the trenches and doing Hyperledger Fabric development, my opinions changed. If I were to revisit Part I of Ethereum vs. Hyperledger [1], I would add one more row to the table as follows:

 EthereumHyperledger
Developer ExperienceF

I haven’t done any programming with Ethereum so don’t know how developer friendly it is but can safely say that Hyperledger scores an F on the developer experience. Lets try to break down the developer experience on following competencies:

  1. Works without any issues
  2. SDK provides good, exhaustive and bug-free code samples showing how to write code and exercise functionality
  3. Comprehensive and accurate documentation
  4. Tech Support: When there is an issue, there is a helpful community to provide support

Rating Scale.

A – excellent. Scores +1 on all dimensions above
B – Good. Better than other alternatives out there
C – Fair. comparable to other alternative platforms
D – Poor. there exist better alternatives out there
F – Fail. -1 on all of the above dimensions

Hyperledger proudly scores an F

  • Broken out of the box: e.g., https://stackoverflow.com/questions/53506205/install-samples-binaries-and-docker-images-not-working-on-mac. Its like you ordered something from amazon and its broken out of the box. Looks like HL team spend no time testing the code works on a mac
  • Buggy Samples: e.g., https://stackoverflow.com/questions/51436123/unable-to-find-neweventhub-function. Another example: https://jira.hyperledger.org/browse/FAB-13070
  • Samples of limited use and help: e.g.,
    • everywhere in the samples they keep on using cryptogen and then write that cryptogen should not be used in production.
    • In all the samples, the private crypto keys are blatantly exposed [example] and there is no sample showing how to protect them in a prod environment.
    • All the samples create a network in which all the nodes are running on the same computer. There is no sample showing how to create a real-world network spanning multiple computers
    • the list goes on. Basically there is no sample showing how to write a production quality app
  • Incorrect documentation: Worse than missing documentation is incorrect documentation and Fabric is full of it. e.g., instructions on https://github.com/hyperledger/fabric-samples/tree/release-1.3/balance-transfer/typescript say that Node.js v6.9.0 – 6.10.0 ( Node v7+ is not supported ) is required whereas the instructions elsewhere say that Node.js v8.4.0 or higher. Even the HL Fabric prerequisites say that If you will be developing applications for Hyperledger Fabric leveraging the Hyperledger Fabric SDK for Node.js, you will need to have version 8.9.x of Node.js installed. I kept a screenshot of the incorrect documentation here in case it gets fixed later. This e.g., caused me lot of trouble and wasted time. As I found out thae hard way, in reality Node.js v6.9.0-6.10.0 will land you in trouble. This is because Promises were introduced only in version 8 of Node.

    Another example of incorrect documentation is here on this line

    let key = enrollment.key.toBytes();

    I preserved a screenshot here. In reality the key needs to be a string and if you use a byte array, there will be an error.
  • Missing Documentation: Hyperledger Fabric relies on a dozen configuration files. Some of them are listed below:
    • configtx.yaml
    • orderer.yaml
    • fabric-ca-server-config.yaml
    • fabric-ca-client-config.yaml
    • core.yaml
    • peer.yaml

nowhere can one find explanation of all the fields in these yaml files. More examples showing the sad state of documentation, various bugs and incomplete features [1, 2, 3, 4, 5, 6]

Some things that are unrelated to developer experience but worth mentioning (identifying open gaps):

  • No support for kubernetes [ref]. Running HL Fabric on Kubernetes requires that you provide privileged access in order to run the chaincode. There are also some other issues as well. As a result, running HLF on kubernetes and thus OpenShift, is not recommended for production.
  • I am also not sure if Hyperledger Fabric really comes with a true consensus protocol [1]
  • And it seems to come with a some security loopholes [ref]. Essentially in order to run fabric, you have to allow peer nodes access to the the docker daemon which they need in order to spin up a new container to run the chaincode; but giving this access is risky as illustrated in [ref]. That is why there is no support for kubernetes.

A list of questions I have asked on fabric DL. And on SO. Bugs I have filed against Fabric.

Conclusion: If you haven’t already made lot of investment in Hyperledger Fabric, it is best to stay away from it.

Advertisements
This entry was posted in Software. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s