<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Publishing DTD v1.1 20151215//EN" "http://jats.nlm.nih.gov/publishing/1.1/JATS-journalpublishing1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:mml="http://www.w3.org/1998/Math/MathML" xml:lang="en" article-type="review-article" dtd-version="1.1">
<front>
<journal-meta>
<journal-id journal-id-type="pmc">CMC</journal-id>
<journal-id journal-id-type="nlm-ta">CMC</journal-id>
<journal-id journal-id-type="publisher-id">CMC</journal-id>
<journal-title-group>
<journal-title>Computers, Materials &#x0026; Continua</journal-title>
</journal-title-group>
<issn pub-type="epub">1546-2226</issn>
<issn pub-type="ppub">1546-2218</issn>
<publisher>
<publisher-name>Tech Science Press</publisher-name>
<publisher-loc>USA</publisher-loc>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="publisher-id">66366</article-id>
<article-id pub-id-type="doi">10.32604/cmc.2025.066366</article-id>
<article-categories>
<subj-group subj-group-type="heading">
<subject>Review</subject>
</subj-group>
</article-categories>
<title-group>
<article-title>Navigating the Blockchain Trilemma: A Review of Recent Advances and Emerging Solutions in Decentralization, Security, and Scalability Optimization</article-title>
<alt-title alt-title-type="left-running-head">Navigating the Blockchain Trilemma: A Review of Recent Advances and Emerging Solutions in Decentralization, Security, and Scalability Optimization</alt-title>
<alt-title alt-title-type="right-running-head">Navigating the Blockchain Trilemma: A Review of Recent Advances and Emerging Solutions in Decentralization, Security, and Scalability Optimization</alt-title>
</title-group>
<contrib-group>
<contrib id="author-1" contrib-type="author" corresp="yes">
<name name-style="western"><surname>Reno</surname><given-names>Saha</given-names></name><xref ref-type="aff" rid="aff-1">1</xref><xref ref-type="author-notes" rid="afn1">#</xref><email>reno.saha39@gmail.com</email></contrib>
<contrib id="author-2" contrib-type="author">
<name name-style="western"><surname>Roy</surname><given-names>Koushik</given-names></name><xref ref-type="aff" rid="aff-2">2</xref><xref ref-type="author-notes" rid="afn1">#</xref></contrib>
<aff id="aff-1"><label>1</label><institution>Department of Computer Science and Engineering, Ahsanullah University of Science and Technology (AUST)</institution>, <addr-line>Dhaka, 1208</addr-line>, <country>Bangladesh</country></aff>
<aff id="aff-2"><label>2</label><institution>Department of Computer Science and Engineering, Bangladesh Army International University of Science and Technology (BAIUST)</institution>, <addr-line>Cumilla, 3501</addr-line>, <country>Bangladesh</country></aff>
</contrib-group>
<author-notes>
<corresp id="cor1"><label>&#x002A;</label>Corresponding Author: Saha Reno. Email: <email>reno.saha39@gmail.com</email></corresp>
<fn id="afn1">
<p><sup>#</sup>These authors contributed equally to this work</p>
</fn>
</author-notes>
<pub-date date-type="collection" publication-format="electronic">
<year>2025</year>
</pub-date>
<pub-date date-type="pub" publication-format="electronic">
<day>03</day><month>07</month><year>2025</year>
</pub-date>
<volume>84</volume>
<issue>2</issue>
<fpage>2061</fpage>
<lpage>2119</lpage>
<history>
<date date-type="received">
<day>07</day>
<month>4</month>
<year>2025</year>
</date>
<date date-type="accepted">
<day>19</day>
<month>5</month>
<year>2025</year>
</date>
</history>
<permissions>
<copyright-statement>&#x00A9; 2025 The Authors.</copyright-statement>
<copyright-year>2025</copyright-year>
<copyright-holder>Published by Tech Science Press.</copyright-holder>
<license xlink:href="https://creativecommons.org/licenses/by/4.0/">
<license-p>This work is licensed under a <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</ext-link>, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</license-p>
</license>
</permissions>
<self-uri content-type="pdf" xlink:href="TSP_CMC_66366.pdf"></self-uri>
<abstract>
<p>The blockchain trilemma&#x2014;balancing decentralization, security, and scalability&#x2014;remains a critical challenge in distributed ledger technology. Despite significant advancements, achieving all three attributes simultaneously continues to elude most blockchain systems, often forcing trade-offs that limit their real-world applicability. This review paper synthesizes current research efforts aimed at resolving the trilemma, focusing on innovative consensus mechanisms, sharding techniques, layer-2 protocols, and hybrid architectural models. We critically analyze recent breakthroughs, including Directed Acyclic Graph (DAG)-based structures, cross-chain interoperability frameworks, and zero-knowledge proof (ZKP) enhancements, which aim to reconcile scalability with robust security and decentralization. Furthermore, we evaluate the trade-offs inherent in these approaches, highlighting their practical implications for enterprise adoption, decentralized finance (DeFi), and Web3 ecosystems. By mapping the evolving landscape of solutions, this review identifies gaps in current methodologies and proposes future research directions, such as adaptive consensus algorithms and artificial intelligence-driven (AI-driven) governance models. Our analysis underscores that while no universal solution exists, interdisciplinary innovations are progressively narrowing the trilemma&#x2019;s constraints, paving the way for next-generation blockchain infrastructures.</p>
</abstract>
<kwd-group kwd-group-type="author">
<kwd>Blockchain trilemma</kwd>
<kwd>scalability</kwd>
<kwd>decentralization</kwd>
<kwd>security</kwd>
<kwd>consensus algorithms</kwd>
<kwd>sharding</kwd>
<kwd>layer-2 solutions</kwd>
<kwd>DAG-based architectures</kwd>
<kwd>cross-chain interoperability</kwd>
<kwd>blockchain optimization</kwd>
</kwd-group>
</article-meta>
</front>
<body>
<sec id="s1">
<label>1</label>
<title>Introduction</title>
<p>Blockchain technology has emerged as a revolutionary paradigm, offering decentralized, transparent, and tamper-resistant systems for applications ranging from cryptocurrencies to supply chain management [<xref ref-type="bibr" rid="ref-1">1</xref>]. Since the advent of Bitcoin in 2008 [<xref ref-type="bibr" rid="ref-2">2</xref>], blockchain technology has transcended its origins as a decentralized ledger for cryptocurrencies, evolving into a foundational technology with transformative potential across finance, supply chain, healthcare, and governance. At its core, blockchain promises a paradigm shift in trustless systems&#x2014;enabling peer-to-peer transactions without intermediaries while ensuring immutability and transparency. Despite its revolutionary promise, blockchain networks face an intrinsic limitation known as the Blockchain Trilemma, a term popularized by Ethereum&#x2019;s Vitalik Buterin [<xref ref-type="bibr" rid="ref-3">3</xref>]. This trilemma posits that a blockchain can only optimize two out of three critical properties&#x2014;decentralization, security, and scalability&#x2014;at the expense of the third.</p>
<p>Early blockchain designs, such as Bitcoin and Ethereum 1.0 [<xref ref-type="bibr" rid="ref-4">4</xref>], prioritized decentralization (anyone can participate) and security (resistance to attacks like 51% attacks) but struggled with scalability&#x2014;processing only a few transactions per second (TPS) [<xref ref-type="bibr" rid="ref-5">5</xref>] compared to traditional payment systems like Visa (50,000&#x002B; TPS). This limitation became evident during Bitcoin&#x2019;s 2017 congestion crisis, where transaction fees soared to over $50 due to network overload. Similarly, Ethereum&#x2019;s infamous CryptoKitties [<xref ref-type="bibr" rid="ref-6">6</xref>] incident in 2017 exposed how even modestly popular decentralized applications (dApps) could clog the network. These bottlenecks spurred a wave of research and experimentation, leading to a spectrum of proposed solutions&#x2014;each attempting to break the trilemma without sacrificing its core tenets. Some approaches, like sharding (dividing the blockchain into parallel chains) and layer-2 protocols (e.g., Zero-Knowledge Rollups (ZK-rollups), state channels), have shown measurable success. Others, such as delegated Proof-of-Stake (dPoS) [<xref ref-type="bibr" rid="ref-7">7</xref>] or federated blockchains [<xref ref-type="bibr" rid="ref-8">8</xref>], achieve scalability but at the cost of reduced decentralization&#x2014;a trade-off that remains controversial among blockchain purists. As blockchain adoption grows, the trilemma&#x2019;s implications extend beyond academic debate into real-world usability.</p>
<sec id="s1_1">
<label>1.1</label>
<title>Motivation and Open Challenges</title>
<p>Despite extensive research, resolving the blockchain trilemma remains an open challenge due to inherent architectural trade-offs and evolving adversarial landscapes. Current solutions often prioritize two attributes at the expense of the third, leading to fragmented ecosystems where blockchains specialize in narrow use cases. For instance, while sharding improves scalability, it introduces cross-shard latency and reduces per-shard decentralization. Similarly, layer-2 protocols like ZK-rollups enhance throughput but rely on centralized sequencers or trusted execution environments (TEEs), creating new attack surfaces. Emerging issues such as maximal extractable value (MEV) exploitation, quantum computing threats, and governance centralization further complicate the trilemma. Existing frameworks also lack adaptability to dynamic network conditions, limiting their applicability in heterogeneous environments like IoT or decentralized finance (DeFi). This paper addresses these gaps by proposing a holistic architecture that integrates hierarchical sharding, adaptive consensus, and zero-knowledge proofs (ZKPs) to dynamically balance trilemma dimensions. Our approach mitigates decentralization-security-scalability trade-offs through innovations such as optimistic cross-shard atomicity, reputation-based incentives, and modular governance&#x2014;advancing toward infrastructures capable of supporting global-scale decentralized applications without compromising core blockchain principles.</p>
<p>Enterprises exploring blockchain for supply chain tracking need scalability to handle millions of transactions. Governments implementing blockchain-based voting systems require security against manipulation. Meanwhile, decentralized finance (DeFi) [<xref ref-type="bibr" rid="ref-9">9</xref>] platforms demand decentralization to avoid centralized control. The inability to reconcile these needs has led to fragmented ecosystems where different blockchains specialize in different trade-offs&#x2014;e.g., Bitcoin (security &#x002B; decentralization), Solana (scalability &#x002B; security), and Polkadot (scalability &#x002B; interoperability) [<xref ref-type="bibr" rid="ref-10">10</xref>]. Recent years have seen unprecedented innovation in tackling the trilemma:
<list list-type="bullet">
<list-item>
<p>Consensus Mechanisms: From energy-intensive PoW to PoS (Ethereum 2.0) and beyond (e.g., Directed Acyclic Graphs [DAGs]) [<xref ref-type="bibr" rid="ref-11">11</xref>].</p></list-item>
<list-item>
<p>Layer-2 Scaling: Rollups (Optimistic, zk-Rollups), state channels (Lightning Network), and sidechains (Polygon).</p></list-item>
<list-item>
<p>Modular Blockchains: Separation of execution, consensus, and data availability (e.g., Celestia, EigenLayer).</p></list-item>
<list-item>
<p>Zero-Knowledge Proofs (ZKPs): Enhancing privacy and scalability simultaneously (e.g., zkSync, StarkNet).</p></list-item>
</list></p>
<p>Yet, no single solution has fully resolved the trilemma. Some layer-2 systems introduce new trust assumptions; sharding complicates cross-shard communication; and PoS networks risk centralization among large stakeholders. This ongoing tension underscores the need for a systematic review of progress, trade-offs, and future directions. This paper provides a comprehensive, critical analysis of recent advances in blockchain trilemma optimization, with three key goals:
<list list-type="bullet">
<list-item>
<p>Taxonomy of Solutions: Classify existing approaches by their trilemma trade-offs (e.g., &#x201C;high scalability, moderate decentralization&#x201D;).</p></list-item>
<list-item>
<p>Comparative Evaluation: Benchmark performance (TPS, finality time, node requirements) across prominent blockchains.</p></list-item>
<list-item>
<p>Emerging Paradigms: Highlight cutting-edge techniques (e.g., AI-driven consensus, quantum-resistant cryptography) that may redefine the trilemma.</p></list-item>
</list></p>
<p>Unlike prior surveys focused narrowly on scalability or security, this review integrates all three trilemma dimensions, offering a holistic view of how they interact. We emphasize real-world deployments (e.g., Ethereum&#x2019;s post-merge performance) alongside theoretical breakthroughs, bridging academia and industry perspectives.</p>
</sec>
<sec id="s1_2">
<label>1.2</label>
<title>Major Contributions</title>
<p>The presented work provides a systematic review of recent advancements in addressing the blockchain trilemma, emphasizing technical innovations, trade-offs, and practical implications. The major contributions of this paper are as follows:
<list list-type="bullet">
<list-item>
<p><bold>Holistic Integration of Trilemma Dimensions</bold></p>
<p>Unlike prior surveys focused narrowly on scalability or security, this review synthesizes decentralization, security, and scalability into a unified analytical framework. We critically examine interdependencies between these properties through real-world deployments (e.g., Ethereum post-Merge) and theoretical breakthroughs, bridging academic and industry perspectives.</p></list-item>
<list-item>
<p><bold>Taxonomy and Comparative Benchmarking of Solutions</bold></p>
<p>We classify 38 distinct approaches into 8 categories&#x2014;including sharding, layer-2 protocols, and hybrid architectures&#x2014;with granular trade-off labeling (e.g., &#x201C;high scalability, moderate decentralization&#x201D;). A comparative analysis benchmarks performance metrics (TPS, finality time, node requirements) across 15 major blockchains, revealing critical efficiency-security trade-offs.</p></list-item>
<list-item>
<p><bold>Analysis of Emerging Cryptographic and Architectural Paradigms</bold></p>
<p>The paper evaluates cutting-edge innovations such as zero-knowledge proof-augmented rollups, TEE-assisted consensus, and modular blockchain designs. We quantify their potential to reconcile the trilemma, including zero-knowledge Authenticated Multi-Hop Locks (zk-AMHLs) achieving 95% verification overhead reduction and RapidChain&#x2019;s 7300 TPS with sub-second latency.</p></list-item>
<list-item>
<p><bold>Practical Implications for Enterprise and Web3 Ecosystems</bold></p>
<p>Through case studies in DeFi, supply chain, and governance, we demonstrate how trilemma optimizations impact real-world adoption. Key findings include Visa-level throughput requirements for enterprise Distributed Ledger Technologies (DLTs) (50,000&#x002B; TPS) and decentralization thresholds (Nakamoto Coefficient <inline-formula id="ieqn-1"><mml:math id="mml-ieqn-1"><mml:mo>&#x2265;</mml:mo></mml:math></inline-formula>100) for trustless voting systems.</p></list-item>
<list-item>
<p><bold>Future Research Roadmap</bold></p>
<p>We identify underexplored areas such as AI-driven consensus tuning, cross-shard MEV resistance, and quantum-secure DAGs. The paper proposes 6 prioritized directions, including adaptive protocol switching frameworks and decentralized resource marketplaces for elastic scaling.</p></list-item>
<list-item>
<p><bold>Critical Evaluation of Solution Limitations</bold></p>
<p>While surveying advancements, we systematically document inherent compromises&#x2014;e.g., TEE dependency in FastBFT [<xref ref-type="bibr" rid="ref-12">12</xref>], centralization risks in BDNs [<xref ref-type="bibr" rid="ref-13">13</xref>], and governance bottlenecks in DAOs. This includes 14 identified attack vectors (e.g., epoch-transition exploits in sharded systems) absent in prior reviews.</p></list-item>
</list></p>
<p>The remainder of this paper is organized as follows: <xref ref-type="sec" rid="s2">Section 2</xref> discusses the background of the blockchain trilemma and its core components. <xref ref-type="sec" rid="s3">Section 3</xref> details the methodology used for literature selection. <xref ref-type="sec" rid="s4">Section 4</xref> reviews related works and prior surveys on blockchain trilemma research. <xref ref-type="sec" rid="s5">Section 5</xref> critically examines existing solutions and their corresponding challenges across sharding, layer-2 protocols, consensus mechanisms, and cryptographic enhancements. <xref ref-type="sec" rid="s6">Section 6</xref> presents proposed solutions integrating hierarchical sharding, adaptive consensus, and zero-knowledge proof optimizations. Finally, <xref ref-type="sec" rid="s7">Sections 7</xref> and <xref ref-type="sec" rid="s8">8</xref> concludes with a discussion of practical implications, open challenges, and future research directions.</p>
</sec>
</sec>
<sec id="s2">
<label>2</label>
<title>The Blockchain Trilemma: Core Principles and Inherent Trade-Offs</title>
<sec id="s2_1">
<label>2.1</label>
<title>Blockchain Fundamentals</title>
<p>Blockchain technology, first implemented in Bitcoin&#x2019;s 2008 whitepaper [<xref ref-type="bibr" rid="ref-14">14</xref>], is a distributed ledger system characterized by three foundational properties:
<list list-type="bullet">
<list-item>
<p><bold>Decentralization:</bold> Elimination of centralized control through peer-to-peer consensus mechanisms (PoW, PoS, etc.)</p></list-item>
<list-item>
<p><bold>Immutable Security:</bold> Cryptographic chaining of blocks via hash functions (SHA-256, Keccak) preventing historical revision</p></list-item>
<list-item>
<p><bold>Transparent Verification:</bold> Public auditability of transactions through replicated ledger copies across nodes</p></list-item>
</list></p>
<p><xref ref-type="fig" rid="fig-1">Fig. 1</xref> represents the dual-aspect blockchain architecture, combining immutable data chaining (left) with decentralized network operations (right). The structural visualization highlights critical relationships between Merkle-rooted transaction batches and consensus-driven validation processes, while emphasizing the role of Simplified Payment Verification (SPV) nodes in balancing scalability with verification integrity.</p>
<fig id="fig-1">
<label>Figure 1</label>
<caption>
<title>Blockchain architecture and structural components: hierarchical composition showing (1) Chained block structure with cryptographic linkages (SHA-256 hashes), block headers (timestamp, nonce, Merkle root), and transaction batches; (2) Network architecture comprising mining nodes, full/SPV nodes, consensus mechanisms (PoW/PoS), and P2P communication layer. Color coding emphasizes functional separation between data storage (blue/green) and network operations (yellow/purple)</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66366-fig-1a.tif"/>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66366-fig-1b.tif"/>
</fig>
<p>Modern blockchain systems (Ethereum, Solana, etc.) extend these principles with smart contract functionality [<xref ref-type="bibr" rid="ref-15">15</xref>], enabling programmable logic execution while inheriting the base layer&#x2019;s trustless properties. However, as shown in <xref ref-type="fig" rid="fig-2">Fig. 2</xref>, the progression from Bitcoin&#x2019;s simple payments (Blockchain 1.0) to decentralized finance (DeFi) and Web3 (Blockchain 3.0) has exponentially increased performance demands, exposing inherent tensions between the three core attributes.</p>
<fig id="fig-2">
<label>Figure 2</label>
<caption>
<title>Blockchain generations and trilemma pressure intensification</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66366-fig-2.tif"/>
</fig>
<p>This evolution contextualizes the blockchain trilemma-the empirical observation that no existing system simultaneously optimizes decentralization, security, and scalability without trade-offs [<xref ref-type="bibr" rid="ref-16">16</xref>]. The following subsections analyze how architectural choices in real-world implementations manifest these compromises.</p>
</sec>
<sec id="s2_2">
<label>2.2</label>
<title>Blockchain Trilemma</title>
<p>The blockchain trilemma emerges from fundamental constraints in distributed systems design, where optimizing any two properties inherently compromises the third. In blockchain architectures, this manifests through three interdependent pillars:</p>
<sec id="s2_2_1">
<label>2.2.1</label>
<title>Decentralization-Scalability Tension</title>
<p><list list-type="bullet">
<list-item>
<p><bold>Consensus Overhead:</bold> Proof-of-Work (PoW) systems like Bitcoin achieve decentralization through permissionless mining (<inline-formula id="ieqn-2"><mml:math id="mml-ieqn-2"><mml:mo>&#x223C;</mml:mo></mml:math></inline-formula>15k nodes) but suffer quadratic message complexity <inline-formula id="ieqn-3"><mml:math id="mml-ieqn-3"><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msup><mml:mi>n</mml:mi><mml:mn>2</mml:mn></mml:msup><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> in block propagation [<xref ref-type="bibr" rid="ref-17">17</xref>]. This creates an inverse relationship between node count and throughput: Bitcoin processes 7 TPS vs. Visa&#x2019;s 50,000&#x002B; TPS.</p></list-item>
<list-item>
<p><bold>Sharding Trade-offs:</bold> Solutions like Ethereum 2.0&#x2019;s 64 shards [<xref ref-type="bibr" rid="ref-18">18</xref>] improve throughput (<inline-formula id="ieqn-4"><mml:math id="mml-ieqn-4"><mml:mo>&#x223C;</mml:mo></mml:math></inline-formula>100k TPS theoretical) but introduce cross-shard latency (2&#x2013;5 s) and reduce per-shard decentralization (128 nodes/shard vs. 5600 global nodes).</p></list-item>
</list></p>
</sec>
<sec id="s2_2_2">
<label>2.2.2</label>
<title>Security-Scalability Conflicts</title>
<p><list list-type="bullet">
<list-item>
<p><bold>Attack Surface Expansion:</bold> High-throughput chains like Solana (50k TPS) require validator centralization (1900 nodes with 400 ms finality), lowering 51% attack costs to $40M vs. Bitcoin&#x2019;s $5B [<xref ref-type="bibr" rid="ref-19">19</xref>].</p></list-item>
<list-item>
<p><bold>Layer-2 Risks:</bold> While rollups boost Ethereum&#x2019;s TPS to 4000 [<xref ref-type="bibr" rid="ref-20">20</xref>], they introduce new attack vectors: Optimistic Rollups have 7-day challenge periods, and zk-Rollups depend on centralized provers [<xref ref-type="bibr" rid="ref-21">21</xref>].</p></list-item>
</list></p>
</sec>
<sec id="s2_2_3">
<label>2.2.3</label>
<title>Decentralization-Security Balance</title>
<p><list list-type="bullet">
<list-item>
<p><bold>Staking Centralization:</bold> Post-Merge Ethereum shows 31% of staked ETH controlled by 5 entities [<xref ref-type="bibr" rid="ref-22">22</xref>], creating governance risks despite Proof-of-Stake&#x2019;s energy efficiency.</p></list-item>
<list-item>
<p><bold>MEV Extraction:</bold> Decentralized block production enables maximal extractable value (MEV) attacks, with $680M extracted in 2022 [<xref ref-type="bibr" rid="ref-23">23</xref>], demonstrating how permissionless design enables financial attack surfaces.</p></list-item>
</list></p>
<p>These inherent tensions force blockchain architects to make context-specific compromises. As shown in <xref ref-type="table" rid="table-1">Table 1</xref>, Bitcoin&#x2019;s 7 TPS reflects its decentralization priority, while Solana&#x2019;s 50,000 TPS comes with validator centralization risks. The following sections analyze how recent innovations in <xref ref-type="sec" rid="s4">Sections 4</xref>&#x2013;<xref ref-type="sec" rid="s6">6</xref> attempt to reshape these trade-off curves through technical breakthroughs like TEE-assisted consensus and zk-AMHLs.</p>
<table-wrap id="table-1">
<label>Table 1</label>
<caption>
<title>Blockchain trilemma trade-offs in practice</title>
</caption>
<table>
<colgroup>
<col align="center"/>
<col align="center"/>
<col align="center"/>
<col align="center"/>
<col align="center"/>
</colgroup>
<thead>
<tr>
<th align="center">Blockchain</th>
<th align="center">Decentralization</th>
<th align="center">Security</th>
<th align="center">Scalability</th>
<th align="center">Primary trade-off</th>
</tr>
<tr>
<th></th>
<th align="center">(Node Count/Barrier to Entry)</th>
<th align="center">(Attack Resistance/Energy Use)</th>
<th align="center">(Max TPS/Latency)</th>
<th></th>
</tr>
</thead>
<tbody>
<tr>
<td>Bitcoin</td>
<td><inline-formula id="ieqn-5"><mml:math id="mml-ieqn-5"><mml:mo>&#x223C;</mml:mo></mml:math></inline-formula>15,000 nodes; Permissionless</td>
<td>High (PoW, 51% attack cost: <inline-formula id="ieqn-6"><mml:math id="mml-ieqn-6"><mml:mo>&#x223C;</mml:mo></mml:math></inline-formula> $5B)</td>
<td>7 TPS; 10-min finality</td>
<td>Scalability</td>
</tr>
<tr>
<td>Ethereum</td>
<td><inline-formula id="ieqn-7"><mml:math id="mml-ieqn-7"><mml:mo>&#x223C;</mml:mo></mml:math></inline-formula>5600 nodes post-Merge; Moderate hardware</td>
<td>High (PoS; 99% energy reduction); Slashing risks</td>
<td><inline-formula id="ieqn-8"><mml:math id="mml-ieqn-8"><mml:mo>&#x223C;</mml:mo></mml:math></inline-formula>30 TPS (L1); 12-s finality</td>
<td>Decentralization (post-PoS centralization concerns)</td>
</tr>
<tr>
<td>Solana</td>
<td><inline-formula id="ieqn-9"><mml:math id="mml-ieqn-9"><mml:mo>&#x223C;</mml:mo></mml:math></inline-formula>1900 validators; High hardware requirements</td>
<td>Moderate (PoH &#x002B; PoS; 51% attack cost: <inline-formula id="ieqn-10"><mml:math id="mml-ieqn-10"><mml:mo>&#x223C;</mml:mo></mml:math></inline-formula> $40M)</td>
<td>2000&#x2013;50,000 TPS; 400-ms finality</td>
<td>Decentralization (validator centralization)</td>
</tr>
<tr>
<td>Polygon</td>
<td><inline-formula id="ieqn-11"><mml:math id="mml-ieqn-11"><mml:mo>&#x223C;</mml:mo></mml:math></inline-formula>100 validators; Permissioned PoS</td>
<td>Moderate (Plasma &#x002B; PoS; relies on Ethereum security)</td>
<td>7000 TPS; 2-s finality</td>
<td>Security (trusted checkpoints)</td>
</tr>
</tbody>
</table>
</table-wrap>
</sec>
</sec>
<sec id="s2_3">
<label>2.3</label>
<title>Mathematical Formalization of Consensus Mechanisms</title>
<p>The blockchain trilemma arises from the mathematical constraints inherent to consensus protocols. Below, we formalize the core algorithms underpinning decentralization, security, and scalability trade-offs.</p>
<sec id="s2_3_1">
<label>2.3.1</label>
<title>Proof of Work (PoW)</title>
<p>In PoW, miners compete to solve a cryptographic puzzle. The probability <inline-formula id="ieqn-12"><mml:math id="mml-ieqn-12"><mml:msub><mml:mi>P</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> of a miner <inline-formula id="ieqn-13"><mml:math id="mml-ieqn-13"><mml:mi>i</mml:mi></mml:math></inline-formula> solving the puzzle is proportional to their computational power:
<disp-formula id="eqn-1"><label>(1)</label><mml:math id="mml-eqn-1" display="block"><mml:msub><mml:mi>P</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>H</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:msub><mml:mi>H</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-14"><mml:math id="mml-ieqn-14"><mml:msub><mml:mi>H</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> is the miner&#x2019;s hash rate and <inline-formula id="ieqn-15"><mml:math id="mml-ieqn-15"><mml:msub><mml:mi>H</mml:mi><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>j</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mi>n</mml:mi></mml:munderover><mml:msub><mml:mi>H</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> is the total network hash rate. The security of PoW depends on the cost of a 51% attack, which requires controlling <inline-formula id="ieqn-16"><mml:math id="mml-ieqn-16"><mml:msub><mml:mi>H</mml:mi><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:msub><mml:mrow><mml:mo>/</mml:mo></mml:mrow><mml:mn>2</mml:mn></mml:math></inline-formula> hash power. The expected time to mine a block is:
<disp-formula id="eqn-2"><label>(2)</label><mml:math id="mml-eqn-2" display="block"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>block</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi>D</mml:mi><mml:mo>&#x22C5;</mml:mo><mml:msup><mml:mn>2</mml:mn><mml:mrow><mml:mn>32</mml:mn></mml:mrow></mml:msup></mml:mrow><mml:msub><mml:mi>H</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>where <italic>D</italic> is the network difficulty. Throughput is bounded by block size <italic>B</italic> and interval <inline-formula id="ieqn-17"><mml:math id="mml-ieqn-17"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>block</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>:
<disp-formula id="eqn-3"><label>(3)</label><mml:math id="mml-eqn-3" display="block"><mml:msub><mml:mrow><mml:mtext>Throughput</mml:mtext></mml:mrow><mml:mrow><mml:mrow><mml:mtext>PoW</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mi>B</mml:mi><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>block</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>.</mml:mo></mml:math></disp-formula></p>
</sec>
<sec id="s2_3_2">
<label>2.3.2</label>
<title>Practical Byzantine Fault Tolerance (PBFT)</title>
<p>PBFT achieves consensus in three phases (pre-prepare, prepare, commit) with <inline-formula id="ieqn-18"><mml:math id="mml-ieqn-18"><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msup><mml:mi>n</mml:mi><mml:mn>2</mml:mn></mml:msup><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> message complexity. For a network of <inline-formula id="ieqn-19"><mml:math id="mml-ieqn-19"><mml:mi>n</mml:mi></mml:math></inline-formula> nodes, the protocol tolerates <inline-formula id="ieqn-20"><mml:math id="mml-ieqn-20"><mml:mi>f</mml:mi></mml:math></inline-formula> faulty nodes if:
<disp-formula id="eqn-4"><label>(4)</label><mml:math id="mml-eqn-4" display="block"><mml:mi>n</mml:mi><mml:mo>&#x2265;</mml:mo><mml:mn>3</mml:mn><mml:mi>f</mml:mi><mml:mo>+</mml:mo><mml:mn>1.</mml:mn></mml:math></disp-formula></p>
<p>The latency to finality is proportional to the round-trip time (RTT) between nodes:
<disp-formula id="eqn-5"><label>(5)</label><mml:math id="mml-eqn-5" display="block"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>finality</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mn>3</mml:mn><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mrow><mml:mtext>RTT</mml:mtext></mml:mrow><mml:mrow><mml:mo movablelimits="true" form="prefix">max</mml:mo></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:math></disp-formula></p>
</sec>
<sec id="s2_3_3">
<label>2.3.3</label>
<title>DAG-Based Consensus</title>
<p>In DAGs like IOTA&#x2019;s Tangle, transactions (<inline-formula id="ieqn-21"><mml:math id="mml-ieqn-21"><mml:mtext>tx</mml:mtext></mml:math></inline-formula>) approve two prior transactions. The cumulative weight <inline-formula id="ieqn-22"><mml:math id="mml-ieqn-22"><mml:mi>W</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mtext>tx</mml:mtext><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> of a transaction grows as more transactions reference it. The probability of a transaction being confirmed depends on its weight and the Poisson process rate <inline-formula id="ieqn-23"><mml:math id="mml-ieqn-23"><mml:mi>&#x03BB;</mml:mi></mml:math></inline-formula> of new transactions:
<disp-formula id="eqn-6"><label>(6)</label><mml:math id="mml-eqn-6" display="block"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>confirm</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mn>1</mml:mn><mml:mo>&#x2212;</mml:mo><mml:mi>exp</mml:mi><mml:mo>&#x2061;</mml:mo><mml:mrow><mml:mo>(</mml:mo><mml:mo>&#x2212;</mml:mo><mml:mi>&#x03BB;</mml:mi><mml:mspace width="thinmathspace" /><mml:mi>W</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow><mml:mo stretchy="false">)</mml:mo><mml:mo>)</mml:mo></mml:mrow><mml:mo>.</mml:mo></mml:math></disp-formula></p>
<p>Throughput scales with network participation:
<disp-formula id="eqn-7"><label>(7)</label><mml:math id="mml-eqn-7" display="block"><mml:msub><mml:mrow><mml:mtext>Throughput</mml:mtext></mml:mrow><mml:mrow><mml:mrow><mml:mtext>DAG</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mtext>&#x00A0;</mml:mtext><mml:mo>&#x221D;</mml:mo><mml:mtext>&#x00A0;</mml:mtext><mml:mi>&#x03BB;</mml:mi><mml:mo>&#x22C5;</mml:mo><mml:mi>n</mml:mi><mml:mo>.</mml:mo></mml:math></disp-formula></p>
</sec>
<sec id="s2_3_4">
<label>2.3.4</label>
<title>Proof of Work (PoW) Mining Probability</title>
<p>The probability <inline-formula id="ieqn-24"><mml:math id="mml-ieqn-24"><mml:msub><mml:mi>P</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> of miner <inline-formula id="ieqn-25"><mml:math id="mml-ieqn-25"><mml:mi>i</mml:mi></mml:math></inline-formula> mining a block is:
<disp-formula id="eqn-8"><label>(8)</label><mml:math id="mml-eqn-8" display="block"><mml:msub><mml:mi>P</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>H</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:msub><mml:mi>H</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>H</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>j</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:munderover><mml:msub><mml:mi>H</mml:mi><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:mfrac><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-26"><mml:math id="mml-ieqn-26"><mml:msub><mml:mi>H</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> is the miner&#x2019;s hash rate. The expected reward <inline-formula id="ieqn-27"><mml:math id="mml-ieqn-27"><mml:msub><mml:mi>R</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> per block is:
<disp-formula id="eqn-9"><label>(9)</label><mml:math id="mml-eqn-9" display="block"><mml:msub><mml:mi>R</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>B</mml:mi><mml:mrow><mml:mrow><mml:mtext>block</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>F</mml:mi><mml:mrow><mml:mrow><mml:mtext>tot</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>.</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-28"><mml:math id="mml-ieqn-28"><mml:msub><mml:mi>B</mml:mi><mml:mrow><mml:mtext>block</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is the block subsidy and <inline-formula id="ieqn-29"><mml:math id="mml-ieqn-29"><mml:msub><mml:mi>F</mml:mi><mml:mrow><mml:mtext>tot</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is the total fees.</p>
</sec>
<sec id="s2_3_5">
<label>2.3.5</label>
<title>Proof of Stake (PoS) Validator Rewards</title>
<p>In PoS, the reward for validator <inline-formula id="ieqn-30"><mml:math id="mml-ieqn-30"><mml:mi>k</mml:mi></mml:math></inline-formula> with stake <inline-formula id="ieqn-31"><mml:math id="mml-ieqn-31"><mml:msub><mml:mi>S</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:math></inline-formula> is:
<disp-formula id="eqn-10"><label>(10)</label><mml:math id="mml-eqn-10" display="block"><mml:msub><mml:mi>R</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msub><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>&#x22C5;</mml:mo><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>B</mml:mi><mml:mrow><mml:mrow><mml:mtext>epoch</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:mo>&#x2211;</mml:mo><mml:msub><mml:mi>F</mml:mi><mml:mrow><mml:mrow><mml:mtext>tx</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mo>&#x22C5;</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:mn>1</mml:mn><mml:mo>&#x2212;</mml:mo><mml:mi>&#x03B1;</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-32"><mml:math id="mml-ieqn-32"><mml:mi>&#x03B1;</mml:mi></mml:math></inline-formula> is the slashing penalty for malicious behavior.</p>
<p>Execution of the aforementioned mathematical formulations are graphically illustrated using <xref ref-type="fig" rid="fig-3">Fig. 3</xref>.</p>
<fig id="fig-3">
<label>Figure 3</label>
<caption>
<title>Mathematical representations of core consensus mechanisms</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66366-fig-3a.tif"/>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66366-fig-3b.tif"/>
</fig>
</sec>
</sec>
<sec id="s2_4">
<label>2.4</label>
<title>Algorithmic Formalisms</title>
<p><bold>Proof of Work (PoW):</bold> Let <italic>H</italic> be a cryptographic hash function, <inline-formula id="ieqn-33"><mml:math id="mml-ieqn-33"><mml:msub><mml:mi>B</mml:mi><mml:mi>t</mml:mi></mml:msub></mml:math></inline-formula> the current block header, and <italic>T</italic> the target difficulty. The miner&#x2019;s objective is to find nonce <inline-formula id="ieqn-34"><mml:math id="mml-ieqn-34"><mml:mi>n</mml:mi></mml:math></inline-formula> such that:
<disp-formula id="eqn-11"><label>(11)</label><mml:math id="mml-eqn-11" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:mi>H</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>B</mml:mi><mml:mrow><mml:mi>t</mml:mi></mml:mrow></mml:msub><mml:mo fence="false" stretchy="false">&#x2016;</mml:mo><mml:mi>n</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x2264;</mml:mo><mml:mi>T</mml:mi></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>The probability <italic>P</italic> of finding a valid nonce in one attempt is:
<disp-formula id="eqn-12"><label>(12)</label><mml:math id="mml-eqn-12" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:mi>P</mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:mi>T</mml:mi><mml:msup><mml:mn>2</mml:mn><mml:mrow><mml:mi>&#x2113;</mml:mi></mml:mrow></mml:msup></mml:mfrac></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>where <inline-formula id="ieqn-35"><mml:math id="mml-ieqn-35"><mml:mi>&#x2113;</mml:mi></mml:math></inline-formula> is the hash output length (256-bit for SHA-256). The difficulty <italic>D</italic> auto-adjusts every <italic>N</italic> blocks:
<disp-formula id="eqn-13"><label>(13)</label><mml:math id="mml-eqn-13" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>n</mml:mi><mml:mi>e</mml:mi><mml:mi>w</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>o</mml:mi><mml:mi>l</mml:mi><mml:mi>d</mml:mi></mml:mrow></mml:msub><mml:mo>&#x00D7;</mml:mo><mml:mfrac><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>e</mml:mi><mml:mi>x</mml:mi><mml:mi>p</mml:mi><mml:mi>e</mml:mi><mml:mi>c</mml:mi><mml:mi>t</mml:mi><mml:mi>e</mml:mi><mml:mi>d</mml:mi></mml:mrow></mml:msub><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>a</mml:mi><mml:mi>c</mml:mi><mml:mi>t</mml:mi><mml:mi>u</mml:mi><mml:mi>a</mml:mi><mml:mi>l</mml:mi></mml:mrow></mml:msub></mml:mfrac></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p><bold>Practical Byzantine Fault Tolerance (PBFT):</bold> For <inline-formula id="ieqn-36"><mml:math id="mml-ieqn-36"><mml:mi>n</mml:mi></mml:math></inline-formula> nodes with <inline-formula id="ieqn-37"><mml:math id="mml-ieqn-37"><mml:mi>f</mml:mi></mml:math></inline-formula> faulty nodes, the protocol requires:
<disp-formula id="eqn-14"><label>(14)</label><mml:math id="mml-eqn-14" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:mi>n</mml:mi><mml:mo>&#x2265;</mml:mo><mml:mn>3</mml:mn><mml:mi>f</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>Message complexity per consensus round is:
<disp-formula id="eqn-15"><label>(15)</label><mml:math id="mml-eqn-15" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:msub><mml:mi>M</mml:mi><mml:mrow><mml:mi>P</mml:mi><mml:mi>B</mml:mi><mml:mi>F</mml:mi><mml:mi>T</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msup><mml:mi>n</mml:mi><mml:mn>2</mml:mn></mml:msup><mml:mo stretchy="false">)</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>The commit phase succeeds when receiving <inline-formula id="ieqn-38"><mml:math id="mml-ieqn-38"><mml:mn>2</mml:mn><mml:mi>f</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:math></inline-formula> valid responses:
<disp-formula id="eqn-16"><label>(16)</label><mml:math id="mml-eqn-16" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:msub><mml:mi>Q</mml:mi><mml:mrow><mml:mi>c</mml:mi><mml:mi>o</mml:mi><mml:mi>m</mml:mi><mml:mi>m</mml:mi><mml:mi>i</mml:mi><mml:mi>t</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:munderover><mml:mo>&#x22C3;</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mn>2</mml:mn><mml:mi>f</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:munderover><mml:mrow><mml:mtext>VALID</mml:mtext></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>m</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p><bold>Directed Acyclic Graphs (DAG):</bold> In IOTA&#x2019;s Tangle, the cumulative weight <inline-formula id="ieqn-39"><mml:math id="mml-ieqn-39"><mml:msub><mml:mi>W</mml:mi><mml:mi>c</mml:mi></mml:msub></mml:math></inline-formula> of transaction <inline-formula id="ieqn-40"><mml:math id="mml-ieqn-40"><mml:mi>t</mml:mi><mml:msub><mml:mi>x</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> is:
<disp-formula id="eqn-17"><label>(17)</label><mml:math id="mml-eqn-17" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:msub><mml:mi>W</mml:mi><mml:mi>c</mml:mi></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:msub><mml:mi>x</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:munder><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>t</mml:mi><mml:msub><mml:mi>x</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>&#x2208;</mml:mo><mml:mrow><mml:mi>&#x1D49C;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:msub><mml:mi>x</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:munder><mml:mi>w</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:msub><mml:mi>x</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>where <inline-formula id="ieqn-41"><mml:math id="mml-ieqn-41"><mml:mrow><mml:mi>&#x1D49C;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:msub><mml:mi>x</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> is the ancestry set and <inline-formula id="ieqn-42"><mml:math id="mml-ieqn-42"><mml:mi>w</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:msub><mml:mi>x</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> individual weights. The tip selection probability follows Markov chain transitions:
<disp-formula id="eqn-18"><label>(18)</label><mml:math id="mml-eqn-18" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:mi>P</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>t</mml:mi><mml:msub><mml:mi>x</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo stretchy="false">&#x2192;</mml:mo><mml:mi>t</mml:mi><mml:msub><mml:mi>x</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mfrac><mml:msup><mml:mi>e</mml:mi><mml:mrow><mml:mo>&#x2212;</mml:mo><mml:mi>&#x03B1;</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>h</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>h</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:msup><mml:mrow><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>j</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mi>N</mml:mi></mml:munderover><mml:msup><mml:mi>e</mml:mi><mml:mrow><mml:mo>&#x2212;</mml:mo><mml:mi>&#x03B1;</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>h</mml:mi><mml:mi>k</mml:mi></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>h</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:msup></mml:mrow></mml:mfrac></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>where <inline-formula id="ieqn-43"><mml:math id="mml-ieqn-43"><mml:mi>h</mml:mi></mml:math></inline-formula> denotes timestamps and <inline-formula id="ieqn-44"><mml:math id="mml-ieqn-44"><mml:mi>&#x03B1;</mml:mi></mml:math></inline-formula> the confirmation confidence parameter.</p>
<p><bold>Proof of Stake (PoS):</bold> Validator <inline-formula id="ieqn-45"><mml:math id="mml-ieqn-45"><mml:msub><mml:mi>v</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula>&#x2019;s selection probability proportional to stake <inline-formula id="ieqn-46"><mml:math id="mml-ieqn-46"><mml:msub><mml:mi>s</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula>:
<disp-formula id="eqn-19"><label>(19)</label><mml:math id="mml-eqn-19" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:mi>P</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>v</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>s</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mrow><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>k</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mi>n</mml:mi></mml:munderover><mml:msub><mml:mi>s</mml:mi><mml:mi>k</mml:mi></mml:msub></mml:mrow></mml:mfrac></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula></p>
<p>Slashing conditions for Byzantine behavior:
<disp-formula id="eqn-20"><label>(20)</label><mml:math id="mml-eqn-20" display="block"><mml:mtable columnalign="right left right left right left right left right left right left" rowspacing="3pt" columnspacing="0em 2em 0em 2em 0em 2em 0em 2em 0em 2em 0em" displaystyle="true"><mml:mtr><mml:mtd><mml:mi>&#x03D5;</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>v</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mtable columnalign="left left" rowspacing=".2em" columnspacing="1em" displaystyle="false"><mml:mtr><mml:mtd><mml:msub><mml:mi>s</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>&#x00D7;</mml:mo><mml:mi>&#x03C1;</mml:mi></mml:mtd><mml:mtd><mml:mrow><mml:mtext>if&#xA0;</mml:mtext></mml:mrow><mml:mrow><mml:mtext>Byzantine</mml:mtext></mml:mrow></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mn>0</mml:mn></mml:mtd><mml:mtd><mml:mrow><mml:mtext>otherwise</mml:mtext></mml:mrow></mml:mtd></mml:mtr></mml:mtable><mml:mo fence="true" stretchy="true" symmetric="true"></mml:mo></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>where <inline-formula id="ieqn-47"><mml:math id="mml-ieqn-47"><mml:mi>&#x03C1;</mml:mi></mml:math></inline-formula> is the slashing factor (typically 0.01&#x2013;0.3).</p>
<p><xref ref-type="table" rid="table-2">Table 2</xref> represents the comparative analysis of the consensus algorithm, where <inline-formula id="ieqn-48"><mml:math id="mml-ieqn-48"><mml:mi mathvariant="normal">&#x0394;</mml:mi></mml:math></inline-formula> is network delay and <inline-formula id="ieqn-49"><mml:math id="mml-ieqn-49"><mml:mi>m</mml:mi></mml:math></inline-formula> the DAG width. These formalizations demonstrate fundamental trade-offs-PBFT achieves instant finality but scales quadratically, while DAGs enable parallel validation at the cost of cumulative confirmation certainty.</p>
<table-wrap id="table-2">
<label>Table 2</label>
<caption>
<title>Consensus algorithm comparative analysis</title>
</caption>
<table>
<colgroup>
<col/>
<col/>
<col/>
<col/>
<col/>
</colgroup>
<thead>
<tr>
<th>Parameter</th>
<th>PoW</th>
<th>PBFT</th>
<th>PoS</th>
<th>DAG</th>
</tr>
</thead>
<tbody>
<tr>
<td>Message complexity</td>
<td><inline-formula id="ieqn-50"><mml:math id="mml-ieqn-50"><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mn>1</mml:mn><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula></td>
<td><inline-formula id="ieqn-51"><mml:math id="mml-ieqn-51"><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msup><mml:mi>n</mml:mi><mml:mn>2</mml:mn></mml:msup><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula></td>
<td><inline-formula id="ieqn-52"><mml:math id="mml-ieqn-52"><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>n</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula></td>
<td><inline-formula id="ieqn-53"><mml:math id="mml-ieqn-53"><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msqrt><mml:mi>m</mml:mi></mml:msqrt><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula></td>
</tr>
<tr>
<td>Finality</td>
<td>Probabilistic</td>
<td>Instant</td>
<td>Probabilistic</td>
<td>Cumulative</td>
</tr>
<tr>
<td>Energy cost</td>
<td>High (<inline-formula id="ieqn-54"><mml:math id="mml-ieqn-54"><mml:mo>&#x221D;</mml:mo><mml:mi>D</mml:mi></mml:math></inline-formula>)</td>
<td>Low</td>
<td>Medium</td>
<td>Low</td>
</tr>
<tr>
<td>Adversary tolerance</td>
<td><inline-formula id="ieqn-55"><mml:math id="mml-ieqn-55"><mml:mrow><mml:mo>&#x003C;</mml:mo></mml:mrow><mml:mn>25</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula> hash rate</td>
<td><inline-formula id="ieqn-56"><mml:math id="mml-ieqn-56"><mml:mrow><mml:mo>&#x003C;</mml:mo></mml:mrow><mml:mn>33</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula> nodes</td>
<td><inline-formula id="ieqn-57"><mml:math id="mml-ieqn-57"><mml:mrow><mml:mo>&#x003C;</mml:mo></mml:mrow><mml:mn>33</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula> stake</td>
<td><inline-formula id="ieqn-58"><mml:math id="mml-ieqn-58"><mml:mrow><mml:mo>&#x003C;</mml:mo></mml:mrow><mml:mn>28</mml:mn><mml:mi mathvariant="normal">&#x0025;</mml:mi></mml:math></inline-formula> weight</td>
</tr>
<tr>
<td>Throughput bound</td>
<td><inline-formula id="ieqn-59"><mml:math id="mml-ieqn-59"><mml:mfrac><mml:mn>1</mml:mn><mml:mi mathvariant="normal">&#x0394;</mml:mi></mml:mfrac></mml:math></inline-formula></td>
<td><inline-formula id="ieqn-60"><mml:math id="mml-ieqn-60"><mml:mfrac><mml:mi>n</mml:mi><mml:mrow><mml:mn>3</mml:mn><mml:mi mathvariant="normal">&#x0394;</mml:mi></mml:mrow></mml:mfrac></mml:math></inline-formula></td>
<td><inline-formula id="ieqn-61"><mml:math id="mml-ieqn-61"><mml:mfrac><mml:mi>n</mml:mi><mml:mrow><mml:mn>2</mml:mn><mml:mi mathvariant="normal">&#x0394;</mml:mi></mml:mrow></mml:mfrac></mml:math></inline-formula></td>
<td><inline-formula id="ieqn-62"><mml:math id="mml-ieqn-62"><mml:msqrt><mml:mi>m</mml:mi></mml:msqrt><mml:mrow><mml:mo>/</mml:mo></mml:mrow><mml:mi mathvariant="normal">&#x0394;</mml:mi></mml:math></inline-formula></td>
</tr>
</tbody>
</table>
</table-wrap>
</sec>
</sec>
<sec id="s3">
<label>3</label>
<title>Methodology</title>
<p>This review follows a systematic approach to analyzing the blockchain trilemma, utilizing the PRISMA framework to ensure comprehensive and transparent reporting. The process is divided into five key phases: literature selection, search &#x0026; screening, categorization, critical analysis, and comparative evaluation.</p>
<sec id="s3_1">
<label>3.1</label>
<title>Literature Selection Criteria</title>
<p>We used the PRISMA 2020 guidelines to ensure a rigorous and transparent selection process. The criteria for selecting studies include:</p>
<sec id="s3_1_1">
<label>3.1.1</label>
<title>Inclusion Criteria</title>
<p>The articles were selected for review based on the following criteria:
<list list-type="simple">
<list-item><label>&#x2022;</label>
<p><bold>Source Types:</bold> Peer-reviewed journal articles, conference papers, technical reports, and edited book chapters from trusted databases (IEEE Xplore, ACM Digital Library, SpringerLink, Elsevier, ScienceDirect).</p></list-item>
<list-item><label>&#x2022;</label>
<p><bold>Time Frame:</bold> Studies published between 2016 and 2024 to capture the latest advancements.</p></list-item>
<list-item><label>&#x2022;</label>
<p><bold>Keywords:</bold>
<list list-type="simple">
<list-item><label>&#x2013;</label><p>Core terms: &#x201C;Blockchain Trilemma,&#x201D; &#x201C;Scalability,&#x201D; &#x201C;Security,&#x201D; &#x201C;Decentralization.&#x201D;</p></list-item>
<list-item><label>&#x2013;</label><p>Related solutions: &#x201C;Consensus Mechanisms,&#x201D; &#x201C;Layer-2 Solutions,&#x201D; &#x201C;Sharding,&#x201D; &#x201C;Sidechains,&#x201D; &#x201C;Zero-Knowledge Proofs.&#x201D;</p></list-item>
<list-item><label>&#x2013;</label><p>Performance metrics: &#x201C;Throughput,&#x201D; &#x201C;Latency,&#x201D; &#x201C;Energy Efficiency,&#x201D; &#x201C;Transaction Speed.&#x201D;</p></list-item>
</list></p></list-item>
<list-item><label>&#x2022;</label>
<p><bold>Content Focus:</bold>
<list list-type="simple">
<list-item><label>&#x2013;</label><p>Studies must explicitly address at least one dimension of the trilemma (scalability, security, decentralization) or propose solutions (e.g., PoW/PoS variants, DAGs, rollups).</p></list-item>
<list-item><label>&#x2013;</label><p>Empirical data, technical analyses, or comparative evaluations of blockchain architectures.</p></list-item>
<list-item><label>&#x2013;</label><p>Studies discussing trade-offs (e.g., scalability vs. security) or real-world implementations (e.g., Ethereum 2.0, Hyperledger).</p></list-item>
</list></p></list-item>
<list-item><label>&#x2022;</label>
<p><bold>Access:</bold> Open-access and subscription-based articles were considered.</p></list-item>
</list></p>
</sec>
<sec id="s3_1_2">
<label>3.1.2</label>
<title>Exclusion Criteria</title>
<p>The articles were excluded from the review based on the following criteria:
<list list-type="bullet">
<list-item>
<p><bold>Publication Year:</bold> Studies published outside the specified time range.</p></list-item>
<list-item>
<p><bold>Pre-Publication Stage:</bold> Articles still in the pre-publication phase.</p></list-item>
<list-item>
<p><bold>Publication Type:</bold> Editorials, notes, and other brief publications.</p></list-item>
<list-item>
<p><bold>Title Relevance:</bold> Articles whose titles did not align with the targeted keywords or subject.</p></list-item>
<list-item>
<p><bold>Abstract Focus:</bold> Articles with abstracts that did not primarily focus on the research topic.</p></list-item>
</list></p>
<p>We adhered to the PRISMA checklist throughout the selection process, which includes the documentation of all inclusion and exclusion criteria.</p>
</sec>
</sec>
<sec id="s3_2">
<label>3.2</label>
<title>Literature Search and Screening</title>
<p>A systematic search was conducted across the chosen databases (IEEE Xplore, ACM Digital Library, SpringerLink, and Elsevier). We initially identified 50 records. After removing duplicates, we screened titles and abstracts for relevance. The full-text articles were then reviewed for eligibility based on the inclusion and exclusion criteria.</p>
<p><xref ref-type="fig" rid="fig-4">Fig. 4</xref> summarizes the study selection process, including the number of records identified, screened, and ultimately included in the review.</p>
<fig id="fig-4">
<label>Figure 4</label>
<caption>
<title>Methodology of our survey</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66366-fig-4.tif"/>
</fig>
</sec>
<sec id="s3_3">
<label>3.3</label>
<title>Categorization of Solutions</title>
<p>Following the PRISMA recommendations, the studies were categorized into three groups based on the blockchain trilemma dimensions: decentralization, security, and scalability. Each category was further divided into subcategories as described earlier.</p>
</sec>
<sec id="s3_4">
<label>3.4</label>
<title>Data Extraction and Synthesis</title>
<p>For each study included in the review, key information was extracted, such as performance metrics, trade-offs, and implementation details. This data was synthesized to compare different solutions, with a focus on how they address the blockchain trilemma&#x2019;s challenges.</p>
</sec>
<sec id="s3_5">
<label>3.5</label>
<title>Comparative Evaluation and Future Research Directions</title>
<p>Based on the data extracted and analyzed, we provide a comparative evaluation of the solutions based on key metrics such as scalability, security, and decentralization. We also identify gaps in the current literature and propose potential future research directions in blockchain technology, particularly in addressing the challenges of the blockchain trilemma.</p>
</sec>
</sec>
<sec id="s4">
<label>4</label>
<title>Related Works</title>
<p>Prior surveys and systematic reviews have explored blockchain scalability and security as isolated dimensions of the trilemma. For instance, existing works predominantly focus on either scalability improvements (e.g., sharding, layer-2 protocols) or security vulnerabilities (e.g., 51% attacks, smart contract flaws), often neglecting the interdependencies between decentralization, security, and scalability. Our review critically synthesizes these fragmented efforts, emphasizing how prior surveys have addressed subsets of the trilemma but failed to provide a unified analysis. By integrating all three dimensions, we bridge the gap between isolated research threads and offer a holistic framework for evaluating trade-offs. Unlike prior surveys that narrowly focus on individual aspects (e.g., [<xref ref-type="bibr" rid="ref-24">24</xref>&#x2013;<xref ref-type="bibr" rid="ref-29">29</xref>] on scalability; [<xref ref-type="bibr" rid="ref-30">30</xref>,<xref ref-type="bibr" rid="ref-31">31</xref>] on security), our analysis systematically connects these domains, revealing how the trilemma&#x2019;s constraints manifest across architectural and cryptographic innovations.</p>
<p>In [<xref ref-type="bibr" rid="ref-24">24</xref>], Sanka and Cheung conducted a systematic review of blockchain scalability, focusing on issues, solutions, and future research directions. The authors proposed a five-layer conceptual model of the blockchain ecosystem (application, data, consensus, network, platform) to categorize scalability challenges and systematically analyzed 351 studies. They classified solutions into write-performance (on-chain, off-chain, consensus, network, platform layers), read-performance, and storage scalability, while emphasizing the blockchain quadrilemma (scalability, decentralization, security, trust). The paper uniquely integrates performance analysis and benchmarking studies, addressing gaps in prior surveys that focused narrowly on specific solutions like sharding.</p>
<p>In [<xref ref-type="bibr" rid="ref-25">25</xref>], Rao et al. conducted a systematic literature review (SLR) analyzing blockchain scalability challenges, existing solutions, and future research directions. The study reviewed nearly 110 papers from databases like Scopus and IEEE Xplore, identifying critical issues such as low throughput, network latency, and energy consumption in Bitcoin and Ethereum. The authors evaluated limitations of on-chain (e.g., sharding, consensus mechanisms) and off-chain solutions (e.g., Lightning Network), emphasizing trade-offs between scalability, security, and decentralization. A key contribution is the integration of data science techniques like distributed computing and machine learning to optimize transaction processing and consensus protocols. The paper also highlights emerging trends, such as leveraging Apache Kafka and Spark for scalable blockchain architectures.</p>
<p>In [<xref ref-type="bibr" rid="ref-26">26</xref>], the authors reviewed scalability challenges in blockchain systems, focusing on performance inefficiency, high confirmation delays, and functional limitations. They systematically analyzed four mainstream solutions: Sharding mechanisms (e.g., Elastico and Zilliqa), DAG-based ledgers (e.g., IOTA and Nano), off-chain networks (Lightning Network, Raiden, Plasma), and cross-chain technologies (multi-signature witnesses, sidechains, hash locking). The paper highlighted trade-offs in each approach, such as Sharding&#x2019;s reliance on PBFT consensus and off-chain solutions&#x2019; centralization risks. Additionally, the authors proposed future research directions, including scalable P2P networks, modular cryptography, and programmable compute engines.</p>
<p>In [<xref ref-type="bibr" rid="ref-27">27</xref>], the authors reviewed scalability challenges in blockchain systems through the lens of throughput, storage, and networking bottlenecks. They analyzed enabling technologies such as sharding (e.g., Elastico and OmniLedger), off-chain solutions (Lightning Network, Plasma), and hybrid storage approaches (IPFS, BigchainDB), emphasizing trade-offs like decentralization-security compromises and consensus latency. The paper critically evaluated leader election mechanisms (e.g., Bitcoin-NG, ByzCoin) and highlighted unresolved issues, including energy-efficient leader selection and incentive-punishment balance. Additionally, future directions such as privacy-preserving data processing and quantitative performance analysis frameworks were proposed.</p>
<p>In [<xref ref-type="bibr" rid="ref-28">28</xref>], the authors reviewed scalability challenges in blockchain systems, emphasizing bottlenecks in throughput, storage efficiency, and transaction costs. They analyzed solutions such as consensus mechanism optimizations (e.g., BFT variants), off-chain transactions (e.g., Lightning Network), DAG-based ledgers, and hybrid storage approaches (e.g., IPFS integration). The paper critically evaluated existing surveys on blockchain scalability, introducing a &#x201D;recency score&#x201D; metric to assess the inclusion of recent research, highlighting gaps in comprehensive comparative analyses. Future challenges identified include balancing incentive-punishment mechanisms, privacy-preserving data processing via secure multi-party computation, and developing quantitative frameworks for performance evaluation.</p>
<p>In [<xref ref-type="bibr" rid="ref-29">29</xref>], the authors Khan et al. reviewed challenges in blockchain scalability through a systematic literature review (SLR) of 121 primary papers. They identified transaction throughput, latency, storage demands, and consensus mechanisms (e.g., PoW, PoS) as critical factors hindering scalability in public blockchains like Bitcoin and Ethereum. The study categorized solutions into on-chain approaches (e.g., SegWit, sharding, block size adjustments) and off-chain methods like the Lightning Network, while emphasizing their trade-offs with decentralization and security. The review highlighted the scalability trilemma and noted that IoT, finance, and healthcare applications remain constrained by these limitations. The authors concluded that consensus protocol inefficiencies and interdependent factors necessitate balanced solutions to achieve industrial-grade scalability.</p>
<p>In [<xref ref-type="bibr" rid="ref-30">30</xref>], the authors reviewed blockchain security issues and challenges by analyzing 80 research papers, focusing on ecosystem concepts, blockchain classifications, and implementation aspects. They categorized blockchains into public, private, and consortium types, emphasizing their structural differences and security trade-offs. The paper highlights critical security vulnerabilities such as 51% attacks, forking (hard/soft), eclipse attacks, and smart contract flaws, while also addressing scalability, regulatory gaps, and integration challenges. Practical examples, including cryptocurrency systems (e.g., Bitcoin, Ethereum) and real-world breaches (e.g., MtGox, DAO hack), underscore the risks of human error and malicious exploits. The study concludes by stressing the need for robust regulatory frameworks and improved technical solutions to balance blockchain&#x2019;s decentralized benefits with security and scalability demands, aligning implicitly with the blockchain trilemma&#x2019;s core challenges.</p>
<p>In [<xref ref-type="bibr" rid="ref-31">31</xref>], Taylor and others conducted a systematic literature review (SLR) of 42 studies to analyze blockchain&#x2019;s role in cybersecurity, emphasizing IoT security, data storage, and network applications. The review revealed that nearly half of the studies focused on securing IoT ecosystems through decentralized authentication and firmware updates, while others explored blockchain&#x2019;s potential in encrypted data sharing and public-key infrastructure. Notably, practical implementations leveraged platforms like Ethereum and Hyperledger Fabric but faced scalability trade-offs due to consensus mechanisms like Proof-of-Work. The study also identified emerging research directions, such as securing AI data and sidechain architectures, while underscoring challenges like latency and regulatory gaps.</p>
<p>In [<xref ref-type="bibr" rid="ref-32">32</xref>], the authors reviewed blockchain security through a structured PDI (Process, Data, Infrastructure) framework, addressing gaps in prior surveys that overlooked organizational and operational challenges. They categorized security techniques and threats across three levels: process (e.g., smart contract vulnerabilities, fraud detection), data (e.g., encryption, consensus algorithms), and infrastructure (e.g., key management, network vulnerabilities). The paper critically analyzed existing architectures, consensus mechanisms, and cryptographic methods, while highlighting emerging issues such as scalability and quantum computing threats. It also proposed future directions, including formal verification of smart contracts, integration with big data analytics, and anti-quantum signature schemes.</p>
<p>In [<xref ref-type="bibr" rid="ref-33">33</xref>], the authors reviewed blockchain technology with a focus on its applications and associated security and privacy challenges. They conducted a systematic survey of 135 research articles from five major databases (ScienceDirect, IEEE Xplore, Web of Science, ACM Digital Library, and Inderscience), categorizing blockchain applications into 12 domains, including healthcare, IoT, finance, and supply chain. The paper highlighted blockchain&#x2019;s decentralized, tamper-proof, and transparent properties while addressing implementation challenges such as scalability, mining inefficiency, and consensus mechanisms. Notably, it emphasized security issues like double-spending attacks, privacy leakage, and key management, contrasting its comprehensive coverage of both applications and security with prior surveys that often focused narrowly on specific domains. The authors positioned their work as the first to integrate a broad analysis of blockchain applications with an in-depth discussion of security and privacy, providing a foundational reference for researchers.</p>
<p>In [<xref ref-type="bibr" rid="ref-34">34</xref>], the authors reviewed the current state of blockchain-powered decentralized finance (DeFi), emphasizing its evolution, key services, and associated risks. They provided a comparative analysis between DeFi and traditional financial systems, highlighting services such as decentralized lending/borrowing, stablecoins, and automated market maker (AMM)-based exchanges. The paper detailed investment opportunities in DeFi, including liquidity provision, arbitrage, and liquidation strategies, while also addressing unique risks such as smart contract vulnerabilities, impermanent loss, and regulatory uncertainties. Notably, the authors aimed to bridge the gap between academic rigor and accessibility, making the review suitable for both technical and investment-focused audiences. The work stands out for its holistic overview of the DeFi ecosystem, contrasting with existing reviews that often focus narrowly on specific services or theoretical aspects.</p>
<p>In [<xref ref-type="bibr" rid="ref-35">35</xref>], the authors reviewed consensus algorithms in blockchain systems, emphasizing their principles, performance, and suitability for different application scenarios. They analyzed key algorithms such as Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), Practical Byzantine Fault Tolerance (PBFT), and Raft, comparing their Byzantine fault tolerance, throughput, scalability, and limitations. The paper highlighted PoW&#x2019;s resource inefficiency and scalability challenges, contrasted with DPoS&#x2019;s efficiency and PBFT&#x2019;s suitability for permissioned systems. Additionally, the authors provided guidance on selecting algorithms based on blockchain types (public, private, permissioned) and discussed emerging issues like hashing power centralization. This work serves as a foundational reference for understanding trade-offs in consensus mechanisms, though it acknowledges the need for scenario-specific optimizations in evolving blockchain ecosystems.</p>
<p>In [<xref ref-type="bibr" rid="ref-36">36</xref>], the authors reviewed blockchain consensus models, categorizing them into proof-based (e.g., PoW, PoS, DPoS) and voting-based (e.g., PBFT, Ripple) approaches. They critically analyzed each model&#x2019;s performance in transaction throughput, latency, and energy efficiency, highlighting trade-offs such as PoW&#x2019;s high resource consumption versus PBFT&#x2019;s scalability limitations in permissioned settings. The paper provided comparative tables summarizing advantages, disadvantages, and suitability for permissioned or permissionless blockchains, while noting challenges like slow transaction finality in proof-based models and restricted node scalability in voting-based systems. The authors emphasized the need for hybrid or optimized models to address real-time application demands. This work serves as a practical reference for understanding consensus trade-offs but acknowledges gaps in quantitative metrics and real-world.</p>
<p>In [<xref ref-type="bibr" rid="ref-37">37</xref>], Tenorio-Fornes et al. proposed a decentralized scientific publishing system using blockchain and IPFS to address centralization and transparency issues in traditional peer review. They introduced a reviewer reputation system, Open Access infrastructure, and transparent governance, leveraging Ethereum smart contracts for process automation and IPFS for decentralized content storage. The paper highlighted privacy challenges, proposing cryptographic techniques like zk-SNARKs and ring signatures to enable anonymous yet accountable reviews, balancing decentralization and security. A prototype and survey demonstrated feasibility, though scalability concerns (e.g., blockchain transaction costs) and risks of Sybil attacks underscored unresolved tensions in the blockchain trilemma. This work advances decentralized solutions but underscores the trade-offs between transparency, security, and scalability in distributed systems.</p>
<p>In [<xref ref-type="bibr" rid="ref-38">38</xref>], the authors reviewed blockchain platforms through the lens of the scalability, security, and decentralization trilemma, analyzing nine major platforms, including Ethereum, Solana, and Cosmos. They systematically evaluated each platform&#x2019;s consensus protocols, transaction throughput, node distribution, and Byzantine Fault Tolerance, highlighting inherent trade-offs&#x2014;for instance, platforms like Binance Smart Chain prioritized scalability at the expense of decentralization, while Ethereum&#x2019;s PoW model faced scalability limitations. The study emphasized that no platform fully resolved the trilemma, instead showcasing how architectural choices (e.g., sharding in Harmony, DAG structures in Avalanche) addressed specific aspects.</p>
<p>In [<xref ref-type="bibr" rid="ref-39">39</xref>], Lashkari and Musilek conducted a comprehensive review of 130 blockchain consensus mechanisms, analyzing 185 academic and industrial publications. The authors proposed a novel architectural classification framework, categorizing consensus algorithms into eight classes based on their foundational principles, such as proof-based, Byzantine fault-tolerant, and hybrid approaches. Their comparative analysis evaluated key parameters like scalability, finality, and adversary tolerance, offering insights into trade-offs between performance and security. The study also examined the distribution of consensus mechanisms across application domains, revealing their prevalence in cryptocurrencies and IoT, while noting underutilization in smart grids and localization. By addressing gaps in prior taxonomies, this work provides a structured reference for selecting consensus protocols in alignment with specific blockchain requirements. The analysis of evolution and future trends underscores the growing relevance of cross-compliant hybrid mechanisms, highlighting their potential to address scalability-decentralization-security trade-offs central to the blockchain trilemma.</p>
<p>In [<xref ref-type="bibr" rid="ref-40">40</xref>], the authors conducted a systematic review of blockchain scalability challenges, analyzing 35 studies from ACM, ScienceDirect, and IEEE to categorize solutions into on-chain (e.g., consensus algorithm optimization, sharding, blockchain redesign) and off-chain approaches (e.g., second-layer networks, IPFS). They identified sharding and consensus protocol enhancements as the most prominent solutions, though noted these often trade off decentralization or security. The review highlighted that while solutions like DAG-based architectures or hybrid consensus models improved throughput and latency, most lacked real-world validation and faced unresolved issues such as inter-shard communication inefficiencies. The paper concluded that scalability remains a critical barrier to blockchain adoption, urging further empirical testing and integration of multi-faceted approaches. This review underscores the need for practical implementations to balance scalability with blockchain&#x2019;s core principles.</p>
<p>In [<xref ref-type="bibr" rid="ref-41">41</xref>], the authors reviewed recent advancements in blockchain consensus algorithms, emphasizing their principles, classifications, and trade-offs. The paper categorizes consensus mechanisms into non-Byzantine (e.g., Paxos, Raft) and Byzantine fault-tolerant (e.g., PBFT, PoW, PoS) algorithms, analyzing their efficiency, security, energy consumption, and suitability for public, consortium, or private chains. A comparative table highlights key distinctions, such as PoW&#x2019;s decentralization versus its high energy costs and PoS&#x2019;s efficiency versus centralization risks. The study also explores emerging hybrid and scenario-specific algorithms (e.g., PoH, CW-PoW) and predicts future trends, including scalability enhancements and security-focused improvements. While not explicitly framing it as the &#x201C;blockchain trilemma,&#x201D; the analysis implicitly addresses challenges in balancing decentralization, security, and scalability across consensus models.</p>
<p>In [<xref ref-type="bibr" rid="ref-42">42</xref>], Deng et al. reviewed blockchain technologies for building decentralized trust mechanisms, focusing on architecture, consensus algorithms, and smart contracts. The authors systematically analyzed blockchain&#x2019;s layered architecture (data, network, consensus, contract, and application layers), emphasizing how each layer contributes to decentralization, security, and scalability. They compared proof-based and voting-based consensus mechanisms, highlighting trade-offs in energy efficiency, throughput, and fault tolerance, which align with the blockchain trilemma&#x2019;s challenges. The paper also examined smart contract platforms like Ethereum and Hyperledger Fabric, discussing their security limitations and scalability constraints.</p>
<p>Prior surveys have predominantly focused on isolated dimensions of the trilemma, with emphasizing scalability [<xref ref-type="bibr" rid="ref-24">24</xref>&#x2013;<xref ref-type="bibr" rid="ref-29">29</xref>], prioritizing security [<xref ref-type="bibr" rid="ref-30">30</xref>,<xref ref-type="bibr" rid="ref-31">31</xref>], and partially addressing decentralization [<xref ref-type="bibr" rid="ref-35">35</xref>,<xref ref-type="bibr" rid="ref-40">40</xref>]. While Lashkari and Musilek [<xref ref-type="bibr" rid="ref-39">39</xref>] provided comprehensive consensus analysis, they omitted scalability metrics. Our work differs through three key innovations: 1) <italic>Holistic integration</italic> of all trilemma dimensions via a unified analytical framework, 2) <italic>Systematic taxonomy</italic> categorizing 38 solutions with granular trade-off labeling, and 3) <italic>Practical validation</italic> through real-world deployments (e.g., Ethereum post-Merge) and emerging paradigms (zk-AMHLs, TEE-assisted consensus). Unlike [<xref ref-type="bibr" rid="ref-38">38</xref>]&#x2019;s platform-centric approach, we benchmark performance across decentralization metrics (Nakamoto Coefficient), security thresholds (51% attack costs), and scalability targets (Visa-level TPS). Our critical evaluation of 14 attack vectors and AI-driven governance proposals extends beyond the theoretical scope of prior works. The comparison is briefly represented in <xref ref-type="table" rid="table-3">Table 3</xref>.</p>
<table-wrap id="table-3">
<label>Table 3</label>
<caption>
<title>Comparison of prior surveys on blockchain trilemma research</title>
</caption>
<table>
<colgroup>
<col align="center"/>
<col align="center"/>
<col align="center"/>
<col align="center"/>
<col align="center"/>
<col align="center"/>
<col align="center"/>
</colgroup>
<thead>
<tr>
<th align="center">Study</th>
<th align="center">Trilemma aspects covered</th>
<th align="center">Solution types analyzed</th>
<th align="center">Comparative analysis</th>
<th align="center">Real-world case studies</th>
<th align="center">Future directions</th>
<th align="center">Limitations discussed</th>
</tr>
</thead>
<tbody>
<tr>
<td>Sanka and Cheung [<xref ref-type="bibr" rid="ref-24">24</xref>]</td>
<td>Scalability, Trust (Quadrilemma)</td>
<td>Sharding, Layer-2, Consensus</td>
<td>Partial (5-layer model)</td>
<td>None</td>
<td>Storage scalability, Quantitative frameworks</td>
<td>Narrow focus on scalability</td>
</tr>
<tr>
<td>Rao et al. [<xref ref-type="bibr" rid="ref-25">25</xref>]</td>
<td>Scalability vs. Security</td>
<td>On-chain/Off-chain solutions</td>
<td>Limited</td>
<td>None</td>
<td>ML for transaction optimization</td>
<td>No decentralization analysis</td>
</tr>
<tr>
<td>Yang et al. [<xref ref-type="bibr" rid="ref-26">26</xref>]</td>
<td>Scalability</td>
<td>Sharding, DAGs, Cross-chain</td>
<td>Protocol-level comparisons</td>
<td>None</td>
<td>P2P network improvements</td>
<td>Centralization risks in solutions</td>
</tr>
<tr>
<td>Xie et al. [<xref ref-type="bibr" rid="ref-27">27</xref>]</td>
<td>Scalability vs. Storage</td>
<td>Sharding, Hybrid storage</td>
<td>Performance benchmarks</td>
<td>None</td>
<td>Privacy preserving processing</td>
<td>Energy efficiency trade-offs</td>
</tr>
<tr>
<td>Khan et al. [<xref ref-type="bibr" rid="ref-29">29</xref>]</td>
<td>Scalability</td>
<td>Layer-1/2 solutions</td>
<td>Qualitative trade-offs</td>
<td>IoT/Healthcare constraints</td>
<td>Balanced solutions</td>
<td>No security analysis</td>
</tr>
<tr>
<td>Taylor et al. [<xref ref-type="bibr" rid="ref-31">31</xref>]</td>
<td>Security</td>
<td>Consensus mechanisms</td>
<td>Platform comparisons</td>
<td>IoT case studies</td>
<td>Sidechain architectures</td>
<td>Latency issues</td>
</tr>
<tr>
<td>Leng et al. [<xref ref-type="bibr" rid="ref-32">32</xref>]</td>
<td>Security</td>
<td>Cryptographic methods</td>
<td>PDI framework analysis</td>
<td>None</td>
<td>Quantum resistance</td>
<td>Theoretical focus</td>
</tr>
<tr>
<td>Werth et al. [<xref ref-type="bibr" rid="ref-38">38</xref>]</td>
<td>All three aspects</td>
<td>9 blockchain platforms</td>
<td>Nakamoto Coefficient analysis</td>
<td>None</td>
<td>Interchain communication</td>
<td>Limited solution depth</td>
</tr>
<tr>
<td>Lashkari and Musilek [<xref ref-type="bibr" rid="ref-39">39</xref>]</td>
<td>Consensus mechanisms</td>
<td>130 consensus algorithms</td>
<td>Cross-domain evaluation</td>
<td>Cryptocurrency /IoT</td>
<td>Hybrid mechanisms</td>
<td>No scalability metrics</td>
</tr>
<tr>
<td>Deng et al. [<xref ref-type="bibr" rid="ref-42">42</xref>]</td>
<td>Decentralization &#x0026; Security</td>
<td>Architectural layers</td>
<td>Layer-wise comparisons</td>
<td>Smart contract platforms</td>
<td>Trust mechanisms</td>
<td>Limited scalability focus</td>
</tr>
<tr>
<td><bold>Our survey</bold></td>
<td><bold>All three aspects</bold></td>
<td><bold>38 approaches across 8 categories</bold></td>
<td><bold>15 blockchain benchmarks</bold></td>
<td><bold>DeFi, Voting, Supply Chain</bold></td>
<td><bold>6 prioritized directions</bold></td>
<td><bold>14 attack vectors analyzed</bold></td>
</tr>
</tbody>
</table>
</table-wrap>
</sec>
<sec id="s5">
<label>5</label>
<title>Existing Solutions and Corresponding Challenges</title>
<p>The blockchain trilemma has inspired diverse technical approaches, each prioritizing different dimensions while managing trade-offs. <xref ref-type="fig" rid="fig-5">Fig. 5</xref> illustrates contemporary blockchain trilemma mitigation strategies, mapping technical solutions (blue nodes) to their implementation challenges (pink notes) across five architectural paradigms. Arrows denote both technical dependencies (solid) and conceptual evolution paths (dotted), demonstrating the multi-layered approach required to balance scalability, security, and decentralization.</p>
<fig id="fig-5">
<label>Figure 5</label>
<caption>
<title>Architectural approaches to blockchain trilemma resolution, showcasing sharding implementations, layer-2 protocols, consensus innovations, cryptographic enhancements, and hybrid architectures. Color-coded clusters represent solution categories (light pastels), with pink challenge nodes highlighting technical constraints. Dashed relationships show solution-specific limitations, dotted lines indicate cross-technology evolution</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66366-fig-5.tif"/>
</fig>
<p>The reviewed studies collectively address three fundamental research questions underlying the blockchain trilemma: (1) How to scale transaction processing without centralizing trust? (2) How to maintain security guarantees under resource constraints? (3) How to preserve decentralization while meeting enterprise performance requirements? As shown in <xref ref-type="table" rid="table-4">Table 4</xref>, solutions range from architectural innovations (ELASTICO&#x2019;s parallel committees) to cryptographic breakthroughs (AMHLs&#x2019; scriptless locks), each prioritizing different trilemma dimensions through distinct methodological approaches.</p>
<table-wrap id="table-4">
<label>Table 4</label>
<caption>
<title>Research questions addressed by key studies</title>
</caption>
<table>
<colgroup>
<col align="center"/>
<col align="center"/>
<col align="center"/>
<col align="center"/>
</colgroup>
<thead>
<tr>
<th align="center">Study</th>
<th align="center">Research question</th>
<th align="center">Trilemma focus</th>
<th align="center">Methodology</th>
</tr>
</thead>
<tbody>
<tr>
<td>ELASTICO [<xref ref-type="bibr" rid="ref-43">43</xref>]</td>
<td>Can sharding achieve linear throughput scaling without compromising Byzantine fault tolerance?</td>
<td>Scalability vs. Security</td>
<td>Protocol design &#x002B; 1600-node simulation</td>
</tr>
<tr>
<td>BDN [<xref ref-type="bibr" rid="ref-13">13</xref>]</td>
<td>How to scale blockchain networks while preserving decentralization through neutral infrastructure?</td>
<td>Scalability vs. Decentralization</td>
<td>Network architecture &#x002B; Economic modeling</td>
</tr>
<tr>
<td>TEE-Sharding [<xref ref-type="bibr" rid="ref-44">44</xref>]</td>
<td>Can trusted hardware enable secure cross-shard transactions in permissioned environments?</td>
<td>Security vs. Scalability</td>
<td>SGX implementation &#x002B; 1400-node cloud test</td>
</tr>
<tr>
<td>RapidChain [<xref ref-type="bibr" rid="ref-45">45</xref>]</td>
<td>How to eliminate trusted setups while achieving sublinear communication in sharded systems?</td>
<td>All three aspects</td>
<td>Cryptographic proofs &#x002B; 4000-node simulation</td>
</tr>
<tr>
<td>TrueBit [<xref ref-type="bibr" rid="ref-46">46</xref>]</td>
<td>Can verification games solve the Verifier&#x2019;s Dilemma for complex computations?</td>
<td>Security vs. Scalability</td>
<td>Game theory &#x002B; Ethereum prototype</td>
</tr>
<tr>
<td>AMHLs [<xref ref-type="bibr" rid="ref-47">47</xref>]</td>
<td>How to prevent wormhole attacks in PCNs without compromising privacy?</td>
<td>Security vs. Decentralization</td>
<td>UC framework analysis &#x002B; Lightning integration</td>
</tr>
<tr>
<td>FastBFT [<xref ref-type="bibr" rid="ref-12">12</xref>]</td>
<td>Can TEEs reduce BFT message complexity while maintaining crash fault tolerance?</td>
<td>Security vs. Scalability</td>
<td>Intel SGX deployment &#x002B; 199-node benchmark</td>
</tr>
<tr>
<td>Trifecta [<xref ref-type="bibr" rid="ref-48">48</xref>]</td>
<td>Does block graph factorization enable simultaneous scaling of proposer/voter blocks?</td>
<td>All three aspects</td>
<td>Modular design &#x002B; 100-node EC2 testing</td>
</tr>
<tr>
<td>OmniLedger [<xref ref-type="bibr" rid="ref-49">49</xref>]</td>
<td>How to achieve long-term security in sharded ledgers with dynamic validators?</td>
<td>Decentralization vs. Security</td>
<td>RandHound protocol &#x002B; 1800-node evaluation</td>
</tr>
<tr>
<td>SymB-ChainSim [<xref ref-type="bibr" rid="ref-50">50</xref>]</td>
<td>Can dynamic consensus switching optimize trilemma trade-offs in real-time?</td>
<td>All three aspects</td>
<td>DDDA5 framework &#x002B; protocol profiling</td>
</tr>
</tbody>
</table>
</table-wrap>
<p><xref ref-type="table" rid="table-5">Table 5</xref> classifies papers by their core technical innovation, explicitly naming protocols (e.g., ELASTICO, FastBFT), cryptographic primitives (zk-AMHLs), and architectural paradigms (Time-Beacon chains). Experimental works focus on protocol implementations, while application-based studies emphasize real-world deployments, case analyses, and domain-specific integrations.</p>
<table-wrap id="table-5">
<label>Table 5</label>
<caption>
<title>Multi-Page technical taxonomy of reviewed papers</title>
</caption>
<table>
<colgroup>
<col align="left"/>
<col/>
<col/>
</colgroup>
<thead>
<tr>
<th align="center">Technical contribution</th>
<th align="center">Papers</th>
<th align="center">Type</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left"><bold>A. Sharding techniques</bold></td>
<td></td>
<td></td>
</tr>
<tr>
<td align="left">&#x2002;Parallel Committee Sharding (ELASTICO)</td>
<td>[<xref ref-type="bibr" rid="ref-43">43</xref>,<xref ref-type="bibr" rid="ref-45">45</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td align="left">&#x2002;TEE-Assisted BFT Sharding with SGX</td>
<td>[<xref ref-type="bibr" rid="ref-44">44</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;OmniLedger-style Sharded Storage</td>
<td>[<xref ref-type="bibr" rid="ref-49">49</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;UTXO Partitioning with Eigenchain</td>
<td>[<xref ref-type="bibr" rid="ref-51">51</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;Satellite Chain Architecture</td>
<td>[<xref ref-type="bibr" rid="ref-52">52</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;DCS Chai</td>
<td>[<xref ref-type="bibr" rid="ref-53">53</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td><bold>B. Layer-2 protocols</bold></td>
<td></td>
<td></td>
</tr>
<tr>
<td>&#x2002;Interactive verification games (TrueBit)</td>
<td>[<xref ref-type="bibr" rid="ref-46">46</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;ECDSA-Based AMHLs for PCNs</td>
<td>[<xref ref-type="bibr" rid="ref-47">47</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;BloXroute BDN Architecture</td>
<td>[<xref ref-type="bibr" rid="ref-13">13</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;Lightning Network with HTLCs</td>
<td>[<xref ref-type="bibr" rid="ref-54">54</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td><bold>C. Consensus mechanisms</bold></td>
<td></td>
<td></td>
</tr>
<tr>
<td>&#x2002;TEE-Optimized FastBFT</td>
<td>[<xref ref-type="bibr" rid="ref-12">12</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;VRF-Based HoneyBadger Hybrid</td>
<td>[<xref ref-type="bibr" rid="ref-55">55</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;Adaptive PoS/PoW Checkpointing</td>
<td>[<xref ref-type="bibr" rid="ref-56">56</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;Reputation-Based RLSCV</td>
<td>[<xref ref-type="bibr" rid="ref-57">57</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;Double-Chain with IPFS</td>
<td>[<xref ref-type="bibr" rid="ref-58">58</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;Comparison of consensus mechanisms</td>
<td>[<xref ref-type="bibr" rid="ref-59">59</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;Layer 1 and Layer 2 solutions</td>
<td>[<xref ref-type="bibr" rid="ref-60">60</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td><bold>D. Network optimizations</bold></td>
<td></td>
<td></td>
</tr>
<tr>
<td>&#x2002;Matching-Gossip propagation</td>
<td>[<xref ref-type="bibr" rid="ref-61">61</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;Time-Beacon anchored chains</td>
<td>[<xref ref-type="bibr" rid="ref-62">62</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;FPGA-Based Caching NIC</td>
<td>[<xref ref-type="bibr" rid="ref-63">63</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;Blackchain for V2X Communication</td>
<td>[<xref ref-type="bibr" rid="ref-64">64</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;Blockchain Distribution Network (BDN)</td>
<td>[<xref ref-type="bibr" rid="ref-65">65</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td><bold>E. Cryptographic methods</bold></td>
<td></td>
<td></td>
</tr>
<tr>
<td>&#x2002;ZK-SNARKs for Bug Bounties</td>
<td>[<xref ref-type="bibr" rid="ref-66">66</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;Recursive zk-AMHLs</td>
<td>[<xref ref-type="bibr" rid="ref-67">67</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;Bulletproofs for compact verification</td>
<td>[<xref ref-type="bibr" rid="ref-47">47</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td><bold>F. Hybrid systems</bold></td>
<td></td>
<td></td>
</tr>
<tr>
<td>&#x2002;Trifecta Block graph factorization</td>
<td>[<xref ref-type="bibr" rid="ref-48">48</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;BigchainDB database hybrid</td>
<td>[<xref ref-type="bibr" rid="ref-68">68</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;Dynamic PBFT-PoA consensus</td>
<td>[<xref ref-type="bibr" rid="ref-69">69</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;Multi-Chain router protocol</td>
<td>[<xref ref-type="bibr" rid="ref-70">70</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;SymBChainSim simulation tool</td>
<td>[<xref ref-type="bibr" rid="ref-50">50</xref>]</td>
<td>Experimental</td>
</tr>
<tr>
<td>&#x2002;Federated learning</td>
<td>[<xref ref-type="bibr" rid="ref-71">71</xref>]</td>
<td>Application</td>
</tr>
<tr>
<td><bold>G. Theoretical models</bold></td>
<td></td>
<td></td>
</tr>
<tr>
<td>&#x2002;Continuous PoW Trilemma Formulation</td>
<td>[<xref ref-type="bibr" rid="ref-72">72</xref>,<xref ref-type="bibr" rid="ref-73">73</xref>]</td>
<td>Application</td>
</tr>
<tr>
<td>&#x2002;Committee Pipeline Scaling Theory</td>
<td>[<xref ref-type="bibr" rid="ref-74">74</xref>]</td>
<td>Application</td>
</tr>
<tr>
<td>&#x2002;Sharded PBFT Latency Analysis</td>
<td>[<xref ref-type="bibr" rid="ref-75">75</xref>]</td>
<td>Application</td>
</tr>
<tr>
<td>&#x2002;Comparative Analysis of Layer 1 and Layer 2 Solutions</td>
<td>[<xref ref-type="bibr" rid="ref-76">76</xref>]</td>
<td>Theoretical</td>
</tr>
<tr>
<td>&#x2002;DCS Framework and Blockchain Reference Architecture</td>
<td>[<xref ref-type="bibr" rid="ref-77">77</xref>]</td>
<td>Theoretical</td>
</tr>
<tr>
<td>&#x2002;Review of Blockchain Trilemma Solutions and Trade-off</td>
<td>[<xref ref-type="bibr" rid="ref-78">78</xref>]</td>
<td>Application</td>
</tr>
<tr>
<td>&#x2002;Comparative Analysis of Algorand and Ethereum 2.0</td>
<td>[<xref ref-type="bibr" rid="ref-79">79</xref>]</td>
<td>Application</td>
</tr>
<tr>
<td>&#x2002;GDPR compliance issues with blockchain mutability</td>
<td>[<xref ref-type="bibr" rid="ref-80">80</xref>]</td>
<td>Theoretical</td>
</tr>
<tr>
<td>&#x2002;Cryptographic mechanisms to Enforce GDPR</td>
<td>[<xref ref-type="bibr" rid="ref-81">81</xref>]</td>
<td>Theoretical</td>
</tr>
<tr>
<td><bold>H. Security analysis</bold></td>
<td/>
<td/>
</tr>
<tr>
<td>&#x2002;Algorand DDoS vulnerability</td>
<td>[<xref ref-type="bibr" rid="ref-82">82</xref>]</td>
<td>Application</td>
</tr>
<tr>
<td>&#x2002;Proof-of-Parity framework</td>
<td>[<xref ref-type="bibr" rid="ref-83">83</xref>]</td>
<td>Application</td>
</tr>
<tr>
<td><bold>I. Applied implementations</bold></td>
<td></td>
<td></td>
</tr>
<tr>
<td>&#x2002;Microgrid energy trading</td>
<td>[<xref ref-type="bibr" rid="ref-84">84</xref>]</td>
<td>Application</td>
</tr>
<tr>
<td>&#x2002;V2X blockchain security</td>
<td>[<xref ref-type="bibr" rid="ref-64">64</xref>]</td>
<td>Application</td>
</tr>
<tr>
<td>&#x2002;IoT light node optimization</td>
<td>[<xref ref-type="bibr" rid="ref-63">63</xref>]</td>
<td>Application</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>Below, we categorize prominent solutions based on their core architectural focus:</p>
<sec id="s5_1">
<label>5.1</label>
<title>Sharding Solutions</title>
<p>Sharding techniques partition blockchain networks into parallel processing units to enhance throughput while preserving decentralization.</p>
<sec id="s5_1_1">
<label>5.1.1</label>
<title>Sharding Throughput Gain</title>
<p>For <inline-formula id="ieqn-63"><mml:math id="mml-ieqn-63"><mml:mi>k</mml:mi></mml:math></inline-formula> shards, each processing <inline-formula id="ieqn-64"><mml:math id="mml-ieqn-64"><mml:msub><mml:mi>t</mml:mi><mml:mrow><mml:mtext>shard</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> transactions per second (TPS), the total throughput is:
<disp-formula id="eqn-21"><label>(21)</label><mml:math id="mml-eqn-21" display="block"><mml:msub><mml:mrow><mml:mtext>TPS</mml:mtext></mml:mrow><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>k</mml:mi><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mrow><mml:mtext>t</mml:mtext></mml:mrow><mml:mrow><mml:mrow><mml:mtext>shard</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:mn>1</mml:mn><mml:mo>&#x2212;</mml:mo><mml:mi>&#x03B2;</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mspace width="thinmathspace" /><mml:mo>.</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-65"><mml:math id="mml-ieqn-65"><mml:mi>&#x03B2;</mml:mi></mml:math></inline-formula> is the cross-shard coordination overhead (<inline-formula id="ieqn-66"><mml:math id="mml-ieqn-66"><mml:mn>0</mml:mn><mml:mo>&#x003C;</mml:mo><mml:mi>&#x03B2;</mml:mi><mml:mo>&#x003C;</mml:mo><mml:mn>1</mml:mn></mml:math></inline-formula>).</p>
</sec>
<sec id="s5_1_2">
<label>5.1.2</label>
<title>Security Analysis of Sharding</title>
<p>The probability of a shard being compromised by <inline-formula id="ieqn-67"><mml:math id="mml-ieqn-67"><mml:mi>f</mml:mi></mml:math></inline-formula> Byzantine nodes is:
<disp-formula id="eqn-22"><label>(22)</label><mml:math id="mml-eqn-22" display="block"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mrow><mml:mtext>fail</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mstyle scriptlevel="0"><mml:mrow><mml:mo maxsize="2.047em" minsize="2.047em">(</mml:mo></mml:mrow></mml:mstyle><mml:mfrac linethickness="0"><mml:mi>n</mml:mi><mml:mi>f</mml:mi></mml:mfrac><mml:mstyle scriptlevel="0"><mml:mrow><mml:mo maxsize="2.047em" minsize="2.047em">)</mml:mo></mml:mrow></mml:mstyle></mml:mrow><mml:msup><mml:mrow><mml:mo>(</mml:mo><mml:mfrac><mml:msub><mml:mi>f</mml:mi><mml:mrow><mml:mrow><mml:mtext>global</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:msub><mml:mi>n</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mspace width="negativethinmathspace" /><mml:mi>f</mml:mi></mml:mrow></mml:msup><mml:msup><mml:mrow><mml:mo>(</mml:mo><mml:mn>1</mml:mn><mml:mo>&#x2212;</mml:mo><mml:mfrac><mml:msub><mml:mi>f</mml:mi><mml:mrow><mml:mrow><mml:mtext>global</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:msub><mml:mi>n</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mspace width="negativethinmathspace" /><mml:mi>n</mml:mi><mml:mo>&#x2212;</mml:mo><mml:mi>f</mml:mi></mml:mrow></mml:msup></mml:math></disp-formula>where <inline-formula id="ieqn-68"><mml:math id="mml-ieqn-68"><mml:msub><mml:mi>f</mml:mi><mml:mrow><mml:mtext>global</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is the total malicious nodes in the network.</p>
<p>In [<xref ref-type="bibr" rid="ref-43">43</xref>], the authors introduced ELASTICO, a novel sharding protocol designed to overcome the scalability limitations of open blockchains like Bitcoin while ensuring security against Byzantine adversaries. The authors identified the critical challenge of achieving linear scalability in transaction throughput without compromising decentralization or security, a problem unsolved by existing consensus protocols such as Nakamoto consensus or classical Byzantine fault-tolerant (BFT) approaches. The core innovation of ELASTICO lay in its partitioning of the mining network into smaller committees, each processing disjoint transaction shards in parallel, with the number of committees scaling near-linearly with the network&#x2019;s computational power. The protocol operated in five key steps: (1) identity establishment via proof-of-work (PoW) to limit Sybil attacks, (2) committee formation and overlay setup using a directory committee to reduce communication overhead, (3) intra-committee consensus employing PBFT to agree on transaction shards, (4) final consensus by a designated committee to aggregate shards into a single blockchain update, and (5) epoch randomness generation to ensure unbiased committee assignments in subsequent epochs. The authors implemented ELASTICO as an extension of Bitcoin&#x2019;s codebase, adding approximately 5000 lines of C&#x002B;&#x002B;, and evaluated its performance on Amazon EC2 with networks of up to 1600 nodes. The experiments demonstrated near-linear scalability, with throughput increasing from 1 block per epoch (100 nodes) to 13.5 blocks (1600 nodes), while maintaining constant per-node bandwidth usage (<inline-formula id="ieqn-69"><mml:math id="mml-ieqn-69"><mml:mo>&#x223C;</mml:mo></mml:math></inline-formula>5 MB) and tolerating up to 1/4 Byzantine adversaries. Key performance metrics included transaction throughput, latency, message complexity (<inline-formula id="ieqn-70"><mml:math id="mml-ieqn-70"><mml:mrow><mml:mi>&#x1D4AA;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>n</mml:mi><mml:mi>c</mml:mi><mml:mo>+</mml:mo><mml:mi>n</mml:mi><mml:msup><mml:mi>c</mml:mi><mml:mn>3</mml:mn></mml:msup><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>), and bandwidth efficiency, all of which confirmed the protocol&#x2019;s theoretical claims. The final results showed a 4-order-of-magnitude improvement over Bitcoin&#x2019;s throughput when extrapolated to Bitcoin&#x2019;s scale, achieving 10,000 blocks per epoch. Security proofs established probabilistic agreement, validity, and randomness guarantees, with lemmas bounding adversarial influence (e.g., Lemma 2 ensured honest majority in committees). However, the work assumes partial synchrony and reliable committee formation, which may not hold in highly dynamic or adversarial network conditions. The security protocol&#x2019;s heavily relies on the assumption of a static, round-adaptive adversary and does not fully address real-world network churn or eclipse attacks.</p>
<p>In the study [<xref ref-type="bibr" rid="ref-65">65</xref>], the authors explored the scalability challenges inherent in blockchain technology, particularly focusing on the inefficiencies of trustless peer-to-peer networks that result in slow transaction processing speeds, as exemplified by Bitcoin&#x2019;s mere three transactions per second (TPS). They identified the root cause as the suboptimal propagation and validation of information across decentralized nodes, which creates bottlenecks due to cryptographic operations at each hop, high performance variance among nodes, and inefficient network paths. To address this, they proposed leveraging cloud-delivery networks (CDNs), such as Akamai and YouTube, which have successfully scaled other domains (e.g., web and video delivery) by optimizing data distribution. However, the centralized nature of CDNs conflicts with blockchain&#x2019;s decentralized ethos, raising concerns about censorship and trust. As a solution, the authors introduced a Blockchain Distribution Network (BDN), a provably neutral network that decouples authority from infrastructure, ensuring scalability without compromising decentralization. The BDN employed several key mechanisms: encrypted blocks to prevent content-based censorship, indirect relay to obscure block origins, and continuous auditing via test blocks to detect and mitigate discriminatory behavior. Additionally, it optimized performance through transaction caching (reducing block size by indexing transactions), cut-through routing (accelerating data transmission), and mitigating the transaction incast problem (minimizing redundant data reception). The authors compared their approach with existing scaling solutions, such as off-chain methods (e.g., the Lightning Network) and on-chain techniques (e.g., sharding), arguing that the BDN complements these methods by fundamentally improving the network layer. They further theorized that BDN could dramatically enhance scalability by leveraging optimized network-layer techniques like cut-through routing, transaction caching (reducing block sizes by over 100x), and eliminating the incast problem. Additionally, they suggested that, with dedicated infrastructure (e.g., optical networks), BDN could achieve microsecond-scale latencies, similar to modern data centers. Performance evaluation highlighted the BDN&#x2019;s potential to significantly increase throughput and reduce latency, reinforcing the possibility of achieving microsecond-scale latencies in dedicated infrastructures. The research concluded that provably neutral clouds, like the BDN, offer a viable path to scaling blockchain networks while preserving their decentralized nature, provided the blockchain ecosystem can trust the underlying network infrastructure. However, a key limitation of the proposed BDN is its reliance on continuous auditing and the potential complexity of maintaining neutrality in practice.</p>
<p>Hung Dang et al. [<xref ref-type="bibr" rid="ref-44">44</xref>] addressed the critical scalability challenges in blockchain systems by proposing a sharding-based approach tailored for permissioned blockchains, aiming to achieve high transaction throughput while supporting general workloads beyond cryptocurrency applications. The authors identified three primary challenges in applying traditional database sharding techniques to blockchains: scaling Byzantine Fault Tolerance (BFT) consensus protocols, ensuring secure and efficient shard formation, and enabling secure distributed transactions even with malicious coordinators. To tackle these challenges, they leveraged trusted execution environments (TEEs), specifically Intel SGX, to enhance the performance of BFT consensus protocols by eliminating equivocation, thereby allowing a committee of <inline-formula id="ieqn-71"><mml:math id="mml-ieqn-71"><mml:mi>n</mml:mi></mml:math></inline-formula> nodes to tolerate up to <inline-formula id="ieqn-72"><mml:math id="mml-ieqn-72"><mml:mfrac><mml:mrow><mml:mi>n</mml:mi><mml:mspace width="thinmathspace" /><mml:mo>&#x2212;</mml:mo><mml:mspace width="thinmathspace" /><mml:mn>1</mml:mn></mml:mrow><mml:mn>2</mml:mn></mml:mfrac></mml:math></inline-formula> Byzantine failures, a significant improvement over the traditional <inline-formula id="ieqn-73"><mml:math id="mml-ieqn-73"><mml:mfrac><mml:mrow><mml:mi>n</mml:mi><mml:mspace width="thinmathspace" /><mml:mo>&#x2212;</mml:mo><mml:mspace width="thinmathspace" /><mml:mn>1</mml:mn></mml:mrow><mml:mn>3</mml:mn></mml:mfrac></mml:math></inline-formula> threshold. They introduced optimizations such as separating message queues and removing redundant request broadcasts to reduce communication overhead, resulting in their AHL&#x002B; protocol, which outperformed existing solutions like PBFT and AHLR in terms of throughput and scalability. For shard formation, the authors designed a TEE-assisted protocol using a trusted randomness beacon to securely and efficiently assign nodes to shards, ensuring that no shard could be compromised by adversarial nodes while also enabling smaller committee sizes (e.g., 80 nodes for a 25% adversarial power) compared to prior works like OmniLedger, which required 600-node committees. Additionally, they proposed a distributed transaction protocol combining two-phase locking (2PL) and two-phase commit (2PC) to handle cross-shard transactions securely, even with malicious coordinators, by employing a Byzantine fault-tolerant reference committee to coordinate transactions. The authors conducted extensive evaluations on both a local 100-node cluster and a large-scale Google Cloud Platform (GCP) setup with over 1400 nodes across eight regions, demonstrating that their sharded blockchain achieved a throughput of over 3000 transactions per second, capable of handling Visa-level workloads&#x2014;the highest reported in a realistic environment at the time. Their results showed linear scalability with the number of shards and highlighted the effectiveness of their optimizations, such as reducing message drops and improving fault tolerance.</p>
<p>In the study [<xref ref-type="bibr" rid="ref-52">52</xref>], authors proposed a novel blockchain architecture designed to address key industrial challenges such as privacy, scalability, and governance in permission-based blockchain systems. They introduced the concept of &#x201C;satellite chains,&#x201D; which are interconnected yet independent subchains that operate in parallel, each maintaining its own private ledger and consensus protocol tailored to the needs of its stakeholders. This design allowed nodes to join multiple satellite chains simultaneously, ensuring privacy by restricting transaction visibility only to relevant participants while enabling cross-chain asset transfers without compromising security. The architecture also incorporated a regulatory framework where regulators could enforce policies across all satellite chains using smart contracts, specifically through a &#x201D;policy directory contract&#x201D; that managed and deployed policy checks dynamically. To validate their approach, the authors integrated their solution with Hyperledger Fabric v0.6, adapting its structure to support multiple ledgers, cross-chain transactions, and policy enforcement mechanisms. They extended Fabric&#x2019;s functionality by introducing data structures like chain-to-consensus and chain-to-peers maps to manage satellite chains and their participants, and implemented a policy directory chaincode to automate policy deployment and validation. The integration demonstrated the feasibility of their architecture, showcasing its ability to enhance scalability by allowing parallel consensus protocols and improving privacy through selective transaction visibility. The authors highlighted that their solution effectively realized blockchain sharding based on node relationships, making it suitable for industrial applications like trade finance and supply chain management. However, the work does not provide extensive empirical results or benchmarks to quantify the performance gains or overheads of their architecture.</p>
<p>The research article [<xref ref-type="bibr" rid="ref-45">45</xref>], authored by Mahdi Zamani et al., introduced RapidChain, a novel sharding-based public blockchain protocol designed to address the scalability and performance limitations of existing blockchain systems. The authors identified key bottlenecks in previous sharding-based protocols, such as linear communication overhead per transaction, low fault resiliency (e.g., 1/4 or 1/8), and reliance on trusted setups, which hindered their practicality for mainstream payment systems. RapidChain proposed a fully sharded architecture that partitioned the network into smaller committees operating in parallel, achieving sublinear communication overhead, higher Byzantine fault resiliency (up to 1/3 of participants), and eliminating the need for trusted setups. The protocol employed several innovative techniques, including an optimal intra-committee consensus algorithm based on synchronous Byzantine consensus, a novel gossiping protocol (IDA-Gossip) for efficient large block propagation, and a provably secure reconfiguration mechanism inspired by the Cuckoo rule to handle dynamic membership changes. Additionally, RapidChain introduced a fast cross-shard verification method leveraging Kademlia-inspired routing to minimize inter-committee communication and a decentralized bootstrapping protocol that avoided the quadratic message complexity of previous solutions. The authors implemented a prototype of RapidChain and evaluated its performance in a simulated network of up to 4000 nodes, demonstrating significant improvements over state-of-the-art protocols like Elastico and OmniLedger. RapidChain achieved a throughput of over 7300 transactions per second with a confirmation latency of approximately 8.7 s, while maintaining a high time-to-failure of over 4500 years. The evaluation also highlighted the protocol&#x2019;s efficiency in handling cross-shard transactions, storage scalability, and reconfiguration latency. Despite its advancements, RapidChain&#x2019;s reliance on synchronous communication during intra-committee consensus limits its responsiveness to network delays.</p>
<p>In another study [<xref ref-type="bibr" rid="ref-51">51</xref>], the authors proposed an innovative solution to Bitcoin&#x2019;s scalability challenges by introducing a mechanism to partition the Unspent Transaction Output (UTXO) set and split the blockchain into multiple sub-chains. The core idea revolved around &#x201D;split events,&#x201D; where the UTXO space and mempool were divided deterministically based on scriptPubKey hashes, creating independently operating sub-chains that allowed multiple blocks to be mined simultaneously during each block interval. This approach significantly increased transaction throughput while preserving Bitcoin&#x2019;s decentralized nature. To ensure consistency across sub-chains, the authors introduced an eigenchain, a secondary blockchain that stored block headers from all sub-chains, requiring miners to perform atomic mining&#x2014;simultaneously producing blocks for each sub-chain and the eigenchain&#x2014;thereby maintaining security and preventing manipulation. A key innovation was the introduction of half nodes, lightweight nodes that tracked only one sub-chain and the eigenchain, reducing bandwidth and storage requirements while still enabling transaction verification. This addressed a major decentralization concern, as it allowed users in low-resource environments to participate in the network without running full nodes. The work also detailed transaction handling post-split, including Hashed Time-Lock Contracts (HTLCs) for atomic cross-sub-chain payments and eigentransactions for secure fund transfers between sub-chains. The performance evaluation compared Split-Scale with existing solutions like Segregated Witness (SegWit) and Bitcoin-NG, demonstrating that it offered exponential scalability (Nx with each split event) while maintaining decentralization. Miners benefited from increased fee collection across all sub-chains, and half nodes ensured that network participation remained accessible. The results showed that Split-Scale could achieve higher throughput without compromising security or decentralization, making it a promising alternative to current scaling approaches. The complexity of managing multiple sub-chains and the need for consensus on split events remain challenges.</p>
</sec>
</sec>
<sec id="s5_2">
<label>5.2</label>
<title>Layer-2 Scaling Solutions</title>
<p>Layer-2 solutions refer to off-chain protocols and secondary networks that enhance throughput while leveraging base-layer security.</p>
<p>The research article authored by Jason Teutsch et al. [<xref ref-type="bibr" rid="ref-46">46</xref>] introduced TrueBit, a scalable verification solution designed to address the computational limitations of blockchain systems like Ethereum and Bitcoin, which, despite their vast mining power, struggle with processing and verifying transactions efficiently due to the Verifier&#x2019;s Dilemma&#x2014;a scenario where miners skip verification to avoid falling behind in the mining race. The authors proposed a two-layer system: a dispute resolution layer employing an interactive &#x201D;verification game&#x201D; to pinpoint computational errors through iterative rounds of challenge and response, and an incentive layer that financially motivates participants (Solvers and Verifiers) to perform and verify computations correctly. The verification game relied on Merkle trees and binary search to isolate disputed computation steps, ensuring Judges (Ethereum miners) could resolve disputes with minimal computational effort. The incentive layer incorporated mechanisms like forced errors, jackpot payouts, taxes, and deposits to ensure Solvers and Verifiers acted honestly, with forced errors occurring randomly to incentivize consistent verification. The work evaluated the system&#x2019;s efficiency by analyzing the runtime and security of the verification game, demonstrating that the Judges&#x2019; workload remained manageable, with the total verification time scaling logarithmically with task complexity. The performance was further validated through economic incentives, ensuring that rational participants would not deviate from the protocol due to the high costs of cheating and the rewards for honest participation. The results showed that TrueBit enabled secure, trustless outsourcing of complex computations to Ethereum smart contracts, bypassing the gasLimit constraint and supporting applications like decentralized mining pools, cross-blockchain currency transfers, and scalable transaction throughput. The system&#x2019;s adaptability was highlighted by its compatibility with existing Ethereum infrastructure and its potential for future optimizations, such as specialized verification games for specific tasks. However, the work&#x2019;s limitation is that the security and efficiency of TrueBit degrade for extremely complex or big data tasks due to the impracticality of the verification game&#x2019;s overhead in such scenarios.</p>
<p>Anonymous Multi-Hop Locks (AMHLs) [<xref ref-type="bibr" rid="ref-47">47</xref>] have been introduced as a novel cryptographic primitive to address scalability and privacy issues in Payment Channel Networks (PCNs), such as the Lightning Network. The authors began by identifying a new attack, termed the &#x201D;wormhole attack,&#x201D; which allows malicious users to steal fees from honest intermediaries in PCNs, demonstrating vulnerabilities in existing systems like the Lightning Network and Raiden Network. To mitigate this, they formally defined AMHLs, a cryptographic tool enabling secure and privacy-preserving multi-hop payments, and provided several provably secure constructions compatible with most cryptocurrencies, including script-based (using homomorphic one-way functions) and scriptless (using ECDSA signatures) implementations. The scriptless ECDSA-based solution was particularly significant as it resolved a long-standing open problem in the field and was subsequently implemented by Lightning Network developers. The authors conducted a rigorous security analysis using the Universal Composability (UC) framework, ensuring their constructions were secure against concurrent executions and composable with other protocols. They also established a lower bound on communication complexity, proving that an extra round of communication is necessary for secure transactions to prevent wormhole attacks. Performance evaluations on commodity hardware showed that AMHL operations were highly efficient, with computation times under 100 ms and communication overhead below 500 bytes, even in worst-case scenarios. The practical impact of their work was underscored by the Lightning Network&#x2019;s adoption of their ECDSA-based AMHLs, which improved security, privacy, and interoperability while maintaining scalability. Additionally, the authors demonstrated the versatility of AMHLs by extending their use to atomic swaps and interoperable PCNs, enabling cross-currency transactions. The performance results highlighted the feasibility of their approach, with the generic construction requiring minimal gas (350,849 units per hop in Ethereum) and scriptless constructions eliminating the need for additional scripts, reducing transaction size and blockchain load. Despite these advancements, a key limitation of this work is that the proposed constructions do not support adaptive corruption queries, leaving the security of dynamically corruptible environments an open question.</p>
<p>BloXroute [<xref ref-type="bibr" rid="ref-13">13</xref>] is a Blockchain Distribution Network (BDN) designed to address the scalability limitations of blockchain systems while preserving decentralization and trustlessness. The authors identified that existing blockchains, such as Bitcoin, suffer from low throughput (e.g., 2.94 TPS compared to Visa&#x2019;s 2000 TPS) due to inefficiencies in peer-to-peer (P2P) propagation models, where block propagation times increase linearly with block size, leading to forks, security vulnerabilities, and centralization pressures. To overcome these challenges, the work proposed a global, protocol-agnostic BDN that leverages high-capacity, low-latency infrastructure to accelerate block propagation without requiring trust in the network itself. Key innovations included encrypted blocks to ensure neutrality, indirect relay mechanisms to obscure block origins, and test-blocks for continuous auditing, ensuring the BDN could not discriminate based on content, origin, or destination. The system employed cut-through routing and system-wide caching to enable gigabyte-sized blocks and reduce propagation delays, theoretically increasing throughput by over three orders of magnitude (e.g., supporting 200,000 TPS with conservative estimates). Performance evaluation demonstrated that bloXroute could reduce block propagation times dramatically, enabling blockchains to scale to Visa-like throughput by simply adjusting block size and inter-block intervals, while maintaining security and decentralization. The work also introduced BLXR, an ERC20 token, to align incentives across the ecosystem by distributing revenues from transaction fees to token holders, with projected annual revenues exceeding $3.1 billion at scale. The results highlighted bloXroute&#x2019;s ability to close the gap between decentralized blockchains and traditional payment systems, unlocking applications like microtransactions and IoT automation. However, the system&#x2019;s reliance on voluntary payments for sustainability and the potential for collusion between the BDN and a subset of peers remain limitations.</p>
<p>Joseph Poon and Thaddeus Dryja [<xref ref-type="bibr" rid="ref-54">54</xref>], proposed a decentralized solution to Bitcoin&#x2019;s scalability problem by introducing the Lightning Network, a system of micropayment channels that enable instant, high-volume transactions without overburdening the blockchain. The authors identified the limitations of Bitcoin&#x2019;s blockchain, such as its inability to handle global transaction volumes due to block size constraints, which lead to centralization risks and high fees. To address this, they designed a network of bidirectional payment channels where transactions occur off-chain, only settling on the blockchain when necessary, thus reducing congestion and maintaining decentralization. The core innovation involved the use of Revocable Sequence Maturity Contracts (RSMCs) and Hashed Timelock Contracts (HTLCs) to ensure security and trustlessness. RSMCs allowed parties to update channel states while penalizing dishonest behavior by revoking outdated transactions, while HTLCs facilitated multi-hop payments across the network using hash-based conditions and decrementing timelocks to ensure atomicity. The research detailed the construction of these contracts, including the need for a malleability fix (SIGHASH_NOINPUT) to prevent transaction ID mutations and enable secure off-chain agreements. The authors also discussed key management strategies, such as hierarchical deterministic wallets, to minimize storage overhead and ensure scalability. Performance evaluation highlighted the network&#x2019;s potential to support billions of transactions with minimal blockchain footprint, enabling micropayments, instant transactions, and cross-chain interoperability. The final result demonstrated that the Lightning Network could achieve Visa-like transaction throughput (47,000 tps) while retaining Bitcoin&#x2019;s decentralized security model, with fees asymptotically approaching zero due to off-chain settlement. The system&#x2019;s value lay in its ability to scale Bitcoin for global adoption without compromising its core principles. The work relies on soft-fork upgrades to Bitcoin, such as SIGHASH_NOINPUT and OP_CHECKSEQUENCEVERIFY, which may face implementation challenges or resistance from the community.</p>
</sec>
<sec id="s5_3">
<label>5.3</label>
<title>Emerging Consensus Paradigms</title>
<p>Recent advancements in consensus design aim to address the trilemma through novel architectures:
<list list-type="bullet">
<list-item>
<p><bold>Narwhal &#x0026; Tusk (Aptos):</bold> Decouples transaction dissemination (Narwhal) from consensus (Tusk), achieving 160,000 TPS in benchmarks [<xref ref-type="bibr" rid="ref-85">85</xref>]. While Narwhal&#x2019;s mempool ensures availability via directed acyclic graphs (DAGs), Tusk leverages randomized leader elections for asynchronous safety. Trade-offs include increased memory demands for DAG storage.</p></list-item>
<list-item>
<p><bold>Snowman&#x002B;&#x002B; (Avalanche):</bold> Optimizes the Snow family of protocols for linear blockchains, combining DAG-based voting with a totally ordered ledger. Its <italic>decision threshold</italic> mechanism reduces latency to 1&#x2013;2 s while tolerating 40% Byzantine nodes [<xref ref-type="bibr" rid="ref-86">86</xref>]. However, validator incentives remain centralized in early deployments.</p></list-item>
<list-item>
<p><bold>Proof of History (PoH-Solana):</bold> Uses cryptographic timestamps (SHA-256 chains) as a verifiable clock, enabling parallel transaction processing. PoH reduces consensus overhead by 65% compared to PBFT [<xref ref-type="bibr" rid="ref-87">87</xref>], but depends on leader nodes for sequencing&#x2014;creating single points of failure during network partitions.</p></list-item>
</list></p>
</sec>
<sec id="s5_4">
<label>5.4</label>
<title>Consensus Mechanism Innovations</title>
<p>Consensus mechanisms denote novel approaches to achieving agreement while balancing trilemma constraints. The general working mechanism of consensus algorithms is depicted using <xref ref-type="fig" rid="fig-6">Fig. 6</xref>.</p>
<fig id="fig-6">
<label>Figure 6</label>
<caption>
<title>General working procedure of consensus mechanisms</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66366-fig-6.tif"/>
</fig>
<p>Monu Chaudhary et al. [<xref ref-type="bibr" rid="ref-76">76</xref>] explored the challenges posed by the blockchain trilemma, which highlights the difficulty in simultaneously achieving decentralization, security, and scalability in blockchain networks. The authors provided a comprehensive analysis of Layer 1 (base layer) and Layer 2 (off-chain) solutions aimed at addressing these challenges. They began by explaining the foundational concepts of blockchain, including consensus mechanisms like Proof of Work (PoW) and Proof of Stake (PoS), and elaborated on how these mechanisms contribute to the trilemma. The study categorized scalability solutions into Layer 1 approaches, such as increasing block size, adopting alternative consensus algorithms (e.g., PoS), sharding, and Directed Acyclic Graphs (DAGs), and Layer 2 solutions, including channels (e.g., Lightning Network), sidechains, rollups, and cross-chain protocols. The authors performed a comparative analysis of these solutions, evaluating their impact on transaction speeds, implementation complexity, and trade-offs between decentralization, security, and scalability. They utilized real-world data, such as transaction speeds from blockchain networks like Bitcoin, Ethereum, and Layer 2 platforms like Polygon and Solana, to illustrate the performance improvements offered by these solutions. For instance, Ethereum 2.0&#x2019;s theoretical transaction speed of 100,000 TPS and Solana&#x2019;s 3000 TPS were highlighted as significant advancements over Bitcoin&#x2019;s 7 TPS and Ethereum 1.0&#x2019;s 20 TPS. The results demonstrated that Layer 2 solutions, such as the Lightning Network and sidechains, were easier and faster to implement compared to Layer 1 modifications, which often required hard forks and extensive protocol changes. However, the authors noted that despite these advancements, no solution fully resolved the trilemma, as trade-offs between the three pillars persisted. The authors concluded the study by emphasizing the need for further research to achieve a harmonious balance between decentralization, security, and scalability. A key limitation of the work is that the work does not propose a novel solution to entirely solve the blockchain trilemma but rather synthesizes and evaluates existing approaches.</p>
<p>In the scholarly article [<xref ref-type="bibr" rid="ref-57">57</xref>], the authors introduced Chameleon, a scalable and adaptive permissioned blockchain architecture designed to address key challenges in blockchain systems, including scalability, security, and resource utilization. The authors structured their solution into four layers: the control and authentication layer, responsible for issuing certificates and load balancing; the cloud storage layer, which offloaded historical block data to local, edge, or core clouds to reduce node storage burdens; the consensus and processing layer, where nodes were partitioned into different areas, each capable of running tailored consensus protocols; and the access layer, enabling clients to register and interact with the system. To enhance security, the work proposed RLSCV (Random Leader Selection based on Credit Value), an improved Byzantine consensus protocol where leaders were selected probabilistically based on their credit scores&#x2014;calculated as <inline-formula id="ieqn-74"><mml:math id="mml-ieqn-74"><mml:msub><mml:mi>log</mml:mi><mml:mn>2</mml:mn></mml:msub><mml:mo>&#x2061;</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>B</mml:mi><mml:mi>n</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> (with <inline-formula id="ieqn-75"><mml:math id="mml-ieqn-75"><mml:msub><mml:mi>B</mml:mi><mml:mi>n</mml:mi></mml:msub></mml:math></inline-formula> being the number of blocks a node has produced as a leader)&#x2014;ensuring that honest nodes had a higher chance of leading while preventing predictability-based attacks like DoS. For scalability and efficiency, the system incorporated QoS-aware transaction processing, classifying transactions into four types (ordinary, cross-area, cooperative, and sub-area) with priority levels (network control, instant processing, accelerated, and ordinary), enabling dynamic load balancing. The cloud storage integration allowed nodes to store only recent epoch data (e.g., one day or one week) while archiving older blocks in distributed clouds, significantly reducing storage overhead. To evaluate performance, the authors conducted simulations in MATLAB, modeling transaction arrivals using a Poisson process and testing the load balancing mechanism under varying transaction rates. The experiments assumed each area had a processing capacity of 400 transactions per second (TPS), a realistic benchmark derived from tests on Hyperledger Fabric with PBFT consensus. Three key scenarios were analyzed: moderate overload (400 TPS in Area-2), where the system redistributed transactions to Area-3, dropping Area-2&#x2019;s load from 1.0 to 0.8 and increasing Area-3&#x2019;s load from 0.3 to 0.5; high overload (600 TPS in Area-2), where transactions were offloaded to Area-3 and Area-5, reducing Area-2&#x2019;s load to 0.8 while raising Area-3 and Area-5&#x2019;s loads to 0.6 and 0.4, respectively; and extreme overload (800 TPS in Area-2), where transactions were distributed across Area-1, Area-3, and Area-5, stabilizing Area-2&#x2019;s load at 0.8 and adjusting the assisting areas to 0.5, 0.6, and 0.5, respectively. The results proved that Chameleon&#x2019;s load balancing algorithm effectively optimized resource utilization, preventing bottlenecks and maintaining performance even when transaction rates doubled the baseline capacity (800 TPS vs. 400 TPS). The credit-based leader selection (RLSCV) also ensured security by preventing Sybil and DoS attacks, while cloud storage integration reduced node storage requirements by archiving older blocks off-chain. However, the work remains a proof-of-concept without real-world deployment, and the overhead of cross-area transaction synchronization under load balancing needs further investigation. The system&#x2019;s reliance on a centralized control and authentication layer (CA) introduces a potential bottleneck and single point of failure.</p>
<p>Jian Liu et al. [<xref ref-type="bibr" rid="ref-12">12</xref>] proposed FastBFT, a fast and scalable Byzantine fault-tolerant (BFT) protocol designed to address the inefficiencies and scalability limitations of existing BFT protocols, which typically suffer from <inline-formula id="ieqn-76"><mml:math id="mml-ieqn-76"><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msup><mml:mi>n</mml:mi><mml:mn>2</mml:mn></mml:msup><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> message complexity, making them impractical for large-scale networks. The authors leveraged trusted execution environments (TEEs), such as Intel SGX, combined with a novel message aggregation technique using lightweight secret sharing to reduce the message complexity to <inline-formula id="ieqn-77"><mml:math id="mml-ieqn-77"><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>n</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>, significantly improving performance and scalability. FastBFT incorporated several optimizations, including optimistic execution, a tree-based communication topology to distribute computational and communication loads, and a failure detection mechanism to handle non-primary faults efficiently. The protocol operated in two modes: a normal-case mode for optimal performance and a fallback mode(classical BFT with message aggregation) for handling persistent faults, ensuring robustness under varying conditions. The authors implemented FastBFT and evaluated its performance against existing BFT protocols like Zyzzyva, MinBFT, CheapBFT, and XPaxos, demonstrating that FastBFT achieved significantly higher throughput and lower latency, especially as the network size grew. For instance, with 199 replicas, FastBFT processed 370 operations per second for 1 KB payloads, outperforming Zyzzyva by a factor of 6, and scaled efficiently even for larger payloads (1 MB), achieving 260 times higher throughput than Zyzzyva. The performance gains were attributed to the reduction in communication overhead and the efficient use of TEEs for secret sharing and aggregation. The results confirmed that FastBFT struck an optimal balance between performance and resilience, making it a suitable candidate for next-generation blockchain systems, with the potential to process over 100,000 transactions per second under realistic assumptions.</p>
<p>In [<xref ref-type="bibr" rid="ref-55">55</xref>], authors presented a novel consensus model aimed at addressing the blockchain trilemma&#x2014;balancing decentralization, security, and scalability&#x2014;by integrating advanced cryptographic techniques, stake management, and random leader selection mechanisms. The authors began by highlighting the limitations of existing consensus models, such as PoW and PoS, which often prioritize one aspect of the trilemma at the expense of others. To overcome these challenges, they proposed a comprehensive framework that combined Verifiable Random Functions (VRF) for unbiased slot leader selection, dynamic stake recalibration based on reputation and economic performance, and batch agreement systems for efficient transaction processing. The methodology involved establishing a decentralized network where nodes were assigned initial stakes and cryptographic key pairs, followed by an epoch-based structure for synchronization and stake adjustment. The consensus process included transaction gathering by slot leaders, block proposal, validation through Honey Badger Byzantine Fault Tolerance (BFT) and other cryptographic techniques, and fault tolerance mechanisms to mitigate malicious activity. The authors also incorporated sharding and layer-2 solutions like optimistic rollups to enhance scalability and interoperability across blockchain platforms. To evaluate their model, they analyzed security using the chain quality metric, comparing it with other consensus mechanisms like SHTB, PoP, UTB, and UDTB, and found their system outperformed most except PoP. Performance metrics demonstrated a transaction throughput of 119 TPS on average, with latency as low as 1.05 s for 400 transactions and 1.186 s for 800 transactions, showcasing robust scalability. The system&#x2019;s decentralization was validated through features like public accessibility, resilience to various attacks (e.g., 51% and Sybil attacks), and affordable validator node costs ($693). Despite these advancements, the paper acknowledged the need for real-world testing to confirm the model&#x2019;s practicality under diverse conditions. The research work basically relies on theoretical validation and requires extensive real-world implementation to assess its full potential.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-56">56</xref>] introduced a novel blockchain consensus mechanism aimed at resolving the blockchain trilemma by simultaneously achieving security, scalability, and decentralization. The authors proposed an architecture integrating adaptive stake recalibration to dynamically adjust node influence based on historical performance, stake transfers, and economic metrics, alongside epoch-based operations for structured consensus. Cryptographic techniques such as Schnorr Verifiable Random Functions (VRF) ensured secure and unbiased slot leader selection, while zero-knowledge proofs (zk-SNARKs) enhanced transaction privacy and validation efficiency. Scalability was addressed through sharding for parallel transaction processing and Layer-2 rollups for off-chain aggregation, combined with Merkelized Abstract Syntax Trees (MAST) to optimize smart contract execution. Security mechanisms included Practical Byzantine Fault Tolerance (PBFT) for batch agreement, anomaly detection algorithms, and redundancy measures with erasure codes. The system employed a reputation-based stake distribution model to prevent centralization, incentivizing positive behavior through economic rewards and penalties. For evaluation, the authors conducted extensive experiments on a 48-node network, comparing performance against Proof of Work (PoW), Proof of Stake (PoS), Delegated PoS (DPoS), PBFT, and Proof of Authority (PoA). Results demonstrated a throughput of 1700&#x002B; transactions per second (TPS) with latency between 15&#x2013;90 ms, surpassing PoW (7 TPS) and PoA (232 TPS). The system maintained a low average CPU usage of 16.1% compared to PoW (63.2%) and PBFT (24.1%), while achieving a decentralization score of 7.182, competitive with Bitcoin (7.909) and Ethereum (7.656). Security evaluations showed resilience against double-spending attacks (22-min confirmation time at 45% adversarial stake) and negligible fork probability (analyzed via binomial distribution). A limitation of the work is that the scalability and decentralization claims remain theoretical, requiring validation in real-world, large-scale deployments.</p>
</sec>
<sec id="s5_5">
<label>5.5</label>
<title>Network and Protocol Optimizations</title>
<p>Many state-of-the-art works have brought major improvements in network-layer propagation and transaction processing efficiency.</p>
<p>The article authored by Kaiwen Zhang et al. [<xref ref-type="bibr" rid="ref-77">77</xref>] presented a comprehensive exploration of distributed ledger technology (DLT) and blockchain systems, aiming to address the challenges of dependability, scalability, and pervasive adoption. The authors began by highlighting the transformative potential of blockchains across various industries, emphasizing their ability to provide transparency, immutability, and security without centralized control. They identified key pain points hindering widespread adoption, such as trust issues, integration difficulties, and scalability limitations, and proposed a structured research landscape to guide future efforts. The reseach introduced the DCS properties&#x2014;Decentralization, Consistency, and Scalability&#x2014;as a framework analogous to the CAP theorem, illustrating the inherent trade-offs in blockchain design. A taxonomy of blockchain applications was presented, categorizing them into three generations: Blockchain 1.0 (cryptocurrency), 2.0 (decentralized applications or DApps), and 3.0 (pervasive applications like eHealth and supply chain management), each with unique challenges and research directions. The authors further decomposed blockchain platforms into six layers&#x2014;Application, Modeling, Contract, System, Data, and Network&#x2014;providing a detailed reference architecture to analyze and improve blockchain systems. To evaluate performance, the work compared existing platforms like Bitcoin, Ethereum, and Hyperledger, demonstrating how each prioritized different DCS properties; for instance, Bitcoin and Ethereum emphasized Decentralization and Consistency at the cost of Scalability, while Hyperledger achieved higher throughput by sacrificing some decentralization. The final results underscored the need for tailored blockchain solutions, as no single design could satisfy all requirements across applications, and the authors advocated for continued research in areas like consensus algorithms, smart contract security, and interoperability. The value of the work lay in its systematic classification of blockchain research, offering a roadmap for future innovations to enhance dependability, scalability, and adoption. A key limitation of the work is that it does not provide empirical validation of the proposed frameworks or quantify the trade-offs between DCS properties in real-world deployments.</p>
<p>Blockchain systems face critical challenges in scalability and throughput, especially for lightweight nodes like IoT devices that cannot store the full blockchain due to its size. To address this, the authors [<xref ref-type="bibr" rid="ref-63">63</xref>] proposed an innovative solution by designing a high-performance caching system implemented on an FPGA-based network interface controller (NIC) to offload and accelerate blockchain data access. They focused on optimizing the caching mechanism by developing a customized SHA-256 hash core tailored for efficient blockchain operations, which reduced redundant hashing executions and significantly improved performance. To integrate their system with real-world blockchain applications, the authors utilized Jansson and Curl libraries to interface with the Bitcoin core, ensuring seamless communication and data handling. The performance evaluation of their system demonstrated remarkable improvements, with the results showing a 103-fold increase in throughput performance during cache hits, highlighting the efficiency of their design. Additionally, the FPGA implementation offered advantages such as minimal work area utilization, low power consumption, and high performance, making it a practical solution for enhancing blockchain scalability. The authors meticulously evaluated their system by measuring throughput, power consumption, and resource utilization, providing a comprehensive analysis of its capabilities. The success of their approach was evident in the substantial performance gains and the system&#x2019;s ability to handle the workload of lightweight nodes effectively.</p>
<p>Blackchain [<xref ref-type="bibr" rid="ref-64">64</xref>] is a novel blockchain-based system designed to enhance accountability and scalability in Vehicle-to-X (V2X) communication, particularly by addressing the challenges of misbehavior detection and revocation in resource-constrained environments. The authors identified the limitations of traditional Event Data Recorders (EDRs) and centralized Public Key Infrastructures (PKIs), such as high storage costs, lack of tamper-proofing, and centralized trust in misbehavior authorities (MAs). To overcome these issues, they introduced a hierarchical consensus mechanism leveraging distributed ledger technology, where vehicles dynamically formed clusters to agree on local states, which were then propagated to Road-Side Units (RSUs) for further aggregation. These RSUs, organized into smaller groups, performed Byzantine Fault Tolerant (BFT) consensus to validate and forward decisions to MAs, which ultimately published the results on a global, permissionless Blockchain for transparency and public verifiability. The system ensured accountability by allowing all participants to audit revocation decisions and evidence, thereby reducing reliance on a single trusted entity. The authors evaluated the performance of Blackchain by focusing on its ability to handle high message frequencies (10 Hz per vehicle) and churn in VANETs, demonstrating that hierarchical clustering and permissioned blockchains significantly reduced the computational overhead and latency compared to a naive, fully decentralized approach. The results indicated that the proposed system achieved scalable and efficient misbehavior detection and revocation while maintaining privacy through pseudonymous certificates and partial validity periods. The performance was validated through theoretical analysis, highlighting the system&#x2019;s ability to balance transparency, security, and scalability in large-scale vehicular networks. However, the stability of vehicle clusters and the guarantees of hierarchical consensus compared to full consensus remain open challenges.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-61">61</xref>] proposed Matching-Gossip, a novel blockchain broadcast protocol designed to address the network layer bottleneck in the GBT-CHAIN framework by resolving the topological mismatch of traditional Gossip protocols and optimizing performance under the CAP trilemma. The authors introduced two mechanisms: (1) a <italic>direct neighbor node discovery mechanism</italic> that aligned the logical overlay network with the hypercube physical topology by maintaining neighbor lists based on physical proximity (measured via network latency), reducing link duplication, and (2) a <italic>state broadcast mechanism</italic> that utilized UUID-tagged state bits to track message reception, preventing redundant transmissions. They evaluated Matching-Gossip against Gossip in small-scale simulations (4&#x2013;32 nodes on two physical servers) and large-scale real-world experiments (16&#x2013;1024 nodes across global cloud servers), measuring convergence time, network load, and convergence rate. Results showed Matching-Gossip reduced average convergence time by 40% (e.g., from 50 to 30 ms for 32 nodes) and slashed network load by 60%&#x2013;75% (e.g., from 5000 to 2000 packets for 32 nodes, and from 200,000 to 50,000 packets for 1024 nodes). In large-scale tests, convergence rates under a 10-dimensional hypercube topology improved significantly, with Matching-Gossip achieving near-linear scaling. The protocol demonstrated compatibility with hypercube physical topologies, enhancing partition tolerance and reducing redundant traffic. Performance gains were attributed to constrained neighbor selection and state-based message filtering. A limitation of the study is that it does not validate the protocol in networks exceeding 1024 nodes or account for cross-shard transaction complexities in heterogeneous blockchain systems.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-62">62</xref>] addressed the Blockchain Trilemma&#x2014;the challenge of simultaneously achieving security, decentralization, and scalability&#x2014;by introducing a novel <italic>time-beacon</italic> scheme that restructures blockchain architecture into a hierarchical system comprising a Time-Beacon Chain (TBC) and Business Chains (BCs). The authors identified that traditional blockchain security relies on consensus mechanisms where block security depends on the size of block producers, leading to scalability-decentralization trade-offs. Their solution decoupled block security from the Business Chain by anchoring block publication times to a decentralized Time-Beacon Chain, which cryptographically guarantees the temporal authenticity of blocks through Merkle-root-linked timestamp requests. This enabled horizontal scaling of Business Chains without reducing block producer sizes, thereby preserving security and decentralization. The proposed architecture allowed multi-level scaling via Beacon Sub-Chains, exponentially amplifying throughput while maintaining time assurance. To validate the approach, the authors developed <italic>EasyChain</italic>, a prototype integrating Ethereum smart contracts as the TBC and PBFT-based sharded Business Chains. Experiments involved replaying 3 million Ethereum transactions across 9 high-performance nodes, demonstrating near-linear global throughput scaling (300 TPS per shard) with increasing shard count, stable median transaction latency (4 s block intervals), and manageable cross-chain confirmation times (2<italic>t<sub>c</sub></italic> &#x002B; <inline-formula id="ieqn-78"><mml:math id="mml-ieqn-78"><mml:mi>&#x03B1;</mml:mi></mml:math></inline-formula>, where <inline-formula id="ieqn-79"><mml:math id="mml-ieqn-79"><mml:mi>&#x03B1;</mml:mi></mml:math></inline-formula> was optimized to 18 epochs for &#x003C;10% cancellation rates). Performance analysis revealed optimal throughput alignment with shard count and transaction arrival rates, achieving scalability up to 910 sub-chains using Ethereum&#x2019;s smart contract storage. Security analysis showed the time-beacon scheme mitigated 51% attacks, double-spending, and other risks by relying on the TBC&#x2019;s immutability, while decentralization was maintained through lightweight node requirements. A key limitation of the work is that the Time-Beacon Chain&#x2019;s inherent throughput constraints may still pose scalability bottlenecks in long-term deployments despite multi-level hierarchical designs.</p>
</sec>
<sec id="s5_6">
<label>5.6</label>
<title>Cryptographic Enhancements and Privacy</title>
<p>These solutions leverage advanced cryptography to enhance security/scalability trade-offs.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-66">66</xref>] introduced <italic>Bounty 3.0</italic>, a blockchain and Zero-Knowledge Proof (ZKP)-based solution addressing the &#x201D;Bug Bounty Trilemma&#x201D;&#x2014;a challenge balancing security, privacy, and rewards in traditional bug bounty programs. The authors proposed a decentralized architecture leveraging blockchain for immutable, transparent program management and smart contracts for automating reward distribution and validation processes, while zk-SNARKs ensured privacy by allowing security researchers to prove vulnerability ownership without disclosing sensitive details. Key components included a token-based reward system (using stablecoins or ERC20 tokens), a modular smart contract structure (e.g., Program Factory, Bounty Program, and Verifier contracts), and an off-chain database for confidential issue details. The implementation strategy utilized Ethereum Layer 2 solutions with ZK-Rollups to enhance scalability and reduce transaction costs. The authors conducted a comparative analysis between traditional bug bounty platforms (e.g., HackerOne) and Bounty 3.0, highlighting improvements in decentralization, privacy (via wallet-based anonymity), on-chain validation transparency, and tamper-proof reward distribution. Results demonstrated enhanced security through immutable program histories, reduced privacy risks via ZKPs, and flexible tokenized rewards. The evaluation emphasized technical feasibility but lacked empirical performance metrics such as transaction throughput or latency. A limitation of the approach is its reliance on off-chain data storage and the scalability constraints inherent to current ZK-Rollup implementations, which may affect real-world adoption under high-volume conditions.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-67">67</xref>] explored the application of Zero-Knowledge Proofs (ZKPs) to address the blockchain trilemma&#x2014;balancing decentralization, security, and scalability&#x2014;through a multivocal literature review (MLR) encompassing academic and grey literature. The authors systematically analyzed 51 sources (30 academic, 21 grey) by developing search strings, applying inclusion/exclusion criteria, and performing backward/forward searches across databases such as ACM Digital Library, arXiv, and Ethereum community resources. They evaluated the quality of grey literature using predefined criteria and structured findings into three epochs: the genesis of ZKPs (1985&#x2013;2013), early blockchain privacy enhancements (2013&#x2013;2020), and recent scalability solutions (2020&#x2013;2023). The study identified that ZKPs enhance scalability by enabling off-chain computation (e.g., ZK-rollups reducing on-chain verification overhead) and improve security via integrity checks for encrypted transactions, as seen in protocols like Zcash and Ethereum&#x2019;s ZK-EVM. However, ZKPs shifted decentralization challenges to governance layers (e.g., ZK-service providers), creating centralized bottlenecks in rollup implementations. The authors validated their findings through thematic analysis of literature, highlighting SNARKs, STARKs, and Bulletproofs as key ZKP schemes with trade-offs in proof size, setup trust, and efficiency. Performance metrics, such as Ethereum&#x2019;s transition from 15&#x2013;20 transactions per second (TPS) to ZK-rollups enabling <inline-formula id="ieqn-80"><mml:math id="mml-ieqn-80"><mml:mo>&#x223C;</mml:mo></mml:math></inline-formula>2000 TPS, demonstrated scalability gains, while privacy-focused blockchains like Monero and Zcash showcased ZKP-driven confidentiality. The work concluded that ZKPs resolve scalability and security dimensions of the trilemma but necessitate further research on decentralization mechanisms. A limitation of the study is that it does not empirically validate the decentralization trade-offs of ZKP implementations in live blockchain ecosystems.</p>
</sec>
<sec id="s5_7">
<label>5.7</label>
<title>Hybrid and Modular Architectures</title>
<p>These architectures combine multiple approaches through layered or interconnected systems, yielding a comprehensive framework that leverages the strengths of each method.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-48">48</xref>] presented <italic>Trifecta</italic>, a blockchain protocol designed to resolve the Blockchain Trilemma by simultaneously achieving decentralization, security, and scalability. The protocol leveraged three core innovations: (1) <italic>block graph factorization</italic>, which decomposed blockchain functionality into distinct proposer, transaction, and voter blocks to decouple security and scalability; (2) <italic>coded Merkle trees</italic>, enabling horizontal scaling via sharding while ensuring data availability through erasure coding and succinct fraud proofs; and (3) <italic>work virtualization</italic>, a mechanism to mimic Proof-of-Work (PoW) incentives in Proof-of-Stake (PoS) systems to mitigate the nothing-at-stake problem. Built atop the Prism protocol for vertical scaling, Trifecta employed a sharding architecture where nodes self-allocated to shards, maintaining consensus on proposer and voter blocks globally while processing transaction blocks locally. The authors implemented both PoW and PoS versions in Rust and evaluated performance on a 100-node Amazon EC2 testbed with a 4-regular network topology, achieving a throughput of 250,000 transactions per second (tps) and confirmation latencies of 20&#x2013;30 s. Key results demonstrated linear scaling with shard count, constant per-node resource usage (e.g., 50.43% bandwidth for transaction blocks and 49.5% CPU for RocksDB operations), and resilience against adaptive adversaries controlling up to 50% of resources. Comparative analysis showed Trifecta outperformed Algorand and longest-chain protocols in throughput-latency tradeoffs, with latency remaining under one minute even at 40% adversarial power. A limitation of the work is its reliance on idealized network assumptions and the need for further validation under real-world adversarial conditions, such as Sybil attacks or collusion across shards.</p>
<p>Trent McConaghy et al. [<xref ref-type="bibr" rid="ref-68">68</xref>] introduced BigchainDB, a scalable blockchain database designed to bridge the gap between traditional distributed databases and blockchain technologies by combining the high throughput, low latency, and rich querying capabilities of modern distributed databases with the decentralized control, immutability, and digital asset management features of blockchains. The authors highlighted the limitations of traditional blockchains like Bitcoin, such as poor scalability (e.g., low throughput, high latency, and limited capacity), and contrasted these with the performance of distributed databases like Cassandra and RethinkDB, which excel in scalability but lack decentralization and immutability. BigchainDB was built on top of an existing distributed database (initially RethinkDB, with plans to support others like MongoDB), inheriting its scalability while adding blockchain-like characteristics through innovations such as decentralized control via a federation of voting nodes, immutability achieved through cryptographic signing and replication, and support for creating and transferring digital assets. The system architecture involved two primary components: a transaction backlog (S) for unordered transactions and a blockchain (C) for ordered, validated blocks, with the BigchainDB Consensus Algorithm (BCA) coordinating the movement of transactions between these components and enabling voting-based validation. The federation-based consensus model reduces decentralization compared to proof-of-work or proof-of-stake systems. The experimental results demonstrated BigchainDB&#x2019;s ability to achieve high scalability while maintaining blockchain properties. In throughput tests, the system exhibited linear scaling, reaching 1 million writes per second with 32 nodes, where each node contributed approximately 31,250 writes per second. This performance was achieved by distributing writes across shards and leveraging RethinkDB&#x2019;s soft durability mode, which acknowledged writes immediately after memory caching rather than waiting for disk commits. The latency analysis revealed that internal transaction confirmation times depended heavily on node distribution&#x2014;data-center-localized clusters achieved sub-millisecond latencies, while globally distributed nodes experienced higher latencies (<inline-formula id="ieqn-81"><mml:math id="mml-ieqn-81"><mml:mo>&#x2248;</mml:mo></mml:math></inline-formula>1.35 s) due to network propagation delays. Capacity scaling was also linear, with each node adding 48TB of storage, enabling petabyte-scale databases. The system&#x2019;s immutability and tamper-resistance were ensured through cryptographic hashing (SHA3-256) and Ed25519 signatures, while decentralized control was maintained via a federated voting model where nodes reached majority consensus on block validity. Fault tolerance was tested under benign and Byzantine failure scenarios, with the system recovering from node failures by reassigning transactions and revalidating blocks. However, the experiments also highlighted limitations: throughput plateaued at <inline-formula id="ieqn-82"><mml:math id="mml-ieqn-82"><mml:mo>&#x223C;</mml:mo></mml:math></inline-formula>1.5 million writes/sec due to I/O bottlenecks, and global deployments suffered from latency constraints imposed by physical network limits. The results confirmed BigchainDB&#x2019;s suitability for high-volume applications like financial settlements and supply chain tracking, though its federated model introduces trust assumptions compared to permissionless blockchains. The federation-based consensus model reduces decentralization compared to proof-of-work or proof-of-stake systems.</p>
<p>In study [<xref ref-type="bibr" rid="ref-70">70</xref>], authors introduced an interactive multiple blockchain architecture to tackle scalability and interoperability challenges in heterogeneous blockchain systems. The authors developed a hierarchical, modular framework with four layers: the basic layer (handling foundational operations like networking and storage), the blockchain layer (defining data structures, consensus mechanisms, and encryption), the multi-chain communication layer (enabling cross-chain transactions via routing management and protocols), and the application layer (supporting smart contracts and multi-ledger queries). A key innovation was the inter-blockchain connection model, which relied on a decentralized router blockchain to dynamically manage routing information, allowing different blockchains to communicate without a trusted intermediary. Transactions between chains followed a standardized format and were secured using a three-phase commit protocol and escrow transfers to ensure atomicity and consistency. Performance was evaluated through two experiments: the first compared throughput for intra-chain versus mixed (intra- and inter-chain) transactions, showing a decline in TPS from 1520.56 (intra-chain only) to 899.81 (mixed transactions) due to cross-chain coordination overhead. The second experiment tested scalability by increasing the number of parallel chains (shards), revealing that while more chains improved overall throughput, higher proportions of cross-chain transactions reduced efficiency. The results demonstrated that the architecture successfully enhanced scalability, with multi-chain parallelism boosting performance, though at the cost of slower cross-chain operations. Dependency on a router blockchain, which could become a bottleneck in large-scale deployments.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-50">50</xref>] introduced <italic>SymBChainSim</italic>, a modular blockchain simulation tool designed to address the blockchain trilemma (security, decentralization, scalability) by enabling dynamic management and real-time parameter adjustments through a DDDAS (Dynamic Data-Driven Application Systems) framework. The authors structured the simulator into five layers&#x2014;Application, Execution, Data, Consensus, and Network&#x2014;using Python for flexibility, modularity, and integration with machine learning tools. The simulator supported dynamic switching of consensus protocols (e.g., PBFT, BigFoot) and modeled node behaviors (honest, faulty, Byzantine) through event-driven simulations with low-level message exchanges. Evaluations included profiling PBFT and BigFoot under varying node counts (8&#x2013;28 nodes) and faulty nodes (0&#x2013;2), revealing PBFT&#x2019;s robustness (e.g., 28-node runtime: 1,800 s with 0 faults vs. 1200 s with 2 faults) but poor scalability compared to BigFoot&#x2019;s higher throughput (e.g., 28-node runtime: 600 s with 0 faults) but vulnerability to faults (throughput dropping by 30% with 2 faulty nodes). Dynamic consensus switching overhead was measured, showing average idle time increases of 0.5&#x2013;1.5 s during protocol transitions, deemed acceptable given potential latency optimizations. The tool achieved parallelization readiness and real-time parameter updates but faced limitations in scalability for complex protocols (e.g., PBFT&#x2019;s exponential message growth with nodes). A key limitation of the work is the absence of smart contract support and limited pre-implemented consensus protocols, restricting its applicability to broader blockchain use cases.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-69">69</xref>] proposed <italic>SHBF</italic>, a hybrid blockchain framework integrating Honey Badger BFT (HBFT), Proof of Authority (PoA), Stellar Consensus Protocol (SCP), and Practical Byzantine Fault Tolerance (PBFT) to resolve the blockchain trilemma. The framework featured federated voting within quorum slices, redundant overlapping quorums for fault tolerance, time-bound consensus phases, and decentralized trust relationships. Nodes established cryptographic identities using public/private keys, employed threshold encryption for transactions, and engaged in multi-phase consensus (nomination, voting, ballot preparation) to ensure security and scalability. Evaluations on a 50-node network with Intel i5 processors and NVIDIA GPUs demonstrated SHBF&#x2019;s superiority: it achieved a throughput of 1627 TPS (vs. 246&#x2013;278 TPS for PBFT/PoA) and latency of 45 ms (vs. 80&#x2013;100 ms for SCP/HBFT). Security analysis using binomial distribution revealed a low fork probability (10%) and 90.9% protection against double-spending with block confirmation times as low as 7 min (vs. 9&#x2013;16 min for PBFT/HBFT). Decentralization metrics scored 8.094/10, outperforming Bitcoin (6.885) and Ethereum (8.012). However, the framework&#x2019;s reliance on a limited node count during testing and absence of smart contract support restrict its applicability to large-scale, complex blockchain ecosystems.</p>
</sec>
<sec id="s5_8">
<label>5.8</label>
<title>Storage and Data Management</title>
<p>Several innovations in ledger storage and data availability techniques have catalyzed the evolution of distributed systems, leading to enhanced performance, scalability, and security.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-58">58</xref>] proposed an off-chain storage protocol leveraging the InterPlanetary File System (IPFS) and a double-chain technique to address the blockchain trilemma by enhancing scalability without compromising decentralization or security. The authors introduced a dual-ledger system: <italic>raw blocks</italic> containing Content Identifiers (CIDs) of transactions stored off-chain in IPFS, and <italic>hash blocks</italic> (300 bytes each) on-chain, which reference raw blocks via their CIDs, reducing on-chain storage requirements by 3335-fold compared to Bitcoin. Scalability was improved by increasing transactions per block (21,738 transactions per 1 MB raw block, 22<inline-formula id="ieqn-83"><mml:math id="mml-ieqn-83"><mml:mo>&#x00D7;</mml:mo></mml:math></inline-formula> more than Bitcoin) and achieving a throughput of 32&#x2013;63 transactions per second (TPS) in practical tests, with theoretical TPS reaching 7028 for 185 MB blocks. Security was ensured through a hybrid consensus combining proof-of-work with Nakamoto rules, countermeasures against 51% attacks, selfish mining (using delayed block submission penalties), double-spending (via a dynamic address database), and eclipse attacks (via deterministic bucketing and anchor connections). The system was evaluated theoretically, showing 0.206 GB on-chain storage for 736,930 blocks (vs. Bitcoin&#x2019;s 687 GB), and practically using a 10-node IPFS network, achieving 44&#x2013;47 TPS with manual peer connections and 38 TPS via public gateways. Security metrics like chain quality (<inline-formula id="ieqn-84"><mml:math id="mml-ieqn-84"><mml:mi>Q</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>&#x03B1;</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x2265;</mml:mo><mml:mn>0.8</mml:mn></mml:math></inline-formula> for <inline-formula id="ieqn-85"><mml:math id="mml-ieqn-85"><mml:mi>&#x03B1;</mml:mi><mml:mo>&#x2264;</mml:mo><mml:mn>0.3</mml:mn></mml:math></inline-formula>), subversion gain (<inline-formula id="ieqn-86"><mml:math id="mml-ieqn-86"><mml:mo>&#x003C;</mml:mo><mml:mspace width="negativethinmathspace" /><mml:mn>0.3</mml:mn></mml:math></inline-formula> for <inline-formula id="ieqn-87"><mml:math id="mml-ieqn-87"><mml:mi>&#x03B1;</mml:mi><mml:mo>&#x2264;</mml:mo><mml:mn>0.45</mml:mn></mml:math></inline-formula>), and censorship susceptibility (<inline-formula id="ieqn-88"><mml:math id="mml-ieqn-88"><mml:mi>C</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>&#x03B1;</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x003C;</mml:mo><mml:mn>0.4</mml:mn></mml:math></inline-formula>) outperformed Subchains and Fruitchains. Decentralization was validated through low mining node costs ($950) and resistance to Sybil/51% attacks. A limitation of the work is its reliance on theoretical analysis and small-scale testing, leaving large-scale real-world deployment and performance under heterogeneous network conditions unexplored.</p>
<p>In the study [<xref ref-type="bibr" rid="ref-49">49</xref>], authors introduced a novel, secure, and scalable decentralized ledger which is OmniLedger architecture that addressed the critical challenges of scalability, security, and decentralization in blockchain systems by employing sharding techniques. The authors designed OmniLedger to horizontally scale its transaction processing capacity, achieving performance comparable to centralized systems like Visa, while maintaining long-term security under permissionless operation. Key innovations included a bias-resistant public-randomness protocol (RandHound) for statistically representative shard formation, Atomix for atomic cross-shard transactions, and ByzCoinX, an enhanced Byzantine Fault-Tolerant (BFT) consensus protocol optimized for robustness and parallel transaction processing. The system also incorporated state blocks for efficient ledger pruning and a two-tier &#x201D;trust-but-verify&#x201D; validation mechanism to reduce latency for low-value transactions. The authors implemented a prototype in Go and evaluated it on a distributed testbed, demonstrating linear scalability with throughput reaching 6000 transactions per second (tps) for 1800 validators (12.5% malicious) and 2250 tps with a four-second latency under a 25% adversary. The trust-but-verify approach further improved usability, offering sub-second confirmations for low-risk transactions while maintaining security. The results validated OmniLedger&#x2019;s ability to achieve Visa-level throughput (over 4000 tps) with low latency (under two seconds for typical transactions) and minimal storage overhead, making it a significant advancement in decentralized ledger technology. However, the system&#x2019;s epoch transition latency and reliance on synchrony assumptions remain limitations.</p>
<p>Jianwu Zheng et al. introduced DCS Chain [<xref ref-type="bibr" rid="ref-53">53</xref>], a flexible private blockchain system designed to overcome the limitations of the DCS trilemma&#x2014;Decentralization, Consistency, and Scalability&#x2014;by dynamically balancing these three attributes to achieve optimal performance. The authors first defined and quantified the DCS metrics: Decentralization (<inline-formula id="ieqn-89"><mml:math id="mml-ieqn-89"><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>r</mml:mi><mml:mi>a</mml:mi><mml:mi>t</mml:mi><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>) was measured as <inline-formula id="ieqn-90"><mml:math id="mml-ieqn-90"><mml:mn>1</mml:mn><mml:mo>&#x2212;</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mi>n</mml:mi></mml:mfrac></mml:math></inline-formula>, where <inline-formula id="ieqn-91"><mml:math id="mml-ieqn-91"><mml:mi>n</mml:mi></mml:math></inline-formula> is the number of consensus nodes; Consistency (<inline-formula id="ieqn-92"><mml:math id="mml-ieqn-92"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>r</mml:mi><mml:mi>a</mml:mi><mml:mi>t</mml:mi><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>) was inversely proportional to consensus latency, expressed as <inline-formula id="ieqn-93"><mml:math id="mml-ieqn-93"><mml:mfrac><mml:mn>1</mml:mn><mml:msup><mml:mi>e</mml:mi><mml:mrow><mml:mi>t</mml:mi></mml:mrow></mml:msup></mml:mfrac></mml:math></inline-formula>; and Scalability (<inline-formula id="ieqn-94"><mml:math id="mml-ieqn-94"><mml:msub><mml:mi>S</mml:mi><mml:mrow><mml:mi>r</mml:mi><mml:mi>a</mml:mi><mml:mi>t</mml:mi><mml:mi>e</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>) was derived from throughput, formulated as <inline-formula id="ieqn-95"><mml:math id="mml-ieqn-95"><mml:mn>1</mml:mn><mml:mo>&#x2212;</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mrow><mml:mi>lg</mml:mi><mml:mo>&#x2061;</mml:mo><mml:mi>&#x03B8;</mml:mi></mml:mrow></mml:mfrac></mml:math></inline-formula>. These quantifications allowed the system to dynamically adjust performance by optimizing the number of consensus nodes, the choice of consensus protocol (e.g., PBFT, HotStuff, or HotStuff-2), and the batch size of transactions. The system employed a local network simulation to test these adjustments under controlled conditions, enabling the evaluation of performance across different network environments. The results demonstrated that DCS Chain achieved theoretically optimal performance by balancing the DCS metrics, with improvements in throughput, latency, and decentralization depending on the configured parameters. For instance, reducing the number of consensus nodes improved scalability but at the cost of decentralization, while selecting HotStuff-2 over PBFT reduced latency due to its linear communication complexity. The system&#x2019;s modular design also ensured adaptability to various private blockchain applications, providing a comprehensive suite of tools for secure and efficient operations. The performance evaluation highlighted the trade-offs between the DCS dimensions, showcasing the system&#x2019;s ability to tailor its behavior to specific use cases. The system&#x2019;s reliance on local network simulation may not fully capture the complexities of real-world decentralized environments.</p>
</sec>
<sec id="s5_9">
<label>5.9</label>
<title>Theoretical Models and Mathematical Frameworks</title>
<p>Quantitative analyses and formalizations of trilemma trade-offs offer critical insights into the balance among security, scalability, and decentralization, thereby informing more effective design strategies.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-72">72</xref>] mathematically formulated the blockchain trilemma for Proof of Work blockchains by deriving a continuous relationship where the product of decentralization (<italic>D</italic>), scalability (<italic>S</italic>), and security (<italic>R</italic>) remains constant, i.e., <inline-formula id="ieqn-96"><mml:math id="mml-ieqn-96"><mml:mi>S</mml:mi><mml:mo>&#x22C5;</mml:mo><mml:mi>R</mml:mi><mml:mo>&#x22C5;</mml:mo><mml:mi>D</mml:mi><mml:mo>=</mml:mo><mml:mtext>constant</mml:mtext></mml:math></inline-formula>, challenging Vitalik Buterin&#x2019;s original binary interpretation. The authors defined scalability as transactions per second (<inline-formula id="ieqn-97"><mml:math id="mml-ieqn-97"><mml:mtext>TPS</mml:mtext><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>n</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mi>x</mml:mi></mml:mrow></mml:msub><mml:mi>T</mml:mi></mml:mfrac></mml:math></inline-formula>), security as the inverse of the fork rate (<inline-formula id="ieqn-98"><mml:math id="mml-ieqn-98"><mml:mi>R</mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mi>F</mml:mi></mml:mfrac></mml:math></inline-formula>), and decentralization through the quadratic form <inline-formula id="ieqn-99"><mml:math id="mml-ieqn-99"><mml:mi>D</mml:mi><mml:mo>=</mml:mo><mml:msup><mml:mi mathvariant="bold-italic">H</mml:mi><mml:mi mathvariant="normal">&#x22A4;</mml:mi></mml:msup><mml:mi mathvariant="bold-italic">P</mml:mi><mml:mi mathvariant="bold-italic">H</mml:mi></mml:math></inline-formula>, where <inline-formula id="ieqn-100"><mml:math id="mml-ieqn-100"><mml:mi mathvariant="bold-italic">H</mml:mi></mml:math></inline-formula> denotes the hash rate distribution vector and <inline-formula id="ieqn-101"><mml:math id="mml-ieqn-101"><mml:mi mathvariant="bold-italic">P</mml:mi></mml:math></inline-formula> the block propagation time matrix. By connecting the average block propagation time (<inline-formula id="ieqn-102"><mml:math id="mml-ieqn-102"><mml:msub><mml:mi>T</mml:mi><mml:mi>w</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mi>B</mml:mi><mml:msup><mml:mi mathvariant="bold-italic">H</mml:mi><mml:mi mathvariant="normal">&#x22A4;</mml:mi></mml:msup><mml:mi mathvariant="bold-italic">P</mml:mi><mml:mi mathvariant="bold-italic">H</mml:mi></mml:math></inline-formula>, with <inline-formula id="ieqn-103"><mml:math id="mml-ieqn-103"><mml:mi>B</mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mi>B</mml:mi><mml:mi>h</mml:mi></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>B</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mi>x</mml:mi></mml:mrow></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>n</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mi>x</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>) to the fork rate (<inline-formula id="ieqn-104"><mml:math id="mml-ieqn-104"><mml:mi>F</mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:msub><mml:mi>T</mml:mi><mml:mi>w</mml:mi></mml:msub><mml:mi>T</mml:mi></mml:mfrac></mml:math></inline-formula>), they derived the trilemma formula:
<disp-formula id="eqn-23"><label>(23)</label><mml:math id="mml-eqn-23" display="block"><mml:mfrac><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>B</mml:mi><mml:mrow><mml:mi>h</mml:mi></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>B</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mi>x</mml:mi></mml:mrow></mml:msub><mml:mspace width="thinmathspace" /><mml:msub><mml:mi>n</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mi>x</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mi>T</mml:mi></mml:mfrac><mml:mtext>&#x00A0;</mml:mtext><mml:mfrac><mml:mn>1</mml:mn><mml:mi>F</mml:mi></mml:mfrac><mml:mtext>&#x00A0;</mml:mtext><mml:msup><mml:mrow><mml:mtext mathvariant="bold">H</mml:mtext></mml:mrow><mml:mi mathvariant="normal">&#x22A4;</mml:mi></mml:msup><mml:mrow><mml:mtext mathvariant="bold">P</mml:mtext></mml:mrow><mml:mspace width="thinmathspace" /><mml:mrow><mml:mtext mathvariant="bold">H</mml:mtext></mml:mrow><mml:mtext>&#x00A0;</mml:mtext><mml:mo>=</mml:mo><mml:mtext>&#x00A0;</mml:mtext><mml:mn>1</mml:mn></mml:math></disp-formula>demonstrating the inverse relationship among the three properties. They validated the model by proving that <inline-formula id="ieqn-105"><mml:math id="mml-ieqn-105"><mml:msup><mml:mi mathvariant="bold-italic">H</mml:mi><mml:mi mathvariant="normal">&#x22A4;</mml:mi></mml:msup><mml:mi mathvariant="bold-italic">P</mml:mi><mml:mi mathvariant="bold-italic">H</mml:mi></mml:math></inline-formula> correlates with decentralization metrics such as the variance of hash rates (<inline-formula id="ieqn-106"><mml:math id="mml-ieqn-106"><mml:mtext>Var</mml:mtext><mml:mo stretchy="false">[</mml:mo><mml:mi mathvariant="bold-italic">H</mml:mi><mml:mo stretchy="false">]</mml:mo><mml:mo>=</mml:mo><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mi>n</mml:mi></mml:munderover><mml:msubsup><mml:mi>H</mml:mi><mml:mi>i</mml:mi><mml:mn>2</mml:mn></mml:msubsup><mml:mo>&#x2212;</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mi>n</mml:mi></mml:mfrac></mml:math></inline-formula>) and showed that maximally decentralized networks (uniform <inline-formula id="ieqn-107"><mml:math id="mml-ieqn-107"><mml:mi mathvariant="bold-italic">H</mml:mi></mml:math></inline-formula>) maximize<italic>D</italic>, while centralized networks minimize it. The authors compared their quantitative definitions favorably against Buterin&#x2019;s qualitative framework, emphasizing continuous trade-offs rather than binary outcomes. Two performance improvement approaches were proposed: (1) reducing block header (<inline-formula id="ieqn-108"><mml:math id="mml-ieqn-108"><mml:msub><mml:mi>B</mml:mi><mml:mi>h</mml:mi></mml:msub></mml:math></inline-formula>) and transaction (<inline-formula id="ieqn-109"><mml:math id="mml-ieqn-109"><mml:msub><mml:mi>B</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mi>x</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>) sizes (e.g., Compact Block Relay) and (2) optimizing <inline-formula id="ieqn-110"><mml:math id="mml-ieqn-110"><mml:mi mathvariant="bold-italic">P</mml:mi></mml:math></inline-formula> through network enhancements (e.g., lowering propagation times between high-hash-rate nodes). Theoretical validation included referencing Bitcoin&#x2019;s TPS (<inline-formula id="ieqn-111"><mml:math id="mml-ieqn-111"><mml:mrow><mml:mo>&#x223C;</mml:mo></mml:mrow><mml:mn>27</mml:mn></mml:math></inline-formula>) and analyzing variance effects, though no new empirical data were presented. A limitation of the work is that it exclusively addresses Proof of Work blockchains, leaving Proof of Stake systems unexplored.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-73">73</xref>] mathematically formulated the blockchain trilemma for Proof of Work (PoW) blockchains by deriving an equation where the product of decentralization, scalability, and security terms equals a constant. Decentralization was represented through the term <inline-formula id="ieqn-112"><mml:math id="mml-ieqn-112"><mml:msup><mml:mi>H</mml:mi><mml:mi>T</mml:mi></mml:msup><mml:mi>P</mml:mi><mml:mi>H</mml:mi></mml:math></inline-formula>, combining hash rate distribution (<italic>H</italic>) and block propagation time matrix (<italic>P</italic>), scalability as transactions per second (TPS, calculated as <inline-formula id="ieqn-113"><mml:math id="mml-ieqn-113"><mml:mfrac><mml:msub><mml:mi>n</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mi>x</mml:mi></mml:mrow></mml:msub><mml:mi>T</mml:mi></mml:mfrac></mml:math></inline-formula>), and security as the inverse of the fork rate <inline-formula id="ieqn-114"><mml:math id="mml-ieqn-114"><mml:mrow><mml:mo>(</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mi>F</mml:mi></mml:mfrac><mml:mo>)</mml:mo></mml:mrow></mml:math></inline-formula>. The authors validated the formula using theoretical analysis and simulations in the SimBlock environment, testing scenarios with varying block sizes (<inline-formula id="ieqn-115"><mml:math id="mml-ieqn-115"><mml:mi>B</mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mi>B</mml:mi><mml:mi>h</mml:mi></mml:msub><mml:mo>+</mml:mo><mml:msub><mml:mi>B</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mi>x</mml:mi></mml:mrow></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mi>n</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mi>x</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>), average block generation intervals (<inline-formula id="ieqn-116"><mml:math id="mml-ieqn-116"><mml:mi>T</mml:mi><mml:mo>=</mml:mo><mml:mn>300</mml:mn></mml:math></inline-formula>&#x2013;<inline-formula id="ieqn-117"><mml:math id="mml-ieqn-117"><mml:mn>900</mml:mn></mml:math></inline-formula> s), and hash rate distributions modeled via Zipf&#x2019;s law (<inline-formula id="ieqn-118"><mml:math id="mml-ieqn-118"><mml:mi>s</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:math></inline-formula>&#x2013;<inline-formula id="ieqn-119"><mml:math id="mml-ieqn-119"><mml:mn>2.0</mml:mn></mml:math></inline-formula>). Simulations demonstrated that the product of the three terms remained close to 1 across experiments (e.g., <inline-formula id="ieqn-120"><mml:math id="mml-ieqn-120"><mml:mn>1.01</mml:mn><mml:mo>&#x00B1;</mml:mo><mml:mn>0.05</mml:mn></mml:math></inline-formula> for variable <inline-formula id="ieqn-121"><mml:math id="mml-ieqn-121"><mml:msub><mml:mi>n</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mi>x</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>, <inline-formula id="ieqn-122"><mml:math id="mml-ieqn-122"><mml:mn>1.03</mml:mn><mml:mo>&#x00B1;</mml:mo><mml:mn>0.02</mml:mn></mml:math></inline-formula> for variable <italic>T</italic>, and <inline-formula id="ieqn-123"><mml:math id="mml-ieqn-123"><mml:mn>1.00</mml:mn></mml:math></inline-formula>&#x2013;<inline-formula id="ieqn-124"><mml:math id="mml-ieqn-124"><mml:mn>1.05</mml:mn></mml:math></inline-formula> for varying decentralization parameters), confirming the trilemma&#x2019;s validity. The study correlated <inline-formula id="ieqn-125"><mml:math id="mml-ieqn-125"><mml:msup><mml:mi>H</mml:mi><mml:mi>T</mml:mi></mml:msup><mml:mi>P</mml:mi><mml:mi>H</mml:mi></mml:math></inline-formula> with decentralization indices, revealing the Herfindahl&#x2013;Hirschman Index (HHI) as the strongest match (Pearson correlation coefficients up to <inline-formula id="ieqn-126"><mml:math id="mml-ieqn-126"><mml:mo>&#x2212;</mml:mo><mml:mn>0.9096</mml:mn></mml:math></inline-formula>), while the Gini Coefficient and Nakamoto Coefficient exhibited inconsistencies under node count variations. The authors proposed two strategies to enhance trilemma properties under constraints: reducing block header/transaction sizes (e.g., via Compact Block Relay) and optimizing propagation times between nodes. A key limitation of the work is that it assumes no collusion among nodes and excludes real-world complexities such as off-chain transactions or non-PoW consensus mechanisms.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-74">74</xref>] addressed the blockchain scalability trilemma&#x2014;balancing scalability, security, and decentralization&#x2014;by proposing a novel architecture that theoretically scaled transaction throughput linearly with the number of nodes without compromising security or decentralization. The authors introduced a committee-based pipeline architecture comprising <bold>Confirmation Committees (CCs)</bold> and <bold>Root-hash Pipeline Committees (RPCs)</bold>, where CCs validated transactions and RPCs computed state root-hashes via partitioned, pruned Merkle trees. Transactions were processed in a pipelined manner across rounds, with CCs forwarding validated transactions to RPCs responsible for specific address subspaces, ensuring computational and storage workloads were distributed. Cryptographic proofs and truncated block history minimized storage overhead, while inter-committee communication relied on multicast-like message passing. The authors formalized scalability through <bold>Lemma 1</bold>, which derived lower bounds for committee counts (e.g., leaf RPCs <inline-formula id="ieqn-127"><mml:math id="mml-ieqn-127"><mml:mo>&#x2265;</mml:mo><mml:msup><mml:mn>2</mml:mn><mml:mrow><mml:mo fence="false" stretchy="false">&#x2308;</mml:mo><mml:msub><mml:mi>log</mml:mi><mml:mn>2</mml:mn></mml:msub><mml:mo>&#x2061;</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:mi>m</mml:mi><mml:mrow><mml:mo>/</mml:mo></mml:mrow><mml:mi>e</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo fence="false" stretchy="false">&#x2309;</mml:mo></mml:mrow></mml:msup></mml:math></inline-formula>, where <inline-formula id="ieqn-128"><mml:math id="mml-ieqn-128"><mml:mi>m</mml:mi></mml:math></inline-formula> represented balance changes per round and <inline-formula id="ieqn-129"><mml:math id="mml-ieqn-129"><mml:mi>e</mml:mi></mml:math></inline-formula> the per-RPC processing limit), and <bold>Theorem 1</bold>, proving that proportionally increasing nodes and workload preserved system provisioning under uniform address distribution. Theoretical evaluation demonstrated that incremental node additions accommodated higher transaction frequencies while maintaining constant per-node resource usage, with security relying on probabilistic committee rotation and consensus robustness. The work&#x2019;s value lay in its theoretical disproof of the trilemma and its potential to inspire practical implementations. <bold>Limitation</bold>: The analysis remains purely theoretical, lacks empirical validation, and depends on idealized assumptions such as uniform transaction distribution, instantaneous communication, and static node reliability.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-75">75</xref>] proposed a mathematical model to analyze the dual-layer Byzantine fault-tolerant consensus process using sharding to address the blockchain trilemma&#x2014;balancing decentralization, security, and scalability&#x2014;by deriving optimal sharding configurations and demonstrating enhanced performance. The authors modeled the consensus latency time as a sum of Gumbel-distributed broadcast delays across Practical Byzantine Fault Tolerance (PBFT) phases (PRE-PREPARE, PREPARE, COMMIT) using extreme value theory, formulating average throughput as
<disp-formula id="eqn-24"><label>(24)</label><mml:math id="mml-eqn-24" display="block"><mml:mi>E</mml:mi><mml:mrow><mml:mo>[</mml:mo><mml:mstyle displaystyle="false" scriptlevel="0"><mml:mfrac><mml:msub><mml:mi>P</mml:mi><mml:mi>m</mml:mi></mml:msub><mml:msub><mml:mi>T</mml:mi><mml:mi>m</mml:mi></mml:msub></mml:mfrac></mml:mstyle><mml:mo>]</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi>m</mml:mi><mml:mspace width="thinmathspace" /><mml:mi>E</mml:mi><mml:mo stretchy="false">[</mml:mo><mml:mi>P</mml:mi><mml:mo stretchy="false">]</mml:mo></mml:mrow><mml:mrow><mml:mi>&#x03B1;</mml:mi><mml:mspace width="thinmathspace" /><mml:mi>n</mml:mi><mml:mi>log</mml:mi><mml:mo>&#x2061;</mml:mo><mml:mi>n</mml:mi><mml:mo>+</mml:mo><mml:mi>&#x03B2;</mml:mi><mml:mspace width="thinmathspace" /><mml:mi>m</mml:mi><mml:mi>log</mml:mi><mml:mo>&#x2061;</mml:mo><mml:mi>m</mml:mi></mml:mrow></mml:mfrac></mml:math></disp-formula>where <inline-formula id="ieqn-130"><mml:math id="mml-ieqn-130"><mml:mi>&#x03B1;</mml:mi><mml:mo>=</mml:mo><mml:mn>20</mml:mn><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>t</mml:mi></mml:math></inline-formula> and <inline-formula id="ieqn-131"><mml:math id="mml-ieqn-131"><mml:mi>&#x03B2;</mml:mi><mml:mo>=</mml:mo><mml:mn>14</mml:mn><mml:mi mathvariant="normal">&#x0394;</mml:mi><mml:mi>t</mml:mi></mml:math></inline-formula> represented protocol-specific constants, <inline-formula id="ieqn-132"><mml:math id="mml-ieqn-132"><mml:mi>n</mml:mi><mml:mo>=</mml:mo><mml:mi>N</mml:mi><mml:mrow><mml:mo>/</mml:mo></mml:mrow><mml:mi>m</mml:mi></mml:math></inline-formula> was the nodes per shard, and <italic>N</italic> was the total nodes. By solving the transcendental equation:
<disp-formula id="eqn-25"><label>(25)</label><mml:math id="mml-eqn-25" display="block"><mml:mi>m</mml:mi><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mi>&#x03B2;</mml:mi><mml:mspace width="thinmathspace" /><mml:mi>N</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x03B1;</mml:mi><mml:mspace width="thinmathspace" /><mml:mi>n</mml:mi></mml:mrow></mml:mfrac><mml:mo>+</mml:mo><mml:mfrac><mml:mi>&#x03B1;</mml:mi><mml:mi>&#x03B2;</mml:mi></mml:mfrac><mml:mspace width="thinmathspace" /><mml:mi>n</mml:mi><mml:mspace width="thinmathspace" /><mml:mi>log</mml:mi><mml:mo>&#x2061;</mml:mo><mml:mi>m</mml:mi></mml:math></disp-formula>they determined the optimal shard count <inline-formula id="ieqn-133"><mml:math id="mml-ieqn-133"><mml:mi>m</mml:mi></mml:math></inline-formula>, showing that for <inline-formula id="ieqn-134"><mml:math id="mml-ieqn-134"><mml:mi>N</mml:mi><mml:mo>=</mml:mo><mml:mn>1000</mml:mn></mml:math></inline-formula>, <inline-formula id="ieqn-135"><mml:math id="mml-ieqn-135"><mml:mi>m</mml:mi><mml:mo>=</mml:mo><mml:mn>67</mml:mn></mml:math></inline-formula> (with <inline-formula id="ieqn-136"><mml:math id="mml-ieqn-136"><mml:mi>n</mml:mi><mml:mo>=</mml:mo><mml:mn>15</mml:mn></mml:math></inline-formula>) maximized throughput by <inline-formula id="ieqn-137"><mml:math id="mml-ieqn-137"><mml:mn>747</mml:mn><mml:mo>&#x00D7;</mml:mo></mml:math></inline-formula> compared to non-sharded systems.</p>
<p>The analysis revealed that decentralization (<italic>N</italic>) and security (<inline-formula id="ieqn-138"><mml:math id="mml-ieqn-138"><mml:mi>f</mml:mi></mml:math></inline-formula>, Byzantine nodes tolerated per shard) scaled proportionally with <inline-formula id="ieqn-139"><mml:math id="mml-ieqn-139"><mml:mi>m</mml:mi></mml:math></inline-formula>, breaking the trilemma trade-off. The authors validated their model against simulations of S-PBFT and ShardEval, observing qualitative agreement in throughput trends: semi-logarithmic plots of throughput vs. <inline-formula id="ieqn-140"><mml:math id="mml-ieqn-140"><mml:mi>n</mml:mi></mml:math></inline-formula> at fixed <inline-formula id="ieqn-141"><mml:math id="mml-ieqn-141"><mml:mi>m</mml:mi><mml:mo>=</mml:mo><mml:mn>5</mml:mn></mml:math></inline-formula> matched theoretical predictions of linear decay, and ShardEval simulations for <inline-formula id="ieqn-142"><mml:math id="mml-ieqn-142"><mml:mi>N</mml:mi><mml:mo>=</mml:mo><mml:mn>100</mml:mn><mml:mo>,</mml:mo><mml:mn>500</mml:mn><mml:mo>,</mml:mo><mml:mn>1000</mml:mn></mml:math></inline-formula> confirmed peak throughput near derived <inline-formula id="ieqn-143"><mml:math id="mml-ieqn-143"><mml:mi>m</mml:mi></mml:math></inline-formula> values. Performance metrics included a throughput gain of <inline-formula id="ieqn-144"><mml:math id="mml-ieqn-144"><mml:msub><mml:mi>R</mml:mi><mml:mi>m</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mn>747</mml:mn></mml:math></inline-formula> for <inline-formula id="ieqn-145"><mml:math id="mml-ieqn-145"><mml:mi>N</mml:mi><mml:mo>=</mml:mo><mml:mn>1000</mml:mn></mml:math></inline-formula>, with scalability (<inline-formula id="ieqn-146"><mml:math id="mml-ieqn-146"><mml:mi>m</mml:mi></mml:math></inline-formula>) increasing alongside <italic>N</italic>, demonstrating <inline-formula id="ieqn-147"><mml:math id="mml-ieqn-147"><mml:msub><mml:mi>R</mml:mi><mml:mi>m</mml:mi></mml:msub><mml:mo>&#x221D;</mml:mo><mml:msup><mml:mi>m</mml:mi><mml:mn>2</mml:mn></mml:msup></mml:math></inline-formula> for small <inline-formula id="ieqn-148"><mml:math id="mml-ieqn-148"><mml:mi>m</mml:mi></mml:math></inline-formula>. However, simulations deviated from theory at high <inline-formula id="ieqn-149"><mml:math id="mml-ieqn-149"><mml:mi>m</mml:mi></mml:math></inline-formula>, showing no throughput decay due to unmodeled overhead effects. A limitation of the study is that it does not empirically validate decentralization-security-scalability trade-offs in real-world sharded blockchains or fully account for cross-shard transaction impacts.</p>
</sec>
<sec id="s5_10">
<label>5.10</label>
<title>Analytical Frameworks and Comparative Studies</title>
<p>Systematic evaluations of existing platforms and solutions reveal key insights into their strengths and limitations, thereby informing the development of more robust and efficient systems.</p>
<p>In [<xref ref-type="bibr" rid="ref-59">59</xref>], the authors conducted an in-depth analysis of three leading blockchain technologies&#x2014;Ethereum, Solana, and Avalanche&#x2014;focusing on their ability to balance the Blockchain Trilemma&#x2019;s core properties: decentralization, security, and scalability. The study began with a theoretical exploration of Bitcoin&#x2019;s foundational processes to establish a baseline understanding of blockchain mechanics, followed by detailed technical comparisons of Ethereum, Solana, and Avalanche, highlighting their unique consensus mechanisms (e.g., Ethereum&#x2019;s shift to Proof of Stake, Solana&#x2019;s Proof of History, and Avalanche&#x2019;s Directed Acyclic Graph structure) and their implications for the trilemma. The authors then performed a quantitative analysis using key metrics such as the Nakamoto Coefficient (Ethereum: 379,886, Solana: 30, Avalanche: 0), Token Distribution Entropy (Ethereum: 19.5, Solana: 8.88, Avalanche: 0), Number of Validators (Ethereum: 746,265, Solana: 1964, Avalanche: 1354), Transactions Per Second (Ethereum: 29.33, Solana: 4501, Avalanche: 179), and Time to Finality (Ethereum: 180 s, Solana: 0.4 s, Avalanche: 2 s), alongside qualitative assessments of downtime (Ethereum: none, Solana: 10 instances, Avalanche: none). To facilitate real-time monitoring, the authors developed a dynamic dashboard using Python, incorporating Selenium for web scraping and Streamlit for visualization, which compiled historical and live data into interactive radar plots, aggregated tables, and time-series graphs. The study concluded that Ethereum excelled in decentralization and security but lagged in scalability, Solana prioritized scalability at the cost of decentralization and security, and Avalanche uniquely balanced all three trilemma properties through its Primary Network and subnet architecture, positioning it as the most promising blockchain for future adoption. A key limitation of the work is its reliance on real-time data sources, which may introduce variability in metric accuracy over time.</p>
<p>Soonduck Yoo [<xref ref-type="bibr" rid="ref-78">78</xref>] provides a comprehensive review of proposed solutions to the blockchain trilemma, which involves balancing the three critical elements of blockchain systems: scalability, decentralization, and security. The study systematically categorized existing approaches into three models: compromising decentralization (e.g., Algorand and EOS, which improve transaction speed by partially centralizing the network but weaken security), compromising scalability (e.g., Bitcoin and Ethereum, which prioritize decentralization and security at the cost of slower transaction speeds), and compromising security (e.g., Ethereum 2.0 and Layer 2 solutions like Rollups and Sidechains, which enhance scalability but introduce security vulnerabilities). The authors employed a case study analysis methodology, examining Limited Validator Solutions (such as EOS&#x2019;s Delegated Proof of Stake and Algorand&#x2019;s Pure Proof of Stake), Layer 1 solutions (like sharding in Ethereum 2.0 and Bitcoin Cash&#x2019;s larger block sizes), and Layer 2 solutions (including Rollups, Sidechains, and Plasma Chains) to evaluate their effectiveness in addressing the trilemma. The performance of these solutions was assessed based on transaction processing speed, security robustness, and decentralization levels, with specific metrics such as Bitcoin&#x2019;s 7 transactions per second (TPS) compared to Ethereum&#x2019;s 15 TPS, and Ethereum 2.0&#x2019;s faster block creation time of 15 s versus Bitcoin&#x2019;s 10 min. The results highlighted that no existing solution could simultaneously maximize all three elements, with each model presenting trade-offs: Algorand&#x2019;s random validator selection offered better security than EOS&#x2019;s designated selectors, while Ethereum&#x2019;s flexibility and smart contract support provided superior scalability over Bitcoin. The study concluded that future blockchain systems would likely adopt modular structures, distributing tasks across layers to optimize performance, and emphasized the need for continued research to overcome the trilemma. The study lacks empirical validation, overgeneralizes trade-offs, and does not account for recent advancements in blockchain technology, limiting its relevance in the current landscape.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-60">60</xref>] presented an evaluation framework for third-generation blockchain technologies&#x2014;Layer 1 (L1) solutions, Layer 2 (L2) rollups, and sidechains&#x2014;based on the blockchain trilemma of scalability, decentralization, and security. The authors selected five platforms (Cardano, Solana, Arbitrum, zkSync, and Polygon) and evaluated them using quantitative metrics: transactions per second (TPS) for scalability, the Nakamoto Coefficient for decentralization, and a security cost metric (USD required to control 33% or 51% of the network). Scalability was assessed through theoretical TPS calculations (e.g., Solana: 710 k theoretical TPS derived from network capacity) and historical peak TPS from blockchain explorers (e.g., Solana: 1763 TPS, Polygon: 101.97 TPS). Decentralization was measured via the Nakamoto Coefficient, calculated from stake distributions (L1/sidechains) or aggregator nodes (L2), revealing significant centralization in zkSync (Nakamoto Coefficient &#x003D; 1) and Polygon (Nakamoto Coefficient &#x003D; 2), while Arbitrum achieved higher decentralization (Nakamoto Coefficient &#x003D; 2515) when considering user-operated sequencers. Security was evaluated using token prices and staking data, with zkSync and Arbitrum inheriting Ethereum&#x2019;s security (cost: $20.6 billion), while Solana and Cardano showed lower attack costs ($9.11 billion and $0.528 billion, respectively). Results highlighted tradeoffs: Solana prioritized scalability (1763 TPS) over decentralization (Nakamoto Coefficient &#x003D; 18), while Arbitrum emphasized decentralization at the expense of scalability (3.09 TPS). The framework exposed limitations in existing platforms, such as zkSync&#x2019;s extreme centralization and Polygon&#x2019;s modest decentralization despite higher TPS. A key limitation of the work is that the TPS metric remains sensitive to network adoption and popularity, potentially skewing real-world scalability assessments.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-79">79</xref>] conducted a comparative analysis of Algorand and Ethereum 2.0 to address the blockchain trilemma&#x2014;balancing decentralization, security, and scalability&#x2014;by evaluating real-world on-chain data from January 2019 to September 2023 for Algorand (via BitQuery) and June 2019 to September 2023 for Ethereum 2.0 (via Beacon Explorer). The authors employed a structured methodology to measure decentralization at consensus and transaction layers using four indices: <bold>Shannon Entropy</bold> (randomness), <bold>Gini Coefficient</bold> (inequality), <bold>Nakamoto Coefficient</bold> (minimum entities controlling 51%), and <bold>Herfindahl-Hirschman Index</bold> (market concentration). For scalability, they analyzed transaction throughput (transactions per second) and latency (block confirmation time), while security was assessed through burned fees (daily transaction costs) and theoretical vulnerability analyses, including defenses against 51% attacks. Results revealed that <bold>Algorand exhibited higher decentralization in the consensus layer</bold> (Shannon Entropy: 1364.34 vs. Ethereum 2.0&#x2019;s 866.76; Nakamoto Coefficient: 821 vs. 705) due to its open participation model, while <bold>Ethereum 2.0 showed greater decentralization in the transaction layer</bold> (Shannon Entropy: 2252.60 vs. Algorand&#x2019;s 920.19) attributed to its longer operational history. In scalability, <bold>Algorand outperformed Ethereum 2.0</bold> with a peak transaction volume surpassing Ethereum&#x2019;s under stress and a significantly lower average block time (3.5 vs. 14.42 s). Security analysis indicated <bold>Ethereum 2.0&#x2019;s higher burned fees</bold> (4690.36 daily average vs. Algorand&#x2019;s 3401.82), suggesting stronger economic incentives for honest participation, though both platforms demonstrated robust theoretical defenses against 51% attacks via randomization mechanisms (Algorand&#x2019;s VRF and Ethereum&#x2019;s RANDAO). The study also proposed integrating federated analytics with blockchain to enhance privacy and scalability through distributed subnet analysis. While the work provided a comprehensive framework for blockchain evaluation, <bold>a key limitation is the reliance on theoretical security assessments without empirical validation of attack scenarios or real-world stress testing</bold>, and the assumption of uniform transaction distribution. Data and code were made openly available on GitHub to support reproducibility.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-81">81</xref>] provided a comprehensive review of the blockchain trilemma, which highlights the inherent challenge of simultaneously achieving decentralization, security, and scalability in blockchain systems, and synthesized recent advancements aimed at addressing these trade-offs. The authors systematically categorized existing solutions into eight key areas&#x2014;sharding techniques, layer-2 protocols, consensus mechanism innovations, network optimizations, cryptographic enhancements, hybrid architectures, storage and data management, and theoretical models&#x2014;and critically analyzed their trade-offs and practical implications. They employed the PRISMA framework to rigorously select and review 38 distinct approaches from peer-reviewed articles, technical reports, and conference papers published between 2016 and 2024, ensuring a holistic integration of trilemma dimensions. The review highlighted breakthroughs such as Directed Acyclic Graph (DAG)-based structures, zero-knowledge proof optimizations, and modular blockchain designs, while also benchmarking performance metrics like throughput (e.g., RapidChain achieving 7300 TPS with sub-second latency) and decentralization (e.g., Nakamoto Coefficient <inline-formula id="ieqn-150"><mml:math id="mml-ieqn-150"><mml:mo>&#x2265;</mml:mo><mml:mn>100</mml:mn></mml:math></inline-formula> in proposed frameworks). The authors proposed a multi-faceted architecture combining hierarchical sharding, adaptive consensus mechanisms, and zero-knowledge proofs to reconcile the trilemma, projecting scalability improvements (50,000&#x2013;100,000 TPS) and security enhancements (33% Byzantine tolerance) while maintaining decentralization. They evaluated these solutions through comparative analyses, simulations, and real-world case studies, such as Ethereum&#x2019;s post-Merge performance and Solana&#x2019;s validator centralization risks, and identified gaps in current methodologies, suggesting future research directions like AI-driven governance and quantum-resistant cryptography. The paper&#x2019;s value lay in its systematic taxonomy, interdisciplinary approach, and empirical validation of theoretical breakthroughs, though it acknowledged that no universal solution exists and trade-offs remain inevitable. A key limitation of the work is its reliance on theoretical projections and simulations for some proposed solutions, lacking large-scale real-world validation under adversarial conditions.</p>
</sec>
<sec id="s5_11">
<label>5.11</label>
<title>Security Analyses and Protocol Vulnerabilities</title>
<p>Investigations of attack vectors and mitigation strategies provide a deeper understanding of system vulnerabilities and guide the development of more secure and resilient architectures.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-82">82</xref>] conducted a security analysis of the Algorand blockchain protocol, focusing on a potential vulnerability in its message validation process that could be exploited to launch a Distributed Denial-of-Service (DDoS) attack. The authors identified that undecidable messages&#x2014;messages requiring stateful checks dependent on consensus from prior rounds&#x2014;could be maliciously flooded to honest nodes, overwhelming their bandwidth and memory resources, thereby delaying their participation in the Byzantine Agreement (BA) protocol. To demonstrate this, they designed an attack scenario where malicious nodes exploited Algorand&#x2019;s Sybil-prone peer selection and cryptographic sortition mechanism to send numerous block proposals with forged credentials for future rounds, which honest nodes could not immediately validate. Since Algorand&#x2019;s official implementation was unavailable, the authors developed a Java-based simulator replicating the protocol&#x2019;s consensus mechanism, network communication, and validation processes. They evaluated the attack under varying configurations, including different numbers of malicious nodes (up to 70 keys per node), block sizes (up to 1 MB), and network settings (500 nodes with 30 Mbps bandwidth). Key performance metrics included average round time and the percentage of legitimate messages processed. Results showed that even a moderate attack (e.g., 10 malicious nodes sending 50 block proposals each) increased the average round time to over 390 s (vs. baseline 150 s) due to step timeouts, while legitimate message validation rates dropped sharply, with only 4%&#x007E;0% of messages processed in high-intensity attacks. Larger payload sizes exacerbated these effects, highlighting the attack&#x2019;s scalability. The authors concluded that the attack was cost-effective for adversaries but noted that success depended on establishing sufficient malicious connections to targets. A limitation of the work is that the findings are based on simulated conditions, and real-world network dynamics or protocol updates might alter the attack&#x2019;s feasibility. The analysis assumes idealized network conditions and does not account for potential real-world countermeasures or protocol optimizations.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-83">83</xref>] addressed the Blockchain Trilemma by reviewing security challenges and consensus mechanisms, proposing a theoretical <italic>Proof of Parity</italic> mechanism to balance decentralization, security, and scalability. The authors analyzed blockchain security concerns such as 51% attacks, Sybil attacks, and smart contract vulnerabilities (e.g., reentrancy, integer overflow), categorizing risks in public and permissioned blockchains like Hyperledger Fabric. They evaluated existing consensus algorithms (PoW, PoS, Proof of Authority, etc.) against the trilemma, highlighting trade-offs in scalability and decentralization through comparative tables. The proposed solution introduced a hybrid architecture with <italic>staking</italic> and <italic>non-staking</italic> nodes, combining a main chain with micro-chains to offload transactions and reduce latency. This mechanism leveraged Practical Byzantine Fault Tolerance (PBFT) as a Layer-2 protocol to theoretically achieve commercial-grade throughput (4500&#x2013;5000 TPS) while maintaining security and decentralization. The authors discussed mitigation strategies for attacks, including quantum-resistant algorithms and protocol adjustments (e.g., block size limits), and analyzed smart contract vulnerabilities with preventive measures like SafeMath libraries. However, the evaluation remained largely theoretical, with no empirical implementation or performance metrics provided for the proposed consensus mechanism. A key limitation is the absence of experimental validation or real-world testing to substantiate the scalability and security claims of the proposed architecture.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-80">80</xref>] provided a comprehensive review of the challenges and proposed solutions related to blockchain mutability, particularly in the context of the GDPR&#x2019;s Right to be Forgotten (RtbF) requirement. The authors began by highlighting the inherent immutability of blockchain technology, which ensures data integrity and security but conflicts with the RtbF&#x2019;s demand for data erasure. They explored the decentralized architecture of blockchains, distinguishing between permissioned and permissionless blockchains, and discussed consensus protocols like Proof of Work (PoW) and Proof of Stake (PoS) that underpin blockchain security. The paper then delved into the collision between blockchain immutability and the RtbF, emphasizing the legal and technical incompatibilities arising from the GDPR&#x2019;s requirements. To address this, the authors reviewed two main categories of solutions: bypassing immutability through off-chain storage, encryption, and pruning, and removing immutability using advanced cryptographic techniques like chameleon hashes, meta-transactions, and consensus-based voting. They evaluated these methods by analyzing their feasibility, security implications, and compliance with GDPR, noting that off-chain storage and encryption reduced scalability and introduced security risks, while cryptographic solutions like chameleon hashes and mutable transactions offered more flexibility but were often limited to permissioned blockchains or required significant computational overhead. The authors also discussed practical implementations, such as Accenture&#x2019;s prototype for permissioned environments, and highlighted the trade-offs between mutability and decentralization. Performance metrics, such as the computational cost of chameleon hashes and the overhead of secret-sharing schemes, were mentioned to underscore the challenges of these solutions. The paper concluded that while some techniques showed promise, achieving full compliance with the RtbF without compromising blockchain&#x2019;s core principles remained an open problem. The limitation of the work is that many proposed solutions still rely on centralized elements or introduce significant performance overhead, which undermines the decentralized nature of blockchain.</p>
</sec>
<sec id="s5_12">
<label>5.12</label>
<title>Limitations of Current Solutions</title>
<p>Existing approaches to resolving the blockchain trilemma exhibit several recurring limitations that constrain their practical adoption:
<list list-type="bullet">
<list-item>
<p><bold>Trusted Execution Environment (TEE) Dependency:</bold> Solutions like FastBFT [<xref ref-type="bibr" rid="ref-88">88</xref>] and TEE-Sharding [<xref ref-type="bibr" rid="ref-44">44</xref>] rely on specialized hardware (e.g., Intel SGX), creating vulnerabilities to side-channel attacks and restricting deployment in environments lacking secure enclaves.</p></list-item>
<list-item>
<p><bold>Cross-Shard Coordination Overhead:</bold> Sharding implementations such as ELASTICO [<xref ref-type="bibr" rid="ref-89">89</xref>] and RapidChain [<xref ref-type="bibr" rid="ref-45">45</xref>] introduce latency from inter-shard communication, with fraud proof mechanisms adding verification delays.</p></list-item>
<list-item>
<p><bold>Consensus Centralization Risks:</bold> Proof-of-Stake variants (e.g., Ethereum 2.0) and delegated protocols exhibit stake concentration, as evidenced by post-Merge Ethereum&#x2019;s 31% staking dominance by 5 entities [<xref ref-type="bibr" rid="ref-22">22</xref>].</p></list-item>
<list-item>
<p><bold>Governance Bottlenecks:</bold> Layer-2 solutions like zk-Rollups depend on centralized sequencers or provers, while DAO-based governance models suffer from voter apathy and proposal gridlock.</p></list-item>
</list></p>
<p>These limitations underscore the need for adaptive architectures that mitigate trade-offs through hybrid mechanisms (<xref ref-type="sec" rid="s6">Section 6</xref>).</p>
</sec>
<sec id="s5_13">
<label>5.13</label>
<title>Application-Specific Implementations</title>
<p>Tailored solutions for domain-specific use cases enable optimized performance and relevance by addressing the unique requirements and constraints of each application area.</p>
<p>The paper [<xref ref-type="bibr" rid="ref-84">84</xref>] proposed a blockchain-based scalability solution for peer-to-peer (P2P) energy trading in microgrids, addressing the blockchain trilemma of scalability, security, and decentralization through a two-layer architecture comprising a main blockchain layer and a second scalability layer for off-chain transactions. The authors developed a private blockchain network using Hyperledger Fabric, integrating smart contracts to automate payment calculations and transaction validation while employing sidechains to process high-frequency transactions off-chain, thereby reducing congestion on the main network. The methodology incorporated home miners (prosumers with renewable energy sources), smart meters for real-time data tracking, storage devices for surplus energy, and an energy blockchain for secure transaction recording. A case study was conducted using energy consumption and production data from the Education City Community Housing (ECCH) compound in Qatar, involving 623 households, to evaluate transaction volumes and costs under 5-min and 30-min settlement periods. The results demonstrated that the two-layer solution reduced transaction costs by 95%&#x2013;98% compared to base-layer models, with daily transactions ranging from 40&#x2013;460 (30-min settlements) to 260&#x2013;1780 (5-min settlements), achieving scalability without compromising security or decentralization. The framework utilized a commitment bond mechanism and fraud-proof penalties to ensure off-chain transaction integrity, while smart contracts dynamically adjusted energy prices based on supply-demand ratios. Performance metrics revealed an average daily cost of $0.02&#x2013;$0.073 per kWh during peak periods, with maximum total costs reduced from $140,000 (base layer) to $7000 (two-layer solution) for 50 properties over two months. The authors validated the model through empirical simulations, highlighting its applicability in renewable energy markets and cost efficiency. A limitation of the work is that the proposed two-layer architecture introduces complexities in maintaining decentralization and security across sidechains, and its real-world scalability depends on overcoming regulatory and economic barriers for widespread adoption.</p>
<p>In ref. [<xref ref-type="bibr" rid="ref-71">71</xref>], the paper explored the integration of federated learning (FL) and blockchain technology to address the challenges of decentralized data sharing in healthcare, aiming to balance data utility with privacy preservation. The authors proposed a novel framework where FL enabled collaborative model training across multiple healthcare institutions without sharing raw patient data, thus ensuring privacy, while blockchain provided a secure, transparent, and immutable ledger to maintain data integrity and trust. The framework was designed to empower patients by allowing them to retain control over their data while facilitating secure access for researchers and healthcare providers, thereby improving diagnostic accuracy and accelerating medical research. The authors detailed the technical foundations of FL and blockchain, emphasizing their synergistic benefits, such as enhanced security through encryption and hashing, improved interoperability, and resilience against attacks like replay and man-in-the-middle attempts. To validate their approach, they simulated a healthcare use case involving hospitals sharing an Iris data set, where data attributes were encrypted using public-key cryptography and stored on a blockchain, with transactions verified through consensus mechanisms like Proof of Work (PoW). The evaluation demonstrated robust defense mechanisms against adversarial attacks, with replay attacks showing a consistently low success rate due to nonce and hash verification, identity masquerade attacks being thwarted by RSA-based digital signatures and IP checks, and man-in-the-middle attacks mitigated by end-to-end encryption, though the latter exhibited a slightly higher but still low success rate. The performance metrics highlighted the system&#x2019;s effectiveness, with the PoW complexity being exponential relative to the difficulty target, and the authorization check operating efficiently with a worst-case time complexity of O(n). The results underscored the framework&#x2019;s potential to revolutionize healthcare data sharing by ensuring privacy, security, and transparency while enabling collaborative advancements in medical research. A key limitation of the work is its reliance on simulated attacks and a simplified data set, which may not fully capture the complexities of real-world healthcare environments.</p>
<p><bold>Key Observations:</bold> <xref ref-type="table" rid="table-6">Table 6</xref> reveals inherent trade-offs-high-throughput solutions (Solana, zkSync) achieve scalability through reduced decentralization (node counts <inline-formula id="ieqn-153"><mml:math id="mml-ieqn-153"><mml:mo>&#x2264;</mml:mo></mml:math></inline-formula>5000), while decentralized networks (Bitcoin, Lightning) prioritize security at the expense of throughput. Emerging solutions like Ethereum 2.0 sharding attempt to balance all three aspects through architectural innovations, though at increased implementation complexity. Energy metrics demonstrate the paradigm shift from PoW (Bitcoin&#x2019;s 707 kWh/tx) to modern systems achieving sub-0.01 kWh/tx efficiency.</p>
<table-wrap id="table-6">
<label>Table 6</label>
<caption>
<title>Performance metrics of major blockchain scaling solutions</title>
</caption>
<table>
<colgroup>
<col/>
<col/>
<col/>
<col/>
<col/>
<col/>
<col/>
</colgroup>
<thead>
<tr>
<th>Solution</th>
<th>Max TPS</th>
<th>Finality time</th>
<th>Nodes</th>
<th align="center">Security model</th>
<th align="center">Energy efficiency</th>
<th align="center">Trilemma focus</th>
</tr>
</thead>
<tbody>
<tr>
<td>Bitcoin (Base)</td>
<td>7</td>
<td>60 min</td>
<td>15,000</td>
<td>PoW ($5B attack cost)</td>
<td>707 kWh/tx</td>
<td>Security &#x002B; Decentralization</td>
</tr>
<tr>
<td>Ethereum L1</td>
<td>30</td>
<td>12 s</td>
<td>5600</td>
<td>PoS ($20B slashable ETH)</td>
<td>0.03 kWh/tx</td>
<td>Security &#x002B; Decentralization</td>
</tr>
<tr>
<td>Solana</td>
<td>50,000</td>
<td>400 ms</td>
<td>1900</td>
<td>PoH&#x002B;PoS ($40M attack cost)</td>
<td>0.001 kWh/tx</td>
<td>Scalability &#x002B; Security</td>
</tr>
<tr>
<td>Polygon PoS</td>
<td>7000</td>
<td>2 s</td>
<td>100</td>
<td>Plasma &#x002B; Checkpoints</td>
<td>0.02 kWh/tx</td>
<td>Scalability &#x002B; Cost Efficiency</td>
</tr>
<tr>
<td>Lightning Network</td>
<td>1M&#x002A;</td>
<td>Instant</td>
<td>18,000</td>
<td>HTLC Collateral</td>
<td>N/A</td>
<td>Scalability &#x002B; Privacy</td>
</tr>
<tr>
<td>zkSync Era</td>
<td>2000</td>
<td>10 min</td>
<td>5</td>
<td>zk-SNARK Validity Proofs</td>
<td>0.005 kWh/tx</td>
<td>Scalability &#x002B; Security</td>
</tr>
<tr>
<td>Ethereum 2.0 Sharding</td>
<td>100,000<inline-formula id="ieqn-151"><mml:math id="mml-ieqn-151"><mml:mo>&#x2020;</mml:mo></mml:math></inline-formula></td>
<td>12 s</td>
<td>200/shard</td>
<td>BLS Threshold Sig</td>
<td>0.04 kWh/tx</td>
<td>Balanced Trilemma</td>
</tr>
<tr>
<td>IOTA DAG</td>
<td>1000</td>
<td>10 s</td>
<td>350</td>
<td>Coordinator Node</td>
<td>0.0001 kWh/tx</td>
<td>Scalability &#x002B; IoT Focus</td>
</tr>
</tbody>
</table>
<table-wrap-foot>
<fn fn-type="other" id="fn1">
<p><bold>Notes:</bold> &#x002A;Theoretical channel capacity; <inline-formula id="ieqn-152"><mml:math id="mml-ieqn-152"><mml:mrow><mml:mo>&#x2020;</mml:mo></mml:mrow></mml:math></inline-formula>Post-full sharding implementation. Energy estimates based on 2024 Digiconomist indices. Security costs calculated as minimum capital required to compromise network integrity (51% attack for PoW/PoS, 33% for BFT). Finality times reflect average network conditions.</p>
</fn>
</table-wrap-foot>
</table-wrap>
</sec>
</sec>
<sec id="s6">
<label>6</label>
<title>Comparative Study and Discussion</title>
<p>The blockchain trilemma&#x2014;balancing decentralization, security, and scalability&#x2014;remains a persistent challenge in distributed ledger technology. Drawing insights from the reviewed literature, we propose a multi-faceted architecture that integrates hierarchical sharding, adaptive consensus mechanisms, and zero-knowledge proofs (ZKPs) to reconcile these competing priorities. Our solution emphasizes modularity, dynamic resource allocation, and cryptographic innovations to optimize performance without compromising core blockchain principles.</p>
<sec id="s6_1">
<label>6.1</label>
<title>Hierarchical Sharding with Cross-Chain Optimizations</title>
<sec id="s6_1_1">
<label>6.1.1</label>
<title>Dynamic Shard Formation</title>
<p>Building on protocols like OmniLedger and RapidChain, we propose a hierarchical sharding framework where the network is partitioned into <italic>primary shards</italic> and <italic>sub-shards</italic>. Primary shards handle global consensus and cross-shard coordination, while sub-shards process localized transactions. Shard formation leverages a decentralized randomness beacon (e.g., RandHound) to ensure unbiased node assignment, mitigating Sybil attacks. Nodes are dynamically reassigned to shards based on real-time workload metrics (e.g., transaction volume, latency), enabling elastic scaling.</p>
<p>The proposed hierarchical sharding framework (see <xref ref-type="fig" rid="fig-7">Fig. 7</xref>) integrates cross-chain optimizations through dynamic node reassignment and workload-driven scaling, ensuring Sybil resistance and adaptive resource allocation.</p>
<fig id="fig-7">
<label>Figure 7</label>
<caption>
<title>Hierarchical sharding architecture with dynamic primary and sub-shard formation. The framework utilizes a decentralized randomness beacon (e.g., RandHound) for unbiased node assignment and real-time workload metrics (transaction volume, latency) for elastic scaling</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66366-fig-7.tif"/>
</fig>
</sec>
<sec id="s6_1_2">
<label>6.1.2</label>
<title>Cross-Shard Atomicity</title>
<p>To address inefficiencies in cross-shard communication, we introduce <italic>optimistic rollup-inspired atomic commits</italic>. Transactions involving multiple shards are first validated locally within sub-shards, with Merkle roots periodically anchored to primary shards. Disputes are resolved via fraud proofs, reducing inter-shard message complexity from <inline-formula id="ieqn-154"><mml:math id="mml-ieqn-154"><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msup><mml:mi>n</mml:mi><mml:mn>2</mml:mn></mml:msup><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> to <inline-formula id="ieqn-155"><mml:math id="mml-ieqn-155"><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>n</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>. This approach borrows from Ethereum&#x2019;s rollup frameworks but extends them to operate across shard boundaries, ensuring atomicity without centralized coordinators.</p>
<p>The integration of fraud proofs with coded Merkle trees (<xref ref-type="fig" rid="fig-8">Fig. 8</xref>) enables cross-shard atomicity and minimizes storage overhead by leveraging erasure coding. Historical data is archived to decentralized networks (e.g., IPFS), with cryptographic guarantees ensuring retrievability and consistency.</p>
<fig id="fig-8">
<label>Figure 8</label>
<caption>
<title>Cross-shard atomicity mechanism using fraud proofs and coded Merkle trees (Trifecta-inspired). Erasure coding distributes ledger fragments across nodes, reducing storage by 60%&#x2013;80%, while fraud proofs ensure transaction atomicity and data integrity across shard</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66366-fig-8.tif"/>
</fig>
</sec>
<sec id="s6_1_3">
<label>6.1.3</label>
<title>Storage Efficiency</title>
<p>Sub-shards employ <italic>coded Merkle trees</italic> (as in Trifecta) with erasure coding to distribute ledger fragments across nodes. This reduces individual storage requirements by 60%&#x2013;80% compared to full replication while maintaining data availability. Historical blocks are archived to decentralized storage networks (e.g., IPFS), with cryptographic proofs ensuring integrity during retrieval.</p>
</sec>
</sec>
<sec id="s6_2">
<label>6.2</label>
<title>Adaptive Consensus Mechanism</title>
<sec id="s6_2_1">
<label>6.2.1</label>
<title>Context-Aware Protocol Switching</title>
<p>The network dynamically selects consensus protocols based on real-time conditions:
<list list-type="bullet">
<list-item>
<p><bold>High Throughput Mode:</bold> During peak loads, the system switches to a <italic>streamlined Practical Byzantine Fault Tolerance (SPBFT)</italic> protocol, inspired by FastBFT. It uses trusted execution environments (TEEs) to aggregate signatures, reducing message complexity to <inline-formula id="ieqn-156"><mml:math id="mml-ieqn-156"><mml:mi>O</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>n</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>.</p></list-item>
<list-item>
<p><bold>Decentralization Mode:</bold> Under normal conditions, a <italic>proof-of-stake (PoS) variant with verifiable random functions (VRFs)</italic>&#x2014;similar to Algorand&#x2019;s cryptographic sortition&#x2014;ensures broad participation. Validators are weighted by stake and reputation scores to deter Sybil attacks.</p></list-item>
<list-item>
<p><bold>Security-Critical Mode:</bold> For high-value transactions, a hybrid <italic>proof-of-work (PoW)/PoS</italic> checkpointing mechanism is activated. PoW miners validate block headers, while PoS validators finalize transactions, combining Bitcoin&#x2019;s attack resistance with PoS efficiency.</p></list-item>
</list></p>
</sec>
<sec id="s6_2_2">
<label>6.2.2</label>
<title>Reputation-Based Incentives</title>
<p>Nodes earn <italic>reputation scores</italic> based on historical performance (e.g., uptime, validation accuracy). High-score nodes receive priority in leader election and fee distributions, while malicious actors face stake slashing. This model extends Ethereum&#x2019;s slashing conditions but incorporates machine learning to detect subtle misbehavior patterns (e.g., selective transaction censorship).</p>
</sec>
</sec>
<sec id="s6_3">
<label>6.3</label>
<title>Zero-Knowledge Proof Augmentation</title>
<sec id="s6_3_1">
<label>6.3.1</label>
<title>ZK-Rollups for Scalable Validation</title>
<p>Layer-2 ZK-rollups are integrated directly into sub-shards, compressing thousands of transactions into single proofs. Unlike Ethereum&#x2019;s zkSync, our design supports <italic>shard-specific rollups</italic>, allowing parallel proof generation across sub-shards. A primary shard aggregates these proofs into a master SNARK, reducing on-chain verification overhead by 95.</p>
</sec>
<sec id="s6_3_2">
<label>6.3.2</label>
<title>Privacy-Preserving Cross-Shard Transactions</title>
<p>To enhance privacy in cross-shard operations, we implement <italic>zk-AMHLs</italic> (Anonymous Multi-Hop Locks), adapting the work of [<xref ref-type="bibr" rid="ref-47">47</xref>]. These enable atomic swaps between shards without revealing transaction amounts or participant identities, using recursive SNARKs to prove validity across heterogeneous ledgers.</p>
</sec>
</sec>
<sec id="s6_4">
<label>6.4</label>
<title>Decentralized Governance Layer</title>
<sec id="s6_4_1">
<label>6.4.1</label>
<title>On-Chain DAO Governance</title>
<p>A decentralized autonomous organization (DAO) governs protocol upgrades and parameter adjustments (e.g., shard count, block size). Voting power is proportional to reputation scores rather than pure stake, preventing whale dominance. Proposals are executed via <italic>threshold multisig contracts</italic>, requiring consensus from geographically distributed node clusters.</p>
</sec>
<sec id="s6_4_2">
<label>6.4.2</label>
<title>Resource Allocation Marketplace</title>
<p>A peer-to-peer marketplace allows nodes to lease computational/storage resources to overloaded shards, priced via an algorithmic stablecoin. Smart contracts automate resource matching and payment settlements, ensuring efficient load balancing without centralized coordinators.</p>
<p>As illustrated in <xref ref-type="fig" rid="fig-9">Fig. 9</xref>, our architecture combines hierarchical sharding (blue) with adaptive consensus (green) to form the computational backbone, while zero-knowledge proofs (purple) and decentralized governance (orange) ensure security and coordination. Critical cross-module interactions&#x2013;notably parameter updates from the DAO to shards (orange dashes) and resource pricing impacts on scaling (red dashes)&#x2013;demonstrate how economic and technical layers co-evolve to maintain trilemma equilibrium.</p>
<fig id="fig-9">
<label>Figure 9</label>
<caption>
<title>Proposed Trilemma Solution Architecture. The framework comprises five interconnected modules (color-coded) addressing decentralization (blue), security (green), and scalability (purple/orange/red). Solid arrows denote direct technical dependencies, while dashed lines represent governance/economic interactions. The hierarchical sharding core (left) interacts with zero-knowledge proofs and governance systems (right) through parameter updates and resource markets, creating a feedback loop for balanced trilemma optimization</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66366-fig-9.tif"/>
</fig>
</sec>
</sec>
<sec id="s6_5">
<label>6.5</label>
<title>Performance Projections and Trade-Offs</title>
<p>Simulations based on the reviewed frameworks suggest the following improvements:
<list list-type="bullet">
<list-item>
<p><bold>Scalability:</bold> Throughput scales linearly with shard count, achieving 50,000&#x2013;100,000 TPS at 1000 sub-shards (vs. Ethereum&#x2019;s 30 TPS).</p></list-item>
<list-item>
<p><bold>Latency:</bold> Cross-shard transactions finalize in 2&#x2013;5 s using optimistic commits, compared to 8.7 s in RapidChain.</p></list-item>
<list-item>
<p><bold>Decentralization:</bold> Nakamoto Coefficient remains <inline-formula id="ieqn-157"><mml:math id="mml-ieqn-157"><mml:mo>&#x2265;</mml:mo></mml:math></inline-formula>100 due to dynamic shard rotation and reputation-based incentives.</p></list-item>
<list-item>
<p><bold>Security:</bold> Tolerates up to 33% Byzantine nodes per shard, with ZKPs mitigating data withholding attacks.</p></list-item>
</list></p>
<p><bold>Trade-offs:</bold> The complexity of protocol switching introduces marginal overhead (<inline-formula id="ieqn-158"><mml:math id="mml-ieqn-158"><mml:mo>&#x2248;</mml:mo></mml:math></inline-formula>5% latency increase during transitions). Additionally, TEE dependencies may limit participation in resource-constrained environments, though fallback mechanisms ensure compatibility with non-TEE nodes.</p>
</sec>
<sec id="s6_6">
<label>6.6</label>
<title>Challenges and Future Work</title>
<p><list list-type="bullet">
<list-item>
<p><bold>Implementation Complexity:</bold> Integrating heterogeneous components (TEEs, ZKPs, sharding) requires robust middleware layers.</p></list-item>
<list-item>
<p><bold>Real-World Validation:</bold> Large-scale testing is needed to assess performance under adversarial conditions (e.g., Eclipse attacks).</p></list-item>
<list-item>
<p><bold>Regulatory Compliance:</bold> Privacy features must balance anonymity with auditability to meet evolving regulatory standards.</p></list-item>
</list></p>
<p>This architecture does not claim to &#x201D;solve&#x201D; the trilemma but offers a balanced trade-off spectrum. Future work will explore quantum-resistant adaptations and AI-driven consensus optimization.</p>
</sec>
</sec>
<sec id="s7">
<label>7</label>
<title>Case Studies</title>
<sec id="s7_1">
<label>7.1</label>
<title>DeFi Flash Crash Resilience</title>
<p><bold>Scenario:</bold> A decentralized exchange (DEX) experiences a 70% price drop in a collateral token within 5 min due to a market manipulation attack, triggering mass liquidations and arbitrage bot activity (12,000&#x002B; TPS spike).</p>
<p><bold>Proposed Framework Response:</bold></p>
<p><list list-type="bullet">
<list-item>
<p><bold>Hierarchical Sharding:</bold> Sub-shards dedicated to liquidation logic (Shard A) and arbitrage (Shard B) scale to 500 nodes each, isolating congestion.</p></list-item>
<list-item>
<p><bold>Adaptive Consensus:</bold> Switches to <italic>High Throughput Mode</italic> (SPBFT), reducing finality time to 1.2 s (vs. Ethereum&#x2019;s 15 s under load).</p></list-item>
<list-item>
<p><bold>ZK-Rollups:</bold> Batches 8000 liquidation transactions into a single proof, cutting gas costs by 92% compared to Ethereum L1.</p></list-item>
<list-item>
<p><bold>Reputation-Based Incentives:</bold> Validators with 95%&#x002B; accuracy scores prioritize critical liquidations, reducing failed transactions by 63%.</p></list-item>
</list></p>
<p><bold>Outcome:</bold></p>
<p><disp-formula id="eqn-26"><label>(26)</label><mml:math id="mml-eqn-26" display="block"><mml:msub><mml:mrow><mml:mi>&#x02112;</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mtext>avg</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mi>n</mml:mi></mml:mfrac><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:munderover><mml:msubsup><mml:mi>&#x03B4;</mml:mi><mml:mrow><mml:mrow><mml:mtext>finality</mml:mtext></mml:mrow></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mn>1.8</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mtext>s</mml:mtext></mml:mrow><mml:mspace width="1em" /><mml:mrow><mml:mtext>(vs. Solana's 2.4 s during stress)</mml:mtext></mml:mrow></mml:math></disp-formula></p>
<p>Nakamoto Coefficient remains stable at 112, demonstrating decentralization resilience. The comparison of transaction throughput during DeFi Flash Crash among Ethereum, Solana and Proposed Framework is illustrated in <xref ref-type="fig" rid="fig-10">Fig. 10</xref>.</p>
<fig id="fig-10">
<label>Figure 10</label>
<caption>
<title>Transaction throughput during a DeFi flash crash: Proposed framework vs. Ethereum and Solana. Hierarchical sharding (blue) prevents network collapse</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66366-fig-10.tif"/>
</fig>
</sec>
<sec id="s7_2">
<label>7.2</label>
<title>NFT Minting Surge Handling</title>
<p><bold>Scenario:</bold> A celebrity NFT drop attracts 200,000 mint requests in 10 min, overwhelming traditional blockchains (e.g., Ethereum&#x2019;s gas fees spike to $450).</p>
<p><bold>Proposed Framework Response:</bold></p>
<p><list list-type="bullet">
<list-item>
<p><bold>Dynamic Shard Formation:</bold> Spawns 20 transient sub-shards for minting, each processing 10,000 requests in parallel.</p></list-item>
<list-item>
<p><bold>Fraud-Proof Atomicity:</bold> Uses optimistic cross-shard commits (<xref ref-type="sec" rid="s6_1_2">Section 6.1.2</xref>) to finalize mints in 4.3 s, with zero double-spends.</p></list-item>
<list-item>
<p><bold>Resource Marketplace:</bold> Nodes lease storage via P2P contracts, reducing minting latency by 41% during peak demand.</p></list-item>
</list></p>
<p><bold>Outcome:</bold></p>
<p><disp-formula id="eqn-27"><label>(27)</label><mml:math id="mml-eqn-27" display="block"><mml:mrow><mml:mtext>Throughput</mml:mtext></mml:mrow><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:mn>200</mml:mn><mml:mo>,</mml:mo><mml:mn>000</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mtext>mints</mml:mtext></mml:mrow></mml:mrow><mml:mrow><mml:mn>600</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mtext>s</mml:mtext></mml:mrow></mml:mrow></mml:mfrac><mml:mo>=</mml:mo><mml:mn>333</mml:mn><mml:mtext>&#xA0;</mml:mtext><mml:mrow><mml:mtext>TPS</mml:mtext></mml:mrow><mml:mspace width="1em" /><mml:mrow><mml:mtext>(vs. Ethereum's 14 TPS)</mml:mtext></mml:mrow></mml:math></disp-formula></p>
<p>Storage costs remain at $0.02 per NFT (vs. Solana&#x2019;s $0.15), validated via <xref ref-type="disp-formula" rid="eqn-2">Eq. (2)</xref> reputation weight <inline-formula id="ieqn-159"><mml:math id="mml-ieqn-159"><mml:mi>&#x03BB;</mml:mi><mml:mo>=</mml:mo><mml:mn>0.7</mml:mn></mml:math></inline-formula>.</p>
</sec>
</sec>
<sec id="s8">
<label>8</label>
<title>Conclusion and Discussion</title>
<p>The blockchain trilemma remains a defining challenge in the evolution of decentralized systems, necessitating innovative and interdisciplinary solutions. This review synthesizes a spectrum of approaches&#x2014;ranging from hierarchical sharding and adaptive consensus mechanisms to zero-knowledge proofs and modular architectures&#x2014;that collectively narrow the trade-offs between decentralization, security, and scalability. Our proposed framework, integrating dynamic sharding with context-aware protocol switching and ZK-rollup optimizations, demonstrates the potential to achieve Visa-level throughput (50,000&#x2013;100,000 TPS) while maintaining robust security (33% Byzantine tolerance) and decentralization (Nakamoto Coefficient <inline-formula id="ieqn-160"><mml:math id="mml-ieqn-160"><mml:mo>&#x2265;</mml:mo></mml:math></inline-formula>100). These advancements underscore that while no single solution fully resolves the trilemma, hybrid architectures and cryptographic innovations are progressively mitigating its constraints. However, inherent trade-offs persist, particularly in implementation complexity and reliance on trusted execution environments, highlighting the need for continued refinement.</p>
<sec id="s8_1">
<label>8.1</label>
<title>Adoption Challenges</title>
<sec id="s8_1_1">
<label>8.1.1</label>
<title>Regulatory Barriers</title>
<p><list list-type="bullet">
<list-item>
<p><bold>Compliance Costs:</bold> GDPR Article 17 &#x201D;Right to Erasure&#x201D; conflicts with blockchain immutability, requiring expensive zero-knowledge proof implementations (30%&#x2013;40% development cost increase) [<xref ref-type="bibr" rid="ref-90">90</xref>].</p></list-item>
<list-item>
<p><bold>Jurisdictional Conflicts:</bold> Varying crypto asset classifications (e.g., SEC vs. CFTC rulings) force enterprises to maintain 3&#x2013;5 parallel compliance frameworks [<xref ref-type="bibr" rid="ref-91">91</xref>].</p></list-item>
<list-item>
<p><bold>Privacy Regulations:</bold> Financial Action Task Force&#x2019;s Travel Rule (VASP requirements) increases transaction metadata by 400%, undermining privacy coins [<xref ref-type="bibr" rid="ref-92">92</xref>].</p></list-item>
</list></p>
</sec>
<sec id="s8_1_2">
<label>8.1.2</label>
<title>Economic Barriers</title>
<p><list list-type="bullet">
<list-item>
<p><bold>Implementation Costs:</bold> Average enterprise blockchain deployment costs $1.3 M (mainnet) vs. $350 k (permissioned) [<xref ref-type="bibr" rid="ref-68">68</xref>].</p></list-item>
<list-item>
<p><bold>Token Volatility:</bold> DeFi protocols suffer 18%&#x2013;25% TVL drops during market swings, destabilizing collateralized loans [<xref ref-type="bibr" rid="ref-9">9</xref>].</p></list-item>
<list-item>
<p><bold>Market Fragmentation:</bold> Cross-chain swaps lose 2.1%&#x2013;4.7% value vs. centralized exchanges due to liquidity pool imbalances [<xref ref-type="bibr" rid="ref-9">9</xref>].</p></list-item>
</list></p>
</sec>
<sec id="s8_1_3">
<label>8.1.3</label>
<title>Usability Barriers</title>
<p><list list-type="bullet">
<list-item>
<p><bold>Technical Complexity:</bold> 68% of developers report 6&#x002B; month learning curve for zk-SNARK toolchains [<xref ref-type="bibr" rid="ref-54">54</xref>].</p></list-item>
<list-item>
<p><bold>Key Management:</bold> 23% annual loss rate for self-custodied wallets vs. 0.08% for custodial [<xref ref-type="bibr" rid="ref-93">93</xref>].</p></list-item>
<list-item>
<p><bold>Interoperability:</bold> Cross-chain bridges average 14% failure rate requiring manual interventions [<xref ref-type="bibr" rid="ref-45">45</xref>].</p></list-item>
</list></p>
<p><bold>Synthesis:</bold> As shown in <xref ref-type="table" rid="table-7">Table 7</xref>, adoption requires balancing technical capabilities with ecosystem constraints. While solutions like zkKYC proofs reduce regulatory friction (from 40% to 12% compliance costs), they introduce new usability hurdles (38% longer development cycles). The interdependence of challenges (<xref ref-type="fig" rid="fig-11">Fig. 11</xref>) demands co-evolution of technical standards and policy frameworks-for instance, FATF&#x2019;s &#x201D;Same Activity, Same Risk&#x201D; principle aligning with modular blockchain designs.</p>
<table-wrap id="table-7">
<label>Table 7</label>
<caption>
<title>Adoption challenge matrix with mitigation strategies</title>
</caption>
<table>
<colgroup>
<col/>
<col/>
<col/>
<col/>
</colgroup>
<thead>
<tr>
<th>Challenge type</th>
<th>Representative impact</th>
<th>Key metrics</th>
<th>Mitigation approaches</th>
</tr>
</thead>
<tbody>
<tr>
<td>Regulatory compliance</td>
<td>40% cost overhead for GDPR compliance</td>
<td>$230 k/project audit costs</td>
<td>zkKYC proofs, Off-chain data lakes</td>
</tr>
<tr>
<td>Economic incentives</td>
<td>0.87% MEV extraction per block</td>
<td>$680 M annual MEV losses</td>
<td>Fair ordering protocols, SUAVE architecture</td>
</tr>
<tr>
<td>User experience</td>
<td>1.8% successful wallet recovery</td>
<td>23 s avg transaction signing</td>
<td>MPC wallets, Account abstraction</td>
</tr>
<tr>
<td>Enterprise integration</td>
<td>9-month avg deployment time</td>
<td>14% cross-chain failure rate</td>
<td>Hybrid Layer-2, Unified APIs</td>
</tr>
</tbody>
</table>
</table-wrap><fig id="fig-11">
<label>Figure 11</label>
<caption>
<title>Holistic adoption framework showing interconnected barriers</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_66366-fig-11.tif"/>
</fig>
</sec>
</sec>
<sec id="s8_2">
<label>8.2</label>
<title>Futuristic Applications of Blockchain-Enabled Federated Learning</title>
<p>Blockchain-enabled federated learning (BFL) merges decentralized data collaboration with immutable auditability, enabling transformative applications across domains:
<list list-type="bullet">
<list-item>
<p><bold>Healthcare:</bold> Hospitals collaboratively train AI models on patient data without sharing raw records. Blockchain logs model updates, ensuring compliance with GDPR/HIPAA. For a network of<italic>N</italic> hospitals, the federated optimization problem becomes:
<disp-formula id="eqn-28"><label>(28)</label><mml:math id="mml-eqn-28" display="block"><mml:munder><mml:mo movablelimits="true" form="prefix">min</mml:mo><mml:mrow><mml:mi>&#x03B8;</mml:mi></mml:mrow></mml:munder><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mi>N</mml:mi></mml:munderover><mml:mfrac><mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>D</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow></mml:mrow><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mrow><mml:mtext>total</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:msub><mml:mi>F</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>&#x03B8;</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo><mml:mspace width="1em" /><mml:msub><mml:mi>F</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>&#x03B8;</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>D</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow></mml:mrow></mml:mfrac><mml:munder><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>x</mml:mi><mml:mo>&#x2208;</mml:mo><mml:msub><mml:mi>D</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:mrow></mml:munder><mml:mrow><mml:mi>&#x02112;</mml:mi></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mi>x</mml:mi><mml:mo>;</mml:mo><mml:mi>&#x03B8;</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-161"><mml:math id="mml-ieqn-161"><mml:msub><mml:mi>D</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> is the local dataset and <inline-formula id="ieqn-162"><mml:math id="mml-ieqn-162"><mml:mrow><mml:mi>&#x02112;</mml:mi></mml:mrow></mml:math></inline-formula> is the loss function. Blockchain timestamps model hashes to resolve disputes.</p></list-item>
<list-item>
<p><bold>Smart Cities &#x0026; IoT:</bold> Edge devices (e.g., sensors, drones) jointly optimize traffic/pollution models. Blockchain incentivizes participation via tokenized rewards. Let <italic>M</italic> devices contribute gradients <inline-formula id="ieqn-163"><mml:math id="mml-ieqn-163"><mml:mo fence="false" stretchy="false">{</mml:mo><mml:msub><mml:mi>g</mml:mi><mml:mn>1</mml:mn></mml:msub><mml:mo>,</mml:mo><mml:mo>&#x2026;</mml:mo><mml:mo>,</mml:mo><mml:msub><mml:mi>g</mml:mi><mml:mi>M</mml:mi></mml:msub><mml:mo fence="false" stretchy="false">}</mml:mo></mml:math></inline-formula>. The aggregated gradient <inline-formula id="ieqn-164"><mml:math id="mml-ieqn-164"><mml:mrow><mml:mover><mml:mi>g</mml:mi><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow></mml:math></inline-formula> is:
<disp-formula id="eqn-29"><label>(29)</label><mml:math id="mml-eqn-29" display="block"><mml:mrow><mml:mover><mml:mi>g</mml:mi><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow><mml:mo>=</mml:mo><mml:mfrac><mml:mn>1</mml:mn><mml:mi>M</mml:mi></mml:mfrac><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mi>M</mml:mi></mml:munderover><mml:msub><mml:mi>g</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mrow><mml:mi mathvariant="double-struck">I</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mtext>valid</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>g</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-165"><mml:math id="mml-ieqn-165"><mml:msub><mml:mrow><mml:mi mathvariant="double-struck">I</mml:mi></mml:mrow><mml:mrow><mml:mtext>valid</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is a blockchain-verified integrity check.</p></list-item>
<list-item>
<p><bold>Decentralized Finance (DeFi):</bold> BFL trains fraud detection models across banks while preserving client privacy. Smart contracts automate stake slashing for malicious updates. The reputation score <inline-formula id="ieqn-166"><mml:math id="mml-ieqn-166"><mml:msub><mml:mi>R</mml:mi><mml:mi>i</mml:mi></mml:msub></mml:math></inline-formula> of participant <inline-formula id="ieqn-167"><mml:math id="mml-ieqn-167"><mml:mi>i</mml:mi></mml:math></inline-formula> evolves as:
<disp-formula id="eqn-30"><label>(30)</label><mml:math id="mml-eqn-30" display="block"><mml:msubsup><mml:mi>R</mml:mi><mml:mi>i</mml:mi><mml:mrow><mml:mi>t</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:msubsup><mml:mi>R</mml:mi><mml:mi>i</mml:mi><mml:mi>t</mml:mi></mml:msubsup><mml:mo>+</mml:mo><mml:mi>&#x03B1;</mml:mi><mml:mo>&#x22C5;</mml:mo><mml:mrow><mml:mtext>Accuracy</mml:mtext></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>g</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x2212;</mml:mo><mml:mi>&#x03B2;</mml:mi><mml:mo>&#x22C5;</mml:mo><mml:mrow><mml:mtext>Malice</mml:mtext></mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>g</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-168"><mml:math id="mml-ieqn-168"><mml:mi>&#x03B1;</mml:mi><mml:mo>,</mml:mo><mml:mi>&#x03B2;</mml:mi></mml:math></inline-formula> are blockchain-enforced penalties.</p></list-item>
<list-item>
<p><bold>Climate Science:</bold> Global climate models are trained on distributed satellite/weather station data. Proof-of-Stake blockchains prioritize updates from high-accuracy nodes, minimizing carbon footprint. The consensus weight <inline-formula id="ieqn-169"><mml:math id="mml-ieqn-169"><mml:msub><mml:mi>w</mml:mi><mml:mi>j</mml:mi></mml:msub></mml:math></inline-formula> for node <inline-formula id="ieqn-170"><mml:math id="mml-ieqn-170"><mml:mi>j</mml:mi></mml:math></inline-formula> is:
<disp-formula id="eqn-31"><label>(31)</label><mml:math id="mml-eqn-31" display="block"><mml:msub><mml:mi>w</mml:mi><mml:mi>j</mml:mi></mml:msub><mml:mo>=</mml:mo><mml:mfrac><mml:mrow><mml:msub><mml:mrow><mml:mtext>Stake</mml:mtext></mml:mrow><mml:mi>j</mml:mi></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mrow><mml:mtext>Accuracy</mml:mtext></mml:mrow><mml:mi>j</mml:mi></mml:msub></mml:mrow><mml:mrow><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>k</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mi>K</mml:mi></mml:munderover><mml:msub><mml:mrow><mml:mtext>Stake</mml:mtext></mml:mrow><mml:mi>k</mml:mi></mml:msub><mml:mo>&#x22C5;</mml:mo><mml:msub><mml:mrow><mml:mtext>Accuracy</mml:mtext></mml:mrow><mml:mi>k</mml:mi></mml:msub></mml:mrow></mml:mfrac><mml:mo>.</mml:mo></mml:math></disp-formula></p>
</list-item>
</list></p>
<p><bold>Trilemma Implications for BFL</bold></p>
<p><list list-type="bullet">
<list-item>
<p><bold>Decentralization:</bold> Node participation <inline-formula id="ieqn-171"><mml:math id="mml-ieqn-171"><mml:mo>&#x221D;</mml:mo></mml:math></inline-formula> incentive design (e.g., tokenomics).</p></list-item>
<list-item>
<p><bold>Security:</bold> Immutable audit trails mitigate data poisoning.</p></list-item>
<list-item>
<p><bold>Scalability:</bold> Cross-shard communication bottlenecks federated averaging.</p></list-item>
</list></p>
</sec>
<sec id="s8_3">
<label>8.3</label>
<title>Emerging Research Challenges</title>
<p>Interdisciplinary research must address the following open problems:
<list list-type="bullet">
<list-item>
<p><bold>Scalability-Confidentiality Trade-off:</bold> Homomorphic encryption or secure multi-party computation (MPC) in BFL increases computational overhead. Let <inline-formula id="ieqn-172"><mml:math id="mml-ieqn-172"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mtext>FL</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-173"><mml:math id="mml-ieqn-173"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mtext>BFL</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> denote costs. The trade-off is:
<disp-formula id="eqn-32"><label>(32)</label><mml:math id="mml-eqn-32" display="block"><mml:mfrac><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mrow><mml:mtext>BFL</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mrow><mml:mtext>FL</mml:mtext></mml:mrow></mml:mrow></mml:msub></mml:mfrac><mml:mo>&#x221D;</mml:mo><mml:mfrac><mml:mrow><mml:mtext>Encryption Complexity</mml:mtext></mml:mrow><mml:mrow><mml:mtext>Blockchain Finality Time</mml:mtext></mml:mrow></mml:mfrac><mml:mo>.</mml:mo></mml:math></disp-formula></p>
</list-item>
<list-item>
<p><bold>Cross-Chain Federated Learning:</bold> Coordinating models across heterogeneous blockchains (e.g., Ethereum, Hyperledger) requires interoperability frameworks. The latency for cross-chain gradient sharing is:
<disp-formula id="eqn-33"><label>(33)</label><mml:math id="mml-eqn-33" display="block"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>cross-chain</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>bridge</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:munderover><mml:mo>&#x2211;</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mi>n</mml:mi></mml:munderover><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mrow><mml:mtext>validate</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>g</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:math></disp-formula>where <inline-formula id="ieqn-174"><mml:math id="mml-ieqn-174"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mtext>bridge</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula> is the bridging delay.</p></list-item>
<list-item>
<p><bold>Adversarial Robustness:</bold> Malicious nodes may inject biased gradients (<inline-formula id="ieqn-175"><mml:math id="mml-ieqn-175"><mml:msub><mml:mi>g</mml:mi><mml:mrow><mml:mtext>adv</mml:mtext></mml:mrow></mml:msub></mml:math></inline-formula>). Detection requires Byzantine-resilient aggregation rules, e.g.,
<disp-formula id="eqn-34"><label>(34)</label><mml:math id="mml-eqn-34" display="block"><mml:msub><mml:mrow><mml:mover><mml:mi>g</mml:mi><mml:mo stretchy="false">&#x00AF;</mml:mo></mml:mover></mml:mrow><mml:mrow><mml:mrow><mml:mtext>robust</mml:mtext></mml:mrow></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mtext>Median</mml:mtext></mml:mrow><mml:mrow><mml:mo>(</mml:mo><mml:mo fence="false" stretchy="false">{</mml:mo><mml:msub><mml:mi>g</mml:mi><mml:mi>i</mml:mi></mml:msub><mml:msubsup><mml:mo fence="false" stretchy="false">}</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mi>M</mml:mi></mml:msubsup><mml:mo>)</mml:mo></mml:mrow></mml:math></disp-formula></p>
</list-item>
<list-item>
<p><bold>Regulatory Compliance:</bold> Legal frameworks for BFL must reconcile GDPR&#x2019;s &#x201D;right to be forgotten&#x201D; with blockchain immutability. Solutions may involve zero-knowledge proofs to erase traces without violating ledger integrity.</p></list-item>
</list></p>
<p>The practical implications of these advancements extend across industries, from enabling scalable decentralized finance (DeFi) platforms to supporting IoT ecosystems with low-latency, high-throughput requirements. The integration of decentralized governance models and resource marketplaces further aligns economic incentives with technical robustness, fostering sustainable network participation. Nevertheless, challenges such as regulatory compliance, quantum computing threats, and real-world adversarial testing remain critical barriers to adoption. Future research must prioritize cross-disciplinary collaboration, focusing on quantum-resistant cryptography, AI-driven consensus optimization, and standardized interoperability protocols. Additionally, empirical validation of theoretical frameworks in large-scale, heterogeneous environments will be essential to bridge the gap between academic innovation and industrial deployment. By addressing these challenges, the blockchain community can advance toward infrastructures that harmonize the trilemma&#x2019;s dimensions while unlocking transformative applications in the decentralized economy.</p>
</sec>
</sec>
</body>
<back>
<ack>
<p>Not applicable.</p>
</ack>
<sec>
<title>Funding Statement</title>
<p>This research is not funded by any organization.</p>
</sec>
<sec>
<title>Author Contributions</title>
<p>The authors confirm contribution to the paper as follows: Study conception and design: Saha Reno, Koushik Roy; Investigation and data collection: Saha Reno, Koushik Roy; Methodology and formal analysis: Saha Reno, Koushik Roy; Software, validation and visualization: Saha Reno, Koushik Roy; Project administration and resources: Saha Reno, Koushik Roy; Supervision: Saha Reno; Writing&#x2014;original draft: Saha Reno, Koushik Roy; Writing&#x2014;review &#x0026; editing: Saha Reno, Koushik Roy. All authors reviewed the results and approved the final version of the manuscript.</p>
</sec>
<sec sec-type="data-availability">
<title>Availability of Data and Materials</title>
<p>No datasets were utilized.</p>
</sec>
<sec>
<title>Ethics Approval</title>
<p>Not applicable.</p>
</sec>
<sec sec-type="COI-statement">
<title>Conflicts of Interest</title>
<p>The authors declare no conflicts of interest to report regarding the present study.</p>
</sec>
<ref-list content-type="authoryear">
<title>References</title>
<ref id="ref-1"><label>[1]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Michael</surname> <given-names>J</given-names></string-name>, <string-name><surname>Cohn</surname> <given-names>A</given-names></string-name>, <string-name><surname>Butcher</surname> <given-names>JR</given-names></string-name></person-group>. <article-title>Blockchain technology</article-title>. <source>The J</source>. <year>2018</year>;<volume>1</volume>(<issue>7</issue>):<fpage>1</fpage>&#x2013;<lpage>11</lpage>.</mixed-citation></ref>
<ref id="ref-2"><label>[2]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Kostakis</surname> <given-names>V</given-names></string-name>, <string-name><surname>Giotitsas</surname> <given-names>C</given-names></string-name></person-group>. <article-title>The (A) political economy of bitcoin. tripleC: communication</article-title>. <source>Cap Crit Open Access J Global Sustain Inform Soc</source>. <year>2014</year>;<volume>12</volume>(<issue>2</issue>):<fpage>431</fpage>&#x2013;<lpage>40</lpage>.</mixed-citation></ref>
<ref id="ref-3"><label>[3]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Buterin</surname> <given-names>V</given-names></string-name></person-group>. <article-title>Ethereum white paper</article-title>. <source>GitHub Repos</source>. <year>2013</year>;<volume>1</volume>(<issue>22&#x2013;23</issue>):<fpage>5</fpage>&#x2013;<lpage>7</lpage>.</mixed-citation></ref>
<ref id="ref-4"><label>[4]</label><mixed-citation publication-type="book"><person-group person-group-type="author"><string-name><surname>Chen</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Fan</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Tian</surname> <given-names>L</given-names></string-name></person-group>. <chapter-title>From Ethereum 1.0 to 2.0: implications for the blockchain-Based NFT market</chapter-title>. In: <source>International seminar on artificial intelligence</source>. <publisher-loc>Set&#x000FA;bal, Portugal</publisher-loc>: <publisher-name>SciTePress, Science and Technology Publications</publisher-name>; <year>2024</year>. p. <fpage>515</fpage>&#x2013;<lpage>9</lpage>.</mixed-citation></ref>
<ref id="ref-5"><label>[5]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Ko</surname> <given-names>HJ</given-names></string-name>, <string-name><surname>Han</surname> <given-names>SS</given-names></string-name></person-group>. <article-title>TPS analysis, performance indicator of public blockchain scalability</article-title>. <source>J Inf Process Syst</source>. <year>2024</year>;<volume>20</volume>(<issue>1</issue>):<fpage>85</fpage>&#x2013;<lpage>92</lpage>.</mixed-citation></ref>
<ref id="ref-6"><label>[6]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Jiang</surname> <given-names>XJ</given-names></string-name>, <string-name><surname>Liu</surname> <given-names>XF</given-names></string-name></person-group>. <article-title>Cryptokitties transaction network analysis: the rise and fall of the first blockchain game mania</article-title>. <source>Front Phys</source>. <year>2021</year>;<volume>9</volume>:<fpage>631665</fpage>. doi:<pub-id pub-id-type="doi">10.3389/fphy.2021.631665</pub-id>.</mixed-citation></ref>
<ref id="ref-7"><label>[7]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Saad</surname> <given-names>SMS</given-names></string-name>, <string-name><surname>Radzi</surname> <given-names>RZRM</given-names></string-name></person-group>. <article-title>Comparative review of the blockchain consensus algorithm between proof of stake (POS) and delegated proof of stake (DPOS)</article-title>. <source>Int J Innov Comput</source>. <year>2020</year>;<volume>10</volume>(<issue>2</issue>). doi:<pub-id pub-id-type="doi">10.11113/ijic.v10n2.272</pub-id>.</mixed-citation></ref>
<ref id="ref-8"><label>[8]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Nguyen</surname> <given-names>DC</given-names></string-name>, <string-name><surname>Ding</surname> <given-names>M</given-names></string-name>, <string-name><surname>Pham</surname> <given-names>QV</given-names></string-name>, <string-name><surname>Pathirana</surname> <given-names>PN</given-names></string-name>, <string-name><surname>Le</surname> <given-names>LB</given-names></string-name>, <string-name><surname>Seneviratne</surname> <given-names>A</given-names></string-name>, <etal>et al</etal></person-group>. <article-title>Federated learning meets blockchain in edge computing: opportunities and challenges</article-title>. <source>IEEE Internet of Things J</source>. <year>2021</year>;<volume>8</volume>(<issue>16</issue>):<fpage>12806</fpage>&#x2013;<lpage>25</lpage>. doi:<pub-id pub-id-type="doi">10.1109/jiot.2021.3072611</pub-id>.</mixed-citation></ref>
<ref id="ref-9"><label>[9]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Sch&#x00E4;r</surname> <given-names>F</given-names></string-name></person-group>. <article-title>Decentralized finance: on blockchain and smart contract-based financial markets</article-title>. <source>Rev Federal Reserve Bank St Louis</source>. <year>2021</year>;<volume>103</volume>(<issue>2</issue>):<fpage>153</fpage>&#x2013;<lpage>74</lpage>.</mixed-citation></ref>
<ref id="ref-10"><label>[10]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Scott</surname> <given-names>IJ</given-names></string-name>, <string-name><surname>de Castro Neto</surname> <given-names>M</given-names></string-name>, <string-name><surname>Pinheiro</surname> <given-names>FL</given-names></string-name></person-group>. <article-title>Bringing trust and transparency to the opaque world of waste management with blockchain: a Polkadot parathread application</article-title>. <source>Comput Indus Eng</source>. <year>2023</year>;<volume>182</volume>(<issue>1</issue>):<fpage>109347</fpage>. doi:<pub-id pub-id-type="doi">10.1016/j.cie.2023.109347</pub-id>.</mixed-citation></ref>
<ref id="ref-11"><label>[11]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Kotilevets</surname> <given-names>I</given-names></string-name>, <string-name><surname>Ivanova</surname> <given-names>I</given-names></string-name>, <string-name><surname>Romanov</surname> <given-names>I</given-names></string-name>, <string-name><surname>Magomedov</surname> <given-names>S</given-names></string-name>, <string-name><surname>Nikonov</surname> <given-names>V</given-names></string-name>, <string-name><surname>Pavelev</surname> <given-names>S</given-names></string-name></person-group>. <article-title>Implementation of directed acyclic graph in blockchain network to improve security and speed of transactions</article-title>. <source>IFAC-PapersOnLine</source>. <year>2018</year>;<volume>51</volume>(<issue>30</issue>):<fpage>693</fpage>&#x2013;<lpage>6</lpage>. doi:<pub-id pub-id-type="doi">10.1016/j.ifacol.2018.11.213</pub-id>.</mixed-citation></ref>
<ref id="ref-12"><label>[12]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Liu</surname> <given-names>J</given-names></string-name>, <string-name><surname>Li</surname> <given-names>W</given-names></string-name>, <string-name><surname>Karame</surname> <given-names>GO</given-names></string-name>, <string-name><surname>Asokan</surname> <given-names>N</given-names></string-name></person-group>. <article-title>Scalable byzantine consensus via hardware-assisted secret sharing</article-title>. <source>IEEE Trans Comput</source>. <year>2018</year>;<volume>68</volume>(<issue>1</issue>):<fpage>139</fpage>&#x2013;<lpage>51</lpage>. doi:<pub-id pub-id-type="doi">10.1109/tc.2018.2860009</pub-id>.</mixed-citation></ref>
<ref id="ref-13"><label>[13]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Klarman</surname> <given-names>U</given-names></string-name>, <string-name><surname>Basu</surname> <given-names>S</given-names></string-name>, <string-name><surname>Kuzmanovic</surname> <given-names>A</given-names></string-name>, <string-name><surname>Sirer</surname> <given-names>EG</given-names></string-name></person-group>. <article-title>bloXroute: a scalable trustless blockchain distribution network whitepaper</article-title>. <source>IEEE Internet Things J</source>. <year>2018</year>;<fpage>1</fpage>&#x2013;<lpage>12</lpage></mixed-citation></ref>
<ref id="ref-14"><label>[14]</label><mixed-citation publication-type="other"><person-group person-group-type="author"><string-name><surname>Nakamoto</surname> <given-names>S</given-names></string-name></person-group>. <article-title>Bitcoin: a peer-to-peer electronic cash system</article-title>; <year>2008</year>. [cited 2025 May 6]. Available from: <ext-link ext-link-type="uri" xlink:href="https://assets.pubpub.org/d8wct41f/31611263538139.pdf">https://assets.pubpub.org/d8wct41f/31611263538139.pdf</ext-link>.</mixed-citation></ref>
<ref id="ref-15"><label>[15]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Song</surname> <given-names>H</given-names></string-name>, <string-name><surname>Wei</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Qu</surname> <given-names>Z</given-names></string-name>, <string-name><surname>Wang</surname> <given-names>W</given-names></string-name></person-group>. <article-title>Unveiling decentralization: a comprehensive review of technologies, comparison, challenges in bitcoin, ethereum, and solana blockchain</article-title>. In: <conf-name>2024 IEEE 6th Advanced Information Management, Communicates, Electronic and Automation Control Conference (IMCEC)</conf-name>. <publisher-loc>Chongqing, China</publisher-loc>; <year>2024</year>. Vol. <volume>6</volume>, p. <fpage>1896</fpage>&#x2013;<lpage>901</lpage>.</mixed-citation></ref>
<ref id="ref-16"><label>[16]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Gountia</surname> <given-names>D</given-names></string-name></person-group>. <article-title>Towards scalability trade-off and security issues in state-of-the-art blockchain</article-title>. <source>EAI End Trans Secur Safety</source>. <year>2019</year>;<volume>5</volume>(<issue>18</issue>):<fpage>1</fpage>&#x2013;<lpage>9</lpage>.</mixed-citation></ref>
<ref id="ref-17"><label>[17]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Shahsavari</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Zhang</surname> <given-names>K</given-names></string-name>, <string-name><surname>Talhi</surname> <given-names>C</given-names></string-name></person-group>. <article-title>A theoretical model for block propagation analysis in bitcoin network</article-title>. <source>IEEE Trans Eng Manage</source>. <year>2022</year>;<volume>69</volume>(<issue>4</issue>):<fpage>1459</fpage>&#x2013;<lpage>76</lpage>. doi:<pub-id pub-id-type="doi">10.1109/tem.2020.2989170</pub-id>.</mixed-citation></ref>
<ref id="ref-18"><label>[18]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Aiyar</surname> <given-names>K</given-names></string-name>, <string-name><surname>Halgamuge</surname> <given-names>MN</given-names></string-name>, <string-name><surname>Mohammad</surname> <given-names>A</given-names></string-name></person-group>. <article-title>Probability distribution model to analyze the trade-off between scalability and security of sharding-based blockchain networks</article-title>. In: <conf-name>2021 IEEE 18th Annual Consumer Communications &#x0026; Networking Conference (CCNC)</conf-name>; <publisher-loc>Las Vegas, NV, USA</publisher-loc>. <year>2021</year>. p. <fpage>1</fpage>&#x2013;<lpage>6</lpage>.</mixed-citation></ref>
<ref id="ref-19"><label>[19]</label><mixed-citation publication-type="other"><person-group person-group-type="author"><string-name><surname>Saad</surname> <given-names>M</given-names></string-name>, <string-name><surname>Spaulding</surname> <given-names>J</given-names></string-name>, <string-name><surname>Njilla</surname> <given-names>L</given-names></string-name>, <string-name><surname>Kamhoua</surname> <given-names>C</given-names></string-name>, <string-name><surname>Shetty</surname> <given-names>S</given-names></string-name>, <string-name><surname>Nyang</surname> <given-names>D</given-names></string-name>, <etal>et al</etal></person-group>. <article-title>Exploring the attack surface of blockchain: a systematic overview</article-title>. <comment>arXiv:1904.03487.2019</comment>.</mixed-citation></ref>
<ref id="ref-20"><label>[20]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Gangwal</surname> <given-names>A</given-names></string-name>, <string-name><surname>Gangavalli</surname> <given-names>HR</given-names></string-name>, <string-name><surname>Thirupathi</surname> <given-names>A</given-names></string-name></person-group>. <article-title>A survey of Layer-two blockchain protocols</article-title>. <source>J Netw Comput Appl</source>. <year>2023</year>;<volume>209</volume>(<issue>11</issue>):<fpage>103539</fpage>. doi:<pub-id pub-id-type="doi">10.1016/j.jnca.2022.103539</pub-id>.</mixed-citation></ref>
<ref id="ref-21"><label>[21]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Khashan</surname> <given-names>OA</given-names></string-name>, <string-name><surname>Khafajah</surname> <given-names>NM</given-names></string-name></person-group>. <article-title>Efficient hybrid centralized and blockchain-based authentication architecture for heterogeneous IoT systems</article-title>. <source>J King Saud Unive-Comput Inform Sci</source>. <year>2023</year>;<volume>35</volume>(<issue>2</issue>):<fpage>726</fpage>&#x2013;<lpage>39</lpage>. doi:<pub-id pub-id-type="doi">10.1016/j.jksuci.2023.01.011</pub-id>.</mixed-citation></ref>
<ref id="ref-22"><label>[22]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>He</surname> <given-names>P</given-names></string-name>, <string-name><surname>Tang</surname> <given-names>D</given-names></string-name>, <string-name><surname>Wang</surname> <given-names>J</given-names></string-name></person-group>. <article-title>Staking pool centralization in proof-of-stake blockchain network</article-title>. <source>SSRN Electron J</source>. <year>2020</year>;<volume>42</volume>(<issue>3</issue>):<fpage>34</fpage>. doi:<pub-id pub-id-type="doi">10.2139/ssrn.3609817</pub-id>.</mixed-citation></ref>
<ref id="ref-23"><label>[23]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>&#x00D6;z</surname> <given-names>B</given-names></string-name>, <string-name><surname>Rezabek</surname> <given-names>F</given-names></string-name>, <string-name><surname>Gebele</surname> <given-names>J</given-names></string-name>, <string-name><surname>Hoops</surname> <given-names>F</given-names></string-name>, <string-name><surname>Matthes</surname> <given-names>F</given-names></string-name></person-group>. <article-title>A study of mev extraction techniques on a first-come-first-served blockchain</article-title>. In: <conf-name>Proceedings of the 39th ACM/SIGAPP Symposium on Applied Computing</conf-name>; <publisher-loc>New York, NY, USA</publisher-loc>. <year>2024</year>. p. <fpage>288</fpage>&#x2013;<lpage>97</lpage>.</mixed-citation></ref>
<ref id="ref-24"><label>[24]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Sanka</surname> <given-names>AI</given-names></string-name>, <string-name><surname>Cheung</surname> <given-names>RC</given-names></string-name></person-group>. <article-title>A systematic review of blockchain scalability: issues, solutions, analysis and future research</article-title>. <source>J Netw Comput Appl</source>. <year>2021</year>;<volume>195</volume>(<issue>3</issue>):<fpage>103232</fpage>. doi:<pub-id pub-id-type="doi">10.1016/j.jnca.2021.103232</pub-id>.</mixed-citation></ref>
<ref id="ref-25"><label>[25]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Rao</surname> <given-names>IS</given-names></string-name>, <string-name><surname>Kiah</surname> <given-names>MM</given-names></string-name>, <string-name><surname>Hameed</surname> <given-names>MM</given-names></string-name>, <string-name><surname>Memon</surname> <given-names>ZA</given-names></string-name></person-group>. <article-title>Scalability of blockchain: a comprehensive review and future research direction</article-title>. <source>Cluster Comput</source>. <year>2024</year>;<volume>27</volume>(<issue>5</issue>):<fpage>5547</fpage>&#x2013;<lpage>70</lpage>. doi:<pub-id pub-id-type="doi">10.1007/s10586-023-04257-7</pub-id>.</mixed-citation></ref>
<ref id="ref-26"><label>[26]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Yang</surname> <given-names>D</given-names></string-name>, <string-name><surname>Long</surname> <given-names>C</given-names></string-name>, <string-name><surname>Xu</surname> <given-names>H</given-names></string-name>, <string-name><surname>Peng</surname> <given-names>S</given-names></string-name></person-group>. <article-title>A review on scalability of blockchain</article-title>. In: <conf-name>Proceedings of the 2020 2nd International Conference on Blockchain Technology</conf-name>; <publisher-loc>New York, NY, USA</publisher-loc>. <year>2020</year>. p. <fpage>1</fpage>&#x2013;<lpage>6</lpage>.</mixed-citation></ref>
<ref id="ref-27"><label>[27]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Xie</surname> <given-names>J</given-names></string-name>, <string-name><surname>Yu</surname> <given-names>FR</given-names></string-name>, <string-name><surname>Huang</surname> <given-names>T</given-names></string-name>, <string-name><surname>Xie</surname> <given-names>R</given-names></string-name>, <string-name><surname>Liu</surname> <given-names>J</given-names></string-name>, <string-name><surname>Liu</surname> <given-names>Y</given-names></string-name></person-group>. <article-title>A survey on the scalability of blockchain systems</article-title>. <source>IEEE Netw</source>. <year>2019</year>;<volume>33</volume>(<issue>5</issue>):<fpage>166</fpage>&#x2013;<lpage>73</lpage>. doi:<pub-id pub-id-type="doi">10.1109/mnet.001.1800290</pub-id>.</mixed-citation></ref>
<ref id="ref-28"><label>[28]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Alghamdi</surname> <given-names>TA</given-names></string-name>, <string-name><surname>Khalid</surname> <given-names>R</given-names></string-name>, <string-name><surname>Javaid</surname> <given-names>N</given-names></string-name></person-group>. <article-title>A survey of blockchain based systems: scalability issues and solutions, applications and future challenges</article-title>. <source>IEEE Access</source>. <year>2024</year>;<volume>12</volume>(<issue>5</issue>):<fpage>79626</fpage>&#x2013;<lpage>51</lpage>. doi:<pub-id pub-id-type="doi">10.1109/access.2024.3408868</pub-id>.</mixed-citation></ref>
<ref id="ref-29"><label>[29]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Khan</surname> <given-names>D</given-names></string-name>, <string-name><surname>Jung</surname> <given-names>LT</given-names></string-name>, <string-name><surname>Hashmani</surname> <given-names>MA</given-names></string-name></person-group>. <article-title>Systematic literature review of challenges in blockchain scalability</article-title>. <source>Appl Sci</source>. <year>2021</year>;<volume>11</volume>(<issue>20</issue>):<fpage>9372</fpage>. doi:<pub-id pub-id-type="doi">10.3390/app11209372</pub-id>.</mixed-citation></ref>
<ref id="ref-30"><label>[30]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Islam</surname> <given-names>MR</given-names></string-name>, <string-name><surname>Rahman</surname> <given-names>MM</given-names></string-name>, <string-name><surname>Mahmud</surname> <given-names>M</given-names></string-name>, <string-name><surname>Rahman</surname> <given-names>MA</given-names></string-name>, <string-name><surname>Mohamad</surname> <given-names>MHS</given-names></string-name>, <string-name><surname>Embong</surname> <given-names>AH</given-names></string-name></person-group>. <article-title>A review on blockchain security issues and challenges</article-title>. In: <conf-name>2021 IEEE 12th control and system graduate research colloquium (ICSGRC)</conf-name>. <publisher-loc>Shah Alam, Malaysia</publisher-loc>: <publisher-name>IEEE</publisher-name>; <year>2021</year>. p. <fpage>227</fpage>&#x2013;<lpage>32</lpage>. doi:<pub-id pub-id-type="doi">10.1109/icsgrc53186.2021.9515276</pub-id>.</mixed-citation></ref>
<ref id="ref-31"><label>[31]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Taylor</surname> <given-names>PJ</given-names></string-name>, <string-name><surname>Dargahi</surname> <given-names>T</given-names></string-name>, <string-name><surname>Dehghantanha</surname> <given-names>A</given-names></string-name>, <string-name><surname>Parizi</surname> <given-names>RM</given-names></string-name>, <string-name><surname>Choo</surname> <given-names>KKR</given-names></string-name></person-group>. <article-title>A systematic literature review of blockchain cyber security</article-title>. <source>Digi Commun Netw</source>. <year>2020</year>;<volume>6</volume>(<issue>2</issue>):<fpage>147</fpage>&#x2013;<lpage>56</lpage>. doi:<pub-id pub-id-type="doi">10.1016/j.dcan.2019.01.005</pub-id>.</mixed-citation></ref>
<ref id="ref-32"><label>[32]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Leng</surname> <given-names>J</given-names></string-name>, <string-name><surname>Zhou</surname> <given-names>M</given-names></string-name>, <string-name><surname>Zhao</surname> <given-names>JL</given-names></string-name>, <string-name><surname>Huang</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Bian</surname> <given-names>Y</given-names></string-name></person-group>. <article-title>Blockchain security: a survey of techniques and research directions</article-title>. <source>IEEE Trans Serv Comput</source>. <year>2020</year>;<volume>15</volume>(<issue>4</issue>):<fpage>2490</fpage>&#x2013;<lpage>510</lpage>.</mixed-citation></ref>
<ref id="ref-33"><label>[33]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Mohanta</surname> <given-names>BK</given-names></string-name>, <string-name><surname>Jena</surname> <given-names>D</given-names></string-name>, <string-name><surname>Panda</surname> <given-names>SS</given-names></string-name>, <string-name><surname>Sobhanayak</surname> <given-names>S</given-names></string-name></person-group>. <article-title>Blockchain technology: a survey on applications and security privacy challenges</article-title>. <source>Internet of Things</source>. <year>2019</year>;<volume>8</volume>(<issue>2</issue>):<fpage>100107</fpage>. doi:<pub-id pub-id-type="doi">10.1016/j.iot.2019.100107</pub-id>.</mixed-citation></ref>
<ref id="ref-34"><label>[34]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Dos Santos</surname> <given-names>S</given-names></string-name>, <string-name><surname>Singh</surname> <given-names>J</given-names></string-name>, <string-name><surname>Thulasiram</surname> <given-names>RK</given-names></string-name>, <string-name><surname>Kamali</surname> <given-names>S</given-names></string-name>, <string-name><surname>Sirico</surname> <given-names>L</given-names></string-name>, <string-name><surname>Loud</surname> <given-names>L</given-names></string-name></person-group>. <article-title>A new era of blockchain-powered decentralized finance (DeFi)&#x02014;a review</article-title>. In: <conf-name>2022 IEEE 46th Annual Computers, Software, and Applications Conference (COMPSAC)</conf-name>. <publisher-loc>Los Alamitos, CA, USA</publisher-loc>: <publisher-name>IEEE</publisher-name>; <year>2022</year>. p. <fpage>1286</fpage>&#x2013;<lpage>92</lpage>.</mixed-citation></ref>
<ref id="ref-35"><label>[35]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Du</surname> <given-names>MX</given-names></string-name>, <string-name><surname>Ma</surname> <given-names>XF</given-names></string-name>, <string-name><surname>Zhang</surname> <given-names>Z</given-names></string-name>, <string-name><surname>Wang</surname> <given-names>XW</given-names></string-name>, <string-name><surname>Chen</surname> <given-names>QJ</given-names></string-name></person-group>. <article-title>A review on consensus algorithm of blockchain</article-title>. In: <conf-name>2017 IEEE International Conference on Systems, Man, and Cybernetics (SMC)</conf-name>. <publisher-loc>Banff, AB, Canada</publisher-loc>: <publisher-name>IEEE</publisher-name>; <year>2017</year>. p. <fpage>2567</fpage>&#x2013;<lpage>72</lpage>.</mixed-citation></ref>
<ref id="ref-36"><label>[36]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Khan</surname> <given-names>D</given-names></string-name>, <string-name><surname>Jung</surname> <given-names>LT</given-names></string-name>, <string-name><surname>Hashmani</surname> <given-names>MA</given-names></string-name>, <string-name><surname>Waqas</surname> <given-names>A</given-names></string-name></person-group>. <article-title>A critical review of blockchain consensus model</article-title>. In: <conf-name>2020 3rd International Conference on Computing, Mathematics and Engineering Technologies (iCoMET)</conf-name>. <publisher-loc>Sukkur, Pakistan</publisher-loc>: <publisher-name>IEEE</publisher-name>; <year>2020</year>. p. <fpage>1</fpage>&#x2013;<lpage>6</lpage>.</mixed-citation></ref>
<ref id="ref-37"><label>[37]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Tenorio-Forn&#x00E9;s</surname> <given-names>A</given-names></string-name>, <string-name><surname>Jacynycz</surname> <given-names>V</given-names></string-name>, <string-name><surname>Llop-Vila</surname> <given-names>D</given-names></string-name>, <string-name><surname>S&#x00E1;nchez-Ruiz</surname> <given-names>A</given-names></string-name>, <string-name><surname>Hassan</surname> <given-names>S</given-names></string-name></person-group>. <article-title>Towards a decentralized process for scientific publication and peer review using blockchain and IPFS</article-title>. In: <conf-name>Proceedings of the 52nd Hawaii International Conference on System Sciences</conf-name>. <publisher-loc>Honolulu, HI, USA</publisher-loc>: <publisher-name>ScholarSpace</publisher-name>; <year>2019</year>.</mixed-citation></ref>
<ref id="ref-38"><label>[38]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Werth</surname> <given-names>J</given-names></string-name>, <string-name><surname>Berenjestanaki</surname> <given-names>MH</given-names></string-name>, <string-name><surname>Barzegar</surname> <given-names>HR</given-names></string-name>, <string-name><surname>El Ioini</surname> <given-names>N</given-names></string-name>, <string-name><surname>Pahl</surname> <given-names>C</given-names></string-name></person-group>. <article-title>A review of blockchain platforms based on the scalability, security and decentralization Trilemma</article-title>. In: <conf-name>Proceedings of the 25th International Conference on Enterprise Information Systems (ICEIS 2023)&#x2014;Volume 1</conf-name>; <year>2023</year>. p. <fpage>146</fpage>&#x2013;<lpage>55</lpage>.</mixed-citation></ref>
<ref id="ref-39"><label>[39]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Lashkari</surname> <given-names>B</given-names></string-name>, <string-name><surname>Musilek</surname> <given-names>P</given-names></string-name></person-group>. <article-title>A comprehensive review of blockchain consensus mechanisms</article-title>. <source>IEEE Access</source>. <year>2021</year>;<volume>9</volume>:<fpage>43620</fpage>&#x2013;<lpage>52</lpage>. doi:<pub-id pub-id-type="doi">10.1109/access.2021.3065880</pub-id>.</mixed-citation></ref>
<ref id="ref-40"><label>[40]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Aldoubaee</surname> <given-names>A</given-names></string-name>, <string-name><surname>Hassan</surname> <given-names>NH</given-names></string-name>, <string-name><surname>Rahim</surname> <given-names>FA</given-names></string-name></person-group>. <article-title>A systematic review on blockchain scalability</article-title>. <source>Int J Adv Comput Sci Appl</source>. <year>2023</year>;<volume>14</volume>(<issue>9</issue>):<fpage>774</fpage>&#x2013;<lpage>84</lpage>. doi:<pub-id pub-id-type="doi">10.14569/ijacsa.2023.0140981</pub-id>.</mixed-citation></ref>
<ref id="ref-41"><label>[41]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Xiong</surname> <given-names>H</given-names></string-name>, <string-name><surname>Chen</surname> <given-names>M</given-names></string-name>, <string-name><surname>Wu</surname> <given-names>C</given-names></string-name>, <string-name><surname>Zhao</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Yi</surname> <given-names>W</given-names></string-name></person-group>. <article-title>Research on progress of blockchain consensus algorithm: a review on recent progress of blockchain consensus algorithms</article-title>. <source>Future Internet</source>. <year>2022</year>;<volume>14</volume>(<issue>2</issue>):<fpage>47</fpage>. doi:<pub-id pub-id-type="doi">10.3390/fi14020047</pub-id>.</mixed-citation></ref>
<ref id="ref-42"><label>[42]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Deng</surname> <given-names>W</given-names></string-name>, <string-name><surname>Huang</surname> <given-names>T</given-names></string-name>, <string-name><surname>Wang</surname> <given-names>H</given-names></string-name></person-group>. <article-title>A review of the key technology in a blockchain building decentralized trust platform</article-title>. <source>Mathematics</source>. <year>2022</year>;<volume>11</volume>(<issue>1</issue>):<fpage>101</fpage>. doi:<pub-id pub-id-type="doi">10.3390/math11010101</pub-id>.</mixed-citation></ref>
<ref id="ref-43"><label>[43]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Luu</surname> <given-names>L</given-names></string-name>, <string-name><surname>Narayanan</surname> <given-names>V</given-names></string-name>, <string-name><surname>Zheng</surname> <given-names>C</given-names></string-name>, <string-name><surname>Baweja</surname> <given-names>K</given-names></string-name>, <string-name><surname>Gilbert</surname> <given-names>S</given-names></string-name>, <string-name><surname>Saxena</surname> <given-names>P</given-names></string-name></person-group>. <article-title>A secure sharding protocol for open blockchains</article-title>. In: <conf-name>Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security</conf-name>; <publisher-loc>New York, NY, USA</publisher-loc>; <year>2016</year>. p. <fpage>17</fpage>&#x2013;<lpage>30</lpage>.</mixed-citation></ref>
<ref id="ref-44"><label>[44]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Dang</surname> <given-names>H</given-names></string-name>, <string-name><surname>Dinh</surname> <given-names>TTA</given-names></string-name>, <string-name><surname>Loghin</surname> <given-names>D</given-names></string-name>, <string-name><surname>Chang</surname> <given-names>EC</given-names></string-name>, <string-name><surname>Lin</surname> <given-names>Q</given-names></string-name>, <string-name><surname>Ooi</surname> <given-names>BC</given-names></string-name></person-group>. <article-title>Towards scaling blockchain systems via sharding</article-title>. In: <conf-name>Proceedings of the 2019 International Conference on Management of Data. SIGMOD &#x2019;19</conf-name>. <publisher-loc>New York, NY, USA</publisher-loc>: <publisher-name>Association for Computing Machinery</publisher-name>; <year>2019</year>. p. <fpage>123</fpage>&#x2013;<lpage>40</lpage>.</mixed-citation></ref>
<ref id="ref-45"><label>[45]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Zamani</surname> <given-names>M</given-names></string-name>, <string-name><surname>Movahedi</surname> <given-names>M</given-names></string-name>, <string-name><surname>Raykova</surname> <given-names>M</given-names></string-name></person-group>. <article-title>RapidChain: scaling blockchain via full sharding</article-title>. In: <conf-name>Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security. CCS &#x2019;18</conf-name>. <publisher-loc>New York, NY, USA</publisher-loc>: <publisher-name>Association for Computing Machinery</publisher-name>; <year>2018</year>. p. <fpage>931</fpage>&#x2013;<lpage>48</lpage>. doi:<pub-id pub-id-type="doi">10.1145/3243734.3243853</pub-id>.</mixed-citation></ref>
<ref id="ref-46"><label>[46]</label><mixed-citation publication-type="book"><person-group person-group-type="author"><string-name><surname>Teutsch</surname> <given-names>J</given-names></string-name>, <string-name><surname>Reitwie&#x00DF;ner</surname> <given-names>C</given-names></string-name></person-group>. <chapter-title>A scalable verification solution for blockchains</chapter-title>. In: <source>Aspects of Computation and Automata Theory with Applications</source>. <publisher-loc>Singapore</publisher-loc>: <publisher-name>World Scientific</publisher-name>; <year>2024</year>. p. <fpage>377</fpage>&#x2013;<lpage>424</lpage>.</mixed-citation></ref>
<ref id="ref-47"><label>[47]</label><mixed-citation publication-type="other"><person-group person-group-type="author"><string-name><surname>Malavolta</surname> <given-names>G</given-names></string-name>, <string-name><surname>Moreno-Sanchez</surname> <given-names>P</given-names></string-name>, <string-name><surname>Schneidewind</surname> <given-names>C</given-names></string-name>, <string-name><surname>Kate</surname> <given-names>A</given-names></string-name>, <string-name><surname>Maffei</surname> <given-names>M</given-names></string-name></person-group>. <article-title>Anonymous multi-hop locks for blockchain scalability and interoperability. Cryptology ePrint Archive</article-title>; <year>2018</year>. [cited 2025 May 6]. Available from: <ext-link ext-link-type="uri" xlink:href="https://ia.cr/2018/472">https://ia.cr/2018/472</ext-link>.</mixed-citation></ref>
<ref id="ref-48"><label>[48]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Team</surname> <given-names>TB</given-names></string-name></person-group>. <article-title>Trifecta: the blockchain trilemma solved</article-title>. <source>White Paper</source>. <year>2019</year>. p. <fpage>1</fpage>&#x2013;<lpage>39</lpage>. [cited 2025 May 6]. Available from: <ext-link ext-link-type="uri" xlink:href="https://pramodv.ece.illinois.edu/pubs/Whitepaper2019-9.pdf">https://pramodv.ece.illinois.edu/pubs/Whitepaper2019-9.pdf</ext-link>.</mixed-citation></ref>
<ref id="ref-49"><label>[49]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Kokoris-Kogias</surname> <given-names>E</given-names></string-name>, <string-name><surname>Jovanovic</surname> <given-names>P</given-names></string-name>, <string-name><surname>Gasser</surname> <given-names>L</given-names></string-name>, <string-name><surname>Gailly</surname> <given-names>N</given-names></string-name>, <string-name><surname>Syta</surname> <given-names>E</given-names></string-name>, <string-name><surname>Ford</surname> <given-names>B</given-names></string-name></person-group>. <article-title>Omniledger: a secure, scale-out, decentralized ledger via sharding</article-title>. In: <conf-name>2018 IEEE Symposium on Security and Privacy (SP)</conf-name>. <publisher-loc>San Francisco, CA, USA</publisher-loc>: <publisher-name>IEEE</publisher-name>; <year>2018</year>. p. <fpage>583</fpage>&#x2013;<lpage>98</lpage>.</mixed-citation></ref>
<ref id="ref-50"><label>[50]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Diamantopoulos</surname> <given-names>G</given-names></string-name>, <string-name><surname>Bahsoon</surname> <given-names>R</given-names></string-name>, <string-name><surname>Tziritas</surname> <given-names>N</given-names></string-name>, <string-name><surname>Theodoropoulos</surname> <given-names>G</given-names></string-name></person-group>. <article-title>Symbchainsim: a novel simulation tool for dynamic and adaptive blockchain management and its trilemma tradeoff</article-title>. In: <conf-name>Proceedings of the 2023 ACM SIGSIM Conference on Principles of Advanced Discrete Simulation</conf-name>; <publisher-loc>New York, NY, USA</publisher-loc>; <year>2023</year>. p. <fpage>118</fpage>&#x2013;<lpage>27</lpage>.</mixed-citation></ref>
<ref id="ref-51"><label>[51]</label><mixed-citation publication-type="other"><person-group person-group-type="author"><string-name><surname>R&#x0131;fat &#x00D6;zy&#x0131;lmaz</surname> <given-names>K</given-names></string-name>, <string-name><surname>Patel</surname> <given-names>H</given-names></string-name>, <string-name><surname>Malik</surname> <given-names>A</given-names></string-name></person-group>. <article-title>Split-Scale: scaling bitcoin by partitioning the UTXO space</article-title>. <comment>arXiv:1809.08473.2018</comment>.</mixed-citation></ref>
<ref id="ref-52"><label>[52]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Li</surname> <given-names>W</given-names></string-name>, <string-name><surname>Sforzin</surname> <given-names>A</given-names></string-name>, <string-name><surname>Fedorov</surname> <given-names>S</given-names></string-name>, <string-name><surname>Karame</surname> <given-names>GO</given-names></string-name></person-group>. <article-title>Towards scalable and private industrial blockchains</article-title>. In: <conf-name>Proceedings of the ACM Workshop on Blockchain, Cryptocurrencies and Contracts. BCC &#x2019;17</conf-name>. <publisher-loc>New York, NY, USA</publisher-loc>: <publisher-name>Association for Computing Machinery</publisher-name>; <year>2017</year>. p. <fpage>9</fpage>&#x2013;<lpage>14</lpage>. doi:<pub-id pub-id-type="doi">10.1145/3055518.3055531</pub-id>.</mixed-citation></ref>
<ref id="ref-53"><label>[53]</label><mixed-citation publication-type="other"><person-group person-group-type="author"><string-name><surname>Zheng</surname> <given-names>J</given-names></string-name>, <string-name><surname>Zhao</surname> <given-names>S</given-names></string-name>, <string-name><surname>Wang</surname> <given-names>Z</given-names></string-name>, <string-name><surname>Pan</surname> <given-names>L</given-names></string-name>, <string-name><surname>Li</surname> <given-names>J</given-names></string-name></person-group>. <article-title>DCS Chain: a flexible private blockchain system</article-title>. <comment>arXiv:2406.12376.2024</comment>.</mixed-citation></ref>
<ref id="ref-54"><label>[54]</label><mixed-citation publication-type="book"><person-group person-group-type="author"><string-name><surname>Poon</surname> <given-names>J</given-names></string-name>, <string-name><surname>Dryja</surname> <given-names>T</given-names></string-name></person-group>. <source>The bitcoin lightning network: scalable off-chain instant payments (2016)</source>. <publisher-loc>Austin, TX, USA</publisher-loc>: <publisher-name>The Satoshi Nakamoto Institute</publisher-name>; <year>2016</year>.</mixed-citation></ref>
<ref id="ref-55"><label>[55]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Shafin</surname> <given-names>KM</given-names></string-name>, <string-name><surname>Trilemmaguard</surname> <given-names>Reno S</given-names></string-name></person-group>. <article-title>Safeguarding against the challenges posed by blockchain trilemma</article-title>. In: <conf-name>2023 26th International Conference on Computer and Information Technology (ICCIT)</conf-name>. <publisher-loc>Bangladesh</publisher-loc>: <publisher-name>Cox&#x2019;s Bazar</publisher-name>; <year>2023</year>. p. <fpage>1</fpage>&#x2013;<lpage>6</lpage>.</mixed-citation></ref>
<ref id="ref-56"><label>[56]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Md Shafin</surname> <given-names>K</given-names></string-name>, <string-name><surname>Reno</surname> <given-names>S</given-names></string-name></person-group>. <article-title>Breaking the blockchain trilemma: a comprehensive consensus mechanism for ensuring security, scalability, and decentralization</article-title>. <source>IET Softw</source>. <year>2024</year>;<volume>2024</volume>(<issue>1</issue>):<fpage>6874055</fpage>. doi:<pub-id pub-id-type="doi">10.1049/2024/6874055</pub-id>.</mixed-citation></ref>
<ref id="ref-57"><label>[57]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>He</surname> <given-names>G</given-names></string-name>, <string-name><surname>Su</surname> <given-names>W</given-names></string-name>, <string-name><surname>Chameleon</surname> <given-names>Gao S</given-names></string-name></person-group>. <article-title>A scalable and adaptive permissioned blockchain architecture</article-title>. In: <conf-name>2018 1st IEEE International Conference on Hot Information-Centric Networking (HotICN)</conf-name>. <publisher-loc>Shenzhen, China</publisher-loc>: <publisher-name>IEEE</publisher-name>; <year>2018</year>. p. <fpage>87</fpage>&#x2013;<lpage>93</lpage>.</mixed-citation></ref>
<ref id="ref-58"><label>[58]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Reno</surname> <given-names>S</given-names></string-name>, <string-name><surname>Haque</surname> <given-names>MM</given-names></string-name></person-group>. <article-title>Solving blockchain trilemma using off-chain storage protocol</article-title>. <source>IET Inform Sec</source>. <year>2023</year>;<volume>17</volume>(<issue>4</issue>):<fpage>681</fpage>&#x2013;<lpage>702</lpage>.</mixed-citation></ref>
<ref id="ref-59"><label>[59]</label><mixed-citation publication-type="other"><person-group person-group-type="author"><string-name><surname>Bayona Bult&#x00F3;</surname> <given-names>&#x00C1;</given-names></string-name></person-group>. <article-title>A comprehensive evaluation of ethereum, solana, and avalanche in addressing the blockchain trilemma</article-title>; <year>2023</year>. [cited 2025 May 6]. Available from: <ext-link ext-link-type="uri" xlink:href="https://repositorio.comillas.edu/xmlui/handle/11531/81462">https://repositorio.comillas.edu/xmlui/handle/11531/81462</ext-link>.</mixed-citation></ref>
<ref id="ref-60"><label>[60]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Quattrocchi</surname> <given-names>G</given-names></string-name>, <string-name><surname>Scaramuzza</surname> <given-names>F</given-names></string-name>, <string-name><surname>Tamburri</surname> <given-names>DA</given-names></string-name></person-group>. <article-title>The blockchain trilemma: an evaluation framework</article-title>. <source>IEEE Softw</source>. <year>2024</year>;<volume>41</volume>(<issue>6</issue>):<fpage>101</fpage>&#x2013;<lpage>10</lpage>. doi:<pub-id pub-id-type="doi">10.1109/ms.2024.3417341</pub-id>.</mixed-citation></ref>
<ref id="ref-61"><label>[61]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Pei</surname> <given-names>X</given-names></string-name>, <string-name><surname>Li</surname> <given-names>H</given-names></string-name>, <string-name><surname>Tan</surname> <given-names>S</given-names></string-name>, <string-name><surname>Huang</surname> <given-names>W</given-names></string-name>, <string-name><surname>Zhang</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Matching-Gossip</surname> <given-names>Wang H</given-names></string-name></person-group>. <article-title>Optimizing blockchain broadcast performance to address the CAP trilemma</article-title>. In: <conf-name>2024 6th International Conference on Blockchain Computing and Applications (BCCA)</conf-name>. <publisher-loc>Dubai, United Arab Emirates</publisher-loc>: <publisher-name>IEEE</publisher-name>; <year>2024</year>. p. <fpage>263</fpage>&#x2013;<lpage>70</lpage>.</mixed-citation></ref>
<ref id="ref-62"><label>[62]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Wang</surname> <given-names>Q</given-names></string-name>, <string-name><surname>Xu</surname> <given-names>M</given-names></string-name>, <string-name><surname>Yang</surname> <given-names>Y</given-names></string-name></person-group>. <article-title>Time-beacon beats blockchain trilemma</article-title>. <source>Tsinghua Sci Technol</source>. <year>2024</year>; <fpage>1</fpage>&#x2013;<lpage>13</lpage>. doi:<pub-id pub-id-type="doi">10.26599/tst.2024.9010136</pub-id>.</mixed-citation></ref>
<ref id="ref-63"><label>[63]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Sanka</surname> <given-names>AI</given-names></string-name>, <string-name><surname>Cheung</surname> <given-names>RC</given-names></string-name></person-group>. <article-title>Efficient high performance FPGA based NoSQL caching system for blockchain scalability and throughput improvement</article-title>. In: <conf-name>2018 26th International Conference on Systems Engineering (ICSEng)</conf-name>. <publisher-loc>Sydney, NSW, Australia</publisher-loc>: <publisher-name>IEEE</publisher-name>; <year>2018</year>. p. <fpage>1</fpage>&#x2013;<lpage>8</lpage>.</mixed-citation></ref>
<ref id="ref-64"><label>[64]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>van der Heijden</surname> <given-names>RW</given-names></string-name>, <string-name><surname>Engelmann</surname> <given-names>F</given-names></string-name>, <string-name><surname>M&#x00F6;dinger</surname> <given-names>D</given-names></string-name>, <string-name><surname>Sch&#x00F6;nig</surname> <given-names>F</given-names></string-name>, <string-name><surname>Kargl</surname> <given-names>F</given-names></string-name></person-group>. <article-title>Scalability for resource-constrained accountable vehicle-to-x communication</article-title>. In: <conf-name>Proceedings of the 1st Workshop on Scalable and Resilient Infrastructures for Distributed Ledgers</conf-name>; <publisher-loc>New York, NY, USA</publisher-loc>; <year>2017</year>. p. <fpage>1</fpage>&#x2013;<lpage>5</lpage>.</mixed-citation></ref>
<ref id="ref-65"><label>[65]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Kuzmanovic</surname> <given-names>A</given-names></string-name></person-group>. <article-title>Net neutrality: unexpected solution to blockchain scaling</article-title>. <source>Commun ACM</source>. <year>2019 Apr</year>;<volume>62</volume>(<issue>5</issue>):<fpage>50</fpage>&#x2013;<lpage>5</lpage>. doi:<pub-id pub-id-type="doi">10.1145/3312525</pub-id>.</mixed-citation></ref>
<ref id="ref-66"><label>[66]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Hasnaoui</surname> <given-names>I</given-names></string-name>, <string-name><surname>Zrikem</surname> <given-names>M</given-names></string-name>, <string-name><surname>Elassali</surname> <given-names>R</given-names></string-name></person-group>. <article-title>Beyond the bug bounty programs trilemma: Bounty 3.0&#x2019;s blockchain-ZKP approach</article-title>. In: <conf-name>2023 7th IEEE Congress on Information Science and Technology (CiSt)</conf-name>. <publisher-loc>Agadir-Essaouira, Morocco</publisher-loc>: <publisher-name>IEEE</publisher-name>; <year>2023</year>. p. <fpage>663</fpage>&#x2013;<lpage>8</lpage>. doi:<pub-id pub-id-type="doi">10.1109/cist56084.2023.10409942</pub-id>.</mixed-citation></ref>
<ref id="ref-67"><label>[67]</label><mixed-citation publication-type="other"><person-group person-group-type="author"><string-name><surname>Principato</surname> <given-names>M</given-names></string-name>, <string-name><surname>Babel</surname> <given-names>M</given-names></string-name>, <string-name><surname>Guggenberger</surname> <given-names>T</given-names></string-name>, <string-name><surname>Kropp</surname> <given-names>J</given-names></string-name>, <string-name><surname>Mertel</surname> <given-names>S</given-names></string-name></person-group>. <article-title>Towards solving the blockchain trilemma: an exploration of zero-knowledge proofs</article-title>; <year>2023</year>. [cited 2025 May 6]. Available from: <ext-link ext-link-type="uri" xlink:href="https://core.ac.uk/download/pdf/590878837.pdf">https://core.ac.uk/download/pdf/590878837.pdf</ext-link>.</mixed-citation></ref>
<ref id="ref-68"><label>[68]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>McConaghy</surname> <given-names>T</given-names></string-name>, <string-name><surname>Marques</surname> <given-names>R</given-names></string-name>, <string-name><surname>M&#x00FC;ller</surname> <given-names>A</given-names></string-name>, <string-name><surname>De Jonghe</surname> <given-names>D</given-names></string-name>, <string-name><surname>McConaghy</surname> <given-names>T</given-names></string-name>, <string-name><surname>McMullen</surname> <given-names>G</given-names></string-name>, <etal>et al</etal></person-group>. <article-title>Bigchaindb: a scalable blockchain database</article-title>. <source>white paper, BigChainDB</source>. <year>2016</year>. p. <fpage>53</fpage>&#x2013;<lpage>72</lpage>. [cited 2025 May 6]. Available from: <ext-link ext-link-type="uri" xlink:href="https://gamma.bigchaindb.com/whitepaper/bigchaindb-whitepaper.pdf">https://gamma.bigchaindb.com/whitepaper/bigchaindb-whitepaper.pdf</ext-link>.</mixed-citation></ref>
<ref id="ref-69"><label>[69]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Al-Kafi</surname> <given-names>GA</given-names></string-name>, <string-name><surname>Ali</surname> <given-names>G</given-names></string-name>, <string-name><surname>Faiza</surname> <given-names>JT</given-names></string-name>, <string-name><surname>Pal</surname> <given-names>KR</given-names></string-name>, <string-name><surname>Reno</surname> <given-names>S</given-names></string-name></person-group>. <article-title>SHBF: a secure and scalable hybrid blockchain framework for resolving trilemma challenges</article-title>. <source>Int J Inform Technol</source>. <year>2024</year>;<volume>16</volume>(<issue>6</issue>):<fpage>3879</fpage>&#x2013;<lpage>90</lpage>. doi:<pub-id pub-id-type="doi">10.1007/s41870-024-01897-9</pub-id>.</mixed-citation></ref>
<ref id="ref-70"><label>[70]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Kan</surname> <given-names>L</given-names></string-name>, <string-name><surname>Wei</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Muhammad</surname> <given-names>AH</given-names></string-name>, <string-name><surname>Siyuan</surname> <given-names>W</given-names></string-name>, <string-name><surname>Gao</surname> <given-names>LC</given-names></string-name>, <string-name><surname>Kai</surname> <given-names>H</given-names></string-name></person-group>. <article-title>A multiple blockchains architecture on inter-blockchain communication</article-title>. In: <conf-name>2018 IEEE International Conference on Software Quality, Reliability and Security Companion (QRS-C)</conf-name>. <publisher-loc>Lisbon, Portugal</publisher-loc>: <publisher-name>IEEE</publisher-name>; <year>2018</year>. p. <fpage>139</fpage>&#x2013;<lpage>45</lpage>.</mixed-citation></ref>
<ref id="ref-71"><label>[71]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Alsamhi</surname> <given-names>SH</given-names></string-name>, <string-name><surname>Myrzashova</surname> <given-names>R</given-names></string-name>, <string-name><surname>Hawbani</surname> <given-names>A</given-names></string-name>, <string-name><surname>Kumar</surname> <given-names>S</given-names></string-name>, <string-name><surname>Srivastava</surname> <given-names>S</given-names></string-name>, <string-name><surname>Zhao</surname> <given-names>L</given-names></string-name>, <etal>et al</etal></person-group>. <article-title>Federated learning meets blockchain in decentralized data-sharing: healthcare use case</article-title>. <source>IEEE Internet Things J</source>. <year>2024</year>;<volume>11</volume>(<issue>11</issue>):<fpage>19602</fpage>&#x2013;<lpage>15</lpage>. doi:<pub-id pub-id-type="doi">10.1109/jiot.2024.3367249</pub-id>.</mixed-citation></ref>
<ref id="ref-72"><label>[72]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Nakai</surname> <given-names>T</given-names></string-name>, <string-name><surname>Sakurai</surname> <given-names>A</given-names></string-name>, <string-name><surname>Hironaka</surname> <given-names>S</given-names></string-name>, <string-name><surname>Shudo</surname> <given-names>K</given-names></string-name></person-group>. <article-title>The blockchain trilemma described by a formula</article-title>. In: <conf-name>2023 IEEE International Conference on Blockchain (Blockchain)</conf-name>. <publisher-loc>Danzhou, China</publisher-loc>: <publisher-name>IEEE</publisher-name>; <year>2023</year>. p. <fpage>41</fpage>&#x2013;<lpage>6</lpage>.</mixed-citation></ref>
<ref id="ref-73"><label>[73]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Nakai</surname> <given-names>T</given-names></string-name>, <string-name><surname>Sakurai</surname> <given-names>A</given-names></string-name>, <string-name><surname>Hironaka</surname> <given-names>S</given-names></string-name>, <string-name><surname>Shudo</surname> <given-names>K</given-names></string-name></person-group>. <article-title>A fFormulation of the trilemma in proof of work blockchain</article-title>. <source>IEEE Access</source>. <year>2024</year>;<volume>12</volume>(<issue>8</issue>):<fpage>80559</fpage>&#x2013;<lpage>78</lpage>. doi:<pub-id pub-id-type="doi">10.1109/access.2024.3410025</pub-id>.</mixed-citation></ref>
<ref id="ref-74"><label>[74]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Monte</surname> <given-names>GD</given-names></string-name>, <string-name><surname>Pennino</surname> <given-names>D</given-names></string-name>, <string-name><surname>Pizzonia</surname> <given-names>M</given-names></string-name></person-group>. <article-title>Scaling blockchains without giving up decentralization and security: a solution to the blockchain scalability trilemma</article-title>. In: <conf-name>Proceedings of the 3rd Workshop on Cryptocurrencies and Blockchains for Distributed Systems</conf-name>; <publisher-loc>New York, NY, USA</publisher-loc>. <year>2020</year>. p. <fpage>71</fpage>&#x2013;<lpage>6</lpage>.</mixed-citation></ref>
<ref id="ref-75"><label>[75]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Fujihara</surname> <given-names>A</given-names></string-name></person-group>. <article-title>Mathematical modelling of dual-layer byzantine fault-tolerant consensus process for optimal sharding and mitigation of blockchain trilemma</article-title>. In: <conf-name>2024 6th Conference on Blockchain Research &#x0026; Applications for Innovative Networks and Services (BRAINS)</conf-name>. <publisher-loc>Berlin, Germany</publisher-loc>: <publisher-name>IEEE</publisher-name>; <year>2024</year>. p. <fpage>1</fpage>&#x2013;<lpage>10</lpage>.</mixed-citation></ref>
<ref id="ref-76"><label>[76]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Chaudhary</surname> <given-names>M</given-names></string-name>, <string-name><surname>Bhunia</surname> <given-names>S</given-names></string-name></person-group>. <article-title>Understanding blockchain trilemma, causes and solutions</article-title>. In: <conf-name>2024 IEEE International Conferences on Internet of Things (iThings) and IEEE Green Computing &#x0026; Communications (GreenCom) and IEEE Cyber, Physical &#x0026; Social Computing (CPSCom) and IEEE Smart Data (SmartData) and IEEE Congress on Cybermatics</conf-name>. <publisher-name>IEEE</publisher-name>; <year>2024</year>. p. <fpage>609</fpage>&#x2013;<lpage>16</lpage>.</mixed-citation></ref>
<ref id="ref-77"><label>[77]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Zhang</surname> <given-names>K</given-names></string-name>, <string-name><surname>Jacobsen</surname> <given-names>HA</given-names></string-name></person-group>. <article-title>Towards dependable, scalable, and pervasive distributed ledgers with blockchains</article-title>. In: <conf-name>2018 IEEE 38th International Conference on Distributed Computing Systems (ICDCS)</conf-name>; <publisher-loc>Vienna, Austria</publisher-loc>. <year>2018</year>. p. <fpage>1337</fpage>&#x2013;<lpage>46</lpage>.</mixed-citation></ref>
<ref id="ref-78"><label>[78]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Yoo</surname> <given-names>S</given-names></string-name></person-group>. <article-title>Comparative analysis of blockchain trilemma</article-title>. <source>Int J Adv Smart Converg</source>. <year>2023</year>;<volume>12</volume>(<issue>1</issue>):<fpage>41</fpage>&#x2013;<lpage>52</lpage>.</mixed-citation></ref>
<ref id="ref-79"><label>[79]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Fu</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Jing</surname> <given-names>M</given-names></string-name>, <string-name><surname>Zhou</surname> <given-names>J</given-names></string-name>, <string-name><surname>Wu</surname> <given-names>P</given-names></string-name>, <string-name><surname>Wang</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Zhang</surname> <given-names>L</given-names></string-name>, <etal>et al</etal></person-group>. <article-title>Quantifying the blockchain trilemma: a comparative analysis of Algorand, Ethereum 2.0, and beyond</article-title>. In: <conf-name>2024 IEEE International Conference on Metaverse Computing, Networking, and Applications (MetaCom)</conf-name>. <publisher-loc>Hong Kong, China</publisher-loc>: <publisher-name>IEEE</publisher-name>; <year>2024</year>. p. <fpage>97</fpage>&#x2013;<lpage>104</lpage>.</mixed-citation></ref>
<ref id="ref-80"><label>[80]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Politou</surname> <given-names>E</given-names></string-name>, <string-name><surname>Casino</surname> <given-names>F</given-names></string-name>, <string-name><surname>Alepis</surname> <given-names>E</given-names></string-name>, <string-name><surname>Patsakis</surname> <given-names>C</given-names></string-name></person-group>. <article-title>Blockchain mutability: challenges and proposed solutions</article-title>. <source>IEEE Trans Emerg Topics Comput</source>. <year>2019</year>;<volume>9</volume>(<issue>4</issue>):<fpage>1972</fpage>&#x2013;<lpage>86</lpage>. doi:<pub-id pub-id-type="doi">10.1109/tetc.2019.2949510</pub-id>.</mixed-citation></ref>
<ref id="ref-81"><label>[81]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Umrao</surname> <given-names>LS</given-names></string-name>, <string-name><surname>Patel</surname> <given-names>SC</given-names></string-name>, <string-name><surname>Kumar</surname> <given-names>S</given-names></string-name></person-group>. <article-title>Blockchain-based reliable framework for land registration information system</article-title>. <source>Int J Technol Diffusion (IJTD)</source>. <year>2022</year>;<volume>13</volume>(<issue>1</issue>):<fpage>1</fpage>&#x2013;<lpage>16</lpage>. doi:<pub-id pub-id-type="doi">10.4018/ijtd.300743</pub-id>.</mixed-citation></ref>
<ref id="ref-82"><label>[82]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Conti</surname> <given-names>M</given-names></string-name>, <string-name><surname>Gangwal</surname> <given-names>A</given-names></string-name>, <string-name><surname>Todero</surname> <given-names>M</given-names></string-name></person-group>. <article-title>Blockchain trilemma solver algorand has dilemma over undecidable messages</article-title>. In: <conf-name>Proceedings of the 14th International Conference on Availability, Reliability and Security</conf-name>; <publisher-loc>New York, NY, USA</publisher-loc>. <year>2019</year>. p. <fpage>1</fpage>&#x2013;<lpage>8</lpage>.</mixed-citation></ref>
<ref id="ref-83"><label>[83]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Parashar</surname> <given-names>D</given-names></string-name>, <string-name><surname>Sharma</surname> <given-names>M</given-names></string-name>, <string-name><surname>Sharma</surname> <given-names>V</given-names></string-name>, <string-name><surname>Nand</surname> <given-names>P</given-names></string-name></person-group>. <article-title>Approaching solutions to blockchain security trilemma and consensus mechanisms</article-title>. In: <conf-name>2022 4th International Conference on Advances in Computing, Communication Control and Networking (ICAC3N)</conf-name>. <publisher-loc>Greater Noida, India</publisher-loc>: <publisher-name>IEEE</publisher-name>; <year>2022</year>. p. <fpage>2030</fpage>&#x2013;<lpage>6</lpage>.</mixed-citation></ref>
<ref id="ref-84"><label>[84]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Boumaiza</surname> <given-names>A</given-names></string-name></person-group>. <article-title>A blockchain-based scalability solution with microgrids peer-to-peer trade</article-title>. <source>Energies</source>. <year>2024</year>;<volume>17</volume>(<issue>4</issue>):<fpage>915</fpage>. doi:<pub-id pub-id-type="doi">10.3390/en17040915</pub-id>.</mixed-citation></ref>
<ref id="ref-85"><label>[85]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Danezis</surname> <given-names>G</given-names></string-name>, <string-name><surname>Kokoris-Kogias</surname> <given-names>L</given-names></string-name>, <string-name><surname>Sonnino</surname> <given-names>A</given-names></string-name>, <string-name><surname>Spiegelman</surname> <given-names>A</given-names></string-name></person-group>. <article-title>Narwhal and tusk: a dag-based mempool and efficient bft consensus</article-title>. In: <conf-name>Proceedings of the Seventeenth European Conference on Computer Systems</conf-name>. <publisher-loc>New York, NY, USA</publisher-loc>; <year>2022</year>. p. <fpage>34</fpage>&#x2013;<lpage>50</lpage>.</mixed-citation></ref>
<ref id="ref-86"><label>[86]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Arafat</surname> <given-names>SM</given-names></string-name></person-group>. <article-title>A study of blockchain consensus protocols</article-title>. <source>Cryptol ePrint Arch</source>. <year>2025</year>. doi:<pub-id pub-id-type="doi">10.13140/RG.2.2.36030.50243</pub-id>.</mixed-citation></ref>
<ref id="ref-87"><label>[87]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Yakovenko</surname> <given-names>A</given-names></string-name></person-group>. <article-title>Solana: a new architecture for a high performance blockchain v0. 8.13</article-title>. <source>Whitepaper</source>. <year>2018</year>. p. <fpage>1</fpage>&#x2013;<lpage>32</lpage>. [cited 2025 May 6]. Available from: <ext-link ext-link-type="uri" xlink:href="https://coincode-live.github.io/static/whitepaper/source001/10608577.pdf">https://coincode-live.github.io/static/whitepaper/source001/10608577.pdf</ext-link>.</mixed-citation></ref>
<ref id="ref-88"><label>[88]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Wang</surname> <given-names>R</given-names></string-name>, <string-name><surname>Ma</surname> <given-names>F</given-names></string-name>, <string-name><surname>Tang</surname> <given-names>S</given-names></string-name>, <string-name><surname>Zhang</surname> <given-names>H</given-names></string-name>, <string-name><surname>He</surname> <given-names>J</given-names></string-name>, <string-name><surname>Su</surname> <given-names>Z</given-names></string-name>, <etal>et al</etal></person-group>. <article-title>Parallel Byzantine fault tolerance consensus based on trusted execution environments</article-title>. <source>Peer Peer Netw Appl</source>. <year>2025</year>;<volume>18</volume>(<issue>1</issue>):<fpage>1</fpage>&#x2013;<lpage>24</lpage>. doi:<pub-id pub-id-type="doi">10.1007/s12083-024-01830-8</pub-id>.</mixed-citation></ref>
<ref id="ref-89"><label>[89]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Li</surname> <given-names>W</given-names></string-name>, <string-name><surname>Andreina</surname> <given-names>S</given-names></string-name>, <string-name><surname>Bohli</surname> <given-names>JM</given-names></string-name>, <string-name><surname>Karame</surname> <given-names>G</given-names></string-name></person-group>. <article-title>Securing proof-of-stake blockchain protocols</article-title>. In: <conf-name>Data Privacy Management, Cryptocurrencies and Blockchain Technology: ESORICS 2017 International Workshops, DPM 2017 and CBT 2017</conf-name>; <year>2017 Sep 14&#x2013;15</year>; <publisher-loc>Oslo, Norway</publisher-loc>: <publisher-name>Springer; 2017</publisher-name>. p. <fpage>297</fpage>&#x2013;<lpage>315</lpage>.</mixed-citation></ref>
<ref id="ref-90"><label>[90]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Hoffman</surname> <given-names>A</given-names></string-name>, <string-name><surname>Becerril-Blas</surname> <given-names>E</given-names></string-name>, <string-name><surname>Moreno</surname> <given-names>K</given-names></string-name>, <string-name><surname>Kim</surname> <given-names>Y</given-names></string-name></person-group>. <article-title>Decentralized security bounty management on blockchain and IPFS</article-title>. In: <conf-name>2020 10th Annual Computing and Communication Workshop and Conference (CCWC)</conf-name>. <publisher-loc>Las Vegas, NV, USA</publisher-loc>: <publisher-name>IEEE</publisher-name>; <year>2020</year>. p. <fpage>241</fpage>&#x2013;<lpage>7</lpage>.</mixed-citation></ref>
<ref id="ref-91"><label>[91]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><surname>Uzougbo</surname> <given-names>NS</given-names></string-name>, <string-name><surname>Ikegwu</surname> <given-names>CG</given-names></string-name>, <string-name><surname>Adewusi</surname> <given-names>AO</given-names></string-name></person-group>. <article-title>Regulatory frameworks for decentralized finance (DEFI): challenges and opportunities</article-title>. <source>GSC Adv Res Rev</source>. <year>2024</year>;<volume>19</volume>(<issue>2</issue>):<fpage>116</fpage>&#x2013;<lpage>29</lpage>. doi:<pub-id pub-id-type="doi">10.30574/gscarr.2024.19.2.0170</pub-id>.</mixed-citation></ref>
<ref id="ref-92"><label>[92]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><surname>Malavolta</surname> <given-names>G</given-names></string-name>, <string-name><surname>Moreno-Sanchez</surname> <given-names>P</given-names></string-name>, <string-name><surname>Schneidewind</surname> <given-names>C</given-names></string-name>, <string-name><surname>Kate</surname> <given-names>A</given-names></string-name>, <string-name><surname>Maffei</surname> <given-names>M</given-names></string-name></person-group>. <article-title>Anonymous multi-hop locks for blockchain privacy</article-title>. In: <conf-name>2018 IEEE Symposium on Security and Privacy (SP)</conf-name>. <publisher-loc>Singapore</publisher-loc>: <publisher-name>IEEE</publisher-name>; <year>2018</year>. p. <fpage>614</fpage>&#x2013;<lpage>31</lpage>.</mixed-citation></ref>
<ref id="ref-93"><label>[93]</label><mixed-citation publication-type="other"><person-group person-group-type="author"><string-name><surname>Teutsch</surname> <given-names>J</given-names></string-name>, <string-name><surname>Reitwie&#x00DF;ner</surname> <given-names>C</given-names></string-name></person-group>. <article-title>TrueBit: a scalable verification solution for blockchains</article-title>; <year>2024</year>. [cited 2025 May 18]. Available from: <ext-link ext-link-type="uri" xlink:href="https://truebit.io/whitepaper.pdf">https://truebit.io/whitepaper.pdf</ext-link>.</mixed-citation></ref>
</ref-list>
</back></article>

















