Banaeian2025ThirdLayer Third layer blockchains are being rapidly developed- Addressing state-of-the-art paradigms and future horizons

Prévia do material em texto

Journal of Network and Computer Applications 233 (2025) 104044 
A
1
Contents lists available at ScienceDirect
Journal of Network and Computer Applications
journal homepage: www.elsevier.com/locate/jnca
Third layer blockchains are being rapidly developed: Addressing
state-of-the-art paradigms and future horizons
Saeed Banaeian Far, Seyed Mojtaba Hosseini Bamakan ∗
Department of Management Sciences, Yazd University, Yazd, 89195-741, Iran
A R T I C L E I N F O
Keywords:
Chainlink
Fantom sonic
Interoperability
Scalability
Universal deFi
A B S T R A C T
Undoubtedly, blockchain technology has emerged as one of the most fascinating advancements in recent
decades. Its rapid development has attracted a diverse range of experts from various fields. Over the past five
years, numerous blockchains have been launched, hosting a multitude of applications with varying objectives.
However, a key limitation of blockchain-based services and applications is their isolation within their respective
host blockchains, preventing them from recording or accessing data from other blockchains. This limitation
has spurred developers to explore solutions for connecting different blockchains without relying on centralized
intermediaries. This new wave of projects, officially called Layer 3 projects (L3) initiatives, has introduced
innovative concepts like cross-chain transactions, multi-chain frameworks, hyper-chains, and more. This study
provides an overview of these significant concepts and L3 projects while categorizing them into interoperability
and scalability solutions. We then discuss opportunities, challenges, and future horizons of L3 solutions and
present a SWOT (Strengths–Weaknesses–Opportunities–Threats) analysis of the two groups of L3 solutions
and all other proposals. As an important part, we introduce the concept of Universal decentralized finance
(DeFi) as one the most exciting applications of L3s which decreases transaction costs, enhances the security
of crowdfunding, and provides many improvements in distributed lending-borrowing processes. The final part
of this study maps the blockchain’s triangle problem on L3s and identifies current challenges from the L3’s
perspective. Ultimately, the future directions of L3 for both academic and industry sectors are discussed.
Contents
1. Introduction ...................................................................................................................................................................................................... 2
1.1. Contribution .......................................................................................................................................................................................... 3
1.2. Survey methodology and references filtering............................................................................................................................................. 4
1.3. Organization .......................................................................................................................................................................................... 4
2. Preliminaries ..................................................................................................................................................................................................... 4
2.1. Blockchain ............................................................................................................................................................................................. 4
2.1.1. Consensus................................................................................................................................................................................ 4
2.1.2. State machine and smart contract .............................................................................................................................................. 5
2.1.3. DApp ...................................................................................................................................................................................... 6
2.1.4. Layers ..................................................................................................................................................................................... 7
2.2. Zero knowledge...................................................................................................................................................................................... 8
2.2.1. Generic ZKP............................................................................................................................................................................. 8
2.2.2. zk-SNARK................................................................................................................................................................................ 8
2.2.3. zk-STARK ................................................................................................................................................................................ 9
2.3. On-chain and off-chain transactions ......................................................................................................................................................... 9
2.3.1. Lightning network .................................................................................................................................................................... 9
2.3.2. Rollup ..................................................................................................................................................................................... 9
2.3.3. zk-rollups ................................................................................................................................................................................ 9
3. Interoperability.................................................................................................................................................................................................. 10
3.1. Cross-chain ............................................................................................................................................................................................ 10
∗ Corresponding author.
E-mail addresses: saeed.banaeian.far@gmail.com (S. Banaeian Far), smhosseini@yazd.ac.ir (S.M. Hosseini Bamakan).
https://doi.org/10.1016/j.jnca.2024.104044
Received 25 July 2024; Received in revised form 15 September 2024; Accepted 20 October 2024
vailable online 28 October 2024 
084-8045/© 2024 Elsevier Ltd. All rights are reserved, including those for text and data mining, AI training, and similar technologies. 
https://www.elsevier.com/locate/jnca
https://www.elsevier.com/locate/jnca
mailto:saeed.banaeian.far@gmail.com
mailto:smhosseini@yazd.ac.ir
https://doi.org/10.1016/j.jnca.2024.104044
https://doi.org/10.1016/j.jnca.2024.104044
http://crossmark.crossref.org/dialog/?doi=10.1016/j.jnca.2024.104044&domain=pdf
S. Banaeian Far and S.M. Hosseini Bamakan
b
i
w
I
o
L
e
t
a
A
a
W
i
w
c
o
a
Journal of Network and Computer Applications 233 (2025) 104044 
3.1.1. CCIP ....................................................................................................................................................................................... 10
3.1.2. Sonic....................................................................................................................................................................................... 10
3.2. Multi-chain ............................................................................................................................................................................................ 12
3.3. Omni chain............................................................................................................................................................................................challenges, including fragmented
liquidity, limited composability, and potential conflicts in achieving
global state consistency. Moreover, deploying DApps across multiple
chains introduces additional friction (Rosa and Rothenberg, 2018; Tang
et al., 2021; Wu et al., 2021). However, it does mitigate the impact of
vulnerabilities associated with bridging mechanisms. An example of a
multi-chain project is Uniswap, which has been deployed on multiple
blockchains.
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Fig. 5. An overview of scalability solutions using L3 blockchains.
3.3. Omni chain
A blockchain architecture that integrates multiple blockchains into
a single cohesive system, providing unified access and functionality
across all integrated networks. This creates a world where seamless
communication among all blockchains is a reality This vision is em-
bodied by the concept of ‘Omni’ (derived from the Latin word for ‘‘all’’
or ‘‘every’’), which is brought to life through LayerZero’s23 innovative
omni-chain framework. Serving as a common language for blockchains,
this pioneering project empowers true cross-chain functionality and
delivers on the promise of effective interoperability. Notably, LayerZero
stands as a leading L3 protocol that spearheads the development of
omni-chain interoperability, catering to the needs of developers in the
blockchain ecosystem.
4. Scalability
With the popularity of blockchain technology and the growth of its
users, scalability (vertical and horizontal) is considered one of the main
23 https://layerzero.network/.
13 
challenges in addition to interoperability solutions (Imani Rad and
Far, 2023; Nasir et al., 2022). This section introduces several exciting
solutions proposed by great blockchain-leader companies. Fig. 5 shows
the relations of L3 solutions for blockchain scalability; Tables 12 and 16
compare (1) Scalability platforms and (2) Hyperchain and Superchain
interoperability platforms and address a distinguished feature for each
project.
4.1. App-chain
App-chain is a blockchain designed specifically for a single ap-
plication or a suite of related applications, optimized to meet the
specific needs and requirements of those applications. In fact, App-
chain refers to a blockchain designed and optimized specifically for
a particular application or protocol, going beyond the customization
offered by DApps (Far et al., 2023b). This specialization grants app-
chains a significant advantage when it comes to tailoring a blockchain
to accommodate unique features and mechanisms required for optimal
functionality. While launching an app-chain may not be inherently
challenging, it is a delicate undertaking that demands the highest level
of efficiency in all aspects to ensure the seamless operation of the
associated DApp.
https://layerzero.network/
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Fig. 6. An overview of the Polkadot ecosystem workflow.
4.2. Para-chain
A para-chain is a blockchain that runs parallel to a primary net-
work, often within frameworks like Polkadot. It shares security and
interoperability with the main network while maintaining its own
unique state and operations. Derived from the Greek word ‘‘para’’,
meaning ‘‘alongside’’, a para-chain relies on the security of a cen-
tral relay chain rather than having its own independent consensus
mechanism. In this context, the term ‘‘para’’ emphasizes the idea that
each blockchain operates in conjunction with the central relay chain
rather than autonomously (Gavin, 2016; Solat and Nait-Abdesselam,
2023; Dubey et al., 2024). This concept is predominantly associated
with networks like Polkadot and Kusama,24 wherein multiple para-
chains operate in parallel. In the case of Polkadot, all para-chains run
alongside each other and are connected to the central Polkadot relay
chain. The primary advantage of the para-chain model is the ability
to facilitate simultaneous operation and interoperability of multiple
blockchains with different capabilities and use cases within a shared
network. Regarding Fig. 6,25 in the following, the detailed workflow
of the Polkadot and Kusama networks are described as two popular L3
examples of para-chain solutions for the scalability problem (Li et al.,
2022). Additionally, Table 10 shows a comparison between the two
para-chains mentioned above (Polkadot and Kusama).
24 https://guide.kusama.network/docs/kusama-getting-started/.
25 Source of Fig. 6: https://cryptoseq.medium.com/polkadot-an-early-in-
depth-analysis-part-two-how-consensus-works-1b2b2f3a2245.
14 
4.2.1. Polkadot
The Polkadot ecosystem is a multi-chain blockchain platform de-
signed to facilitate a heterogeneous, scalable, and interoperable net-
work of blockchains. Developed by the Web3 Foundation26 and spear-
headed by Dr. Gavin Wood, co-founder of Ethereum, Polkadot aims
to address several of the critical limitations of existing blockchain
networks, such as scalability, interoperability, and governance. The
ecosystem is structured around a unique multi-chain architecture that
connects various blockchains into a unified network, enabling them to
communicate and share security. As illustrated in Fig. 6, the Polkadot
ecosystem involves six main entities which are now defined in the
following.
• Relay Chain: The Relay Chain is the central chain of the Polkadot
network, responsible for the network’s security, consensus, and
cross-chain interoperability. It is designed to be minimalistic,
handling only the essential functions like transaction finality,
consensus mechanism, and interoperability. The Relay Chain does
not support smart contracts directly; instead, it facilitates the
coordination and communication between various Parachains and
parathreads.
The Relay Chain is the heart of the Polkadot ecosystem. It pro-
vides the base layer of security, consensus, and cross-chain in-
teroperability for the network. It uses a nominated proof-of-stake
(NPoS) consensus algorithm, where validators are nominated by
DOT holders (the native token of Polkadot). The Relay Chain’s
26 https://gavwood.com/.
https://guide.kusama.network/docs/kusama-getting-started/
https://cryptoseq.medium.com/polkadot-an-early-in-depth-analysis-part-two-how-consensus-works-1b2b2f3a2245
https://cryptoseq.medium.com/polkadot-an-early-in-depth-analysis-part-two-how-consensus-works-1b2b2f3a2245
https://gavwood.com/
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Table 10
A comparison between Polkadot and Kusama.
Polkadot Kusama
Applications
Implementation of B2B apps slower upgrades Testnet for early stage apps
DeFi applications requiring high security Applications for lass-risk apps
Apps involving stability and robustness Testing and deployment platform for Polkadot apps
Benefits
Conventional and methodical governance Faster and update governance
Slower upgrades Faster upgrades
More focus on security and stability Fewer hurdles and easier para-chain deployment
Implementation of risk-free apps Suitable for experimentation and early testing
More conservative Low band requirements for validators and para-chains
High rewards for validators Latest technology
Use cases
Enterprise and B2B applications Early-stage start-up network
Financial applications Experimentation on new ideas
High-value applications requiring bank-like security, stability and robustness Apps that do not yet require bank-like security and robustness
Upgrade path for early-stage apps Pre-production environment for Polkadot
d
design is intentionally minimalistic to maximize efficiency, focus-
ing solely on key functionalities such as securing the network,
coordinating validators, and enabling cross-chain communication.
• Parachains: Parachains (parallelized chains) are individual
blockchains that run parallel to the Relay Chain within the
Polkadot ecosystem. Each parachain can be tailored to aspecific
use case or function, benefiting from Polkadot’s shared security
and interoperability. Parachains are secured by the Relay Chain
validators and can communicate with each other through the
Polkadot network’s cross-chain message passing (XCMP) protocol.
A parachain is an independent blockchain that runs in parallel
within the Polkadot network. Parachains benefit from the shared
security of the Relay Chain and can interoperate with other
parachains through Polkadot’s cross-chain messaging protocols.
Parachains are optimized for specific use cases, such as DeFi,
identity verification, or supply chain tracking. They lease slots on
the Relay Chain via an auction process, ensuring only high-value
projects utilize the network’s resources.
• Parathreads: Parathreads are similar to parachains but operate on
a pay-as-you-go model. This means they do not require a contin-
uous slot on the Relay Chain, making them more economical for
blockchains that do not need constant availability. Parathreads
share slots with other parathreads in a pooled arrangement, al-
lowing them to participate in the network as needed, rather than
continuously.
A parathread is a more flexible, pay-as-you-go variant of a
parachain. Parathreads do not require a dedicated slot on the
Relay Chain, making them ideal for projects that need sporadic
access to the network. They participate in a pooled scheduling
system, where multiple parathreads share a limited number of
execution slots. This model allows for cost-effective and scalable
participation in the Polkadot ecosystem without the long-term
commitment of a full parachain slot.
• Parathread Pool: The Parathread Pool is a mechanism within the
Polkadot network that manages the availability and scheduling of
parathreads. Since parathreads do not have dedicated slots on the
Relay Chain, the parathread pool ensures that these parathreads
can be scheduled and executed efficiently when they need to
produce a block. The pool operates on a dynamic basis, allow-
ing parathreads to participate based on their demand and the
availability of network resources.
The Parathread Pool manages the execution and scheduling of
parathreads. Since parathreads operate on a pay-as-you-go basis,
the parathread pool coordinates which parathread gets access to
a slot at any given time. The pool ensures efficient utilization
of network resources, allowing multiple parathreads to execute
15 
based on demand and availability. This dynamic scheduling is
crucial for maintaining the flexibility and cost-efficiency of the
parathread model.
• Validators: Validators are nodes that secure the Polkadot network
by participating in the consensus process on the Relay Chain.
They validate proofs from collators (parachain nodes), partici-
pate in consensus mechanisms (like Nominated Proof-of-Stake, or
NPoS), and produce new blocks for the Relay Chain. Validators
also play a critical role in maintaining the shared security model
of Polkadot by validating the state transitions of all parachains.
Validators are crucial for securing the Polkadot network. They
perform several functions including Validating Blocks (valida-
tors verify the correctness of blocks produced by collators for
parachains), Participating in Consensus (they engage in the NPoS
consensus process to propose and agree on new blocks for the
Relay Chain), Security validators ensure the integrity and security
of the entire network by validating the state transitions of all
connected parachains, and Stake Bonding (they must stake a sig-
nificant amount of DOT tokens, incentivizing honest and reliable
behavior under the threat of economic penalties (slashing) for
malicious actions).
• Collators: Collators are full nodes of parachains that collect trans-
actions from users and produce block candidates for validators to
verify. They maintain a full node of both the parachain and the
Relay Chain, allowing them to collate transactions into parachain
blocks and submit these blocks to Relay Chain validators. Colla-
tors play a vital role in ensuring that parachains remain opera-
tional and synchronized with the Relay Chain.
Collators are essential to the operation of parachains. They main-
tain the full state of both the parachain and the Relay Chain,
gather transactions from parachain users, and produce block can-
didates. These block candidates are then submitted to valida-
tors on the Relay Chain for verification. Collators ensure the
parachain’s transactions are valid and correctly ordered, facilitat-
ing the smooth operation and integration of parachains within the
Polkadot network.
4.2.2. Kusama
Kusama is an experimental, pre-production environment for Polka-
ot, designed to serve as a testing ground for new technologies, gover-
nance models, and features before they are deployed on the Polkadot
network. Launched by the Web3 Foundation (Dr. Gavin Wood), Kusama
mirrors the structure and functionalities of Polkadot, providing a live,
operational environment where developers can experiment and iterate
quickly.
All in all, the Kusama ecosystem and entities roles are very similar to
the Polkadot; however, there are several deep similarities, differences,
and relations between them listed in the following.
S. Banaeian Far and S.M. Hosseini Bamakan
b
v
P
c
t
t
Z
k
S
c
i
c
b
P
f
w
R
r
a
t
T
w
f
Journal of Network and Computer Applications 233 (2025) 104044 
• Similarities: (1) Architecture: Both Kusama and Polkadot share a
multi-chain architecture consisting of a Relay Chain, parachains,
parathreads, validators, and collators. This architecture enables
scalability, interoperability, and shared security across connected
blockchains, (2) Consensus Mechanism: Both networks utilize a
NPoS consensus mechanism, where validators are nominated by
token holders (KSM for Kusama and DOT for Polkadot) to secure
the network and validate transactions, (3) Interoperability: Both
platforms facilitate cross-chain communication and interoperabil-
ity through the XCMP protocol, enabling seamless interaction
between different parachains and parathreads, and (4) Gover-
nance: Kusama and Polkadot employ on-chain governance mech-
anisms that allow token holders to propose and vote on network
upgrades, changes, and improvements. This decentralized gover-
nance model ensures community involvement in decision-making
processes.
• Differences: (1) Purpose and Use Case, (2) Speed and Risk, (3)
Token Economics, and (4) Community and Projects.
• Relations: As clarified recently, Kusama and Polkadot ecosystems
are very similar. Hence, there are three main relations between
their teams, goals and policies: (1) Interconnected Ecosystem:
Kusama and Polkadot are closely related, with Kusama acting as a
testing ground for Polkadot. Successful experiments and features
on Kusama can be ported to Polkadot after proving their viability
and security, (2) Development Pipeline: Developers often deploy
and refine their projects on Kusama first, taking advantage of
its faster-paced environment to iterate quickly. Once a project is
stable and mature, it can transition to Polkadot for long-term de-
ployment, and (3) Shared Vision: Both networks are developed by
the Web3 Foundation and share the same overarching vision of a
decentralized, interoperable, and scalable multi-chain ecosystem.
They are integral parts of the broader Web3 ecosystem, work-
ing together to drive innovation and adoption of decentralized
technologies.
Kusama and Polkadot represent a dual-network strategy aimed at
alancing rapid innovation with stability and security. Kusama pro-
ides a dynamic environment for testing and experimentation, while
olkadot offers a robust platform for deploying production-grade appli-
ations. Together, they form a comprehensive ecosystem that supports
he development and adoption of decentralized technologies, driving
he evolution of the blockchain space.
4.3. Side-chain
A side-chain is an autonomous blockchain connected to a main
blockchain (mainnet) through a two-way peg, allowing for thetransfer
of assets between the main blockchain and the side-chain. This connec-
tion facilitates scalability and experimentation by enabling the transfer
of tokens or digital assets between the two blockchains (Aggelos and
indros, 2020; Sunny and Nadal, 2012; Uriarte and DeNicola, 2018).
They present a promising solution to address the scalability challenges
faced by blockchains. Side-chains have the capability to run DApps
and alleviate the computational burden on the main chain (Peilin
et al., 2023). These chains operate with their own tokens, protocols,
consensus mechanisms, and security measures. Notably, several well-
nown projects, including Polygon,27 Loom Network,28 Gnosis,29 and
kale,30 provide mechanisms for establishing connections with side-
hains, further expanding the possibilities for blockchain scalability and
nteroperability.
27 https://docs.polygon.technology/.
28 https://loomx.io/developers/en/intro-to-loom.html and https://github.
om/loomnetwork.
29 https://docs.gnosischain.com/.
30 https://docs.skale.network/.
16 
In the following, a comprehensive description of each four side-
chain-based L2 solutions is provided. Ultimately,Table 11 presents a
comparison between these networks.
4.3.1. Polygon
As a leader and the most famous L2 solution for blockchain scala-
ility, the Polygon network31 (formerly known as Matic Network) is a
framework for building and connecting Ethereum-compatible
blockchain networks. It aims to create a scalable, interoperable, and
secure multi-chain ecosystem of blockchains, akin to an Internet of
Blockchains. In a technical word, Polygon is a L2 scaling solution for
Ethereum, designed to improve transaction speed and reduce costs
by utilizing sidechains for off-chain computation while retaining se-
curity through the Ethereum mainnet. It provides the infrastructure
for creating and managing blockchain networks that are capable of
interconnecting in a way that enhances scalability without sacrificing
security or decentralization. The main goal of Polygon is to address
Ethereum’s scalability issues by providing a framework for building and
connecting L2 chains, sidechains, and other infrastructures, thus en-
abling faster and cheaper transactions while maintaining compatibility
with the Ethereum network.
As depicted in Fig. 7, there are several important entities in the
olygon network several important (not all) will now defined in the
ollowing.
• Sequencer: The sequencer is responsible for ordering and packag-
ing transactions into blocks before they are committed to the main
chain. To ensure efficient and timely transaction processing and
block creation, optimizing the throughput of the network.
• Data Availability Committee (DAC): The DAC is a group of nodes
that ensures data availability for transactions processed by the se-
quencer, providing an extra layer of security and availability. To
guarantee that transaction data is accessible and can be retrieved,
ensuring the transparency and reliability of the network.
• Aggregator: Aggregators collect transactions from the network and
aggregate them into a single batch that can be processed together.
To increase efficiency by reducing the number of individual trans-
actions that need to be validated and processed by the sequencer,
thus optimizing throughput and minimizing latency.
• Prover: The prover generates cryptographic proofs that validate
the correctness of state transitions or transactions. To ensure
the integrity and correctness of transactions in the network by
providing verifiable proofs that can be checked by any node.
• Synchronizer: Synchronizers are responsible for maintaining con-
sistency and synchronization between the main chain and the
sidechains or L2 chains. To ensure that all chains remain in sync
with the main Ethereum chain, preventing any discrepancies or
data mismatches.
In Polygon’s architecture, various cryptographic primitives and al-
gorithms are utilized. One crucial component is the zk-Rollup tech-
nology, which uses ZKPs to validate transactions (Lavaur et al., 2022,
2023).
The basic principle involves the prof of knowledge mechanism 𝑃 (𝑥),
here 𝑃 is the prover and 𝑥 is the statement to be proven; For zk-
ollups, the proof ensures that a set of transactions is valid without
evealing the transactions themselves. This can be formalized using
s 𝜋 = 𝑍 𝐾 𝑃 ({𝑇𝑖}) where 𝜋 is the zero-knowledge proof, 𝑍 𝐾 𝑃 is
he zero-knowledge proof function, and {𝑇𝑖} is the set of transactions.
he efficiency and scalability are achieved through batch processing
hich is formalized as 𝑉 𝑒𝑟𝑖𝑓 𝑦(𝜋 , {𝑇𝑖}) where 𝑉 𝑒𝑟𝑖𝑓 𝑦 is the verification
unction related to the selected ZKP scheme.
31 https://docs.polygon.technology/cdk/architecture/cdk-validium/
#validium-data-flow.
https://docs.polygon.technology/
https://loomx.io/developers/en/intro-to-loom.html
https://github.com/loomnetwork
https://github.com/loomnetwork
https://docs.gnosischain.com/
https://docs.skale.network/
https://docs.polygon.technology/cdk/architecture/cdk-validium/#validium-data-flow
https://docs.polygon.technology/cdk/architecture/cdk-validium/#validium-data-flow
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Fig. 7. The general framework of the Polygon workflow.
Table 11
A comparison between discussed side-chain-based solutions for the blockchain scalability problem.
Feature/Aspect Polygon network Loom network Gnosis network Skale network
Primary goal Scalability, interoperability for
Ethereum
Scalable DApps, particularly
games and social apps
Decentralized financial tools,
prediction markets
Scalable infrastructure for
Ethereum DApps
Main
application
General DApps, DeFi, NFT
platforms
High-transaction DApps,
games
Prediction markets,
decentralized exchanges
High-performance DApps,
financial platforms
Scalability
solution
L2 sidechains and rollups Application-specific sidechains Ethereum mainnet with
custom protocols
Elastic sidechains
Consensus
mechanism
Proof of Stake (PoS) Delegated Proof of Stake
(DPoS)
Varies (Ethereum’s PoW/PoS) Asynchronous Byzantine Fault
Tolerant (ABFT)
Throughput High (dependent on sidechains
used)
High (sidechains tailored to
specific applications)
Moderate (limited by
Ethereum mainnet’s
scalability)
High (dynamic scalability with
elastic sidechains)
Transaction
fees
Lower than Ethereum mainnet Lower than Ethereum mainnet Depends on Ethereum mainnet
fees
Lower than Ethereum mainnet
Security
features
Inherits security from
Ethereum, PoS validation
DPoS validation, sidechain
security
Ethereum’s security,
multi-signature wallet (Gnosis
Safe)
ABFT consensus, Ethereum
mainnet integration
Interoperability High (connects various L2
solutions and sidechains)
Moderate (interoperable with
Ethereum mainnet)
High (focused on Ethereum,
integrates with other chains)
High (seamless integration
with Ethereum mainnet)
Flexibility High (supports multiple types
of chains and solutions)
Moderate (application-specific
sidechains)
High (various financial tools
and applications)
High (customizable elastic
sidechains)
Key advantages Scalability, lower costs, broad
application support
High throughput for specific
DApps, cost-effective
Secure financial tools,
decentralized governance
Dynamic scalability,
cost-effectiveness, high
performance
Polygon network provides a robust framework for scaling Ethereum
by employing sidechains and L2 solutions. Overall, Polygon’s mathe-
matical framework involves cryptographic functions, batch-processing
algorithms, and state transition verifications to ensure scalability, se-
curity, and decentralization. Using zk-Rollups and other cryptographic
techniques enhances the network’s capability to handle a high through-
put of transactions while maintaining integrity and decentralization.
17 
4.3.2. Loom network
Loom Network is another L2 scaling solution for Ethereum, of-
fering a platform that enables DApps to run at scale with improved
performance anduser experience. It utilizes sidechains to offload com-
putation and state management from the Ethereum mainnet, allowing
for faster and cheaper transactions. The Loom Network is a platform-
as-a-service (PaaS) designed to make it easy for developers to build
DApps on the Ethereum blockchain. It aims to provide scalability and
S. Banaeian Far and S.M. Hosseini Bamakan
g
h
N
s
t
o
P
E
f
u
t
i
E
s
d
w
f
a
t
s
t
i
c
p
s
p
s
o
a
p
r
o
Journal of Network and Computer Applications 233 (2025) 104044 
performance enhancements for DApps, particularly those that require
high transaction throughput, such as social media platforms and online
ames.
Loom network brings many advantages. For example, by offloading
computation and state management to sidechains, Loom Network sig-
nificantly increases the throughput of DApps, allowing them to handle a
large number of transactions per second (TPS). Moreover, its BaseChain
(it is the mainchain of the Loom Network, acting as a hub that connects
all Loom DAppChains to the Ethereum mainnet) ensures seamless
interoperability between its sidechains and the Ethereum mainnet, as
well as with other major blockchains; And the applied user experience
interface enhances performance and reduces transaction costs leading
to a better user experience, making DApps more practical and appealing
for everyday use.
As a practical example, assume a blockchain-based game with a
igh number of daily transactions for in-game actions. Using the Loom
etwork, the game can run on DAppChains (they are application-
pecific sidechains that run parallel to the Ethereum mainnet, handling
he bulk of the computational load for DApps), processing thousands
f transactions per second without congesting the Ethereum mainnet.
layers can seamlessly transfer their assets between the game and the
thereum mainnet using Plasma Cash (it is a variant of the Plasma
ramework designed to enhance security and scalability by allowing
sers to create unique, non-fungible tokens (NFTs) (Far et al., 2022b)
hat represent their assets on the sidechain), ensuring security and
nteroperability.
4.3.3. Gnosis
The Gnosis Network is another decentralized platform built on
thereum, primarily focused on creating open financial and governance
ystems. It provides the infrastructure for creating prediction markets,
ecentralized exchanges, and other financial instruments. Gnosis Net-
ork is a decentralized platform leveraging Ethereum to offer various
inancial tools and services, with a strong focus on prediction markets
nd decentralized exchanges. It aims to facilitate the creation and
rading of assets in a decentralized manner, ensuring transparency and
ecurity. Four below key components provide these exciting features:
1. Gnosis Safe: Gnosis Safe is a multi-signature wallet solution that
allows multiple parties to manage funds securely. To provide a
secure way to store and manage digital assets, requiring multiple
approvals for transactions to enhance security.
2. Gnosis Protocol: The Gnosis Protocol is a decentralized exchange
(DEX) protocol designed for trading ERC-20 tokens. To enable
efficient and trustless trading of assets without relying on a
centralized authority, leveraging batch auctions to determine
fair prices.
3. Prediction Markets: Gnosis provides a platform for creating and
participating in prediction markets, where users can trade on the
outcome of future events. To harness collective intelligence and
provide a decentralized mechanism for forecasting and decision-
making.
4. Conditional Tokens: Conditional tokens are used within Gnosis’s
prediction markets, representing the outcome of specific events.
To facilitate the creation of complex financial products and
prediction markets by allowing users to bet on various outcomes.
The collaboration of the mentioned components causes several ad-
vantages where Gnosis Safe ensures high security for managing funds
with multi-signature functionality, making it resistant to single points
of failure. Additionally, as a decentralized platform, Gnosis ensures
ransparency in its operations, from prediction markets to decentral-
zed exchanges. Ultimately, Gnosis’s focus on prediction markets and
onditional tokens provides innovative financial instruments and mech-
anisms for decentralized decision-making.
18 
4.3.4. Skale
The Skale Network is an Ethereum-compatible L2 scaling solution
that provides high-throughput, low-latency, and cost-effective infras-
tructure for deploying and running DApps. It aims to enhance the
erformance of Ethereum-based DApps by offering a network of elastic
idechains. Skale Network is designed to improve the scalability and
erformance of Ethereum DApps by utilizing a network of elastic
idechains. These sidechains operate independently but are fully inter-
perable with the Ethereum mainnet, allowing for seamless integration
nd enhanced performance.
4.4. Super-chain
A super-chain is a large-scale blockchain infrastructure supporting
multiple interconnected blockchains, designed to enhance performance,
scalability, and security through advanced consensus mechanisms and
architecture. Introduced by Optimism, this unified network features
shared security measures, communication layers, and an open-source
development stack (Bünz et al., 2020; Yamina and Yacine, 2023; Han
et al., 2024b). This approach simplifies the deployment of new chains,
making it as straightforward as deploying smart contracts. Super-chain
embodies an interconnected network of L2 solutions constructed on the
OP-stack. Its primary objective is to bring internet-scale capabilities to
Ethereum while ensuring scalability without fragmenting ecosystems.
However, the Superchain is currently a concept and an in-progress
roject, not yet a concrete reality.32
In addition to the Polygon network as a well-known, discussed
ecently, there are two other networks that could be considered state-
f-the-art super-chain solutions:
1. Optimism33: Optimism is a L2 scaling solution for Ethereum that
leverages optimistic rollups to improve transaction throughput
and reduce costs. By aggregating multiple transactions into a
single batch processed on the main Ethereum chain, Optimism
enhances scalability and reduces congestion. Its integration into
the super-chain framework demonstrates how multiple rollups
can interact seamlessly, providing a unified layer of security and
governance.
2. Arbitrum34: Arbitrum is another L2 solution designed to in-
crease Ethereum’s throughput and decrease transaction fees
using rollup technology. It employs an innovative fraud-proof
mechanism to ensure the integrity and correctness of transac-
tions. Within a super-chain structure, Arbitrum’s role would be
to provide a highly scalable and secure environment for DApps,
benefiting from shared security and interoperability with other
rollups.
Regarding the advantages of applying super-chains as L2 solutions
for the blockchain scalability problem, there are three challenges that
are listed in the following:
1. Interoperability: Achieving seamless communication and inter-
action between different blockchains within a super-chain re-
mains a significant challenge. Ensuring that various L2 solu-
tions can effectively interoperate without compromising security
or performance is complex and requires robust protocols and
standards.
2. Security: While the super-chain model aims to provide shared
security, maintaining the security integrity of multiple inter-
connected chains is demanding. Potential vulnerabilities in one
chain could pose risks to the entire network, necessitating strin-
gent security measures and constant vigilance.
32 https://docs.optimism.io/stack/explainer#foundational-superchain-
concepts.
33 https://optimism.io/.
34 https://arbitrum.io/.
https://docs.optimism.io/stack/explainer#foundational-superchain-concepts
https://docs.optimism.io/stack/explainer#foundational-superchain-concepts
https://optimism.io/
https://arbitrum.io/
S. Banaeian Far and S.M. Hosseini Bamakan
b
t
p
g
c
s
e
st
p
e
Journal of Network and Computer Applications 233 (2025) 104044 
Table 12
A comparison between scalability platforms and addressing a distinguished feature for each.
Feature Polkadot Kusama Loom network Gnosis chain Skala
Consensus
mechanism
PoS + Relay chain Experimental PoS PoS PoS Sharding + PoS
Scaling
approach
Parachains Experimental
Parachains
DApp-specific
sidechains
xDAI stablecoin Dynamic sharding
Distinguished
feature
Shared security Fast deployment App-specific
scalability
Low-cost stable
transactions
Dynamic resource
scaling
Table 13
A comparison between discussed super-chain-based solutions for the blockchain scalability problem.
Feature/Aspect Polygon network Optimism network Arbitrum network
Primary Goal Scalability, interoperability for
Ethereum
Scalable and cost-effective Ethereum
transactions
Scalable, fast, and low-cost
transactions for Ethereum
Main
application
General DApps, DeFi, NFT platforms General DApps, DeFi, scaling
Ethereum transactions
General DApps, DeFi, enterprise
applications
Scalability
solution
L2 sidechains and rollups Optimistic rollups Optimistic rollups
Consensus
mechanism
PoS Ethereum’s PoW/PoS, with fraud
proofs for rollups
Ethereum’s PoW/PoS, with fraud
proofs for rollups
Throughput High (dependent on sidechains used) High (batch processing of
transactions)
High (batch processing of
transactions)
Transaction
fees
Lower than Ethereum mainnet Lower than Ethereum mainnet Lower than Ethereum mainnet
Security
features
Inherits security from Ethereum, PoS
validation
Inherits security from Ethereum,
fraud-proofing
Inherits security from Ethereum,
fraud-proofing
Interoperability High (connects various L2 solutions
and sidechains)
High (fully compatible with
Ethereum)
High (fully compatible with
Ethereum)
Flexibility High (supports multiple types of
chains and solutions)
Moderate (focused on scalability with
rollups)
Moderate (focused on scalability with
rollups)
Key advantages Scalability, lower costs, broad
application support
Simple integration with Ethereum,
low fees
High compatibility with Ethereum,
efficient scaling
a
T
h
r
t
a
3. Decentralization and Governance: Balancing scalability with de-
centralization is a perennial challenge in blockchain develop-
ment. Super-chain projects must ensure that their governance
models do not centralize control, thereby undermining the de-
centralized ethos of blockchain technology. Establishing fair
and transparent governance frameworks that accommodate the
interests of diverse stakeholders is crucial.
The super-chain concept represents a significant advancement in
lockchain technology, aiming to solve scalability issues while main-
aining security and decentralization. Practical implementations like
Optimism, Arbitrum, and Polygon illustrate the potential of this ap-
roach. However, challenges related to interoperability, security, and
overnance must be addressed to realize the full promise of super-
hains, and as the technology and its implementations mature, the
uper-chain could become a foundational element of the next gen-
ration of blockchain networks. Table 13 presents a comparison be-
tween the three called super-chain solutions discussed above (Polygon,
Optimism, and Arbitrum).
4.5. Hyper-chain
A hyper-chain is an advanced blockchain framework that empha-
izes ultra-high scalability and performance, often utilizing innovative
echnologies and architectures that surpass traditional blockchain ca-
abilities. This concept, known as the final L3, represents a significant
volution in blockchain technology (Lee et al., 2022). Hyper-chains
are essentially super-chains enhanced by ZK-based rollups, providing
exponential and secure scalability (Alshahrani, 2024). By leveraging
ZK-based rollups, hyper-chains aim to overcome limitations and sig-
nificantly enhance the scalability of blockchain networks. The zkSync
Hyperchains is one of the most famous hyper-chain examples.
19 
Technically, hyper-chains operate by implementing a multi-layered
rchitecture where L3 solutions build upon the foundations laid by L2
technologies (Abdella et al., 2024). ZK-based rollups are crucial to this
design, enabling hyper-chains to aggregate multiple transactions into a
single proof, which is then verified on the base L1. This process dra-
matically reduces the computational and storage requirements on the
main chain, thus significantly increasing throughput. Furthermore, ZK-
rollups ensure enhanced security and privacy by using zero-knowledge
proofs, which allow transaction verification without revealing under-
lying data. The hyper-chain framework also incorporates advanced
consensus mechanisms, cross-chain interoperability protocols, and state
sharding to optimize performance and resource utilization further.
hese elements collectively contribute to an architecture capable of
andling thousands of transactions per second, making hyper-chains a
obust solution for scalable blockchain applications.
In addition to academic solutions, several practical projects par-
ially provide hyper-chains. In the following, four famous projects are
ddressed, and Table 14 presents a comparison between these projects.
1. zkSync Hyperchains35: zkSync Hyperchains utilize zero-
knowledge rollups to achieve high scalability and security. By
bundling multiple transactions into a single proof and then
validating it on the Ethereum mainnet, zkSync significantly
reduces the load on the primary blockchain. This process not
only enhances throughput but also lowers transaction costs.
zkSync Hyperchains leverage recursive proofs to maintain low
latency and high efficiency, ensuring that the system can handle
a vast number of transactions concurrently without compromis-
ing security. zkSync Hyperchains are applied in various DeFi
35 https://docs.zksync.io/zk-stack/concepts/zk-chains.
https://docs.zksync.io/zk-stack/concepts/zk-chains
S. Banaeian Far and S.M. Hosseini Bamakan
a
n
i
s
d
d
I
i
a
s
t
w
t
w
(
Journal of Network and Computer Applications 233 (2025) 104044 
platforms to improve transaction speeds and reduce costs. By
integrating zkSync, these platforms can offer users a seamless
and efficient trading experience. Additionally, zkSync supports
smart contracts, making it a versatile solution for developers
looking to build scalable and secure DApps on Ethereum.
2. StarkNet36: The StarkNet is a permissionless decentralized ZK-
Rollup that supports general computation over Ethereum. It
utilizes STARK (Scalable Transparent Argument of Knowledge)
proofs, which are a type of zero-knowledge proof that ensures
data privacy and security while enabling scalability. StarkNet
operates as an L3 solution, layering on top of existing blockchain
infrastructure to provide a high-throughput environment capa-
ble of supporting complex smart contracts and DApps.
The StarkNet is applied in environments where high throughput
and privacy are crucial, such as in enterprise blockchain solu-
tions and high-frequency trading platforms. By implementing
StarkNet, these applications can scale effectively while maintain-
ing robust security and privacy standards, making it ideal for
handling large volumes of sensitive transactions.
3. Optimism Hyperchains37: Optimism Hyperchains use optimistic
rollups to enhance blockchain scalability. Unlike ZK-rollups,
optimistic rollups assume transactions are valid by default and
only run fraud proofs if a challenge is presented. This ap-
proach reduces computational overhead and increases trans-
action throughput. Optimism Hyperchains integrate advanced
fraud-proof systems and economic incentives to ensure that
transactions remain secure and verifiable.
Optimism Hyperchains are employed in various blockchain
games and NFT platforms, where transaction speed and cost
are critical. By adopting Optimism, these platforms can offer
users faster and cheaper transactions, enhancing the overall
user experience and enabling more complex and interactive
applications.
4. Polygon Hermez38: PolygonHermez is a decentralized ZK-Rollup
solution that focuses on scaling Ethereum by batching multi-
ple transactions into a single proof. It uses zk-SNARKs (Zero-
Knowledge Succinct Non-Interactive Arguments of Knowledge)
to achieve this, ensuring high security and efficiency. Polygon
Hermez supports token transfers and smart contract interactions,
providing a scalable and secure environment for DApps.
Polygon Hermez is used extensively in payment solutions and
microtransaction platforms. By integrating Polygon Hermez,
these platforms can process a large volume of transactions
quickly and affordably, making it feasible to handle micropay-
ments and other high-frequency transactions without congestion
or high fees.
As advanced tools are used to implement hyper-chains, there are
lso state-of-the-art challenges. Hence, this study believes that the four
umbered items with possible solution(s) in the following are more
mportant (the details will discussed in the next section):
• Data Availability: Ensuring data availability is critical for the
security and functionality of hyper-chains, as the off-chain com-
putation model requires that data remains accessible to verify
transaction proofs.
Implementing robust data availability committees or leveraging
decentralized storage solutions like IPFS (Inter Planetary File
System) can help ensure data is always accessible. Additionally,
new cryptographic techniques such as erasure coding can enhance
data availability by distributing data across multiple nodes.
36 https://www.starknet.io/.
37 https://www.theblock.co/post/293397/optimisms-superchain-now-
upports-layer-3-chains-via-op-stack.
38 https://hermez.io/ and https://polygon.technology/blog/polygon-zk-
eep-dive-into-polygon-hermez-2-0.
20 
• Interoperability: Hyper-chains need to interact seamlessly with
different blockchain networks to maximize their utility and adop-
tion.
Developing standardized cross-chain communication protocols
and utilizing bridges that allow asset transfer and message passing
between different chains can enhance interoperability. Protocols
like Polkadot and Cosmos are pioneering solutions in this domain.
• Security: Maintaining security while achieving high scalability is
a significant challenge, as higher transaction volumes can attract
more sophisticated attacks.
Employing advanced cryptographic techniques like zk-SNARKs
and zk-STARKs for transaction verification can ensure robust
security. Additionally, implementing multi-layered security proto-
cols and continuous monitoring for suspicious activities can help
maintain the integrity of the hyper-chain.
• User Experience: Ensuring a seamless and user-friendly experi-
ence is essential for the widespread adoption of hyper-chains,
especially when dealing with complex cryptographic operations.
Developing intuitive user interfaces and integrating wallet solu-
tions that abstract the complexity of the underlying technology
can enhance user experience. Providing educational resources
and support can also help users navigate and utilize hyper-chain
applications effectively.
5. Discussion and future directions
In recent sections, several L3-based solutions aimed at enhancing
the interoperability and scalability of emerging blockchain systems
were reviewed. However, various factors need to be considered when
etermining whether to adopt any of these solutions for current issues.
t is clear that none of the solutions is definitively the best or worst;
each can be applied based on the specific problem statement. For
further clarification, Table 15 presents a SWOT analysis (Helms and
Nixon, 2010; Valentin, 2001) of the solutions reviewed in Sections 3
and 4. This SWOT analysis provides a high-level overview of each
solution’s strengths, weaknesses, opportunities, and threats, highlight-
ng key considerations for each blockchain solution. Consequently, this
nalysis assists developers and product owners in selecting the most
uitable solutions to address the discussed challenges.
5.1. Opportunities
In addition to providing good interoperability and excellent scal-
ability for blockchain-based networks discussed recently (see Sec-
ions 3 and 4), L3 solutions also involve several marginal but important
achievements. In the following, the three important categories of them
are listed. Table 17 summarizes this section.
5.1.1. Universal DeFi
DeFi, a well-known paradigm, provides excellent financial services
ithout a central authority and no need for user registration. However,
hese types of services are provided on a single blockchain (Far et al.,
2023b; Adisa et al., 2024; Abdullah et al., 2024), and there should be
an existence of a centralized bridge (e.g., a centralized exchange) to
connect two or more blockchains. Hence, it seems the presence of a
universal DeFi to link blockchains (the ideal is to link all blockchains)
causes much assistance in integrating DeFi (Chainlink39 is one of the
most successful L3 projects in this regard, and has brought many
innovative services Teoh, 2023; Saad et al., 2024; Han et al., 2024a).
‘‘One DeFi for all blockchains’’ is an ambitious but feasible idea
hich can absolutely remove the interference of governance and banks
Spinoglio, 2022). Hence, we believe that the universal DeFi provides
many applications in which developers with their innovative solutions
play the most critical roles in this application; The following lists
several important ones:
39 https://docs.chain.link/.
https://www.starknet.io/
https://www.theblock.co/post/293397/optimisms-superchain-now-supports-layer-3-chains-via-op-stack
https://www.theblock.co/post/293397/optimisms-superchain-now-supports-layer-3-chains-via-op-stack
https://hermez.io/
https://polygon.technology/blog/polygon-zk-deep-dive-into-polygon-hermez-2-0
https://polygon.technology/blog/polygon-zk-deep-dive-into-polygon-hermez-2-0
https://docs.chain.link/
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Table 14
A comparison between discussed hyper-chain-based solutions for the blockchain scalability problem.
Feature/Aspect zkSync hyperchains StarkNet Optimism hyperchains Polygon Hermez
Primary goal Scalable, low-cost transactions
using zk-Rollups
Scalable, secure transactions
using zk-STARKs
Scalable and cost-effective
Ethereum transactions
Scalable, secure transactions
using zk-Rollups
Main
application
General DApps, DeFi, NFT
platforms
General DApps, DeFi, enterprise
applications
General DApps, DeFi, scaling
Ethereum transactions
General DApps, DeFi, NFT
platforms
Scalability
solution
zk-Rollups zk-STARKs Optimistic Rollups zk-Rollups
Consensus
mechanism
zk-Rollups with validity proofs zk-STARKs with validity proofs Ethereum’s PoW/PoS, with
fraud proofs for rollups
zk-Rollups with validity proofs
Throughput High (zk-Rollup efficiency) High (zk-STARK efficiency) High (batch processing of
transactions)
High (zk-Rollup efficiency)
Transaction
fees
Lower than Ethereum mainnet Lower than Ethereum mainnet Lower than Ethereum mainnet Lower than Ethereum mainnet
Security
features
Inherits security from Ethereum,
zk-proof validation
Inherits security from Ethereum,
zk-proof validation
Inherits security from Ethereum,
fraud-proofing
Inherits security from Ethereum,
zk-proof validation
Interoperability High (compatible with
Ethereum and other zk-Rollups)
High (fully compatible with
Ethereum)
High (fully compatible with
Ethereum)
High (compatible with
Ethereum and other zk-Rollups)
Flexibility High (supports various
applications)
High (supports complex
computations and applications)
Moderate (focused on scalability
with rollups)
High (supports various
applications)
Key advantages Scalability, lower costs, high
security
Scalability, high security,
supports complex logic
Simple integration with
Ethereum, low fees
Scalability, lower costs, high
security
Table 15
The SWOT analysis of the reviewed solutions in Sections 3 and 4.
Solution Strengths Weaknesses Opportunities ThreatsCross-chain Facilitates interoperability,
enables asset transfer between
chains
Potential security vulnerabilities,
complexity in implementation
Expanding use cases through
seamless integration of diverse
blockchains
Risk of hacks and exploits,
governance issues across chains
Multi-chain Enhances scalability, leverages
diverse blockchain features
Fragmented ecosystems, complex
management
Custom solutions for various use
cases, increased flexibility
Compatibility issues, maintenance
challenges
Omni-chain Unified system, centralized
management of multiple chains
Potential centralization risks,
higher complexity
Streamlined operations, improved
user experience
Central point of failure, security
risks
App-chain Tailored solutions for specific
applications, optimized
performance
Limited scope, less
generalizability
High efficiency for targeted use
cases, custom optimizations
Dependency on the application,
scalability limitations
Para-chain Shared security, interoperability
with a main network (e.g.,
Polkadot)
Dependency on main network,
limited autonomy
Enhanced scalability, robust
ecosystem support
Main network vulnerabilities,
potential bottlenecks
Side-chain Scalability, experimentation
without affecting mainnet
Security concerns, reliance on
mainnet
Innovation and development
freedom, targeted optimizations
Security risks, potential for
isolation
Super-chain High performance, advanced
scalability
Complexity, potential for
over-centralization
Support for large-scale
applications, enhanced security
models
Technological challenges, high
implementation costs
Hyper-chain Ultra-high scalability and
performance
Cutting-edge technology might be
untested, complexity
Leading-edge solutions, next-gen
applications
Rapid technological changes,
potential lack of standards
Table 16
A comparison between hyperchains and superchains and addressing a distinguished feature for each.
Feature Polygon Optimism Arbitrum zkSync
hyperchains
StarkNet Optimism
hyperchains
Polygon Hermez
Consensus
type
PoS Optimistic
rollups
Optimistic
rollups
zk-Rollups zk-STARKs Aggregated
rollups
zkEVM rollups
Scaling
mechanism
Plasma +
Rollups
Rollups Fraud-proof
rollups
zk-Rollups zk-proofs Horizontal
scaling
zkEVM
Distinguished
feature
Modular
blockchains
Low-cost
optimistic
rollups
Fraud-proof
scalability
zk-based
hyperchains
Cairo and
ZK-STARKS
Rollups
aggregation
Full zk
• Stake here, get loan there: Blockchain-based loans are one of the
most attractive DeFi services and stablecoins play a critical role
in them (Tzinas and Zindros, 2023; Lau and Tse, 2021). For
example, you can stack several ETHs and get a loan equal to
70% of the stacked value for USDT on the Ethereum blockchain;
the stacked ETHs will be locked and un-withdrawable until the
settlement (Spinoglio, 2022).
21 
The concept of ‘‘One DeFi for all blockchains’’ enables DeFi tech-
nology to provide loan services between two or more blockchains.
In this paradigm, you can stack a cryptocurrency in a blockchain
(e.g., FTM on the Fantom blockchain) and get a loan on another
blockchain (e.g., USDT on the Ethereum blockchain).
Locking digital assets as collaterals for getting loans or receiving
service (universal lending-borrowing service) can be assumed as
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Table 17
The summary of Section 5.1 (three important opportunities of L3 development).
Item Universal DeFi Education Healthcare systems
Important
players
Developers and User Interface (UI) designers Metaverse developers and User Experience
(UX) designers
Data scientist and AI experts
Second level
players
DEX owners Professors and teachers Physicians and nurses
Service
providers
DEXes and DeFi platforms Virtual schools and academia Hospitals and Healthcare centers
End users Investors (from planktons to whales) Students, researchers, and science seekers Patients
Requirements Personal computers or smartphones Multimedia I/O enable personal computers
or smartphones (camera, microphone, smart
glasses, etc.)
Wearable sensor-supported personal
computers or smartphones (Heart rate
sensors, measuring blood sugar, body
temperature, blood pressure, measuring
neurological problems, etc.)
Applications Stake here, get loan there - Universal
crowdfunding - Removing centralized
bridges - Metaverse applications -
Regulation facili - Single-register-on
One world, one school - Common workspace
and experiments - Exchange of science and
culture - Universal academic certificates -
Unlimited development of decentralized
science - Fair and universal comparison
Go anywhere with your physician -
Consensus between physicians - Exact
prescription - Increasing the accuracy of
nurses - Easy patients and disease tracking
U
another application of the Universal DeFi or the ‘‘One DeFi for all
blockchains’’ concept.
• Universal crowdfunding: Crowdfunding for blockchain-based
projects and launching an initial coin offering (ICO) are well-
known methods of collecting initial Investment for projects
(Campino et al., 2022; Fridgen et al., 2018; Karpenko et al.,
2021). In these types of crowdfunding, initial investors get consid-
erable shares of the launched projects/coin (Cai, 2018;
Guggenberger et al., 2024) (many types of fraud exist in these
types of crowdfunding, but they are not in this study’s scope).
Most current crowdfunding is run centrally and a small number
are launched on a single blockchain (fraud is possible).
This application offers the ‘‘Universal crowdfunding’’ paradigm
enables project owners to collect funds through all blockchains
for developing on one blockchain. In ‘‘Universal crowdfunding’’
where no third party exists, every initial investor can pay/lock
their currencies in every blockchain to get shares in a partic-
ular. For example, an initial investor can execute a smart con-
tract developed on the Fantom blockchain for paying FTMs, and
get several shares/coins of a project that will be launched in
the Ethereum blockchain. This application is possible if L3s are
developed properly.
• Removing centralized bridges: Although centralized services will
not be removed, developing efficient and high-throughput L3s
can decrease the impact of centralized bridges in blockchain-
based services (Daghmehchi Firoozjaei et al., 2020; Lan et al.,
2021). Removing centralized bridges is one of the cost-side ap-
plications of the universal DeFi which makes cross-chain transac-
tions much faster and efficient. Moreover, enables DApps design-
ers/developers to generate user-friendly UI for beginners who do
have not enough knowledge about different blockchains, DEXs,
and blockchain-based services (Kannengießer et al., 2020; Aspris
et al., 2021; Choi and Kim, 2024).
As a high-potential example depicted in Fig. 8, assume an amateur
end-user has FTMs on the Fantom blockchain and wants to buy
several objects in the Decentraland environment developed on the
Ethereum blockchain. On the user side, he/she purchases a virtual
car in the Decentraland environment with FTMs. But on the DApp
side, the process is a little complex. The L3 DApp should first
change the user’s FTMs to ETHs, and then an L2 DEX changes
ETHs to MANAs (MANA is a token used in the Decentraland) to
be able for use in the Decentraland for purchasing the car.
• Metaverse applications: The development of an unified metaverse
is a challenging issue that has several aspects including conflicts
between different native tokens, programming, different goals,
quality of environments, and financial calculation. In this regard,
22 
this study believes that universal DeFi can solve the financial
interoperability challenges of metaverses (Far et al., 2023b).
Relying on the universal DeFi paradigm (similar to Fig. 8, but
not exactly40), audiences of different metaverses can purchase
products, as NFTs, from other metaverses to use in their arbi-
trary metaverse (Far et al., 2022b; Banaeian Far and Bamakan,
2023; Far et al., 2022a). It ishighlighted that this application re-
quires several preliminaries, such as unifying the programming of
metaverses, applying the same methods in objects development,
developing similar environments, etc.
• Regulation facilitator: Standardization is a challenging step for
governments, foundations, or consortiums which becomes more
acute if they face many paradigms (Yeoh, 2017; Lianos et al.,
2019; Akanfe et al., 2024; Luna et al., 2024). In this regard,
integrating and merging several projects into one (the ideal state
is to merge all projects into one) could strongly reduce the stan-
dardization costs and time. On another hand, a regulation process
to implement policies for a small number of projects (the ideal
state is regulation only for one project) is very faster than if many
projects launch for similar goal(s) but with different processes.
As a result, the universal DeFi provides many enhancements in
regulations and standardization processes.
• Single-register-on (if mandatory due to regulation): Although open-
to-all-service without authentication is one of the attractions of
blockchain-based systems, some services may require registration
due to several policies and regulations (Akanfe et al., 2024; Luna
et al., 2024) (e.g., the 1 inch DEX). In this state, there is no
interoperability way (for user’s information sharing) if a user
wants to use the same service in different blockchains or different
services on several blockchains. Hence, the existence of a dis-
tributed L3 infrastructure provides users’ information sharing for
all DeFi services in all blockchains with one-time user registration
in addition to increasing interoperability and scalability (Sung-Un
and Jung, 2024; Nandi et al., 2020). Based on this application,
the single-register-on (SRO) service can be introduced as one of
the basic primary issues in the integration of all DeFi services to
achieve universal DeFi.
As a conclusion, the SWOT analysis, shown in Table 18, provides
a comprehensive overview of the strengths, weaknesses, opportuni-
ties, and threats associated with the implementation and adoption of
niversal DeFi as a sub-application within L3 blockchains.
40 E.g., a user can sell his product’s NFT on a metaverse developed on the
Avalanche blockchain, and, after passing similar steps, he can buy/mint a
similar product in the Decentraland environment.
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Fig. 8. An example of L3 applications in removing centralized bridges for the Metaverse applications.
Table 18
The SWOT analysis of the Universal DeFi discussed in Section 5.1.1.
Strengths Weaknesses Opportunities Threats
Interoperability: Seamlessly
connects multiple blockchains,
enhancing the flexibility and
reach of DeFi services.
Complexity: Implementation and
maintenance of such a system can
be complex and
resource-intensive.
Expansion of DeFi services: Can
lead to the development of new
DeFi products and services that
leverage cross-chain capabilities.
Market competition: Other
blockchain solutions and
emerging technologies might offer
competing services, potentially
limiting adoption.
Decentralization: Eliminates the
need for centralized bridges,
reducing risks associated with
central points of failure.
Regulatory Challenges: Navigating
the regulatory landscape across
multiple jurisdictions can be
difficult. Navigating the
regulatory landscape across
multiple jurisdictions can be
difficult.
Universal Crowdfunding:
Enables more efficient and
widespread fundraising
opportunities across multiple
blockchains.
Technological obsolescence:
Rapid advancements in
blockchain technology could
render current solutions obsolete.
Innovation potential:
Encourages innovative solutions
from developers, fostering a
dynamic and evolving DeFi
ecosystem.
Security risks: Increased
complexity and interoperability
can introduce new security
vulnerabilities.
Metaverse integration: Supports
financial interoperability within
metaverses, facilitating
cross-metaverse transactions and
enhancing user experiences.
Fraud and scams: The increase
in cross-chain transactions and
crowdfunding might attract
fraudulent activities, requiring
robust security measures and
regulations.
Cost efficiency: Reduces
transaction costs by eliminating
intermediaries and streamlining
cross-chain interactions.
Integration difficulties: Ensuring
compatibility and smooth
integration with existing
blockchain protocols and services
can be challenging.
Regulatory standardization: Can
aid in creating more standardized
and streamlined regulatory
frameworks, benefiting both
regulators and participants.
Adoption resistance:
Stakeholders in traditional finance
and even within certain
blockchain communities might
resist the shift towards a
universal DeFi system.
User accessibility: Simplifies the
user experience, making DeFi
more accessible to a broader
audience, including beginners.
Dependence on L3
development: Success is
contingent on the effective
development and adoption of
Layer 3 technologies.
Single-register-on: Provides a
unified user registration system,
simplifying user management and
enhancing regulatory compliance.
Systemic risk: The
interconnected nature of a
universal DeFi system could mean
that failures or attacks on one
part of the system have
far-reaching impacts across
multiple blockchains.
23 
S. Banaeian Far and S.M. Hosseini Bamakan
v
m
S
Journal of Network and Computer Applications 233 (2025) 104044 
5.1.2. Education
Education is another aspect of L3 development in which the meta-
erse plays a critical role. the six exciting applications of L3 develop-
ent in education are identified in the following. Table 19 presents a
WOT analysis for this aspect of L3 development.
• One world, one school (or university): Regarding the critical role of
metaverses in education, students can present in Three-
Dimensional (3D) classrooms remotely with their avatars (Far
et al., 2023b; Far and Rad, 2022; Kaddoura and Husseiny, 2023;
Pradana and Elisa, 2023). However, it is not yet common, and
very small numbers of education are held on metaverses as initial
tests. As the future horizon (we hope very soon), L3 development
will make easy school change (or being in the same school)
if students migrate since the launching of each classroom on
each blockchain enables students to be present in the classrooms
from wherever they are. Therefore, the ambitious dream of ‘‘One
world, one school’’ will be fulfilled if efficient L3s are developed,
and worldwide schools are held on metaverses.
• Common workspace and experiments: Virtual laboratories, interna-
tional classrooms, common workspaces, participating in interna-
tional exhibitions, and being in science places from all over the
world with a click provide many achievements in addition to
reducing costs and assisting environmental protection (Far and
Rad, 2022; Far et al., 2023c). However, L3-based linking of all
metaverses enhances the efficiency of workspaces and users of
a particular metaverse can join other workspaces, as guesses, to
increase interoperability. This fact achieves huge scalability for
metaverse owners to attract a lot of audiences and increase their
revenue.
• Exchange of science and culture: The presentation of international
education makes the world’s cultures closer. For example,
Africans can link to Indians, everyone can travel to America and
Canada, and Asians can meet their European collegemates easily
to exchange their science and culture (Bibri, 2022; Gaurav, 2023;
Tsai, 2024; Banaeian Far and Rad, 2023). This causes a rapid
exchange of state-of-the-art sciences with different perspectives
and the communication of various cultures; As a result, the spread
of powerful L3-enabled metaverses and education can provide
many improvements in the exchange of science and culture.
• Universal academic certificates: There are many Internet-based
academies that hold courses and provide international certificates
to graduates(Coursera,41 Udemy,42 etc.). However, people world-
wide could not accept all of them because of several reasons, such
as uncompetitive and sometimes expensive costs, the possibility
of conflict of interest of professors/teachers, restricted access due
to embargo, lack of general acceptance, and level differences
in the quality of courses. The low attractiveness of 2D environ-
ments and traditional structures are other issues that recently
attracted a massive number of ‘‘Generation Z’’ to 3D-environment
(Metaverse-based) courses (Far et al., 2023c). Although the cur-
rent metaverse-based academia are not acceptable by all and
not general, the integrated courses and environments based on
state-of-the-art technologies illustrate a huge potential to be the
favorite of everyone since providing unique and fair presentations
for the same exams and universal academic certificates (Duan
et al., 2021; Pregowska et al., 2024; Colamartino et al., 2024).
Hence, the development of L3 and preparation of easy access for
enrolled students to all courses presented in each blockchain will
increase the acceptability of universal academic certificates issued
by metaverse-based academies.
41 https://www.coursera.org/.
42 https://www.udemy.com/.
24 
• Unlimited development of decentralized science (DeSci): Blockchain
technology has enabled excellent collaboration for research teams
in secure data sharing and fairness salary (Weidener, 2024; Ding
et al., 2022). In this regard, DeSci, as a newly-emerged concept,
provides many achievements and improves background issues
of science-based projects such as financial calculation, fairness,
complete removal of conflict of interests, and fair payment to all
participants of projects (Wang et al., 2022a).
Unlimited collaboration in science and development of the DeSci
concept is one of the most important achievements of L3 proceed-
ing in education in which the FunDeSci43 (NFT-based fundraising
for decentralized science) is known as a success platform that
launches projects as NFTs for universal funding and assigns shares
to all funders. However, as this platform does not benefit from L3,
it will be introduced as the top project if it applies L3 interfaces
in its background.
• Fair and universal comparison: Smart contract-based transcripts
and AI-in-the-background exams provide fair and universal com-
parisons for worldwide researchers and students. Additionally,
this achievement with the assistance of the science finance (SciFi)
paradigm increases the motivation to be a participant in univer-
sal projects (Far et al., 2023b; Gorkhali and Chowdhury, 2022;
Tenorio-Fornés et al., 2021). Hence, as the last important appli-
cation of L3 development in education, this study believes that
efficient L3 is the most important issue in the near future that
predicts the future will be virtual.
5.1.3. Healthcare systems
Enhancing blockchain-based healthcare systems is another aspect
of L3 proceedings in which data scientists and Artificial Intelligence
(AI) experts play critical roles in assisting physicians. The following
listed items address several important applications of L3s development
in healthcare systems.
• Go anywhere with your physician: Modern TeleMedicine empow-
ered by wearable sensors presents a visual connection and natural
sense for physicians and patients (Far et al., 2023c; Jain et al.,
2022; Bamakan et al., 2022). This topic becomes more exciting
when a meeting is held in an ideal Metaverse between the patient
and physician. This paradigm transfers the most natural senses
and causes more accurate prescriptions by the physician.
Metaverse-based TeleMedicine (in several works called MetaMed
(Far et al., 2023b)) enables patients to go anywhere with their
physician(s) or meet their physician(s) everywhere they are. The
main challenge solved by the efficient development of L3s is
to link different metaverse-based TeleMedicine services devel-
oped on different blockchains. This means every patient, who
has a smartphone with a L3 DApp, can use Metaverse-based
TeleMedicine service even if this service has been launched in
another blockchain and provided by a different hospital or health-
care center.
• Consensus between physicians: One file that consists of the collec-
tion of all documents of a patient provides much assistance to
all participants (physicians, doctors, nurses, etc.) of a healthcare
system (Gallo et al., 2021; Cummings et al., 2007). Integration
of all opinions with considering a novel access control and data
management presents valuable insight into dealing with patients
and the treatment process.
In an integrated dataset, the best consensus between physicians
is made and caused to the most accurate prescriptions by the
treatment team. As with the previous item, healthcare centers
or hospitals are allowed to share their electronic health records
(EHR) through each blockchain they want. However, it causes
limitation of access for their collaborators which L3s are known
as the best solution.
43 https://fundesci.com/.
https://www.coursera.org/
https://www.udemy.com/
https://fundesci.com/
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Table 19
The SWOT analysis of the Education discussed in Section 5.1.2.
Strengths Weaknesses Opportunities Threats
Global accessibility to education
through metaverse-based
platforms.
Current limited adoption and
technological readiness of L3 and
metaverse in education.
Expansion of education access to
remote and underserved regions
globally.
Regulatory challenges and
potential legal issues surrounding
blockchain and virtual education
environments.
Enhanced collaboration through
virtual laboratories and
international classrooms.
High costs and technological
barriers for widespread adoption.
Increased revenue streams for
educational institutions through
scalable and interoperable
platforms.
Cybersecurity threats and risks
associated with digital platforms
and blockchain technology.
Rich cultural exchange and
diversity in education.
Potential resistance to change
from traditional education
systems and stakeholders.
Development of innovative
educational tools and resources
leveraging L3 technology.
Digital divide exacerbating
inequalities if access to necessary
technology is not widespread.
Possibility of universal academic
certificates increasing recognition
and credibility.
Concerns over the quality and
standardization of courses and
certifications.
Strengthening global collaboration
in research and development
projects.
Potential monopolization by
major tech companies,
undermining decentralization
efforts.
Decentralized science (DeSci)
promoting fair and transparent
research collaborations and
funding.
Security and privacy issues
associated with blockchain and
metaverse technologies.
Enhancing the credibility and
acceptance of online and
metaverse-based education.
Resistance to adoption due to
skepticism about the effectiveness
and legitimacy of
metaverse-based education.
Fair and universal comparisons
through smart contracts and
AI-driven exams.
Initial setup complexity and the
need for significant infrastructure
and technical support.
Creating inclusive and engaging
learning environments for
Generation Z and beyond.
Environmental concerns related to
the energy consumption of
blockchain and metaverse
infrastructures.
Table 20
The SWOT analysis of the healthcare systems discussed in Section 5.1.3.
Strengths Weaknesses Opportunities Threats
Enhanced interoperability across
different blockchain networks,
enabling seamless access to
Metaverse-based TeleMedicine
services regardless of the
underlying blockchain.
Complexity in implementing and
maintaining L3 solutions, which
may require advanced technical
expertise and resources.
Development of innovative
healthcare products combining AI,
blockchain, and Metaverse
technologies, providing
cutting-edge solutions for patient
care.
Resistance from traditional
healthcare providers and systems
toadopt new technologies and
integrate with blockchain-based
solutions.
Improved consensus and
collaboration among physicians
through integrated datasets,
leading to more accurate
prescriptions and treatment plans.
Potential privacy and security
concerns with widespread access
to comprehensive patient data.
Expansion of TeleMedicine
services, offering more flexible
and accessible healthcare options
for patients globally.
Potential cybersecurity threats
targeting healthcare data stored
and transmitted through
blockchain networks.
Increased accuracy in
prescriptions with the integration
of AI, leveraging comprehensive
EHRs for better decision-making.
Dependence on the availability
and reliability of blockchain
networks and associated
technologies.
Enhanced collaboration between
healthcare centers, hospitals, and
other stakeholders through
interoperable blockchain systems.
Legal and ethical challenges
regarding the ownership, access,
and use of patient data on
blockchain platforms.
Enhanced efficiency and accuracy
of nurses by providing complete
access to classified patient
information and AI-based
assistance.
Scalability issues in handling vast
amounts of healthcare data across
multiple blockchains.
Greater accuracy and efficiency in
healthcare delivery, improving
patient outcomes and overall
healthcare quality.
Possible technical failures or
downtimes in blockchain
networks, affecting the
availability and reliability of
healthcare services.
Efficient patient and disease
tracking, especially for infectious
diseases, facilitated by
interoperable and scalable
blockchain solutions.
Regulatory and compliance
challenges related to the use of
blockchain in healthcare,
particularly in different regions
and jurisdictions.
Adoption of advanced AI-driven
treatment systems, reducing
human error and improving
precision in healthcare.
- High costs associated with the
development, deployment, and
maintenance of L3-based EHR
systems.
• Exact prescription: Recent proceedings of Machine Learning (ML)
(Rajeswari et al., 2024; Mohammed et al., 2024; Kayikci and
Khoshgoftaar, 2024) and AI cannot be ignored (Shinde et al.,
2024; Hennebelle et al., 2024; Puri et al., 2024). Regarding ML,
advanced generative AI is able to make better decisions than
humans and even experts. With access to all EHRs related to each
patient, an AI-based prescription system can bring much help to
physicians and decrease possible mistakes.
Treatment systems based on artificial intelligence can make more
accurate decisions if they have access to more comprehensive
information about patients, pandemics, state-of-the-art knowl-
edge, and healthcare trends and proceedings. This study believes
that the merging of AI with blockchain-based treatment systems
presented as L3 DApps (or an ideal metaverse Far and Rad, 2022)
25 
will considered as one of the most exciting healthcare products
shortly.
• Increasing the accuracy of nurses: In addition to doctors, nurses also
have several tasks that should be done very accurately and with
no mistakes (Chen et al., 2024b; Singhal et al., 2023). In this
regard, the correct access of nurses to classified information to
perform their duties and the presence of AI-based assistants will
help them speed up the process of treating patients (Shinde et al.,
2024; Puri et al., 2024).
Based on the above, access to complete information and prescrip-
tions of all doctors is an important thing for nurses, which can
significantly increase their accuracy in performing tasks (Singhal
et al., 2023). Collecting complete patient information, including
the type of disease, sensitivities, opinions of different doctors,
S. Banaeian Far and S.M. Hosseini Bamakan
c
a
a
o
b
c
b
i
P
Journal of Network and Computer Applications 233 (2025) 104044 
ethical characteristics and other relevant information requires a
strong and always available system, which L3 blockchains can be
considered as a technological solution.
• Easy patients and disease tracking: The COVID-19 pandemic taught
many things to healthcare systems and governments in addition
to causing many improvements in healthcare systems and raising
a lot of innovative scientific ideas (Bamakan et al., 2022). One
of the best policies is patient and disease tracking which has a
strong impact on quarantine tracking and disease prevention, and
those policies should be considered for all patients with infectious
diseases and viruses.
There are many solutions for implementing the aforementioned
issues which most of them are centralized ones, and other
blockchain-based proposals use a single blockchain (or multi-
chain with centralized bridges) (Khan et al., 2024; Marbouh et al.,
2020; Lee et al., 2020). It is much clear that those proposals
suffer from scalability and the absence of interoperability which
limit both groups of patients and treatment staff, and the L3
development is the best solution.
In conclusion, the SWOT analysis, shown in Table 20, provides a
omprehensive overview of the strengths, weaknesses, opportunities,
nd threats associated with implementing and adopting EHR systems
s one of the important applications within L3 blockchains.
5.2. Challenges
As clarified, the L3 blockchains also can be assumed as a subgroup
f blockchain technology. Hence, from L3s’ perspective, they have
similar (in basic aspects) but different (in-depth) challenges with L1s
and L2s (the blockchain triangle problems/challenges: decentraliza-
tion, security, and scalability Ricco, 2022; Yizhong et al., 2024). In
the following, we address three main categories of challenges of L3
lockchains without considering the scalability (possible solutions are
discussed in Section 5.3).
5.2.1. Being distributedly
‘‘Being distributedly’’ in the context of L3 blockchains and dis-
tributed bridges specifically refers to maintaining a decentralized ar-
hitecture that facilitates interoperability and secure communication
etween different blockchain networks. Here, we address three crit-
cal challenges in this domain: maintaining decentralized consensus,
managing decentralized trust, and ensuring decentralized scalability.
1. Maintaining Decentralized Consensus: Decentralized consensus is
the backbone of any distributed blockchain system (Bamakan
et al., 2020; Du et al., 2017). For L3 blockchains, achieving
consensus without relying on a central authority is complex
due to the involvement of multiple networks with potentially
different consensus mechanisms.
Designing decentralized consensus for several blockchains con-
nectivity is more complex than consensus on a single blockchain
and suffers challenges such as (1) heterogeneous consensus
mechanisms which should properly support L3 blockchains for
reconciling various consensus protocols (e.g., PoW, PoS, DPoS)
from the underlying L1 and L2 networks (Ephrati and Rosen-
schein, 1993; Chen et al., 2024a). (2) Considering latency and
synchronization for ensuring timely and synchronized updates
across multiple distributed networks can lead to latency issues
and potential consensus failures (Guo et al., 2024; Zhang et al.,
2023a).
Although we discuss possible solutions in Section 5.3, here we
briefly refer to state-of-the-art solutions. (1) Applying consensus
bridging protocols similar to the Polkadot44 network to use relay
44 https://www.allcryptowhitepapers.com/wp-content/uploads/2019/08/
olkaDotPaper.pdf.
26 
chains to achieve consensus across different blockchains is a
practical solution that can be improved in security and pri-
vacy aspects. (2) Using asynchronous Byzantine Fault Tolerance
(aBFT) algorithms which are used in Fantom’s Lachesis proto-
col45 assists manage consensus in asynchronous environments.
2. Managing Decentralized Trust: Decentralized trust involves ensur-
ing that trust is distributed across the network without central
intermediaries (Matt et al., 1996; Chun and Bavier, 2004). For
L3 systems, this includes managing cross-chain transactions and
validating data from different blockchains (Marcel, 2024; Xie
et al.,13
4. Scalability ......................................................................................................................................................................................................... 13
4.1. App-chain .............................................................................................................................................................................................. 13
4.2. Para-chain ............................................................................................................................................................................................. 14
4.2.1. Polkadot .................................................................................................................................................................................. 14
4.2.2. Kusama ................................................................................................................................................................................... 15
4.3. Side-chain.............................................................................................................................................................................................. 16
4.3.1. Polygon ................................................................................................................................................................................... 16
4.3.2. Loom network.......................................................................................................................................................................... 17
4.3.3. Gnosis ..................................................................................................................................................................................... 18
4.3.4. Skale ....................................................................................................................................................................................... 18
4.4. Super-chain............................................................................................................................................................................................ 18
4.5. Hyper-chain ........................................................................................................................................................................................... 19
5. Discussion and future directions.......................................................................................................................................................................... 20
5.1. Opportunities ......................................................................................................................................................................................... 20
5.1.1. Universal DeFi ......................................................................................................................................................................... 20
5.1.2. Education ................................................................................................................................................................................ 24
5.1.3. Healthcare systems ................................................................................................................................................................... 24
5.2. Challenges ............................................................................................................................................................................................. 26
5.2.1. Being distributedly ................................................................................................................................................................... 26
5.2.2. Security and privacy................................................................................................................................................................. 26
5.2.3. Throughput and reliability ........................................................................................................................................................ 27
5.3. Future directions .................................................................................................................................................................................... 28
5.3.1. Being distributedly ................................................................................................................................................................... 28
5.3.2. Security and privacy................................................................................................................................................................. 29
5.3.3. Throughput and reliability ........................................................................................................................................................ 31
6. Conclusion ........................................................................................................................................................................................................ 33
CRediT authorship contribution statement ........................................................................................................................................................... 33
Declaration of competing interest ........................................................................................................................................................................ 33
Acknowledgments .............................................................................................................................................................................................. 33
Data availability ................................................................................................................................................................................................ 33
References......................................................................................................................................................................................................... 33
d
l
f
s
1. Introduction
Layer 1 blockchains (L1s), the foundational frameworks of various
lockchain-based technologies, represent widely recognized constructs
n the field. Ethereum stands as the most renowned example of an L1,
ith other notable instances including Avalanche, and Fantom (Till
and Hartenstein, 2018) (it is noted that the Internet is assumed as
the zero layer of blockchain technology, or L0 blockchain is the same
nternet; in fact, L0 blockchain is the same infrastructure hardware
f the Internet). The proficient minds steering the development of
1s endeavor to address the primary quandary of blockchains, which
revolves around achieving an optimal equilibrium encompassing se-
curity, scalability, and decentralization (Ghassan, 2016; Ricco, 2022;
Yizhong et al., 2024). It is undeniable that the most optimal resolution
ngenders a wide spectrum of developers to embark upon launching
heir decentralized applications (DApps) on these platforms (Peilin
et al., 2023; Harjot, 2023).
Layer 2 projects (L2s) encompass the entirety of applications lever-
ging blockchain technology (Ankit et al., 2023; Lewis et al., 2020).
They primarily revolve around smart contracts associated with DApps.
mong these L2 endeavors, Decentralized Finance (DeFi) has emerged
s an exceptionally popular field over the past six years (Zetzsche et al.,
2020; Far et al., 2023b). It continues to captivate considerable attention
and interest within both industry and academia, as evidenced by sub-
stantial funds and investments being allocated towards its development.
ithin DeFi applications, stablecoins assume crucial roles, particularly
n lending scenarios, while wrapped tokens enable traders to explore a
ider range of trading pairs. Consequently,2023a; Bamakan and Far, 2024).
For example, (1) verification of cross-chain transactions or trans-
fer of data between multiple chains without a single point of
trust is challenging (Chen et al., 2020). Additionally, (2) Dif-
ferent blockchains have varying security assumptions, making it
challenging to create a universally trusted system (trust assump-
tions) (AlMarshoud et al., 2024; Liu et al., 2023a).
Using (1) cross-chain oracles or decentralized oracles like the
Chainlink project46 is a good solution that provides trusted data
feeds across multiple blockchains. Another possible solution (2)
Applying inter-blockchain communication protocol (IBC) (Essaid
et al., 2023; Dinesha and Patil, 2023) which is used by the Cos-
mos47 facilitates secure and reliable cross-chain communication.
3. Ensuring Decentralized Scalability: Decentralized scalability ad-
dresses the need to support a growing number of transactions
and data without central bottlenecks, maintaining efficiency and
performance (Vaudenay, 2020; Ahlqvist et al., 2022).
In this issue, (1) resource management to provide efficient com-
putational and storage resources across distributed networks
is essential. Moreover, (2) considering the throughput of the
transactions without compromising decentralization is one of the
important challenges which should be solved.
In response to the previous paragraph, (1) L2 scaling solu-
tions techniques such as rollups48 (e.g., Optimistic Rollups, zk-
Rollups) improve scalability while maintaining decentralization
(see Section 2.3). (2) Sharding methods, as another L2 solu-
tion which was Implemented in the Ethereum 2.0 project49
distributed the network load across multiple shards.
5.2.2. Security and privacy
In the context of individuals or DAOs working different project
(e.g., scientific, financial, etc.) across different blockchains, security
and privacy are paramount. When transferring data between
blockchains through L3 blockchains, they face significant challenges
related to teams/individuals privacy, data confidentiality, and au-
thentication methods. The following items provide a comprehensive
overview of these challenges, detailing how they occur. It incorporates
advanced cryptographic techniques and formulas to address these
specific challenges.
1. Privacy aspects: Individuals or DAO-based teams often consist of
members from multiple organizations, each bringing proprietary
knowledge and sensitive information (Far and Bamakan, 2022).
When they transfer data between blockchains through L3s, the
metadata associated with the transactions, such as the identities
of the /individuals/teams, the number of participants, and their
affiliations, can be exposed. This exposure can lead to targeted
attacks, corporate espionage, and breaches of confidentiality
45 https://fantom.foundation/fantomResearchPapers.
46 Whitepaper v-1: https://research.chain.link/whitepaper-v1.pdf.
47 https://whitepaper.io/coin/cosmos.
48 https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/
4698.
49 https://unlock-protocol.github.io/ethhub/ethereum-roadmap/ethereum-
2.0/eth-2.0-phases/.
https://www.allcryptowhitepapers.com/wp-content/uploads/2019/08/PolkaDotPaper.pdf
https://www.allcryptowhitepapers.com/wp-content/uploads/2019/08/PolkaDotPaper.pdf
https://fantom.foundation/fantomResearchPapers
https://research.chain.link/whitepaper-v1.pdf
https://whitepaper.io/coin/cosmos
https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698
https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698
https://unlock-protocol.github.io/ethhub/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/
https://unlock-protocol.github.io/ethhub/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/
S. Banaeian Far and S.M. Hosseini Bamakan
a
m
Journal of Network and Computer Applications 233 (2025) 104044 
agreements (Zhao et al., 2023; Zhang et al., 2022; Wang et al.,
2022b). The transparency of blockchain networks exacerbates
this risk, as transaction data is often publicly accessible. L3
blockchains should protect this information to maintain trust
and collaboration integrity.
As a general solution, homomorphic encryption scheme allows
computations on encrypted data without decrypting it, preserv-
ing privacy during the computation process (Gentry, 2009).
The Paillier cryptosystem, an additive homomorphic encryption
scheme, operates as 𝐸(𝑚1).𝐸(𝑚2) = 𝐸(𝑚1 + 𝑚2) 𝑚𝑜𝑑 𝑛2, where
𝐸(𝑚) is the encryption of message 𝑚, and 𝑛 is a large composite
number (the product of two large primes, 𝑝 and 𝑞). This property
is beneficial for DAOs to perform collaborative computations
on private data without revealing the data itself. Regarding the
generic presentation, the detailed encryption and decryption of
the Paillier cryptosystem formulas are 𝑐 = 𝐸(𝑚) = (1 +𝑚𝑛).𝑟𝑛 𝑚𝑜𝑑
𝑛2 and 𝐷(𝑐) = (𝑐𝑑 mod 𝑛2)−1
𝑛 .𝜇 𝑚𝑜𝑑 𝑛 where 𝑟 is a random number
in 𝚉∗𝑛, 𝑑 is the private key, and 𝜇 is the modular multiplicative
inverse (Paillier, 1999).
ZKP-based solutions enable the prover to convince the verifier
that a statement is true without revealing any underlying in-
formation (Lavaur et al., 2022, 2023; Banaeian Far and Rad,
2021). zk-SNARKs are a notable type of ZKPs used for scalable
verification described in Section 2.2 (Luong and Park, 2022).
All in all, although the described possible solutions seem good,
distributed implementation of them, where no trusted party
exists, is challenging. Therefore, the main challenge in this
items is known to removing central authorities for coordinating
L3s which soundly executes L3s connections (Simmons, 1994;
Syverson, 1991).
2. Data confidentiality: Every information or data which involve
the exchange of highly sensitive data, including proprietary
algorithms, financial data, sensor data, and business strategies.
If this data is intercepted or improperly accessed, it can lead to
significant financial losses and competitive disadvantages (Far
et al., 2023a; Banaeian Far et al., 2023). L3 blockchains need
to ensure robust data confidentiality mechanisms to prevent
unauthorized access and data breaches.
When small number of users/teams want to share confidential
data, symmetric encryption provide much assistance since it
utilizes a single key for both encryption and decryption for
confidentiality through the shared secret keys. The Advanced
Encryption Standard (AES) is the most widely used symmetric
encryption algorithm, with the generic operation as 𝐶 = 𝐸𝑘(𝑃 )
and 𝑃 = 𝐷𝑘(𝐶), where 𝐸𝑘 and 𝐷𝑘 are the encryption and de-
cryption functions, respectively, 𝑃 is the plaintext, and 𝐶 is the
ciphertext. AES operates on blocks of 128 bits using keys of 128,
192, or 256 bits, employing multiple rounds of substitution and
permutation operations to ensure the most excellent confusion
and diffusion (Rijmen and Daemen, 2001).
It should be said that encryption is not the single and simple way
keeping information confidential. This way suffers several chal-
lenges such as asymmetric key agreement (how can distributedly
establish key pairs?), the big volume of information, secret key
comptonization, key management, and many other challenges
that should be solved provably.
3. Authentication (if mandatory due to regulation): Authenticating
both data and entities ensures the integrity and legitimacy of the
information and the participants. Without strong authentication
mechanisms, individuals or DAO-based teams are susceptible to
data tampering, impersonation, and unauthorized access, un-
dermining the trust and accuracy of the transferred informa-
tion (Yeoh, 2017; Lianos et al., 2019; Akanfe et al., 2024; Luna
et al., 2024; Far and Bamakan, 2022).
Applying digital signatures are a method to verify the authen-
ticity of a message or document, ensuring it was created by
27 
a known sender and not altered in transit. The Elliptic Curve
Digital Signature Algorithm (ECDSA) (Johnson et al., 2001)
is a widely adopted digital signature scheme, which operates
with two main functionsof 𝑆 𝑖𝑔 𝑛𝑎𝑡𝑢𝑟𝑒(𝑟, 𝑠) = 𝑠𝑖𝑔 𝑛(𝑘, 𝑚) and
𝑉 𝑒𝑟𝑖𝑓 𝑖𝑐 𝑎𝑡𝑖𝑜𝑛(𝑣) = 𝑣𝑒𝑟𝑖𝑓 𝑦(𝑄, 𝑚, (𝑟, 𝑠)), where 𝑘 is the private key,
𝑄 is the public key, 𝑚 is the message, and (𝑟, 𝑠) are the sig-
nature components. ECDSA leverages the properties of elliptic
curves over finite fields to provide equivalent security to RSA
but with smaller key sizes. A Certificate Authority (CA) verifies
the identity of the certificate holder and signs the certificate,
creating a chain of trust that can be verified by anyone using the
CA’s public key. However, the absence of a distributed Public
Key Infrastructure (dPKI) (Kfoury and Khoury, 2018; Schaerer
et al., 2022; Papageorgiou et al., 2020; Rashid et al., 2021),
as a framework for managing digital certificates and public-key
encryption with relying on no party is essential blockchain-based
system and the coordination of L3s. The dPKI can ensure the
generated public key belongs to the entity it claims to represent
through the use of digital certificates.
5.2.3. Throughput and reliability
Throughput and reliability are critical factors for the effective op-
eration of L3s and distributed bridges in the context of decentralized
data sharing across multiple blockchains. Throughput refers to the rate
t which data is processed and transferred within the network, typically
easured in transactions per second (𝑇 𝑃 𝑆) (Luo et al., 2024; Xu et al.,
2024; Li and Zhao, 2024). Higher throughput ensures that the system
can handle a large volume of data and transactions efficiently. Relia-
bility, on the other hand, concerns the consistency and dependability
of the data transfer process, ensuring that data is delivered accurately
and on time without loss or corruption. Both factors are essential for
maintaining the integrity, performance, and user trust in decentralized
systems.
1. Scalability and Network Congestion: Scalability issues arise when
the network’s capacity to process transactions does not grow pro-
portionally with the increase in user activity and data volume.
Network congestion can lead to significant delays, increased
transaction costs, and decreased throughput (Imani Rad and Far,
2023; Huang et al., 2024; Duan et al., 2023).
In L3s, which operate on top of base L1 and L2, data has to tra-
verse multiple layers. Each layer might have its own throughput
limitations, compounding the scalability issues. Layered archi-
tecture of blockchain, as depicted in Fig. 1, same-layer coor-
dination and preparing maximum unifying the same layer of
blockchains (e.g., L2 of Blockchain #1 with L2 of Blockchain
#2) is one of the primary work for this challenge (Abdella
et al., 2024; Datta et al., 2024). Moreover, methods described
in Section 2.3 can be applied as good solution if improved to be
more distributed.
As another solution, managing transactions across different
blockchains also involves complex coordination mechanisms
which can introduce latency. Hence, atomic swaps or other
interoperability protocols require secure and synchronized com-
munication, often slowed by network conditions and consensus
mechanisms.
While Sharding (dividing the blockchain into smaller, more man-
ageable parts) and parallel transaction processing can enhance
throughput (e.g., Sharding and parallelization methods), they
also introduce challenges in maintaining data consistency and
reliability across shards, especially when synchronizing state
changes in real-time.
2. Consensus Mechanism Efficiency: The consensus mechanisms used
in blockchains (such as Proof of Work, Proof of Stake, etc.) are
fundamental to ensuring data reliability but can significantly
impact throughput (Xie et al., 2023b; Sisi et al., 2023).
S. Banaeian Far and S.M. Hosseini Bamakan
c
s
i
l
d
a
i
e
f
(
o
c
o
p
Journal of Network and Computer Applications 233 (2025) 104044 
Although PoW mechanism provides high security, its intensive
computational requirements limit throughput and lead to slower
transaction times. For L3s relying on PoW-based blockchains,
this creates a bottleneck (Lei et al., 2022; Zhu et al., 2023;
Wang et al., 2020a). On another side, PoS and its derivatives
(like Delegated PoS, Byzantine Fault Tolerance) offer improved
throughput over PoW. However, the effectiveness of these mech-
anisms in L3s depends on the underlying blockchain’s ability
to quickly reach consensus without compromising security (see
Table 4 for the comprehensive comparison). Implementing hy-
brid consensus mechanisms can potentially balance through-
put and reliability (Wu et al., 2020; Liu et al., 2020). For
example, combining PoW for block creation and PoS for block
validation can enhance efficiency, but this also introduces com-
plexity in consensus protocols, which can affect overall system
performance.
3. Data Integrity and Error Handling: Ensuring data integrity and
handling errors in a decentralized and distributed environment is
inherently challenging. Any loss, corruption, or mismanagement
of data can severely impact reliability (Huang et al., 2020;
Banaeian Far et al., 2024).
Implementing redundancy mechanisms, such as multiple copies
of data across different nodes, can enhance reliability. However,
this redundancy must be managed efficiently to avoid excessive
overhead that can reduce throughput (Jiang et al., 2019; Liu
et al., 2023b). In fact. selecting best trad-off between enhancing
reliability and paying cost and time is important.
Advanced cryptographic techniques and error correction codes
can detect and correct errors in data transmission. For example,
Merkle trees are used to ensure data integrity (for error detec-
tion), but the overhead of these cryptographic operations can
impact throughput (Liu et al., 2023b).
As the final proposal, designing fault-tolerant systems that can
continue to operate effectively even in the presence of node
failures or network partitions is critical. Techniques such as BFT
can provide high reliability but at the cost of increased commu-
nication overhead, affecting throughput (Fan et al., 2021).
All in all, throughput and reliability in L3s are interdependent and
rucial for the functionality of decentralized data sharing. Addressing
calability, optimizing consensus mechanisms, and ensuring robust data
ntegrity and error handling are fundamental to overcoming the chal-
enges and achieving a balance between high throughput and reliable
ata operations. Hence, it is better to select the best way to develop L3
fter understanding main goals, costs, and measuring all potentials.
5.3. Future directions
Regarding the challenges mentioned above, future directions of the
L3 blockchains, as a newly-emerged topic, can deeply be assumed in-
novative solutions for the aforementioned challenges. In the following,
three categories of solutions are listed.50
5.3.1. Being distributedly
The L3s blockchains or distributed bridges, play a pivotal role
n enhancing scalability, interoperability, and security of blockchain
cosystems. Table 21 provides a brief comparison between three offered
proposals.
Before the future directions listed below, we discuss the used stan-
dards and criteria for rating cells in Table 21.
50 Note: It is highlighted that the following suggestion are brief guidelines
or the future works, and they are not fully complete for implementation
everyone wants to follow this field should find all details, analyzing meth-
ds, and learn many more knowledge about networking, cryptography, and
ommunication theories).
28 
• Decentralization: High: The method widely distributes control
across participants, preventing centralization.
• Interoperability: Very High: The method is designed to work seam-
lessly across different blockchains. Moderate: The method can be
adapted for cross-chain use, but it is not its primary function.
• Security: Very High: Provides robust protection against unautho-
rized access and tampering. High: Offers strong security, though
implementation complexity may introduce risks.
• Scalability: High: Can efficiently handle growthby distributing
tasks across participants. Moderate: May face challenges scaling
due to complexity and cross-network coordination.
A key aspect of L3 development is achieving a high degree of
decentralization. This article suggests three advanced cryptographic
tools and networking techniques to achieve this as one of the aspects
f future directions of L3: cross-consensus mechanisms, secret sharing
rotocols, and threshold schemes.
1. Cross-Consensus Mechanisms: Cross-consensus mechanisms en-
sure that different blockchain networks can validate transactions
and state changes based on a unified protocol, enhancing inter-
operability and decentralization (Bamakan et al., 2020; Du et al.,
2017). We offer two proposal to be used as future works:
• Using Hybrid Consensus Algorithm: Combine the strengths of
PoW, PoS, and BFT to create a hybrid consensus algorithm
that can operate across multiple blockchains (Wu et al.,
2020; Liu et al., 2020). The equation 𝐶𝐻 𝑦𝑏𝑟𝑖𝑑 = 𝑤1.𝐶𝑃 𝑜𝑊 +
𝑤2.𝐶𝑃 𝑜𝑆+ 𝑤3.𝐶𝐵 𝐹 𝑃+ is the basic formula – can be ex-
panded – where 𝑤1, 𝑤2, and 𝑤3 are weights assigned to
each consensus component based on network conditions
and security requirements.
• Applying IBC Protocol (Essaid et al., 2023; Dinesha and Patil,
2023): Implement IBC to facilitate message passing and
transaction validation across different blockchains. In the
IBC protocol, the 𝐼 𝐵 𝐶(𝑡) = 𝛴𝑛
𝑖=1𝐻(𝑇𝑖, 𝑃𝑖) is the main
formula, where 𝑇𝑖 is the transaction, 𝑃𝑖 is the proof, and
𝐻 is a hash function ensuring the integrity and order of
cross-chain transactions.
As a guideline for easy implementation (1) use the Gossamer
protocol to achieve cross-consensus validation, and (2) desig-
nate releasers to facilitate communication and consensus across
blockchains.
2. Secret sharing protocols: SSPs distribute a secret among multiple
parties, requiring collaboration to reconstruct the secret, thereby
enhancing security and decentralization. Two well-known SSP
are addressed in the following which could be considered to be
used in the future blockchains.
• Shamir’s Secret Sharing (Shamir, 1979): Use Shamir’s secret
sharing scheme to split the private key or critical data
into 𝑛 shares, with a threshold 𝑘 required to reconstruct
the secret. In the Shamir’s secret sharing scheme, 𝑆(.) as a
polynomial sentence is defined as 𝑆(𝑥) = 𝑎0 + 𝑎1𝑥 + 𝑎2𝑥2+
... 𝑎𝑘−1𝑥𝑘−1 𝑚𝑜𝑑 𝑝, where 𝑎0 is the secret and 𝑝 is a prime
number.
• Verifiable Secret Sharing (VSS) (Rabin and Ben-Or, 1989):
The VSS is the enhanced version of Shamir’s secret sharing
with verifiable proofs to ensure the integrity of the shares.
In the VSS, 𝑉 𝑆 𝑆 = 𝑔𝑆(𝑥) 𝑚𝑜𝑑 𝑝, where 𝑔 is a generator
of a cyclic group, ensuring that each share can be verified
without revealing the secret.
As a guideline for easy implementation (1) Implement Dis-
tributed Key Generation (DKG) protocols to securely generate
and distribute shares, and (2) Use Pedersen commitments to
ensure the secrecy and integrity of the shares.
S. Banaeian Far and S.M. Hosseini Bamakan
a
c
d
h
c
p
u
c
H
Journal of Network and Computer Applications 233 (2025) 104044 
Table 21
A general comparison between three offered proposals in Section 5.3.1 (Being distributedly).
Item Cross-consensus mechanisms Secret sharing protocols Threshold schemes
Decentralization High High High
Interoperability Very high Moderate Moderate
Security High Very high Very high
Scalability Moderate High High
Implementation complexity High Moderate High
Performance overhead Moderate Low Low
Fault tolerance Moderate Very high Very high
Cryptographic robustness High Very high Very high
Real-world usage Emerging Well-established Emerging
Example implementations Gossamer, IBC protocol Shamir’s secret sharing, VSS MPC, BLS signatures
3. Threshold schemes: Threshold schemes allow a subset of parties to
perform a cryptographic operation, enhancing security and fault
tolerance (Far et al., 2023a; Banaeian Far et al., 2024). In this
regard, we address two famous scheme to help and manual for
applications in the near horizon:
• Threshold Signatures (Shoup, 2000; Harn, 1994): Implement
threshold signature schemes where a predefined number
of participants, who are assumed as the participants of the
distributed bridge, can jointly sign a message. Regarding
the Lagrange interpolation the equation 𝜎 = 𝜋𝑡
𝑖=1𝜎
𝜆𝑖
𝑖 𝑚𝑜𝑑
𝑝 is the main assumption, where 𝜎𝑖s are partial signatures
and 𝜆𝑖s are Lagrange coefficients.
• Threshold Encryption (Delerablée and Pointcheval, 2008;
Boneh et al., 2018): As with threshold signature, encrypt-
ing data such that only a threshold number of parties
can decrypt it is possible. The generic presentation of a
threshold encryption algorithm is 𝑐 = (𝑔𝑟, 𝑀 .ℎ𝑟), where 𝑐 is
the ciphertext, 𝑀 is the message, 𝑔 and ℎ are generators,
and 𝑟 is a random value selected by the encryptor.
As a brief guideline for easy implementation (1) Use Multi-Party
Computation (MPC) protocols to collaboratively compute cryp-
tographic functions (Goldreich, 1998; Du and Atallah, 2001),
and (2) Implement Boneh–Lynn–Shacham (BLS) (Boneh et al.,
2004) threshold signatures for efficient and secure multi-party
signing.
5.3.2. Security and privacy
Undoubtedly, security and privacy is the most essential aspect of
ll information systems, and it is not far from L3. Regarding addressed
hallenges in Section 5.2.2, in the following we identify neat future
irection that can improve security and privacy aspects in L3 (it is
ighlighted that each solution should be chosen based on the spe-
ific requirements of the L3 blockchain, balancing between security,
rivacy, and computational efficiency).
Before the description of the proposals, we present our criteria and
sed standards. To determine the qualitative descriptors such as ‘‘Min-
imal’’, ‘‘Low’’, ‘‘Medium’’, ‘‘High’’, etc., in the context of Table 22 for
ryptographic techniques, we use a combination of factors, including
theoretical efficiency, practical benchmarks, and industry standards.
ere’s how each descriptor is defined:
• Time Goals and Normalization of Sizes
– Time Goals: Verification Speed is often measured in terms
of milliseconds to seconds, depending on the application.
For example, ‘‘Fast’’ verification in zk-SNARKs might be on
the order of milliseconds, while ‘‘Slow’’ in interactive ZKPs
could take seconds or longer.
– Size Normalization: Proof Size can be normalized based on
the number of bits or kilobytes, depending on the applica-
tion. For example: Small proof size: Less than 1 kB, Medium
proof size: 1 kB to 10 kB, and Large proof size: Greater than
10 kB.
29 
• Setup Complexity: Minimal: The setup requires little to no spe-
cial configuration, typically involving only basic cryptographic
primitives. Example: General ZKPs without trusted setup. Low:
The setup is straightforward, possibly requiring the generation
of public parameters but no extensive infrastructure or trusted
setup. Example: Simple encryption schemes. Medium: Requires a
more involved setup, potentially involving trusted entities or com-
plex initialization procedures. Example: Group signatures. High:
Involves extensive pre-computation, trusted setups, or specialized
hardware. Example: zk-SNARKs with a trusted setup phase.
• Verification Speed: Slow: Verification time is long, often linear
or worse in the size of the input or proof. Example: General
ZKPs with interactive protocols. Medium: Verification is more
efficient but may still be substantial for large inputs. Example:
FHE operations. Fast: Verification is highly optimized and can be
done in near constant time, independent of input size. Example:
zk-SNARKs.
• Proof Size: Small: Proofs are compact, typically logarithmic or
constant in size relative to the statement being proven. Example:
zk-SNARKs. Medium: Proofs are moderately sized, scaling linearly
with the complexity of the statement. Example: General ZKPs.
Large: Proofs can be large, possibly quadratic or worse in size.Example: zk-STARKs.
• Trust Assumptions: Minimal: Requires minimal assumptions, such
as no need for trusted third parties or special setups. Example:
zk-STARKs. Moderate: Requires some trust in external entities
or setup, but mitigates these assumptions through cryptographic
techniques. Example: Anonymous authentication with a group
manager. High: Requires significant trust, such as a trusted setup
phase where security depends on secrecy during setup. Example:
zk-SNARKs.
• Scalability: Low: The method does not scale well with increas-
ing data size or complexity, often leading to exponential in-
creases in computation or storage. Example: Basic interactive
ZKPs. Medium: Scales reasonably well but may still encounter
performance bottlenecks with very large data. Example: PHE.
High: Designed to handle large-scale applications efficiently, with
near-linear or logarithmic scaling. Example: zk-STARKs.
• Privacy Level: Low: Provides basic privacy protections but may ex-
pose some metadata or require revealing certain information. Ex-
ample: Basic authentication protocols. Medium: Enhances privacy
but may still have some vulnerabilities, such as possible inference
from public parameters. Example: Identity-based authentication.
High: Provides strong privacy guarantees, such as full anonymity
and non-disclosure of the underlying data. Example: zk-SNARKs,
zk-STARKs.
• Cryptographic Strength: Moderate: Based on standard
cryptographic assumptions but may be vulnerable to emerging
threats or quantum attacks. Example: Older public-key cryptosys-
tems. High: Built on robust, well-studied cryptographic principles
and resistant to most known attacks. Example: zk-SNARKs. Very
High: Incorporates advanced techniques or quantum-resistant
algorithms, offering the highest level of security. Example: zk-
STARKs.
S. Banaeian Far and S.M. Hosseini Bamakan
a
b
e
Journal of Network and Computer Applications 233 (2025) 104044 
Table 22
A general comparison between offered proposals in Section 5.3.2 (Security and privacy).
Feature Applying ZKPs Using homomorphic
calculations
Implementing authentication methods
General
ZKP
zk-SNARKs zk-STARKs FHE PHE Anonymous
Auth
Mutual
Auth
Auth w/o
Third Party
Identity-
based
Auth
Role-
based
Auth
Setup complexity Low High Medium High Medium Medium Medium Medium High Medium
Verification
speed
Slow Fast Fast Slow Fast Fast Fast Fast Fast Fast
Proof size Medium Small Large Medium Small Small Small Small Medium Small
Trust
assumptions
Minimal Trusted
Setup
None None None Group
Manager
None None Trusted
Authority
None
Scalability Low High High Low Medium High High High Medium High
Privacy level High High High High High High Medium Medium High Medium
Cryptographic
strength
High High Very high Very high High High High High High Medium
Implementation
cost
Medium High High Very high High Medium Medium Medium High Medium
Interoperability High Medium Medium Low Medium High High High Medium High
• Implementation Cost: Low: Requires minimal computational re-
sources, straightforward to implement. Example: Simple public-
key cryptography. Medium: Requires more resources, such as
memory or processing power, but still feasible for most applica-
tions. Example: Anonymous authentication. High: Demands sig-
nificant resources, both in terms of computation and infrastruc-
ture. Example: The FHE. Very High: Involves cutting-edge tech-
nology or extensive computational requirements, often reserved
for specialized applications. Example: zk-SNARKs/FHE.
• Interoperability: Low: Difficult to integrate with other systems or
protocols, requiring significant modifications. Example: Propri-
etary cryptographic systems. Medium: Can be integrated with
some effort but may face compatibility issues. Example: Role-
based authentication with custom roles. High: Designed to work
seamlessly with a wide range of systems and protocols. Example:
Public-key infrastructures, standard cryptographic libraries.
Table 22 provides a brief comparison between three offered propos-
ls. The normalization helps in comparing across different technologies
y setting common benchmarks based on practical applications and
xpected performance.
1. Applying ZKPs: ZKPs allow one party (the prover) to prove to an-
other party (the verifier) that they know a value without reveal-
ing the value itself. This is crucial for privacy in L3 blockchains.
As discussed in Section 2.2 and compared in Table 5, there
are three main categories of ZKPs, including general ZKP, zk-
SNARKs, and zk-STARKs. In the following, we provide a brief
formula-based definition of each to facilizing who want to follow
this idea as future work.
• General ZKP (Goldreich and Oren, 1994; Fiege et al., 1987):
The general ZKP is an interactive protocol in which both
prover and verifier should connect. The general ZKPs de-
fined in the three following steps.
(𝑖) Setup: Public parameters 𝑝𝑝 are generated, (𝑖𝑖) Proving:
Prover 𝑃 generates a proof 𝜋 that they know a secret 𝑤
such that 𝑅(𝑥, 𝑤) = 1, where 𝑥 is public, and (𝑖𝑖𝑖) Verifying:
Verifier 𝑉 checks the proof 𝜋 by running 𝑉 (𝑥, 𝜋 , 𝑝𝑝) which
outputs true (1) or false (0).
Regarding above equations, general ZKPs involve an inter-
active protocol where the prover demonstrates knowledge
of a secret value without revealing it. The setup gener-
ates public parameters, and during the proving phase, the
prover creates a proof 𝜋 that confirms they know a secret
w such that 𝑅(𝑥, 𝑤) = 1, where 𝑥 is a public value. The
30 
verifier then uses 𝑉 (𝑥, 𝜋 , 𝑝𝑝) to check the validity of the
proof. This process ensures that the verifier is convinced of
the prover’s knowledge without learning the secret itself.
The interaction between the prover and verifier, along
with the iterative nature of the protocol, enhances security
but may introduce complexity in terms of communication
overhead and proof verification time.
• zk-SNARK (Luong and Park, 2022): The zk-SNARK proto-
cols are a little different which they set via the determined
common reference string (CRS) (Pass, 2003) in the four
below steps.
(𝑖) Setup: Trusted setup generates the CRS, (𝑖𝑖) Proving:
Prover P computes 𝜋 using the CRS and the secret witness
𝑤 for 𝑅(𝑥, 𝑤) = 1, (𝑖𝑖𝑖) Verifying: Verifier V verifies 𝜋 using
a verification key derived from CRS, and (𝑖𝑣) Formula:
Proof system can be expressed as 𝜋 = 𝑃 𝑟𝑜𝑣𝑒(𝐶 𝑅𝑆 , 𝑥, 𝑤) and
verification as 𝑉 𝑒𝑟𝑖𝑓 𝑦(𝑣𝑘, 𝑥, 𝜋).
zk-SNARKs are a type of non-interactive zero-knowledge
proof that require a trusted setup phase to generate a
CRS. The prover uses the CRS and a secret witness 𝑤 to
create a succinct proof 𝜋 that a particular statement is true
(i.e., 𝑅(𝑥, 𝑤) = 1). The verifier can then quickly check
the proof using a verification key derived from the CRS.
The formulas 𝜋 = 𝑃 𝑟𝑜𝑣𝑒(𝐶 𝑅𝑆 , 𝜋 , 𝑤) and 𝑉 𝑒𝑟𝑖𝑓 𝑦(𝑣𝑘, 𝑥, 𝜋)
encapsulate the efficiency and succinctness of zk-SNARKs,
making them ideal for applications requiring fast verifica-
tion times and minimal proof sizes, despite the need for a
trusted setup.
• zk-STARK (Ben-Sasson et al., 2019): Against zk-SNARKs, zk-
STARKs need no trusted setup, and it makes the initial
process faster. Hence, this type of ZKPs seems more suit-
able to use in the blockchain-based systems and L3s. The
four general steps of zk-STARKs are defined as follows.
(𝑖) Setup: No trusted setup required. Uses publicly verifi-
able randomness, (𝑖𝑖) Proving: Uses polynomial commit-
ments over a finite field. (𝑖𝑖𝑖) Verifying: Verifier checks
that the commitments satisfy the polynomial equations.
(𝑖𝑣) Formula: STARK proof can be represented as 𝜋 =
𝑆 𝑇 𝐴𝑅𝐾𝑃 𝑟𝑜𝑣𝑒(𝑝𝑝, 𝑥, 𝑤) and verification as 𝑆 𝑇 𝐴𝑅𝐾𝑉 𝑒𝑟𝑖𝑓 𝑦
(𝑝𝑝, 𝑥, 𝜋).
The zk-STARKs offer scalable and transparent ZKPs with-
out the need for a trusted setup. They leverage poly-
nomial commitments over a finite field to create proofs
that are both efficient to generate and verify. The prover
S. Banaeian Far and S.M. HosseiniBamakan
-
v
t
m
a
s
e
o
r
p
p
t
d
b
Journal of Network and Computer Applications 233 (2025) 104044 
uses 𝑆 𝑇 𝐴𝑅𝐾𝑃 𝑟𝑜𝑣𝑒(𝑝𝑝, 𝑥, 𝑤) to produce a proof 𝜋, while the
verifier checks its validity with 𝑆 𝑇 𝐴𝑅𝐾𝑉 𝑒𝑟𝑖𝑓 𝑦(𝑝𝑝, 𝑥, 𝜋). The
transparency of zk-STARKs, due to their reliance on pub-
licly verifiable randomness instead of a trusted setup, en-
hances their security. Additionally, their scalability ensures
that they remain practical even as the size and complexity
of the data grow, although this may result in larger proof
sizes compared to zk-SNARKs.
2. Using homomorphic calculations (Gentry, 2009): Homomorphic
encryption allows computations on encrypted data without de-
cryption, preserving privacy. There are two aspects for homo-
morphic encryption schemes that can be applied in multiple
chain calculations.
• Partially Homomorphic Encryption (PHE) (Shafagh et al.,
2017): In PHEs, only one operation on ciphertexts make
an operation on plaintexts (the same operation or another
one). In the following, we provide the Paillier encryption
system as a well-known additive homomorphism model
(e.g., RSA Rivest et al., 1983 and ElGamal ElGamal, 1985
are also PHEs).
(𝑖) The encryption algorithm is 𝑐 = 𝐸 𝑛𝑐(𝑝𝑘, 𝑚) = 𝑔𝑚.𝑟𝑛
𝑚𝑜𝑑 𝑛2, and (𝑖𝑖) The addition method is 𝑐1. 𝑐2 𝑚𝑜𝑑 𝑛2 =
𝐸 𝑛𝑐(𝑝𝑘, 𝑚1 + 𝑚2).
• Fully Homomorphic Encryption (FHE)
(Mahato and Chakraborty, 2023): In FHEs, the same calcu-
lations on the ciphertexts are caused on plaintexts (e.g., mul
tiplication on ciphers make multiplication on plains, and
the ⊕ on ciphertexts make the XoR operation on plain-
texts). The FHEs are generally defined in the five steps
provided as follows.
(𝑖) Setup: Generate public–private key pair (𝑝𝑘, 𝑠𝑘), (𝑖𝑖) En-
cryption: Encrypt data 𝑚 as 𝑐 = 𝐸 𝑛𝑐(𝑝𝑘, 𝑚), (𝑖𝑖𝑖) Computa-
tion: Perform operation ⊕ on ciphertexts: 𝑐′ = 𝐸 𝑣𝑎𝑙(𝑝𝑘, ⊕,
𝑐1, 𝑐2), (𝑖𝑣) Decryption: Decrypt 𝑐′ to get the result 𝑚′ =
𝐷 𝑒𝑐(𝑠𝑘, 𝑐′), and (𝑣) Formula: For the function 𝑓 , 𝐷 𝑒𝑐(𝑠𝑘,
𝐸 𝑣𝑎𝑙(𝑝𝑘, 𝑓 , 𝐸 𝑛𝑐(𝑝𝑘, 𝑚1), 𝐸 𝑛𝑐(𝑝𝑘, 𝑚2))) = 𝑓 (𝑚1, 𝑚2).
As a brief guideline for easy implementation (1) Use libraries like
TFHE or Microsoft SEAL for direct implementation, (2) Combine
FHE with secure MPC for efficiency, and (3) Use leveled FHE for
specific depth circuits.
3. Implementing authentication methods (if mandatory due to regula-
tion): Authentication is crucial for security in L3 blockchains.
Advanced methods provide privacy and trust without third par-
ties (Yeoh, 2017; Lianos et al., 2019; Akanfe et al., 2024; Luna
et al., 2024; Far and Bamakan, 2022). Many types of authen-
tication exist that based on requirement and network accesses
can be applied for applying L3s as future practical or academic
works.
It is highlighted that due to the distributedness of L3s, there
should not to use one party/entity for executing the protocol, but
trade-off between the L3’s distributedness and the authentication
protocol’s cost and delay is also a critical issue. Several impor-
tant authentication methods are (1) anonymous authentication
(by using ZKPs or ZK-based signatures Lu et al., 2008; Baum
et al., 2023), (2) mutual authentication (challenge-response pro-
tocols is suggested Ryu et al., 2022; Al-Maliki and Al-Assam,
2021), (3) authentication without third party (dPKI-based sig-
nature is a suitable method Schaerer et al., 2022), and (4)
identity-based authentication (certificateless identity-based sig-
natures seem a good choice for using Gao et al., 2021; Srivastava
et al., 2022), etc.
As a summary, ZKPs offer robust privacy with varying setup and
erification costs; Homomorphic encryption ensures secure computa-
ions but is computationally intensive; And advanced Authentication
ethods enhance security and privacy, with trade-offs in complexity
nd trust assumptions.
31 
5.3.3. Throughput and reliability
L3 blockchains, or distributed bridges, play a crucial role in en-
hancing blockchain scalability and interoperability. Their main goal
is to maintain high throughput and reliability. In this section, we
focus on three main innovative approaches to developing L3s with
more throughput and reliability: layered architecture, relay chains, and
the use of Merkle trees with Proof of Existence (PoE) mechanisms.
We also present Table 23 comprehensive table comparing suggested
olutions based on various parameters to evaluate their effectiveness
in enhancing throughput and reliability to enable developers for easy
selecting better method.
In the following, we first describe our standards and criteria for
Low, Moderate, and High that have filled Table 23. These classifications
are based on industry standards, technical benchmarks, and practical
considerations within blockchain technology.
• Throughput: High: Supports thousands of TPS. Moderate: Supports
hundreds of TPS. Low: Supports tens of TPS or lower.
• Reliability: High: Near 100% uptime with strong consensus. Mod-
erate: Generally reliable but with occasional disruptions. Low:
Prone to frequent disruptions or inconsistent transaction finality.
• Scalability: High: Scales well with minimal performance loss.
Moderate: Scales to an extent but with bottlenecks. Low: Limited
scalability, performance degrades with growth.
• Interoperability: High: Seamless cross-chain interactions. Moder-
ate: Some interoperability, but with limitations. Low: Mostly
isolated, limited cross-chain communication.
• Security: High: Advanced cryptography and robust against attacks.
Moderate: Solid security but with some vulnerabilities. Low:
Susceptible to common attacks, lacks comprehensive security.
• Complexity: High: Involves complex, resource-intensive imple-
mentation. Moderate: Manageable complexity, requires moderate
expertise. Low: Simple, easy to implement and maintain.
• Implementation Cost: High: Significant resources required. Mod-
erate: Moderate investment needed. Low: Minimal cost and re-
sources required.
• Maintenance: High: Frequent updates and monitoring needed.
Moderate: Periodic maintenance required. Low: Minimal ongoing
effort needed.
The classification into ‘‘Low’’, ‘‘Moderate’’, and ‘‘High’’ was based on
xisting benchmarks in blockchain technology, such as the performance
f established systems (like Bitcoin, Ethereum, Polkadot), academic
esearch on blockchain scalability and security, and the practical ex-
eriences of developers in the field. The comparison is designed to
rovide a relative ranking rather than absolute values, making it easier
o compare different approaches under similar conditions. We also will
elve into the technical solutions for each approach in such a way that
e a good guideline for who want to work in this field.
1. Layered architecture (coordinating with the same layer): Imple-
menting a layered architecture where each layer coordinates
with nodes within the same layer to distribute the load evenly
and ensures reliability (Abdella et al., 2024).
There are several methods, we briefly address to the three well-
known. (𝑖) Hierarchical Sharding (Yizhong et al., 2024; Solat
and Nait-Abdesselam, 2023; Kwak et al., 2020; Tong et al.,
2019) This method divide the network into hierarchical shards,
where each shard is responsible for a subset of transactions. It
causes the improvement of throughput by parallelizing transac-
tion processing. However, coordinating for efficient shard and
cross-shard communication is a challenge. The 𝑆𝑖 = 𝐻(𝑇 𝑥𝑗 ∥
𝑃𝑘) is the shard assignment, where 𝑆𝑖 is the shard identifier,
𝐻 is the hash function, 𝑇 𝑥𝑗 is the transaction, and 𝑃𝑘 is the
participant. (𝑖𝑖) Layer-Specific Consensus Mechanisms: This idea
implements consensus mechanisms tailored to the specific needs
of each layer (e.g., BFT for reliability and PoS for scalability)
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Table 23
A general comparison between offered proposals in Section 5.3.3 (Throughput andreliability).
Item Layered architecture Applying relay chain Merkle tree and the PoE mechanism
Hierarchical
sharding
Layer-specific
consensus
Inter-layer
protocols
Polkadot-
style relay
chains
IBC
protocols
Atomic
swaps
Merkle trees PoE ZKPs
Throughput High Moderate Moderate High High High Moderate Moderate Moderate
Reliability High High High High High High High High High
Scalability High High Moderate High High Moderate Moderate Moderate Moderate
Interoperability Moderate Moderate High High High High Moderate Moderate Moderate
Security High High High High High High High High Very high
Complexity High Moderate High High High High Moderate Low Very high
Implementation
cost
High Moderate High High High Moderate Low Low High
Maintenance Moderate Moderate High High High Moderate Low Low High
t
t
(
L
e
i
s
Fig. 9. The Merkle tree structure.
to optimizes performance and security based on the layer’s
role (Stanley et al., 2016; Moses and Rajsbaum, 2002). In this
method, considering seamless interoperability between layers is
essential. In the BFT consensus, 𝜎 = 2
3𝑁 + 1, where 𝜎 is the
number of nodes required for consensus, and 𝑁 is the total
number of nodes. As the third suggestion future work, (𝑖𝑖𝑖) Inter-
layer protocols develop protocols for efficient communication
and data exchange between layers, such as cross-layer transac-
tion protocols. The Inter-layer protocols enhance data integrity
and consistency (Guo et al., 2022; Di Stefano et al., 2020).
However, developers should design protocols so that they are
robust against attacks and faults.
2. Applying relay chain: Utilize relay chains to interconnect different
blockchain networks, facilitating communication and transac-
tion processing across them (Wang et al., 2020b; Zhang et al.,
2021). Here, we identify three topics to follow.
(𝑖) Using Polkadot-Style Relay Chains51 You can use a cen-
tral relay chain to connect multiple parachains, each respon-
sible for specific tasks or types of transactions. This method
provides high scalability and security through shared security
model. However, the complexity in relay chain management and
parachain onboarding is an issue required exact implementation.
(𝑖𝑖) Applying IBC protocol (Essaid et al., 2023; Dinesha and
51 https://wiki.polkadot.network/docs/learn-architecture.
32 
Patil, 2023) Developing an IBC protocol for secure message
passing between blockchains facilitates interoperability without
compromising individual blockchain sovereignty. This idea is
good, but you should ensure the protocol soundness of security
and efficiency. (𝑖𝑖𝑖) Implement Atomic Swaps and Cross-Chain
Transactions52: Atomic swap protocols are used for seamless
asset exchange across different blockchains (Han et al., 2019;
Thyagarajan et al., 2022; Herlihy, 2018). These protocols elimi-
nate the need for trusted third parties. However, they require ad-
vanced cryptographic techniques and consensus on transaction
finality.
3. Merkle tree (Merkle, 1987) and the PoE mechanism (Chopra et al.,
2019): Use Merkle trees and PoE to ensure data integrity and
non-repudiation in blockchain transactions. As shown in Fig. 9
Merkle tree is defined as a hash tree and formalized as 𝑖𝑛𝑝𝑢𝑡𝑙 𝑒𝑣𝑒𝑙𝑖
← ℎ(𝑜𝑢𝑡𝑝𝑢𝑡𝑙 𝑒𝑓 𝑡𝑙 𝑒𝑣𝑒𝑙𝑖−1 ∥ 𝑜𝑢𝑡𝑝𝑢𝑡𝑟𝑖𝑔 ℎ𝑡𝑙 𝑒𝑣𝑒𝑙𝑖−1 ). In the other word, Merkle
tree can be defined as a 2-to-1 map that shown as ℎ ∶ {0, 1}2𝑙 →
{0, 1}𝑙 (𝑙 is a constant value, e.g., 256).
This a general idea, bit for more detail, we present a brief
overview on three subtopic of this category.
(𝑖) Using Merkle Tree for Data Structure: In this idea you should
implement Merkle trees to hash transactions and store them in
a hierarchical manner (Banaeian Far et al., 2024). This method
provides an efficient data verification and integrity checks. But
managing tree growth and optimizing update mechanisms is
challenging and requires deep knowledge. (𝑖𝑖) Using PoE mech-
anism: Using PoE mechanism for timestamp and verification the
existence of data at a specific point in time causes a tamper-proof
audit trail (Shawn et al., 2021). However, ensuring the scala-
bility of PoE mechanisms should be considered. (𝑖𝑖𝑖) Applying
ZKP-based methods: If you are an expert cryptographer, you can
integrate ZKPs with Merkle trees for enhanced privacy and data
verification. This way enhances security and privacy without
revealing underlying data (Kuznetsov et al., 2024; Zhang et al.,
2023b). But, note that in the implementation, computationally
intensive and requires advanced cryptographic expertise is very
important.
The development of L3 blockchains requires innovative approaches
o ensure throughput and reliability. By implementing layered archi-
ectures, relay chains, and Merkle tree with PoE mechanisms, everyone
or team) can significantly enhance the performance and robustness of
3s. The proposed solutions offer various methods of implementation,
ach with its own set of advantages and challenges. The Table 23 assists
n evaluating these methods based on different parameters, guiding the
election of the most suitable approach for specific use cases.
52 https://chain.link/education-hub/atomic-swaps.
https://wiki.polkadot.network/docs/learn-architecture
https://chain.link/education-hub/atomic-swaps
S. Banaeian Far and S.M. Hosseini Bamakan
o
i
c
i
Journal of Network and Computer Applications 233 (2025) 104044 
6. Conclusion
The empowerment of L3s is crucial in addressing the weaknesses
f L1s solutions and enhancing the applicability of L2s. However,
it is important to note that L3 projects are currently in their early
stages and can be considered highly premature. As the development
progresses, future DApps will increasingly rely on the advancements
and capabilities offered by L3 solutions. In order to thrive in the
evolving technological landscape, experts and developers in the field
of Web3 and DApp development should prioritize increasing their
understanding and mastery of L3 technologies. By doing so, they can
position themselves as frontrunners in the ever-expanding horizon of
technology.
This study not only serves as a foundational academic exploration
nto the emerging L3 blockchain solutions but also paves the way for
future advancements in both academic research and industry practices.
As L3 technologies continue to evolve, they promise to unlock new lev-
els of interoperability and scalability within the blockchain ecosystem,
addressing the critical limitations faced by current L1 and L2 solu-
tions. For the academic community, this research opens up numerous
avenues for further investigation, including the development of more
robust frameworks for L3 integration, security enhancements, and the
exploration of new applications such as Universal DeFi. Meanwhile, for
industry stakeholders, the insights provided in this study highlight the
strategic importance of embracing L3 technologies to stay competitive
in the rapidly advancing blockchain landscape. As the technology
matures, the convergence of academic research and industry innovation
will be crucial in realizing the full potential of L3 solutions, leading
to the creation of more efficient, secure, and decentralized blockchain
networks.
CRediT authorship contribution statement
Saeed Banaeian Far: Writing – original draft, Investigation, Data
curation, Conceptualization. Seyed Mojtaba Hosseini Bamakan: Writ-
ing – review & editing, Project administration.
Ethics approval and consent to participate
This article does not contain any studies with human participants
or animals performed by any of the authors.
Funding
This research received no specific grant from any funding agency in
the public, commercial, or not-for-profit sectors.
Declaration of competing interest
The authors declare that they have no known competing finan-
ial interests or personal relationships that could have appeared to
nfluence the work reported in this paper.
Acknowledgments
We gratefully acknowledge the financial support from the Iran
NationalScience Foundation (INSF) [Project number: 4035501]
Data availability
No data was used for the research described in the article.
33 
References
Abdella, Juhar Ahmed, et al., 2024. MuLCOff: A multi-layer consensus and off-chain
computation for efficient and privacy-aware blockchain-based peer-to-peer energy
trading. IEEE Netw..
Abdullah, Yasir, et al., 2024. Electronic health record using DEFI with the help of
blockchain. In: AIP Conference Proceedings. Vol. 2742, AIP Publishing, No. 1.
Adisa, Olawale, et al., 2024. Decentralized finance (DEFI) in the US economy: A review:
Assessing the rise, challenges, and implications of blockchain-driven financial
systems. World J. Adv. Res. Rev. 21 (1), 2313–2328.
Aggelos, Kiayias, Zindros, Dionysis, 2020. Proof-of-work sidechains. In: Financial
Cryptography and Data Security: FC 2019 International Workshops, VOTING and
WTSC, St. Kitts, St. Kitts and Nevis, February 18–22, 2019, Revised Selected Papers
23. Springer International Publishing.
Ahlqvist, Victor, Holmberg, Pär, Tangerås, Thomas, 2022. A survey comparing
centralized and decentralized electricity markets. Energy Strategy Rev. 40, 100812.
Akanfe, Oluwafemi, Lawong, Diane, Rao, H. Raghav, 2024. Blockchain technology and
privacy regulation: Reviewing frictions and synthesizing opportunities. Int. J. Inf.
Manage. 76, 102753.
Al-Maliki, Ossama, Al-Assam, Hisham, 2021. Challenge-response mutual authentication
protocol for EMV contactless cards. Comput. Secur. 103, 102186.
AlMarshoud, Mishri Saleh, Al-Bayatti, Ali H., Kiraz, Mehmet Sabir, 2024. Security,
privacy, and decentralized trust management in VANETs: a review of current
research and future directions. ACM Comput. Surv..
Alshahrani, Saeed M., 2024. Enabling blockchain for Saudi Arabia drug supply chain
using internet of things (IoT). PeerJ Comput. Sci. 10, e2072.
Anastasia, Mavridou, Laszka, Aron, 2018. Designing secure ethereum smart contracts: A
finite state machine based approach. In: Financial Cryptography and Data Security:
22nd International Conference, FC 2018, Nieuwpoort, Curaçao, February 26–March
2, 2018, Revised Selected Papers 22. Springer Berlin Heidelberg.
Ankit, Gangwal, Gangavalli, Haripriya Ravali, Thirupathi, Apoorva, 2023. A survey of
layer-two blockchain protocols. J. Netw. Comput. Appl. 209, 103539.
Anthony Jnr, Bokolo, 2024. Enhancing blockchain interoperability and intraoperability
capabilities in collaborative enterprise-a standardized architecture perspective.
Enterp. Inf. Syst. 18 (3), 2296647.
Aspris, Angelo, et al., 2021. Decentralized exchanges: The wild west of cryptocurrency
trading. Int. Rev. Financ. Anal. 77, 101845.
Aumayr, Lukas, et al., 2022. Sleepy channels: Bi-directional payment channels without
watchtowers. In: Proceedings of the 2022 ACM SIGSAC Conference on Computer
and Communications Security.
Bamakan, Seyed Mojtaba Hosseini, Far, Saeed Banaeian, 2024. Distributed and trust-
worthy digital twin platform based on blockchain and Web3 technologies. Cyber
Secur. Appl. 100064.
Bamakan, Seyed Mojtaba Hosseini, Malekinejad, Pooria, Ziaeian, Mehran, 2022. To-
wards blockchain-based hospital waste management systems; applications and
future trends. J. Clean. Prod. 349, 131440.
Bamakan, Seyed Mojtaba Hosseini, Motavali, Amirhossein, Bondarti, Alireza Babaei,
2020. A survey of blockchain consensus algorithms performance evaluation criteria.
Expert Syst. Appl. 154, 113385.
Banaeian Far, Saeed, Asaar, Maryam Rajabzadeh, Haghbin, Afrooz, 2023. A blockchain-
based coin mixing protocol with certificateless signcryption. Peer-to-Peer Netw.
Appl. 16 (2), 1106–1124.
Banaeian Far, Saeed, Asaar, Maryam Rajabzadeh, Haghbin, Afrooz, 2024. A generic
framework for blockchain-assisted on-chain auditing for off-chain storage. Int. J.
Inf. Secur. 1–29.
Banaeian Far, Saeed, Bamakan, Seyed Mojtaba Hosseini, 2023. NFT-based identity
management in metaverses: challenges and opportunities. SN Appl. Sci. 5 (10),
260.
Banaeian Far, Saeed, Rad, Azadeh Imani, 2021. Distributed auditing protocol for
blockchain-based transactions using a distributed signature. Secur. Priv. 4 (3), e156.
Banaeian Far, Saeed, Rad, Azadeh Imani, 2023. What are the benefits and opportunities
of launching a metaverse for NEOM city? Secur. Priv. 6 (3), e282.
Baum, Carsten, et al., 2023. Publicly verifiable zero-knowledge and post-quantum
signatures from vole-in-the-head. In: Annual International Cryptology Conference.
Springer Nature Switzerland, Cham.
Ben-Sasson, Eli, et al., 2019. Scalable zero knowledge with no trusted setup. In:
Advances in Cryptology–CRYPTO 2019: 39th Annual International Cryptology
Conference, Santa Barbara, CA, USA, August 18–22, 2019, Proceedings, Part III
39. Springer International Publishing.
Bibri, Simon Elias, 2022. The social shaping of the metaverse as an alternative to the
imaginaries of data-driven smart cities: A study in science, technology, and society.
Smart Cities 5 (3), 832–874.
Boneh, Dan, Franklin, Matt, 2001. Identity-based encryption from the Weil pairing. In:
Annual International Cryptology Conference. Springer Berlin Heidelberg, Berlin,
Heidelberg.
Boneh, Dan, Lynn, Ben, Shacham, Hovav, 2004. Short signatures from the weil pairing.
J. Cryptol. 17, 297–319.
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb1
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb1
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb1
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb1
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb1
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb2
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb2
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb2
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb3
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb3
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb3
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb3
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb3
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb4
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb4
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb4
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb4
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb4
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb4
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb4
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb5
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb5
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb5
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb6
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb6
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb6
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb6
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb6
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb7
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb7
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb7
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb8
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb8
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb8
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb8
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb8
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb9
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb9
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb9
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb10
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb10
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb10
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb10
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb10
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb10
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb10
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb11
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb11
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb11
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb12
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb12
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb12
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb12http://refhub.elsevier.com/S1084-8045(24)00221-2/sb12
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb13
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb13
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb13
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb14
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb14
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb14
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb14
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb14
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb15
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb15
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb15
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb15
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb15
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb16
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb16
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb16
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb16
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb16
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb17
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb17
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb17
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb17
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb17
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb18
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb18
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb18
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb18
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb18
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb19
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb19
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb19
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb19
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb19
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb20
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb20
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb20
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb20
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb20
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb21
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb21
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb21
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb22
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb22
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb22
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb23
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb23
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb23
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb23
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb23
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb24
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb24
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb24
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb24
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb24
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb24
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb24
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb25
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb25
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb25
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb25
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb25
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb26
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb26
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb26
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb26
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb26
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb27
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb27
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb27
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Boneh, Dan, et al., 2018. Threshold cryptosystems from threshold fully homomorphic
encryption. In: Advances in Cryptology–CRYPTO 2018: 38th Annual International
Cryptology Conference, Santa Barbara, CA, USA, August 19–23, 2018, Proceedings,
Part I 38. Springer International Publishing.
Bruschi, Francesco, et al., 2022. A scalable decentralized system for fair token
distribution and seamless users onboarding. Blockchain: Res. Appl. 3 (1), 100031.
Bünz, Benedikt, Kiffer, Lucianna, Luu, Loi, Zamani, Mahdi, 2020. Flyclient: Super-light
clients for cryptocurrencies. In: 2020 IEEE Symposium on Security and Privacy. SP,
IEEE, pp. 928–946.
Cai, Cynthia Weiyi, 2018. Disruption of financial intermediation by FinTech: a review
on crowdfunding and blockchain. Account. Finance 58 (4), 965–992.
Campino, José, Brochado, Ana, Rosa, Álvaro, 2022. Initial coin offerings (ICOs): Why
do they succeed? Financ. Innov. 8 (1), 17.
Chen, Xiao, Ding, Jie, Lu, Zhenyu, 2020. A decentralized trust management system
for intelligent transportation environments. IEEE Trans. Intell. Transp. Syst. 23 (1),
558–571.
Chen, Yourong, et al., 2024a. Efficient and secure blockchain consensus algorithm for
heterogeneous industrial internet of things nodes based on double-DAG. IEEE Trans.
Ind. Inform..
Chen, Li, et al., 2024b. Utilization of blockchain technology in personalized nursing: A
scoping review. J. Clin. Nurs..
Chiara, Braghin, Riccobene, Elvinia, Valentini, Simone, 2024. Modeling and verification
of smart contracts with abstract state machines. In: Proceedings of the 39th
ACM/SIGAPP Symposium on Applied Computing.
Choi, Nakhoon, Kim, Heeyoul, 2024. Decentralized exchange transaction analysis and
maximal extractable value attack identification: Focusing on uniswap USDC3.
Electronics 13 (6), 1098.
Chopra, Kriti, Gupta, Kunal, Lambora, Annu, 2019. Proof of existence using blockchain.
In: 2019 International Conference on Machine Learning, Big Data, Cloud and
Parallel Computing. COMITCon, IEEE.
Chun, Brent N., Bavier, Andy, 2004. Decentralized trust management and accountability
in federated systems. In: 37th Annual Hawaii International Conference on System
Sciences, 2004. Proceedings of the. IEEE.
Colamartino, Chiara, Manta, Francesco, Toma, Pierluigi, 2024. NFTs for certified
products: a heritage to protect on the table of the metaverse. Appl. Econ. 1–16.
Cummings, Joseph, et al., 2007. Intensive care unit telemedicine: review and consensus
recommendations. Am. J. Med. Qual. 22 (4), 239–250.
Daghmehchi Firoozjaei, Mahdi, et al., 2020. Hy-bridge: A hybrid blockchain for privacy-
preserving and trustful energy transactions in internet-of-things platforms. Sensors
20 (3), 928.
Datta, Anwitaman, et al., 2024. BlockChain I/O: Enabling cross-chain commerce. IEEE
Access.
Delerablée, Cécile, Pointcheval, David, 2008. Dynamic threshold public-key encryption.
In: Annual International Cryptology Conference. Springer Berlin Heidelberg, Berlin,
Heidelberg.
Di Stefano, Alessandro, et al., 2020. Resolution of blockchain conflicts through
heuristics-based game theory and multilayer network modeling. In: Proceedings
of the 21st International Conference on Distributed Computing and Networking.
Diaz, I, Villagra, M., 2021. Oracle swap exchange whitepaper.
Dinesha, Disha Lagadamane, Patil, Balachandra, 2023. Achieving interoperability in
heterogeneous blockchain users through inter-blockchain communication protocol.
Authorea Preprints.
Ding, Wenwen, et al., 2022. DeSci based on Web3 and DAO: A comprehensive overview
and reference model. IEEE Trans. Comput. Soc. Syst. 9 (5), 1563–1573.
Du, Wenliang, Atallah, Mikhail J., 2001. Secure multi-party computation problems
and their applications: a review and open problems. In: Proceedings of the 2001
Workshop on New Security Paradigms.
Du, Mingxiao, et al., 2017. A review on consensus algorithm of blockchain. In: 2017
IEEE International Conference on Systems, Man, and Cybernetics. SMC, IEEE.
Duan, Haihan, et al., 2021. Metaverse for social good: A university campus prototype.
In: Proceedings of the 29th ACM International Conference on Multimedia.
Duan, Li, et al., 2023. Attacksagainst cross-chain systems and defense approaches: A
contemporary survey. IEEE/CAA J. Autom. Sin. 10 (8), 1647–1667.
Dubey, Kumar Pradyot, et al., 2024. Parallel Byzantine fault tolerance method for
blockchain. In: Artificial Intelligence, Blockchain, Computing and Security Volume
1. CRC Press, pp. 605–612.
El Ioini, Nabil, Pahl, Claus, 2018. A review of distributed ledger technologies. In: On
the Move to Meaningful Internet Systems. OTM 2018 Conferences: Confederated
International Conferences: CoopIS, C & TC, and ODBASE 2018, Valletta, Malta,
October 22-26, 2018, Proceedings, Part II. Springer International Publishing.
ElGamal, Taher, 1985. A public key cryptosystem and a signature scheme based on
discrete logarithms. IEEE Trans. Inf. Theory 31 (4), 469–472.
Ephrati, Eithan, Rosenschein, Jeffrey S., 1993. Distributed consensus mechanisms
for self-interested heterogeneous agents. In: [1993] Proceedings International
Conference on Intelligent and Cooperative Information Systems. IEEE.
Ernstberger, Jens, et al., 2024. Do you need a zero knowledge proof? Cryptol. ePrint
Arch..
34 
Essaid, Meryam, Kim, Jungyeon, Ju, Hongteak, 2023. Inter-blockchain communication
message relay time measurement and analysis in cosmos. Appl. Sci. 13 (20), 11135.
Fan, Yuqi, Wu, Huanyu, Paik, Hye-Young, 2021. DR-BFT: A consensus algorithm for
blockchain-based multi-layer data integrity framework in dynamic edge computing
system. Future Gener. Comput. Syst. 124, 33–48.
Far, Saeed Banaeian, Asaar, Maryam Rajabzadeh, Haghbin, Afrooz, 2023a. Distributed
auditing protocol for untraceable transactions. J. Inf. Secur. Appl. 73, 103429.
Far, Saeed Banaeian, Bamakan, Seyed Mojtaba Hosseini, 2022. Blockchain-based re-
porting protocols as a collective monitoring mechanism in DAOs. Data Sci. Manag.
5 (1), 11–12.
Far, Saeed Banaeian, Rad, Azadeh Imani, 2022. Applying digital twins in metaverse:
User interface, security and privacy challenges. J. Metaverse 2 (1), 8–15.
Far, Saeed Banaeian, Rad, Azadeh Imani, Asaar, Maryam Rajabzadeh, 2023b.
Blockchain and its derived technologies shape the future generation of digital
businesses: a focus on decentralized finance and the metaverse. Data Sci. Manag.
6 (3), 183–197.
Far, S. Banaeian, Rajabzadeh Asaar, M, Haghbin, Afrooz, 2022a. An unlinkable repu-
tation transfer framework for blockchain-based retail markets using non-fungible
tokens. J. Adv. Comput. Eng. Technol..
Far, Saeed Banaeian, et al., 2022b. A review of non-fungible tokens applications in the
real-world and metaverse. Procedia Comput. Sci. 214, 755–762.
Far, Saeed Banaeian, et al., 2023c. Toward metaverse of everything: Opportuni-
ties, challenges, and future directions of the next generation of visual/virtual
communications. J. Netw. Comput. Appl. 217, 103675.
Fiege, Uriel, Fiat, Amos, Shamir, Adi, 1987. Zero knowledge proofs of identity. In:
Proceedings of the Nineteenth Annual ACM Symposium on Theory of Computing.
Fridgen, Gilbert, et al., 2018. Don’t slip on the initial coin offering (ICO): A taxonomy
for a blockchain-enabled form of crowdfunding. In: 26th European Conference on
Information Systems. ECIS.
Gallo, Gaetano, et al., 2021. E-consensus on telemedicine in proctology: a
RAND/UCLA-modified study. Surgery 170 (2), 405–411.
Gao, Sheng, et al., 2021. A privacy-preserving identity authentication scheme based on
the blockchain. Secur. Commun. Netw. 1 (2021), 9992353.
Gaurav, Akshat, 2023. Metaverse and globalization: Cultural exchange and digital
diplomacy. In: Data Science Insights Magazine. Insights2Techinfo.
Gavin, Wood, 2016. Polkadot: Vision for a heterogeneous multi-chain framework. White
Pap. 21 (2327), 4662.
Gentry, Craig, 2009. Fully homomorphic encryption using ideal lattices. In: Proceedings
of the Forty-First Annual ACM Symposium on Theory of Computing.
Ghassan, Karame, 2016. On the security and scalability of bitcoin’s blockchain. In: Pro-
ceedings of the 2016 ACM SIGSAC Conference on Computer and Communications
Security.
Goldreich, Oded, 1998. Secure multi-party computation. pp. 1–108, Manuscript.
Preliminary version 78.110.
Goldreich, Oded, Oren, Yair, 1994. Definitions and properties of zero-knowledge proof
systems. J. Cryptology 7 (1), 1–32.
Gorkhali, Anjee, Chowdhury, Rajib, 2022. Blockchain and the evolving financial market:
A literature review. J. Ind. Integr. Manag. 7 (01), 47–81.
Gourley, David, Totty, Brian, 2002. HTTP: The Definitive Guide. O’Reilly Media, Inc..
Gu, Zhuoming, Lin, Dan, Wu, Jiajing, 2022. On-chain analysis-based detection of
abnormal transaction amount on cryptocurrency exchanges. Phys. A 604, 127799.
Gudgeon, Lewis, et al., 2019. Sok: Off the chain transactions. IACR Cryptol. ePrint
Arch. 2019, 360.
Guggenberger, Tobias, et al., 2024. Kickstarting blockchain: designing blockchain-based
tokens for equity crowdfunding. Electron. Commer. Res. 24 (1), 239–273.
Guo, Hao, Li, Wanxin, Nejad, Mark, 2022. A hierarchical and location-aware consensus
protocol for IoT-blockchain applications. IEEE Trans. Netw. Serv. Manag. 19 (3),
2972–2986.
Guo, Cheng, et al., 2024. A game-theory-based scheme to facilitate consensus latency
minimization in sharding blockchain. Inform. Sci. 657, 119954.
Han, Runchao, Lin, Haoyu, Yu, Jiangshan, 2019. On the optionality and fairness of
atomic swaps. In: Proceedings of the 1st ACM Conference on Advances in Financial
Technologies.
Han, Yutong, Wang, Chundong, Wang, Huaibin, 2024a. Research on blockchain
cross-chain model based on NFT+ cross-chain bridge. IEEE Access.
Han, Daoqi, et al., 2024b. A lightweight blockchain architecture with smart col-
laborative and progressive evolution for privacy-preserving 6G IoT. IEEE Wirel.
Commun..
Harjot, Singh, 2023. DApps: Decentralized applications for blockchains. In: Distributed
Computing to Blockchain. Academic Press, pp. 87–104.
Harn, Lein, 1994. Group-oriented (t, n) threshold digital signature scheme and digital
multisignature. IEE Proc., Comput. Digit. Tech. 141 (5), 307–313.
Helms, Marilyn M., Nixon, Judy, 2010. Exploring SWOT analysis–where are we now?
A review of academic research from the last decade. J. Strategy Manag. 3 (3),
215–251.
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb28
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb28
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb28
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb28
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb28
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb28
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb28
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb29
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb29
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb29
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb30
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb30
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb30
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb30
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb30
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb31
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb31
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb31
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb32
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb32
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb32
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb33
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb33
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb33
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb33
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb33
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb34
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb34
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb34
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb34
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb34
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb35
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb35
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb35
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb36http://refhub.elsevier.com/S1084-8045(24)00221-2/sb36
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb36
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb36
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb36
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb37
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb37
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb37
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb37
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb37
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb38
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb38
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb38
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb38
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb38
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb39
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb39
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb39
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb39
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb39
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb40
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb40
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb40
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb41
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb41
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb41
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb42
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb42
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb42
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb42
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb42
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb43
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb43
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb43
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb44
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb44
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb44
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb44
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb44
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb45
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb45
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb45
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb45
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb45
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb46
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb47
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb47
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb47
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb47
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb47
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb48
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb48
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb48
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb49
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb49
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb49
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb49
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb49
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb50
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb50
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb50
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb51
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb51
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb51
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb52
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb52
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb52
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb53
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb53
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb53
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb53
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb53
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb54
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb54
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb54
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb54
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb54
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb54
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb54
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb55
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb55
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb55
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb56
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb56
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb56
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb56
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb56
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb57
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb57
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb57
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb58
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb58
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb58
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb59
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb59
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb59
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb59
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb59
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb60
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb60
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb60
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb61
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb61
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb61
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb61
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb61
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb62
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb62
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb62
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb63
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb63
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb63
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb63
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb63
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb63
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb63
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb64
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb64
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb64
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb64
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb64
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb65
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb65
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb65
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb66
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb66
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb66
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb66
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb66
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb67
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb67
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb67
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb68
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb68
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb68
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb68
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb68
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb69
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb69
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb69
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb70
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb70
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb70
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb71
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb71
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb71
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb72
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb72
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb72
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb73
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb73establishing decentralized
onnections among L1s, where no centralized entity exists, represents
ne of the challenging yet intriguing quandaries encountered in DeFi
pplications. The resolution(s) to this challenge holds the potential
2 
to empower traders and users to engage in transactions between L2s
eveloped on disparate blockchains or partake in similar activities.
A plethora of practical, specialized solutions in the form of single-
task applications have been introduced, with numerous projects poised
for imminent launch (Maurice, 2018; Gavin, 2016; Diaz and Villa-
gra, 2021). These endeavors are commonly referred to as L3s, which
aim to facilitate decentralized cross-chain transactions, establish con-
nections between L1s datasets, and develop a common programming
language for multiple blockchains, among other objectives. Presently,
L3s stand as cutting-edge subjects of great interest in the industry.
Advanced cryptographic tools, including zero-knowledge proofs, multi-
party computing, and homomorphic schemes, have played a pivotal
role in providing substantial assistance to the development of L3 so-
utions (Martinez et al., 2020).
Blockchain technology has evolved through three main genera-
tions, each addressing the limitations of the previous. First-generation
blockchains, like Bitcoin (2009) (Satoshi, 2008) and Litecoin1 (2011),
focused on decentralized digital currencies, primarily offering secure,
immutable ledgers for peer-to-peer transactions. However, they were
limited in scalability and programmability. Second-generation
blockchains, such as Ethereum2 in 2015 (the most well-known smart
contract infrastructure) and NEO3 in 2014 (known as one of the
irst smart economy developed on blockchain technology), introduced
mart contracts, enabling DApps and automation of trust without
intermediaries. They faced issues with scalability and high transaction
costs. Third-generation blockchains, like Cardano4 (2017) and Polka-
dot5 (2020), focused on improving scalability, interoperability, and
1 https://litecoin.org/.
2 https://ethereum.org/en/.
3 https://neo.org/.
4 https://cardano.org/.
https://litecoin.org/
https://ethereum.org/en/
https://neo.org/
https://cardano.org/
S. Banaeian Far and S.M. Hosseini Bamakan
b
s
i
d
t
t
e
f
r
v
a
s
h
i
b
c
a
a
e
b
t
v
e
b
d
t
t
H
i
f
d
t
o
Journal of Network and Computer Applications 233 (2025) 104044 
energy efficiency through advanced consensus mechanisms and cross-
chain communication. Looking forward, fourth-generation blockchains
(similar to some L3 goals) aim to enhance decentralized governance,
privacy, and AI integration, tackling current challenges in scalability
and transaction finality.
The blockchain trilemma problem is a well-known problem in
lockchain technology that posits a fundamental trade-off between
three key attributes: decentralization, security, and scalability (Ghassan,
2016; Ricco, 2022; Yizhong et al., 2024). In essence, the trilemma
uggests that achieving all three of these attributes simultaneously in
a blockchain system is exceedingly difficult, if not impossible. Decen-
tralization refers to the distribution of control across a wide network of
participants, ensuring no single entity has overarching power. Security
nvolves the network’s ability to remain resistant to attacks, ensuring
ata integrity and trustworthiness. Scalability, the most elusive of the
hree, pertains to the blockchain’s ability to handle a large number of
ransactions per second without compromising its efficiency. Typically,
nhancing one of these aspects leads to compromises in the others;
or example, increasing scalability through higher throughput might
equire a reduction in decentralization or security, leading to potential
ulnerabilities.
Interoperability (Pillai et al., 2020; Anthony Jnr, 2024) and scal-
bility (Imani Rad and Far, 2023; Nasir et al., 2022) are critical
considerations as the blockchain ecosystem evolves and attempts to
address the trilemma. Interoperability involves the seamless interac-
tion between different blockchain networks, enabling them to share
information and value across distinct systems without needing inter-
mediaries. Achieving interoperability enhances the overall utility of
blockchain technology, allowing for broader adoption and use cases.
However, it also introduces new scalability challenges, as networks
must now support cross-chain transactions and interactions, potentially
increasing the computational load and the complexity of maintaining
ecurity. Solutions like Sharding, L2 protocols, and cross-chain bridges
ave been proposed to enhance scalability while preserving decentral-
zation and security. These approaches aim to break down the trilemma
y enabling networks to process more transactions efficiently and se-
urely while maintaining their decentralized nature, though achieving
 perfect balance remains an ongoing challenge in blockchain research
