ECLB: Edge-Computing-Based Lightweight Blockchain Framework for Mobile Systems

)e blockchain technology achieves security by sacrificing prohibitive storage and computation resources. However, in mobile systems, the mobile devices usually offer weak computation and storage resources. It prohibits the wide application of the blockchain technology. Edge computing appears with strong resources and inherent decentralization, which can provide a natural solution to overcoming the resource-insufficiency problem. However, applying edge computing directly can only relieve some storage and computation pressure.)ere are some other open problems, such as improving confirmation latency, throughput, and regulation. To this end, we propose an edge-computing-based lightweight blockchain framework (ECLB) for mobile systems.)is paper introduces a novel set of ledger structures and designs a transaction consensus protocol to achieve superior performance. Moreover, considering the permissioned blockchain setting, we specifically utilize some cryptographic methods to design a pluggable transaction regulation module. Finally, our security analysis and performance evaluation show that ECLB can retain the security of Bitcoin-like blockchain and better performance of ledger storage cost in mobile devices, block mining computation cost, throughput, transaction confirmation latency, and transaction regulation cost.


Introduction
Since Satoshi Nakamoto invented Bitcoin in 2008 [1], the blockchain technology has gained considerable interest and adoption in multiple fields, such as economics, cryptography, and mathematics. Blockchain makes it possible to process the online trade among mutual distrust parties. e security of the blockchain technology is achieved by sacrificing prohibitive computation and storage resources to jointly maintain a unique transaction ledger. However, most mobile systems are underresourced due to weak mobile devices. As a result, it is a matter of great difficulty to apply the blockchain technology to mobile systems. Some details are shown as follows: On the one hand, each miner contributes immense computation effort to painstakingly solve a cryptographic problem, i.e., the proof of work (PoW) problem. Only the miner who first succeeds in solving the PoW problem can pack some transactions into a new valid block and append to the longest ledger. Generally, the mining machines, such as ANTMINER S9 Hydro, reach up to 18TH/s [2], while the hash rates of the normal mobile devices are just at the MH/s level. According to the statistics, Bitcoin alone is estimated to use tens of Terawatt hours per year, which is enough to power a mid-sized country. It indicates that most normal mobile devices cannot undertake the mining work because of their limited computational power.
On the other hand, each miner has to maintain an entire copy of the transaction ledger, i.e., every transaction record from the beginning of time. Storing the entire blockchain ledger requires a remarkable amount of storage capacity. Take Bitcoin as an example; the total size of a local ledger reached more than 380 GB on February 18, 2021 [3]. And, it is growing at a rate of around 70 MB per day. It is not feasible for a normal mobile device to store such a large-size ledger. Table 1 shows some ledger growth information in several different blockchain systems.
In conclusion, most mobile devices are unable to provide such computation and storage capacities to meet the requirements for working as miners. e aforementioned issues must be solved to popularize the blockchain applications in mobile systems.
Edge computing appears with inherent decentralization and strong resources, which can provide a natural solution to overcoming the aforementioned resource-insufficiency situation [7,8]. As Abbas et al. pointed out in [9], edge computing is now a promising technology in the 5G mobile environment. Each edge node locates close to the end devices at the edge network and can provide sufficient capacities of storage, computation, and networking to support the mining work. at is, edge computing relies on edge nodes to create services that are distributed across edge domains. us, constructing a lightweight blockchain system based on edge computing is a natural and appropriate way to make the blockchain technology widely used in practical mobile systems.

