ScaL2Chain: Towards a Scalable Protocol for Multi-Chain Decentralized Applications

Abstract

During the last decade, the blockchain landscape has rapidly evolved, fostering the development of decentralized applications (DApps) that utilize cross-chain interactions. Although existing technologies have enhanced transaction processing and introduced interoperability solutions, scalability challenges persist, undermining their effectiveness. In particular, traditional cross-chain DApp interaction protocols experience performance bottlenecks due to their dependence on on-chain validation mechanisms, resulting in increased latency and computational costs. To address these issues, this paper presents the ScaL2Chain protocol, which is designed to facilitate efficient and secure cross-chain transactions for DApps. ScaL2Chain leverages off-chain technologies, such as payment channels, to enable participants to conduct transactions with a minimal on-chain footprint. By implementing an innovative state verification mechanism, ScaL2Chain guarantees high performance, confidentiality, and transaction integrity. Our empirical evaluations indicate that ScaL2Chain significantly outperforms existing solutions in terms of transaction throughput. Specifically, compared to baseline systems, ScaL2Chain achieves a 7.9-times to 8.4-times improvement in permissionless environments and a 1.9-times to 35.8-times improvement in permissioned environments under workloads with 4-64 DApps and varying cross-chain transaction ratios (0–100%).

1. Introduction

Blockchain is a decentralized, immutable, and transparent distributed ledger that enables multiple participants within a network to collaboratively maintain a consistent record in the absence of mutual trust [1]. Its foundation is built upon consensus mechanisms that ensure the security and integrity of the ledger, thereby mitigating single points of failure and reducing the risk of malicious manipulation [2,3,4,5]. Originally emerging from Bitcoin, blockchain technology was designed to provide a secure and reliable record of digital currency transactions [6]. As the technology has evolved, blockchain has transitioned from merely recording transactions to supporting smart contract platforms that enable intricate applications, such as Ethereum [1]. The introduction of smart contracts not only enhances blockchain’s functionality but also promotes the development of decentralized applications (DApps) and cross-chain interaction protocols [7]. This advancement facilitates efficient and secure exchanges of data and value between diverse blockchains, fulfilling the growing demands for transparency, trust, and efficiency across various industries, including finance, supply chain management, and healthcare [8].

Despite the significant role of traditional DApps and their cross-chain interaction protocols, numerous scalability challenges persist. First, these protocols often encounter limitations in transaction capacity; existing DApp cross-chain solutions rely on blockchain consensus mechanisms to validate transaction authenticity, which restricts the processing speed and throughput [9]. Additionally, light client-based bridging solutions suffer from inefficiencies in information transmission, as they require the sharing of substantial data proportional to the length of the source chain, resulting in a large computational overhead [10]. Current solutions are primarily dependent on the characteristics of the source chain state and its consensus mechanism, complicating and extending protocol design, which negatively affects compatibility and usability across different blockchains [11]. To achieve scalable multi-chain DApp interaction protocols, three key requirements [12] must be satisfied.

1.

High Performance: Transaction processing should demonstrate high throughput and low latency.

2.

High Confidentiality: Detailed information regarding transactions between DApps should remain confidential.

3.

High Reliability: Each DApp interaction must guarantee that transactions are processed correctly and in the intended order.

Layer 2 refers to technologies that enhance the transaction efficiency by shifting the majority of transaction processing from the main blockchain to off-chain environments. Layer-2 solutions can address scalability challenges associated with cross-chain interactions among DApps. Specifically, the new protocol design employs off-chain technologies, such as payment channels, enabling users to execute secure transactions without relying on the main chain [13]. This approach significantly reduces the amount of on-chain data transmitted and simplifies verification processes [14]. Furthermore, the protocol incorporates incentive mechanisms to encourage participant compliance, thereby ensuring system stability and security [13,15,16].

However, existing Layer-2 solutions remain underdeveloped and struggle to meet all three aforementioned requirements simultaneously [17]. These solutions can be broadly categorized into two types: the first type consists of decentralized off-chain executors, where parties deposit assets on-chain and establish private communication channels for exchanging off-chain authenticated transactions [3]. Upon channel closure, the final collateral is recorded on-chain. Notable examples include payment channels for efficient token transfers and state channels for general transaction transfers [18]. However, since each channel handles transactions that are not guaranteed by Layer-1 consensus protocols, malicious nodes may disrupt the intended execution order, resulting in a system state that fails to meet security requirements [19]. The second approach involves centralized but untrustworthy executors. For instance, commit-chain schemes execute off-chain transactions through executors and periodically submit updates to the Layer-1 chain as checkpoints, allowing users to verify the correctness of transaction execution and challenge any wrongful behavior by the executors [20]. Furthermore, technologies such as verifiable computation and zero-knowledge proofs (ZKPs) enable rollup protocols [21] to record verifiable execution proofs on-chain, thereby enhancing the usability of Layer-2 transactions and alleviating the monitoring burden on users regarding executor behavior.

To address these gaps, this paper introduces ScaL2Chain, a scalable and privacy-preserving Layer-2 protocol specifically designed for secure, high-performance, and reliable cross-chain interactions among decentralized applications (DApps). ScaL2Chain incorporates lightweight nodes and off-chain payment channels [22] to minimize the on-chain data overhead and expedite transaction processing. Additionally, it introduces an innovative state verification mechanism that ensures security and consistency during cross-chain operations. Furthermore, ScaL2Chain employs privacy-preserving technologies to protect sensitive transaction details and implements robust consensus rules to mitigate malicious behaviors, thereby achieving an efficient, trustworthy, and confidential environment for cross-chain interactions. The distinctions between our work and previous studies are summarized in

Table 1. Comparison of ScaL2Chain with existing works.

Solution	Scalability Enhancement	Cost Efficiency	Complex Contract Support	High Throughput	Universal Compatibility
Bool Network [23]	✗	✗	✗	✗	✔
Glimpse [24]	✗	✔	✗	✗	✗
PSSC [25]	✔	✔	✗	✔	✔
Tremble [26]	✔	✔	✗	✔	✗
Universal Atomic Swaps [27]	✗	✔	✗	✗	✔
Verilay [28]	✗	✔	✗	✗	✗
ScaL2Chain	✔	✔	✔	✔	✔

