How to Measure Decentralization in Crypto

Decentralized data storage in the blockchain

Part 1: "Decentralized data storage in the blockchain"
Before every blockchain project, there is the choice of the right framework. The market is large, but commercial offers involve the risk of license costs that are difficult to calculate.
  • Energy consumption index in Bitcoin mining: The graphic illustrates the massive energy consumption of the proof-of-work consensus procedure.
The market for blockchain solutions is growing rapidly. Research & Markets predicts the global market will reach $ 7.7 billion by 2022. That corresponds to an average annual growth rate (CAGR) of a remarkable 79.6 percent.
Blockchain technology, also known as Distributed Ledger Technology (DLT), emerged from the hype of cryptocurrencies. In the meantime, however, blockchains have left this niche behind. In a blockchain, for example, events from IoT sensors can be logged or controlled on the basis of smart contracts. Blockchain technology also allows the automated processing of business activities and audits on the basis of predefined rules, also including artificial intelligence. Blockchains thus form the cornerstone for a large number of applications in usage scenarios that now span almost the entire economy.
There is no shortage of appropriate blockchain platforms and frameworks. Just like the blockchains on which they are based, these solutions differ considerably in terms of their functionality.


But how does the blockchain work now? A blockchain, a "blockchain", is essentially a distributed database that manages a continuously growing list of data records, the blocks, with the help of a consensus procedure. Unlike conventional databases, blockchains focus on protecting data from manipulation.
A blockchain is like a distributed cash register, the validity of which the authorized users vote on when new transactions are entered. If the register is correct, the blockchain is authenticated and replicated using cryptographic algorithms.
The distributed, decentralized nature of a blockchain ensures a high level of data redundancy. The consensus procedure is responsible for ensuring data integrity: Authorized network nodes vote on the status of the blockchain using the available replicas and can receive financial incentives for their maintenance tasks. The result is an efficient, self-sufficient, decentralized data store with the ability to heal itself - and a certain potential for abuse.

Public, private, consortium

All blockchains fall into one of three categories: they are public, private, or consortium-controlled. Some frameworks support several of these blockchain categories.
Public blockchains: They (also) offer users without a verified identity unrestricted access to their functionality (anonymized / pseudonymized). Anyone interested can access all available information, submit new transactions, vote on the validity of the blocks and participate in the maintenance of the blockchain. To prevent abuse, consensus-building mechanisms are used in combination with economic incentives (such as mining a cryptocurrency). In many scenarios, however, public access to the block chain is in principle undesirable.
Private blockchains: They restrict access to a group of authorized, known identities under the control of a single organization. Typical areas of application for the private blockchain are document management and the tracking of research results.
Consortium-controlled blockchains: This hybrid form of private and public blockchains restrict privileged access to the shared ledger to a group of authorized, known identities, but unlike private blockchains, they are not under the control of a single organization, but of a group of allied companies. This should strengthen confidence in the fairness of the system. Consortium-controlled blockchains use their own consensus-building processes, which run on previously defined network nodes (partially decentralized).
A hybrid blockchain can give external partners access to carry out a set number of queries and request information on the blockchain status, while authorized write access takes place on privileged notarial nodes.
2nd part: "Consensus building is the be-all and end-all"

Consensus building is the be-all and end-all

  • Etherum 2.0: This is what the architecture looks like at a glance.
