Modeling a multi-layered blockchain framework for digital services that governments can implement

2.1 Types of blockchain

In general, three types of blockchain are identified. In a public blockchain, any node can join the blockchain network, download the complete chain of blocks, and even, in some cases, add its information to the blocks. Only specific computers authorized by the owner of the network can participate in a private blockchain. A consortium blockchain is when the network is managed privately but by organizations that share the responsibilities of monitoring and maintaining this network.

The main advantage of private blockchains is the high speed of transactions that you can obtain, so they are also more efficient when controlling the equipment that makes up the network. Consequently, they also use less electrical energy compared to a public type blockchain [9]. Although private blockchains can make the content of their blocks public, then content could be vulnerable by the blockchain owner since the teams that control the blockchain are in their possession. They could make changes in past blocks because the older the block, the more difficult it will be to modify it. In public blockchains, it is almost impossible to modify a past block. Therefore, the information is highly reliable, and, certainly, it will not change for the interests of some. However, to keep the network protected, it is necessary to implement a robust consensus algorithm that protects the information against possible nodes that maliciously modify the data. In the case of the consortium blockchain, it can share the responsibilities of maintaining the blockchain among the participating organizations. These shortlisted organizations determine who can submit transactions or access the data.

Depending on the blockchain type used, one can obtain different behavior in the network, making necessary to define the type of service you want to implement to choose the best one.

Once the best type of blockchain has been selected, we can ensure security on the information. The speed of transactions per second that the network can perform is another point to improve. Various proposals have emerged of different degrees of modification to the original blockchain to enhance the scalability of the speed of transactions in blockchain. The former sought to solve the problem without modifying the operation of the blockchain, one of which was to increase the size of the block by a particular percentage [10]. However, these solved the problem partially. Later, it was proposed to remove the block size limit [11], but that would generate large blocks, and only companies with large amounts of storage could be miners. This would make the blockchain network centralized. There are other modifications similar to those mentioned, and in general, between one and the other, two of the following three attributes can be obtained [12]: security, decentralization, speed of transactions. The critical part for a blockchain to define its attributes is the consensus algorithm it uses.

2.2 Blockchain consensus algorithms

The consensus algorithms were created to support group decisions, where each individual within the group participates and supports a decision that will work best among the group members. It is a form of democratic resolution in which the members support the decision of the majority. Consensus is easy when everything is going well. However, when failures arise due to various circumstances such as imperfect channels, participant drops, violation of synchronizations, or even when some may conspire so that this consensus does not occur (malicious behavior), other more complex requirements for consensus arise. This is the case on distributed systems and decentralized systems where the failures mentioned above usually occur [13].

Then, a consensus algorithm is a protocol used to agree on a single data value between distributed systems or processes. These algorithms are mainly used to achieve reliability in a network involving multiple distributed nodes containing the same information [14]. In the case of the blockchain, the consensus algorithm is the element that defines how the blocks are created, distributed, and validated [15]. Different proposals for consensus algorithms have emerged to optimize blockchain implementations depending on the properties that blockchains must maintain. More information on the characteristics of these consensus algorithms can be found in [16].

5.1 Block integrity validation

The proposal of a multilayer model represents a possible solution to the problem of trust in digital services. It allows a higher decentralization of information, and by the creation of layers, better management is carried out. In this way system efficiency due to the speed of transactions is not reduced when transactions are created by a service.

In the multi-layer architecture proposed, the integrity of the information is key and currently crucial in all systems. If data integrity is not guaranteed, to have an effective and efficient system is useless. The integrity of the information is inherited from the same original characteristics of the blockchain.

On one hand, layers two, three, and four the integrity of the information rests mainly on the trusted nodes in charge of validating transactions, since they uses consensus algorithms implementing private blockchains. The set of cryptographic techniques used in these consensus algorithms makes easy to identify when a node wants to act dishonestly, because the node must authenticate itself and through the use of hashes it is possible to detect who issued the transactions.

On the other hand, layer one uses a consensus algorithm that implements a public blockchain. In this type of blockchain, the origin of the nodes that join the network to verify transactions is unknown. The objective is that anyone who wants to participate can do it, therefore, the information is susceptible to malicious modifications. One consensus algorithm used in these type of blockchain is PoW that has proven to be strong in the face of these events. In this case, analysing how the integrity property is guarantee on PoW is important.

This analysis is taken from the work [8], where the first and most popular cryptocurrency, Bitcoin, is presented. This work concludes that it is computationally hard to maliciously modify the information contained in the blocks and later argue that that modified data is valid.

Below is the probability that an attacker will achieve honest block generation. The attack consist on a node generating an alternative chain (one that gives it some benefit) and later trying to make that alternative chain a valid one.

