Blockchains are popular as a means to enable trustless, decentralized, peer-to-peer value transfer. Among the approaches to achieving distributed consensus in cryptocurrencies, Proof-of-Work (PoW) is the oldest, most established, and arguably most well-understood. However, PoW-based cryptocurrencies are currently limited in terms of transaction throughput in comparison with traditional payment mechanisms, such as credit card transactions. This has resulted in increased transaction costs as cryptocurrencies rise in popularity and a greater shift towards alternate scaling mechanisms. In particular Proof-of-Stake (PoS) and other Proof-of-X consensus protocols and a proliferation of Layer 2 protocols, side-chains, and bridges have been proposed and implemented in order to enable lower transaction fees. All of these approaches have alternate assumptions and trust models in comparison with Proof-of-Work and, as a result, come with their own associated challenges and weaknesses.
The two most notable cryptocurrencies, Bitcoin and Ethereum, are both PoW-based111at the time of writing, Ethereum has not yet attempted the transition to Proof-of-Stake and at the time of this writing are capable of achieving under 20 transactions per second [georgiadis2019many, chauhan2018blockchain], whereas Visa alone can execute more than 2,000 transactions per second on their credit card network [chauhan2018blockchain]. Indeed, it is now presumed (without proof) by a majority of people that Proof-of-Work cryptocurrencies simply cannot meet the throughput requirements of a global currency.
In this paper, we introduce BlockReduce, a PoW cryptocurrency that achieves high transaction throughput (as a Layer 1 protocol). We describe BlockReduce by first identifying the primary factors that cause low transaction throughput (and therefore, large fees) in PoW blockchains and then address and ameliorate each factor, thus resulting in a truly scalable solution.
The primary tools underlying our solution for scalability are as follows:
Latency-dependent Clustering of Network Nodes: As noted across literature [wan2019evaluating]
, network latency is one of the biggest factors in the scalability of blockchain systems. In our work, we translate this understanding of network latency into a suitable hierarchical clustering, where nodes self-partition into a hierarchy of sub-networks with which they share low-latency connections. Each sub-network operates its own blockchain to validate and update a partition of the overall application state.
Transaction-dependent Security: Currently, a vast majority of blockchains (and a vast majority of PoW blockchains) afford the same level of security—where security refers to the amount of work required to succeed in a double-spend attack—for all transactions, regardless of the economic value of the transaction. However, in most human-commerce centric interactions, low-value transactions (and blocks incorporating them) are not secured to the same level as high-value transactions. For example, credit card transactions of low value often do not require signatures, while higher value transactions go through a more stringent signature verification process. Ultimately, even in the blockchain domain, we believe that security should be transaction-value dependent, with high-value blocks (and associated transactions) afforded much higher security guarantees. Thus, the amount of work applied to all transactions need not be the same in the short-term, although we remark that eventually all transactions in BlockReduce are secured by the maximum amount of work available to the system.
Merged Mining: Rather than performing PoW computations on a single block header, miners simultaneously mine multiple blockchains using the same PoW computations, and one PoW solution might correspond to blocks in multiple blockchains. This has two effects in BlockReduce. The first is that all miners are mining the root chain of the hierarchy, meaning the root chain receives the maximum amount of work available in the network. The second is that periodically blocks (which we refer to as coincident blocks) will be found which are shared between blockchains at different levels of the hierarchy, which allows work to be shared across the blockchains and enables cross-blockchain state-transitions.
I-a Proof-of-Work Blockchains
The goal of a PoW blockchain is to achieve consensus on transaction sets to be committed to a public ledger by performing work on blocks containing transaction references. The first published instance of Proof-of-Work being applied to blockchains is Nakamoto’s famous Bitcoin protocol [Nakamoto2008]
, where Nakamoto combined PoW with a block selection rule called the Longest Chain Rule to achieve Nakamoto consensus on transactions. Bitcoin was later proven to satisfy strong forms of consistency and liveness in asynchronous networks with bounded adversarial delays[Pass2016].
BlockReduce uses PoW to reach a similar form of consensus on each blockchain in its hierarchy. In order to accommodate for its hierarchical structure, BlockReduce utilizes a variant of the Longest Chain Rule which we refer to as the Hierarchical Longest Chain Rule. We describe these aspects of the BlockReduce protocol in more detail in Sections III-B and IV-C.
I-B Proof-of-Work Efficiency
A significant limiter of transaction throughput in public blockchains is the amount of time it takes for data to propagate within the peer-to-peer network after blocks are mined. Long block propagation times limit the efficiency of the Proof-of-Work algorithm, as a node which has not yet received a new block must either continue mining on a stale information set or pause mining activities until the new block is received and validated. However, an adversary mining a private chain may not experience this propagation delay, lending the adversary an advantage over honest miners in the case of an attack. In order to minimize the advantage experienced by the adversary, PoW blockchains must have low block generation rates which consequently limit transaction throughput.
In order to provide additional intuition about this phenomenon, we define the PoW efficiency of a blockchain as the fraction of PoW computations which are computed on the canonical chain, i.e., the blocks which are committed to the transaction ledger. In the ideal setting in which all nodes follow the protocol and there are no network delays on block propagation, the PoW efficiency . If is the total rate of block generation by the network, and the network delay is the time between when a block is found and when it is received by all nodes in the network, [Pass2018] computes the effective block generation rate to be , resulting in a PoW efficiency of .
Furthermore, if a fraction of nodes are adversarial and are mining a private branch of the blockchain as part of an attack, then the PoW efficiency of honest nodes, , decreases as increases. On the other hand, assuming the adversary experiences negligible network delay with itself while mining a private chain (i.e., the adversary experiences effective network delay ), the adversary’s PoW efficiency is approximately 1. Herein lies the problem. If is fixed, then an adversary’s relative advantage over honest nodes increases as the block generation rate increases. Systems such as Bitcoin suppress in order to reduce the impact of on the PoW efficiency of honest nodes. This phenomenon is discussed in various works [bagaria2019prism, dembo2020everything], and several solutions have been presented which assume to be fixed. In this work, we partition the network in such a way that the experienced by each sub-network is lower than that of the overall network, thereby allowing each sub-network to operate a blockchain with a higher block generation rate. Moreover, we achieve this while maintaining the same PoW efficiency in all blockchains, which we believe is critical to a truly scalable blockchain. We utilize the Hierarchical Longest Chain Rule described in IV-C to guarantee that each blockchain receives the maximum amount of work available to the network, thereby achieving high transaction throughput without sacrificing security or PoW efficiency.
I-C Our Contributions
We present BlockReduce, a PoW blockchain system which enables high transaction throughput by utilizing a hierarchy of merged mined blockchains operating in parallel on non-overlapping partitions of the application state. To the best of our knowledge, BlockReduce is the first protocol which promises superlinear scaling with the number of parallel blochchains it operates while still securing each blockchain with the maximum amount of work available to the network. We introduce the Hierarchical Longest Chain Rule as a block-selection mechanism which allows each blockchain in the hierarchy to inherit the work of its parent and also enables native cross-blockchain state transitions between any state partitions in the hierarchy. Finally, we analyze the performance of the protocol to demonstrate the superlinear scalability of BlockReduce.
Ii Related Work
There have been many proposals for scaling transaction throughput in blockchains. We provide a brief summary of several types of approaches.
Ii-a Parallel PoW Blockchains
Many protocols aim to achieve high transaction throughput by operating several blockchains in parallel in a manner conceptually similar to BlockReduce. The PoW version of Parallel Chains [Fitzi2018] involves mining a metablock containing candidate blocks for a number of parallel chains which operate non-overlapping state partitions. Notably, Parallel Chains does not support cross-blockchain transactions and is therefore of more limited use than BlockReduce. Chainweb [martino2018chainweb] is another protocol operating many parallel chains, where each block header references the headers of other chains in order to braid the chains together. Chainweb allows cross-blockchain state transitions and also features a mechanism by which chains inherit work from one another, but can achieve only a linear increase in transaction throughput with the number of parallel chains whereas BlockReduce is able to achieve superlinear scaling.
Ii-B Proof-of-Stake Protocols
Many Proof-of-Stake protocols have been proposed and implemented, such as Ouroboros Praos [kiayias2017ouroboros] and Ethereum’s planned move to Proof-of-Stake, as a means to enable high transaction throughput and low settlement times. However, Proof-of-Stake protocols currently do not afford the same security guarantees as PoW and suffer from shortcomings such as the “nothing at stake” problem and predictability on the next miner who is eligible to mine [brown2019formal].
Ii-C Layer 2 Protocols
There are multiple Layer 2 protocols (i.e., protocols which operate independently and only periodically interact with the blockchain) which have been developed in order to facilitate high transaction throughput. These include Starkware, Polygon, and Lightning among many others [sguanci2021layer]. Although some such architectures can achieve high transaction throughput, Layer 2 solutions inevitably require alternate trust models from the core blockchain protocol which may not be suited for all use cases. BlockReduce scales as a Layer 1 protocol and does not require an alternate trust model or any additional assumptions to achieve scalability.
In this section, we describe the network model which we use for analysis of the BlockReduce protocol, the merged mining technique used to mine BlockReduce, and a transaction model in which transactions are initially secured with an amount of work commensurate to their economic value.
Iii-a Network Model
In this paper, we adopt a simple overlay-network model to understand the interactions between nodes: that of a -regular graph on network nodes. This model arises from the standard set forth by Bitcoin, where the protocol executed by each node attempts by default to maintain a set of 8 peers, which approximates a -regular graph.
We assume a synchronous, round-based model for block propagation. According to [Fountoulakis2013]
, with probability, the number of synchronous rounds required for data to broadcast via gossip in a random -regular network of nodes is
We use this result to characterize the overall network propagation delay (i.e., the amount of time it takes for a single block to be propagated across the network) in terms of the single-link propagation delay, , as follows.
Adopting the shortened notation of [Fountoulakis2013], this gives us the following bound.
Defining in this way makes it clear that decreases as or decrease. In Section IV we show that is reduced in higher order blockchains within the BlockReduce protocol, which allows for a higher block generation rate while still maintaining high PoW efficiency of honest nodes within those blockchains.
Iii-B Merged Mining
Mining in BlockReduce is similar to mining in Bitcoin or Ethereum, except that in BlockReduce, multiple blocks are mined simultaneously using a technique called merged mining [xu2017taxonomy] and the Longest Chain Rule (LCR) used by Bitcoin is modified to accommodate the hierarchical structure of BlockReduce.
BlockReduce miners use merged mining to simultaneously mine a blockchain in each level of the hierarchy—where levels are referred to as orders—with the same PoW computations. To accomplish this, miners construct a block for each blockchain they are mining, concatenate the block headers together, and perform PoW computations on the resulting shared block header. Blockchains closer to the root of the hierarchy have higher PoW difficulties, and a block which meets the difficulty requirement of a blockchain of order also meets the difficulty requirement of each blockchain of order greater (i.e., further from the root) than , as it necessarily meets all lower difficulties. These blocks are called coincident blocks because they are valid blocks in multiple blockchains and serve to coincide those blockchains via shared block references. In Section IV, we show that by using the hierarchical longest chain rule, coincident blocks impose a partial ordering on blocks in different blockchains, which enables cross-blockchain state transitions.
Iv A Hierarchy of Blockchains
In this section, we describe the BlockReduce protocol and show that all nodes operating a particular blockchain are able to agree upon its state.
The BlockReduce protocol requires that nodes self-partition into a hierarchy of sub-networks, where the hierarchy is a tree consisting of levels called orders. Each sub-network is denoted , where is the unique path from the root to the specified node in the hierarchy tree. The root of the hierarchy tree is of order and the leaves are of order .
We adopt a functional notation when discussing relationships between sub-networks, blockchains, and state partitions. We denote to be the parent sub-network of in the hierarchy tree and to be the order of . We often overload this functional notation with inputs , , or simply , and each of these usages has precisely the same meaning. An example of a BlockReduce sub-network partitioning and associated hierarchy structure is provided in Figures 1 and 2. In this example, the hierarchy has three orders, and networks of order 1 and 2 each have two child sub-networks.
Each miner must mine a blockchain of each order corresponding to a path from root to leaf in the hierarchy tree. For simplicity, we assume that all sub-networks of the same order contain the same number of nodes and that each mining node mines exactly one sub-network per order, although in practice there may be sub-networks with more miners than others and miners which elect to mine more than one sub-network per order. Each sub-network operates a blockchain to to achieve consensus on a partition of the state, . Blockchains of order have block arrivals at a rate , block propagation delay , and an average single-link propagation delay .
Iv-B Partitioning the Ledger State
We adopt a generic state model in which each transaction constitutes an update to the application state. This could be used in the UTXO (Unspent Transaction Output) model, where the application state is simply the set of all UTXOs, or a more sophisticated smart contract model, where the application state is the smart contract state. State is partitioned between all blockchains to prevent duplication, and each transaction must specify an origin blockchain and a destination blockchain . If the origin and destination of a transaction are the same, the state transition occurs in the same way as a traditional blockchain implementation. If the origin of a transaction is different from its destination, for example if an asset is being moved from the origin blockchain to the destination blockchain, then the state update involves removing the asset from the origin state and adding it to the destination state. This leads to the following protocol rule.
Protocol Rule 1.
In order for a transaction with origin to be valid, the state that it modifies must be valid with respect to .
For example, if a user is attempting to move an asset from to , then the transaction must have origin and the user must demonstrate ownership of the asset in .
Iv-C The Hierarchical Longest Chain Rule
BlockReduce utilizes a novel consensus rule to select the canonical chain—i.e., the chain of blocks referencing state updates to be applied—for each blockchain. In Bitcoin and other more traditional systems, the Longest Chain Rule (LCR) stipulates that the canonical chain is the sequence of valid blocks with the most work (often referred to as the longest chain or, more accurately, the heaviest chain) [Nakamoto2008]. BlockReduce follows a similar rule but must also account for the existence of coincident blocks within the hierarchy.
Before defining the Hierarchical Longest Chain Rule (HLCR), we first define what conditions a block must meet to be considered valid. While specific requirements may vary between implementations, such as varying block size, transaction and/or smart contract structure, or block header composition, in general we can define a valid block as follows.
Protocol Rule 2 (Valid Block).
A block is considered to be valid if it meets all protocol rules and all of its predecessors of any order are also valid.
In other words, a valid block must conform to the rules of the blockchain and must reference no prior blocks of any order which deviate from those rules. Next, we define the HLCR which miners use to determine the canonical chain in BlockReduce.
Protocol Rule 3 (The Hierarchical Longest Chain Rule).
The canonical chain of the root blockchain is the heaviest sequence of valid blocks in . The canonical chain of any blockchain of order greater than 1 is the heaviest sequence of blocks which contains all coincident blocks between and which are present in the canonical chain of , and no coincident blocks between and which are not present in the canonical chain of .
In other words, the canonical chain for the root blockchain is selected via the standard LCR. For each other blockchain of order greater than , the canonical chain must include all coincident blocks that are shared between and that are present in the canonical chain of . However, if there is some coincident block between and that is not in the canonical chain of , then it cannot be in the canonical chain of .
If an incoming block causes the canonical chain to change, then the state updates dictated by blocks which are no longer part of the canonical chain must be reverted and the new state updates applied. This is why the canonical chain must contain all coincident blocks that are shared with the parent blockchain, as otherwise a cross-blockchain state transition which has been applied at both origin and destination could later be reverted at the origin but not the destination, thus causing an inconsistency in the overall network state.
Iv-D Inter-Blockchain Ordering via Coincident Blocks
Within a single blockchain, all blocks in the canonical chain are totally ordered according to their distance from the genesis block. Between blockchains of different orders, blocks are partially ordered due to the coincident blocks which arise from merged mining.
Intuitively, coincident blocks serve as a shared points in “time” between blockchains, and they allow nodes to agree upon which blocks came “before” the coincident block and which blocks came “after.”
This property of coincident blocks allows all nodes in both and to agree on the existence and ordering of all blocks prior to the coincident block in either blockchain. This, in turn, enables cross-blockchain state transitions to occur, as nodes operating the destination blockchain can agree on precisely when the state transition should be applied to the destination state.
Iv-E Inherited Work via Coincident Blocks
Although in the short term, blocks containing transactions of low economic value may be secured with a fraction of the maximum work available to the network, in the longer term this security level is not sufficient. If a block containing a cross-blockchain state transition were to be removed from the canonical chain of , but the state transition for that transaction had already been applied to , then an inconsistency in the overall network state could arise.
Intuitively, the HLCR prevents this type of inconsistency by giving “infinite weight” to coincident blocks in context of the child blockchain—i.e., regardless of the number of blocks in any number of forks in the child blockchain, if one fork contains a coincident block in the canonical chain of the parent blockchain, then that fork will always be selected. Then in order for a coincident block to be removed from the canonical chain of , it must first be removed from . The result is that inherits the work applied to . In other words, a modification to the canonical chain of can only occur if the coincident block is first removed from the canonical chain of .
Iv-F State Updates
In order to maintain a consistent state between nodes, state updates to must be performed by all nodes in in the same order. This is simple for transactions with the same origin and destination, as the state updates can be performed in the order that they are referenced by that blockchain. For transactions with different origin and destination, the state transition must be handled in two steps. First, is updated according to the transaction (e.g., the removal of an asset from the origin state) as soon as it is included in a block in the canonical chain of . , however, cannot be updated immediately, as there is initially no way for nodes operating to agree upon when the state transition should be applied. Protocol Rule 4 describes the criteria which must be met for a state transition to be applied to , and Protocol Rule 5 describes the order in which all state updates are applied when a block is processed.
Protocol Rule 4.
Let be a transaction with origin and destination , and let be the highest order common ancestor between and . The state transition pertaining to is applied as soon as the block containing is a part of the canonical chain of . The state transition pertaining to , however, is only applied after a coincident block is found which is shared by and and, if , a subsequent coincident block is found which is shared by and .
This rule guarantees that a chain of block references is established between and before is updated. Intuitively, we can think of cross-blockchain state transitions as traveling “up” and “down” the hierarchy. Nodes in can verify that the block containing is in the canonical chain of because of the coincident block between and , and they can also agree upon the existence of the coincident block between and and update while processing that coincident block.
Protocol Rule 5.
The state transitions for a given block in are applied to in the following order. First, if is a coincident block, all transactions with destination which are eligible to be applied to according to Protocol Rule 4 are applied in order of highest origin order to lowest origin order. Transactions with the same origin order are applied in order of the blockchain index at that order, and transactions with the same origin index are applied in chronological order according to their inclusion in their origin blockchain. After that, all transactions directly referenced by are applied to in the order in which they are referenced by .
Protocol Rules 3, 4, and 5 guarantee that all nodes in the same sub-network perform state transitions in the same order, meaning any two nodes which agree on the canonical chain will have consistent local state. This is formalized by Theorem IV.1.
For any given blockchain , any two correct nodes in which agree on the canonical chain of will agree on .
We prove Theorem IV.1 inductively, first remarking that any two correct nodes must agree upon the genesis block and the associated state when the blockchain is instantiated. We then show that for each block in the canonical chain of , both nodes must apply the same state updates to and in the same order, as to do otherwise would require at least one of the nodes to break a protocol rule.
We use induction to prove the statement. Let and be two correct nodes in which agree on the canonical chain of . It suffices to show that and agree on at the genesis block, and that thereafter both nodes perform identical updates to .
First, note that in any blockchain system, all nodes agree on the genesis block and the initial state, and thus all nodes in initially agree upon . By Protocol Rule 3, each block in the canonical chain of must be processed in the same order by and . Then it remains to show that for any block in the canonical chain of , and perform the same updates to in the same order when processing .
We prove this by contradiction. Assume that when processing , applies an update defined by some transaction with origin and destination to but does not. This can only occur if believes the state update for should be applied to while does not, as by Protocol Rule 5, given the same set of state updates to apply, and would perform them in the same order. By assumption, is correct and would only apply the state update for if and/or is equal to . Then we can examine the following cases.
. In this case, is directly referenced in . This leads to a contradiction, as and both have the same block and can verify its contents using the block hash.
and is an ancestor of . In this case, is the highest order common ancestor between and , meaning must be a coincident block between and . We know that is in the canonical chain of prior to . Then because is in the canonical chain of , by the HLCR, and must both agree on the canonical chain of prior to , thus leading to a contradiction.
and is an ancestor of . In this case, is the highest order common ancestor between and , meaning the block containing is a coincident block satisfying the first condition in Protocol Rule 4, and is a coincident block between and . By the HLCR, and must agree that is in the canonical chain of , as otherwise it could not be part of the canonical chain of . Then and must also agree on the canonical chain of prior to , thus leading to a contradiction.
and is not an ancestor of nor is an ancestor of . Let be the highest order common ancestor of and . If applies the state update for , then a coincident block between and must be in the canonical chain of prior to , and must be a coincident block between and . By the HLCR, is in the canonical chain of , and and must agree that is in the canonical chain of . Additionally, if is in the canonical chain of , then it must also be in the canonical chain of , and and must agree upon the canonical chain of prior to . Again, this leads to a contradiction.
Therefore if applies the state update for some transaction to , must also do so and in the same order.
The statement follows. ∎
As a corollary of Theorem IV.1, all correct nodes in which agree on the canonical chain of also agree on , i.e., the root blockchain in BlockReduce achieves similar guarantees to that of a single-blockchain system.
In this section we show that BlockReduce achieves transaction throughput that scales superlinearly with the number of blockchains in each order.
V-a Decreased Propagation Delay via Network Partitioning
Sub-networks of order (i.e., all but the root sub-network) have a network delay which is strictly less than , where is analagous to the experienced by a traditional blockchain operated by a full network of nodes. This is due to the decreased size of the sub-networks and the ability for nodes to select the sub-network with which they share low-latency peer connections in order to reduce the overall block propagation time that they experience.
It is clear from Equation 3 that a smaller network naturally has lower propagation delays than a larger network. In order to enhance this intuition, if we assume that there are sub-networks of order , then we can bound as follows:
Then the propagation delay for any order will be strictly increasing with the number of sub-networks in that order.
Additionally, we remark that under the distribution of node-to-node latencies in Bitcoin as measured by [Neudecker2019], latency between nodes can vary significantly from one pair to the next. We assume that in the absence of a protocol mechanism requiring nodes to join a particular sub-network, each node will attempt to operate in the sub-network with they share the lowest latency in order to maximize their rewards. As a result, we argue that in each sub-network of order greater than , the average per-link propagation delay between nodes in order sub-networks will be smaller than that between nodes in —i.e., for all . While we do not need to directly use this result in our proof, it nonetheless further supports the claim in Theorem V.1.
Overall, the network propagation delay within each sub-network will be much smaller than that of the network as a whole (i.e., the network delay of a similar system such as Bitcoin), and as a result the rate of block generation can be much higher within each sub-network.
V-B Aggregate Throughput
In this section, we show that within each order in the hierarchy, the total transaction throughput increases as the number of blockchains in that order increases despite the PoW efficiency remaining fixed between all blockchains. Moreover, the increase is superlinear with the number of blockchains in each order, as each additional blockchain adds an additional network partition and thus reduces the propagation delay experienced by nodes in each sub-network. We state this property of BlockReduce more formally in the following theorem.
The aggregate transaction throughput of each order in the BlockReduce protocol scales superlinearly with the number of blockchains in that order, and all blockchains in the hierarchy have identical PoW efficiency.
We prove this theorem by showing that the effective block generation rate of an order blockchain grows as the number of order blockchains increases.
Recall that is the total block generation rate of a blockchain of order , then the effective block generation rate is , and the PoW efficiency is . It suffices to show that if is the number of blockchains of order , increases as increases.
We hold the PoW efficiency fixed between all blockchains to that of the root blockchain, i.e., Substituting the results from Equation 4, we get
which simplifies to
Then the effective block generation rate—i.e., the rate at which blocks are appended to the canonical chain—for an order blockchain with the same PoW efficiency as that of the root blockchain is
Clearly, the right hand size of this equation increases with , meaning does as well. Then because all blocks are assumed to contain the same number of transactions, the statement follows. ∎
Vi Discussion and Future Work
BlockReduce is a PoW-based blockchain system which achieves high transaction throughput through a hierarchy of merged mined blockchains which each operate a partition of the overall application state in parallel. Critically, the full PoW available to the network is applied to all blockchains in BlockReduce, and cross-blockchain state transitions are enabled seamlessly within the core protocol. In this section, we highlight several discussion points and avenues for future work.
Self-selection of sub-network participation. Mining nodes in BlockReduce are allowed to mine any vertical slice of blockchains within the PoW hierarchy. However, because the vast majority of miners in any PoW blockchain are economically motivated, most miners will elect to mine the blockchains which grant them the highest rewards. In this way, blockchains within each order will be self-balancing as miners naturally drift towards any available blockchains with reduced competition. In the absence of competitive advantage in mining power, miners will elect to mine the blockchains with which they share the lowest latency connections in order to minimize the probability that their blocks are lost to network forks. We believe that this alignment of incentives should result in the formation of low-latency clusters of mining nodes which are able to achieve very high PoW efficiency, although we leave an incentive-based analysis to future work.
Further analysis of the BlockReduce protocol. As mentioned in the introduction, the core contribution of this work is the specification of the BlockReduce protocol. We provide a coarse analysis of the performance of the BlockReduce protocol under a synchronous communication model with fixed network delays and do not fully characterize the impact of protocol properties such as self-optimizing sub-network partitioning. However, we believe that both further performance analysis under a more advanced network model and empirical testing of the BlockReduce protocol will be interesting future work.
Low-value transaction security and settlement time tradeoffs. BlockReduce users have a high degree of flexibility when transacting, as they can control both the short-term security and the settlement time of their transactions by selecting which blockchain to transact in. Higher order blockchains will have low settlement times and low security in the short term, as the sub-networks operating these blockchains will be lightweight and the rates of block generation will be high. This is ideal for transactions of low economic value, as the consequence of a low-value transaction being removed from the canonical chain is minor. Users desiring a higher degree of security might elect to transact in lower order blockchains in order to utilize a larger fraction of the PoW of the network despite the tradeoff of longer settlement times. The precise characterization of this tradeoff will be specific to a particular implementation, and it is likely that any BlockReduce implementation will provide a default wallet which is capable of selecting the appropriate transaction location in an automated fashion.
Expected hierarchy structure and future implementation. Although we have designed BlockReduce to support an arbitrary hierarchy tree, real-world hardware and network infrastructure as well as timing requirements of a functional blockchan network will limit both the number of orders and the number of blockchains per order that are realizable in practice. As the number of blockchains in the BlockReduce hierarchy increases, cross-blockchain state transitions become increasingly delayed due to the decreasing relative frequency of coincident blocks linking each blockchain. For example, if a blockchain has 3 child blockchains, then an average of 1 in every 3 blocks in will be coincident with each child blockchain. If this number increases to 100 child blockchains, the expected time required for a coincident block to be found with one particular child increases dramatically. Implementation and empirical testing will be required to determine the optimal configuration for any given use case and network topology.