nd development.
Increasing the interoperability of blockchain-based systems through
the use of L3 blockchains involves implementing advanced protocols
and frameworks that enable seamless communication and data ex-
change between disparate blockchain networks. L3 solutions typically
build on the scalability and security enhancements of L2 technolo-
gies, offering additional functionalities such as cross-chain compati-
bility, DApp integration, and enhanced transaction efficiency (Pillai
t al., 2020; Anthony Jnr, 2024). By facilitating interoperability, L3
lockchains allow different blockchain systems to interact and operate
ogether more effectively, thereby fostering a more interconnected and
ersatile blockchain ecosystem. This integration not only broadens
the use cases of blockchain technology but also enhances its overall
fficiency and utility. Scalability is another challenging problem in
lockchain-based systems, encompassing both vertical and horizontal
imensions (Ricco, 2022; Yizhong et al., 2024; Imani Rad and Far,
2023; Nasir et al., 2022). Vertical scalability refers to the infrastruc-
ure’s ability to provide higher throughput and lower latency, ensuring
he system can handle an increased volume of transactions efficiently.
orizontal scalability, on the other hand, relates to the system’s capac-
ty to support a growing number of users while maintaining a balance of
airness and performance as user numbers increase. L3 blockchains ad-
ress these scalability challenges by implementing advanced protocols
hat enhance both throughput and user capacity, thereby improving the
verall performance and accessibility of blockchain-based platforms.
5 https://polkadot.network/development/docs/.
3 
1.1. Contribution
The L3 is a recent concept introduced by the industry and this study
sees an initial academic approach to it for future developments. In the
realm of L3s, numerous terms have emerged, including app-chain, side-
chain, omni-chain, para-chain, cross-chain, multi-chain, hyper-chain,
super-chain, mega-chain, and ultra-chain. While these terms may ap-
pear similar, they differ significantly in their goals and architectural
frameworks (some of them are known as L2 solutions, and some others
are off-chain ones). Nevertheless, all of these variations have been pro-
posed and developed to address two primary challenges encountered in
the blockchain domain. Firstly, they aim to achieve interoperability, en-
abling seamless and extensive interaction among diverse blockchains.
Secondly, they strive to scale blockchain systems while upholding the
fundamental tenets of security and decentralization. Overall, this paper
delves into the concepts underlying L3s within these two categories
as mentioned earlier. In this regard, this study makes several key
contributions to the emerging field of L3 solutions, providing an in-
depth analysis of their potential impact on the blockchain ecosystem.
The contributions are highlighted as follows.
1. Pioneering Academic Exploration: This paper represents one of
the first comprehensive academic investigations intohttp://refhub.elsevier.com/S1084-8045(24)00221-2/sb73
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb74
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb74
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb74
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb74
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb74
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb75
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb75
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb75
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb76
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb76
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb76
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb77
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb77
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb77
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb78
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb79
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb79
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb79
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb80
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb80
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb80
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb81
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb81
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb81
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb82
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb82
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb82
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb82
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb82
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb83
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb83
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb83
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb84
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb84
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb84
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb84
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb84
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb85
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb85
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb85
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb86
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb86
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb86
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb86
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb86
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb87
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb87
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb87
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb88
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb88
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb88
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb89
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb89
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb89
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb89
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb89
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Hennebelle, Alain, et al., 2024. Secure and privacy-preserving automated machine
learning operations into end-to-end integrated IoT-edge-artificial intelligence-
blockchain monitoring system for diabetes mellitus prediction. Comput. Struct.
Biotechnol. J. 23, 212–233.
Herlihy, Maurice, 2018. Atomic cross-chain swaps. In: Proceedings of the 2018 ACM
Symposium on Principles of Distributed Computing.
Hopwood, Daira, et al., 2016. Zcash Protocol Specification. Vol. 4.220, GitHub, San
Francisco, CA, USA, p. 32.
Huang, Junjie, Tan, Liang, Xiao, Jianmei, 2024. RON-based cross-chain routing
optimization strategy in metaverse. IET Blockchain.
Huang, Pei, et al., 2020. A collaborative auditing blockchain for trustworthy data
integrity in cloud storage system. IEEE Access 8, 94780–94794.
Imani Rad, Azadeh, Far, Saeed Banaeian, 2023. Socialfi transforms social media: an
overview of key technologies, challenges, and opportunities of the future generation
of social media. Soc. Netw. Anal. Min. 13 (1), 42.
Jain, Nikita, Gupta, Vedika, Dass, Pranav, 2022. Blockchain: A novel paradigm for
secured data transmission in telemedicine. In: Wearable Telemedicine Technology
for the Healthcare Industry. Academic Press, pp. 33–52.
Jiang, Yiming, et al., 2019. A cross-chain solution to integrating multiple blockchains
for IoT data management. Sensors 19 (9), 2042.
Johnson, Don, Menezes, Alfred, Vanstone, Scott, 2001. The elliptic curve digital
signature algorithm (ECDSA). Int. J. Inf. Secur. 1, 36–63.
Kaddoura, Sanaa, Husseiny, Fatima Al, 2023. The rising trend of metaverse in
education: Challenges, opportunities, and ethical considerations. PeerJ Comput. Sci.
9, e1252.
Kannengießer, Niclas, et al., 2020. Bridges between islands: Cross-chain technology for
distributed ledger technology.
Karpenko, Oksana A., Blokhina, Tatiana K., Chebukhanova, Lali V., 2021. The initial
coin offering (ICO) process: regulation and risks. J. Risk Financ. Manag. 14 (12),
599.
Kayikci, Safak, Khoshgoftaar, Taghi M., 2024. Blockchain meets machine learning: a
survey. J. Big Data 11 (1), 9.
Kfoury, Elie, Khoury, David, 2018. Distributed public key infrastructure and PSK
exchange based on blockchain technology. In: 2018 IEEE International Conference
on Internet of Things (IThings) and IEEE Green Computing and Communications
(GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE
Smart Data (SmartData). IEEE.
Khan, Riaz Ullah, et al., 2024. Blockchain-based trusted tracking smart sensing network
to prevent the spread of infectious diseases. IRBM 45 (2), 100829.
Kotzer, Arad, Gandelman, Daniel, Rottenstreich, Ori, 2024. Sok: Applications of sketches
and rollups in blockchain networks. IEEE Trans. Netw. Serv. Manag..
Kuznetsov, Oleksandr, et al., 2024. Enhanced security and efficiency in blockchain with
aggregated zero-knowledge proof mechanisms. IEEE Access.
Kwak, Ji-Young, et al., 2020. The design of hierarchical consensus mechanism based
on service-zone sharding. IEEE Trans. Eng. Manage. 67 (4), 1387–1403.
Lan, Rongjian, et al., 2021. Horizon: A gas-efficient, trustless bridge for cross-chain
transactions. arXiv preprint arXiv:2101.06000.
Lau, Hakwan, Tse, Stephen, 2021. Decentralized basic income: Creating wealth with
on-chain staking and fixed-rate protocols. arXiv preprint arXiv:2107.14312.
Lavaur, Thomas, Lacan, Jérôme, Chanel, Caroline PC., 2022. Enabling blockchain
services for ioe with zk-rollups. Sensors 22 (17), 6493.
Lavaur, Thomas, et al., 2023. Modular zk-rollup on-demand. J. Netw. Comput. Appl.
217, 103678.
Lee, Donghyeok, Park, Namje, Kim, In Kyung, 2022. Method for linking block-chain
using hyper-chain, and apparatus therefor. U.S. Patent No. 11, 323, 245.
Lee, Hsiu-An, et al., 2020. Global infectious disease surveillance and case tracking
system for COVID-19: development study. JMIR Med. Inform. 8 (12), e20567.
Lei, Liu, Song, Liangtu, Wan, Jiahua, 2022. Improved method of blockchain cross-chain
consensus algorithm based on weighted PBFT. Comput. Intell. Neurosci. 1 (2022),
5169259.
Lewis, Gudgeon, Moreno-Sanchez, Pedro, Roos, Stefanie, McCorry, Patrick, Ger-
vais, Arthur, 2020. Sok: Layer-two blockchain protocols. In: Financial Cryptography
and Data Security: 24th International Conference, FC 2020, Kota Kinabalu,
Malaysia, February 10–14, 2020 Revised Selected Papers 24. Springer International
Publishing, pp. 201–226.
Li, Jiao, Zhao, Wanting, 2024. Blockchain cross-chain protocol based on improved
hashed time-locked contract. Cluster Comput. 1–21.
Li, Jingjing, et al., 2022. Transformation of plants into polka dot arts: Kusama Yayoi as
an inspiration for deep learning. In: International Conference on Human-Computer
Interaction. Springer International Publishing, Cham.
Lianos, Ioannis, et al. (Eds.), 2019. Regulating Blockchain: Techno-Social and Legal
Challenges.Oxford University Press.
Lipmaa, Helger, 2024. Polymath: Groth16 is not the limit. Cryptol. ePrint Arch..
Liu, Yizhong, et al., 2020. SSHC: A secure and scalable hybrid consensus protocol for
sharding blockchains with a formal security framework. IEEE Trans. Dependable
Secure Comput. 19 (3), 2070–2088.
Liu, Gao, et al., 2023a. DePTVM: Decentralized pseudonym and trust value management
for integrated networks. IEEE Trans. Dependable Secure Comput. 21 (1), 110–124.
35 
Liu, Zhenpeng, et al., 2023b. Dynamic data integrity auditing based on hierarchical
Merkle hash tree in cloud storage. Electronics 12 (3), 717.
Loi, Luu, et al., 2016. Making smart contracts smarter. In: Proceedings of the 2016
ACM SIGSAC Conference on Computer and Communications Security.
Lu, Li, et al., 2008. Pseudo trust: Zero-knowledge authentication in anonymous P2Ps.
IEEE Trans. Parallel Distrib. Syst. 19 (10), 1325–1337.
Luna, Manuel, et al., 2024. A blockchain-based approach to the challenges of EU’s envi-
ronmental policy compliance in aquaculture: From traceability to fraud prevention.
Mar. Policy 159, 105892.
Luo, Xinyi, et al., 2024. CrossChannel: Efficient and scalable cross-chain transactions
through cross-and-off-blockchain micropayment channel. IEEE Trans. Dependable
Secure Comput..
Luong, Duc Anh, Park, Jong Hwan, 2022. Privacy-preserving blockchain-based
healthcare system for IoT devices using zk-SNARK. IEEE Access 10, 55739–55752.
Mahato, Ganesh Kumar, Chakraborty, Swarnendu Kumar, 2023. A comparative review
on homomorphic encryption for cloud security. IETE J. Res. 69 (8), 5124–5133.
Mantas, Jurgelaitis, Butkienė, Rita, 2022. Solidity code generation from UML
state machines in model-driven smart contract development. IEEE Access 10,
33465–33481.
Marbouh, Dounia, et al., 2020. Blockchain for COVID-19: review, opportunities, and a
trusted tracking system. Arab. J. Sci. Eng. 45, 9895–9911.
Marcel, Kaiser, 2024. From scalability to cross-chain DeFi. In: The Elgar Companion to
Decentralized Finance, Digital Assets, and Blockchain Technologies. Edward Elgar
Publishing, pp. 265–279.
Martinez, Gayoso, Victor, Luis Hernández-Álvarez, Encinas, Luis Hernandez, 2020.
Analysis of the cryptographic tools for blockchain and bitcoin. Mathematics 8 (1),
131.
Matt, Blaze, Feigenbaum, Joan, Lacy, Jack, 1996. Decentralized trust management. In:
Proceedings 1996 IEEE Symposium on Security and Privacy. IEEE.
Maurice, Herlihy, 2018. Atomic cross-chain swaps. In: Proceedings of the 2018 ACM
Symposium on Principles of Distributed Computing. pp. 245–254.
Merkle, Ralph C., 1987. A digital signature based on a conventional encryption function.
In: Conference on the Theory and Application of Cryptographic Techniques.
Springer Berlin Heidelberg, Berlin, Heidelberg.
Miyachi, Ken, Mackey, Tim K., 2021. hOCBS: A privacy-preserving blockchain frame-
work for healthcare data leveraging an on-chain and off-chain system design. Inf.
Process. Manag. 58 (3), 102535.
Mohammed, Mazin Abed, et al., 2024. Securing healthcare data in industrial cyber–
physical systems using combining deep learning and blockchain technology. Eng.
Appl. Artif. Intell. 129, 107612.
Moses, Yoram, Rajsbaum, Sergio, 2002. A layered analysis of consensus. SIAM J.
Comput. 31 (4), 989–1021.
Nandi, Meghali, et al., 2020. A secured land registration framework on blockchain. In:
2020 Third ISEA Conference on Security and Privacy. ISEA-ISAP, IEEE.
Nasir, Muhammad Hassan, Arshad, Junaid, Khan, Muhammad Mubashir, Fatima, Ma-
hawish, Salah, Khaled, Jayaraman, Raja, 2022. Scalable blockchains—A systematic
review. Future Gener. Comput. Syst. 126, 136–162.
Paillier, Pascal, 1999. Public-key cryptosystems based on composite degree residu-
osity classes. In: International Conference on the Theory and Applications of
Cryptographic Techniques. Springer Berlin Heidelberg, Berlin, Heidelberg.
Papageorgiou, Alexander, et al., 2020. DPKI: a blockchain-based decentralized public
key infrastructure system. In: 2020 Global Internet of Things Summit. GIoTS, IEEE.
Pass, Rafael, 2003. On deniability in the common reference string and random oracle
model. In: Advances in Cryptology-CRYPTO 2003: 23rd Annual International Cryp-
tology Conference, Santa Barbara, California, USA, August 17-21, 2003. Proceedings
23. Springer Berlin Heidelberg.
Peilin, Zheng, et al., 2023. Blockchain-based decentralized application: A survey. IEEE
Open J. Comput. Soc. 4, 121–133.
Pillai, Babu, Biswas, Kamanashis, Muthukkumarasamy, Vallipuram, 2020. Cross-chain
interoperability among blockchain-based systems using transactions. Knowl. Eng.
Rev. 35, e23.
Poon, Joseph, Dryja, Thaddeus, 2016. The bitcoin lightning network: Scalable off-chain
instant payments. 1638897446181.
Pradana, Mahir, Elisa, Hanifah Putri, 2023. Metaverse in education: A systematic
literature review. Cogent Soc. Sci. 9 (2), 2252656.
Pregowska, Agnieszka, Osial, Magdalena, Gajda, Aleksandra, 2024. What will the
education of the future look like? How have metaverse and extended reality
affected the higher education systems? Metaverse Basic Appl. Res. 3, 57.
Puri, Vikram, Kataria, Aman, Sharma, Vishal, 2024. Artificial intelligence-powered
decentralized framework for internet of things in healthcare 4.0. Trans. Emerg.
Telecommun. Technol. 35 (4), e4245.
Rabin, Tal, Ben-Or, Michael, 1989. Verifiable secret sharing and multiparty protocols
with honest majority. In: Proceedings of the Twenty-First Annual ACM Symposium
on Theory of Computing.
Rajeswari, B, et al., 2024. Health care and management using block chain and machine
learning. Health Care 13 (2), 241–246.
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb90
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb90
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb90
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb90
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb90
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb90
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb90
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb91
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb91
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb91
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb92
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb92
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb92
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb93
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb93
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb93
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb94
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb94
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb94
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb95
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb95
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb95
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb95
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb95
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb96
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb96
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb96
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb96
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb96
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb97
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb97
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb97
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb98
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb98
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb98
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb99
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb99
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb99
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb99
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb99
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb100
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb100
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb100
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb101
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb101http://refhub.elsevier.com/S1084-8045(24)00221-2/sb101
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb101
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb101
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb102
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb102
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb102
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb103
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb103
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb103
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb103
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb103
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb103
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb103
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb103
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb103
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb104
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb104
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb104
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb105
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb105
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb105
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb106
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb106
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb106
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb107
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb107
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb107
http://arxiv.org/abs/2101.06000
http://arxiv.org/abs/2107.14312
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb110
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb110
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb110
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb111
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb111
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb111
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb112
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb112
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb112
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb113
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb113
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb113
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb114
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb114
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb114
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb114
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb114
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb115
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb115
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb115
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb115
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb115
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb115
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb115
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb115
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb115
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb116
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb116
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb116
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb117
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb117
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb117
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb117
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb117
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb118
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb118
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb118
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb119
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb120
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb120
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb120
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb120
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb120
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb121
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb121
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb121
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb122
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb122
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb122
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb123
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb123
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb123
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb124
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb124
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb124
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb125
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb125
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb125
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb125
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb125
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb126
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb126
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb126
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb126
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb126
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb127
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb127
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb127
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb128
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb128
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb128
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb129
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb129
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb129
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb129
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb129
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb130
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb130
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb130
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb131
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb131
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb131
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb131
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb131
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb132
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb132
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb132
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb132
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb132
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb133
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb133
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb133
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb134
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb134
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb134
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb135
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb135
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb135
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb135
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb135
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb136
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb136
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb136
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb136
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb136
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb137
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb137
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb137
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb137
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb137
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb138
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb138
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb138
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb139
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb139
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb139
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb140
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb140
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb140http://refhub.elsevier.com/S1084-8045(24)00221-2/sb140
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb140
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb141
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb141
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb141
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb141
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb141
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb142
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb142
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb142
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb143
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb143
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb143
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb143
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb143
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb143
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb143
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb144
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb144
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb144
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb145
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb145
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb145
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb145
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb145
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb146
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb146
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb146
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb147
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb147
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb147
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb148
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb148
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb148
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb148
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb148
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb149
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb149
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb149
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb149
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb149
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb150
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb150
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb150
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb150
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb150
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb151
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb151
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb151
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Rashid, Aqsa, et al., 2021. Blockchain-based public key infrastructure: A transparent
digital certification mechanism for secure communication. IEEE Netw. 35 (5),
220–225.
Ricco, Halim, 2022. Decentralization, Scalability, and Security Trade-Off in Blockchain
System: Comparison on Different Approaches (BS thesis). University of Twente.
Rijmen, Vincent, Daemen, Joan, 2001. Advanced encryption standard. In: Proceedings
of Federal Information Processing Standards Publications. Vol. 19, National Institute
of Standards and Technology, p. 22.
Rivest, Ronald L., Shamir, Adi, Adleman, Leonard M., 1983. Cryptographic
communications system and method. U.S. Patent No. 4, 405, 829.
Rosa, Raphael Vicente, Rothenberg, Christian Esteve, 2018. Blockchain-based decentral-
ized applications for multiple administrative domain networking. IEEE Commun.
Stand. Mag. 2 (3), 29–37.
Ryu, Jongseok, et al., 2022. Design of secure mutual authentication scheme for
metaverse environments using blockchain. IEEE Access 10, 98944–98958.
Saad, Moustafa Mowaffak, Sobhy, Dalia, Saad, Amani A., 2024. Veritas: Layer-2 scaling
solution for decentralized oracles on ethereum blockchain with reputation and
real-time considerations. J. Sens. Actuator Netw. 13 (2), 21.
Sathyanarayanan, Manamohan, Shastry, Krishnaprasad Lingadahalli, Garg, Vishesh,
2023. System and method of decentralized machine learning using blockchain. U.S.
Patent No. 11, 605, 013.
Satoshi, Nakamoto, 2008. Bitcoin: A peer-to-peer electronic cash system.
Schaerer, Jakob, Zumbrunn, Severin, Braun, Torsten, 2022. Veritaa: A distributed public
key infrastructure with signature store. Int. J. Netw. Manage. 32 (2), e2183.
Shafagh, Hossein, et al., 2017. Secure sharing of partially homomorphic encrypted IoT
data. In: Proceedings of the 15th ACM Conference on Embedded Network Sensor
Systems.
Shamir, Adi, 1979. How to share a secret. Commun. ACM 22 (11), 612–613.
Shawn, Lim Wei Ming, et al., 2021. Blockchain-based proof of existence (POE)
framework using ethereum smart contracts. In: Proceedings of the Eleventh ACM
Conference on Data and Application Security and Privacy.
Shehar, Bano, et al., 2020. State machine replication in the libra blockchain. Avalaible
at: https://developers.libra.org/docs/state-machine-replication-paper. (Consulted
19 December 2020).
Shinde, Rucha, et al., 2024. Securing AI-based healthcare systems using blockchain
technology: A state-of-the-art systematic literature review and future research
directions. Trans. Emerg. Telecommun. Technol. 35 (1), e4884.
Shoup, Victor, 2000. Practical threshold signatures. In: Advances in Cryptology—
EUROCRYPT 2000: International Conference on the Theory and Application of
Cryptographic Techniques Bruges, Belgium, May 14–18, 2000 Proceedings 19.
Springer Berlin Heidelberg.
Simmons, Gustavus J., 1994. Proof of soundness (integrity) of cryptographic protocols.
J. Cryptology 7, 69–77.
Singhal, Pooja, Gupta, Shelly, Singh, Jagendra, 2023. An integrated approach for
analysis of electronic health records using blockchain and deep learning. Recent
Adv. Comput. Sci. Commun. 16 (9), 1–10.
Sisi, Zhou, et al., 2023. A systematic review of consensus mechanisms in blockchain.
Mathematics 11 (10), 2248.
Solat, Siamak, Nait-Abdesselam, Farid, 2023. Sharding distributed replication systems
to improve scalability and throughput. In: Building Cybersecurity Applications with
Blockchain and Smart Contracts. Springer Nature Switzerland, Cham, pp. 101–124.
Spinoglio, Francesco, 2022. Redefining banking through defi: a new proposal for free
banking based on blockchain technology and defi 2.0 model. J. New Finance 2 (4),
1.
Srivastava, Vikas, et al., 2022. Blockchain-envisioned provably secure multivariate
identity-based multi-signature scheme for internet of vehicles environment. IEEE
Trans. Veh. Technol. 71 (9), 9853–9867.
Stanley, Natalie, et al., 2016. Clustering network layers with the strata multilayer
stochastic block model. IEEE Trans. Netw. Sci. Eng. 3 (2), 95–105.
Sun, Xiaoqiang, et al., 2021. A survey on zero-knowledge proof in blockchain. IEEE
Netw. 35 (4), 198–205.
Sung-Un, S.O.N.G, Jung, Jin-Wook, 2024. System and method for providing personal
information using one time private key based on blockchain of proof of use. U.S.
Patent No. 11, 943, 362.
Sunny, King, Nadal, Scott, 2012. Ppcoin: Peer-to-peer crypto-currency with
proof-of-stake. self-published paper, August 19.1.
Syverson, Paul, 1991. The use of logic in the analysis of cryptographic protocols. In:
Proceedings. 1991 IEEE Computer Society Symposium on Research in Security and
Privacy. IEEE Computer Society.
Szabo, Nick, 1997. Formalizing and securing relationships on public networks. First
Monday.
Tang, Xiangyan, et al., 2021. A DAPP business data storage model based on blockchain
and IPFS. In: Artificial Intelligence and Security: 7th International Conference,
ICAIS 2021, Dublin, Ireland, July 19–23, 2021, Proceedings, Part II 7. Springer
International Publishing.
Tenorio-Fornés, Ámbar, et al., 2021. Decentralizing science: Towards an interoperable
open peer review ecosystem using blockchain. Inf. Process. Manage. 58 (6), 102724.
36 
Teoh, Bryan, 2023. Solving the blockchain oracle problem to enablesupply chain mass
adoption. In: AIP Conference Proceedings. Vol. 2582, AIP Publishing, No. 1.
Thibault, Louis Tremblay, Sarry, Tom, Hafid, Abdelhakim Senhaji, 2022. Blockchain
scaling using rollups: A comprehensive survey. IEEE Access 10, 93039–93054.
Thyagarajan, Sri AravindaKrishnan, Malavolta, Giulio, Moreno-Sanchez, Pedro, 2022.
Universal atomic swaps: Secure exchange of coins across all blockchains. In: 2022
IEEE Symposium on Security and Privacy. SP, IEEE.
Till, Neudecker, Hartenstein, Hannes, 2018. Network layer aspects of permissionless
blockchains. IEEE Commun. Surv. Tutor. 21 (1), 838–857.
Tochner, Saar, Zohar, Aviv, Schmid, Stefan, 2020. Route hijacking and dos in off-chain
networks. In: Proceedings of the 2nd ACM Conference on Advances in Financial
Technologies.
Tong, Wei, et al., 2019. A hierarchical sharding protocol for multi-domain iot
blockchains. In: ICC 2019-2019 IEEE International Conference on Communications.
ICC, IEEE.
Tsai, Shu-pei, 2024. Investigating metaverse marketing for travel and tourism. J. Vacat.
Market. 30 (3), 479–488.
Tzinas, Apostolos, Zindros, Dionysis, 2023. The principal–agent problem in liquid
staking. In: International Conference on Financial Cryptography and Data Security.
Springer Nature Switzerland, Cham.
Uriarte, Rafael Brundo, DeNicola, Rocco, 2018. Blockchain-based decentralized
cloud/fog solutions: Challenges, opportunities, and standards. IEEE Commun. Stand.
Mag. 2 (3), 22–28.
Valentin, Erhard K., 2001. SWOT analysis from a resource-based view. J. Mark. Theory
Pract. 9 (2), 54–69.
Vaudenay, Serge, 2020. Centralized or decentralized? The contact tracing dilemma.
Wang, Longze, et al., 2020a. Dynamic adaptive cross-chain trading mode for
multi-microgrid joint operation. Sensors 20 (21), 6096.
Wang, Hongkai, et al., 2020b. An electricity cross-chain platform based on sidechain
relay. In: Journal of Physics: Conference Series. Vol. 1631, IOP Publishing, No. 1.
Wang, Fei-Yue, et al., 2022a. The DAO to DeSci: AI for free, fair, and responsibility
sensitive sciences. IEEE Intell. Syst. 37 (2), 16–22.
Wang, Jianghao, et al., 2022b. A survey on privacy protection of cross-chain. In: Inter-
national Conference on Artificial Intelligence and Security. Springer International
Publishing, Cham.
Weidener, Lukas, 2024. Decentralized science (DeSci): Definition, shared values, and
guiding principles.
Wright, Gary R., Richard Stevens, W., 1995. TCP/IP Illustrated, Volume 2: The
Implementation. Addison-Wesley Professional.
Wu, Yaqin, Song, Pengxin, Wang, Fuxin, 2020. Hybrid consensus algorithm optimiza-
tion: A mathematical method based on POS and PBFT and its application in
blockchain. Math. Probl. Eng. 1 (2020), 7270624.
Wu, Kaidong, et al., 2021. A first look at blockchain-based decentralized applications.
Softw. - Pract. Exp. 51 (10), 2033–2050.
Xie, Tianxiu, et al., 2023a. Cross-chain-based trustworthy node identity governance in
internet of things. IEEE Internet Things J..
Xie, Mingyue, et al., 2023b. A survey on blockchain consensus mechanism: research
overview, current advances and future directions. Int. J. Intell. Comput. Cybern.
16 (2), 314–340.
Xu, Shujiang, et al., 2024. Relay network-based cross-chain data interaction protocol
with integrity audit. Comput. Electr. Eng. 117, 109262.
Yamina, Khenfouci, Yacine, Challal, 2023. SuperChain: Decentralized and trustful
supervised learning over blockchain. In: 2023 Fifth International Conference on
Blockchain Computing and Applications. BCCA, IEEE.
Yeoh, Peter, 2017. Regulatory issues in blockchain technology. J. Financ. Regul.
Compliance 25 (2), 196–208.
Yizhong, Liu, et al., 2024. SS-DID: A secure and scalable Web3 decentralized identity
utilizing multi-layer sharding blockchain. IEEE Internet Things J..
Zetzsche, Dirk A., Arner, Douglas W., Buckley, Ross P., 2020. Decentralized finance
(defi). J. Financ. Regul. 6, 172–203.
Zhang, Li, Zhang, Baoxian, Li, Cheng, 2023a. An efficient and reliable byzantine
fault tolerant blockchain consensus protocol for single-hop wireless networks. IEEE
Trans. Wireless Commun..
Zhang, Mengqian, et al., 2021. Accelerating transactions relay in blockchain networks
via reputation. In: 2021 IEEE/ACM 29th International Symposium on Quality of
Service. IWQOS, IEEE.
Zhang, Jiashuo, et al., 2022. Xscope: Hunting for cross-chain bridge attacks. In: Pro-
ceedings of the 37th IEEE/ACM International Conference on Automated Software
Engineering.
Zhang, Zongyang, et al., 2023b. Ligerolight: Optimized IOP-based zero-knowledge
argument for blockchain scalability. IEEE Trans. Dependable Secure Comput..
Zhao, Qianrui, et al., 2023. A comprehensive overview of security vulnerability
penetration methods in blockchain cross-chain bridges. Authorea Preprints.
Zheng, Zibin, et al., 2020. An overview on smart contracts: Challenges, advances and
platforms. Future Gener. Comput. Syst. 105, 475–491.
Zhu, Linkai, et al., 2023. Optimized cross-chain mechanisms for secure and reliable
domain information synchronization in blockchain-driven networks. In: CCF China
Blockchain Conference. Springer Nature Singapore, Singapore.
Zibin, Zheng, et al., 2018. Blockchain challenges and opportunities: A survey. Int. J.
Web Grid Serv. 14 (4), 352–375.
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb152
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb152
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb152
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb152
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb152
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb153
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb153
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb153
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb154
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb154
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb154
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb154
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb154
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb155
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb155
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb155
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb156
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb156
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb156
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb156
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb156
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb157
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb157
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb157
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb158
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb158
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb158
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb158
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb158
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb159
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb159
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb159
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb159
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb159
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb160
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb161
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb161
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb161
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb162
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb162
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb162
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb162
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb162
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb163
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb164
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb164
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb164
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb164
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb164
https://developers.libra.org/docs/state-machine-replication-paper
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb166http://refhub.elsevier.com/S1084-8045(24)00221-2/sb166
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb166
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb166
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb166
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb167
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb167
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb167
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb167
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb167
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb167
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb167
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb168
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb168
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb168
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb169
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb169
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb169
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb169
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb169
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb170
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb170
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb170
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb171
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb171
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb171
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb171
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb171
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb172
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb172
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb172
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb172
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb172
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb173
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb173
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb173
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb173
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb173
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb174
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb174
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb174
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb175
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb175
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb175
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb176
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb176
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb176
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb176
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb176
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb177
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb177
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb177
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb178
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb178
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb178
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb178
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb178
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb179
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb179
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb179
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb180
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb180
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb180
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb180
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb180
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb180
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb180
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb181
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb181
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb181
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb182
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb182
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb182
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb183
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb183
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb183
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb184
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb184
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb184
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb184
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb184
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb185
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb185
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb185
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb186
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb186
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb186
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb186
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb186
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb187
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb187
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb187
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb187
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb187
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb188
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb188
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb188
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb189
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb189
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb189
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb189
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb189
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb190
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb190
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb190
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb190
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb190
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb191
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb191
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb191
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb192
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb193
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb193
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb193
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb194
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb194
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb194
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb195
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb195
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb195
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb196
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb196
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb196
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb196
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb196
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb197
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb197
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb197
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb198
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb198
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb198
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb199
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb199
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb199
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb199
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb199
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb200
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb200
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb200
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb201
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb201
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb201
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb202
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb202
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb202
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb202
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb202
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb203http://refhub.elsevier.com/S1084-8045(24)00221-2/sb203
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb203
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb204
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb204
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb204
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb204
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb204
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb205
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb205
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb205
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb206
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb206
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb206
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb207
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb207
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb207
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb208
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb208
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb208
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb208
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb208
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb209
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb209
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb209
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb209
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb209
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb210
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb210
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb210
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb210
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb210
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb211
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb211
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb211
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb212
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb212
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb212
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb213
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb213
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb213
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb214
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb214
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb214
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb214
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb214
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb215
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb215
http://refhub.elsevier.com/S1084-8045(24)00221-2/sb215
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Saeed Banaeian Far received the B.Sc and M.Sc degrees in
electrical engineering from Yadegar-e-Imam Khomeini (rah),
Shahr-e-Rey Branch Islamic Azad University Tehran, Iran,
in 2012, and 2016, respectively. He got his Ph.D. degree
from the Department of Electrical and Computer Engineer-
ing, Science and Research Branch, Islamic Azad University,
Tehran, Iran in 2023. He is now head of the Blockchain
and Metaverse research lab (BMRL). His research interests
include cryptography and network security, privacy, pri-
vacy in blockchain-based security protocols, digital twin
technology, and blockchain’s derived technologies (e.g., 3D
Internet, Metaverse, Web3, NFT, dNFT). He also cooperates
with international journals as a referee, including The
Computer Journal, IET Blockchain, The Journal of Super
Computing, Peer-to-Peer Networking and Application, Ex-
pert Systems with Applications, Automation in Construction,
SN Computer Sciences, Information Fusion Transactions on
Multimedia Computing Communications and Applications,
IEEE Wireless Communication Magazine, Energy Strategy
Reviews, IEEE Networking Letters, Cybersecurity and Ap-
plication, Information Fusion, Future Generation Computer
Systems, Journal of Parallel and Distributed Computing,
37 
International Journal of Medical Informatics, Economic
analysis and policy.
Seyed Mojtaba Hosseini Bamakan is an Assistant Professor
at the Department of Management and Data Science, Yazd
University, Iran and a visiting professor under CAS Presi-
dent’s International Fellowship Initiative (PIFI) at the Center
for High Performance Computing, Shenzhen Institutes of
Advanced Technology (SIAT), Shenzhen, China. He was a
postdoctoral researcher at Shenzhen Institute of Advanced
Technology (SIAT), Chinese Academy of Sciences (CAS)
in 2018. He received his Ph.D. degree in Data Science
from University of Chinese Academy of Sciences (UCAS).
He has authored multiple articles in peer-reviewed sci-
entific journals, including Journal of Cleaner Production,
Knowledge-Based Systems, Expert Systems with Applica-
tions, Energy, Neurocomputing and Computational Design
and Engineering. His current research interests include
blockchain technology, business intelligence, data mining,
and intelligent optimization techniques.
	Third layer blockchains are being rapidly developed: Addressing state-of-the-art paradigms and future horizons
	Introduction
	Contribution
	Survey methodology and references filtering
	Organization
	Preliminaries
	Blockchain
	Consensus
	State machine and smart contract
	DApp
	Layers
	Zero knowledge
	Generic ZKP
	zk-SNARK
	zk-STARK
	On-chain and off-chain transactions
	Lightning network
	Rollup
	zk-Rollups
	Interoperability
	Cross-chain
	CCIP
	Sonic
	Multi-chain
	Omni chain
	Scalability
	App-chain
	Para-chain
	Polkadot
	Kusama
	Side-chain
	Polygon
	Loom Network
	Gnosis
	Skale
	Super-chain
	Hyper-chain
	Discussion and future directions
	Opportunities
	Universal DeFi
	Education
	Healthcare systems
	Challenges
	Being distributedly
	Security and privacy
	Throughput and reliability
	Future directions
	Being distributedly
	Security and privacy
	Throughput and reliability
	Conclusion
	CRediT authorship contribution statement
	Ethics approval and consent to participate
	Funding
	Declaration of competing interest
	Acknowledgments
	Data availability
	Referencesthe concept