Challenge.
e direct integration of blockchain and edge computing can only relieve some storage and computing pressure at end mobile devices. But first, the end devices do not always work as completely light nodes. ey usually are interested in some types of transaction information, maybe related to their jobs, life, or something else. ey often want to store some transactions as well. Second, there are some other open problems, such as improving the transaction confirmation latency, throughput, etc. ese performance metrics must be optimized when applying the blockchain technology to mobile systems. It is a paradox. e reason is that, on the one hand, the high transaction confirmation latency and low throughput are caused by the computationintensive consensus protocol itself. On the other hand, the computation-intensive consensus protocol is a key to maintaining the security and stability of blockchain systems.
To sum up, the challenge is how to solve this paradox to achieve both light weight at end mobile devices and superior performance regarding transaction confirmation latency and throughput. Some related works have been done so far. Cebe et al. [10] proposed an integrated lightweight blockchain framework for forensic applications of connected vehicles, abbreviated as Block4Forensic. In Block4Forensic, each node maintains a shared ledger and a fragmented ledger. e shared ledger stores hash values. e fragmented ledger stores some transactions attracted by the corresponding participant. Liu et al. [11] proposed a mobile edge-computing-enabled wireless blockchain framework where the computation-intensive mining tasks could be offloaded to the nearby edge nodes and the cryptographic hashes of blocks could be cached in the edge servers. Chen et al. [12] proposed a multi-hop cooperative and distributed computation offloading algorithm that considered the data processing tasks and the mining tasks together for blockchain-empowered Industrial Internet of ings (IIoT). Lei et al. [13] proposed Groupchain, a novel scalable public blockchain of a two-chain structure suitable for fog computing. To some extent, Groupchain overcomes the scalability challenge of blockchain's integration with fog computing. Eyal et al. [14] proposed Bitcoin-NG, a Byzantine fault-tolerant blockchain protocol. It decouples Bitcoin's blockchain operation into leader election and transaction serialization. It introduces high generation frequency of micro-blocks for transaction commitment. Table 2 shows the advantages and disadvantages of these works.
ese works give us great inspiration to study the blockchain application problems. ere are also some other related works [15][16][17]. All these works can only solve part of the aforementioned challenges.

Contributions.
e main contributions are summarized as follows: (1) We propose a novel lightweight blockchain framework based on edge computing (ECLB) for mobile systems. It takes edge nodes as miners, to relieve some storage and computation pressure at end mobile devices. As for the mobile devices, we introduce the fragmented ledger structure [10], to let them obtain the transaction information of interest. In this proposed ECLB framework, edge computing and blockchain technology complement each other, which makes the blockchain technology applicable in mobile systems. (2) Under the ECLB framework, we reform the block structures into leader block and transaction block. e leader blocks are used to record leader nodes, who succeed in solving the PoW puzzles. e transaction blocks are used to record the transaction history via most edge nodes' signature assurance. Such a structure optimizes the blockchain metrics, including throughput and transaction confirmation latency.
(3) Considering the popular permissioned blockchain settings, we specifically utilize symmetric encryption algorithm and ciphertext-policy attribute-based encryption (CP-ABE) scheme [18] to design a pluggable regulation layer. It is a secure solution for supervising the transaction behaviors. Note that due to the low efficiency, the CP-ABE schemes cannot be readily adopted. Here, in order to meet the requirement of high efficiency, we combine CP-ABE with symmetric encryption algorithm to improve the regulation efficiency. 1.3. Structure of the Paper. e rest of the paper is organized as follows: Section 2 presents the preliminaries. Section 3 presents our ECLB system model. Section 4 presents our ECLB protocol design. Sections 5 and 6 formally analyze the security and experimentally evaluate the performance of our ECLB. Section 7 reviews the related works. Section 8 discusses the solution to the blockchain fork problems. Finally, Section 9 concludes this paper.

Preliminaries
We briefly review the blockchain technology and the CP-ABE scheme.

Blockchain. Blockchain was invented by Satoshi
Nakamoto in 2008 to serve as the public transaction ledger of the Bitcoin cryptocurrency [1]. e ledger records a continuously growing list of transactions, called blocks, which are linked by the cryptographic hash of the previous block. e general structure of the block and the blockchain is shown in Figure 1.
A blockchain is typically managed by a peer-to-peer (P2P) network collectively following a predefined consensus protocol. Each miner contributes a large amount of computation energy for packing transactions into a new block, i.e., the consensus procedure or mining tasks. As we know, PoW is a frequently and widely used consensus protocol, such as in the Bitcoin systems. PoW requires a complicated computational process for packing transactions. It is a random process where a lot of trials and errors are required on average before a PoW solution is generated. In PoW, all the miners have to use different nonces and calculate the hash value of the constantly changing block header continuously, until the calculated hash value is not greater than a given value. When one node obtains the target, all other nodes must mutually confirm the correctness of the value. Finally, a new block is generated. e flow of new block generation procedures is shown in Figure 2. A new block is determined in a round. e characteristics of the blockchain technology are listed as follows: (i) Decentralization: the blockchain is built on a P2P network, which is naturally decentralized. All participating nodes have the same copy of the blockchain ledger. (ii) Immutability: once a block is written to a blockchain, the information cannot be altered. (iii) Authenticity: users can trust that transactions will be executed exactly as the protocol comments. us, the transaction data in blockchain ledger are all authentic. (iv) Pseudonymity: blockchain uses a pseudo-identity mechanism. Each user can generate as many pseudo-identities as he/she likes to increase identity privacy.
Obviously, it should reduce the pressure of both ledger storage and block mining computation to design a thoughtful lightweight blockchain system. Simultaneously, the scalability is also an important factor to measure a blockchain system. Scalability itself includes two important metrics: throughput and transaction confirmation latency.

