In the last couple of years, I’ve been a part of creating new solutions using blockchain technology. There have been many great applications, but equally, we came across some misconceptions. Not just within the teams, but also in how the field progressed. After reading an article last month on best practices with smart contract design, I thought it was time to collect these lessons learned and my two cents and share them with you.

Of course, it’s my point of view, it would be good to hear back from you as well.

1. Don’t start a project by yourself

Are you thinking of getting a blockchain started? Many times, a company will think it best to start by themselves, and let others join in once they got something going. Discussions will start on how to protect certain data, how to separate it, how to keep it secure.

Red flags should be raised at this point on two of the key values of any proper blockchain implementation: Collaboration and Trust. Don’t start as a single party but make sure you get your partners at the table. It may take a bit more effort, but you’ll soon see if there is a viable product. And if there is data you don’t want to share; you may want to reconsider using a blockchain.

2. There is no blockchain solution

Blockchain is a component. It is used to share data among all that are connected and has built-in integrity mechanisms. It is not a complete solution; in LoB applications they generally take a small portion of the total solution.

3. A smart contract is not that smart

Despite the name, a smart contract should contain only those parts required to assure data integrity and traceability. There are many misconceptions on what should be part of a smart contract, including:

• Business rules: these tend to change; they are soft rules. Also, they may differ between companies.
• Fraud detection: A blockchain does not detect fraud, despite popular view. It does not opinionate transactions, won’t prevent theft or murder as a result of a transaction. It does provide a source of information that can be analyzed for fraudulent events.
• Calls to external systems: these should never be part of a smart contract, as it’s very specific. Most blockchain solutions do provide an event bus so you can subscribe to smart contract events.

4. Don’t centralize, it’s not a database

As with any new technology, patterns and practices will be formed. And already we see some who are willing to pick up the task of coming up with design patterns. Some even go as far as to copy the centralized design patterns and pass them off as a good idea. Two patterns I’m proposing to be made an anti-pattern in blockchain development:

1. The factory contract. In short, it’s a register of all objects of a particular type you’ve created, so they’re easier to be retrieved.
   Now the main issue I have with this is that it’s centralization at a point where it’s not needed. We all understand the difficulties when there are no CRUD operations, but learn to work with events. If you’re in desperate need of a catalog, keep a shadow administration in a database and update it using events.
2. The data registry. To solve the problem of not being able to update a smart contract definition many patterns are popping up. The data registry tries to solve a problem where you want to deploy a new version of a smart contract but keep the data in the old version. In short it introduces a data registry contract that can store data for all smart contracts, so on an update only the functions are updated. A proxy contract will be used to link to the new version so any user will not notice anything has changed.
   This concept starts at the point where someone tries to manage a long-running contract containing all data and it is supposedly hard to migrate (like the factory contract). The premise of complex long-running contracts required for centrally managing data and controlling it is diametrically opposed to the concept of blockchain, hence the trouble to get them in place.

Please don’t try to cram everything in one contract. Make sure every entity is created separately using one version of a smart contract definition. It will stay alive for the duration required and does what it needs to do to support that one real-world entity. Make them small, short-lived, dynamic and always use a circuit breaker (one of the good patterns).
And should you come across a bug, deal with it. Fix the bug, deploy new versions and kill the old ones. Since an object is contained it shouldn’t be too hard.

And finally

Blockchain technology is a great asset, it simplifies collaboration between parties when they’re ready to collaborate. It’s not a golden hammer and should not be a goal. But be practical, be open and enjoy the power the blockchain could provide.

Image source