of L3 blockchains, which have so far been primarily driven by
industry initiatives. By bringing L3 concepts into the academic
discourse, this study lays the foundation for future research and
development in this rapidly evolving domain.
2. Comprehensive Terminology Clarification: We provide a detailed
examination and clarification of the numerous terms associated
with L3 solutions, such as app-chain, side-chain, omni-chain,
para-chain, cross-chain, multi-chain, hyper-chain, super-chain,
mega-chain, and ultra-chain. Despite the apparent similarity of
these terms, our analysis highlights the significant differences in
their goals, architectures, and functionalities. This clarification
is crucial for both researchers and practitioners to navigate the
complexities of L3 solutions effectively.
3. Novel Categorization of L3 Solutions: The study introduces a novel
framework for categorizing L3 projects into two primary groups:
interoperability and scalability solutions. By doing so, it provides
a structured approach to understanding the diverse landscape
of L3 technologies and their respective contributions to the
blockchain ecosystem. This categorization not only simplifies
the complexity of L3s but also aids in identifying the specific
challenges and opportunities within each category.
4. SWOT Analysis of L3 Solutions: We conduct a thorough SWOT
analysis of both interoperability and scalability solutions within
the L3 domain. This analysis offers a strategic overview of the
current state of L3 technologies, highlighting their potential to
overcome existing blockchain limitations while also identifying
the risks and challenges that must be addressed to realize their
full potential.
5. Introduction of Universal DeFi: One of the most exciting contribu-
tions of this study is the introduction of the concept of Universal
DeFi as a promising application of L3 technologies. We discuss
how L3s can significantly reduce transaction costs, enhance the
security of crowdfunding, and improve distributed lending and
borrowing processes. This novel concept underscores the trans-
formative potential of L3s in revolutionizing the DeFi landscape.
6. Mapping the Blockchain Trilemma to L3s: The paper offers a
unique perspective by mapping the well-known blockchain
trilemma (scalability, security, decentralization) onto L3 solu-
tions. By doing so, we identify current challenges from an L3
perspective, providing insights into how L3s can be designed
to balance these three critical factors more effectively than
previous layers.
https://polkadot.network/development/docs/
S. Banaeian Far and S.M. Hosseini Bamakan
o
o
h
o
t
p
s
o
t
m
p
o
y
s
b
r
a
o
a
e
i
o
c
h
e
B
a
t
e
Journal of Network and Computer Applications 233 (2025) 104044 
Table 1
Technically deep references bounded by year.
Year bound Journal Conference ePrints Reports Patents Total
papers articles
Before 2000 0 0 0 0 0 0
2000–2009 1 1 0 0 0 2
2010–2019 3 4 1 0 0 8
2020–2024 6 10 5 2 4 27
Total 10 15 6 2 4 37
Table 2
Important references categorized by keywords.
Searched keyword Number of reference(s)
Blockchain 17
Cryptography 10
Consensus 5
Privacy 4
Public key infrastructure 4
Security 4
Data integrity 3
Smart contracts 3
Atomic swaps 3
Cross-Chain 3
Multi-party computation 2
Proof of existence 2
Zero-knowledge proof 2
Dynamic data auditing 2
IoT 2
Homomorphic encryption 1
Multi-layer consensus 1
Merkle trees 1
Hybrid consensus 1
Distributed ledger 0
7. Future Directions and Research Roadmap: Finally, the study con-
cludes with a forward-looking discussion on the future directions
of L3 technologies, both in academic research and industry appli-
cations. We offer a strategic roadmap for researchers interested
in exploring recent advances in blockchain interoperability and
scalability, setting the stage for future breakthroughs in this
field.
This study not only highlights the potential of L3 solutions to ad-
dress the current limitations of blockchain technology but also provides
a solid foundation for future research and innovation in this promising
area.
1.2. Survey methodology and references filtering
In this study, we first compiled all references obtained from the
article’s bibliography and ensured to capture details such as author
names, titles, publication sources, and publication years. We then tax-
nomized more important of them into five main categories: (𝑖) Journal
Papers: The references published in peer-reviewed journals. This cate-
gory typically includes articles that undergo rigorous review processes.
Hence, journal papers are considered the most reliable category. (𝑖𝑖)
Conference Articles: Include references from conference proceedings,
ften presenting novel research findings and developments. Several
igh-rank conferences/summits can be at the level of top journals, and
thers are known as moderate or low levels. Therefore, we have tried
o select articles published in high-rank conferences. (𝑖𝑖𝑖) ePrints are
reprints or electronic prints available online, often on platforms like
arXiv or institutional repositories. Selecting this type of document is
very sensitive and requires knowing the authors and a deep under-
tanding of a topic. (𝑖𝑣) Reports: Include technical reports, whitepapers
f projects, or government reports that contribute relevant insights
o the study. (𝑣) Patents: Identify references that are patented, which
ay showcase technological innovations and applications. The selected
atents for this study are selected via the Google patent. This category
 t
