chainScale: Multi-Chain Scalability

• chainScale is a blockchain interoperability protocol that enhances scalability and consistency by distributing local tasks and coordinating cross-chain events via one-time contracts.
• It decomposes cross-chain transactions into per-chain tasks with reversal mechanisms to ensure atomicity and resilience under varying consensus rules.
• The scheme leverages efficient request channels and a mixed push/pull gossip network to maintain timely state updates and minimize overhead in cross-chain operations.

chainScale is a blockchain interoperability scheme introduced to improve overall scalability by distributing workload across multiple independent blockchains, while coordinating only the subset of tasks that span chains through a one-time cross-blockchain contract and a blockchain-wise gossip network. Its stated objective is to provide linear scalability for the whole system and consistency among honest systems, without requiring one global chain to process all activity (Liu et al., 2020). In the cited literature, the label also appears in unrelated contexts, including numerical methods for Lévy scale functions (Mijatović et al., 2013) and chain-based model scaling for LLMs (Song et al., 17 May 2025).

1. Terminological scope and motivating problem

In the blockchain usage, chainScale addresses two coupled difficulties: performance scalability, meaning higher throughput without weakening security, and node scalability, meaning support for many nodes without the quadratic communication cost typical of classic BFT protocols. The scheme starts from the observation that local transactions can remain on their native chains, while only cross-chain tasks need explicit coordination. This shifts scalability from vertical expansion of a single chain to cooperative execution across multiple blockchain systems (Liu et al., 2020).

The label is not unique in the cited literature. The following usages are distinct.

Usage	Domain	Core idea
chainScale	Blockchain interoperability	One-time cross-blockchain contracts plus gossip-based consistency (Liu et al., 2020)
“chainScale” method	Lévy-process numerics	CTMC approximation and finite recursion for scale functions (Mijatović et al., 2013)
“chain-scale” language modeling	LLMs	Nested chain-based scaling through CoR, CoL, and CoM (Song et al., 17 May 2025)

Within blockchain research, the central claim is that interoperability can improve scalability because each blockchain processes its own local workload independently, and only cross-chain tasks invoke the coordination protocol. The main risk introduced by that design is correctness under heterogeneous consensus rules and adversarial conditions across chains. chainScale therefore couples its scalability argument to a consistency mechanism based on contract finalization, request channels, and gossip dissemination of remote views (Liu et al., 2020).

2. Architectural structure

The framework has three principal components: a one-time cross-blockchain contract (CBC), request channels for checking and committing cross-chain status, and a blockchain-wise gossip network that spreads views and detects inconsistencies. A cross-chain task involving systems $S_i$ and $S_j$ is decomposed into per-chain transactions $(tx_i, tx_j)$, together with reversal transactions $(tx_i', tx_j')$ used if the task fails (Liu et al., 2020).

For system $S_i$, the contract transaction is defined as

$$ctx_i := H(tx_i)\,||\,H(tx_i')\,||\,h_i\,||\,j\,||\,H(tx_j)\,||\,H(tx_j')\,||\,h_j ,$$

and symmetrically for $S_j$,

$$ctx_j := H(tx_j)\,||\,H(tx_j')\,||\,h_j\,||\,i\,||\,H(tx_i)\,||\,H(tx_i')\,||\,h_i .$$

Here $H(\cdot)$ is a hash function, $h_i$ and $S_j$0 are expiration heights, and $S_j$1 is the reversal of $S_j$2. The contract is “one-time” because it coordinates one specific cross-chain task and becomes irrelevant after expiration or finalization (Liu et al., 2020).

The purpose of the CBC is to approximate atomic behavior across chains. Either both systems complete their intended transactions, or the timeout logic causes the reverse transactions to be committed. The result is then bound to each blockchain through on-chain finality and immutable block history. The protocol also imposes a locking rule: if $S_j$3 is a precondition of $S_j$4, then $S_j$5; if a contract is waiting, any dependent transaction is locked and cannot be verified as valid until the contract resolves (Liu et al., 2020).

3. Cross-chain execution protocol

The execution flow is contract-first. A cross-chain task is received; each involved chain commits its own contract metadata $S_j$6; before the expiration height, each chain repeatedly checks whether the peer chain has also committed the matching contract; if both sides are observed, the actual task transaction is committed; if the task does not complete before timeout, the reverse transaction is committed instead (Liu et al., 2020).

The protocol summarized as Algorithm 2 (Cross Blockchain Contract) checks the validity of $S_j$7, commits $S_j$8, repeatedly queries the peer chain via $S_j$9 before height $(tx_i, tx_j)$0, commits $(tx_i, tx_j)$1 if the other contract is observed, and after expiration inspects whether the peer committed $(tx_i, tx_j)$2 or $(tx_i, tx_j)$3. Timeout handling is specified separately in Algorithm 3: the system enters a lock, removes the contract from the waiting list, checks whether the task was actually committed, and if not, commits the reverse transaction $(tx_i, tx_j)$4 (Liu et al., 2020).

