...by Daniel Szego
"On a long enough timeline we will all become Satoshi Nakamoto.."
Daniel Szego

Monday, April 2, 2018

A framework for analyzing and comparing distributed ledger frameworks

Distributed technologies are getting more and more complex every day and there are an increasing number of different such technologies. For this reason it is important to set up a framework in which different distributed ledger and blockchain technologies can be analyzed and compared with each other. For the general comparison we would defined the following important dimensions:

- Transaction semantics: this dimension simply describes what can be represented by a transaction. In most simply exceptions transaction represent simply the sending of cryptocurrency from one account to another on. In more difficult scenarios, transaction represent general cryptoassets or IOU information. The other end of the possibilities are the general purpose smart contract programming languages, which provide the possibility to implement any kind of programming languages.

- Transaction structure, or rather transaction storage structure: is the way how the transactions are stored. In a blokchain based system the storage is the blockchain itself, but with other technologies like IOTA or Hashgraph, the transaction structure is rather a directed acyclic graph.  

- Transaction privacy: this dimension shows how a distributed ledger system handles transaction privacy and permissions. Most typical blockchain systems are completely public and do not handle privacy or transactions at all, meaning that all transactions are public for everyone and a transaction can be executed if one has the private key. Most cryptocurrency systems are moving to the pseudonym direction, meaning that although the transactions are public, the addresses are hard to associate with physical identities. Advanced, mostly consortium blockchain solutions, realize partial privacy meaning that some part of the transaction, like the amount to be transferred, is hidden and the rest is private. More experimental solutions offer more in the direction of transaction privacy, like with the help of zero knowledge proofs. 
Another direction is crypto-asset permission. Supposing we deal with crypto-assets, it makes sense to define different transactions for creating, reading or modifying a crypto-asset and associate permissions to these transactions. Optionally something as "delete" can be defined as well, like with creating an inverse transaction. 

- Network scope: this dimension described the scope of the P2P network. The most simple network is a private one, even if it is heavily discussed if it makes sense. The next possible solution are the consortium networks where peers of the system are not available to everyone just for a certain number of consortium members, usually concentrating on a specific industrial field. The other end of the range are the public distributed ledger technologies where the network is reachable publicly to everyone.   

- Consensus performance: clearly one of the most important part of every distributed ledger technology is the consensus mechanism. One of the major dimension how different different consensus algorithms can be compared is the performance. Performance can be best described with the average confident processing time of a transaction and the number of transactions that can be processed each second.
- Consensus fault tolerance: the second most important property of the different consensus algorithms is the fault tolerance. The sides of the coin are the simply fault tolerant systems and the maximal byzantine fault tolerant systems, where the system works even if 33% percent of the nodes are taken over by hackers. 
- Token and cryptoeconomics: last but not least, it an important feature for every distributed ledger system how much it contains tokens supporting internal or external mechanisms. Some systems do not have tokens at all, others support tokens only for different internal incentive mechanisms, but of course there are cryptocurrencies and multi-token systems as well.