4 
is illustrated in Table 1. It is highlighted that Table 1 refers to this type
f category and technically deep references that have been bounded by
ear.
Table 2 utilizes keywords from the titles of important references to
categorize them into relevant topics or themes. Most-used keywords can
include terms related to blockchain, cryptography, security protocols,
and distributed systems.
Our approach ensures clarity and organization in presenting the
ources used in your article, categorized by type, year, and relevance
ased on title keywords, and it adjusts the numbers based on the actual
eferences we have for a precise reflection of our research methodology
nd filtering process. Tables 1 and 2 provide a clear breakdown of the
references based on both publication year ranges and keywords in their
titles.
1.3. Organization
The rest of the paper is organized as follows.
Section 2 briefly identifies paper preliminaries. As two main sec-
tions of this study, Section 3 identifies several important interoper-
ability solutions known as L3 blockchains, and Section 4 addresses
another critical category of solutions for blockchain scalability relying
n L3s. Section 5 provides a discussion on the aforementioned solu-
tions and clarifies opportunities, challenges, and future horizons of L3
blockchains. Finally, Section 6 concludes this study.
2. Preliminaries
This section identifies the technical preliminaries of this study, and
Table 3 shows the acronyms used in this paper.
2.1. Blockchain
Blockchain is a decentralized and distributed digital ledger technol-
ogy designed to securely record and verify transactions across multiple
computers in a way that ensures data integrity and transparency (Till
nd Hartenstein, 2018; Satoshi, 2008; Zibin et al., 2018). Its main goal
is to enable secure, tamper-proof transactions without the need for
intermediaries such as banks or central authorities, fostering a trustless
nvironment. Exciting properties of blockchain include its immutabil-
ty, as once data is written, it cannot be altered without the consensus
f the network, and its transparency, providing a clear audit trail that
an be publicly verified. Additionally, blockchain’s use of cryptographic
ashing and consensus mechanisms like Proof of Work (PoW) (Aggelos
and Zindros, 2020) or Proof of Stake (PoS) (Sunny and Nadal, 2012)
ensures robust security and resilience against fraud and cyber-attacks,
making it a promising foundation for applicationsbeyond cryptocur-
rency, such as supply chain management, voting systems, and digital
identity verification.
2.1.1. Consensus
The goal of consensus in blockchain technology is to achieve agree-
ment among distributed nodes on the state of the blockchain ledger
(Bamakan et al., 2020). This agreement ensures that all participants in
the network have a consistent and tamper-proof record of transactions.
Consensus protocols are fundamental for maintaining the integrity,
security, and trustworthiness of the blockchain, preventing double-
spending and other malicious activities by ensuring that only legitimate
transactions are added to the ledger.
Consensus mechanisms are crucial in blockchains because they
nable decentralized networks to function without a central authority.
y allowing multiple nodes to collectively agree on the validity of trans-
ctions and the state of the blockchain, consensus protocols facilitate
rustless interaction between participants. This decentralized approach
nhances security and resilience, as there is no single point of failure
hat can be exploited by attackers (Bamakan et al., 2020; Du et al.,
S. Banaeian Far and S.M. Hosseini Bamakan
f
m
s
v
‘
2
a
w
i
a
p
c
g
b
a
A
a
o
L
l
a
c
T
c
a
i
d
i
i
s
a
a
i
o
e
t
o
p
Journal of Network and Computer Applications 233 (2025) 104044 
Table 3
The list of acronyms and notations.
Acronym Description
3D Three-Dimensional
aBFT asynchronous Byzantine Fault Tolerance
AES Advanced Encryption Standard
AI Artificial Intelligence
BLS Boneh–Lynn–Shacham
CA Certificate Authority
CCIP Cross-Chain Interoperability Protocol
CRS Common Reference String
DAO Distributed Autonomous Organizations
DT Digital Twin
DeFi Decentralized Finance
DeSci Decentralized Science
DGK Distributed Key Generation
dPKI distributed Public Key Infrastructure
ECDSA Elliptic Curve Digital Signature Algorithm
EHR Electronic Health Records
ERC-∗∗∗ Ethereum Request for Comments-𝑁 𝑜.
FHE Fully Homomorphic Encryption
FunDeSci NFT-based fundraising for decentralized science
IBE Identity-based Encryption
IBC Inter-Blockchain Communication
ICO Initial Coin Offering
IoT Internet of Things
ML Machine Learning
MoT Metaverse of Everythings
MPC Multi-Party Computation
NFT Non-Fungible Tokens
NPoS Nominated Proof-of-Stake
PaaS Platform-as-a-Service
PHE Partially Homomorphic Encryption
PoE Proof of Existence
PoS Proof of Stake
PoW Proof of Work
SciFi Science Finance
SRO single-register-on
SSP Secret-Sharing Protocol
SWOT Strongness–Weakness–Opportunity–Threat
TPS Transactions Per Second
UI User Interface
UX User Experience
VSS Verifiable Secret Sharing
Web3 The third generation of Internet (blockchain-based)
zk-SNARK Zero-Knowledge Succinct Non-Interactive Argument of Knowledge
zk-STARK Zero-Knowledge Scalable Transparent Argument of Knowledge
ZKP Zero-Knowledge Proof
2017). Additionally, consensus protocols help in scaling blockchain
networks, allowing them to support a larger number of transactions and
participants.
Consensus mechanisms are implemented in L1, each with its unique
eatures and trade-offs. PoW requires nodes to solve complex mathe-
atical problems, ensuring security through computational effort, as
een in Bitcoin (Satoshi, 2008; Aggelos and Zindros, 2020). PoS selects
alidators based on the number of coins they hold and are willing to
‘stake’’ as collateral (Sunny and Nadal, 2012), as used in Ethereum
.0.6 Delegated Proof of Stake (DPoS) involves stakeholders voting for
 small number of delegates to validate transactions and create blocks,