CP-ABE.
e CP-ABE scheme was proposed to achieve fine-grained access control [18]. In CP-ABE, a user's secret attribute key is associated with an attribute set. e ciphertext of a message is associated with an access policy. A user will succeed in decrypting a ciphertext if and only if the user's attribute set matches the access policy associated with the ciphertext. e CP-ABE scheme consists of four algorithms [18]: (i) CPABE.Setup(1 λ ) ⟶ MK, PK: it takes the security parameter 1 λ as input, and outputs a master key MK and a public key PK. (ii) CPABE.Encrypt(T, m, PK) ⟶ CT: it takes as input an access policy tree T over the universe of attributes, a message m, and the public key PK, then encrypts m Table 2: Advantages and disadvantages of some existing works.

Research
Advantages Disadvantages [10] Make each end device to maintain a fragmented ledger, to reduce the storage pressure Does not consider improving the transaction throughput and confirmation latency [11] Offload the computation-intensive mining tasks to nearby edgecomputing nodes [12] Disburden the data processing tasks and mining tasks from end devices to edge servers [13] Employ a leader group to optimize the transaction throughput and confirmation latency Does not consider reducing the ledger storage pressure at end devices [14] Decouple Bitcoin's blockchain operation into leader election and transaction serialization to achieve scalability as a ciphertext CT, such that only a user that possesses a set of attributes that satisfies the access tree T will be able to decrypt the message m.
(iii)CPABE.KeyGenerate(PK, MK, A u ) ⟶ SK u : it takes as input the public key PK, the master key MK, and a user's attribute set A u , then outputs the user's secret attribute key SK u .
(iv)CPABE.Decrypt(PK, CT, SK u ) ⟶ m: it takes as input the public key PK, the ciphertext CT of a message m, and a user's secret attribute key SK u , then outputs the message m if the user's attribute set satisfies the access policy tree associated with CT.

System Model
e conception model of our ECLB framework is shown in Figure 3. It mainly consists of the following four layers: (1) Cloud data center layer: it is in charge of storing encrypted transaction information specifically for the permissioned blockchain setting. We assume that the cloud data center is honest but curious. at means, it acts in an honest fashion and correctly follows the designated protocol specification. However, it is curious to infer and analyze the stored data to harvest additional information to gain illegal profits. (2) Edge nodes layer: each node on this layer undertakes the mining work as a blockchain miner node, i.e., solving the PoW puzzles and storing an entire copy of the blockchain ledger. Each edge node i has a public/private key-pair (pk i , sk i ). It is either honest or Byzantine. Byzantine nodes do not follow the consensus protocol accidentally or maliciously. It means that they might fail to join the consensus or collude to attack the whole network. Assume that there are n edge nodes, these n nodes are well connected in a P2P network, and the number of Byzantine nodes is f, where n ≥ 3f + 1 is required in our model [13].    Hence each end device only stores a fragmented ledger [10], consisting of the copy of the block headers and some transaction records of interest. End devices are usually too weak to be miners. ey only download some transaction information of interest from nearby edge nodes. us, they can be trustworthy or not, which has no effect to the whole network. (4) Regulator layer: it consists of some regulators and a trusted authority (TA). is layer is designed specifically for the permissioned blockchain setting. On the one hand, the regulators request to gain the transaction data in cloud to carry out trading regulation. On the other hand, considering the transaction privacy preservation, only the regulators are allowed to get the transaction data. And, they are not allowed to get the data outside of their privileges. us, the regulators are assumed to be honest but curious. e TA is in charge of controlling the access privilege, i.e., authorizing the access privilege only to the regulators. e TA is assumed to be trustworthy.

