The demand for decentralized value exchange solutions has been steadily growing for the last few decades. In that light, blockchain technology has gained momentum as a trustless platform for arbitrary computations. The myriads of consensus protocols, networks, and custom functionalities enable the migration of a wide range of traditional centralized finance into a distributed environment, reducing the impact of a single custodian entity. Nonetheless, the technology has met significant limitations related to scaling. Modern blockchain networks are faced with high transaction latencies, low throughput, and evergrowing storage requirements. Gradual iterative solutions have been proposed to offload computational complexity tied to consensus onto subnetworks or an off-chain extension. Such solutions often come in the form of second-layer structures, such as rollups, or an entirely new approach towards consensus similar to the Ethereum 2.0 multichain system. A tree-based state sharding and load balancing has been proposed in recent studies but is associated with limitations of its own. In the following article we will provide an overview of existing scaling solutions and propose an improvement of tree-based architecture by generalizing the approach to a directed acyclic graph (DAG)-based system. Its structure, security considerations, and communication management between interconnected chains will be laid out, providing a basis for further research in scalability and efficiency in multichain networks.
Traditional financial institutions require both interacting clients to put trust into a third party and its accounting capabilities. The outsourcing of building a compliant asset exchange system simplified security management and integration efforts, while in exchange, a centralized entity keeps a private ledger holding records about each transaction ever processed within the institution and holds responsibility for its consistency and validity.
Unfortunately, there were plenty of historical occasions when such a trusted entity became a reason for financial data leakage or fraudulent activities either because of a coordinated attack against the institution or unintentional changes made by employees. Centralized solutions highly depend on political and social landscape which could endanger trusted assets in critical situations. Hence, the demand for decentralized solutions has been steadily rising for the past few decades.
The most widely adopted technology for decentralized asset exchange is a blockchain network.
Comprised of thousands of participating peers, each responsible for validation and verification of
data consistency, blockchain technology lays foundation for trustless and secure accounting of
occurring transactions [
Nonetheless, the basic Consistency, Availability, and Partition Tolerance (CAP) theorem has its
implication for building such networks [
Most modern consensus protocols in blockchain networks require an agreement by a majority of
participants to either accept or deny a new block [
Significant efforts have been put into research to improve the finalization speed and throughput,
which are mostly centered around the second layer of blockchain systems [
A prominent example of such an approach used in Ethereum is called rollups and helps to
significantly reduce latencies and increase the throughput of the system [
The previously discussed extensions improve these conditions, but to allow horizontal scaling while
keeping strong consistency guarantees, another approach is required using sharding as a core
principle. Such a system is comprised of multiple subnetworks or autonomous networks interacting
with each other through custom consensus or communication protocols [
As of now, Ethereum is one of the most popular networks utilizing such a principle. By leveraging
a Beacon chain and a Proof of Validity mechanism, it allows the distribution of processing of
transactions between multiple subnetworks [
Cosmos Network is another example of an attempt to build a large-scale multichain system and
serves as a communication layer between external networks. In contrast to the Ethereum 2.0
solution, its main goal is to conjoin multiple independent networks rather than build an isolated
multichain system [
Lastly, Avalanche leverages subnetworking and multiple ledgers for division of responsibilities.
C-Chain executes smart contracts, P-Chain manages the lifecycle of subnets, while X-Chain manages
the native assets available on Avalanche. [
Sharding the state of a blockchain in a tree-like structure is an attempt to combine the scalability
properties of the Cosmos network while locally improving security on par with the Ethereum
network. The main purpose of such architecture is to divide traffic both by cohesion and
responsibility zones. The rationale and comparison between existing solutions are provided in their
own dedicated article [
The network is comprised of three main structures: the chain trunk, bough chains, and spring
chains. Here, the chain trunk serves as a root of the network and is a gene-sis point of a multichain
system, its governance, and its coordination. The trunk connects distant leaves and might become
the primary bottleneck in distant communication [
Bough chains are the managing chains responsible for implementing the communication protocol
among its subjected spring chains. A bough chain could potentially manage and validate another
bough chain, enabling growth of the structure. Spring chains are the main computational units to be
used by clients. While it is possible to execute a transaction on a bough chain, it would cost more
and is incentivized against due to scalability considerations [
Figure 1 shows a diagram of the tree-based multichain system architecture:
Here we can clearly see a combination of properties from previously discussed multichain solutions. The tree-based invariant incorporates Proof of Validity similar to one used in Ethereum 2.0 for the bough chain and its child networks. It also promotes distant communication through parents or custom channels similar to Cosmos. The division between governance ledger and clientoriented load is separated akin to the Avalanche approach, resulting in an efficient sharding method.
The tree-based architecture also describes three primary communication modes between its
subnetworks. The primary and most efficient is through the parent bough chain and a Proof of
Validity mechanism. Secondary is a multi-hop transaction passing to non-distant relatives. Lastly,
the architecture allows establishing custom communication bridges between distant chains to avoid
congestions [
The purpose of the article is to improve the limitation tied to the trunk chain in the tree-based
architecture. The overall goal is to develop an architecture based on Directed Acyclic Graphs (DAG)
that aims to improve the scalability and security properties of the proposed model [
When constructing a multichain system model, evaluating its efficiency against existing solutions
is crucial. Therefore, this paper discusses the comparison model as one of its key points. The model
A directed graph is acyclic iff it admits a topological ranking [
A level function (topological ranking):
ℓ: → ℕ = {0,1,2, … }.
This function assigns an integer level to each node such that ( , ) ∈ ⇒ ℓ( ) < ℓ( ). Then, for each ∈ ℕ, define : = { ∈ : ℓ( ) = } as a set of assigned levels for each node. ℓ can be chosen to be strict (no equal levels along any edge) since we topologically require ℓ( ) < ℓ( ). • • • • • • = ( , ℎ) is a forest of arborescences (disjoint union of rooted out-trees), with (possibly multiple) roots .
No node has two different backbone parents. includes parameters representing security and scalability properties and evaluates them based on the previous iteration, a recently suggested enhancement, and a collection of pre-existing networks.
The architecture is a finite, simple, directed graph = ( , ) [
Simplicity: no self-loops ( , ) ∉ and no multi-edges (because edges are elements of a set of ordered pairs).
Acyclicity: there is no directed cycle (no sequence 0 → 1 → ⋯ → = 0 with ≥ 1). ℓ (tie(1) (2) (3) (4) (5) breaking) without changing reachability.
We partition edges into backbone vs cross edges.
edges.
For every ∈ : = ℎ ∪̇ ,
ℎ ∩ = ∅, −ℎ( ) ≤ 1, where ∪̇ disjoint union, ∅ is the empty set, ℎ is a set of backbone edges, and is a set of cross where −ℎ( ): = |{ ∈ : ( , ) ∈ ℎ}|.
Consequences: For every ( , ) ∈ :
ℓ( ) < ℓ( ) ⋏ ( , ) ∉ ℎ.
Cross edges preserve acyclicity and cannot duplicate a backbone edge. They may skip levels arbitrarily (as long as ℓ( ) < ℓ( )). The level function organizes edges by levels: ℎ ⊆ ⋃ × +1 ∈ℕ Backbone edges move exactly one level down:
Root node: ∈ ⟺ −ℎ( ) = 0; Bough node: +ℎ( ) ≥ 1;
Spring node (leaf): +ℎ( ) = 0.
Roles are derived, not labelled: they depend only on degrees in ℎ. Multiple roots are allowed (no (7)
A quadruple ( , ℎ, , ℓ) defines a valid DAG-multichain architecture iff all of the following hold:
⋃ ∈ℕ × +1 ⋏ ⊆ ⋃ < × .
Here, (1) (4) are the essential structural rules and (5) is a convenient normalization matching
A Governance Structure is a shared security mechanism initially introduced for the tree-based
architecture. Within DAG-based architecture it could be represented as a subgraph of the multichain
backbone [
= ( , ), By default, consists of all immediate parent child pairs: ( ) = parent function, defined as ( ) ∈ ∪ ∅. ( ) = ∅ iff is a root.
= {( , ( )) ∣ ∈ , ( ) ≠ ∅},
A Governance Structure is essentially the restriction of the backbone forest to a consecutive chain (or small hierarchy) of boughs. It captures their hierarchical organization. There could be many Governance Structures within a multichain system.
A United Governance Structure is a higher-order governance subgraph [
= ( , ), ⊆ is a subset of participating bough chains that agreed to extend governance through the consensus process. shared security. ⊆ × is the set of agreed governance relations among them with an established • • • • • • where: where: Formally: ⊆ is the subset of bough nodes (blockchain networks) participating in this governance structure. default direct control. ⊆ ℎ is the set of parent-child edges between consecutive boughs inside representing (8) (9) (10) (11)
If ( , ) ∈ and ( , ) ∈ , then ( , ) ∈ . Unlike , which is local and hierarchical, allows extended coordination: validator rotation, policy alignment, and inter-chain communication. For simplicity we did not index in the definition, but it should be clear that there could be multiple as well as in a multichain system.
The purpose of a United Governance Structure is to expand shared security principle farther than a direct parent to child relation. Withing such a structure there is a pool of shared and rotated validators to reduce the likelihood of 51% attacks. Such a structure does not scale horizontally since the assignment of validators requires general consensus, hence there could be many disjoined structures throughout the multichain system.
A large-scale multichain system could have numerous blockchain networks interconnected within a global network. Addressing a single chain in such a scenario could pose a problem when relying on unstructured unique names. A directory service would be required either on-chain or off-chain to manage requests routing.
Maintaining such a directory could have its limitations due to update propagation and bottlenecks. Hence, within a discussed architecture, we propose to utilize a structured and routable naming system for individual chains, similar to DNS.
Figure 3 shows a diagram of the DNS-like routing system within the multichain architecture:
In a classical DNS system, there are multiple levels of servers, including root domain servers,
toplevel servers, and authoritative servers [
An advantage in contrast to some centralized directory service is apparent from the perspective of distant networks. When a client from spring chain A tries to create a transaction involving assets on spring chain B, all that chain A has to know is the root chain address, which then points to its authoritative record, allowing for recursive traversal of the graph.
Now a similar problem happening with unstructured names could happen if there are many root
chains dynamically created or updated. In such cases the role of a root DNS server could be allocated
to a single off-chain directory service or a separate blockchain network. Since the cardinality of the
root-level chain should not be significant, the capabilities of a single blockchain network would be
enough for such a purpose.
Message Verification (MV),
NIST SP 800-30 [
Shared Security (SS), every domain fully secluded (1); shared security in specific clusters (2); shared security for most, not all, cross-chain traffic (3); shared security covers >90% of inter-chain transactions (4); all interchain operations are validated through a shared pool (5).
Pooled validators set raise economic security and reduce the probability of 51% attacks since it would require an infeasible amount of computational and voting power for an attacker to influence the consensus process. Validators rotation is essential to ensure that there could not be organized pooling of consensus votes.
Coordinator Centralization (CC), network (1); major coordination network with multiple subordinate chains (3); multiple dominant chains with a balanced workload (3); the multichain is distributed with local coordinators but without global (4); distributed architecture without reliance on coordination hubs (5).
Security assessment includes multiple categories discretely scored following ISO/IEC 27005
riskassessment practice [
Trust introduces potential attack vectors, the less trust is put into cross-ledger transaction the better (e.g. verifiable proof are preferred). External actors could get compromised which diminishes decentralized security principles. Global coordination chains are potential single points of failure.
Data Retention & Redundancy (DR), could be pruned (1); periodic roots for short history (2); moderate historical checkpoints (3); strong redundancy and proofs (4); explicit retention with configurable depth (5).
Blast Radius / Containment (BR) compromise propagates globally (1); spillover limited to hub cluster (2); spillover limited to a governance group (3); spillover limited to parent-child only (4); compromise fully contained (5).
To combine the previously discussed scores, we use a weighted geometric mean [
So the final formula looks as follows:
= ( 3 ⋅ 3 ⋅ 2 ⋅ 1 ⋅ 2)111.
Within this scoring model, higher means more secure. Poor dimensions drag down the score (no averaging-away weaknesses). To normalize the score and use it later for cumulative assessment model, we use: ∗ =
/5.
assessment of the architecture. The performance metrics are calculative in relative perspective to compared networks.
Latency utility ∗ shows relative performance of an architecture. It compares latencies with respect to the fastest available ∗ = / , where is the lowest latency observed within assessed multichain systems. ̅ is an average latency associated with an inter-chain transaction within target architecture. Latencies here include routing, consensus/finality delay, periodic proof interval, and queueing.
Throughput utility ∗ measures relative ability of cross-chain message processing per second and defined as ∗ = μ/μ , where μ is the cross-chain throughput capacity of the architecture and μ is the highest capacity among the compared set. If the throughput is unlimited within a multichain system, its total score is ∗ = 1.5.
Const utility ∗ shows the cost associated with an inter-chain transaction. The following formula is used: ∗ = / ̅, where is the lowest cost observed within assessed multichain system and ̅is the average cost of a target architecture. Since cost could fluctuate due to economic reasons, we assume the cost as an amount of records required on multiple ledgers to perform an asset transfer. If there is no additional cost, then ∗ = 1.5.
Each cross-chain operation requires proof so that participants from different ledgers could verify the validity of the state. Data availability ∗ shows extra bytes related to the construction of such proofs ∗ = / , where is the overhead within a target system and is the minimal overhead among tested systems. If there is no overhead, then ∗ = 1.5.
Within a cumulative assessment model, we include 5 dimensions discussed previously: = ∗ + ∗ + ∗ + ∗ + ∗ , where, the weights are summing to 1 with = 0.2, = 0.3, = 0.1, Therefore, the formula is as follows:
= 0.2 ⋅ ∗ + 0.3 ⋅ ∗ + 0.1 ⋅ ∗ + 0.1 ⋅ Here, the higher the value the better.
It is possible to get score larger than 1 due to metrics such as ∗ = 1.5.
3.2. Ethereum 2.0
Latency in Ethereum 2.0 could be represented ̅ ℎ 2.0 ≈ 984 seconds, which describes a
finalized assets transfer between shards [
Moving on to the throughput μ, each shard should post a commitment to a beacon chain per
epoch, where an epoch is roughly 384 seconds [
Cost ̅as a count of records per cross-chain transaction could be expressed as follows: a record
on chain A for the transaction, a record on chain A for the proof object, a record for commitment on
the beacon chain shared in a batch, a record on chain B for the transaction and one for proof
verification [
Data overhead ℎ 2.0 ≈ 544 bytes for a Merkle proof with a depth of 16 [
Normalized Security Score:
= (53 ⋅ 13 ⋅ 42 ⋅ 31 ⋅ 32)111 ≈ 2.69.
∗
=
Latency ̅ ≈ 12 second to finalize a transaction which includes sending it for validation to
the relay chain and inclusion into the destination ledger [
Throughput μ ≈ 2000
ability to validate transactions depending on allocated cores and including limitations on messages
to parachains [
Cost ̅ ≈ 5 includes the original transaction and XCMP message on chain A, entry on the
relay chain, and respective transaction and XCMP receipt on chain B [
Data overhead ≈ 1536 bytes for three XCMP entries on chain A, relay, and B
respectively [
Security Score:
Shared Security (SS = 5) shared validation pool coordinated through a relay chain [
Message Verification (MV=4) XCMP/XCM with verification of proof from the relay chain
[
Data Retention & Redundancy (DR = 3) relay finality and checkpoints for data verification
[
Blast Radius / Containment (BR = 3) parachain faults are isolated but relay faults could
propagate [
Shared Security (SS = 5) shared validation pool coordinated through a beacon chain [
Message Verification (MV=4) on-chain verification of roots received from the beacon chain
[
Data Retention & Redundancy (DR = 2) the beacon stores periodic roots for data verification
but does not support data restoration [
Blast Radius / Containment (BR = 4) security breaches are isolated to a child chain but
potential major issues could happen if the beacon itself gets compromised [
Composite Security Score:
ℎ Normalized Security Score: (16) (17) (18) (19)
Latency ̅ ≈ 30 seconds to finalize a transaction which includes request commitment on chain
A, its transfer to the hub, and later to the chain B [
Since Cosmos is a distributed system without an apparent limitation in scale, its throughput final
estimation ∗ = 1.5 [
Cost ̅ ≈ 8 in case if we consider a single hub hop. Each hop would include commitment
and deletion records on the source and receipt and acknowledgement records on the destination [
Data overhead ≈ 192 bytes the commitment and acknowledgement records [
Security Score: • • • • •
Shared Security (SS = 1) connects uncoordinated ledgers, does not ensure shared security
[
Coordinator Centralization (CC = 4) does not enforce centralized topology, multiple hubs
could be used for connecting ledgers [
Message Verification (MV=4) on-chain light clients verify headers and proofs with
minimized trust [
Data Retention & Redundancy (DR = 2) light clients windowing and pruning are typical,
proof is isolated to a short context [
Blast Radius / Containment (BR = 5) security breach on one chain does not propagate to
another since Cosmos serves as a communication media rather than a shared security
coordinator [
Normalized Security Score: = (13 ⋅ 43 ⋅ 42 ⋅ 21 ⋅ 52)111 ≈ 2.68. ∗ =
Latency ̅ ℎ ≈ 4 seconds to finalize a transaction which includes commitment to chain A, its
transfer through the teleporter, and later to the chain B [
Avalanche is a highly distributed system without an apparent limitation in scale of transaction
processing. Though it could have unlimited number of subnetworks, the primary chain is responsible
for recording the assignments of validators which could become a bottleneck. Its throughput final
estimation ∗ ℎ = 1 [
Cost ̅ ℎ ≈ 2 in case if we consider AWM/Teleporter. One record for the request is written
on chain A and another for the import on the chain B [
Data overhead ℎ ≈ 512 bytes where each side writes a normal transaction that carries
an AWM proof including the message, BLS aggregate signature, and the metadata [
The apparent performance of the Avalanche network stems from its internal organization and reliance on a few coordinating networks. In contrast to completely disjointed systems such as Cosmos, Avalanche requires each subnetwork to register and manage its validators through the main chain. This cohesion allows boosting performance but at the cost of a potential blast in case of the main chain compromise. Composite Security Score:
Normalized Security Score: •
Shared Security (SS = 4) centralized pooling in place with subnets including validators from
the primary chain [
Coordinator Centralization (CC = 2) shared security coordination network [
Blast Radius / Containment (BR = 4) faults are typically isolated to a subnetwork [
Latency could vary greatly depending on the communication path. It could be either with the siblings
or to the distant nodes. Since the design of architecture assumes high cohesion, the most frequent
method of communication should be done through the bough chain where latency should be similar
to Ethereum 2.0. ̅ − ≈ 984 seconds to finalize a transaction which includes sending it for
validation to the relay chain and inclusion into the destination ledger [
The tree-based architecture in its essence as a data structure does not strictly impose the
communication mode between siblings, but the original article assumed coordination like Ethereum
2.0 between siblings. Since the Trunk chain underpins the entire system μ − ≈ 6720
transactions per second [
Cost ̅ − = 4 similar to estimation for Ethereum 2.0 but could grow significantly larger
for distant-node communication [
Data overhead − = 544 bytes for coordination through the bough chain between
siblings [
Security Score:
Shared Security (SS = 2) shared security within boughs and its direct child network. Coordinator Centralization (CC = 2) has a major coordination network (The Tree Trunk). Message Verification (MV=4) trust minimized cryptographic proofs for most operations. Data Retention & Redundancy (DR = 5) explicit and configurable N-ancestor data retention. Blast Radius / Containment (BR = 3) faults are typically isolated to a subnetwork but could propagate if happen on local coordination networks.
Composite Security Score:
− Normalized Security Score: = (23 ⋅ 23 ⋅ 42 ⋅ 51 ⋅ 32)111 ≈ 2.65.
(24) 2.65 (25) ∗ − = 5 ≈ 0.53.
The purpose of the Tree-based architecture was to improve the horizontal scalability capabilities of multichain systems.
In contrast to the tree-based, the newly proposed DAG-based architecture assumes communication expected to be the dominant way due to cohesion principles, the estimated latency ̅ − = 12 second to finalize a transaction which includes sending it for validation to the relay chain and inclusion into the destination.
Throughput in such an architecture is not limited to the trunk chain or any other general coordination network, making its final estimation ∗ − = 1.5. There could be many root chains connecting different branches. Moreover, cross-connection facilitates efficient transactions.
Cost ̅ − = 5 similar to Polkadot and includes the original transaction and XCMP
message on chain A, entry on the relay chain, and respective transaction and XCMP receipt on chain
B [
Data overhead between sibling chains is similar to the Polkadot, − = 1536 bytes for
three XCMP entries on chain A, relay, and B respectively [
Security Score: •
Shared Security (SS = 3) shared security within boughs and its direct child network with additional governance structures that could be shared.
Coordinator Centralization (CC = 4) no global coordination network.
Message Verification (MV=4) trust minimized cryptographic proofs for most operations. Data Retention & Redundancy (DR = 5) explicit and configurable N-ancestor data retention. Blast Radius / Containment (BR = 3) faults are typically isolated to a subnetwork but could propagate if happen on local coordination networks. (26) (27) Composite Security Score:
− Normalized Security Score:
= (33 ⋅ 43 ⋅ 42 ⋅ 51 ⋅ 32)111 ≈ 3.58. ∗ − =
The results obtained in the previous subsections could be organized in a table for a more convenient comparison.
From the results we can see the improvement within DAG-based architecture over the tree-based.
The increasing growth in traffic related to decentralized operations has led to a surge in research on scalable multichain systems. Novel consensus protocols and inter-chain protocols are being developed to allow the sustainable growth of distributed and decentralized computations. In this based multichain system by generalizing it to a DAG-based system.
A new coordination hierarchy has been discussed, showcasing previous consensus constraints and their mitigation. The DAG-based approach allowed us to avoid a single bottleneck tied to the trunk chain of the system. In contrast to the tree-based architecture, multiple authoritative connection points could be established, allowing for parallelized request flow.
Additionally, the DAG-based approach allows for improving the security properties of the system by enabling multiple higher-level validations of transactions. The intersection of security boundaries allows spreading the validation responsibility to participants in multiple networks, which improves the security guarantees.
Overall, the purpose of this article is to improve a previously developed tree-based architecture by leveraging the properties of a DAG. A comparison between the proposed architecture and existing systems has been provided, showing its relevance. The research aims to spark further interest in building scalable and secure systems.
The authors have not employed any Generative AI tools.
The authors would like to thank colleagues and reviewers for their valuable comments and suggestions, which helped improve the quality of this work. No external funding was received for this research.