hich is utilized by platforms like EOS7 and Tron.8 Proof of Author-
ty (PoA) relies on a set of pre-approved validators whose identities
re known and trusted, offering faster transactions and reduced com-
utational overhead, as implemented in the VeChain9 blockchain. A
omprehensive comparisons of most applicable consensus is presented
in Table 4.
6 https://ethereum.org/en/roadmap/.
7 https://docs.eosnetwork.com/.
8 https://developers.tron.network/.
9 https://docs.vechain.org/.
5 
Heterogeneous blockchain consensus methods can be related to-
ether through their role within a layered architecture, where each
layer handles different aspects of the blockchain’s operation. At the
ase, L1 provides the foundational infrastructure for interoperability
nd communication across multiple blockchains. An example is the
valanche consensus protocol, which operates at L1 by enabling scal-
ble, decentralized networks that can host heterogeneous blockchains
r subnets, each potentially running different consensus mechanisms.
1 consensus methods typically focus on creating a unified network
ayer to facilitate cross-chain transactions, data sharing, and the man-
gement of multiple blockchains.
The L2 protocols, such as Ethereum, operate on top of L1 and
are responsible for the direct execution of smart contracts, transaction
validation, and maintaining the state of a single blockchain. Ethereum
uses PoS following its transition from PoW, which focuses on achieving
onsensus for transactions and state updates within its own ecosystem.
he relationship between L1 and L2 consensus mechanisms lies in their
omplementary functions—L1 provides the cross-chain infrastructure
nd scalability, while L2 ensures the security, execution, and state
ntegrity of individual blockchains. This layered approach allows for
iverse consensus methods to coexist, enabling a more scalable and
nteroperable blockchain ecosystem.
Consensus protocols also play a vital role in executing smart con-
tracts, which are self-executing contracts with the terms directly written
nto code. By ensuring that all nodes agree on the outcome of con-
tract executions, consensus mechanisms guarantee that smart contracts
are executed consistently and correctly across the network. This con-
sistency is essential for the reliability and predictability of DApps,
enabling them to function as intended without the need for a trusted
third party.
2.1.2. State machine and smart contract
Autonomy in blockchain technology refers to the decentralized,
elf-regulating nature of the system, which operates without central
uthority through mechanisms like consensus algorithms. Consensus
lgorithms ensure all network participants, whether they are miners
n proof-of-work systems or validators in proof-of-stake systems, agree
n the validity of transactions and the state of the blockchain. Min-
rs/validators play crucial roles by validating transactions, securing
he network, and appending new blocks to the blockchain (Zheng
et al., 2020; Loi et al., 2016). On top of this, smart contracts act as
L2 solutions, providing automated and self-executing contracts based
on predetermined rules and conditions. These smart contracts operate
within the blockchain’s state machine (Sathyanarayanan et al., 2023;
Shehar et al., 2020), which ensures they function correctly and au-
tonomously according to the current state and transitions defined by
the underlying protocol.
In the following, a brief description of the inherent ‘‘State machine’’
f blockchain and the execution of ‘‘Smart contracts’’ on blockchains is
rovided.
• State machine: The state machine in blockchains is a formalized
model consisting of states, transitions, and rules that govern
how the blockchain’s state evolves over time. Each block in the
blockchain represents a state transition triggered by transactions
that include, among other operations, the invocation of smart
contracts (Sathyanarayanan et al., 2023; Shehar et al., 2020).
When a smart contract is executed, the state machine processes
the contract’s code and the input parameters to determine the
resulting state. This deterministic processing is critical for the
autonomous execution of smart contracts, as it ensures that all
nodes in the network can independently and consistently verify
the contract’s outcomes. By strictly adhering to the defined state
transitions, the state machine provides a reliable and tamper-
proof mechanism for running smart contracts without the need
for centralizedoversight or intermediaries.
https://ethereum.org/en/roadmap/
https://docs.eosnetwork.com/
https://developers.tron.network/
https://docs.vechain.org/
S. Banaeian Far and S.M. Hosseini Bamakan
m
d
h
a
t
i
e
Journal of Network and Computer Applications 233 (2025) 104044 
Table 4
The comparison of consensus mechanisms.
Comparing
items
PoW PoS DPoS PoA PoB PoE BFT PBFT aBFT
Energy
consumption
High due to
mining
Low Low Low Moderate Low Low Low Low
Scalability Moderate High High High Moderate Moderate Moderate High High
Security High, relies
on computa-
tional power
High, relies
on stake
High, relies
on elected
delegates
High, relies
on validator
identity
High, relies
on economic
loss
High, relies
on
cryptographic
proof
Moderate,
relies on
majority
agreement
High, relies
on majority
and specific
tolerances
High,
optimized for
asynchronous
operations
Decentraliza-
tion
High Moderate to
high
Moderate to
low
Low High High Moderate Moderate High
Consensus
finality
Probabilistic
(multiple
confirma-
tions)
Deterministic
(single
confirmation)
Deterministic Deterministic Deterministic Deterministic Deterministic Deterministic Deterministic
Transaction
speed
Slow
(minutes)
Fast (seconds
to minutes)
Fast
(seconds)
Fast
(seconds)
Moderate
(minutes)
Fast
(seconds)
Moderate
(seconds to
minutes)
Fast
(seconds)
Fast
(seconds)
Resistance to
attacks
High,
susceptible to
51% attack
High,
susceptible to
51% attack
High,
susceptible to
collusion
High,
susceptible to
collusion
High,
requires
substantial
financial cost
High,
difficult to
forge proofs
Moderate,
susceptible to
malicious
nodes
High,
tolerant up to
1/3 malicious
nodes
Very high,
tolerant to a
high level of
faults
Complexity High,
complex
mining
process
Moderate,
simpler than
PoW
Moderate,
involves
delegate
voting
Low, simple
validation by
authority
Moderate,
involves
burning coins
Low, simple
cryptographic
proof
Moderate,
involves
multiple
node commu-
nication
High,
involves
intricate
agreement
protocols
High,
involves
intricate
agreement
protocols
Reward
distribution
Miners
rewarded
with new
coins
Validators
rewarded
with
transaction
fees
Delegates
rewarded
with
transaction
fees
Validators
rewarded
with
transaction
fees
Burners
rewarded
with new
coins
No rewards,
service proof
only
Rewards or
penalties
based on
node
behavior
Rewards or
penalties
based on
node
behavior
Rewards or
penalties
based on
node
behavior
Use cases Bitcoin,
Ethereum
(pre-2.0)
Ethereum
2.0, Cardano
EOS, TRON VeChain, PoA
Network
Slimcoin Proving
existence of
documents
and data
Early
blockchain
networks
Hyperledger,
Zilliqa
Fantom,
Avalanche
t
f
F
r
t
a
F
a
c
b
• Smart contract: Smart contracts are self-executing programs stored
on the blockchain that automatically enforce and execute the
terms of an agreement when predefined conditions are met (Szabo,
1997). The execution of smart contracts in blockchain environ-
ments relies heavily on state machines. A state machine in this
context is a computational model that defines the possible states
of the system and the transitions between these states based
on executed operations. When a smart contract is invoked, the
blockchain’s state machine processes the input data and the
contract’s code to transition from the current state to a new state,
ensuring all operations adhere to the rules and constraints of
the blockchain protocol (Zheng et al., 2020; Loi et al., 2016).
This process ensures deterministic and verifiable execution, essen-
tial for maintaining trust and integrity within the decentralized
system.
The relation between state machine and smart contract (Anastasia
and Laszka, 2018; Mantas and Butkienė, 2022; Chiara et al., 2024):
Smart contracts on public blockchains are inherently tied to the state
achines of their respective hosting blockchains. These state machines
efine the framework within which smart contracts operate, dictating
ow state transitions occur in response to contract executions. When
 smart contract is deployed and invoked, the state machine ensures