ECLB Protocol Design
In this section, we will describe our ECLB protocol design in detail, including three parts: transaction ledger storage, transaction packing and confirmation, and transaction regulation. Some major notations used in our ECLB protocol are shown in Table 3.

Transaction Ledger Storage.
In real applications, the edge nodes are located close to the end mobile devices, and have much stronger storage and computation capabilities compared with the end mobile devices. us, we take the edge nodes as blockchain miners and the edge devices as light nodes.
Specifically, in our framework, there are two chains: a leader chain and a transaction (Tx) chain. ere are two kinds of blockchain ledgers: full ledger and fragmented   ledger.
e full ledger records the identities of both the leaders and the transaction history, by packing the public keys of the leaders and the transaction records. e fragmented ledger records the block headers of the full ledger and some transaction records attracted to the corresponding end mobile devices. Obviously, the fragmented ledger [10] is specifically introduced for the end devices. Each edge node stores an entire copy of the full ledger. e structure of the transaction ledger storage is described in Table 4.
As their name imply, the leader chain packs the public keys of the leader, while the Tx chain packs the whole transaction records. e ledgers produced by both the leader chain and the Tx chain form the full ledger. All the block headers in the full ledger and a part of the transactions packed by the Tx chain form the fragmented ledger. Obviously, the size of the fragmented ledger is much smaller than that of the full ledger. e edge nodes play the role of miner nodes, and thus are responsible to store the full ledger. e end mobile devices only need to store the fragmented ledger, due to their weak resources. us, they play the role of light nodes. Nevertheless, they still can obtain the transaction information since the fragmented ledger maintains a part of transactions.

