Regarding new/emerging technologies in the integration space, I'm quite open to investigate the potential value which they can offer. I'm a great proponent of for example Kafka, the highly scalable streaming platform and Docker to host microservices. However, I've been to several conferences and did some research online regarding blockchain and I'm sceptical. I definitely don't claim to be an expert on this subject so please correct me if I'm wrong! Also, this is my personal opinion. It might deviate from my employers and customers views.
Most of the issues discussed here are valid for public blockchains. Private blockchains are of course more flexible since they can be managed by companies themselves. You can for example more easily migrate private blockchains to a new blockchain technology or fix issues with broken smart contracts. These do require management tooling, scripts and enough developers / operations people around your private blockchain though. I don't think it is a deploy and go solution just yet.
1 Immutable is really immutable!
A pure public blockchain (not taking into account sidechains and off chain code) is an immutable chain. Every block uses a hashed value of the previous block in its encryption. You cannot alter a block which is already on the chain. This makes sure things you put on the chain cannot suddenly appear or disappear. There is traceability. Thus you cannot accidentally create money for example on a distributed ledger (unless you create immutable smart contracts to provide you with that functionality). Security and immutability are great things but they require you to work in a certain way we are not that used to yet. For example, you cannot cancel a confirmed transaction. You have to do a new transaction counteracting the effects of the previous one you want to cancel. If you have an unconfirmed transaction, you can 'cancel' it by creating a new transaction with the same inputs and a higher transaction fee (at least on a public blockchain). See for example here. Also if you put a smart contract on a public chain and it has a code flaw someone can abuse, you're basically screwed. If the issue is big enough, public blockchains can fork (if 'the community' agrees). See for example the DAO hack on Etherium. In an enterprise environment with a private blockchain, you can fork the chain and replay the transactions after the issue you want corrected on the chain. This however needs to be performed for every serious enough issue and can be a time consuming operation. In this case it helps (in your private blockchain) if you have a 'shadow administration' of transactions. You do have to take into account however that transactions can have different results based on what has changed since the fork. Being careful here is probably required.
2 Smart Contracts
Smart contracts! It is really cool you can also put a contract on the chain. Execution of the contract can be verified by nodes on the chain which have permission and the contract is immutable. This is a cool feature!
However there are some challenges when implementing smart contracts. A lot becomes possible and this freedom creates sometimes unwanted side-effects.
CryptoKitties
You can lookup CryptoKitties, a game implemented by using Smart Contracts on Etherium. They can clog a public blockchain and cause transactions to take a really long time. This is not the first time blockchain congestion occurs (see for example here). This is a clear sign there are scalability issues, especially with public blockchains. When using private blockchains, these scalability issues are also likely to occur eventually if the number of transactions increases (of course you can prevent CryptoKitties on a private blockchain). The Bitcoin / VISA comparison is an often quoted one, although there is much discussion on the validity of the comparison.
Immutable software
Smart contracts are implemented in code and code contains bugs and those bugs, depending on the implementation, sometimes cannot be fixed since the code on the chain is immutable. Especially since blockchain is a new technology, many people will put buggy code on public blockchains and that code will remain there forever. If you create DAO's (decentralized autonomous organizations) on a blockchain, this becomes even more challenging since the codebase is larger. See for example the Etherium DAO hack.
Hello World forever!
Because the code is immutable, it will remain on the chain forever. Every hello world tryout, every CryptoKitten from everyone will remain there. Downloading the chain and becoming a node will thus become more difficult as the amount of code on the chain increases, which it undoubtedly will.
Business people creating smart contracts?
A smart contract might give the idea a business person or lawyer should be able to design/create them. If they can create deterministic error free contracts which will be on the blockchain forever, that is of course possible. It is a question though how realistic that is. It seems like a similar idea that business people could create business rules in business rule engines ('citizen developers'). In my experience technical people need to do that in a controlled, tested manner.
There is no bank in between you and the (public) blockchain. This can be a good thing since a bank eats money. However in case of for example the blockchain loses popularity, steeply drops in value or has been hacked (compare with a bank going bankrupt, e.g. Icesave) than you won't have any guarantees like for example the deposit guarantee schemes in the EU. Your money might be gone.
Updating the core code of a running blockchain is due to its distributed nature, quite the challenge. This often leads to forks. See for example Bitcoin forks like Bitcoin Cash and Bitcoin Gold and an Etherium fork like Byzanthium. The issue with forks is that it makes the entire cryptocurrency landscape crowded. It is like Europe in the past when every country had their own coin. You have to exchange coins if you want to spend in a certain country (using the intermediaries everyone wants to avoid) or have a stack of each of them. Forks, especially hard forks come with security challenges such as replay attacks (transactions which can be valid on different chains). Some reasons you might want to update the code is because transactions are slow, security becomes an issue in the future (quantum computing) or new features are required (e.g. related to smart contracts).
5 Blockchain and privacy legislation (GDPR)
Security
Security is one of the strong points of blockchain technology and helps with the security by design and by default GDPR requirements. There are some other things to think about though.
The right to be forgotten
Things put on a blockchain are permanent. You cannot delete them afterwards, although you might be able to make then inaccessible in certain cases. This conflicts with the GDPR right to be forgotten.
Data localization requirements
Every node has the entire blockchain and thus all the data. This might cause issues with legislation. For example requirements to have data contained within the same country. This becomes more of a challenge when running blockchain in a cloud environment. In Europe with many relatively small countries, this will be more of an issue compared to for example the US, Russia or China.
Blockchain in the cloud
It is really dependent on the types of services the blockchain cloud provider offers and how much they charge for it. It could be similar to using a bank, requiring you to pay per transaction. In that case, why not stick to a bank? Can you enforce the nodes being located in your country? If you need to fix a broken smart contract, will there be a service request and will the cloud provider fork and replay transactions for you? Will you get access to the blockchain itself? Will they provide a transaction manager? Will they guarantee a max transactions per second in their SLA? A lot of questions for which there are probably answers (which differ per provider) and based on those answers, you can make a cost calculation if it will be worthwhile to use the cloud blockchain. In the cloud, the challenges with being GDPR compliant are even greater (especially for European governments and banks).
If you have lost your private key or lost access to your wallet (more business friendly name of a keystore) containing your private key, you might have lost your assets on the blockchain. Luckily a blockchain is secure and there is no easy way to fix this. If you have a wallet which is being managed by a 3rd party, they might be able to help you with recovering it. Those 3rd parties however are hacked quite often (a lot of value can be obtained from such a hack). See for example here, here and here.
7 A blockchain transaction manager is required
A transaction is put on the blockchain. The transaction is usually verified by several several nodes before it is distributed to all nodes and becomes part of the chain. Verification can fail or might take a while. This can be hours on some public blockchains. It could be the transaction has been caught up by another transaction with higher priority. In the software which is integrated with a blockchain solution, you have to keep track on the state of transactions since you want to know what the up to date value is of your assets. This causes an integration challenge and you might have to introduce a product which has a blockchain transaction manager feature.
8 Resource inefficient; not good for the environment
Blockchain requires large amounts of resources when compared to classic integration.
Everyone node has the complete chain so everyone can verify transactions. This is a good thing since if a single node is hacked, other nodes will overrule the transactions which this node offers to the chain if they are invalid in whatever way. However this means every transaction is distributed to all nodes (network traffic) and every verification is performed on every node (CPU). Also when the chain becomes larger, every node has a complete copy and thus diskspace is not used efficiently. See for example some research on blockchain electricity usage here. Another example is that a single Bitcoin transaction (4 can be processed per second) requires the same amount of electricity as 5000 VISA transactions (while VISA can do 4000 transactions per second, see here). Of course there is discussion on the validity of such a comparison and in the future this will most likely change. Also an indication blockchains are still in the early stages.
Blockchain is relatively new and new implementations appear almost daily. There is little standardisation. The below picture was taken from a slide at the UKOUG Apps17 conference in Birmingham this year (the presentation was given by David Haimes).
Even with this many (partially open source) products, it seems every implementation requires a new product. For example the Estonian government has implemented their own blockchain flavor; KSI Blockchain. It is likely that eventually there will be a most common used product which will hopefully be the one that works best (not like what happened in the videotape format wars).
Which product?
If you choose a product now to implement, you will most likely not choose the product which will be most popular in a couple of years time. Improvements to the technology/products will quite quickly catch up to you. This will probably mean you would have to start migration projects.
Standards?
For example in case of webservice integrations, there are many internationally acknowledged standards such as the WS-* standards and SOAP. For REST services there is JOSE, JWT and of course JSON. What is there for blockchain? Every product uses its own protocol. Like in the times when Microsoft conjured up its own HTML/JavaScript standards causing cross browser compatibility issues. Only this time there are hundreds of Microsofts (slightly exaggerating but 50 at least).
10 Quantum computing
Most of the blockchain implementations are based on ECDSA signatures. Elliptic curve cryptography is vulnerable to a modified Shor's algorithm for solving the discrete logarithm problem on elliptic curves. This potentially makes it possible to obtain a user's private key from their public key when performing a transaction (see here and here). Of course this will be fixed, but how? By forking the public blockchains? By introducing new blockchains? As indicated before, updating the technology of a blockchain can be challenging.
How to deal with these challenges?
You can jump on the wagon and hope the ride will not carry you off a cliff or you could be careful when implementing blockchain technology. I would not expect in an enterprise to quickly get something to production which will actually be worthwhile in use without requiring a lot of expertise to work on all the challenges.
Companies will gain experience with this technology and architectures which mitigate these challenges will undoubtedly emerge. A new development could also be that the base assumptions the blockchain technology is based on, are not practical in enterprise environments and another technology arises to fill the gap.
Alternatives
Not really
To be honest, a solid alternative which covers all the use cases of blockchain is not easily found. This might also help in explaining the popularity of blockchain. Although there are many technical challenges, in absence of a solid alternative, where should you go to implement those use cases?
SWIFT?
Exchanging value internationally has been done by using the SWIFT network (usually by using a B2B application to provide a bridge). This however often requires manual interventions (at least in my experience) and there are security considerations. SWIFT has been hacked for example.
Kafka?
The idea of having a consortium which guards a shared truth has been around for quite a while in the B2B world. The technology such a consortium uses can just as well for example be a collection of Kafka topics. It would require a per use-case study if all the blockchain features can be implemented. It will perform way better, the order of messages (like in a blockchain) can be guaranteed, a message put on a topic is immutable and you can use compacted topics to get the latest value of something. Kafka has been designed to be easily scalable. It might be worthwhile to explore if you can create a blockchain like setup which does not have its drawbacks.
Off-chain transactions and sidechains
Some blockchain issues can be mitigated by using so-called off-chain transactions and code. See for example here. Sidechains are extensions to existing blockchains, enhancing their privacy and functionality by adding features like smart contracts and confidential transactions.
Finally
It might not seem like it, from the above, but I'm excited about this new technology. Currently however in my opinion, it is still immature. It lacks standardization, performance and the immutable nature of a blockchain might be difficult to deal with in an actual enterprise. With this blog I tried to create some awareness on things you might think about when considering an implementation. Currently implementations (still?) require much consultancy on the development and operations side, to make it work. This is of course a good thing in my line of work!
No comments:
Post a Comment