What’s wrong with Corda R3 and how ALEHUB maintains private
blockchains?https://medium.com/@alehub/whats-wrong-with-corda-r3-and-how-alehub-maintains-private-blockchains-5bc85da9da7fCorda is a project developed by R3 foundation, which was being supported by some powerful financial institutions from time to time. Among rivals we can name Hyperledger Fabric and Ethereum (more precisely Enterprise Ethereum Alliance). For a rather long time Corda pretended to be quite a perspective undertaking: it contains interesting implementation of some core ideas of Bitcoin while preserving confidentiality and anonymity — although in a little bit restricted and far-fetched way. However, financial industry was interested in the system and many banks experimented with it.
But recent news has shown that, possibly, the project is not as strong as it seemed to be at first glance. If we believe the news, consortium is running out of money. The facts are controversial and the sources of information are unclear. But as some sponsors left the project in 2016 and new investors do not pay as much attention to it as it needs, it’s worth saying that there is no smoke without fire.
However, this article is not about financial or marketing reasons for possible failure of Corda. As mentioned before, this system contains interesting, but nevertheless controversial implementation of Bitcoin ideas. Of course, this platform is based on blockchain — like the majority of projects embodying distributed ledgers. But also Corda implements the concept of Unspent Transaction Output (UTXO). In case of Bitcoin this approach provides users with high level of anonymity, which is sometimes used for illegal financial operations.
If we suppose that all the financial crimes are not likely to happen, this is the point where the nature of cryptocurrency shows its positive side. UTXO demands checking the complete history of transactions to ensure that each transaction which performed state transition in the past is correct. But each block contains a list of transactions which requires checking the complete history of transactions for each UTXO. In Bitcoin all the UTXO sequences start as rewards for miners. When UTXO is spent, only one check is required: the validation of block with initial UTXO. Latter transactions do not require complete checking of all the history, as only correct UTXO can enter the blockchain in the form of block. This is possible only thanks to the distributed nature of blockchain: every full node maintains complete version of blockchain and performs validation whenever a new block or a new transaction for mining arrive.
The core idea of the previous paragraph is that blockchain of Bitcoin has a specific validation algorithm which allows to maintain integrity and correctness of transaction flow iteratively, on the basis of previously validated blocks and transactions. However, it’s interesting that in Ethereum (which is thought to be the successor of Bitcoin) there is no such concept as UTXO. Ethereum is built upon state transition machine, i.e. it is system with states, and transitions are performed by applying transactions to the state in a pre-defined order. The more interesting it is that Corda preferred UTXO to state transition machine.
As developers of Corda said in their materials about the system, the only individuals who really need to know about transaction between Alice and Bob, are actually Alice and Bob — and, possibly, some regulator. Thus Corda provides maximum confidentiality of transactions — as the transactions are shared only by concerned parties. Such approach has some advantages. The risk of leakage is minimal, the system does not store multiple copies of transactional information and the model is simple to comprehend.
The ill-intentioned activities in Corda are prevented by Know Your Customer (KYC) and Anti-Money Laundering (AML) policies. These are maintained by public key and digital certificates infrastructures. Every user has a certificate issued by some certification center. The certificate contains credentials granted when transactions are performed to follow the policies and to protect customers and clients from malicious activities.
But all the pros are canceled by one simple con: the blockchains are actually private. All the parties in Corda possess their own sequence of transactions. There are no actual blocks here and mining is not needed. When transaction is performed, it consumes one or more UTXO as inputs and creates new UTXO to be spent in the future. This is exactly the model of Bitcoin assets flow. The key problem about it is the necessity to check all the transactions (more precisely, credentials) which preceded the performed transaction. This undermines the anonymity and confidentiality up to some limits. The absence of blocks makes the simplification of validation impossible and requires to perform complete verification of transaction history which will become more resource-consuming over time.
It is also important that Corda is vulnerable to double-spending attacks which requires using special oracles to prevent attackers from performing such kind of attack. Oracles are some parties in the network which are responsible for registration of transactions consuming some UTXO. Thus, when accepting the payment, user has to ask the oracle whether UTXO is already spent.
ALEHUB borrows the model of private blockchains but only up to some limit. The fact that only concerned parties should maintain the state seems correct and reasonable. Storing project data in completely distributed systems gives more questions than answers:
Is there any time limit for storing data?
What is the price for storage?
How parties which do not perform mining should be rewarded?
Are there any limits for consumed space?
Not to mention the fact that some projects require enormous space for storage (of course, we mean big data here). The prohibition of such projects seems purblind considering the increasing role of such projects in scientific and practical spheres. Moreover, some projects can contain critical information, which should not be disclosed in any circumstances. This either requires using private blockchains, or encryption of data, which brings us to the issue of block verification. Encrypted data mathematically is indistinguishable from random. Thus it is impossible to check the contents of uploaded files. Which again requires solving previously stated questions.
Private blockchains in ALEHUB are special data flows which are shared between concerned parties. Such blockchains can be many in each project, there is no restriction for amount. This approach helps to perform access control: each blockchain has access control list which can be violated only by the will of some concerned party, which will cause consequences. This is not much different from current situation when freelancers are able to divulge some information concerning the project. The same problem is characteristic of any business: the problem of insiders is among the most difficult to solve in the sphere of information security. The only way to protect against such activities is the pre-determination of liability. Sometimes the division of data flows can be reasonable: often the parts of some system have no significance while the system itself is important and expensive. When different contractors create different parts of the system, it is far more challenging to perform malicious actions.
The internal structure of private blockchains is simple and is determined by framework which reminds of Google ProtoBuf. It depends on the application and the project. Still headers of blocks are structured and contain hash-sum of previous block, digital signatures of concerning parties and some other system data. Blocks of private blockchains can be registered in high-level blockchain to prevent malicious activities of business partner. This might help in case of controversial situations at the end of project or in case of dispute.
Also it’s worth mentioning that even one private blockchain can be partially shared between contractors. This is achieved thanks to the structure of blockchain. As headers contain all the required information to verify the blockchain, only headers must be shared by all contractors working with the private blockchain. This reminds of Simple Payment Verification (SPV) achieved by such structures as Merkle Trees.
To sum up, ALEHUB uses and develops the undertaking of R3 Foundation and improves the concept of private blockchains. The approach allows to achieve confidentiality of project data while preserving distributed nature of ledger based on blockchain. That is all the participants possess only required information: the contractors and the clients — all the information concerning projects (taking access control into account), and all the users in the system — the blockchain which contains all the financial and contract information which allows to achieve transparency and sustainability of the system and its financial model thanks to mutual control.
Stay tuned with us, soon we’ll have more good news about our project and the development process.