Transaction
Packing and Confirmation. Section 4.1 introduces lightweight ledger storage at end mobile devices. In this part, we will describe the scalability optimization and lightweight mining computation.
Inspired by [13,14], we construct a leader group to achieve high scalability. e edge nodes participating in the mining work form the leader group. Assume that there are n edge nodes (i.e., miners) that collectively commit transactions via new blocks, and at most (n − 1)/3 of them are Byzantine nodes.
In our ECLB, there are two chains growing in parallel: a leader chain and a transaction (Tx) chain, as shown in Figure 4. For convenience, we simply call the blocks in the leader chain leader blocks, and the blocks in the Tx chain Tx blocks. e leader chain is used to record which edge node competes successfully for serving as a leader.
In our ECLB, first each edge node tries to solve a PoW problem to mine a leader block for competing for being a leader. e leader block packs its own public keys and the corresponding reward coinbase. Once an edge node wins, denoted as Node i , a new leader block will be generated and broadcast to all the other edge nodes. Node i chooses and packs some new transactions into a Tx block by embedding its signature as assurance. In parallel, all the edge nodes still can work on solving another PoW problem to compete for being a leader. Once another edge node wins, denoted as Node j , Node j will be a new leader and the aforementioned procedures are repeated. Note that an edge node can be a leader in succession, i.e., i � j may happen. We can see that only the leader has the right to pack new transactions. Now we present the aforementioned transaction packing and confirmation process, as follows: ( (4) All the edge nodes collect the signed block from each other edge node. If an edge node obtains the signed block b t from 2/3 supermajority, meaning that all the edge nodes agree on the candidate block b t , then b t will be appended to the Tx chain. (5) Repeating steps (2)-(4) until another leader block is generated. at is, during the steps (2)-(4), in parallel, all the edge nodes work on solving a PoW problem and mining a new leader block to compete for being a leader.
e transaction packing and confirmation processes are shown in Figure 5, assuming that the edge node Node 0 is the leader who is the first to succeed in solving PoW, Node 3 is faulty.

Transaction Regulation.
In public/permissionless blockchain systems, any transaction information is available to any entity in the network, which provides much convenience to the regulator department. However, in the permissioned blockchain, only the blockchain member nodes are allowed to obtain the transaction information. Hence, an interface of reading the Tx ledger needs to be set for outside regulator department. To this end, we will design a transaction regulation protocol specifically for the permissioned blockchain setting.
Considering the requirements of both privacy preservation and secure regulation, we will employ the CP-ABE scheme to realize secure sharing of the transaction records with legal regulators. However, the CP-ABE scheme is notoriously inefficient in encryption and decryption. To solve this problem, we will utilize the key encapsulation mechanism to improve the efficiency [19,20]. First, the central control of the permissioned blockchain encrypts a symmetric key key using the CP-ABE scheme. en, key is shared with all the edge node members and repeatedly used to encrypt the valid and newly packed transaction records. Last, only the designated data consumers, i.e., valid regulators, can succeed in decrypting the key, and further decrypting the transaction records by the key. As a result, the transaction records are stored in ciphertext format in cloud server and can only be accessed by the legal regulators. e detailed transaction regulation protocol consists of the following steps: (  CT key is outsourced to the cloud for storage. In addition, the central controller sends the symmetric key key to all the edge nodes. (2) A regulator requests a secret attribute key SK u from the trusted authority (TA) in the regulator layer. e TA calls the CP-ABE's key generation algorithm to compute where A u is the regulator's attribute set. SK u is sent to the corresponding regulator. (3) e regulator downloads the key ciphertext CT key from the cloud, and uses his or her secret attribute key SK u to decrypt the symmetric key key, i.e., key � CPABE.Decrypt PK, CT key , SK u If his or her attribute set A u satisfies the access policy tree APT, he or she will obtain key, otherwise null. (4) Once a new Tx block b t is committed, the corresponding leader uses the symmetric key key to symmetrically encrypt each transaction record tx i of b t as where SE(·, ·) represents a symmetric encryption. Each CTX i is outsourced to the cloud server. is step is repeated with each new committed Tx block. (5) e regulator downloads the transaction ciphertext CTX i from the cloud, and symmetrically decrypts it by key to obtain the plain transaction records, i.e., where SD(·, ·) is the symmetric decryption algorithm corresponding to SE(·, ·). Note that the aforementioned steps (1) and (3) are, respectively, one-time computation during the symmetric key's life cycle. It can be set very long until key is leaked.
Step (2) is also a one-time computation for each regulator. Hence, the online computation cost of this transaction regulation module mainly depends on steps (4) and (5). ese two steps are symmetric encryption and decryption, which are efficient obviously. us, the real-time transaction regulation is well supported in our ECLB.
In conclusion, we design an efficient transaction regulation module specifically for the permissioned blockchain setting, by combining the CP-ABE scheme with the key encapsulation mechanism.
is transaction regulation module preserves the transaction privacy preservation and simultaneously supports efficient regulation required by the practical government department.

Security Analysis
In this section, we will provide some security analysis, including fault tolerance, the least number of edge nodes to reach a high security level, Sybil attack, double-spending attack, and chosen-plaintext attack (CPA).

Fault Tolerance.
e security of fault tolerance is analyzed by proving the following theorem.

Theorem 1.
e edge nodes guarantee fault tolerance, if the number of Byzantine edge nodes f is no more than (n − 1)/3, i.e., n ≥ 3f + 1, where n is the total number of edge nodes.
Proof. Assume all the edge nodes are divided into three disjoint sets, i. e., H 1 , H 2 and for the worst case, If the Byzantine edge nodes in B want to change the system status, they need to first mine a leader block to propose a consensus process. In this way, malicious nodes can gain agreement from supermajority edge nodes. To win this attack, it requires By simplifying equations (6)-(9), we can get erefore, all the edge nodes are able to guarantee fault tolerance if the number of Byzantine members f is no more than (n − 1)/3, i.e., n ≥ 3f + 1.

e Number of Edge Nodes.
We assume that each edge node is either honest or Byzantine, and the mining is a fair game. Let p be the probability of that an edge node is Byzantine. As mentioned in Section 5.1, there are less than f � (n − 1)/3 Byzantine edge nodes.
us, using the cumulative binomial distribution, the security probability of the leader chain is computed as Considering that in the Bitcoin, the recommended 6block-confirmation is calculated under p � 0.1 and security level ≥0.99, we will set the same adversary probability and security level. e leader chain ensures the same security as long as there are not less than 16 edge nodes, as shown in Figure 6. It means that as long as our ECLB framework is configured with no less than 16 edge nodes, the security level ≥0.99 can be guaranteed.

Sybil Attack.
Sybil attacks [21] allow a malicious participant to subvert a peer-to-peer network by creating many pseudonymous identities in order to work as multiple distinct nodes.
By using PoW to compete for being a leader, the leader chain has a natural ability to resist Sybil attacks. Recall that once an edge node becomes a leader, it is the only one to be allowed to broadcast blocks. In order to become a leader, it must solve a PoW problem, which is extremely computationally intensive. PoW raises the cost of creating a new leader identity.
us, it mitigates Sybil attacks, wherein security property is guaranteed by the leader chain.

Double-Spending Attacks.
In the leader chain, any edge node checks the collective signatures of a Tx block, in which a supermajority (i.e.1/2) of the edge nodes permit its validity. In other words, the Tx chain is under the supervision of all the edge nodes instead of a single leader. us, a doublespending attacker will have no chance to use the same coin(s) to issue two (or more) transactions [22]. Moreover, in this respect, 0-block-confirmation services can be provided for clients in a secure way.

Chosen-Plaintext Attack (CPA).
We first give Definition 1 of CPA security of our ECLB protocol. We then demonstrate the CPA security of our ECLB protocol by proving eorem 2.

Definition 1.
Our ECLB protocol is CPA secure if the transaction regulation protocol is CPA secure.

Theorem 1.
Our ECLB protocol is CPA secure.
Proof. We reduce the CPA security proof of our ECLB protocol to that of the transaction regulation protocol. As we know, there are some efficient and symmetric encryption algorithms that are secure against CPA, such as AES and DES. Hence, whether the transaction regulation protocol is secure against CPA depends on the indistinguishability of the symmetric key's ciphertext against CPA. e indistinguishability of the symmetric key key's ciphertext is guaranteed by the CPA security of the traditional CP-ABE scheme [18]. us, it proves that the transaction regulation protocol is secure against CPA. Finally, according to Definition 1, our ECLB protocol is also CPA secure. □ 6. Performance Evaluation 6.1. Implementation. We extend the Bitcoin Simulator [23] to implement the key elements of the transaction packing and confirmation process for performance analysis, with the absence of Byzantine nodes. e transaction regulation protocol is implemented using the Java Pairing-based Cryptography (JPBC) library [24]. e experimental machine is configured with Intel(R) CORE(TM)2 Duo CPU E8400 @ 3.00 GHz and 8.00 G RAM. In addition, we simulate the broadcast, sign, and verify procedures by imposing a latency of 100 ms for each edge node [13]. e reason is that the network topology is almost a complete graph, and the broadcast procedure is very fast.

Ledger Storage.
We set the size per transaction at around 256 bytes, and the size per block at 1 MB. us, one block contains around 4000 transactions. In Bitcoin, each full node, i.e., miner, stores the entire transaction ledger, while each light node stores only the block headers. In ECLB, each edge node stores the entire leader ledger and transaction ledger, while each end mobile device stores the fragmented ledger, i.e., only all the block headers and some transaction of interest. Note that the leader ledger is very small compared with the transaction ledger, since only one leader block is mined after around every 1500 transaction blocks. Hence, we speculate that the ledger storage cost at an edge node in ECLB is almost as high as that at a full node in Bitcoin. e ledger storage cost at the end mobile device in ECLB will be slightly higher than that at the light node in Bitcoin but much lower than that at the full node and the edge node. Figure 7 actually demonstrates the aforementioned speculation, where "x% ToI" represents an average x% percentage of transactions stored by each end mobile device. e ledger storage cost at light node of Bitcoin is too small to be shown. Even though the ledger storage cost at end devices is slightly higher than that at light node in Bitcoin, for 3.6 × 10 6 transactions, it costs around 86 MB to store the fragmented ledger at the end device with 10% transaction of interest. us, our ECLB achieves lightweight ledger storage at end mobile devices.

Block Mining.
In Bitcoin, each miner needs to solve a PoW problem for mining a new block. While in our ECLB, only the leader block is mined through solving a PoW problem. All the Tx blocks are created by only the corresponding signatures, which is much lighter than solving a PoW problem. Most importantly, the leader block mining and the Tx block creation procedures are executed in parallel. us, our ECLB holds lightweight and efficient block mining process. Figure 8 shows the block mining time with  6.4. roughput. We set block frequency to 1 per 10 minutes for Bitcoin and the leader block frequency as the same. Obviously, the throughput of our ECLB is shown by only the Tx chain. We test the throughputs with different block sizes. Figure 9 shows the experimental results. We observe that our ECLB achieves much higher throughput than Bitcoin of 100 times on average.

Transaction Consensus Latency.
Since the transaction commitment is submitted through the Tx chain, we only consider the transaction block commitment among the edge nodes for the transaction consensus latency. To see the scalability of ECLB's consensus process in terms of the number of edge nodes, we set the transaction block size to 1 MB, which is the maximum block size in current Bitcoin. In Bitcoin, the consensus latency is the time for at least 50% nodes to receive a block. Groupchain [13] and our ECLB have 3 and 2 rounds of interactions on average, respectively. Figure 10 shows the experimental results. We observe that our transaction consensus latency is slightly higher than that of Bitcoin and lower than that of Groupchain. But Groupchain and our ECLB allow the blocks already appended to the blockchain to be confirmed valid immediately without the 6-block confirmation, while the Bitcoin needs 6-block-confirmation mechanism.
6.6. Regulation Efficiency. We evaluate the regulation efficiency from the aspects of online transaction encryption and decryption, i.e., Steps (4) and (5)   that the other 3 steps need to run only once and can be performed offline and in advance. Figure 11 shows the online encryption and decryption time cost. We observe that they are constant and low enough to satisfy efficient transaction regulation.

Related Works
In this section, we introduce some related works in the area of lightweight blockchain and access control.

Lightweight Blockchain.
Since the advent of blockchain technology, much effort has been devoted to designing lightweight blockchain systems for decentralized Internet of ings [25]. Liu et al. [15] proposed a lightweight blockchain system to alleviate the resource occupation of blockchain and made it suitable for IIoT. Specifically, the work exploited an Unrelated Block Offloading Filter (UBOF) to detect and offload unrelated transactions, thus achieving lightweight feature. However, offloading "unrelated transactions" will hinder the transaction regulation in the future. For longterm consideration, all the transaction records should be stored completely. Qu et al. [26] proposed a lightweight blockchain model based on hypergraphs. ey used the hypergraph theory to partition the entire network into many hyperedges. Each hyperedge stores a part of transaction data to reduce the storage pressure. However, there are many nodes thus many transaction copies inside the same hyperedge, and one node might belong to more than one hyperedge. But, it brings inconvenience for transaction data sharing. In addition, high data redundancy is still not welladdressed. Cebe et al. [10] proposed an integrated lightweight blockchain framework for forensic applications of connected vehicles. In the work, each participant maintains a shared ledger and a fragmented ledger. e shared ledger keeps only hash values. e fragmented ledger keeps only some information that is of interest to the corresponding  participants. e fragmented ledger greatly inspired us to design a lightweight ledger storage format at weak end devices. Lei et al. [13] proposed Groupchain, a novel scalable public blockchain of a two-chain structure suitable for fog computing of IoT services computing. Groupchain designed a lightweight transaction confirmation protocol to realize 0block confirmation.
ere are also many other works on lightweight blockchain [15][16][17][27][28][29]. Nevertheless, all these works do not achieve light weight in terms of both ledger storage and block mining computation. A simple comparison is shown in Table 5.

Access Control.
In this section, we will discuss some related works where the access control mechanisms were designed to achieve both privacy preservation and flexible data sharing.
Identity-based encryption enables fine-grained data access control [30][31][32]. As an advancement, attribute-based encryption (ABE) defines a user identity by his/her attribute set. Sahai and Waters [33] first proposed this method to exert access control over encrypted data. Later, Goyal et al. [34] extended the ABE method to key-policy attribute-based encryption (KP-ABE), by associating a user's secret key with an access policy over attributes. e user can decrypt the ciphertext if and only if the attribute set of the ciphertext satisfies the access policy specified in his/her secret key. e encryptor exerts no control over who has access to the data being encrypted. Bethencourt et al. [18] extended the ABE method to the ciphertext-policy attribute-based encryption (CP-ABE), by associating the ciphertext with an access policy over attributes. A user's secret attribute key is generated from his identity attribute set. e user can decrypt the ciphertext if and only if his/her attribute set satisfies the access policy specified in the ciphertext. e access policy maker is able to decide who should have access to the encrypted data. Currently, many works have been done to devote the ABE method to outsourcing and sharing data securely and flexibly.
Ding et al. [35,36] proposed a privacy-preserving data processing scheme with flexible access control based on the homomorphic encryption of ABE. It realizes various computations over encrypted data in an efficient way and simultaneously flexibly controls the access to data processing results. Belguith et al. [37] introduced a securely outsourcing multi-authority ABE scheme with policy hidden for the cloud-assisted IoT. Our another work [38] proposed an efficient fine-grained access precision control (FAPC) scheme to achieve secure sharing of the same data, under different precisions with different data users. Deng et al. [20] combined the identity-based encryption and identity-based broadcast encryption mechanisms to propose an identity-based encryption transformation scheme. It supports the encrypted data shared with more people beyond those initially designated by the data owner. Xiong et al. [39] constructed a CP-ABE-based storage model for data storing and secure access in a cloud for IoT applications. It introduces an attribute authority management (AAM) module in the cloud storage system functioning as an agent that provides a user-friendly access control and highly reduces the storage overhead of public keys. Multiple ABE approaches have been proposed to implement secure data outsourcing [40][41][42][43], and keyword searching [44][45][46].
Considering the real-time requirement for transaction regulation, we combine the CP-ABE with the key encapsulation mechanism, to design an efficient transaction regulation protocol.

Discussion of Forks
e fork problems are not discussed above. ere are two parallel chains in our ECLB, i.e., the leader chain and the Tx chain. Hence, there are two kinds of forks. Now, we will talk about the corresponding solutions, respectively.
(1) e leader chain fork: it is the first important problem to solve, since it is the leader who guarantees the security of Tx blocks. Here, we will employ the corresponding solution in [13]. For ease of reading, we now recap it. Assume that there are k (2) e Tx chain fork: assume that N i is the previous leader node, Node j the new leader node packed by a new leader block lb t , t the time stamp of this new leader block. After the generation of this new leader block lb t , the previous leader node N i and some other edge nodes might receive lb t with some delay, due to the bad network. us, N i still keeps on packing and broadcasting some Tx blocks. Assume that these Tx blocks are denoted as BS N i � b t1 , b t2 , . . . , b tm , simultaneously, the new leader Node j also is packing and broadcasting some Tx blocks. As a consequence, there will be a time overlap between BS N i and the Tx blocks by the new leader Node j . It will cause chaos of the transaction verification. Our solution to this Tx chain fork is to set only the Tx blocks with time stamps no later than t valid and remained in the Tx chain, namely b x |b x ∈ BS N i , x ≤ t . Otherwise, the Tx blocks packed by the previous leader but with time stamps later than t will be all abandoned.

Conclusions
In this paper, we propose an edge-computing-based lightweight blockchain (ECLB) framework for mobile systems. In the ECLB framework, the edge nodes play a minor role. As a consequence, the storage and computation pressure at end mobile devices are greatly relieved. e fragmented ledger is employed as the storage format at end mobile devices. In this way, the end mobile devices not only can obtain information of interest but also do not need to store an entire copy of the ledger. Moreover, we design a two-chain structure of a leader chain and a transaction chain.
ese two chains grow in parallel. It greatly improves the throughput and confirmation latency. In addition, considering the regulation requirements under the permissioned blockchain setting, we specifically design a pluggable, secure, and efficient transaction regulation protocol. Finally, we give some formal security analysis and performance evaluation. It is demonstrated that our ECLB framework is secure and feasible.

Data Availability
All the experimental data used to support the findings of this study are included within the article.

Conflicts of Interest
e authors declare that there are no conflicts of interest.