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

Abstract

The general population increasingly uses digital services, meaning services which are delivered over the internet or an electronic network, and events such as pandemics have accelerated the need of using new digital services. Governments have also increased their number of digital services, however, these digital services still lack of sufficient information security, particularly integrity. Blockchain uses cryptographic techniques that allow decentralization and increase the integrity of the information it handles, but it still has disadvantages in terms of efficiency, making it incapable of implementing some digital services where a high rate of transactions are required. In order to increase its efficient, a multi-layer proposal based on blockchain is presented. It has four layers, where each layer specializes in a different type of information and uses properties of public blockchain and private blockchain. An statistical analysis is performed and the proposal is modeled showing that it maintains and even increases the integrity of the information while preserving the efficiency of transactions. Besides, the proposal can be flexible and adapt to different types of digital services. It also considers that voluntary nodes participate in the decentralization of information making it more secure, verifiable, transparent and reliable.

Keywords

Blockchain digital services trust smart contracts

1 Introduction

The connectivity of new electronic devices has increased in recent decades [1], the term internet of things (IoT) [2] has become increasingly popular. The general population in developed and medium-developed countries has stealthily adopted electronic devices with network connectivity, such as TVs, clocks, washing machines, refrigerators, etc. The same is expected to happen in cities as consequence of the increase of public smart devices such as traffic lights, lights, cameras, sensors, solar panels, etc. that even now the term “smart cities” [3] is also heard. This new concept for cities will promote the creation and use of devices connected to the network.

On one hand, all these devices have created a need for infrastructure and specific software that manages, validates, protects, and automates the information that is generated by them. On the other hand, blockchain has created new functionalities and ways of decentralizing information.

However, it still needs improvements so that implementation with multiple information flows is feasible. Nowadays, because blockchain has scalability problems with the speed of transactions, that is not possible. Once a transaction limit is reached, new transactions are delayed and become more expensive [4].

The governments of multiple countries have acted as a consequence of the increase in digital services, regulating some and implementing the digital services that they offer to their taxpayers to streamline procedures and reduce costs [5]. At the same time, citizens demand from their governments more and more transparency in the use of their resources [6]. For all these reasons, the information handled by the various digital services required to be secure to become reliable. Therefore, these services also require to increase their trust before the population can actively use them.

The governments of different countries have already recognized the advantages of blockchains. Some of them have already launched projects to incorporate blockchains into digital services. However, they have encountered difficulties functioning in the best way possible way [7]. That is why proposals that improve these disadvantages are required so that blockchain can be implemented and be feasible.

Therefore, a proposal of a multilayer blockchain is presented. The model has four independent layers of blockchain. Each layer focuses on a specific type of information, having the quality of flexibility to set up different governmental digital services that could use only some layers depending on the functionality they want to obtain.

This article presents the modeling of the proposal for a multilayer blockchain. The paper consists of 5 sections. This is an introduction; section 2 contains the necessary concepts for understanding modeling, section 3 includes the multilayer proposal, section 4 contains the results, and section 5 the conclusions.

2 Blockchain types and consensus algorithms

Blockchain is a decentralized database made up of multiple blocks interconnected by cryptographic hash from previous blocks. Its origin dates back to October 31, 2008, when Satoshi Nakamoto published the article “Bitcoin: A Peer-to-Peer Electronic Cash System" in a cryptography forum. In this paper, he proposed a distributed and politically decentralized system to send money through digital tokens. By using asymmetric cryptography, hash functions and a consensus protocol transactions can be validated by users through the same network nodes that are voluntarily connected, eliminating control of the network to a single person or organization [8].

Each node that joins the blockchain obtains a copy of the chain of blocks, being distributed in different computers, and creating a physical decentralization. Through consensus, algorithms are synchronized and updated.

The general operation of the blockchain is as follows:

In a block the information to be recorded is added. In this block, the previous block’s hash is added (which must meet the characteristics of being valid). This hash creates a link with the previous block, so the resulting blocks cannot be modified.

