Layer-1 vs. Layer-2: Scaling Solutions and Their Effects on Blockchain Security and Decentralization

Table of Links

Abstract and I. Introduction

II. Background

III. Related Works

IV. Comparative Analysis

V. Findings and Evaluation

VI. Conclusion and References

IV. COMPARATIVE ANALYSIS

This section examines the impact on each property of the blockchain trilemma when implementing layer-one and layer-two scaling solutions across UTXO and account-based transaction models. Comparable metrics are up-scale factors, transaction throughput and dispute resolution. Qualitative comparison will be used to express the strengths and limitations of decentralisation and security.

A. Layer-One Sharding

The works of Luu et al. in Elastico presented a decentralised scalable solution to sharding and parallelisation, proposing feasible approaches to shard assignment without central coordination [18]. Although scaling increases with network growth linearly, individual shard security is sacrificed. This culminates in an 8% average shard failure probability, having negative security implications and undermining scaling through failure bottlenecks [21]. Resilience to byzantine threats decreases consistently, as shards are added, meaning infinite scaling eventually completely sacrifices system integrity. This can be partly attributed to small shard sizes [20]. Kokris-Kogias et al address bottleneck and security issues native to Elastico scaling through their work on OmniLedger. By increasing shard size byzantine fault tolerance is more effectively managed in a decentralised setting. The implementation of an atomic commit protocol directly combats double spending, an issue imperfectly solved in industry approaches previous to OmniLedger. Cross-shard atomicity ensures UTXO funds aren’t indefinitely locked as pending in-cases of malicious coordination. This was achieved through rejection and acceptance proof, with resilient commit and rollback parameters [20]. Probabilistically, OmniLedger could survive for 230 years before complete shard failure undermines the blockchain. In contract Elastico can survive 1 hour, under the same parameters [35].

Zilliqa utilises directory service shards to increase security and transaction efficiency through transaction coordination This mitigates double-spending and is a scalable solution to transaction sharding. Transaction speeds don’t scale as highly compared to RapidChain or OmniLedger, however transaction assignment is more secure[36].

B. Layer-Two Scalability

Plasma follows a nested, parent/child chain architecture built on Ethereum [9]. Although Ethereum supports a high level of decentralisation, Plasma can centralise aspects of processing activities due to centric coordination on some sidechains [25]. Security challenges are found in consensus, weakening the overall byzantine fault tolerance of the network. For these reasons Plasma severely sacrifices security and decentralisation in the pursuit of scalability.

Compared to Plasma ZKsync achieves far greater decentralisation and security at scale. Despite significantly lower transaction speeds and latency, ZKsync manages all three attributes of the blockchain trilemma while achieving impactful scalability. The zero-knowledge nature of this solution is privacy preserving by default, increasing overall system security. ZKsync is fully dependent on smart contract implementation to aggregate transaction processing, making it infeasible for UTXO based projects [32]. Nested-chains like Plasma can be deployed over a wider array of layer-one implementations, making them more feasible for less specialised use-cases.

Contrasting ZKsync and zero-knowledge rollups in general, optimistic roll ups like Arbitrum focus on hyper-scalability, with disregard for other decentralisation. Supporting the highest scaling of any solution at both layer-one and two, Arbitrum is a prime example of the trilemma. The use of trusted centralised sequencers, undermines the decentralised aims of all permissionless blockchain projects. Security is increased through fraud proofs, although slow generation increases transaction latency. Although transactions are processed quickly, latency causes large time windows until a transaction is immutably confirmed.

C. State Transaction Models

The core UTXO account model used by Bitcoin was designed to handle transactions from one user to anothers private key address. The way the unspent transactions are generated and spent means that these transactions have a greater chance of being scaled by processing them in parallel. Although the UTXO model has minimal expressiveness in terms of on-chain logic, the UTXO model enables scalability and confidentiality, with much simpler transaction verification [11].

Vitalik introduced the Account-model into the Etheruem blockchain, which runs on a global virtual machine which maintains a record of all transactions, users and even smart contracts. Accounts are ran by private keys or smart contracts and store user assets as account balance. Although storing account state within the global state makes things easier, it also limits scalability options at layer one and requires the introduction of layer 2 solutions such as Plasma [9].

More recently, Cardano’s IOHK developed the eUTXO model, which maintains the core aspect of the UTXO model with regards to how each transaction consumes unspent outputs in order to produce new unspent transactions that can be further spent. As Cardano intended to implement smart contract functionality, using the basic UTXO model that was designed to do little more than handle payments would be unsuitable. This is highlighted through the lack of expressive coded logic available on-chain to UTXO systems. The use of an Account model addresses the issue of limited expressiveness by developing specialised smart contract accounts, becoming far to complex [37].

To create an eUTXO, two core additional pieces of functionality are needed to build upon the base UTXO model. The model needed to ensure that smart contract state was maintained and also enforce that the same smart contract logic is used throughout the whole sequence of transactions. This eUTXO model enables native-assets and smart contracts to be used on the UTXO model for the first time [6].