.

We summarize our contributions as follows:

1.

We propose ScaL2Chain, a novel scalable protocol designed to facilitate efficient state sharing and interaction among multi-chain DApps. ScaL2Chain can execute cross-chain transfers conditionally, efficiently, securely, and trustlessly, thereby addressing the performance bottlenecks of existing multi-chain DApp solutions.

2.

We design the cross-chain transaction processing flow of the transmission integration constraint synergy (TICS) workflow to ensure efficient and trustless transaction execution in a multi-chain environment. This process optimizes the state update mechanism, safeguarding both transaction confidentiality and execution correctness, thereby effectively preventing potential malicious activities.

3.

We conduct extensive experiments to evaluate the performance of ScaL2Chain. Our evaluation compares ScaL2Chain against three baseline systems across key parameters including the DApp count (4-64), cross-application transaction ratio (0–100%), and node failure rate (0–30%). The results indicate that ScaL2Chain’s throughput in a non-task environment improves by 7.9 to 8.4 times compared to baseline schemes, while, in permissioned environments, it increases by 1.9 to 35.8 times.

2. Background

In this section, we first present an example of multi-chain DApps to illustrate the motivation for our work. Subsequently, we introduce the primary concepts related to our proposed solutions.

2.1. Motivation Example

As shown in Figure 1, we present three DApps operating on different blockchains: a lending platform, liquidity providers, and asset managers. Each DApp is supported by three executors (nodes). In this context, two workflows are illustrated.

Workflow 1. Consider the following business logic for cross-application transactions ① to ③: ① the lending platform $L_A$ creates order $O_m$ for a 5 BTC loan and sets its status to “Created”; ② the asset manager $M_B$ receives $O_m$, assigns fund pool $F_n$ to the order, and designates liquidity provider $P_A$ to transfer the funds; ③ after the funds are secured, $L_A$ updates the status of $O_m$ to “Funded”.

Workflow 2. In-application transactions ④ and ⑤ result in the following business logic: ④ user $U_A$ pledges collateral and requests a 5 BTC loan from lending platform $L_A$; ⑤ once the collateral is verified, $L_A$ updates the borrowing record and commits the new status to the blockchain.

High Confidentiality. For each DApp, certain data are only visible internally, with only data hashes recorded on the blockchain for integrity checks. Certain transaction content must remain hidden from DApp executors, including the value of $U_A$’s collateral in transactions ④ and ⑤.

High Reliability. Ensuring transaction security requires adherence to two standards: (1) execution correctness—this must be publicly verifiable; without disclosing the value of user collateral, the lending platform must ensure that $U_A$ locked adequate collateral when obtaining the loan; (2) transaction ordering—this ensures that DApps can only execute transactions in a predetermined order to prevent rollback attacks; otherwise, malicious users may exploit outdated states for unfair advantages, such as borrowing against already liquidated collateral, compromising system security.

State Inconsistency. Transactions ④ and ⑤ signify changes to $U_A$’s collateral status and loan records, confirmed with signatures from the lending platform DApp executors. After processing transaction ⑤, if colluding executors attempt to alter $U_A$’s collateral status or loan balance, Layer-1 validators may be unable to detect these outdated states, leading to inconsistencies between Layer 1 and Layer 2.

Breach of Confidentiality. Assuming that the DApp operates in a black box, inputting the encrypted value of $U_A$’s collateral and then outputting the updated loan eligibility status (if valid), if the system state can be rolled back and different collateral values can be fed into the “black box”, the encrypted user collateral values may be at risk of targeted attacks, potentially manipulating collateral-to-loan ratios until resulting in an output of “insufficient collateral”.

Scalability. To enhance the scalability of DApps, ScaL2Chain employs a multi-chain architecture to support high throughput and flexible cross-chain transactions. For example, ScaL2Chain allows users to engage in cross-chain lending across multiple chains, enabling borrowers to pledge collateral on one chain while receiving loans on another, increasing the capital efficiency while ensuring that users can quickly and conveniently access financial services across different blockchain ecosystems. Furthermore, ScaL2Chain’s consensus-agnostic characteristic allows for seamless deployment on any chain supporting payment channels, thereby enhancing interoperability across various blockchains. As a result, ScaL2Chain improves the scalability and security of decentralized lending applications, paving the way for innovative DeFi applications, such as trustless cross-chain collateralized lending.

To meet these requirements simultaneously, we introduce ScaL2Chain.

2.2. Payment Channel Layer-2 Blockchain Scaling

We describe payment channels established through interactions with the blockchain, facilitating instantaneous payments between two parties. These channels are fundamentally similar to those detailed in previous research (see, for example, [13]). As depicted in Figure 2, the payment channel $\gamma$ between the participants, Alice and Bob, is established via an opening protocol in which Alice deposits 100 coins and Bob deposits 50 coins. Consequently, the initial balance of the channel can be represented by the following process:

$$[Alice\to 100,Bob\to 50]$$

This representation indicates that Alice possesses 100 coins in her $\gamma$ account, while Bob possesses 50 coins, resulting in a total of 150 coins.

Before channel $\gamma$ is closed, these coins remain locked, meaning that the participants cannot utilize them for other purposes. Once this setup is complete, Alice and Bob can update their fund allocation within the channel multiple times without interacting with the blockchain. For instance, if Alice wishes to pay Bob 20 coins, the updated balance would be

$$[Alice\to 80,Bob\to 70]$$

The total value remains 150 coins.

Payment channels significantly enhance the scalability of blockchain technology by enabling numerous rapid transactions to occur off-chain without the need to submit each transaction to the blockchain. Through channel transactions, multiple small transactions can be aggregated into a single on-chain transaction, thus reducing the load on the blockchain, lowering the transaction fees, and increasing the processing speeds. When Alice and Bob decide to close the channel, Alice submits the current balance to the blockchain, resulting in her receiving 80 coins and Bob receiving 70 coins. This mechanism facilitates continuous off-chain updates of transaction states, allowing participants to conduct multiple transactions while only requiring the first and last transactions to be recorded and uploaded to the blockchain. Consequently, this not only enhances the transaction efficiency but also significantly improves the scalability of the blockchain network, enabling greater simultaneous user participation.