x is the probability that an honest node is the one who validates and adds the following block to the chain.

y is the probability that a attacker node will validate and add the following block to the chain.

y _n is the probability that the attacker node reaches the chain integrates from n blocks behind.

x n = { 1 if x ≤ y ( y / x ) n if x > y }(1)

Assuming that the computational power (and not the number of nodes) of honest participants is greater than the computational power of participants who want to modify the information to their advantage (dishonest nodes), it is verifiable that the probability drops exponentially as the number of blocks the attacker has to reach increases. With the probabilities being against the attacker, if he does not have a lucky break that gets him ahead from the start, his chances will fade as he falls further and further behind.

The time a given receiver would need to wait to be sure that a transaction is valid and will not change is obtained as follows: the sender is assumed to be a malicious node that wants the receiver to believe (at least for a while) that malicious information it has managed to add to a block (e.g. trying to spend the same token twice) will change that information at its convenience. The receiver will eventually receive a warning when this happens, but the sender hopes that it is already too late. Once the transaction has taken place, the malicious sender must hurry and secretly validate new blocks on a parallel chain containing an alternative version of its transaction. The receiver waits until the transaction has been added to the block and n blocks have been added after it. It does not know the amount of progress the attacker has made, but assuming that honest blocks have taken the expected average time per block, the attacker’s potential progress will be a Poisson distribution with an expected value:

λ = n y x(2)

To get the probability that a rogue node can add the last few blocks, we multiply the Poisson density for each increase in progress it could have made by the possibility it could have reached from that point:

∑ k = 0 ∞ λ k e - λ k ! · { ( y / x ) n - k if k ≤ n 1 if k > n }(3)

Rearranging it:

1 - ∑ k = 0 n λ k e - λ k ! ( 1 - ( y / x ) ( n - k ) )(4)

The probability results are calculated in the first 10 blocks, in increments of 0.05 from y = 0.05 to y = 0.25 (in percentage 5% -25%), which represents the maximum probability of 25% of rogue nodes adding the following block (see Table 1).

It can be seen that in case of y = 0.05 in block number 3 the attacker has less than 1% success and the same happens in block 4 when y = 0.10, for y = 0.15 the block is number 5, while for y = 0.20 it is in block 7 and for y = 0.25 it is in block 10.

The analysis shows that although the attackers have an excellent initial probability of violating information, as more blocks are added to the chain, the likelihood of being successful decreases exponentially (see Fig. 5). For the analysis to be valid, it is assumed that the attacker must maintain his initial computing power of the attack and continue without being detected.

OPEN IN VIEWER

Fig. 5

Exponential downward trend as more blocks are generated.

A well-decentralized blockchain network makes it difficult for a single node to have 25% processing power or more. Still, the calculations were made assuming that the attacker starts with 30%, 35%, 40% and 45% and the block in which the attacker would have less than 1% success would be block 16, 27, 58, and 220, respectively. Therefore, also found an exponential upward behavior to approach the 50% probability of an attacker’s success. When y ≥ 0.5 or more the integrity of the blocks is at risk since it means that half or more than half of the nodes have the greatest processing power, which is why decentralization is of great importance, to greater decentralization greater the difficulty for a set of nodes to exceed 50% of processing power.

On the other hand, it is observed that the probability that attackers with sufficient computational power, when trying to modify the information and want to make it pass as good. Should have several strokes of luck in a row and find the valid hashes faster than the other nodes to give the chain dishonest as it is correct. That time plays a role against them because as the chain grows, their probability decreases exponentially. Eventually, they will no longer represent a risk and assume that they are not detected and blocked before.

The following section establishes the definitions and properties that define the unique architecture of the multilayer proposal.

This section includes the modeling of the proposal. To do so, we will first present the notation used for it. This includes each of the elements of the model presented in 4. The main element of our proposal is a layer. Thus, we present the following definition.

Definition 5.1 (Layer) A layer is a logical separation in our model that processes the predefined types of information. It also includes a set of blocks. It is denoted as C. Each layer has a number of nodes that are responsible for executing a consensus algorithm and later storing a copy of the blokchain. Definition 5.2 (Nodes) The nodes are electronic devices connected through a network. Nodes are capable of creating, receiving, or transmitting information over a communication channel. They collectively execute a consensus algorithm to validate blocks that later will be stored on the blockchain. They are also responsible for the reliability of the stored data. An individual node is denoted as p. Blocks are where information is stored and are defined as follows.

Definition 5.3 (Block) A block is a component that stores different types of information. Blocks are generated by nodes p. Each layer will have a different set of blocks. Then, blocks in layer one are denoted by x, those in layer two by y, those in layer three by z, and those in layer four by d.