The core task of a blockchain engine is to reliably and efficiently build consensus between decentralized, self-sufficient participants in the blockchain network. This is a process for coordinating the state of the shared blockchain and transaction processing. There is an essential difference between the various blockchain frameworks in the type of consensus-building. Various mechanisms are available for reaching consensus:
Proof of Work (PoW): Used by Bitcoin, Litecoin and Ethereum 1.0, among others. In order to be able to register new transactions, the participants in question, called miners, have to qualify through the computational work, known as mining. This method of reaching a consensus is slow, requires an enormous amount of energy and ultimately leads to the centralization of power over the network in the hands of a few mining pools.
Proof of Stake (PoS): In order to be able to register new transactions, the participants who are entitled to validation, the validators, have to deposit a deposit in virtual currency as proof of their justified interest. This method of reaching a consensus is more energy-efficient and faster than PoW, but it promotes savings and slows down the willingness to pay. PoS is planned for Ethereum 2.0 and 3.0.
Delegated Proof of Stake (DPoS): Here the network participants choose the so-called witnesses in a continuous vote. Only the witnesses are allowed to witness the transaction, some of these users receive remuneration for their service. The voting rights result from the value of the inserted tokens.
Federated Byzantine Agreement (FBA): Membership is open, control is decentralized, but instead of a quorum, the procedure relies on quorum slices - subsets of the authorized nodes. The individual nodes choose themselves which quorum slices they want to trust. The quorum slices should preferably overlap in order to avoid contradicting transactions, the dreaded blockchain divergence. So the consensus comes about in a decentralized way. In addition, it is not necessary that each of the nodes is known in advance and has been checked for trustworthiness.
Raft: Network nodes split into a leader and followers or (if no leader exists) into followers and candidates for the leader. The network needs a leader to synchronize the creation of blocks and record a log. Followers without a leader immediately offer themselves as candidates and hold a vote from which a leader emerges (the nodes vote on the current state of the blockchain; this creates a consensus). This node then sends a heartbeat signal to the other participants as long as it can carry out its blockchain maintenance tasks. These then replicate the current state of the blockchain. An example of Raft is the Hyperledger Sawtooth project.
Practical Byzantine Fault Tolerance (pBFT): The pBFT model can cope with Byzantine errors, i.e. the activities of malicious nodes, under the assumption that independent node failures and manipulated messages originate from very specific independent nodes that never make up more than (n-1) / 3 of all nodes. The network essentially consists of a primary node, the leader, and backup nodes (the leader changes in a round-robin process). All nodes within the system communicate intensively with one another, whereby they have to prove both the origin and the integrity of the message transmission to the respective recipient. The honest knots then reach a consensus. The algorithm was developed for asynchronous systems. With a small number of nodes, pBFT is characterized by high performance with an impressive overhead runtime and only a small increase in latency. It is more energy efficient than a pure PoW system, but in smaller networks it is susceptible to Sybil attacks, in which one node can manipulate many other nodes. In the case of larger networks, the overhead increases again. pBFT is therefore best suited for blockchains that require authorization; in public blockchains it is used in a hybrid implementation. PBFT is used, for example, in the Hyperledger solutions Fabric and Sawtooth.
Other consensus algorithms worth mentioning are Hedera Hashgraph (aBFT consensus) and Intel's Proof of Elapsed Time (PoET).
Part 3: "Blockchain and Smart Contracts"

Blockchain and smart contracts

A large number of blockchain applications are open source. They are on Github, for example, and can be tried out and adapted as you wish. Common implementations of software solutions based on blockchain essentially consist of the following elements:
  • executable code, for example from smart contracts
  • Middleware, i.e. software for integrating external data sources, for example Omnitude, an identity ecosystem based on a hybrid blockchain
  • external applications that integrate with the blockchain, for example crypto wallets
In the first concept of DLT technology - created by Satoshi Nakamoto - a blockchain was created that could only log transactions without any additional conditions. Smart contracts, one of the most attractive features of a blockchain ecosystem, are now a core component of almost all blockchain frameworks, from Ethereum to Hyperledger Sawtooth to MultiChain.
Smart contracts are executable code that can process blockchain transactions based on additional data about the fulfillment of specified conditions. For example, it is possible to log events based on measured values ​​from IoT sensors in order to trigger automatic payments within the framework of contractual conditions under software control.
Smart contracts form the internal transaction engine of Ethereum, one of the leading blockchain frameworks. Ethereum offers a robust implementation of smart contracts as executable code for the Ethereum virtual machine, for example in Solidity or Vyper.
In addition to setting up decentralized applications, the Ethereum platform also enables DAOs (decentralized autonomous organizations) to be set up and executed on the basis of smart contracts. These are essentially economic entities that are designed in software. They have digital assets or other rights of their participants to manage and use these resources using smart contracts. Owners of the inserted tokens can vote on the fate of their DAOs.
The Ethereum blockchain currently uses the proof-of-work consensus procedure. New blocks are created through complex proof-of-work mining. Every node of the Ethereum network has to validate every transaction. This process has reduced volume and slowed transaction processing.
Ethereum settles the network fees for the remuneration of the miners in "gas", a unit for measuring the compute expenses for the execution of transactions, the processing of smart contracts and other operations on Ethereum.
4th part: "Problem: Scalability"

Problem: scalability

  • Etherum: In the two years up to the beginning of 2019, the number of transactions per day has increased more than tenfold; the problem of scalability is therefore increasing.
