Blockchain and Security: Drawbacks in a Private Blockchain Development (Part II)
By Elena Derymova on ALTCOIN MAGAZINE
In the second part of my ‘Blockchain and Security’ series, I would like to continue talking about working with a private blockchain environment from scratch. We will dive into different levels of security, testing, and review any potential drawbacks. Before we start, I will give you a simple question to investigate:
Is there any sense in securing a blockchain if other components are not properly secured?
In private blockchain/DLT development, every step matters. Whether it’s choosing technology, designing architecture, setting up the environment, or developing the business logic, the security of the whole ecosystem will be impacted substantially.
In this article, we will not focus on the DevOps parts, but it’s definitely one of the most important steps on the way to build a secure and stable blockchain environment. The general advice here is to use tools that are the most compatible with the blockchain platform you’ve chosen. My favorite but rather outdated example is Hyperledger Fabric + Kubernetes.
Hyperledger Fabric’s official docs show how to build a Docker environment, but there are several reasons why it’s not always suitable for production. In this case, Kubernetes might save the situation, however, at the same time, it might create problems.
At this point, there are two ways of moving on. The first one is to use IBM Cloud, which created a Kubernetes Service that allows you to efficiently operate, monitor and scale all the clusters, as well as easily set up their products, including Fabric. Or check some open-source solutions (or implement it yourself). However, I found only one project aimed to ease the process of setting up a production-ready environment. Unfortunately, I haven’t had a chance to test it myself, but this is something worth trying: it’s open-source, flexible and still being updated.
And what about the real security concerns that might appear after the environment is properly set up?
- Trust
Full decentralization couldn’t be achieved in the private blockchain, as it’s all about control. Organizations control almost all the layers of data management, including participation and access control. This is why it’s called private blockchain or private permissioned blockchain. What does that mean for security? Probably that you should trust an organization before performing any actions or putting your data.
- Access to the block data
Blockchain is generally regarded as a transparent source of different data that could be checked by anyone anytime. Yes, if we are talking about public models. On the other hand, if you’d like to check a bunch of random information being a participant of a private blockchain, you’ll have a hard time doing so without proper permission. Even if you got the right to check it, this information might be limited by a blockchain service provider. For example, in public blockchain, you can use block-explorers or manually perform all the commands in terminal to check all the source block data, but it is not that easy in permissioned environments. Sources are usually hidden in secured containers, and block-explorers are not commonly provided by private blockchain holders.
- Nodes management
It’s no secret that private blockchain highly depends on the initial network architecture and configurations. Sometimes it could be poorly set up, turning node management into a living hell. If a node suddenly goes offline, there should be a way to immediately bring it back or replace with a running one; if a node starts malfunctioning, it should be turned off or banned. Some blockchains also require proper endorsement policy and should be configured with an ability to choose and replace endorsing nodes.
Some general security issues should be considered as well
- Integration and API
Connecting any 3rd party services to the blockchain might increase the risks of security damages. APIs and integrators are the so-called bridges between blockchain and the real world, and these bridges may play a trick with the blockchain environment. Integrating any 3rd party solutions doesn’t give you a guarantee that these solutions are well tested and don’t have any significant drawbacks.
- Lack of testing
A favorite part. How many times I’ve heard something like “Oh, we have a limited budget. Let’s cut testing!”? Too many. I promised not to touch any budget-related topics, but this is where the issues are inseparable. Tests of the blockchain core used to be absolutely underestimated, mostly because they seem to be quite unnecessary. Let’s be honest, blockchain is considered to be an autonomous unit with built-in security features. And if the public one somehow fits into this statement, private and permissioned 100% depend on the initial set up, including tests. For example, performance testing will help you check whether the blockchain is correctly set up and configured, as well as how it handles different levels of the workload and whether it needs some improvements to become production-ready; security testing will define any massive drawbacks and protect you from possible blockchain-related attacks; blockchain environment testing is necessary to check the block capacity, transaction flow, and validation flow, if any.
Testing is definitely a huge part of the development process, and it’s hard to place it into a single paragraph. More details on testing I will cover in the future parts of the series.
Conclusion
There are no perfect blockchain solutions that could be easily operated and set up, and neither are there steps that could be skipped or dropped. While considering private blockchain development, you should always pay attention to the environment and testing.
In the next parts, I would like to talk about smart contracts security and data security. In the meantime, feel free to ask me or share your thoughts on how to build a stable blockchain solution!
