How the Blockchain Handles More Transactions as It Grows

Table of Links

Abstract and I. Introduction

II. Background

III. Related Works

IV. Comparative Analysis

V. Findings and Evaluation

VI. Conclusion and References

This section examines the various approaches to blockchain scaling, at each level of the blockchain stack. Layer-one consists of on-chain solutions, which is where the transactional model, consensus mechanism and blockchain architecture sits. Layer-two consists of any off-chain solution used to support the operation of an underlying layer-one solution, this includes sidechains and off-chain processing.

A. Layer 1 – On-chain

Transaction throughput doesn’t scale alongside network growth due to processing occurring sequentially. To solve this, the layer 1 network can be divided into shards acting as singular entities processing transaction validation in parallel. This allows throughput to scale out as the network grows (see Fig. 4). The following explores how select challenges are approached in different projects and literature.

1) Network Sharding: The first challenge in sharding is securely segmenting the network into smaller groups. Each shard must maintain Byzantine fault tolerance, which is difficult as shards are exponentially smaller than an entire network. To ensure probabilistic Byzantine fault-tolerance, shard assignment must be unbiased and randomised. Elastico tackles this in their identity establishment and shard formation phase, at the start of each epoch [18]. This is where nodes each generate an identity based on a correct proof-of-work (PoW) solution. The PoW solution is a publicly verifiable hash and has the following values inserted into it: “epoch randomness”, “IP address”, “public key” and “nonce”. Nodes are assigned uniformly at random to shards based on specific bits in the output hash of the PoW function. For example, all nodes with hashes ending in “0010” are assigned to “shard 1” and all hashes ending in “0111” to “shard 2”. Elastico assures epoch randomness is generated by a designated “final shard” at the end of each epoch, for use in the identity establishment of the next. Final consensus is achieved by the “final shard”, which computes the merkelized value of blocks from all other shards. The result of this is broadcast across the entire network at the end of each epoch [18]. Instead of Elastico’s PoW based identity establishment, OmniLedger uses a verifiable random function (VRF) to generate a ticket used in the unbiased and unpredictable election of a temporary shard coordinator. The VRF is a keyed cryptographic hash generated using a node’s private key, that can be verified and accessed using their public key [19]. In the event the elected coordinator is deemed to be malicious, OmniLedger uses the RandHound protocol to generate an unbiasable random string (URS) calculated from the previously created VRF of each node. The URS is computed by the temporary leader, but the output is completely dependent on the VRFs produced by each individual node [20].

2) Transaction Sharding: After shard assignment, the next challenge is determining how transactions will be allocated to individual shards to ensure that double-spending isn’t possible by transacting the same funds in multiple shards [21]. Transactions can instead be handled based on certain attributes such as their sending address [22]. An address’s subsequent transactions are therefore handled by the shard which stores the transaction originators current UTXO state. Zilliqa’s sharding protocol uses a single directory service shard (DSS), to assign transactions to processing shards based on attributes, which operates similar to Elastico’s “final shard”. The DSS is also used in block synchronisation at the end of each epoch and can be conceptualised as a coordinator similar to beacon/parent chains used in layer 2 approaches [22].

3) Cross-shard Transactions: Finally, cross-shard transactions are critical to ensure the validity of transactions complying with different changing UTXO states across different shards [21]. OmniLedger proposes an atomic commit protocol to manage the finalisation, or roll back transactions based on the consensus of multiple shards [20]. Atomic commit transactions occur in three phases: (i) initialization, (ii) lock and (iii) unlock [21]. In this protocol, the client (transaction originator) is leveraged as an atomic coordinator. In initialization, the transaction is sent to multiple shards where the UTXO state is locked. Shards individually achieve consensus, responding with a cryptographic proof-of-acceptance (PoA) or proof-ofrejection (PoR) hash to the client. To commit the transaction, the client sends all PoAs to a predefined shard, where the transaction is unlocked and committed. Similarly, if any PoR is received, the client sends this to shards maintaining the locked UTXO, where it’s unlocked and rolled back [20]. This process ensures the transaction is either committed to a block on one shard or unlocked and rolled back on all shards. If the client doesn’t respond the state will be unlocked and rolled back allowing the UTXO to be spent in another transaction [21].

B. Layer 2 – Off-chain

Off-chain solutions are used to simulate horizontal scaling found with layer 1 sharding techniques. Alternative to small network shards, sidechains are used to handle transactions, achieving similar parallelization to individual UTXO shards. Sidechains rely on different validators and mechanisms to process transactions easing on-chain congestion. Such chains use two-way pegs to provide interoperability between the mainchain being scaled and itself, allowing a multidirectional asset transferral The mainchain adopts a parent role, dictating underlying security, approving off-chain processing, and arbitrating off-chain disputes. This is comparable to designated coordinators in some layer-one sharding protocols [23]. Generally, the UTXO model is used to easily represent whether a state has been spent or not, ensuring accurate state transitions of the main-chain while minimising mass-exit costs. In Fig. 5, the two-way peg is seen sitting between the parent and childchain. Tokens from the parent are locked, with the equivalent value being created/unlocked on the child for the transaction to be processed [24].