Public blockchains, including Ethereum, are currently suffering from acute scalability issues. The comparatively slow processing of code on Ethereum disqualifies the framework for many applications and increases interest in alternatives. Nevertheless, the number of transactions per day on Ethereum has increased more than tenfold in the last two years up to the beginning of 2019. With this network size, building consensus via proof of work proves to be decidedly too expensive and not sufficiently reliable. Not even TrueBit, a promising protocol for off-chain calculations in WebAssembly bytecode to support the parallelization of smart contracts, can solve the fundamental problem of the Ethereum framework in the long term.
Ethereum 2.0 is supposed to remedy this with a new consensus protocol. Three fundamental improvements are intended to address the problem of scalability:
  • Conversion to the modified proof-of-stake consensus procedure (PoS) Casper with Beacon Chain and Casper FFG
  • Blockchain sharding: the division of the blockchains into partitions, the so-called shards, in order to parallelize and accelerate the processing of transactions
  • eWASM (Ethereum WebAssembly), a subset of the open W3C standard specially developed for the execution of smart contracts on Ethereum
The proposed blockchain sharding is to be implemented via the so-called random beacon chain. This side chain is supposed to manage validator nodes and compare the resulting shard states. It is currently under development. Sharding should significantly improve the performance of the Ethereum framework.
The most important task of the beacon chain is to enable consensus building via proof of stake outside the current blockchain (i.e. without hard fork); Here, the Casper Validators with their deposited deposits are supposed to vouch for the validity of the blocks they have certified. Validators must transfer at least 32 ethers (around 2500 euros) from the PoW chain (the current mainnet) to the beacon chain and store them in a smart contract. The beacon chain will then branch out to the various shard chains and listen for new blocks.
The shards should enable a higher scalability of the Ethereum blockchain and the parallelization of the transaction processing. They each have their own backlink to the beacon chain. This must be certified by a group of randomly selected validators of the respective shard in order to transfer the blocks into the beacon chain.
The Ethereum community expects a higher Byzantine fault tolerance of the blockchain from Casper. Casper sanctions dishonest validator nodes and manipulative participants by having the protocol withdraw the deposited deposits.
Part 5: "Hyperledger Fabric"

Hyperledger Fabric

  • Ethereum 2.0 in action: Beacon Chain (blue), Shard Chains (green), finalized blocks (yellow) and the crosslinks.
Hyperledger Fabric comes from the development labs at IBM. The framework serves as the basis for the development of decentralized applications in the corporate environment based on a blockchain that requires authorization. The core of the platform is written in Go.
The modular architecture of Fabric allows the integration of consensus, membership and other services as loadable modules. A unique feature of Fabric is the concept of private channels (modeled on private chats). Hyperledger Executive Director Brian Behlendorf sums it up: "If you have a large blockchain network and only want to share data with certain parties, you can create a private channel with just those participants."

Hyperledger Sawtooth

Hyperledger Sawtooth emerged from the Sawtooth Lake project by Intel and is currently being further developed under the umbrella of the Hyperledger Foundation under an Apache 2.0 license. The framework supports both authorization-free and authorization-requiring blockchains.
It scales to very large networks and is strongly geared towards agility. The functional scope of Hyperledger Sawtooth includes basic functions such as controlling communication between nodes in a network, storing data in the blockchain and handling smart contracts and consensus algorithms. As the only one of the leading blockchain frameworks, it can be expanded dynamically at runtime.
Sawtooth stores persistent data in the on-chain key-value store, a binary distributed store that is available to all Validator nodes. The data can be changed with the help of transactions.Each transaction belongs to a so-called transaction family and is processed with the help of the associated handler. The handler of a transaction family receives the payload of the transaction, analyzes it, executes the necessary business logic and writes the necessary changes to memory.
Unlike in the case of blockchain frameworks such as Ethereum, Sawtooth can process smart contracts code in any programming language and store it outside the blockchain. Instead of distributing the code of the smart contracts with the blockchain, each validator node has to install software in order to be able to execute the smart contracts.
Part 6: "Blockchain as a Service"

Blockchain as a Service

