In the anonymous and autonomous society like a blockchain system, every record should be re-derivable. This feature forms the essential trust of the blockchain, and secures the blockchain; thus, keeping every history transaction is critical. However, the size of the Nakamoto blockchain (Bitcoin ) has grown from the ground to over in the past ten years from January 2009 to June 2019; the size doubled since the February 2017 (at slightly over ) . If the exponential growth to be continued, we are expecting to in Jan 2021, to in Jan 2022. Parallel to the growth of blockchain size, the storage cost of being a full node (the node which stores all the blocks of the mainchain) in the Bitcoin network is also grown in exponential.
It holds the promise that, through the usage of blockchain, complex and data-demanding jobs can be distributed through predefined protocols (usually through smart contracts [5, 6, 31]) to the anonymous nodes throughout the network, and the majority consensus can secure the job results. Ideally, an alternative-finance system can be built upon—the job publisher pays the system to do tasks, while the anonymous nodes in the system get paid by generating the commonly recognised task results. It is guaranteed by the decentralisation and anonymous nature of blockchain that as long as the security threshold—the Adversary not having more than half of the participated calculation power is sustained, the results recognised by the majority are the correct results
. However, the oversize problem increases the bar of storage requirement for participants, making the system hard to process data-heavy applications like training Artificial Intelligence video recognition models[29, 30] distributedly and decentralisedly if the system remains universally joinable. Ordinary devices simply do not have enough space to store the data, and the system becomes increasingly centralised if the system process those applications. A transaction in Bitcoin and other Distributed Ledgers [5, 20] sized only around several hundreds of bytes. Even with such little usage of data, disadvantaged nodes are gradually leaving the mining game of most Distributed Ledger systems. More and more devices are acting in lightweight mode [9, 14] or join in mining pools [32, 21] for the reason of both lacking calculation advantage and the space for storing the blockchain.
Many flavours of approaches like weighted models [9, 14, 17], off-chain [26, 12], blockchain sharding [41, 18, 39] are proposed in recent researches to improve the performance of the blockchain. Many approaches attempt to ease the burden of individual nodes and solve the dilemma among having the ability to process everything, maintaining the decentralised system and increasing the performance.
For weighted models, the winning chance in the mining game and the duty of a node are different by weights. The lightweight node system [9, 14] is an example of the weighted model. A lightweight node does not store any block but is the client of some full nodes. They require relevant transactions from the full node to verify a new transaction using Simple Payment Verification (SPV) inquires. A lightweight node only takes up to 4.2M Bytes per year, regardless of the total size of blockchain , but it cannot verify the new blocks and can be misled by full nodes. In Delegated Proof of Stake (DPoS) , people elect a fixed number of representatives and contribute their stakes to these representatives; these representatives then compete in the game of PoS . DPoS has excellent performance because the representative nodes usually have a superpower regarding calculation ability, storage, and network bandwidth. These models are now commonly used in many blockchain-powered IoT systems [16, 13], where lightweight nodes are at the edge, or the nodes contribute their stakes to DPoS to function the system. Because the use of authoritarian/superior nodes, the systems are potential-centralised and the system security highly depends on these representatives.
For off-chain approaches, the relevant persons publish a co-signed contract at the beginning and the end of the relationship. Then they do the trading securely through off-chain channels [4, 7] without publishing transactions to the blockchain. They only publish the transactions to the blockchain when one violates the off-chain transactions. They need to monitor the blockchain to detect any violations; thus, it is not desirable for users who may go offline. And, there are few usages of off-chain approaches in non-financial related applications. Instead of broadcasting the task and the task result to the network, the entities who use off-chain methods must communicate in private, and this also compromises the anonymous nature of the blockchain.
For blockchain sharding approaches, they distribute nodes into different shards and divide the storage as well as the jobs to different shards which runs in parallel so that generally the work demand for individual nodes are not increased with the increase of transaction per second globally. Blockchain sharding is designed for applications that require high concurrency and high transaction per second. The design of blockchain sharding approaches mainly focuses on lowering the chance for the Adversary to occupy the majority spots in a shard when the Adversary has taken a relatively large population of nodes but has not taken the majority nodes globally. It is possible for the Adversary not having a security threshold number of nodes globally but controlled a shard, then the security of the system as a whole is compromised. In order to maintain the security of the system, there are very strict requirements over the number of shards and the number of nodes inside a shard .
We see some blockchain-based storage systems proposed in recent years [40, 38, 37, 34, 36, 22, 1, 8, 28], for most cases, the blockchain is only used as the ”contract-signing witness” between the data publisher and the data keeper. Approaches so far are not trying to reduce the size of the blockchain itself and thus cannot avoid the storage pattern of Bitcoin. Not to mention, the nodes not only need to store the transaction (the contract between the data-publisher and the data-keeper), they also need to keep some data published by the data-publishers.
In this paper, we show a new blockchain structure that cut the blockchain into parts. We use blocks as the input to update the states of the ledger. Once a block is accepted, the transactions inside are executed, and then a new state is derived basing on the old one. In Bitcoin case, a state is the balance of every wallet address. A fixed number of blocks are placed into a segment; a segment is stored by different nodes and is retrieved by a user only when the user wants to re-derive a state. The nodes keep the latest state so that they can verify the new transactions. They also need to keep a segment assigned by the system to participate in the mining game. In this model, the Adversary may attempt to cause a permanent loss of a specific blockchain segment by storing all the copies of a blockchain segment and then disappear from the network once succeed. The Adversary may also attempt to deceive the system by claiming it stores a part of the blockchain which it does not store.
Segment blockchain dynamically divides the blockchain into segments following the sequence of blockchain. It requires nodes to show a PoW (Proof of Work) [2, 35] when joining in the system as well as every time the nodes present the evidence of storing to the system. In this way, we avoid the Sybil attack and make sure that the Adversary can only take up to of nodes if it has 50% of the overall calculation power. We use a hypothesis taken from our recent blockchain sharding research  to label different nodes in Segment blockchain. We categories the participated nodes into different classes and ensures every part of the blockchain is stored by one node per class. Nodes gain the reward for keeping the blockchain segments in the edited game of mining.
Instead of using that hypothesis to build a blockchain sharding system that is more focusing on the improvement of transaction per second, Segment blockchain concentrates solely on the reduce of blockchain size. In blockchain sharding systems, the honest nodes must be the majority of every shard to keep the security of the system as a whole. However, considering storage, when an Adversary fails to become the keeper of every copy of a Segment, its attack does not succeed. So that, in segment blockchain, we do not require the honest people to be the majority of the people who store a specific segment, we only need to ensure that every segment gets at least a reliable keeper. With the loose security threshold, we can assign less number of nodes to store a segment in order to keep that segment securely, compared to blockchain sharding systems where they need to secure the majority nodes are honest. That is why the storage can be much shrunken.
Segment blockchain is suitable for most blockchain applications nowadays including notation, identity control , multinational customs record exchange  which applications do not require a large transaction throughput (like ten thousand to 1 million per second), but get benefit from decentralisation. It also helps the implementation of blockchain in IoT environment where the edge devices are lacking storage capacity to keep the full record; meanwhile, the systems are not requiring significant transaction per second . Segment blockchain can even be used to improve the blockchain sharding by separating transaction storage from transaction verification: the nodes in shards only keep the latest state in their shards, and the history transactions are placed into Segments and being handled separately by Segment blockchain.
In the following sections, we will show the Segment blockchain in detail, discuss why our method is secured and can provide a failure probability; also, how the model prevents the spoof of storing. We will also show the data requirement compared to the traditional Nakamoto blockchain (Bitcoin).
Ii The Jury Hypothesis and its usage in Segment blockchain
We proposed the Jury Hypothesis as an analogy of an Byzantine-node tolerate blockchain sharding approach in , which turns the blockchain into multiple committees that run in parallel.
The Jury Hypothesis states that the member of the Jury of a court comes from the diverse background, so that when a verdict is reached, it can be seen as the decision reached from the whole society (every class of people). If it takes different occupations to form a jury, then when there are a number of court hearings run in parallel, there are number of people in each one of the occupation. Table I shows a court schedule; each court represents a shard, is a person controlled by the Adversary while is an honest person.
It is ruled that a verdict is reached when a pre-defined , number of people inside the jury reached a consensus. Assuming there exists a random assignment scheme that assigns people of the same occupation to different courtrooms where different court hearings are taken place in parallel. Then, the chance for the Adversary to gain spots inside the target courtroom is (assuming the Adversary put all its nodes into the front occupations)
where is the number of people inside courtroom who are controlled by the Adversary. To derive the maximised , we want to be maximised because is the same. Let the Adversary has number of people inside the system (Court Jury Schedule), then . To maximise the value of , we consider
This scenario is the maximised because, given any positive integer ,
Ii-a The Jury Hypothesis for Segment blockchain
Let the jury of a court stores part of the blockchain, then for the Adversary to control all the people () inside this jury is
Let the court system has a number of jury members in total (). Then,
If the Adverary has no more than fraction of the people inside the system (Nakamoto blockchain threshold), then
Thus, the maximum chance for a failure to occur is .
The challenge of implementing Jury Hypothesis for the blockchain storage is (1) how to give different nodes different occupations. (2) how to randomly assign storage to a node. (3) how to prove that a node stores a data. (4) how to adjust the membership and reform the jury when nodes go offline.
Iii segment blockchain
Segment blockchain cuts the blockchain into segments. The size and the number of blockchain segments are dynamically adjusted base on the quantity and the occupation of nodes in the system. Every node only stores one blockchain segment and the block header of every block in the mainchain.
Iii-a Block as input
Let the blockchain be a state machine where every block is the input of the current state; the machine reaches the next state after processing the current block. In Segment blockchain, every node keeps the latest state and all the block headers while storing some copies of the previous blocks. The blockchain is secured when a node can download all the blocks, run them as inputs, and derive the same state. Figure 1 shows an example of this design.
In Bitcoin case, the state can be a ledger that records the balance of every account.
Iii-B blockchain segments
Let there be number of blockchain segments; every segment takes number of nodes following the index number of the blocks and a state derived from the latest block of the previous segment. is the current length of the blockchain. Except the last segment, other segments are of equal length. The last segment would additionally contain blocks. Figure 2 shows an example of this design.
|, .||, .|
Iii-C Node Membership
Let every block has a section which records the pending nodes. The pending nodes are nodes which reported to the system but has not yet been assigned with storage. When a node wants to join in the system, it checks the pending nodes information of the latest block and finds an occupation that is less affluence in number. It then claims that occupation. Let there be a threshold PoW difficulty . The node needs to present a PoW of a difficulty to the system before this node’s info (the occupation and a public identity key) is written into the pending node section. Table II shows the structure of this PoW. Until the node has been instructed to store a specific blockchain segment, the node needs to additionally present a difficulty PoW (of the same content) in every iteration of the mining game to the system to keep the spot in the pending node section.
|Hash_Prev_block||32 bytes||The hash of the|
|block in block height|
|Occupation||4 bytes||The occupation claimed|
|Identity Key||32 bytes||Node’s public identity key|
|Nonce||32 bytes||The number tried for this PoW|
|to reach the required difficulty|
Rank the nodes’ info by the time their info is written into the pending section in ascending order into a list . Let refers to the index pending node of the occupation . Every time when , the storage of all nodes is re-assigned while the size of the blockchain segment is readjusted and more blockchain segments are created and are added to the system. Table III and IV shows an example of the nodes in the system and the list; Table V and VI show a possible situation of the nodes in the system and the list when the front elements of every occupation in the list (Table IV) are added to the system. Because there is a queue for the pending nodes in every occupation, it is nature for the nodes to claim an occupation that is less affluence in number to join in the system quicker. In this way, we solve the challenge (1) of segment blockchain.
Iii-D Storage assignment
When new nodes are added to the system right after block height , let refers to the identity key of the node of occupation which stores blockchain segment. Create a
link with and rank by the ascending order, then adjust according to the sequence of the ranked . is the hash of the block , is a hash function that returns an integer. After the procedure above, the assignment is completed. In this way, we solved the challenge (2) of segment blockchain.
Iii-E Proof of Storage
Let every block header records the Merkle root of the transactions embedded in the block. Let be the block header hash of the latest block height (block height ). If the node in occupation stored the blockchain segment , then let
where is the index number of a transaction in blockchain segment , is a function that returns the number of transactions inside the blockchain segment . When the nodes present the evidence of storing the blockchain segment at the block height (referred to as Proof of Storage), it should provide
The transaction which refers to.
A Merkle branch that can derive the Merkle root indicated in the block header of a block in the blockchain segment .
The transaction which refers to is inside block .
Figure 3 shows an example of the Proof of Storage. In this way, we solved the challenge (3) of segment blockchain.
Iii-F Mining and blockchain segment size adjustment
Segment blockchain runs the same mining rule as Nakamoto blockchain for the block creation. Nakamoto blockchain rules that the node which presents a valid block with the most difficult PoW in an iteration wins that iteration of the mining game.
Let there be number of blockchain segments existing in the system, and the current block height is . Then, the nodes who were assigned to store the number blockchain segment should send the Proof of Storage to the network after the block of the block height is created. They need to submit a PoW of difficulty alongside the Proof of Storage. Table VII shows the structure of PoW for these nodes.
|Hash_Prev_block||32 bytes||The hash of the|
|block in block height h-s|
|Identity Key||32 bytes||Node’s public identity key|
|Nonce||32 bytes||The number tried for this PoW|
|to reach the required difficulty|
The information of the nodes which stored blockchain segment and presented Proof of Storage and PoW is embedded in the block of the second next block height. Figure 4 shows an example of this procedure.
When a node which stores the blockchain segment , does not present the Proof of Storage and the fulfilled PoW at the block height , the membership of this node is eliminated after the block height . If this node is of occupation , and there is a pending node in , then replaces the eliminated node. If there is no pending node in , then , the number of blocks in every blockchain segment is adjusted accordingly. After that, all nodes storing the blockchain segment before the adjustment are back to the pending node section. In this way, we solve the challenge (4) of segment blockchain.
Iii-G Storage adjustment delay
When is changed, the components of every segment is changed. Because of that, nodes need to adjust the segments they store by adding or deleting blocks, and sometimes it also needs to derive a new state from the old one. For example, in Figure 2, when changed from 2 to 3, blockchain segment two would contain ”State 1” instead of ”State 2”. The nodes store segment two would need to derive the State 1 by acquiring segment one and execute blocks since ”State 0”. It is required that the nodes need to keep the old version of their segments for one block iteration after is changed to avoid conflicts between different versions of segments. In this way, it is providing time for nodes to change the segments smoothly.
There are two parts of reward in segment blockchain, one for creating a block, one for keeping the blockchain segments. The reward for creating the block is given using the same rule as Nakamoto blockchain (the reward starts from a large amount of currency at first, and cut in half in every fixed time window until reaching zero). The reward for keeping the blockchain segments is given using the following rules:
When a node showed the Proof of Storage and the fulfilled PoW in the block height , the reward is given to this node at the block of the block height (using the node’s public identity key as the wallet address).
The reward is equally divided to every node.
The amount of the reward for every iteration comes from the system (as like the Nakamoto blockchain). After the reward from the system goes to zero, the reward then comes from the transaction fees.
Iii-I Power constrain
As every node which stores the data are required to present amount of difficulty per block height, the node should at least be able to generate a difficulty PoW per iteration. We say the node which can generate difficulty PoW in one iteration has power. Let , and there is amount of power globally. The Adversary who has amount of power can only keep of nodes in a system of nodes because it needs to place amount of power for every Adversary node. If , every node still needs place amount of power to maintain the spot in the system in every iteration. Otherwise, the Adversary node will be expelled at the next time window (the time window is sized ) for not being able to provide a difficulty PoW. If an Adversary who has amount of power stop placing power for its node and tries to gain a new node , and cannot remain in the system at the same time. This is because also needs of power in order to become a pending node. Thus, regardless of the number of , for an Adversary who has amount of power, it can only keep of the nodes.
Iv Combining blockchain sharding with Segment blockchain
For blockchain sharding approaches, nodes only store transactions in their shards, so that the storage globally is also divided. However, since blockchain sharding approaches aim to process the transactions in different shards in parallel to improve the transaction per second globally, the system is requiring the honest nodes to be the majority of every shard. As a result, the number of shards that the transactions as a whole can be divided into, in blockchain sharding approaches, is much smaller than the number of Segments that the transactions can be divided into in Segment blockchain.
For an blockchain sharding system which uses Segment blockchain, the nodes keep the latest state in their shards and store different segment of the blockchain (the segments may or may not be one that contains blocks within the nodes’ shards). We need to consider two failure probabilities in this system: the chance for the Adversary to control a shard and the chance for the Adversary to take all the copies of a segment. Since the two attacks are unrelated, the maximum failure probability for a blockchain sharding system in overall is
We know that
where , T is a pre-defined setting 111The smaller the T is, the less secure a shard is, the larger the T is, the easier a shard can be halted by the Adversary .
We can use equation 14 to calculate the maximum number of shards required for the n/2 blockchain sharding approach to function securely and the maximum number of segments the Segment blockchain embedded to the system can have in order to maintain the same security threshold .
Let (this is the maximum , because if exceed this number the Adversary would be the majority). Then, we can derive:
Assumed we set the maximum failure probability to be (this bounds the number of ), then we derive which is shown in Figure 5.
As the data in Figure 5 suggested, the blockchain can be divided into more times of segments than shards, so that the nodes can store a much smaller number of blocks than store all the blocks of a shard. Thus, if a blockchain sharding system separates the transaction storage from transaction verification by embedding a segment blockchain, the storage requirement for an individual node can be reduced significantly.
V Data requirement
Let a record in State sized (a wallet address sized , the balance of a wallet address sized ). Let a block of the Nakamoto blockchain sized , a block of segment blockchain sized . A record in sized ( for the occupation of this node, for the public identity key and for the PoW it demonstrated). In reality, we can use persistent data structure  to store States. In this way, the size of storage can be further reduced.
Figure 6 shows the data requirement for the segment blockchain with different number of records in the State (let , ), and with the changes of the block height h. Let there be nodes (the number of the Bitcoin nodes currently), pending nodes are in the pending node section in every block. Figure 7 shows the differences in the amount of data stored in a node in the Nakamoto blockchain and the amount of data stored by a node in segment blockchain with the different number of accounts in the state. Segment blockchain largely shrank the data required while maintaining the full functions of Nakamoto blockchain.
As the analysis in Section 2 showed, the chance for the Adversary who has of the overall calculation power to store all the copies of a block is . When , the security of segment blockchain reached the security level of the standard public-private encryption systems. It is very safe to use an segment blockchain to power financial systems because the encryption systems of the same security threshold are already widely tested by the public and used in many online banking systems.
In this paper, we showed an approach to reduce the storage requirement of the blockchain system while keeping the decentralisation without compromising the security of the blockchain. The data analyses proved that segment blockchain largely reduced the data requirement compared to Nakamoto blockchain. Thus, it is of more advantage to using segment blockchain to power data-heavy blockchains.
-  (2016) Blockstack: a global naming and storage system secured by blockchains. In 2016 USENIX Annual Technical Conference (USENIXATC 16), pp. 181–194. Cited by: §I.
-  (2015) Preventing the 51%-attack: a stochastic analysis of two phase proof of work in bitcoin. In Availab le at http://referaat. cs. utwente. nl/conference/22/paper/7473/preventingthe-51-attack-a-stochasticanalysis-oftwo-phase-proof-of-work-in-bitcoin. pdf, Cited by: §I.
-  Bitcoin.com. Bitcoin.com Charts. External Links: Cited by: §I.
-  (2018) Scalable funding of bitcoin micropayment channel networks. Royal Society open science 5 (8), pp. 180089. Cited by: §I.
-  (2014) A next-generation smart contract and decentralized application platform. white paper 3, pp. 37. Cited by: §I.
-  (2016) Smart contract templates: foundations, design landscape and research directions. arXiv preprint arXiv:1608.00771. Cited by: §I.
-  (2015) A fast and scalable payment network with bitcoin duplex micropayment channels. In Symposium on Self-Stabilizing Systems, pp. 3–18. Cited by: §I.
-  (2016) A temporal blockchain: a formal analysis. In 2016 International Conference on Collaboration Technologies and Systems (CTS), pp. 430–437. Cited by: §I.
-  (2017) Lsb: a lightweight scalable blockchain for iot security and privacy. arXiv preprint arXiv:1712.02969. Cited by: §I, §I, §I.
-  (2002) The sybil attack. In International workshop on peer-to-peer systems, pp. 251–260. Cited by: §I.
-  (2017) Blockchain identities: notational technologies for control and management of abstracted entities. Metaphilosophy 48 (5), pp. 634–653. Cited by: §I.
-  (2017) On or off the blockchain? insights on off-chaining computation and data. In European Conference on Service-Oriented and Cloud Computing, pp. 3–15. Cited by: §I.
-  (2018) Roll-dpos: a randomized delegated proof of stake scheme for scalable blockchain-based internet of things systems. In Proceedings of the 15th EAI International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services, pp. 482–484. Cited by: §I.
-  (2018) Unifying lightweight blockchain client implementations. In Proc. NDSS Workshop Decentralized IoT Security Stand., pp. 1–7. Cited by: §I, §I, §I.
-  Simplified payment verification (spv). Cited by: §I.
-  (2017) Managing iot devices using blockchain platform. In 2017 19th international conference on advanced communication technology (ICACT), pp. 464–467. Cited by: §I.
-  Blockchain based decentralized scalable identity and access management system for internet of things. Cited by: §I.
-  (2018) Omniledger: a secure, scale-out, decentralized ledger via sharding. In 2018 IEEE Symposium on Security and Privacy (SP), pp. 583–598. Cited by: §I.
-  (1996-April 2) Method of managing data structure containing both persistent data and transient data. Google Patents. Note: US Patent 5,504,895 Cited by: §V.
-  (2014) Delegated proof-of-stake (dpos). Bitshare whitepaper. Cited by: §I, §I.
-  (2015) Bitcoin mining pools: a cooperative game theoretic analysis. In Proceedings of the 2015 International Conference on Autonomous Agents and Multiagent Systems, pp. 919–927. Cited by: §I.
-  (2018) Block-secure: blockchain based scheme for secure p2p cloud storage. Information Sciences 465, pp. 219–231. Cited by: §I.
-  (2017) Caterpillar: a blockchain-based business process management system.. In BPM (Demos), Cited by: §I.
-  (2008) Bitcoin: a peer-to-peer electronic cash system. Working Paper. Cited by: §I, §I.
-  (2018) Unveiling the potential of blockchain for customs. WCO Research Paper 45. Cited by: §I.
-  (2016) The bitcoin lightning network: scalable off-chain instant payments. Working paper. Cited by: §I.
-  (2019) Secure data storage based on blockchain and coding in edge computing. Math. Biosci. Eng 16, pp. 1874–1892. Cited by: §I.
-  (2018) Incentive mechanism of data storage based on blockchain for wireless sensor networks. Mobile Information Systems 2018. Cited by: §I.
-  (2000) Activity recognition from video sequences using declarative models. In ECAI, pp. 673–680. Cited by: §I.
Explainable artificial intelligence: understanding, visualizing and interpreting deep learning models. arXiv preprint arXiv:1708.08296. Cited by: §I.
-  (2017) Contract law 2.0:‘smart’contracts as the beginning of the end of classic contract law. Information & Communications Technology Law 26 (2), pp. 116–134. Cited by: §I.
-  (2016) Incentive compatibility of bitcoin mining pool reward functions. In International Conference on Financial Cryptography and Data Security, pp. 477–498. Cited by: §I.
-  (2014) Blackcoin’s proof-of-stake protocol v2. URL: https://blackcoin. co/blackcoin-pos-protocol-v2-whitepaper. pdf 71. Cited by: §I.
-  (2014) Sia: simple decentralized storage. Nebulous Inc. Cited by: §I.
-  (2015) The quest for scalable blockchain fabric: proof-of-work vs. bft replication. In International workshop on open problems in network security, pp. 112–125. Cited by: §I.
-  (2018) Forkbase: an efficient storage engine for blockchain and forkable applications. Proceedings of the VLDB Endowment 11 (10), pp. 1137–1150. Cited by: §I.
-  (2014) Metadisk a blockchain-based decentralized file storage application. Tech. Rep.. Cited by: §I.
-  (2018) A blockchain-based storage system for data analytics in the internet of things. In New Advances in the Internet of Things, pp. 119–138. Cited by: §I.
-  (2020) An n/2 byzantine node tolerated blockchain sharding approach. In The 35th ACM/SIGAPP Symposium On Applied Computing, http://gofun.online/document/blockchain_sharding.pdf, Cited by: §I, §I, §I, §II, footnote 1.
-  (2018) Section-blockchain: a storage reduced blockchain protocol, the foundation of an autotrophic decentralized storage architecture. In 2018 23rd International Conference on Engineering of Complex Computer Systems (ICECCS), pp. 115–125. Cited by: §I.
-  (2018) Rapidchain: scaling blockchain via full sharding. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pp. 931–948. Cited by: §I.