A nonce number is added, which is modified when the block’s hash is calculated (this is done when the block is extracted). Since the hash is necessary to comply with a specific structure, it is required to vary the content of the block and the nonce number until the expected result is obtained.

While the block is being validated, to add more information to it is impossible (i.e. it is not changeable). Validation is done following the proof-of-work mechanism used throughout the network. This process is also known as block mining. In this validation, the nonce number is modified until the block hash meets certain specifications. This verification takes some time, depending on the difficulty of the proof-of-work mechanism used.

When the block validation process is complete, the hash of that block is added to the next block, which will contain new data by then.

Any change made to a validated block will be easily detected, as the block’s hash will change completely, and thus it will become an invalid block. This will happen when the next block, which contains the current block’s hash, is validated, making any inconsistencies in the information to be detected. Similarly, the modified block will also have to be validated again, and all the blocks that appear after it.

This validation process makes the information stored in a chain of blocks reliable, given the difficulty and time required to validate the blocks in front of the modified block again.

Although blockchain emerged as a politically decentralized system, later blockchain implementations emerged that were not politically decentralized, obtaining some variants, thus generating more types of blockchain.

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].

3 Related work

In this section some work related to the separation of functions and/or information in layers on Blockchain are presented.

Cheng and Zhang (2017) in [17] present a proposal for a blockchain-based network model to improve the implementation of IoT devices, maintaining network security by combining cloud storage protocols and proposing two types of layers: external layers and high-level layers. The external layers operate centrally as cloud servers commonly do, while the high-level layers connect to external layers and behave like connected IoT devices. Unlike the outer layer, at the high-level layer, the network is decentralized.

Badr et al. (2018) in [18] describe a multilayer model for clinical patient data, resuming the model proposed by Cheng and Zhang but reconfiguring the layers into 3 main levels. The first level for the patient’s devices and sensors, the second level corresponding to hospitals, laboratories, medical bodies, etc. The third level for centralized cloud storage.

Chang et al. (2018) in [19] propose a two-layer blockchain-based model to preserve clinical patient data and ensuring their privacy. Deep learning algorithms are added and used to ensure data distribution without sacrificing data privacy.

Zhou et al. (2018) in [20] propose a multilayer architecture from which a cryptocurrency called MOAC is implemented. The proposal maintains security, decentralization and speed of transactions using smart contract functionality through two-layer splitting. The base layer is used for storing the files and the top layer to execute smart contracts.

These proposals present models of two or more layers in which different type of layers are considered. Some divide the general model into different layers and others focus only on the blockchain layers they initially defined. All seek to improve efficiency and data privacy, some by using smart contracts others do not. All proposals are tied to a specific use case, i.e. they would not work for any other type of problem. None of the proposals add document storage functionality.

4 A four-layer model based on blockchain

The blocks that make up a blockchain usually contain different types of information. Examples of this information are hash values, index tables, encrypted data, transaction information, smart contracts, among others. As far as we know, the files are not stored on the blockchain. This is because the size of the blocks will increase affecting the speed of transactions [21].

The model consists of four independent and interconnected layers. Each layer stores a different type of information that is distributed on the nodes participating in such layers. In this way, each layer is ordered and specialized on the requirements given by the type of information is being stored. These layers are the following four: Layer one: Index-Keys, Layer two: Transactions, Layer three: SmartContracts, Layer four: Files.

Layer one is dedicated to store index tables, cryptographic keys and the identifiers of transactions, smart contracts, and documents. The consensus algorithm implemented in this layer is PoW (Proof of Work) [8]. The purpose of this layer is to have the most significant distribution, ensuring its availability and security. Layer two is dedicated to transaction storage. It stores the necessary information corresponding to all transactions that take place. To improve the speed of transactions, this layer is less decentralized than layer one. The consensus algorithm implemented in this layer is the PBFT (Practical Byzantine Fault Tolerance) [22]. Layer three stores all the information related to smart contracts, the consensus algorithm implemented in this layer is also PBFT. Layer four stores the files in the formats required by the application. This layer uses the IPFS (InterPlanetary File System) [23], a protocol and a network between nodes that is used to store and share data in a distributed fashion.

