By Lenn Bass
Blockchain is the new hype. Following Gardner’s hype-cycle, it is probably just over the initial peak (which I tend to agree, given my paper I will present here at ICSA). Basically, one needs to see blockchain as another type of technology. So, what are its basic elements? In essence, we can identify three elements:
- Contracts
- An immutable history of transactions
- cryptographic encoding
The first element comprises the “what is put on it?”. For example, in the case of crypto-currency: who transfers what to whom? There are two types of contracts: explicit and implicit. An explicit contract allows to create code to specify the rules, such as Codechain for Hyperledger fabric (by IBM), or solidity for Ethereum. In an implicit model, the environment dictates the rule, for which bitcoin is the most well-known example.
Next comes the immutable history of transactions. In fact, this is the idea of a distributed ledger, on which you can only put new things. The idea is that each next block stores the hash of the previous block, such that if you want to alter a block, you need to edit all other blocks. As the blocks are both distributed over all peers, and calculating a new hash is very expensive, changing an element basically becomes impossible. By using a Merkle Tree, checking the validity of the chain becomes O(log N), instead of having a normal linked list implementation. Key remains: it is simple to check, but difficult to create.
Last element is the cryptographic encoding. Much depends on the principle of Quadratic Span Programs, or zero-knowledge proofs. The key idea in this approach is that, following Diffie Hellman’s SSH algorithm, two public keys are generated: a prover and a verifier key. For the fact what I prove, I use the public prover key. The way the keys are generated should remain private. This way, anything in the contract can remain secret. Only the fact that I proved it is on the blockchain, which can be simply verified using a verifier key. There is the zerocoin example that shows these principles.
By now there are many different technologies available. Hence, we can start evaluating it as in any software architecture: why and when should we choose a blockchain? What do we put on the chain? For example, is it possible to put something on the chain that represents the data (e.g. a hash) instead of the actual data? Or, do we need immutable data? What type of concensus mechanism do we need? etc. This way, blockchain technology becomes part of trade-off analyses, in which software architects are trained. So, use it well-informed, instead of just following a hype…
His slides can be found at slideshare.