Sidechain networks can be created, with a tree-like recursive parent/child relationship, filtering transaction processing away from bottlenecks. This approach to parallelization is known as a nested-chain. Transactions are delegated to children, which in turn may have generations of chains under them. This circumstance requires a chain to act in both a child and parent role. This architecture is implemented in the Plasma network, to increase Ethereum’s scalability and is demonstrated in Fig. 6 [25]

Upon the processing of transactions, child-chains transform all transactions in the block into a single cryptographic value and then periodically record the results back to the parent. Such processing can be specialised to the sidechain, for example, Bitcoin Lightning Network handles microtransactions for Bitcoin, saving bandwidth for large security-critical transactions on the main chain [26]. Plasma network scales the execution of smart contracts, made possible by Ethereum’s account-based transaction model. Smart contracts automate the offload of transactions, to specific Plasma chains based on predefined transaction attributes. Plasma processes these and submits the merkleized fraud-proof back to Ethereum [25]. This enables users to report any dishonest nodes to their parent-chain, roll back the block to protect digital assets and penalise the malicious actor, which helps protect against the risk of Sybil attacks and other forms of corruption that may occur [27].

C. Layer 2 – Hybrid Scaling

Rollups are a recent development in scaling blockchain technologies which are considered to be a hybridization of both layer 1 and layer 2 solutions [27]. Rollups work in a similar manner to nested-chains but are trusted to scale more by solving specific data availability issues that are seen with complete layer 2 solutions, rather than just moving all data, storage state and computation onto a side-chain. Transactions that are about to be processed are “rolled up” into a single batched transaction, and then compressed to decrease the size and cost of each batch, enabling more efficient transactions to occur. Rollups only migrate the transaction execution and state storage off-chain into specialised “rollup” contracts while retaining just enough data about each transaction on the mainchain [26].

Once the execution is complete, the results of the change in state will be relayed back to layer 1. Storing transaction data on-chain is essential to maintain transactional security as it enables the integration of a byzantine-fault tolerant consensus mechanism to manage the trustless state of consensus on the layer 1 chain [26]. By securing rollups with blockchain security mechanisms and storing transaction data on-chain, the hybrid system allows anyone user to process transactions locally to detect fraud, initiate withdrawals from the rollup and also start producing batches of transactions.

Each rollup stored on-chain maintains a Merkle root hash of the batched transactions for the current state of the contract, known as the state-root, which includes account balances and rollup code logic. This is vital when verifying the state of a batch to see if the previous state-root hash of the batch matches with the current root-state. If they do match, the proposed state-root will transition into a new rollup state-root [27].

Although the transaction data stored on-chain is secured through consensus mechanisms, the transactions being executed and the change of state within the rollup contract will not be validated by the main-chains consensus. Rollups require alternative mechanisms to prove that the state-root of the contract following batch transaction confirmation is accurate. This is needed as without batch verification, a malicious actor can submit a batch with a fraudulent Merkle-root and incur no consequences, then being capable of transferring all digital assets within the rollups to their own account. There are two completely different approaches to solve the issue of fraudulent states, which are optimistic rollups and zeroknowledge rollups [28].

1) Optimistic Rollups: Optimistic rollups follow an interactive approach to verify whether a submitted batch has a fraudulent post-state root. Each rollup contract tracks the historical state-roots and the hash of each transaction batch. Transaction batches are confirmed optimistically, but if users discover that one of the batches produces an incorrect poststate root, they can generate and publish a fraud-proof containing the transaction and part of the Merkle tree to the chain proving that the batch was processed incorrectly [29]. Rollup contracts verify whether the fraud-proof is legitimate, and if it is deemed to be, that batch and all consequent batches are rolled-back. Rollups benefit from the main-chain security but do offer a lower throughput than Plasma and ZK Rollups. The trade-off for the lower throughput is the ability to scale smart contracts with an optimistic model [26]. Optimistic rollup projects include Optimism and Arbitrum [30] [31].

2) Zero-Knowledge Proofs: ZK-rollups solutions are based on the concept of zero-knowledge proofs and validity proofs, which are both cryptographic proofs that get included with every batch. The ZK rollup framework makes use of zeroknowledge proofs, which lets observers immediately prove the validity of an assertion by ensuring that the post-state recorded to the main chain is the accurate result hash from executing the batch. This can be verified very quickly onchain, regardless of how big the computation is, however, the computation required to create a ZK proof is expensive and only suitable for transaction management and not complex smart contract execution [26]. There are projects which are attempting to explore ZK-Rollups, including ZKSync which uses the SNARK implementation and StarkEX implementing STARK proofs [32] [33].

Once a user wishes to withdraw their funds from the childchain back to the main-chain, the user balance is calculated using spent and unspent transaction outputs that occurred on the side-chain associated with the user’s private key. This value of the native tokens on the side-chain is then put into a lockbox and unlocked on the parent-chain. There is typically a validation period for confirmation of the spent and unspent transactions to ensure accuracy [34].