Layer one is the lightest and most decentralized layer, while layer four would barely be decentralized and the one with the largest block size. Layer two must be decentralized to a lesser extent than Layer one but to a greater extent than Layer three and four. In comparison, Layer three must be decentralized to a greater extent than Layer four but to a lesser extent than Layer one and two. This will be of great importance to maintain high transaction speed and enough security. The level of decentralization of the model is variable since it will depend on the layer or layers that are required to be used for certain digital services.

Depending on the service you want to mount in the multilayer blockchain architecture, four different types of information flows are possible.

The first case is the simplest. It occurs when the service does not require storing files, nor is it going to use smart contracts (see Fig. 1). In this case, the first two layers are used. The first to store the operational data of the service and the second to process and store the transactions that occur in the service. Layer one, which has the operational data, generates the required cryptographic hashes and triggers transactions in layer two, which, once processed, inform Layer one to save their respective indexes.

Fig. 1

Flow 1: the first two layers are used.

The second case occurs when file storage is not necessary but smart contracts are. Therefore, layer four is not used. As in case one, layer one generates the cryptographic hashes that requires and the necessary transactions, which in turn can create smart contracts in layer three. These smart contracts then will contain one or more transactions triggered by layer two and will send to layer one its indexes to be stored (see Fig. 2).

Fig. 2

Flow 2: Layers one, two, and three are used.

The third case occurs when file storage is required, but smart contracts are not. Then, layer one again generates the cryptographic hashes to later store transactions in layer two. Once storage is completed, saves the necessary files in layer four and reports the respective indexes to layer one to also be stored (see Fig. 3).

Fig. 3

Flow 3: layers 1, 2 and 4 are used.

Finally, the fourth case occurs when all layers are used. This happens when a service uses smart contracts and also requires file storage. In this case, layer one that contains the operational data of the service generates their respective cryptographic hashes to generate transactions in layer two. Later the necessary smart contracts are generated in layer three, where files are created to be saved in layer four. This generates one or more transactions in layer two, which respective indexes are stored in layer one (see Fig. 4).

Fig. 4

Flow 4: all 4 layers are used.

By implementing this structure between blocks and layers, the speed of transactions depends on the number of layers that the application uses. The higher the number of layers used, the lower the validation rate of the information in the blocks is. Otherwise, the lower the number of layers used, the speed of validation of the blocks will be higher.

5 Results

