In a software project, good developers make use of so-called best practices. These are a collection of experiences and achievements of already completed projects. A project in Hyperledger Fabric is also a software project and has its best and worst practices. Unfortunately, these practices are not so widespread in the Hyperledger Fabric environment. During my career in building Hyperledger Fabric solutions for large clients, I could identify several best- and also worst-practices.
I had few conversations with blockchain developers especially for Hyperledger Fabric and we discussed those practices. In this article, I want to highlight three of them that should be avoided when you are on a real project:
Don't implement it in your favorite programming language.
Don't overestimate the transaction throughput.
The project is not finished without on- and offboarding procedures.
1. The favorite Programming Language for the Chaincode
At the beginning of every Hyperledger Fabric project, you should ask yourself which programming language will be used for the chain code or smart contract. With the latest version 2, the languages Java, Go, Typescript, and Javascript are available for selection. According to the figure, you can see that most developers provide a background in Java. Hyperledger started in 2015 with the Go language and developers who have been involved from the beginning have written many PoCs in this language.
What I observe here is that decisions here are made too stubbornly. Hyperledger Fabric aims to create trust in B2B business through decentralization without the involvement of intermediaries. Therefore, the Eco-system is committed to identifying early the developer know-how of the industry it is in. The choice of the right programming language has the following implications.
For a smartcontract to be used within a network, it must be reviewed and approved by all (unless otherwise defined) participants. Ideally, the development of the chaincode is done decentrally by the participants themselves. If one of the participants lacks the skills, it can lead to delays or even rejection of the chaincode.
Furthermore, a non-familiar programming language may have barriers to entry for onboarding additional participants into the network, because the missing technical expertise must be purchased.
The goal should be to use a widespread industry-standard programming language for the chaincode so that participants in a network have the opportunity to understand the code and develop it further if necessary.
2. Keep your data lean in your chain
It should be self-evident for every developer that too much information in a database leads to the fact that reading and writing into it takes longer. In terms of performance, a blockchain is not as fast as a conventional database. How could it be? Every transaction requires an endorsement process and is shared with the entire network.
Unfortunately, I still see many solutions that overwhelm the blockchain with data and use it as a mass data store, which isn't one. There are two types of criteria that every blockchain engineer has to There are two types of criteria that every developer must face. Firstly, there are the technical requirements, which are technology-dependent and must therefore be considered individually.
And on the other hand, there are business requirements. Which data should be managed on-chain or off-chain? Which data is relevant for an endorsement mechanism? All these questions have already been answered by me in another article, which you can read here.
The bottom line here is that the blockchain should only contain data that is really predestined for decentralized management.
3. The next generation needs clean onboarding
Most companies start with a proof of concept to evaluate the defined use case. The various participants in the network are usually simulated until they are actually onboarded onto the blockchain.
For a developer, the project is usually over when the chaincode is fully implemented and the network is deployed on the customer side. From this point on, the consultants start to present the product or the platform to the simulated participants together with the customer and to demonstrate the added value to them.
If the talks are successful, the first technical hurdle already follows. The participant has to be onboarded and the developers are on the next project or not available.
Potential participants often ask what they have to do to join the solution. It is therefore indispensable to think about onboarding topics early on. As a developer or architect, onboarding procedures must be developed before the project is finished, because this is the only way to avoid the big hurdle of scaling.
Conclusion
In this article, we've looked at 3 potential things to avoid. Choosing the programming language for the smart contract based on the industry standard, carefully selecting or minimizing the data that is stored in a blockchain, and making onboarding as seamless as possible.
These points extremely limit the further development and scalability of the blockchain solution and should therefore be addressed early on.
Are there any other things you can think of then post them in the comments or leave me feedback. Otherwise, I wish you a happy new and successful year.
Comments