hat each step of the contract’s logic is executed deterministically and
n accordance with the blockchain’s consensus rules. This relationship
nsures that the contract’s state changes are consistent across all net-
work nodes, providing transparency and trust. The state machine’s role
is to enforce the correct execution order and state transitions, enabling
smart contracts to function autonomously and securely. This interplay
6 
between smart contracts and state machines underpins the decentral-
ized and reliable nature of blockchain-based applications, ensuring that
contract outcomes are predictable, verifiable, and immutable.
2.1.3. DApp
DApps are software applications built on a decentralized network,
typically a blockchain. Unlike traditional applications running on cen-
ralized servers controlled by a single entity, DApps leverage a peer-to-
peer (P2P) network of computers or nodes. This distributed architecture
osters several exciting properties (Peilin et al., 2023; Harjot, 2023).
irst, it enhances security and censorship resistance. Data and code are
eplicated across the network, making them tamper-proof and resistant
o single points of failure. Second, DApps promote transparency, as
ll transactions and codes are publicly verifiable on the blockchain.
inally, they empower user autonomy, as applications operate without
 central authority controlling access or functionality. These attributes
ontribute to the growing popularity of DApps, particularly within the
lockchain ecosystem.
The execution of DApps hinges on smart contracts, self-executing
code stored on the blockchain. These contracts define the rules and
logic governing DApp functionality (Far et al., 2023b). When users
interact with a DApp, they trigger the execution of relevant smart
contracts on the blockchain network. Nodes then collectively verify
and execute the code, ensuring a secure and transparent process. This
eliminates the need for intermediaries, fostering trust and reducing
transaction costs. Additionally, smart contracts enable autonomous
operation of DApps, as predefined conditions within the code auto-
matically execute actions upon specific events (Far et al., 2023b). This
paves the way for innovative applications with built-in features like
automated payments or secure data storage. However, the technical
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Fig. 1. The four-layer architecture of blockchain.
complexity of smart contract development and potential vulnerabil-
ities within the code itself remains ongoing areas of research and
improvement.
2.1.4. Layers
As clarified, blockchain is an Internet-based distributed ledger
(El Ioini and Pahl, 2018). However, the seven-layer TCP/IP Internet
architecture is assumed only the blockchain’s infrastructure. Generally,
blockchains are divided into four layers (0, 1, 2, and 3). Fig. 1 depicts
those mentioned layers, and the following descriptions technically
define each layer.
• L0 (Internet): The foundational layer providing the underlying
infrastructure, such as the internet and networking protocols, is
required for the higher blockchain layers to communicate and
operate. This layer ensures the connectivity and data transfer
essential for blockchain activities which TCP/IP (Wright and
Richard Stevens, 1995) (Transmission Control Protocol/Internet
Protocol), and HTTP/HTTPS (Gourley and Totty, 2002) (Hyper
Text Transfer Protocol/Secure) are two famous protocols.
7 
• L1 (Distributed ledger technology): The base layer where the
blockchain itself operates, implementing the consensus mech-
anism (Aggelos and Zindros, 2020; Sunny and Nadal, 2012),
data structure, and basic transaction protocols. It ensures secure,
immutable, and decentralized record-keeping (Satoshi, 2008). Bit-
coin, Ethereum, Fantum, and Avalanche are the most well-known
L1 blockchains.
• L2 (Smart contracts and DApps): This layer buildson the
blockchain to enable more complex operations through smart
contracts (self-executing contracts with the terms of the agree-
ment directly written into code) and decentralized applications
(DApps) (Peilin et al., 2023; Harjot, 2023). It enhances scalability
and functionality. the Polygon is a well-known Ethereum-based
network providing many achievements (Far et al., 2023b).
• L3 (Distributed bridges): The interoperability layer facilitates the
transfer of assets and data across different blockchain networks,
enabling communication and value exchange between disparate
blockchains. It addresses the issue of blockchain isolation by
connecting various networks (Kannengießer et al., 2020;
S. Banaeian Far and S.M. Hosseini Bamakan
a
a
i
a
c
a
f
S
p
o
a
w
𝑥
Journal of Network and Computer Applications 233 (2025) 104044 
Table 5
A comparison between discussed ZKP subgroups.
Feature Generic ZKP zk-SNARK zk-STARK
Definition Interactive proof system Non-interactive, succinct proof Transparent, scalable proof
Goals Privacy-preserving verification Efficient, non-interactive proofs Scalable, transparent proofs
Famous
scheme/Contributor
Goldwasser, Micali, Rackoff Groth16 by Jens Groth Eli Ben-Sasson et al.
Main security goal Zero-knowledge Non-interactive zero-knowledge Transparent zero-knowledge
Protocol steps 1. Commitment, 2. Challenge, 3.
Response, and 4. Verification
1. Key Generation, 2. Proving, and 3.
Verification
1. Encoding, 2. Randomness, 3. Proof
Generation, and 4. Verification
Difference Interactives Requires trusted setup No trusted setup required
Usage in blockchain Private transactions Privacy-preserving cryptocurrencies Scalability solutions
Enhancing
security/Privacy
Validating cross-chain transactions Efficient cross-chain validation Scalable and transparent validation
Cost comparisons High interaction cost Trusted setup cost Lower setup cost
Computational cost High due to interaction Low for verification Higher for prover, low for verifier
Communications
cost
High due to multiple rounds Low Moderate
Relation to L3 Versatile and can be adapted to
various L3 use cases, including niche
applications where SNARKs or
STARKs are less optimal.
Ideal for privacy-preserving
transactions and scalable verification
in L3 applications like private
payments and secure identity
management.
Suited for L3 applications requiring
high scalability and transparency,
such as rollups and data availability
layers.
m
e
a
i
Daghmehchi Firoozjaei et al., 2020; Lan et al., 2021). Polkadot,
Sonc, and Cosmos are introduced as two distributed bridges that
link several blockchains.
2.2. Zero knowledge
Zero-knowledge proofs (ZKPs) are cryptographic protocols that en-
ble one party (the prover) to convince another party (the verifier) that
 statement is true without revealing any information beyond the valid-
