Kasplex L2: A lightweight Rollup solution based on Kaspa

Introduction

With the development of blockchain technology, scalability and programmability remain key challenges, especially for blockchains that adopt the UTXO model. Kaspa, as a Layer 1 public blockchain utilizing a BlockDAG structure, achieves high throughput but lacks native smart contract functionality, a limitation also faced by other UTXO systems like Bitcoin. To address this issue, the Kaspa ecosystem has developed Kasplex L2, a Layer 2 solution that implements Ethereum Virtual Machine (EVM) compatible smart contracts through a Rollup-based architecture.

In this article, we will conduct a technical analysis of Kasplex L2 from the perspective of security and research institutions. Our goal is to objectively assess its design, technical implementation, and its impact on the UTXO blockchain. We will explore how Kasplex L2 works, compare it with Bitcoin's Inscriptions (such as BRC-20), and discuss its advantages and limitations. This analysis aims to provide a broader discussion reference for scalability solutions in UTXO model blockchains.

Understanding Kaspa Layer 1: A High Throughput UTXO Blockchain

Kaspa is a layer one blockchain that uses a BlockDAG structure, allowing multiple blocks to be produced in parallel. This design is driven by the GHOSTDAG protocol, enabling Kaspa to achieve a high throughput of 10 BPS. Unlike account-based blockchains (such as Ethereum), Kaspa uses a UTXO model, where transactions are validated by consuming unspent outputs and creating new outputs, ensuring an efficient validation process.

While this architecture performs excellently in payment scenarios, it faces challenges in programmability. The UTXO model is inherently stateless, lacking the ability to maintain persistent state or execute complex computations—key functionalities required for smart contracts. Therefore, Kaspa's capabilities are limited to simple transfers, which has also driven the development of layer two solutions to extend its capabilities.

Kasplex L2: A Rollup-based solution for smart contract execution

The Kaspa ecosystem explores three Layer 2 (L2) solutions: Sparkle, Igra L2, and Kasplex L2. Sparkle is still in the theoretical stage, and Igra L2 is still in the development stage. Our analysis focuses on Kasplex L2, as it is the most mature implementation to date.

Kasplex L2 is a layer 2 scaling solution based on Rollup, which relies on the layer 1 chain for transaction ordering and data availability while shifting the computational load to layer 2. In this design, the Kaspa layer 1 chain is responsible for determining the standard order of transactions and ensuring that their data is publicly accessible, while Kasplex L2 executes EVM bytecode to enable smart contract functionality.

Technical Design and Workflow

The core mechanism of Kasplex L2 is to embed EVM bytecode in the load of Kaspa layer one chain transactions. The process can be divided into the following steps:

Transaction Submission: The user submits a transaction to the Kaspa Layer 1 chain, where the payload includes EVM bytecode. For example, the payload may encode a call to the HelloWorld() smart contract function.

Level 1 chain sorting: Kaspa's BlockDAG sorts transactions within its DAG structure, providing a deterministic transaction sequence.

Layer 2 Execution: Kasplex L2 operates as an indexer, scanning load-bearing transactions on the primary chain, extracting EVM bytecode, executing it in a specified order, and updating its state. Invalid or conflicting transactions (e.g., transactions attempting double spending) will be discarded.

Transaction Submission Mechanism

Kasplex L2 supports two transaction submission methods, each with different impacts:

Canonical Submission: Transactions are submitted directly to L1 through Kaspa-compatible wallets, eliminating the need for relay nodes and adhering to the decentralized principles of blockchain systems.

Proxied Submission: Transactions are submitted through a Relayer to be compatible with EVM tools like MetaMask. The Relayer forwards the transaction to Kaspa L1, ensuring it is recorded before being processed by L2. This method prioritizes user convenience but introduces a dependency on the Relayer.

The delegation submission mechanism ensures atomicity by requiring that all Layer 2 transactions must be anchored on the L1 chain. If a transaction occurs on L2 but has not yet been recorded on the Layer 1 chain, a relayer will submit it to the L1 chain for confirmation. This design prevents "native" L2 transactions from bypassing the L1 chain consensus, thereby avoiding potential security risks. The diagram below illustrates the two submission paths:

Standard Path: Wallet → Kaspa L1 → Kasplex L2

Agent Path: MetaMask → Relay → Kaspa L1 → Kasplex L2

You may notice that the transaction is actually completed on L1 first, and then interpreted by the L2 indexer. This is exactly how Kasplex L2 works: L1 finalizes the data first, and then L2 reads the transaction and updates the state.

Comparison with Bitcoin Inscriptions

To better understand Kasplex L2, it is very helpful to compare it with Bitcoin Inscriptions (especially BRC-20). Both aim to extend the functionality of UTXO model blockchains by utilizing L1 for data storage and ordering, but there are differences in their implementation and objectives.

similarity

Data embedded in L1: Kasplex L2 and BRC-20 will embed data in layer one chain transactions. BRC-20 uses Bitcoin's Tapscript (enabled by the SegWit upgrade) to store token metadata, typically achieved through a three-step process of "commit (data hash) → reveal (the data itself) → spend (token transfer)." Kasplex L2 embeds EVM bytecode into the payload of Kaspa L1 transactions, achieving similar L2 operation anchoring.