3. Related Works

3.1. Scalability of Decentralized Applications

The business logic of DApps is implemented through smart contracts on the blockchain. Permissionless blockchains like Ethereum [29] pioneered smart contract functionality but have limited throughput due to their proof of work (PoW) consensus. This limitation has spurred the development of more efficient blockchain architectures.

• Advanced BFT engines. Permissioned ledgers such as Hyperledger Fabric [30] and Quorum [31] use crash-fault or Byzantine fault tolerance (BFT) mechanisms instead of PoW. These systems implement protocols like Raft [32], PBFT [33], and IBFT [29], achieving several hundred transactions per second (TPS). However, each replica re-executes every transaction, and global ordering becomes a bottleneck with multiple DApps on the same chain. Research has streamlined Byzantine consensus: Tendermint [34], HotStuff [35], and SBFT [36] reduce message rounds or achieve linear commits, but the throughput is still limited because each validator duplicates state storage and execution. Hybrids on Steroids [37] encapsulates consensus logic within Intel software guard extensions (SGX) to reduce the latency while maintaining deterministic replay requirements.
• Sharding and cross-application architectures. OmniLedger-style shards [38] partition states horizontally to increase the aggregate TPS, but cross-shard transactions require two-phase protocols and still serialize through shard roots, creating bottlenecks. CAPER [39] and MultiChain [40] enable each DApp to operate its own consensus while a higher-level protocol manages inter-application transfers, adding complexity and latency. SlimChain [41] separates execution from ordering by maintaining only digests on-chain, but its single Merkle accumulator becomes a contention point when multiple proposers attempt concurrent updates.

3.2. Scalable Blockchain Protocol

Scalable blockchain protocols address scalability limitations by offloading transaction processing from the main chain while maintaining its security. These methods differ in their architectures, security models, and performance.

• Payment and state channel networks. The Lightning Network [13] and its duplex extension [22], along with the Raiden Network for ERC-20 tokens [42], allows participants to exchange signed updates off-chain, settling only opening and closing states on Layer 1. These networks provide sub-second latency and low fees but have limited transaction logic and require participants to stay online throughout the routing process.
• Commit-chain architectures. Commit chains evolve architectures through Khalil et al.’s model [43], placing an untrusted operator between users and Layer 1. This operator periodically submits the Merkle roots of the off-chain ledger to Layer 1, allowing users to submit fraud proofs when necessary. This design removes the “always online” requirement of payment channels, but it exposes transaction contents to the operator, raising privacy concerns.
• Rollup systems. Rollups are an advanced Layer-2 paradigm with two main types. Optimistic rollups batch transactions and rely on fraud-proof challenge windows, causing finality delays of minutes to days. Notable examples include the Plasma [44] and Optimistic rollup prototypes [45]. Zero-knowledge rollups (ZK-rollups) use succinct ZKPs instead of fraud proofs; zkSync [46] and similar designs [21] achieve faster finality but incur high computational costs for proof generation. Both approaches use a single global Merkle root, which can create contention when multiple DApps operate.
• TEE-assisted Layer 2. Some systems combine Layer-2 processing with trusted execution environments (TEEs). Teechain [47] shows how TEEs can secure multi-hop payment channels, while Hybrids on Steroids [37] uses SGX to speed up BFT consensus. SlimChain [41] executes contracts within SGX proposers while using stateless Layer-1 validators. These methods offer advantages but may expose plaintext transactions or still serialize state updates through a single root hash, limiting scalability in concurrent applications.

3.3. Multi-Chain Constructions

Multi-chain structures can be used to address the issues of liquidity and user activity dispersion across multiple blockchain networks. These systems achieve cross-chain interoperability through various architectural approaches.

• Sidechain implementations. Sidechains expand blockchain ecosystems by running parallel chains with bidirectional asset transfer. Liquid [48] is an early Bitcoin sidechain using federated consensus for confidential transactions and fast settlement. Polygon [49] operates a proof of stake (PoS) sidechain for Ethereum, processing EVM-compatible transactions at higher throughput while committing checkpoints to the main network. Gnosis Chain [50] shows how application-specific sidechains can be optimized for certain use cases while inheriting security from the parent chain. Avalanche’s subnet architecture [51] allows customizable sidechains with independent validators. While sidechains enhance throughput, they generally involve security trade-offs as they have fewer validators, raising centralization risks [52].
• Multi-chain network protocols. Multi-chain network protocols create interoperability frameworks for independent blockchains. Cosmos pioneered this with the inter-blockchain communication (IBC) protocol [53], enabling trustless state transfers through standardized messaging and light client verification. Polkadot [54] uses a shared security model where parachains inherit security from a common validator set. Its cross-consensus message (XCM) format [55] standardizes cross-chain communication. Innovations like Chainlink’s cross-chain interoperability protocol (CCIP) [56] and LayerZero [57] enhance trustless communication. These protocols advance an interconnected ecosystem that maintains the unique advantages of individual chains while facilitating seamless cross-chain interactions [11].

4. ScaL2Chain Overview

4.1. Design Goals and Challenges

We next summarize the relevant design goals and technical challenges regarding scalable cross-chain DApp transaction protocols and secure, low-cost cross-chain transaction verification.

4.1.1. Scalable Cross-Chain DApp Transaction Protocol

• Design objectives. (1) Achieve scalability through constant computational and storage complexity. (2) Enable cross-chain operations independent of source chain consensus mechanisms. (3) Minimize data storage and relay requirements. (4) Support deployment on blockchain platforms with signature verification capabilities.
• Technical challenges. (1) Different blockchain ecosystems implement various rules and consensus mechanisms. It is essential to develop an innovative cross-chain state transition verification mechanism to ensure the accuracy and consistency of transactions without relying on the consensus of the source chain. (2) There are inherent differences in transaction loads and architectures among different blockchains. Therefore, it is necessary to construct an efficient computational model to reduce the time and space complexity of cross-chain operations. (3) Finding the right balance between the data required for efficiency and security is crucial. We must design a lightweight transaction relay and storage solution to transmit only the minimal necessary cross-chain data. (4) The diverse architectures and consensus algorithms adopted by different blockchains complicate the creation of standardized protocols. (5) Some challenges may be encountered during actual deployment. In interactive verification schemes, all ScaL2Chain states must maintain eventual consistency. The key to achieving this consistency lies in efficiently and securely transmitting and verifying messages to avoid potential security risks. Therefore, a universal cross-chain DApp transaction protocol that is compatible with blockchain platforms supporting basic signature verification is needed.

