- All Categories
- Augmented reality
- Business Intelligence
- Front End & UI Platforms
- IT business
- Java development
- Mobile development
- News and events
- Platforms and frameworks
- Project management
- Software engineering
- Software modernization
- Test automation
- Video and live streaming
- Web design
- Web development
How to choose a private blockchain… kind of thing
As soon as you’ve decided that blockchain or distributed ledger is the technology your business cannot flourish without, the question of choosing the right one between those two comes up. There are plenty of promising projects out there that can be adjusted to your needs. The only way of making up your mind is to take into account all the important criteria.
Structure & Data
If you want to share some data between nodes (connection points) and don’t need to keep an entire history of all the transactions (append-only data structure) you can go for a Distributed Ledger. It is a database that exists across several locations or among different participants. Although it doesn’t hit the headlines as Blockchain does, Blockchain is just one type of a Distributed Ledger. The main difference between them is that, unlike blockchain, a DL does not necessarily need to have a data structure in blocks. Being not dependent on the previous block, DL reaches a very good speed of transactions. The most vivid example of DL is R3 Corda.
Storing big files in the blockchain is not a great idea. Information is added in blocks, limited in size, so it is impossible to add a big package of data at a time. If you are sure you need not just hashes, but also tamper resistance, visibility, decentralization for your files, consider Storj and Sia.
All enterprise-focused systems assure to be permissioned ones, but in most cases, it’s simple role management. Multichain – an open platform for building blockchains – has the following list of permissions: connect, send, receive, issue, mine, activate, admin. It’s a pretty good and flexible list, but when you create a smart contract with completely different entities and roles, this list won’t help. You won’t be able to specify the existing permissions, for instance, to grant different access according to the hierarchy (admin, super admin, owner, staff, guest) or ban a particular group of people from buying your product (e.g. to forbid those who are underage to buy alcohol), etc… So be ready to implement your own permissions system.
Most chains save data in key-value storages like LevelDB. They are very fast and good at simultaneous writing, but to find and sort the information out you have to duplicate all the data in a separate general-purpose database and keep this copy up to date. However, there are blockchains where you don’t have have to do it. Hyperledger Fabric supports extended queries thanks to CouchDb, EOS, and BigchainDB thanks to MongoDB. Also, Credits has query capabilities with Credits DBMS.
Market conditions are changing and the conditions of deals are changing along with them. In this respect, immutability – one of the main advantages of blockchain – becomes a disadvantage that developers should cope with when they want to upgrade a smart contract. Migrating data to a new contract can take a lot of resources and lead to unwanted issues like errors, stealing the money from the contract account, changing the data by someone who isn’t supposed to do it, and many others. Thus, if these procedures might occur quite often, then it’s important to choose a blockchain that will handle this problem as fast and smoothly as possible.
In Hyperledger Fabric you can change the contract or even write a new one independently on a channel state. As Hyperledger Fabric splits into channels, the modifications you want to make will be applied only to the channel with an existing contract. Similar to this, you can upgrade a contract in your private installation of EOS.
The term is self-defining: it’s a mutual agreement among the participants on the state of all data. The type of consensus depends on the way it is reached, for example by a voting requirement of a simple majority or by using some validators, etc. Although you might hear about many types of consensus, in reality, there’re just a few that make sense within a private blockchain. These are PoA, BFT, Raft.
Not all blockchains have the same requirements for privacy. In some of them, the process of adding new participants may cause certain inconveniences. E.g. in Hyperledger Fabric you will have to update a channel block and upgrade a chaincode. Also to make sure a participant has got encrypted data you have to wait for him to be online otherwise the information can be lost. The only chain that natively allows to revoke access to the previously granted data is Hyperledger Iroha. To make a private transaction in Quorum you have to wait for all the participants mentioned in the privateFor field. That’s not a good choice if you want to restrict access to some information within a chain, for example, to interact with a particular participant without other participants seeing it.
If exchanging the assets is your priority consider financial chains. They are fast and easy to understand. Some of them even support creating your own native assets, e.g. Stellar, Credits, BigchainDB, NEO, NEM, MultiChain, Hyperledger Iroha, Chain Core, Openchain.
There are three projects that allow you to create your own transaction handler and do absolutely what you want, e.g. work with the state on a low level or run any code, Substrate, Tendermint, Hyperledger Sawtooth. These frameworks allow you to focus on business logic of your chain, not on consensus, validating blocks, and storing them. If you want to create your own consensus and exchange special signals, instead of blocks, consider libp2p.
Here’s the inconvenient truth: the amount of energy consumed by blockchain technology is comparable to that of a small country. The good news is that it relates to chains based on Proof-of-Work consensus (e.g. Bitcoin). PoW is the first consensus algorithm for a blockchain to secure data, but, fortunately, not the only one. There are other options such as a Proof-of-Authority consensus which allows pre-selected nodes to run a chain, using about the equivalent energy of a light bulb. Hyperledger is a good example of a private blockchain that uses PoA.
The ability to directly interact with peers like in R3 Corda also significantly decreases energy consumption, because there is no necessity to broadcast and validate blocks.
Again, it depends on the types of consensus. The only slow one is PoW. The others are fast enough. Of course, it’s hard to compare the speed of a really decentralized system with a highly optimized and scaled database cluster, so keep in mind that interacting within a blockchain still can be a bottleneck in your architecture.
There’s no one-size-fits-all solution. But it doesn’t mean that you have to tolerate the features you don’t really need. Feel free to combine! By adding something you are interested in and cutting off anything useless, you will eventually come to what is best for your business!