In this section, a probabilistic analysis was performed to check the completeness and modeling of the overall behavior of the proposal is presented.

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} = {\begin{matrix} 1 & if x \leq y \\ {(y / x)}^{n} & if x > y \end{matrix}}$ (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 \frac{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:

$\sum_{k = 0}^{\infty} \frac{λ^{k} e^{- λ}}{k!} \cdot {\begin{matrix} {(y / x)}^{n - k} & if k \leq n \\ 1 & if k > n \end{matrix}}$ (3)

Rearranging it:

$1 - \sum_{k = 0}^{n} \frac{λ^{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).

Table 1

The probability in percentage of an attacker’s success decreasing as more blocks are generated in the chain

	5%	10%	15%	20%	25%
1	10.1203	20.45	30.969	41.589	52.23
2	1.2646	5.0977	11.504	20.392	31.54
3	0.1641	1.3172	4.4227	10.3241	19.611
4	0.0216	0.3455	1.7252	5.2997	12.351
5	0.0028	0.09136	0.6783	2.7415	7.835
6	0.0003	0.02428	0.2680	1.4250	4.994
7	0.00005	0.006473	0.1062	0.743	3.193
8	0.000006	0.0017299	0.0422	0.3885	2.046
9	0.0000009	0.0004631	0.0168	0.203	1.314
10	0.00000001	0.0001241	0.0067	0.0106	0.845

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.

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.

5.2 Proposal modeling

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, $\frac{p_{i} - 1}{2}$ messages sent by p₁ to these number of nodes.

[–] In the worst case, where all nodes have to agree, (p_i) -1 messages sent by p₁ to all the nodes on the layer.

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, $\frac{p_{j} - 1}{2}$ messages sent by p₁ to these number of nodes.

In the worst case, two thirds of nodes have to agree, $\frac{2 p_{j} - 1}{3}$ 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, $\frac{p_{s} - 1}{2}$ messages sent by p₁ to these number of nodes.

In the worst case, two thirds of nodes have to agree, $\frac{2 p_{s} - 1}{3}$ 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 > \frac{2 p_{j} - 1}{3} \geq \frac{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_iinC₁, y_iin 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.

C₂ will store transaction (T_i) on the blocks y_i that have a size between 1.1 MB and 2 MB.

C₃ will store Smart Contracts (SC) on the blocks z_i that have a size between 2.1 MB and 5 MB.

C₄ will store files on the blocks x_i that have a size between 5.1 MB and 10 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 the transaction carries the instruction to generate a smart contract, the y_i+1 block generates a z_i+1 block in C3 where a p_s node validates the block and is distributed to p_s - 1 remaining nodes.

If the transaction carries the instruction to save a file, the block z_i+1 generates a block d_i+1 in C4 where a node p_e validates the block and the file is distributed in fractions on some nodes.

Finally the block indexes and hashes are stored in a new block x_i+1 in C1, where the block is validated by the competition of all nodes p_i where at the end the first one that completes the proof of work distributes it to the other nodes p_i - 1.

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.

Level of decentralization is staggered, the lower the number of nodes the less time it takes to update all nodes with the same information, being C1 the one with the highest number of nodes.

Block size is an important factor to speed up the block distribution. Being C1 blocks of smaller size.

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.

5.3.1 Scenario 1

In our first scenario, the application requires storing the indexes of keys and transactions, so it is not needed to store files and smart contracts. In this case, the first two layers are used. The first layer stores the operational data of the service. The second layer processes and stores the transactions that occur in the service. Layer one, which has the operational data, generates the necessary cryptographic keys and triggers the transactions in layer two, which, once processed, informs layer one to store their respective indexes.

The administrator registers and configures the set of rules, policies, users, and processes of the service in a block ( $x_{i}^{r}$ ).

The necessary cryptographic keys are generated, such as hashes (), public keys k_u1 and private keys $k_{u 1}^{- 1}$ ensuring integrity and security of the information.

Users authorized to carry out transactions do that by signing transactions including the necessary complementary data. Therefore the transaction T_y is generated with the minimum number of parameters, a transaction identifier ID_y, the issuer’s signature (SenderSingX_y), and the transaction data (Data_y).

Once the transaction is carried out, the identifier of the transaction is taken back to layer one to be stored ID_y.

5.3.2 Scenario 2

In our second scenario, file storage is not necessary, so layer four is not used. Layer one generates the cryptographic keys and the necessary transactions. Layer two, which in turn will create smart contracts in layer three. Subsequently, these contracts will create one or more transactions in layer two and send indexes to be stored in layer one. As we can see, steps 1, 2 and 3 are the same as in scenario 1, therefore, these are not again presented.

Some transactions from layer 2, might generate smart contracts SC_z to automate future transactions in the services. These transactions as minimum will contain the identifier of the smart contract (ID_z), the information of the transaction that generates it (ID (T_y)) and the smart contract data Data_z.

Smart contracts generate one or more transactions when executed. Each of these transactions T_y contains the previously mentioned parameters: transaction identifier (ID_y), smart contract information (ID (SC_z)) and data transaction (Data_y).

Once the transactions have been carried out, the identifiers of the transactions ID_y and smart contracts ID_z are returned to layer 1 to be saved.

5.3.3 Scenario 3

In our third scenario, file storage is necessary, but smart contracts are not. Then, layer one generates the cryptographic keys to generate later the transactions required in layer two. Once completed, the files are stored in layer four, and report the corresponding indexes are to layer one. Steps 1, 2 and 3 are the same as in the scenario 1, therefore, these are not presented here.

In layer four, some transactions might create and store files f_d, which parameters are the file identifier (ID_d), information of the transaction that generates it (ID (T_y)) and the data in the file Data_d.

Once the transactions have been carried out, the identifiers of the transactions ID_y and the generated files ID_d are returned to layer one to be saved.

5.3.4 Scenario 4

Finally, in our fourth scenario, indexes of keys, transactions, smart contracts, and files are required, so all layers are used. In this case, layer one generates their respective cryptographic keys to generate transactions in layer two later. These, in turn, create smart contracts in layer three, where files are generated and later stored in layer four. These smart contracts create transactions in layer two, which indexes are stored in layer one. Steps 1, 2 and 3 are the same as in case 1, therefore, these are not presented here.

Some transactions might create smart contracts SC_z to automate future transactions in the services. Their parameters are the smart contract identifier (ID_z), information of the created transactions (ID (T_y)) and the smart contract data Data_z.

Some transactions might create and store files f_d, which parameters are the file identifier (ID_d), information of the transaction that generates it (ID (T_y)) and the data in the file Data_d.

Once the transactions have been carried out, the identifiers of the transactions (ID_y), smart contracts (ID_z) and saved files (ID_d) are returned to layer one to be saved.

As previously mentioned, the scenario that will be present in each moment of execution will depend on the service offered and the functionalities that such service is implemented.

6 Conclusions

The presented model can be divided into two essential parts, layer one of public blockchain characteristics and layers two, three, and four of private blockchain characteristics. In the first part, a statistical analysis is presented given the control of unknown nodes that can participate in the network. The decentralization of the information must be guaranteed so it is difficult to maliciously change such information. After reviewing the analysis performed, it should be noted that an attacker has time against him. Since its probability of success drops exponentially as more blocks are generated. The only way to win is to control 50 % or more nodes on the network, which is very difficult to do in practice.

A multilayer blockchain framework is created to deliver an efficient digital service, which decentralizes information at different levels.

After that, three model properties are formalized: (1) block generation speed, (2) decentralization level, and (3) block size. We explain how our system design meet these properties at different levels depending on the information handled by each layer.

The proposed multilayer blockchain model is sufficiently flexible, making it a generic system that can be used in differente scenarios, guaranteeing security, trust, and transparency.

Layer one nodes are decentralized, enabling the participation of nodes that want to join, which allows the validation of the blocks to be more reliable. An opportunity opens up using multilayer blockchain in IoT functionalities. For example, in smart cities where they can be interconnected with the smart contracts that the blockchain makes possible by automatically validating and executing the warrants. We appreciate the support to CONACyT with scholarship number 701979 and UNAM-PAPIIT (TA101021).

References

Lipschultz

, Free expression in the age of the Internet: Social and legal boundaries, Routledge, 2018.

Zito

, La sustentabilidad de internet de las cosas, Cuadernos del Centro de Estudios en Diseño y Comunicación. Ensayos, (2018), pp. 1–3.

Kamel Boulos

M.N.

and Al-Shorbaji

N.M.

, On the internet of things, smart cities and the who healthy cities, International Journal of Health Geographics1 (2014), 5–7. DOI: 10.1186/1476-072X-13-10.

Peck

M.E.

, Blockchain world-do you need a blockchain? this chart will tell you if the technology can solve your problem, IEEE Spectrum54(10) (2017), 38–60.

Gil-García

J.R.

, Mariscal

and Ramírez

, Gobierno electrónico en méxico, Documento de Trabajo de la División de Administración Pública del CIDE, (214), 2010.

Lamana

F.T.

, El gobierno electrónico: servicios públicos y participación ciudadana. Laboratorio de Alternativas, 2007.

Jun

M.S.

, Blockchain government-a next form of infrastructure for the twenty-first century, Journal of Open Innovation: Technology, Market, and Complexity4(1) (2018), 7.

Nakamoto

, Bitcoin: A peer-to-peer electronic cash system. Web: https://bitcoin.org/bitcoin.pdf accessed 27-07-2021, (2008), pp. 1–9.

Yang

, Wakefield

, Lyu

, Jayasuriya

, Han

, Yi

, Yang

, Amarasinghe

and Chen

, Public and private blockchain in construction business process and information integration, Automation in Construction118 (2020), 103276. ISSN 0926-5805. doi: https://doi.org/10.1016/j.autcon.2020.103276.

10.

Momoh

, Segwit (segregated witness).Web: https://www.investopedia.com/terms/s/segwit-segregatedwitness.asp accessed 27-07-2021, 2017.

11.

Bajpai

, What is bitcoin unlimited? Web: https://www.investopedia.com/terms/b/bitcoin-unlimited.asp accessed 27-07-2021, 2016.

12.

Leon Zhao

, Fan

and Yan

, Overview of business innovations and research opportunities in blockchain and introduction to the special issue, Financial Innovation pp. 28–29, 2016. ISSN 2199-4730. DOI: 10.1186/s40854-016-0049-2.

13.

Ren

and Beard

R.W.

, Consensus algorithms for double-integrator dynamics, Distributed Consensus in Multivehicle Cooperative Control: Theory and Applications (2008), pp. 77–104.

14.

Fischer

M.J.

, The consensus problem in unreliable distributed systems (a brief survey). In International Conference on Fundamentals of Computation Theory (1983), pp. 127–140. Springer.

15.

Baliga

, Understanding blockchain consensus models, Persistent4 (2017), 1–14.

16.

Garay

and Kiayias

, Sok: A consensus taxonomy in the blockchain era. In Cryptographers? Track at the RSA Conference (2020), pp. 284–318. Springer.

17.

and Zhang

L.-J.

, A blockchain based new secure multi-layer network model for internet of things. In 2017 IEEE International Congress on Internet of Things (ICIOT) (2017), pp. 33–41. IEEE.

18.

Badr

, Gomaa

and Abd-Elrahman

, Multi-tier blockchain framework for iot-ehrs systems, Procedia Computer Science141 (2018), 159–166.

19.

Chang

E.Y.

, Liao

S.-W.

, Liu

C.-T.

, Lin

W.-C.

, Liao

P.-W.

, Fu

W.-K.

, Mei

C.-H.

and Chang

E.J.

, Deeplinq: Distributed multi-layer ledgers for privacy-preserving data sharing, In 2018 IEEE International Conference on Artificial Intelligence and Virtual Reality (AIVR) (2018), pp. 173–178. IEEE.

20.

Yang

, DavidChen

, Zhou

and Wang

, The moac platform: Advancing performance with layered multi-blockchain architecture for enhanced smart contracting. Web: https://www.moac.io/uploads/MOAC_White Paper.pdf Accessed 6 Mar 2020, 2018.

21.

García-Morales

, Luces y sombras sobre el impacto del blockchain en la gestión de documentos, Anuario Think EPI12 (2018), 345–351.

22.

Castro

, Liskov

, Practical byzantine fault tolerance and proactive recovery, ACM Transactions on Computer Systems (TOCS)20(4) (2002), 398–461. DOI: 10.1145/571637.571640.

23.

Steichen

, Fiz

, Norvill

, Shbair

and State

, Blockchain-based, decentralized access control for ipfs. In 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (Smart-Data) (2018), pp. 1499–1506. IEEE.