4.1.2. Secure and Low-Cost Cross-Chain Transaction Verification

• Design objectives. (1) Conduct comprehensive security analysis within the universal composability framework. (2) Implement robust penalty mechanisms to deter malicious behavior. (3) Control transaction costs within twice the standard Ethereum transaction fee. (4) Ensure near-instant transaction finality.
• Technical challenges. (1) In a distributed environment, a range of potential adversarial behaviors and attack vectors exist. Thus, we need to employ methods from the Byzantine adversary model to formally prove the security of the protocol. (2) In a competitive landscape, understanding participants’ motivations and designing effective mechanisms to encourage cooperation are essential in mitigating the risks associated with exploitation and dishonest behavior. We must create multi-layered economic incentive mechanisms to guide participants toward honest behavior. (3) Simplifying the verification process often introduces security vulnerabilities, while overly complex processes may impede scalability and responsiveness. We must optimize the verification process to reduce the computational complexity while maintaining security integrity. (4) Nodes exhibit geographic dispersion and experience inherent communication latency across different networks. Therefore, achieving near-instant finality while minimizing the impact of network latency is essential.

4.2. Current Limitations

4.2.1. Computational and Storage Complexity

DApp cross-chain transactions face significant challenges related to storage and computational complexity. Traditional cross-chain transaction solutions [21,58] require the storage of data blocks and proof headers in a manner that is linearly correlated with the length of the source chain, resulting in storage complexity of $\mathcal{O}\left({\mathcal{L}}_O\right)$. Concurrently, the generation of ZKPs demands substantial computational resources, with the cost of a single verification approaching 230,000 gas and the computational complexity being linearly proportional to the length of the source chain. As the scale of blockchain networks expands, the storage and computational overheads of cross-chain bridging systems will increase exponentially, severely constraining system scalability and performance. Furthermore, the divergent consensus mechanisms across different blockchains exacerbate this technical bottleneck, rendering current cross-chain bridging solutions inadequate for large-scale network environments.

4.2.2. Security and Interoperability

Another critical challenge in DApp cross-chain transactions is the risk of centralization, frequent hacking attacks, substantial financial losses, and significant interoperability limitations. These cross-chain transaction methods typically rely on specific blockchain consensus mechanisms, which impede universal cross-chain interaction. Current solutions primarily support only basic token exchanges and lack the capability to verify complex off-chain transactions or accommodate advanced financial applications. More importantly, these approaches require the triggering of on-chain events, which increases the transaction processing burden on the blockchain and reduces the overall system throughput, resulting in prohibitively high relay and security verification costs.

4.3. System Overview

Figure 3 provides an overview of ScaL2Chain, which facilitates secure interactions between DApps across various blockchains. It comprises key components such as Alice and Bob, the participants; a smart contract that governs their transactions; and a protocol for state updates, dispute resolution, and fraud prevention. This protocol allows for unlimited DApp state updates on a Layer-2 network until a significant transaction is required on the target blockchain, highlighting a structured workflow that includes initialization, updates, and settlement phases. Security is enhanced through clearly defined timeouts and collateral requirements, ensuring that both parties comply with their agreements.

4.3.1. ScaL2Chain Protocol $\mathrm{\Pi }$

The ScaL2Chain protocol, denoted as $\mathrm{\Pi }$, is designed to facilitate secure and efficient interactions in DApps between the source chain ${\mathcal{L}}_O$ and the target chain ${\mathcal{L}}_D$. During the initialization phase, participants Alice and Bob reach an agreement and create a smart contract $\mathcal{SC}$ on the target chain through the $\mathsf{Setup}$ procedure, which manages both parties’ assets and maintains the transaction status. Alice and Bob can update the DApp status on the Layer-2 network an unlimited number of times until a transaction update is required on the target chain. If the status update can be completed successfully within the specified time limit $t_0$, Alice relays the transaction information $\mathrm{\Pi }$ to the smart contract using the $\mathsf{ProSub}$ procedure; if it cannot be completed on time, Alice can resolve disputes through the $\mathsf{Dispute}$ procedure. Meanwhile, Bob continuously monitors for potential disputes and can respond within the designated timeframe $t_1$. The design of the ScaL2Chain protocol also addresses potential fraud risks. For example, in the context of a loan DApp, Alice must lock an equivalent amount of assets on the target chain as collateral, ensuring her ability to repay the borrowed funds within a specified timeframe. If she fails to repay as agreed, Bob has the right to claim all assets held within the contract. The entire protocol upholds fairness and security by establishing clear timeout periods and dispute resolution mechanisms, thereby ensuring that agreements are maintained even when participants fail to submit the required information or initiate a dispute.

4.3.2. Decentralized Application $\mathcal{DAPP}$

Within the framework of the ScaL2Chain protocol $\mathrm{\Pi }$, the operation of the DApp is divided into multiple stages: setup, updating, and settlement. First, participants Alice and Bob create a smart contract on the target chain ${\mathcal{L}}_D$. Throughout the operation of the DApp, both parties can perform any number of state updates on Layer 2 until a transaction update must be executed on the main chain. The protocol establishes clear time limits and dispute resolution mechanisms to prevent dishonesty and financial losses, thereby ensuring a balance of interests for both parties. The DApp facilitates effective fund allocation and state management through a series of predefined parameters and functions, such as state transition relations and outcome mapping functions, providing users with secure and efficient decentralized financial services. By integrating time-lock contracts and dispute resolution solutions, our DApp enhances the transaction credibility and significantly boosts the security of interactions in a trustless environment.

4.3.3. Smart Contract $\mathcal{SC}$

The smart contract $\mathcal{SC}$ is a core component of the ScaL2Chain protocol $\mathrm{\Pi }$, responsible for managing and executing transactions within DApps on the target chain ${\mathcal{L}}_D$. This contract ensures the security and transparency of transactions between Alice and Bob through a series of explicit functions and conditions, and it is capable of addressing potential disputes and instances of fraud. During the protocol’s setup phase, Alice and Bob first create the smart contract via the $\mathsf{Setup}$ procedure and lock the corresponding assets as collateral. They also define an asset allocation function f, which maps the DApp state to the funding distribution between the two parties. These core parameters ensure the security of assets and the traceability of transaction states.