The scheme relies on explicit finality. A block is finalized if more than $(tx_i, tx_j)$5 nodes confirm it and more than $(tx_i, tx_j)$6 blocks follow it. The examples given are PBFT-style finality with $(tx_i, tx_j)$7 and $(tx_i, tx_j)$8, and PoW-style finality with $(tx_i, tx_j)$9 and $(tx_i', tx_j')$0. Once the contract transaction $(tx_i', tx_j')$1 and the follow-up task or reversal transaction are committed under that finality condition, the result becomes permanently attached to the chain’s history (Liu et al., 2020).

A successful cross-chain task requires only a bounded number of request-channel interactions. The reported minimum is at least four cross-chain requests for one successful task. For two honest systems, the protocol commits at most 4 transactions in the success case—$(tx_i', tx_j')$2—and at most 4 transactions in a failure case, for example $(tx_i', tx_j')$3 (Liu et al., 2020).

4. Gossip network, remote views, and consistency

The second major mechanism is the gossip layer. Each blockchain system maintains a view list of other systems’ states. A view $(tx_i', tx_j')$4 stored by $(tx_i', tx_j')$5 about $(tx_i', tx_j')$6 contains recent finalized block hashes, signatures or threshold signatures, and enough information to validate the remote chain’s claimed state. Each system stores the hashes of the latest $(tx_i', tx_j')$7 finalized blocks and a proof of their validity, with local storage cost about

$(tx_i', tx_j')$8

hash values per system (Liu et al., 2020).

The dissemination protocol is mixed push/pull. In push mode, a system broadcasts updated views periodically or after relevant events. In pull mode, if a system receives a partial or incomparable view, it requests the missing information. The intended effect is anchoring: a result committed on one chain is propagated as a view artifact to all other systems without forcing them to re-confirm the entire remote chain from scratch (Liu et al., 2020).

Consistency has two layers. First, the CBC logic enforces completion-or-reversal behavior for honest systems. Second, the gossip network detects inconsistent chain states. If a blockchain forks or exposes contradictory views to different peers, honest systems eventually observe incompatible views and treat that chain as suspicious or Byzantine. The paper’s stated guarantee is that honest systems converge on a consistent view of other honest systems, while forked or malicious branches can be detected and their ongoing contracts canceled or frozen before damage spreads (Liu et al., 2020).

The parameter $(tx_i', tx_j')$9 controls the trade-off between robustness and overhead. Larger $S_i$0 gives more robust view comparison at the cost of more storage and dissemination; smaller $S_i$1 lowers overhead but weakens security. The maximum tolerated gap between a received view and local state is bounded by $S_i$2 (Liu et al., 2020).

5. Scalability model and empirical behavior

The scalability claim is that cross-chain communication cost grows proportionally to the number of cross-chain tasks, not to the total number of chains. Local transactions remain local, and only cross-chain tasks invoke CBC logic and proof queries. Because coordination uses point-to-point request channels and gossip spreads only views and conflict evidence, the design avoids a global consensus bottleneck across all systems (Liu et al., 2020).

The request-channel communication model is explicit. In a permissioned setting, a naive all-to-all request costs

$S_i$3

node-to-node communications for one request. With a designated sender, the minimum can be reduced to $S_i$4. With probabilistic sampling and sufficiently small error probability $S_i$5, the number of confirmations can be reduced under the bound

$S_i$6

This is used to justify randomized evidence collection in permissioned settings (Liu et al., 2020).

The simulation-based evaluation uses 10,000 blocks, block creation speed $S_i$7 s/block, system sizes $S_i$8, cross-chain task rates $S_i$9, and gossip send rates $$ctx_i := H(tx_i)\,||\,H(tx_i')\,||\,h_i\,||\,j\,||\,H(tx_j)\,||\,H(tx_j')\,||\,h_j ,$$0. The authors report that request messages scale linearly with cross-chain task count, with example request counts 4553, 10603, and 28670. Gossip counts are reported as roughly 750:1709:5454 for scale $$ctx_i := H(tx_i)\,||\,H(tx_i')\,||\,h_i\,||\,j\,||\,H(tx_j)\,||\,H(tx_j')\,||\,h_j ,$$1. Increasing gossip rate reduces the gap between local views and true remote state, and increasing cross-chain task rate also reduces the expected gap because it triggers more frequent updates (Liu et al., 2020).

A concrete operating point is also given: with gossip rate around 30% and fewer than 1 cross-chain task per 9 blocks, the expected gap is below 3, and $$ctx_i := H(tx_i)\,||\,H(tx_i')\,||\,h_i\,||\,j\,||\,H(tx_j)\,||\,H(tx_j')\,||\,h_j ,$$2 is suggested as a safe worst-case setting. This suggests that the practical utility of the protocol depends not only on the number of chains, but also on the intensity of cross-chain traffic and the timeliness of gossip dissemination (Liu et al., 2020).

The design is also positioned relative to other interoperability systems. The reported communication/security structures are: Cosmos with 4 hub transactions + 2 internal transactions, security via hub chain; Polkadot with 1 relay chain transaction + 2 internal transactions + 1 proof query, security via relay chain; DeXTT with 2 broadcast transactions + 2 internal transactions, security via veto process; and the chainScale scheme with 2 proof queries + 4 internal transactions, security via gossip network (Liu et al., 2020).