In the blocks, the transactions that are generated are saved and these are defined as follows. Definition 5.4 (Transaction) A transaction is a transfer of value and creates relation on different data, it is transmitted to the p _i to be validated. It is denoted as T _y .

To control the speed with which the blocks are generated it is necessary to add the time unit, which will allow configuring the block generation speed according to the needs of the service to be used, therefore the time unit is defined as follows. Definition 5.5 (Unit of time) A unit of time is the time it takes to generate a block. It is denoted as ut. In layer three, smart contracts are used. These will generate one or more transactions autonomously.

Definition 5.6 (Smart contract) A smart contract is a set of transactions (T _y ) that will be executed in a specific time (ut) once certain predetermined conditions are met. A smart contract is previously accepted and signed by all the p _i that participate in it. It is denoted as SC. The data necessary for a digital service to be operational must be considered and defined as follows.

Definition 5.7 (Application data sets) The application data can be sets of rules, users, policies, and processes that contain the service configuration and are added to the blocks of layer one. They are denoted as x i r . Each block will contain the exact time in which it was created. With that time, blocks are arranged chronologically. This time will be added as a field on the block and it is defined as follows.

Definition 5.8 (Timestamp) A timestamp is a numeric value that indicates the exact time a block was generated. It is denoted as timestamp. Another necessary property is the decentralization that each layer is going to obtain as consequence of the transaction speed and the used consensus algorithm. It is defined as follows.

Definition 5.9 (Decentralization level) The level of decentralization refers to the number of nodes required for a consensus protocol to function correctly. The higher the number of nodes, the higher the level of decentralization. It is denoted as dc. Finally, the model that contemplates the four proposed layers is defined. Definition 5.10 (Model) A model denoted as P contains a set of layers C₁, . . . , C₄, where C₁ is a set of blocks belonging to layer one, C₂ is a set of blocks belonging to layer one layer two, C₃ is a set of blocks that belong to layer three and C₄ is a set of blocks that belong to layer four.

Blockchain uses asymmetric cryptography, so the nodes use a key pair. So, the keys of a node p₁ are k_p1 (public key) and k p 1 - 1 (private key). Blockchain also uses a hash function h which, given a message m, will create the hash result m′. This operation is called h (m) = m′.

From these definitions, the following properties are defined. These describe the generation of the blocks and the connection between the lower layers.

The transaction rate is the ability to process different amounts of information in a given period. The greater the amount of data, difficult it becomes to maintain and reduce the time necessary for processing. That is why the transaction rate is affected by the size of the blocks. The level of decentralization and the speed of generation of the blocks, following properties refer to each of these.

Property 5.1 Block generation speed Depending on the digital service, a suitable block generation must be configured, however, the following must always be met:

In Layer one the set C₁ = {x₁, x₂, . . . x _n } such that x _i are blocks that are generated sequentially every ut₁ units of time.

In Layer two the set C₂ = {y₁, y₂, . . . y _n } such that y _i are blocks that are generated sequentially every ut₂ units of time.

In Layer three the set C₃ = {z₁, z₂, . . . . z _n } such that z _i are blocks that are generated sequentially every ut₃ units of time.

In Layer four the set C₄ = {d₁, d₂, . . . d _n } such that d _i are blocks that are generated sequentially every ut₄ units of time.

Therefore, the blocks are generated with the following temporal relation ut₁ > ut₂ ≥ ut₃ > ut₄.

These property is achieved by the consensus protocol used in each layer. Lets analyse each layer.

If C₁ uses PoW as consensus protocol and has p _i nodes, then the validation of a block x_n+1 created by p₁ requires:

[–] In the best case, where majority of nodes agreed, p i - 1 2 messages sent by p₁ to these number of nodes.

If C₂ uses PBFT as consensus protocol and has p _j nodes, then the validation of a block y _j created by p₁ requires:

In the best case, where majority of nodes agreed, p j - 1 2 messages sent by p₁ to these number of nodes.

If C₃ uses PBFT as consensus protocol too and has p _s nodes, then the validation of a block z _s created by p₁ requires:

In the best case, where majority of nodes agreed, p s - 1 2 messages sent by p₁ to these number of nodes.

C₄ does not use a consensus protocol, because it is used to store files in a decentralized way, but if has p _e nodes. So only two node needs to be available among all the available nodes p _e  - ((p _e ) -2).

As we can see in worse case ( p i ) - 1 > 2 p j - 1 3 ≥ 2 p s - 1 3 > p e - ( ( p e ) - 2 ) therefore property 5.2 is satisfied, layer 4 blocks will be validated and added to the chain faster than layer 3 blocks. Layer 3 and 2 blocks will have similar behavior, although layer 3 blocks will have fewer nodes compared to layer 2, so they should add the blocks faster. Finally, layer 1 blocks will take longer to be validated and added to the chain compared to the other layers.