In the DApp update phase, the smart contract allows both parties to submit state update requests, which are internally validated to ensure compliance with the protocol’s stipulations. When Alice or Bob submits proof of a transaction, the contract performs a validity check to verify that the submitted state is current and legitimate. In specific situations, such as when Alice fails to submit an update within the specified timeframe, the smart contract triggers a penalty mechanism to protect the rights of the participants. Furthermore, the smart contract is designed to handle disputes, allowing Alice and Bob to initiate and resolve conflicts according to the rules of the protocol. If a dispute arises, the contract verifies the provided evidence and makes decisions regarding penalties or asset distribution. By clearly defining state transitions, penalty mechanisms, and settlement conditions, the smart contract $\mathcal{SC}$ safeguards the rights of both parties in a decentralized environment.

5. Protocol Design

This section delineates the transaction processing mechanism of the ScaL2Chain protocol $\mathrm{\Pi }$ and its corresponding smart contract $\mathcal{SC}$ deployed on layer ${\mathcal{L}}_D$. Initially, Alice and Bob establish consensus on the ScaL2Chain parameters and instantiate a smart contract on ${\mathcal{L}}_D$ through the $\mathsf{Setup}$ procedure. Subsequently, they execute an arbitrary sequence of DApps updates on Layer 2 until encountering a transaction update that requires execution on ${\mathcal{L}}_D$. If this update completes successfully within the predefined time threshold $t_0$, Alice propagates $\mathrm{\Pi }$ to contract $\mathcal{SC}$ via the $\mathsf{ProSub}$ procedure. In case of failure, Alice initiates resolution through the $\mathsf{Dispute}$ procedure. Concurrently, Bob monitors the dispute status on ${\mathcal{L}}_D$, and, upon Alice’s dispute initiation, Bob can resolve it prior to time $t_1$. If neither the protocol submission nor dispute initiation occurs before time $t_2$, Bob becomes entitled to all contract funds through the $\mathsf{Punish}$ procedure.

5.1. Naive Construction Workflow

In the cross-chain interaction scenario of the ScaL2Chain DApp, Alice and Bob represent two mutually untrusting participants. They deploy the DApp on the source chain ${\mathcal{L}}_O$ and maintain their respective cryptographic account key pairs $(sk,pk)$ on the destination chain ${\mathcal{L}}_D$. We assume that participants continuously monitor the transaction status on the destination chain ${\mathcal{L}}_D$ by operating full nodes throughout protocol execution. For analytical simplification, we establish that currencies on the source chain ${\mathcal{L}}_O$ and destination chain ${\mathcal{L}}_D$ possess equivalent economic value.

This section illustrates ScaL2Chain’s preliminary construction through a loan DApp. In the setup phase, depicted in Figure 4, Bob intends to provide a loan of amount b to Alice on the source chain ${\mathcal{L}}_O$. As collateral, Alice must lock an equivalent amount b in the smart contract on the destination chain ${\mathcal{L}}_D$. She can retrieve the collateral only by proving through the smart contract within a finite time $t_0$ that she has returned the loan to Bob (denoted as $Alice\stackrel{b}{\to }Bob$). Failure to repay as scheduled results in Bob retaining the collateral assets. During the setup phase, Alice and Bob are required to submit specific parameters to the smart contract:

• Channel funding transaction $t{x}_f$;
• Proof submission timeout threshold $t_0$;
• Dispute resolution timeout threshold $t_1$;
• Closure timeout threshold $t_2$ for scenarios with neither proof submission nor dispute initiated;
• Mapping function f transforming DApp token allocation to smart contract balance distribution.

We now construct the update phase of the ScaL2Chain protocol and identify potential vulnerabilities in its naive construction. In this phase, Alice intends to update the DApp via the transaction $Alice\stackrel{b}{\to }Bob$. She naively attempts to validate the update’s occurrence by presenting the commitment transaction $t{x}_{Alice}^l$ co-signed by herself and Bob. This approach inherently exposes Alice and Bob to substantial security risks. Upon submitting the commitment transaction $t{x}_{Alice}^l$ and its corresponding signatures ${\sigma }_A$ and ${\sigma }_B$ to the smart contract, these artifacts will be publicly disclosed on-chain, rendering them visible to all network participants, including external protocol actors. Consequently, anyone who possesses the commitment transaction along with Alice and Bob’s signatures could potentially complete their DApp loan transaction.

To prevent such risks, Alice and Bob must provide the smart contract with two commitment transactions, $t{x}_{Alice}^l$ and $t{x}_{Bob}^l$, accompanied by their corresponding signatures, ${\sigma }_A$ and ${\sigma }_B$. However, these commitment transactions exclusively contain the current DApp balance allocation information, omitting specific transfer amounts. Consequently, a malicious Alice could potentially exploit the contract through the following strategies:

• Submitting an outdated DApp update that predates the establishment of the ScaL2Chain smart contract;
• Submitting commitment transactions representing disparate DApp update stages, such as $t{x}_{Alice}^l$ and $t{x}_{Bob}^l$, corresponding to the i-th and $(i-1)$-th channel updates, respectively.

5.2. TICS Workflow

In this subsection, we design the update phase of the DApp in detail based on the TICS workflow illustrated in Figure 5. Simultaneously, Figure 6 illustrates the specific implementation of the update subprocedure, which performs rigorous validity checks for each state update.

5.2.1. Transmission

To verify whether the DApp update submitted by Alice satisfies the $Alice\stackrel{b}{\to }Bob$ condition, the smart contract must ascertain the balance allocation of both parties prior to the update. This requirement mandates that Alice and Bob report their channel’s balance allocation to the smart contract during the setup phase, before executing the $Alice\stackrel{b}{\to }Bob$ update. However, this approach reveals significant limitations: after contract initialization, both parties must expeditiously execute the update and abstain from intermediate updates before ScaL2Chain resolution. Consequently, if the circumstances evolve, both parties risk encountering inconsistent information.