6. Security model, adversaries, and limitations

Two adversary classes are considered. In the first, malicious nodes may hijack request channels or return incorrect responses, but cannot finalize bad blocks. The claim is that such an attacker has negligible probability of preventing honest nodes from receiving correct messages, because honest systems require valid proofs or signatures and the attacker cannot produce enough signatures for a false finalized state. If probabilistic sampling is used, the probability of reaching only corrupted responders is also negligible under the stated combinatorial bound (Liu et al., 2020).

The second class is more severe: one malicious blockchain can finalize bad blocks. The proposed defense is cross-system visibility through gossip. If a chain presents one finalized view to one system and a conflicting view elsewhere, honest systems spread both views, at least one honest system detects the finality violation before expiration, and the cross-chain task can be canceled or frozen. This is the paper’s core interoperability-security claim: malicious chain behavior becomes observable across the network before it silently corrupts other chains’ cross-chain tasks (Liu et al., 2020).

The scheme’s assumptions are strong and delimit its scope. It assumes that each blockchain has finality, that request channels exist between relevant systems, that the gossip network is sufficiently connected, that cross-chain tasks are sparse relative to local tasks, and that expiration heights $$ctx_i := H(tx_i)\,||\,H(tx_i')\,||\,h_i\,||\,j\,||\,H(tx_j)\,||\,H(tx_j')\,||\,h_j ,$$3 and $$ctx_i := H(tx_i)\,||\,H(tx_i')\,||\,h_i\,||\,j\,||\,H(tx_j)\,||\,H(tx_j')\,||\,h_j ,$$4 are properly tuned. The paper is explicit that security depends on timely propagation of view updates; if the gossip layer is weak, attacks become harder to detect. It also states that the protocol does not solve all fork-resolution problems and that conflict resolution after detection is “another topic” (Liu et al., 2020).

A common misconception is that the proposal is a universal replacement for single-chain execution. The stated model is narrower: each blockchain preserves its own local execution and finality rules, while chainScale provides coordination only for tasks that span chains. A plausible implication is that its benefits are most pronounced when cross-chain work is substantially smaller than aggregate local work, because the protocol’s overhead is attached to the cross-chain subset rather than to all transactions (Liu et al., 2020).

7. Other research uses of the label

Outside blockchain interoperability, a separate numerical-analysis usage refers to a method for computing scale functions of a spectrally negative Lévy process by approximating the process with an upwards skip-free continuous-time Markov chain $$ctx_i := H(tx_i)\,||\,H(tx_i')\,||\,h_i\,||\,j\,||\,H(tx_j)\,||\,H(tx_j')\,||\,h_j ,$$5 and evaluating a finite linear recursion. The method produces $$ctx_i := H(tx_i)\,||\,H(tx_i')\,||\,h_i\,||\,j\,||\,H(tx_j)\,||\,H(tx_j')\,||\,h_j ,$$6 and $$ctx_i := H(tx_i)\,||\,H(tx_i')\,||\,h_i\,||\,j\,||\,H(tx_j)\,||\,H(tx_j')\,||\,h_j ,$$7, uses nonnegative coefficients determined by the Lévy triplet, is described as numerically stable, and has computational cost $$ctx_i := H(tx_i)\,||\,H(tx_i')\,||\,h_i\,||\,j\,||\,H(tx_j)\,||\,H(tx_j')\,||\,h_j ,$$8 to obtain $$ctx_i := H(tx_i)\,||\,H(tx_i')\,||\,h_i\,||\,j\,||\,H(tx_j)\,||\,H(tx_j')\,||\,h_j ,$$9 (Mijatović et al., 2013). In that literature, the underlying fluctuation-theoretic machinery is developed explicitly for upwards skip-free Lévy chains, whose scale functions satisfy linear recursions and admit closed forms in special cases (Vidmar, 2013).

A distinct usage appears in language-model scaling. There, “chain-scale” refers to turning model scaling into a nested, chain-based structure through Chain-of-Representation (CoR), Chain-of-Layer (CoL), and Chain-of-Model (CoM), instantiated for Transformers as Chain-of-Language-Model (CoLM) and extended with KV sharing in CoLM-Air (Song et al., 17 May 2025). The design yields multiple sub-models at varying sizes for elastic inference, supports progressive expansion by adding chains, and reports prefill acceleration in long-context inference, including up to 27× speedup with MInference in the reported setting (Song et al., 17 May 2025).

The coexistence of these usages reflects a shared but domain-specific intuition: “chain” denotes an ordered dependency structure, while “scale” denotes either improved scalability or scale-function computation. The substantive mechanisms, however, are unrelated. In blockchain interoperability, chainScale means contract-mediated, gossip-anchored coordination across chains; in Lévy numerics, it denotes lattice recursion for scale functions; in language modeling, it denotes nested causal decomposition of hidden representations (Liu et al., 2020).