L1 as a trusted data source: In two scenarios, L1 provides the ordering of operations. BRC-20 relies on the Bitcoin blockchain for token transfer ordering, while Kasplex L2 uses Kaspa's BlockDAG for smart contract execution ordering.

Dependence on indexers: Both rely on off-chain indexers for processing. The BRC-20 indexer parses Bitcoin transactions to track token balances, while the Kasplex L2 indexer executes EVM bytecode to maintain smart contract states.

Difference

Efficiency achieved: The three-step process of BRC-20 is a workaround of the rigid Bitcoin protocol, while Kasplex L2 benefits from Kaspa's more cooperative L1, allowing data to be embedded in a single transaction payload, thereby reducing complexity and system overhead.

Performance considerations: Bitcoin's throughput is about 7 transactions per second, with a block generated approximately every 10 minutes, making the Inscriptions process both slow and expensive. The 10 BPS upgrade of Kaspa provides significant performance advantages, allowing Kasplex L2 to process larger-scale transactions more efficiently.

Scope and Functionality: BRC-20 primarily focuses on token issuance and transfer, while Kasplex L2 supports full EVM compatibility, allowing for the execution of complex smart contracts such as DeFi protocols or NFT marketplaces.

Agreement Flexibility: The design of Bitcoin emphasizes immutability, forcing L2 solutions to work around its limitations. Although Kaspa also adopts the UTXO model, its L1 design is more flexible, allowing for tighter integration with L2 solutions such as Kasplex.

This comparison highlights a key insight: although both are similar in the concept of using L1 for data storage and sorting, Kasplex L2 leverages the architectural advantages of Kaspa to achieve higher efficiency and broader functionality than inscriptions.

Evaluating Kasplex L2: Advantages and Limitations

From a technical research perspective, Kasplex L2 demonstrates the following significant advantages and limitations.

Advantages

Function expansion: Kasplex L2 successfully expands Kaspa's capabilities by supporting EVM-compatible smart contracts, enabling it to accommodate use cases such as decentralized applications and tokenization that cannot be realized on the primary chain.

Efficient use of L1: Kasplex L2 utilizes Kaspa's BlockDAG for transaction ordering and data availability, minimizing the computational burden on the second layer and focusing solely on execution. This design aligns perfectly with Kaspa's high throughput architecture.

Public Verifiability: As all transactions are recorded on L1, the execution of smart contracts on Kasplex L2 can be independently verified by rerunning the EVM bytecode in standard order, ensuring transparency.

Limitations and Risks

Indexer Trust Issues: L2 indexers play a crucial role in executing bytecode and maintaining state, but there is a risk of malicious behavior from indexers, such as providing a Merkle root externally while privately maintaining a fabricated state. Addressing this issue requires the establishment of a decentralized indexer network and the introduction of economic incentives or penalty mechanisms.

Reorganization Challenge: Although Kaspa's BlockDAG is efficient, the parallel block creation mechanism may lead to recent block reorganizations. This could force L2 to roll back and re-execute transactions, increasing system complexity and introducing a certain risk of zero-confirmation double spending on L2.

Insights on UTXO model blockchain

Kasplex L2 provides a case study for the programmability extension of UTXO model blockchains, which holds reference significance for systems like Bitcoin. Both Kaspa and Bitcoin are limited in smart contract support due to UTXO design, but Kaspa's higher throughput and more flexible L1 architecture create a more favorable environment for L2 solutions.

For Bitcoin, the design of Kasplex L2 proposes the following exploratory directions:

Relay integration: The proxy submission mechanism demonstrates how to integrate EVM tools with UTXO blockchains, a concept that can be applied to second-layer solutions like Bitcoin's BitVM.

Execution based on indexers: Utilizing indexers to perform computations off-chain and anchoring data on L1 aligns with the Bitcoin Inscriptions model and may inspire new programmable expansion ideas.

From a research perspective, Kasplex L2 is a valuable experiment that demonstrates the differences in throughput and protocol flexibility of UTXO blockchains, and how these differences impact the feasibility of L2 solutions. Its research findings can provide design references for the entire blockchain ecosystem, especially for systems that prioritize decentralization and security over native programmability.

Conclusion

Kasplex L2 is a technically reliable Rollup-based implementation that supports EVM-compatible smart contracts by utilizing Kaspa's L1 for transaction ordering and data availability. Our analysis highlights its efficiency in leveraging Kaspa's high throughput BlockDAG, as well as its capability to expand through EVM compatibility. We believe that Kasplex L2 makes a practical contribution to the research of L2 solutions for UTXO model blockchains. A comparison with Bitcoin Inscriptions reveals similarities in shared principles and the impact of L1 design on the feasibility of L2. For researchers and developers, Kasplex L2 provides a perspective on the intersection of scalability, programmability, and decentralization in blockchain systems.

Reference

Kasplex Github. [Online]. Available:

Kaspa Research, “On the Design of Based zk-Rollups over Kaspa’s UTXO-Based DAG Consensus,” 2024. [Online]. Available:

Special thanks to our BitsLab researcher @ZorrotChen for your contributions to this article!