To address this challenge, the smart contract can validate the update’s reasonableness by accessing the channel state preceding the $Alice\stackrel{b}{\to }Bob$ transaction. For instance, the smart contract could initially retrieve the latest commitment transaction demonstrating Alice holding $b_{Alice}$ tokens and Bob holding $b_{Bob}$ tokens. Subsequently, Alice and Bob provide a new $Alice\stackrel{b}{\to }Bob$ update commitment transaction illustrating Alice now possessing $b_{Alice}-b$ tokens and Bob holding $b_{Bob}+b$ tokens. Through this mechanism, the smart contract can infer the validity of Alice’s token transfer to Bob. However, this process reveals two primary potential vulnerabilities: first, it requires both parties to submit two commitment transactions; second, it remains unable to prevent potentially malicious behavior, such as Alice submitting an outdated state update.

5.2.2. Integration

To prevent Alice from submitting outdated states while ensuring effective state validation by the smart contract, our objective is to enable the smart contract to perform arbitrary DApp state updates during its lifetime, requiring only a concise commitment transaction proof from Alice and Bob individually.

To achieve this goal, we require two critical types of protocol information to be embedded in the commitment transaction $t{x}_u^l$ for the update $Alice\stackrel{b}{\to }Bob$. The first type is a unique identifier $id$ for the update, which enables multiple updates by DApp participants and provides the smart contract with a specific update marker, effectively preventing Alice from submitting false proofs composed of old updates. The second type involves embedding the hash of a revocation secret $r_u$ in $t{x}_u^l$, which helps the smart contract to verify the consistency of $t{x}_{Alice}^l$ and $t{x}_{Bob}^l$ states and prevents dishonest participants from submitting expired states. However, these protocol information elements in $t{x}_u^l$ alone cannot fully protect the protocol’s continuity, as malicious parties might still exploit non-revoked old states for DApp updates before contract settlement.

5.2.3. Constraint

During the active period of the ScaL2Chain contract, participants are prohibited from updating the DApp using unrevoked old states through on-chain methods. Under normal circumstances, the latest state should be the unrevoked state. However, the DApp update process may encounter significant risks, where one party might obtain the other party’s revocation secret before revealing their own, thereby gaining a substantial advantage by holding two unrevoked valid states or updating the DApp using any revocation secret without punishment.

It is crucial to emphasize that, even if a cheating party uses a revoked old state to update the DApp, ScaL2Chain’s security remains intact, as the counterparty can punish and reclaim funds. To prevent unrevoked old states from being used to update the DApp, we have implemented transaction time locks for all commitment transactions in ScaL2Chain, rendering these transactions invalid before a specific time. The ScaL2Chain DApp update process consists of four sequential steps:

• Participants exchange new revocation secrets;
• Exchange signed locked commitment transactions $t{x}_u^l$;
• Exchange old revocation secrets;
• When participants reach the expected update $Alice\stackrel{b}{\to }Bob$, exchange signed unlocked commitment transactions $t{x}_u^{unl}$.

The transaction time lock expires at $t_2$, preventing malicious participants from closing the channel through on-chain methods during the ScaL2Chain active period. As proof input for ScaL2Chain contract verification, we define proof $\pi$ as $(t{x}_{Alice}^{unl},{\sigma }_A,t{x}_{Bob}^{unl},{\sigma }_B)$. However, when one party is uncooperative—such as refusing to provide commitment transactions or old revocation secrets—the other party may be unable to immediately update the DApp due to time lock restrictions, potentially creating a hostage situation. For example, Bob might not respond to Alice’s DApp update request, retaining the collateral on ${\mathcal{L}}_D$ or abandoning the funds lent on ${\mathcal{L}}_O$, thereby leaving Alice passive and unable to update the DApp or redeem coins from the smart contract.

5.2.4. Synergy

To protect honest users from hostage attacks, we provide Alice with an economic leverage mechanism that encourages Bob to cooperate in updating the DApp. Specifically, if Bob fails to honestly update the channel within time $t_0$, Alice can invoke the contract’s $\mathsf{Dispute}$ function to submit a dispute, presenting the latest signed locked commitment transaction $t{x}_{Alice}^l$ received from Bob, along with a newly created signed unlocked commitment transaction $t{x}_{Bob}^{unl}$ to enforce the update.

Subsequently, Bob will have until $t_1$ to use the $\mathsf{ResolveDispute}$ function to reveal the signed unlocked commitment transaction $t{x}_{Alice}^{unl}$ and provide the necessary proof to the smart contract. If Alice raises a false dispute using an old state $t{x}_{Alice}^l$, Bob can punish her by revealing the revocation secret of that transaction. Notably, if Alice halts during the DApp update and attempts to frame Bob in the ScaL2Chain smart contract without sharing the revocation secret, Bob will not share the non-time-locked transaction with her, as the update remains incomplete.

At this point, even if Alice raises a dispute on ${\mathcal{L}}_D$ to reclaim the unlocked transaction, she will be unable to update the DApp using the old state, as the commitment transaction is locked until after $t_2$. In contrast, Bob will be able to extract the unlocked transaction $t{x}_{Bob}^{unl}$ from the smart contract, thereby updating the DApp and disclosing $t{x}_{Alice}^{unl}$. Thus, even in complex scenarios, the final state of the DApp can accurately reflect the true outcome on ${\mathcal{L}}_D$. Through this mechanism, the protocol effectively ensures security and fairness while protecting the rights and interests of both parties.

5.3. Adaptability Discussion

5.3.1. Consensus

When analyzing the adaptability of ScaL2Chain to various blockchain consensus mechanisms, the primary factor to consider is whether ${\mathcal{L}}_O$ employs a proof of work (PoW) mechanism. This critical determinant directly influences the operation and performance of ScaL2Chain, as differences in data verification and storage requirements across consensus protocols can result in significant resource consumption and costs.

In a PoW environment, ScaL2Chain can effectively implement light client protocols. These protocols allow smart contracts on ${\mathcal{L}}_D$ to track only the block headers of ${\mathcal{L}}_O$, utilizing Merkle proofs to verify the validity of transactions and related events. By minimizing the data that need to be processed, this approach significantly reduces the computational and storage burdens, thereby enhancing the interaction efficiency.