The level of decentralization refers to two aspects. First, it is the number of nodes that keep a complete copy of the information (architectural decentralization) and, second, how these copies are maintained updated. Therefore, this property depends on the consensus protocol and the type of blockchain used in each layer.

Property 5.2 Decentralization level

Let C₁ be layer one, C₂ be layer two, if x _i in C₁ and y _j in C₂ then ∀x : f (x _i ) = x_i+1 where f receives a block x and generates the following block x_i+1 both in C₁, ∃x : g (x _i ) = y _j where g joins a block x _i in C₁ with a block y _j in C₂. Both functions f and g generate the decentralization level dc₁.

Let C₂ be layer two, C₃ be layer three, if y _i in C₂ and z _j in C₃ then ∀y : f (y _i ) = y_i+1 where f receives a block y and generates the following block y_i+1 both in C₂, ∃y : g (y _i ) = z _j where g joins a y _i block in C₂ with a z _j block in C₃. Both functions f and g generate the decentralization level dc₂.

Let C₃ be layer three, C₄ be layer four, if z _i in C₃ and d _j in C₄ then ∀z : f (z _i ) = z_i+1 where f receives a block z and generates the following block z_i+1 both in C₃, ∃z : g (z _i ) = d _j where g joins a z _i block at C₃ with a d _j block at C₄. Both functions g f and g generate the decentralization level dc₃.

Let C₄ be layer four and d _j in C₄ then ∀d : f (d _i ) = d_i+1 where f receives a block d and generates the next block d_i+1 both in C₄. The f function generates the decentralization level dc₄.

Therefore, the levels of decentralization meet the following relation dc₁ > dc₂ > dc₃ > dc₄.

If C₁, C₂, C₃ and C₄ has p _i , p _j , p _s and p _e nodes respectively, then each will have an updated copy of the blokchain. This is achieved by distributing a valid node to all the neighbour nodes.

In the worst case, each node sends the validated block (x _i , y _i , z _i and d _i ) to the rest nodes. If all the nodes perform the same action, the total of sent validated blocks is p (p _n ) -1.

But it is assumed that i > j > s > e, why it is best for each layer’s consensus algorithm, then

p _i  (p _n ) -1 > p _j  (p _n ) -1 > p _s  (p _n ) -1 > p _e  (p _n ) -1

therefore property 5.2 is satisfied.

The block size significantly influences the rapid distribution to all nodes, so depending on the digital service, must be configured adequate block size, but must meet the following.

Property 5.3 The block size

Letx _i inC₁, y _i in C₂, z _i in C₃ and d _i in C₄ then the maximum size of the information contained within the blocks, has a limit such that |x _i | < |y _i | < |z _i | < |d _i |.

The block size is defined by the designer of the application. An application can decide to use PoW to include an image as part of the transaction, with all the implications in time and cost that this decision might have. In our model, each layer will store certain type of information in each block, therefore, limiting its size.

C₁ will store index-keys on the blocks x _i that have a size between 0.5 MB and 1 MB.

If we take the worst case in each of out layers then 1MB < 2MB < 5MB < 10MB, therefore property 5.2 is satisfied.

With these properties, the number of blocks per layer is limited and their maximum size. In this way, we ensure the level of decentralization in each layer and the transaction rate of the blocks.

By joining these layers, the following behavior is created. Lets analyse one example in which all layers are used.

Depending on the use case, a different number of layers will need to be used. The following subsection describes the general architecture and the various instances in which not all layers are used.

When a transaction request is made, the requester is checked for cryptographic keys in C1, after being validated in C2 the transaction T₁ is generated, which is stored in a block y _i  + 1, a node p _j validates the block and is distributed to p _j  - 1 remaining nodes.

If we add up together all these number, then the measures of this properties for one transaction on our complete model is:

Block generation speed is high in C2, C3 and C4, in a few seconds a generated block is validated and distributed to the other nodes. In C1 the blocks would take a few minutes, until the proof of work is finished.

With the proposal, a transaction will be confirmed in the order of seconds, including the generation of smart contracts and possibly files saved. In addition, indexes are saved in a public blockchain copy. Contrary, if we do the same in an application based only on PoW, the transaction times would be in the order of minutes being not possible to store files or use smart contracts. In conclusion, the block distribution and confirmation times would increase considerably.

5.3 General architecture of information flows

In this section, we present the general architecture of our model, showing how the number of layers to use depends on the information created by a specific application. It makes our model flexible enough to be used in a variety of settings. To demonstrate this, we present four different information streams that represent the most common scenarios. It is essential to mention that even only these scenarios are presented, these are representative but not restrictive.