Blockchain frameworks offer ample potential for developing innovative solutions that rely on massive computing power. A suitable environment for this is the cloud. Blockchain technology was previously implemented in the company's own data center, in the crypto engine of the distributed ledger. But with the advent of Blockchain-as-a-Service offerings in the cloud (BaaS), blockchain developers have gained new options for connecting their decentralized apps, or DApps for short.
Microsoft Azure has developed into the blockchain technology leader over the last few years and initially presented a blockchain-as-a-service service called EBaaS (Ethereum Blockchain as a Service) for the development of prototypes of public smart contracts based on the Ethereum blockchain. In the first implementation, however, the platform still lacked the ability to manage rights, which is why developers couldn't do much with it.
Microsoft went back to the drawing board with the wish list of the Azure users and further optimized the service. The result is an entire ecosystem of blockchain solutions on Microsoft Azure: multi-networked consortium-controlled blockchains and the powerful Coco framework
for highly scalable, confidential, consortium-controlled blockchain networks on Azure. In addition to Ethereum, Azure users can now set up other blockchain networks in the cloud, including, for example, Quorum (EEA), Hyperledger Fabric, R3 Corda and Chain Core.
In addition, it is possible on Microsoft Azure to use private, public and consortium-controlled blockchain ecosystems equally in productive operation. The latter was the real challenge. Consortium-controlled networks require the ability to manage the blockchain across multiple trading partners while ensuring increased confidentiality.
The Azure operator sees the greatest benefits of blockchain technology in the area of ​​cybersecurity, specifically in connection with identity management and encryption, both of which are prerequisites for use in the corporate environment. In collaboration with Accenture and other members of the Decentralized Identity Foundation, the Redmond-based company is experimenting with the blockchain as the basis for a cloud-based system for the secure management of decentralized digital identities (DIDs). As part of this cooperation, among other things, an encrypted data store for decentralized identities and a server called Universal DID Resolver, which is to mediate between DIDs of different blockchains, for example as part of Microsoft's own Authenticator app.
In the design announced by Microsoft, the ID of a user is to be anchored in the blockchain, while the actual identity data is secured in encrypted form outside the blockchain in the so-called ID hub. Here the data is inaccessible even to Microsoft.
Azure's leadership did not remain unchallenged for long. Above all, AWS has followed suit. According to its own statements, Amazon does not want to be tied to a specific protocol or a specific blockchain platform. Rather, the aim is to create an ecosystem that can bring as many usage scenarios as possible in a large number of industries under one roof. AWS works with T-Mobile, the consulting agencies PwC and Deloitte and the venture capital company Digital Currency Group, among others. Developers can currently set up their blockchain runtime environment for Ethereum or Hyperledger Fabric using AWS blockchain templates as a container on ECS or as a Docker container on EC2 instances.
7th part: "The pitfalls of licensing"

The pitfalls of licensing

The license conditions in the context of a software stack or ecosystem of blockchain-based solutions are among the topics that developers should consciously deal with from the start. Because with such interlocked stacks as blockchain software, changing a license at a later date is not just tedious, but basically impossible. This is due to the large number of participants who have made a contribution, do not know each other and could tacitly refuse their consent.
License conflicts are inevitable in the blockchain scene and are extremely problematic. For example, the decision-makers at Hyperledger were thinking for a while of hosting projects that would be connected to the Ethereum chain in the role of a client or that would be based on the Ethereum platform. Hyperledger could rely on the Ethereum protocol and choose a de facto standard for blockchains.
The integration was initiated by Ethereum inventor Vitalik Buterin. The Hyperledger community was accordingly open to the idea. In order to consolidate the cooperation, Ethereum C ++ (cpp-ethereum) should flow into Hyperledger. However, this project could not be implemented in accordance with the license. The terms of use of the two projects were incompatible with each other due to the use of different open source licenses. Ethereum C ++ was licensed under the GPLv3, while Hyperledger uses Apache 2.0. The integration of Ethereum C ++ in Hyperledger would have required a new licensing of the Ethereum C ++ client - with the consent of each individual developer - on Apache 2.0. The cooperation ultimately failed due to the many complexities of this project. For considerable parts of the Ethereum ecosystem, the license conditions are still not clearly specified, but they tend to be of a restrictive interpretation; one shouldn't be surprised at the result. The conclusion is therefore: So check who is using third-party code under license - even more precisely with blockchain solutions.
Hyperledger currently hosts Fabric (the flagship framework for blockchain solutions), Sawtooth Lake (an innovative blockchain with modular transaction families) and Iroha (an open source blockchain platform for trustworthy, fast and secure applications with Byzantine fault tolerance), from Ethereum, among others there is practically no trace here.
There is also another, blockchain-specific aspect of software licenses: the emergence of hybrid licenses such as JLP (Jelurida Public License), a Coinleft license. Based on the GNU GPL, it adds an additional requirement to its copyleft substructure: In order to use the Nxt software for their own code, developers must airdrop 10 percent of the coins they generate to the Nxt developer community.

Conclusion & outlook

The choice of the blockchain framework has far-reaching consequences. It influences the performance of the solutions based on it, determines the permissible methods of consensus building, the challenges of interoperability and the required degree of cybersecurity.
It should be borne in mind, for example, that once a decision has been made in favor of a commercial framework, the development of license costs can never really be predicted. A proprietary framework with a commercial license can therefore easily mean the end of the blockchain project. And even large companies often steer clear of commercial blockchain frameworks because a fee-based licensing model often has a negative impact on the size and growth of a developer community.
A challenge when dealing with the blockchain for interested companies is not least the oversized selection of frameworks. The following PDF file therefore presents the most important blockchains and their properties.

more on the subject