However, when ${\mathcal{L}}_O$ transitions to a non-PoW consensus mechanism, such as proof of stake (PoS), the benefits of light client protocols diminish. In a PoS environment, smart contracts on ${\mathcal{L}}_D$ must verify all block headers and maintain an ever-expanding blockchain. This process incurs substantial computational and storage overheads, which may lead to verification delays, thus impacting the timeliness and feasibility of inter-chain interactions. For instance, the cost of verifying a single block header on Ethereum can be as high as approximately USD 4900, a fee that is prohibitive for most applications.

To address scenarios in which ${\mathcal{L}}_O$ is a non-PoW blockchain, we propose the application of Bulletproofs as a solution. Bulletproofs are an efficient non-interactive zero-knowledge proof scheme that enables the prover to demonstrate effectively to smart contracts on ${\mathcal{L}}_D$ that ${\mathcal{L}}_O$ has undergone a specific state transition. In this design, the smart contract continuously tracks the latest state of ${\mathcal{L}}_O$, denoted as $\mathsf{st}$, and allows any participant to generate and submit a Bulletproof to prove the transition of the state from $\mathsf{st}$ to ${\mathsf{st}}^{\prime }$.

This design offers two significant advantages. First, the reliability characteristics of Bulletproofs ensure the overall security of ScaL2Chain, eliminating the need for additional security assumptions, particularly avoiding reliance on committees. Second, with specially constructed Bulletproofs, ${\mathcal{L}}_D$ can verify state transitions more efficiently than by directly integrating the consensus mechanism of ${\mathcal{L}}_O$ into the smart contract. This optimization not only significantly reduces the overall cost of ${\mathcal{L}}_O$ but also keeps the storage overhead of the smart contract at a manageable constant value, further enhancing the flexibility and adaptability of ScaL2Chain in accommodating various consensus mechanisms and distinct blockchain architectures.

5.3.2. Resource-Constrained Small Blockchain

Given the limitations in computing capacity, storage space, and network bandwidth inherent in many smart devices, traditional blockchain consensus mechanisms are often inadequate. To address these challenges, the ScaL2Chain protocol has been optimized for resource-constrained environments. Firstly, ScaL2Chain significantly reduces the volume of on-chain data transmission by leveraging off-chain technologies such as payment channels. This reduction is particularly important for resource-limited networks. For instance, smaller blockchains frequently struggle to manage a high volume of on-chain verification and processing tasks. In contrast, ScaL2Chain mitigates these demands through an effective state validation mechanism, thereby ensuring high availability and real-time transaction capabilities. Secondly, the protocol’s design allows it to operate under any consensus mechanism. This compatibility enhances the flexibility for smaller blockchains by enabling them to select consensus methods that align with their specific needs. Furthermore, ScaL2Chain prioritizes data privacy and security during interactions—a critical aspect for smaller networks that may be more vulnerable to attacks.

6. Security in the UC Framework

6.1. Security Model

To formally model our construction, we adopt the global universal composability (GUC) framework [59]. Our analysis draws on methodologies from the existing literature [3,60,61,62,63,64]. We utilize the ideal functionality of payment channels [62] to accurately capture their characteristics. Our model is fully consistent with the payment channel framework, incorporating synchronization with a global clock [65], authenticated communication to ensure message delivery [61], and treating the ledger as an ideal append-only data structure for the tracking of all published transactions [62]. We instantiate the ledger twice: once for ${\mathcal{L}}_D$ and once for the payment channel functionality, which indirectly serves ${\mathcal{L}}_O$, positioned above ${\mathcal{L}}_O$. The delay of the ledger is parameterized by $\mathrm{\Delta }$, where $\mathrm{\Delta }$ represents the upper limit on the time required for a valid transaction record to be reflected in the ledger.

6.2. Ideal Function ${\mathcal{F}}_{ScaL2chain}$

We introduce the ideal functionality ${\mathcal{F}}_{ScaL2chain}$, which formally defines the input/output behavior, any side effects on $\mathcal{L}$, and the properties that we aim to capture. Specifically, we encapsulate atomicity through a penalty attribute. Informally, this means that if one party publishes an outdated state or refuses to execute a valid update, all funds will revert to the non-cheating party (i.e., a penalty will be imposed). As long as this attribute is preserved, it can be readily proven that ScaL2Chain satisfies this definition.

6.3. Security Analysis

We assume the existence of static corruption, in which the adversary $\mathcal{A}$ selects the targets to corrupt at the onset of the protocol’s execution. Concurrently, there exists an environment $\mathcal{E}$ that can capture any events outside the protocol’s execution. The UC proof aims to demonstrate that the formal ScaL2Chain protocol $\mathrm{\Pi }$ is as secure as the ideal functionality ${\mathcal{F}}_{ScaL2chain}$ or the version of ${\mathcal{F}}_{ScaL2chain}$ implemented through GUC, thus sharing the same security properties. To this end, we define a simulator $\mathcal{S}$ that can transform any attacks on the real-world protocol $\mathrm{\Pi }$ into attacks on the ideal functionality ${\mathcal{F}}_{ScaL2chain}$. In other words, for any probabilistic polynomial-time (PPT) environment $\mathcal{E}$, whether interacting with $\mathrm{\Pi }$ or with ${\mathcal{F}}_{ScaL2chain}$ and $\mathcal{S}$, the interactions should be computationally indistinguishable. Finally, we present the main security theorem.

Theorem 1.

The ScaL2Chain protocol Π GUC realizes the ideal functionality ${\mathcal{F}}_{ScaL2chain}$.

7. Experimental Study

7.1. Experimental Settings

7.1.1. Key Parameters