ty of the statement itself (Goldreich and Oren, 1994; Sun et al., 2021).
ZKPs are pivotal in applications requiring privacy and security, such
as authentication systems and blockchain technologies. They ensure
properties like completeness (if the statement is true, the verifier will be
convinced), soundness (if the statement is false, the verifier will not be
convinced), and zero knowledge (no information about the statement is
revealed to the verifier). The following subsections describe three types
of ZKPs and their usage in blockchain-based systems and distributed
bridges (or L3s) and Table 5 compares them (Table 5 outlines the key
spects of generic ZKPs, zk-SNARKs, and zk-STARKs, emphasizing their
differences in definition, goals, security properties, protocols, and their
impact on blockchain-based systems).
2.2.1. Generic ZKP
A generic zero-knowledge proof is a proof system where the prover
onvinces the verifier that a certain statement is true without revealing
ny additional information. These are interactive proofs where multiple
rounds of communication can occur between the prover and the veri-
ier. The original concept of zero-knowledge proofs was introduced by
hafi Goldwasser, Silvio Micali, and Charles Rackoff in their seminal
aper (Fiege et al., 1987).
The primary goal is to provide a framework that ensures the veracity
f a claim while maintaining the privacy of the underlying data. The
main security goal is to ensure that no information other than the
validity of the statement is revealed, even if the verifier tries to extract
dditional information. In a formal description, consider a scenario
here the prover wants to prove knowledge of a secret 𝑥 such that
2 ≡ 𝑦 𝑚𝑜𝑑 𝑛 without revealing 𝑥. The basic protocol of this type of
ZKP is now reviewed in the following four steps (Fiege et al., 1987).
1. Commitment: Prover picks a random 𝑟 ∈ Z∗
𝑛 and computes 𝑎 = 𝑟2
𝑚𝑜𝑑 𝑛. Then, prover sends 𝑎 to the verifier.
2. Challenge: Verifier sends a random bit 𝑏 ∈ {0, 1}.
8 
3. Response: If 𝑏 = 0, prover sends 𝑟 to the verifier. Else, prover
sends 𝑠 = 𝑟.𝑥 𝑚𝑜𝑑 𝑛 to the verifier.
4. Verification: If 𝑏 = 0 verifier checks 𝑎 ≡ 𝑟2 𝑚𝑜𝑑 𝑛. Else, verifier
checks 𝑎.𝑦 ≡ 𝑠2 𝑚𝑜𝑑 𝑛.
Generic ZKPs are interactive and require multiple rounds of com-
unication (Ernstberger et al., 2024), unlike non-interactive variants
like zk-SNARKs (Luong and Park, 2022) and zk-STARKs (Ben-Sasson
t al., 2019). Generic ZKPs can be used for private transactions, en-
suring the correctness of transactions without revealing the details.
They can secure cross-chain transactions by validating proofs without
exposing sensitive information, thus preventing data leaks and ensuring
transactional privacy.
2.2.2. zk-SNARK
zk-SNARK stands for ‘‘Zero-Knowledge Succinct Non-Interactive Ar-
gument of Knowledge’’. It is a type of ZKP that allows for a non-
interactive proof that is both succinct and verifiable in constant time.
One of the most famous zk-SNARK schemes is Groth16, proposed by
Jens Groth (Lipmaa, 2024).
The goal is to provide efficient and scalable proof systems that
re non-interactive and succinct. Security items which are enabled
n zk-SNARKs are used to ensure soundness and zero-knowledge in a
non-interactive manner, allowing for efficient verification. The basic
protocol of this type of ZKP is now reviewed in the three below
steps (Luong and Park, 2022).
1. Key Generation: A trusted setup generates public parameters
{𝑝𝑘, 𝑣𝑘}. This involves creating a common reference string (CRS)
using bilinear pairings. For example, given a pairing-friendly
elliptic curve, we generate a structured reference string (SRS).
2. Proving: Prover computes a proof 𝜋 = (𝐴 = 𝑔𝑎1 , 𝐵 = 𝑔𝑏2, 𝐶 = 𝑔𝑐1)
for some 𝑎, 𝑏, and 𝑐 derived from the circuit and witness 𝑤 using
the public parameters and the 𝑤.
3. Verification: Verifier uses the verification key to check the proof
𝜋. Finally, the verifier checks 𝑒(𝐴, 𝐵) = 𝑒(𝑔1, 𝑔2)𝑐 where 𝑒 is a
bilinear pairing defined as a map 𝑒 ∶ G1 ×G1 → G2 that ∀𝑃 , 𝑄 ∈
G1 and ∀𝑎, 𝑏 ∈ Z𝑝 has following formalized properties (Boneh
and Franklin, 2001).
(a) Bilinearity: 𝑒(𝑎𝑃 , 𝑏𝑄) = 𝑒(𝑃 , 𝑄)𝑎𝑏.
(b) Non-degeneracy: 𝑒(𝑃 , 𝑃 ) ≠ 1𝑝.
(c) Computability: ∀𝑃 , 𝑄 ∈ G1, 𝑒(𝑃 , 𝑄) is computable.
S. Banaeian Far and S.M. Hosseini Bamakan
z
p
e
t
m
s
s
i
b
c
c
n
o
d
a
E
f
a
c
i
m
r
m
R
p
a
l
a
b
w
o
l
a
z
Journal of Network and Computer Applications 233 (2025) 104044 
zk-SNARKs are non-interactive and require a trusted setup, unlike
k-STARKs which do not require a trusted setup. Used in privacy-
reserving cryptocurrencies like Zcash to hide transaction details while
nsuring their correctness (Hopwood et al., 2016). zk-SNARKs can
validate cross-chain transactions efficiently, reducing the need for in-
eraction and maintaining the confidentiality of transaction data.
2.2.3. zk-STARK
zk-STARK stands for ‘‘Zero-Knowledge Scalable Transparent Argu-
ent of Knowledge’’. It is a type of ZKP that is transparent (no trusted
etup required) and scalable. The concept of zk-STARKs was introduced
by Eli Ben-Sasson,Michael Riabzev, and others (Ben-Sasson et al.,
2019).
Main goal of zk-STARK are providing scalability and transparency
proof systems without relying on a trusted setup. Moreover, security
policies provide soundness and zero-knowledge in a transparent and
calable manner. The basic protocol of this type of ZKP is now reviewed
n the following four steps (Ben-Sasson et al., 2019).
1. Encoding: Prover encodes the statement into a polynomial 𝑃 (𝑥).
For example, if proving a computation, the polynomial repre-
sents the steps of the computation.
2. Randomness: Using public randomness, prover generates a low-
degree extension 𝑃 (𝑥).
3. Proof Generation: Prover commits to 𝑃 (𝑥) and generates a Merkle
tree of evaluations. Then, the prover sends the root of the Merkle
tree and some evaluations to the verifier.
4. Verification: Verifier checks the low-degree property and consis-
tency of the polynomial evaluations using the Merkle tree proofs.
This involves checking consistency at randomly chosen points.
zk-STARKs do not require a trusted setup and are designed to
e more scalable than zk-SNARKs. Employed in projects like Stark-
Ware10 to ensure scalability and security for blockchain applications.
zk-STARKs can provide scalable proof verification for cross-chain trans-
actions, ensuring transparency and robustness without compromising
on security.
2.3. On-chain and off-chain transactions
On-chain transactions refer to cryptocurrency transactions that are
recorded directly on the blockchain. The network’s nodes verify and
confirm these transactions, becoming part of the immutable public
ledger (Satoshi, 2008; El Ioini and Pahl, 2018; Gu et al., 2022). On-
chain transactions are decentralized and transparent, ensuring that
every transaction is publicly recorded and verifiable. However, the pro-
ess can be slow and expensive, especially during times of high network
ongestion, as each transaction requires confirmation from multiple
odes and incurs transaction fees (Miyachi and Mackey, 2021).
Off-chain transactions, on the other hand, occur outside the main
blockchain network. These transactions are typically facilitated by sec-
ndary layers or protocols that interact with the primary blockchain but
o not require immediate recording on it (Gudgeon et al., 2019). Off-
chain transactions are faster and can be more cost-effective, as they do
not require every transaction to be broadcasted to and confirmed by the
entire network. Key differences between on-chain and off-chain trans-
actions include speed, cost, and the level of decentralization (Tochner
et al., 2020). Two notable examples of off-chain transaction methods
re the Lightning Network11 for Bitcoin and the Plasma framework12 for
thereum. The following provides a discussion of several practical and
amous methods of off-chain and L2-based transactions, and Table 6
presents a comparison between them in several aspects.
10 https://starkware.co/.
11 https://lightning.network/.
12 https://www.learnplasma.org/en/learn/framework.
9 
2.3.1. Lightning network
The Lightning Network is a second-layer solution for Bitcoin, de-
signed to facilitate faster and cheaper transactions by creating a net-
work of payment channels. These channels allow parties to trans-
ct off-chain, only broadcasting the final state of the transactions to
the blockchain when the channel is closed. This reduces the load
on the Bitcoin blockchain, enabling microtransactions and enhancing
scalability.
The Lightning Network operates by establishing bi-directional pay-
ment channels between users. Once a channel is open, users can con-
duct numerous transactions off-chain (Gudgeon et al., 2019; Aumayr
et al., 2022). The balance is updated in real-time between the parties,
but the blockchain is only updated when the channel is closed. This
off-chain mechanism significantly speeds up transactions and reduces
fees.
The Lightning Network offers several benefits, including reduced
transaction fees, faster transaction times, and increased scalability for
the Bitcoin network. However, it also has weaknesses, such as the
omplexity of setting up and maintaining channels, potential liquidity
ssues, and security risks like the requirement for both parties to be
online to transact (Poon and Dryja, 2016). Challenges include ensuring
network reliability and managing routing complexities. Security risks
involve the potential for fraud if one party attempts to close a channel
with an outdated state.
2.3.2. Rollup
Rollups are L2 scaling solutions for blockchain networks that bundle
multiple transactions into a single batch, which is then recorded on the
ain blockchain. This approach increases transaction throughput and
educes costs by offloading the bulk of transaction processing from the
ain chain to the Rollup (Thibault et al., 2022; Bruschi et al., 2022;
Kotzer et al., 2024).
Some of the most prominent Rollup projects include Optimistic
ollups13 and zk-Rollups.14 Optimistic Rollups, such as those used by
rojects like Optimism, rely on a fraud-proof system where transactions
re assumed valid until proven otherwise. zk-Rollups, used by projects
ike zkSync,15 employ zero-knowledge proofs to ensure the validity of
transactions.
Key issues in Rollup transactions include ensuring the security of
off-chain data, managing the complexity of smart contracts involved,
nd dealing with potential delays in transaction finality. Rollups offer
enefits such as improved scalability and reduced fees but also have
eaknesses, including potential centralization risks and the complexity
f implementation.
2.3.3. zk-rollups
zk-Rollups, or zero-knowledge Rollups,16 are a type of Rollup that
uses zero-knowledge proofs to verify the correctness of off-chain trans-
actions. This cryptographic approach ensures that transactions are valid
without revealing the underlying data. zk-Rollups are enhanced by
their ability to provide high security and privacy, as zero-knowledge
proofs allow for transaction validation without exposing sensitive in-
formation (Lavaur et al., 2022, 2023). This is particularly beneficial
for applications requiring confidentiality.
The primary difference between Rollup and zk-Rollup transactions
ies in the method of validation. While Rollups use a batch processing
pproach with optimistic validation or fraud proofs, zk-Rollups utilize
ero-knowledge proofs to validate transactions instantly and securely.
zk-Rollups offer enhanced security and privacy compared to tradi-
tional Rollups, as the zero-knowledge proofs ensure that no transaction
13 https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/.
14 https://chain.link/education-hub/zero-knowledge-rollup.
15 https://zksync.io/.
16 https://ethereum.org/en/developers/docs/scaling/zk-rollups/.
https://starkware.co/
https://lightning.network/
https://www.learnplasma.org/en/learn/framework
https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/
https://chain.link/education-hub/zero-knowledge-rollup
https://zksync.io/
https://ethereum.org/en/developers/docs/scaling/zk-rollups/
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Table 6
A comparison between transaction methods.
Aspect On-chain Off-chain Transactions of Bitcoin’s lightning Rollup zk-Rollup
transactions transactions network transactions transactions
Security High Variable High but dependent on channels High Very high
Privacy Low Variable Low Low High
Anonymity Low Variable Low Low High
Confidentiality Low Variable Low Low High
Scalability Low High Very high High Very high
Fee High Low Very low Low Very low
Computational cost High Low Moderate Moderate High
Communication cost High Low Low Moderate High
Complexity of implementation Low Moderate High High Very high
Double spend attack Low Variable Low Low Very low
51% attack High Variable Low Low Very low
Fig. 2. The general presentation of cross-chain and multi-chain.
details are leaked. However, they also face challenges such as the com-
putationalintensity of generating proofs and the complexity of imple-
menting the cryptographic mechanisms. Opportunities include higher
scalability and better privacy features for blockchain applications.
3. Interoperability
There are several solutions for enhancing interoperability among
blockchains (Pillai et al., 2020; Anthony Jnr, 2024). Three important
of them will now addressed. Fig. 2 depicts the locating of cross-
chain and multi-chain among blockchain connections, Table 9 com-
pares interoperability platforms and addresses a distinguished feature
for each.
3.1. Cross-chain
A cross-chain mechanism enables seamless interoperability between
different blockchain networks, allowing them to communicate and
transfer assets or data. Primarily based on bridges, this solution fo-
cuses on facilitating blockchain interoperability by allowing different
blockchains to exchange data or value and conduct transactions with
one another (Maurice, 2018). However, it is important to acknowledge
that cross-chain projects are susceptible to security vulnerabilities and
potential attacks. Among the various cross-chain initiatives, Chain-
link’s Cross-Chain Interoperability Protocol (CCIP) stands out as the
most prominent and robust example (Diaz and Villagra, 2021) which
the ‘‘Transporter’’17 project is the most popular, and the ‘‘Sonic’’18
(Fantom Cross-Chain Communication Protocol) is another distributed
cross-chain technology will be developed relying on the potential of
Fantom. This project represents a pioneering step towards the future
of on-chain finance, where institutions require seamless integration of
their existing systems with L1s.
17 https://www.transporter.io/.
18 https://fantom.foundation/sonicPage.
10 
3.1.1. CCIP
As depicted in Fig. 3, CCIP takes a modular approach to cross-chain
communication.19 Its core component is a Router contract deployed
on each supported blockchain. This Router acts as a message relay,
receiving instructions from applications and forwarding them to the
appropriate counterpart chain. On each chain, OnRamp and OffRamp
contracts handle incoming and outgoing messages, respectively. Secu-
rity is a major focus, with the Risk Management Network overseeing
validation and anomaly detection. This network uses concepts like
‘‘Blessing’’ and ‘‘Cursing’’ by Chainlink’s decentralized oracle nodes to
ensure the legitimacy of messages and deter malicious behavior. Essen-
tially, CCIP facilitates cross-chain actions like asset transfers, message
passing, and data access through a secure and standardized framework.
3.1.2. Sonic
Fantom Sonic is the name that covers the new Fantom technology
stack, replacing the previous Opera. The new technology stack is in-
cluded in the new Fantom Sonic Client that validators and other nodes
will run to power the network, which comprises mainly the Fantom
Virtual Machine (FVM), Carmen database storage, and an optimized
Lachesis consensus mechanism.20
Sonic tackles cross-chain communication from a different angle.
It leverages Fantom’s Opera Chain, a Directed Acyclic Graph (DAG)
based blockchain known for its high throughput and scalability. These
differences cause to provide several enhancements for Sonic which
Tables 7 and 8 compare the Fantom Sonic and Opera chain proper-
ties. Sonic utilizes a network of validators on each connected chain.21
These validators secure communication by creating ‘‘validity proofs’’
that cryptographically demonstrate the legitimacy of a transaction on
their home chain. These proofs are then relayed to other chains for
19 https://blog.chain.link/transporter-launch/.
20 https://blog.fantom.foundation/fantom-foundation-launches-testnet-for-
fantom-sonic/.
21 Source of Tables 7 and 8: https://blog.fantom.foundation/fantom-
foundation-launches-testnet-for-fantom-sonic/.
https://www.transporter.io/
https://fantom.foundation/sonicPage
https://blog.chain.link/transporter-launch/
https://blog.fantom.foundation/fantom-foundation-launches-testnet-for-fantom-sonic/
https://blog.fantom.foundation/fantom-foundation-launches-testnet-for-fantom-sonic/
https://blog.fantom.foundation/fantom-foundation-launches-testnet-for-fantom-sonic/
https://blog.fantom.foundation/fantom-foundation-launches-testnet-for-fantom-sonic/
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Fig. 3. The Chainlink’s CCIP framework and detailed workflow.
Table 7
A general comparison between Fantom Sonic and Opera chain.
General feature Fantom Sonic (Carmen Scheme 3) Opera (1.1.2-rc.6)
Minimum consensus quorum 15 14
Validators’ stake share Equal Naturally distributed
Peak gas per day (B) 34,560 283.96
Peak gas per second (M) 405 3.28
Peak transaction per second (M) 2100 21
Archive node DB size (GB/100 M Tx) 180 2.160
Archive node DB at 518 M Tx (GB) 1000 10,893
Live pruned DB size at 518 M Tx (GB) 351 1904
Offline pruned DB size (GB) N/A 1.904
Table 8
A comparison between Fantom Sonic and Opera chain validators.
Validators feature Fantom Sonic (Carmen Scheme 3) Opera (1.1.2-rc.6)
Live pruning support Yes No
Minimum offline pruning downtime w/ standby node None 30 min
Full offline pruning downtime None 3–8 h
Validator hardware cost Low Higher
Validator operating cost Low Higher
Validator operating risk Low Higher
Average offline pruning period None 166 days
DB size growth rate (GB/day) 0.74 17.78
Time to full sync ≤2 days ≤4 weeks
verification, enabling trustless communication. Unlike CCIP’s modular
approach, Sonic operates as a single protocol, streamlining integration
for developers. Additionally, Sonic focuses on optimizing transaction
fees and latency, aiming for faster and more cost-effective cross-chain
interactions.
11 
As shown in Fig. 4, the FVM converts Ethereum Virtual Machine22
(EVM) bytecode of smart contracts seamlessly into a new virtual ma-
chine format on the fly (while executing transactions). Deployed smart
22 https://ethereum.org/en/developers/docs/evm/.
https://ethereum.org/en/developers/docs/evm/
S. Banaeian Far and S.M. Hosseini Bamakan Journal of Network and Computer Applications 233 (2025) 104044 
Fig. 4. The Fantom SONIC framework.
Table 9
A comparison between interoperability platforms and addressing a distinguished feature for each.
Feature Chainlink CCIP Fantom Sonic LayerZero Axelar
Primary
consensus
Decentralized oracles aBFT (DAG-based) ULN with relayers Decentralized validator
set
Cross-chain
architecture
Secure oracle-based
transfers
DAG for scalability Ultra-light nodes Universal cross-chain
support
Distinguished
feature
Oracle-powered security Fast finality via DAG Efficient ULNs Decentralized,
plug-and-play
contracts that are available only in EVM bytecode remain executable
without retranslating the high-level source code (e.g. Solidity) into the
new virtual machine format. Then, the FVM interacts with the LiveDB
and the ArchiveDB. As mentioned, the LiveDB contains only the current
world state and is optimized for progressing the world state from one
block to the next. Validators only have a LiveDB but no ArchiveDB. The
FVM reads and writes the data in the LiveDB. In contrast, archive nodes
have the LiveDB and ArchiveDB to stay synced. They process requests
of historical states via the RPC interface. Its data is read only by the
RPC server, and the FVM adds the world state of new blocks.
3.2. Multi-chain
Multi-chain refers to a system or platform that operates across
multiple independent blockchain networks, leveraging the unique
12 
capabilities and features of each to enhance functionality and scalabil-
ity (DApps, particularly DEXes and DeFi services, e.g., UniSwap, 1inch,
etc.). In this configuration, each DApp functions on a segregated collec-
tion of smart contracts distributed across various blockchains (Gavin,
2016). This approach significantly enhances the overall throughput,
facilitates user onboarding, and improves cost efficiency, allowing
for parallel network evolution. Nonetheless, the adoption of a multi-
chain approach also presents certain