• DApp Workload Design. Each DApp employs the KVStore smart contract from the BLOCKBENCH [7] macro-benchmark suite, which executes read and write operations on key–value pairs. The experiments use YCSB workloads [66] in three configurations: mixed mode (50% reads, 50% writes), read-only mode, and write-only mode. To simulate cross-application transactions, state addresses are evenly distributed among DApps, and transactions are constructed by randomly combining two read/write operations. These transactions may execute within a single DApp or span two DApps.
• Node Configuration Scheme. System nodes are allocated based on the total number of DApps, with each DApp configured with four nodes. Each DApp connects to a single client that submits the workload. To evaluate ScaL2Chain’s fault tolerance against pure L1 solutions, we introduce temporary failures at each block interval, where nodes in ScaL2Chain fail with probability $\varphi$.
• Other Parameters. Following prior work [67], the block generation frequency does not affect the throughput but increases the latency when reduced. We therefore adopt standard settings: 1-second intervals for Raft and 10-second intervals for PoW. For the block capacity and ScaL2Chain batch size, larger values increase both the throughput and latency. We set both parameters to 256 transactions, approximating Ethereum’s average block size. Based on Ethereum’s address statistics, we configure the global state size to $2^{26}$ entries, shared across all DApps.

7.1.2. Baseline Systems, Metrics, and Experimental Environment

We select three baseline systems for comparison with ScaL2Chain under both permissioned and permissionless network environments: Quorum, CAPER, and SlimChain. To ensure a fair comparison and result reproducibility, all baseline systems and ScaL2Chain operate on identical Azure Standard-DC16ads-v5 (Microsoft, Redmond, WC, USA) instances with uniform hardware specifications (16 vCPUs, 64 GB RAM, 1500 Mbps bandwidth). YCSB workloads use identical random seeds across all systems to ensure comparable transaction patterns. Each data point represents the average of 5 independent runs with 95% confidence intervals. All systems are optimized according to their official documentation, and measurements exclude 60-second warmup periods to eliminate initialization bias. Network conditions and failure scenarios are controlled using standardized simulation parameters to ensure reproducible results. We measure the throughput and latency across the parameter space defined in

Table 2. Key parameters and their value ranges used in the experiments.

Parameter	Values
Number of DApps	4, 8, 16, 32, 64
Percentage of cross-app transactions	0%, 25%, 50%, 75%, 100%
DApp node failure rate $\varphi$	0%, 10%, 20%, 30%

. The throughput is the number of transactions finalized per second by the main chain. Latency encompasses the average time for transaction execution, consensus, and additional overheads. Additional overheads include encryption/decryption in Quorum and SlimChain and RSA accumulator operations in ScaL2Chain. We exclude the transaction queuing time at DApp nodes, since peak throughput measurements require full-capacity operation, which generates substantial queuing delays.

7.2. Experimental Results

• Analysis of Impact of DApp Scale on System Performance. The experimental data in Figure 7 indicate that, as the number of DApps increases, the throughput of all permissioned blockchain systems exhibits a downward trend. Performance comparisons reveal that ScaL2Chain demonstrates significant scalability advantages: its throughput lead over Raft Quorum increases from 23.6 times to 35.8 times, while its advantage over CAPER grows from 1.9 times to 2.5 times. Regarding latency performance, the latency reduction of ScaL2Chain relative to Raft Quorum improves from 65.2% to 75.9%. ScaL2Chain employs a Layer-2 architecture and a four-stage TICS workflow to handle cross-chain interactions, whereas CAPER processes only intra-chain cross-application communications through a directed acyclic graph structure. Consequently, ScaL2Chain incurs a higher latency overhead than CAPER. However, as the number of DApps increases, ScaL2Chain’s latency multiple relative to CAPER decreases from 3.9 times to 3.3 times. These metrics robustly demonstrate the exceptional scalability of ScaL2Chain in permissioned networks. However, in comparisons with the performance of Quorum-P and SlimChain-P, the improvement of ScaL2Chain remains relatively constant, with performance advantages maintained between 7.9 and 8.4 times and 1.6 and 1.8 times, respectively. This phenomenon arises because the PoW consensus protocol in the L1 chain becomes the primary performance bottleneck, and its processing efficiency is unaffected by variations in the number of DApps.
• Impact of Cross-Application Transaction Ratio on System Performance Constraints. Figure 8 shows that as the ratio of cross-application transactions increases from 0% to 100%, both CAPER and ScaL2Chain-R experience a decline in throughput and an increase in latency due to the need to execute Raft local consensus among DApps. Specifically, the processing capacity of ScaL2Chain-R drops from 1462 TPS to 1176 TPS, while that of CAPER decreases from 986 TPS to 324 TPS. ScaL2Chain-R employs a batching strategy that requires only two global consensus rounds. Consequently, its throughput advantage over CAPER amplifies as the cross-application transaction ratio increases, rising from an initial 1.5 times to 3.6 times. In terms of latency, the latency overhead multiple of ScaL2Chain-R compared to CAPER decreases from 3.5 times to 2.8 times, indicating that the batching strategy effectively mitigates delays caused by local consensus in high cross-application transaction scenarios.
• Regulation Effect of Read/Write Operation Ratio on System Performance. The experiments adjusting the read/write operation ratio of workloads, shown in Figure 9, indicate that, under purely read load conditions, all systems can achieve outstanding throughput values exceeding 13,000 TPS, primarily due to the absence of a consensus protocol overhead in read operations. However, as the ratio of write operations increases, the processing performance of all systems shows a downward trend. From the perspective of latency, the consensus overhead of ScaL2Chain is comparable to that of CAPER, PoW Quorum, and SlimChain.

8. Conclusions

In this work, we present ScaL2Chain, a novel protocol designed to address the scalability challenges encountered by multi-chain DApps. We establish the advantages of off-chain transaction processing over traditional on-chain solutions and demonstrate how ScaL2Chain employs payment channels to enhance the transaction speed, security, and confidentiality. Notably, we introduce a unique state verification mechanism that ensures accurate and consistent cross-chain interactions without relying on the consensus of the source chain.

We emphasize that ScaL2Chain facilitates efficient asset transfers across multiple blockchains, thereby unlocking new opportunities for multi-chain DApps, including trustless lending protocols. Furthermore, our protocol enables users to execute cross-chain operations seamlessly, increasing interoperability while reducing on-chain costs.

We conducted a rigorous analysis of ScaL2Chain within the UC framework, complemented by game-theoretic insights to ensure rational behavior among participants. Our empirical evaluations indicate that ScaL2Chain surpasses existing solutions, achieving significant improvements in throughput and latency, thereby reaffirming its potential to enhance DApp interactions by fostering more accessible and efficient economic transactions across diverse blockchain ecosystems.