Redefining Hybrid Blockchains: A Balanced Architecture

Syed Ibrahim Omer

REVIEW 4 major objections 5 minor 19 references

Redefining Hybrid Blockchains: A Balanced Architecture

T0 review · 4 major / 5 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A semi-centralized hybrid blockchain that splits consensus from networking can exceed 1000 transactions per second on a consumer laptop, with median finality of 2.2 seconds.

desk verdict A genuinely implemented hybrid-chain proof-of-concept whose 'over 1000 TPS' headline is block-consensus throughput, not end-to-end throughput; the paper is honest about this in the body but not in the abstract. read the letter →

arxiv 2504.18966 v1 pith:OK5L7GJE submitted 2025-04-26 cs.CR cs.DC

Syed Ibrahim Omer This is my paper · ORCID

classification cs.CRcs.DC

keywords hybridblockchainsemi-centralizedarchitectureKafkapub-subKubernetesdeploymentPBFTconsensustransactionthroughputtimetofinalitystake-basedvalidatorselection

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper aims to establish that a semi-centralized hybrid blockchain—decentralized validators running PBFT consensus, with a master node governing all communication through a Kafka pub-sub middleware—can break the usual trade-off between scalability, governance, and decentralization that has kept blockchains out of government and enterprise use. If the architecture works as claimed, a single hosting entity can operate a network that reaches over 1000 transactions per second (average block throughput of 1030 TPS), finalizes transactions in a median 2.2 seconds, and synchronizes nodes in about 43 milliseconds, even on a constrained laptop. The design matters because earlier hybrid solutions are improvised merges of public and private chains, which create performance bottlenecks or governance gaps; this architecture makes the balance a foundational property instead of a patch.

What carries the argument

The load-bearing mechanism is the separation of consensus and networking into two independently scalable layers joined by a Kafka pub-sub middleware. Validator nodes run a Practical Byzantine Fault Tolerance (PBFT) consensus among themselves, while a master node mediates all inter-node communication through Kafka, authenticates participants, and selects validators for each round using stake-weighted randomness. Containerized microservices on Kubernetes give each layer fault isolation and independent deployability, and the resulting linear $O(n)$ (or $O(bn)$) network complexity is what allows the architecture to claim scalable throughput without the quadratic messaging cost of peer-to-peer connectivity.

What would settle it

Deploy the same containerized services on at least three geographically separated machines connected by a wide-area network with realistic bandwidth limits and a three-broker Kafka cluster, then measure block throughput and time-to-finality as the validator count grows from 1 to 4 to 16; if throughput falls below 1000 TPS or degrades by more than a few percent per added validator, the claimed scaling consistency would be refuted.

Watch

Extended reading notes

Core claim

The central claim is that replacing peer-to-peer communication with a Kafka-mediated hub-and-spoke network, and separating the network protocol (owned by a centralized master node) from the consensus protocol (owned by decentralized validator nodes), yields a blockchain that is scalable, governable, and economically viable. The paper supports this with a proof-of-concept deployment on Kubernetes: average block throughput of 1030 transactions per second, median time to finality of 2.2 seconds, and synchronization time of 43 milliseconds across scaled deployments of 1, 3, and 4 validators. It also argues that network complexity drops from $O(n^2)$ in a full peer-to-peer mesh to roughly $O(n)$ here, and that the master node can break staking monopolies, addressing a governance failure of pure proof-of-stake. The paper is explicit that the implementation is a proof-of-concept, not a production-ready system.

Load-bearing premise

The scalability conclusion rests on the assumption that running 1, 3, and 4 validator nodes on one laptop, with a single Kafka broker and one run per deployment, measures the architecture's real distributed scaling behavior; if actual network latency, bandwidth limits, and multi-broker fault tolerance change the results, the 'consistent performance across scaled deployments' claim is unsupported.

Editorial extensions

If this is right

If the measured 1030 TPS and 2.2-second finality carry over to real deployments, enterprise and government chains could handle payment-scale transaction loads while keeping data governance local.
The layer separation means consensus can scale by onboarding third-party validators while the host only scales the networking layer, shifting most infrastructure cost off the host.
The hub-and-spoke topology turns the network from $O(n^2)$ to roughly $O(n)$ traffic, so the architecture's relative efficiency over a peer-to-peer network grows as the validator set grows.
A master node empowered to break stake monopolies is presented as a governance remedy that pure proof-of-stake lacks, though it introduces a trusted-party role.
The measured bottlenecks (transaction pooling at ~412 TPS and Merkle-root hashing in the pre-prepare and prepare phases) point to parallel processing as the clear next step for higher throughput.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The 1030 TPS figure is the block-consensus ceiling; the transaction pool itself processed at ~412 TPS, so a user-facing deployment would likely quote the lower number until pooling is parallelized.
Because all deployments ran on one laptop with a single Kafka broker and one run per configuration, 'consistent performance across scaled deployments' is better read as evidence of resource isolation than as a distributed-scaling guarantee; a wide-area, multi-broker test is the natural follow-up.
The security and fault-tolerance arguments are qualitative and untested; the master node is a trusted party with the power to censor or reorder transactions, so the decentralization claim hinges on accepting this governance role.
If even part of the throughput survives a multi-host, multi-broker deployment, the networking pattern is protocol-agnostic and could be applied to other consensus algorithms beyond PBFT.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Here's the short version: this is a real proof-of-concept for a hybrid blockchain with a Kafka-mediated network layer, PBFT consensus, and a master node that controls validator selection. The abstract says it achieves over 1000 TPS. The paper's own body says that is block-creation TPS for the consensus phase, while the transaction pool processes about 412 TPS. So the headline is a component metric being presented as system throughput. That is the biggest problem, and it is fixable.

The authors are honest elsewhere. Section 5.1 explicitly says security, fault tolerance, and economic incentives are out of scope. Section 5.6 lists the single-broker Kafka, the local laptop, and the missing geographic distribution. The numbers are internally consistent, the code is on GitHub, and the experimental method is standard for a proof-of-concept. The integration of known components into a master-governed, microservices-based chain is new in the literature, even if no single component is new.

Where the paper is soft: the scalability conclusion rests on three deployments (1, 3, and 4 nodes) on one laptop, one run each, no error bars, and one Kafka broker. That is thin, but the paper cautions against overreading it. The more serious issue is metric mislabeling. With 512-transaction blocks and median time-to-finality of 2.2 seconds, a serial pipeline gives at most about 230 user-visible TPS, and even a pipelined version cannot exceed the roughly 410 TPS pool rate. The Visa and PayPal comparison in Section 7.3 uses block TPS, which is misleading. The abstract's claims about security and economic viability are neither tested nor formally argued; Section 4 is qualitative and plausible, but it is not evidence.

Nothing here is circular: there are no fitted parameters, and the experiment directly tests the implementation. The theoretical O(n) versus O(n^2) network complexity argument is simplified but directionally reasonable.

Who this is for: people working on permissioned or hybrid blockchain architectures, especially those interested in Kafka as a consensus transport. It is not a theoretical contribution and not a rigorous benchmark paper, but it is a useful data point on what a single-laptop Kubernetes setup can do.

Recommendation: this deserves a serious referee, not a desk reject. The right outcome is major revision: rescope the abstract and title to describe block-consensus throughput, report end-to-end and pool TPS prominently, add repeated runs and more nodes if possible, and move security and economic-viability claims to future work. If you are the editor, send it out. If you are the referee, do not let the headline stand.

Referee Report

4 major / 5 minor

Summary. The paper proposes a hybrid blockchain architecture that combines a centralized master node and Kafka pub-sub middleware with a decentralized set of validator nodes running PBFT consensus, deployed as containerized microservices on Kubernetes. The authors report a proof-of-concept evaluation on a consumer-grade laptop with three deployments (1, 3, and 4 validator nodes), claiming an average block throughput of 1030 transactions per second, a median time to finality of 2.2 seconds, and a synchronization time of 43 ms. They further claim that performance is consistent across scaled deployments and that the architecture offers improved scalability, governance, and economic viability. The evaluation is explicitly scoped to scalability and performance; security, fault tolerance, and economic incentives are discussed theoretically but not comprehensively tested.

Significance. If the claims were properly scoped, this paper would be a modest but useful proof-of-concept: it demonstrates that a Kafka-based, microservice-oriented blockchain can achieve moderate consensus-phase throughput on commodity hardware, and it openly enumerates limitations. Strengths include the public availability of the implementation on GitHub, the use of Rust for performance-sensitive components, and a clear separation of consensus and networking concerns. However, the headline 'over 1000 TPS' is a component-level metric (Block TPS as defined in §5.5), not end-to-end user-visible throughput, and the scalability evidence is based on only three local deployments with no repeated runs or variance estimates. The novelty relative to prior permissioned designs such as Hyperledger Fabric's Kafka-based ordering service is incremental. The paper's main value is as a starting point for a more rigorous evaluation rather than as a demonstration of the strong system-level claims made in the abstract.

major comments (4)

[Abstract, §5.5, §6.1, Table 6.1] The central claim of 'over 1000 transactions per second' is Block TPS, defined in §5.5 as the rate for block creation and consensus only, not end-to-end throughput. Table 6.1 reports Pool TPS around 406-409, and §6.4 states that transaction pooling and processing consumes roughly 83% of total processing time. A serial block pipeline with 512-transaction blocks and a median time to finality of 2.2 seconds yields at most about 230 user-visible TPS, and even an optimized pipeline is bounded by the roughly 410 TPS pool rate. The abstract and the Visa/PayPal comparison in §7.3 treat the 1030 TPS figure as system throughput, which overstates the architecture's end-to-end performance and makes the comparison non-apples-to-apples.
[§5.3, §5.6, Table 6.2, §6.5] The scalability conclusion rests on three deployments (1, 3, and 4 validator nodes) running on a single laptop with one Kafka broker, no repeated runs, and no reported error bars or confidence intervals. Section 5.6 explicitly acknowledges the absence of geographic distribution, bandwidth limits, high-latency links, multi-broker fault tolerance, and true parallelism. The percentage changes in Table 6.2 therefore cannot support the abstract's 'consistent performance across scaled deployments'; moreover, §6.5 itself reports a decreasing trend in block throughput and increasing variability as node count grows, which further weakens the consistency claim.
[§4.2] The theoretical complexity comparison assumes a peer-to-peer network in which every node is connected to every other node, resulting in O(n^2) complexity. Realistic P2P blockchains such as Tendermint use gossip-based or partial-mesh overlays with subquadratic message complexity, so the O(n^2) baseline is a strawman. The claimed linear-scaling advantage of the proposed architecture over P2P networks is not established by this argument, and the paper does not test the architecture at node counts where the difference would matter.
[Abstract, §5.1, §8.3] The abstract states that the findings highlight the system's scalability, security, and economic viability, but §5.1 explicitly restricts the evaluation to scalability and performance and states that comprehensive testing of security, fault tolerance, and economic incentives is out of scope. §8.3 lists these as future work. Consequently, the security-related claims in §3.5 and §4.1 (e.g., Sybil and 51% attack resistance, master-node monopoly breaking) are untested, and the abstract overstates the scope of evidence provided.

minor comments (5)

[Abstract, §6.5, §6.7] The abstract claims 'consistent performance across scaled deployments,' but §6.5 reports that the median block throughput decreases as node count increases and that variability grows with more nodes. Please reconcile this wording with the data in §6.5 and Table 6.2.
[§6.7, Table 6.2] Section 6.7 states that 'most of the metrics have been affected by less than 1% across scaled deployments,' but Table 6.2 shows block TPS changes of -1.83% and -1.10%, and a 77.36% change in commit time from single-node to 3-node deployment. The quantitative claim in the text does not match the table.
[Table 6.1, §5.5] The table caption for Table 6.1 uses 'Pool TPS' and 'Block TPS' without defining them; a cross-reference to §5.5 where these metrics are defined would improve readability.
[§7.3, References [17], [18]] The benchmark figures for Visa (1667 TPS) and PayPal (193 TPS) are both cited to the same reference (Vranken, [17]/[18]), which appears to be a mistake; please provide correct, distinct sources for these industry figures.
[§3.1, §8.2] There are minor typographical errors: 'trilema' should be 'trilemma' in §3.1, and 'This separation separation' should be 'This separation' in §8.2.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the throughput claim is a direct measurement of the implemented prototype, not a fitted or self-referential derivation.

full rationale

The paper's central performance claim (average Block TPS of approximately 1030, median time to finality of 2.2 seconds, synchronization time of 43 ms) is an empirical measurement of the authors' own implementation, reported in Section 6.1 and Table 6.1. There is no fitted parameter that is later renamed as a prediction, no load-bearing self-citation, no uniqueness theorem imported from the authors' prior work, and no equation in the theoretical analysis (Section 4) that is equivalent by construction to the experimental numbers. The theoretical discussion is qualitative (e.g., O(n) vs O(n^2) network complexity) and is not used to generate the measured TPS values. The only related concern is that the abstract's 'over 1000 transactions per second' corresponds to Block TPS as defined in Section 5.5, which excludes transaction-pool processing; this is a metric-validity and presentation issue rather than circular reasoning, because the number is directly observed under the stated experimental setup rather than derived from or fitted to the claim itself. The paper also explicitly acknowledges limiting assumptions in Section 5.6, including single-laptop deployment, one Kafka broker, and lack of geographic distribution, which further confirms that the results are presented as bounded empirical observations rather than as a self-referential derivation. No circular step can be exhibited with a specific reduction, so the appropriate finding is no significant circularity.

Assumptions & free parameters 5 free parameters · 5 assumptions · 0 invented entities

The central performance claim rests on hand-picked experiment configurations (single Kafka broker, fixed batch/block sizes, fixed resource limits) and on several domain assumptions from PBFT, PoS, and networking theory. No new physical entities are introduced; the master node is a role, not a new construct. The main unverified load-bearing assumptions are the honesty of the master node and the security economics of staking.

free parameters (5)

Kafka broker count = 1
Set to one broker in Table 5.2, so the measured performance and the claimed fault tolerance do not reflect multi-broker deployments.
Kafka topic partitions = 5
Kafka partitioning affects parallelism and ordering; no sensitivity analysis is reported.
Transaction batch size = 64
Batching directly affects pool throughput and is fixed across runs; another value could change the 412 TPS pool result.
Block size = 512 transactions
Block TPS depends on this fixed block size; larger blocks would change the throughput/finality tradeoff.
Resource allocation = 10 CPU threads, 30 GB RAM
Kubernetes resource limits in Table 5.1 were chosen by trial and error (Section 7.2) and not swept, so performance is tied to this hand-picked allocation.

assumptions (5)

standard math PBFT provides safety and liveness when fewer than one third of validators are Byzantine.
Invoked implicitly in Sections 3.3 and 4.1 as the basis for consensus integrity, but the paper does not state the fault threshold or proof.
domain assumption The master node is honest and trusted.
The master selects validators and mediates all communication (Section 3.2); if it is malicious or compromised, the governance and security claims fail. The paper acknowledges this centralization in Section 3.5.
domain assumption Stake-based validator selection makes Sybil and 51% attacks economically impractical.
Borrowed from PoS literature in Section 4.1 but not empirically tested; Section 5.1 says simulated Sybil and 51% attacks are out of scope.
domain assumption A peer-to-peer network has O(n^2) message complexity because every node connects to every other.
Section 4.2 uses this model to argue the Kafka architecture is more scalable, but real P2P overlays use gossip or structured topologies with lower per-node degree.
domain assumption Nodes are homogeneous and transactions arrive uniformly in fixed-size batches.
Stated in Section 5.6 as assumptions of the experiment; real deployments have heterogeneous hardware and bursty transaction arrival.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Redefining Hybrid Blockchains: A Balanced Architecture." pith.science (2026). https://pith.science/paper/OK5L7GJE

@misc{pith2026250418966,
  author       = {Pith},
  title        = {Pith review of: Redefining Hybrid Blockchains: A Balanced Architecture},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OK5L7GJE}},
  note         = {Machine review of arXiv:2504.18966}
}

read the original abstract

Blockchain technology has completely revolutionized the field of decentralized finance with the emergence of a variety of cryptocurrencies and digital assets. However, widespread adoption of this technology by governments and enterprises has been limited by concerns regarding the technology's scalability, governance, and economic sustainability. This paper aims to introduce a novel hybrid blockchain architecture that balances scalability, governance, and decentralization while being economically viable for all parties involved. The new semi-centralized model leverages strategies not prevalent in the field, such as resource and node isolation, containerization, separation of networking and compute layers, use of a Kafka pub-sub network instead of a peer-to-peer network, and stakes-based validator selection to possibly mitigate a variety of issues related to scalability, security, governance, and economic sustainability. Simulations conducted on Kubernetes demonstrate the architecture's ability to achieve over 1000 transactions per second, with consistent performance across scaled deployments, even on a lightweight consumer-grade laptop with resource constraints. The findings highlight the system's scalability, security, and economic viability, offering a robust framework for enterprise and government adoption.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

19 extracted references · 17 canonical work pages

[1]

Bitcoin: A Peer-to-Peer Electronic Cash System,

S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System," 2008. [Online]. Available: https://bitcoin.org/bitcoin.pdf. [Accessed: Jan. 6, 2025]

work page 2008
[2]

Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform,

V. Buterin, "Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform," 2013. [Online]. Available: https://ethereum.org/en/whitepaper/. [Accessed: Jan. 6, 2025]

work page 2013
[3]

Bitcoin energy consumption worldwide 2017-2025

Statista, "Bitcoin energy consumption worldwide 2017-2025", 2024. [Online]. Available: https://www.statista.com/statistics/881472/worldwide-bitcoin-energy-consumption/. [Accessed: Jan. 6, 2025]

work page 2017
[4]

Ministry of Finance, Government of Pakistan, "Energy," in *Pakistan Economic Survey 2023-24*, 2024, ch. 14, pp. 1-10. [Online]. Available: https://www.finance.gov.pk/survey/chapter_24/14_energy.pdf. [Accessed: Jan. 6, 2025]

work page 2023
[5]

Ethereum 2.0,

K. Lau and Crypto.com, “Ethereum 2.0,” report, 2020. Available: https://assets.ctfassets.net/hfgyig42jimx/7j3AVp5aCnx2Ct2P6T6kY/e8991d5da1972d5d7602 33868f237609/Crypto.com_Macro_Report_-_Ethereum_2.0.pdf [Accessed: Jan. 8, 2025]

work page 2020
[6]

The Latest Gossip on BFT Consensus,

E. Buchman, J. Kwon, and Z. Milosevic, "The Latest Gossip on BFT Consensus," arXiv, 2018. [Online]. Available: https://doi.org/10.48550/arxiv.1807.04938. [Accessed: Jan. 8, 2025]

arXiv doi:10.48550/arxiv.1807.04938 2018
[7]

The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments,

J. Poon and T. Dryja, "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments," Jan. 2016. [Online]. Available: https://lightning.network/lightning-network-paper.pdf. [Accessed: Jan. 8, 2025]

work page 2016
[8]

Scaling,

Ethereum Foundation, "Scaling," Ethereum.org, May 7, 2024. [Online]. Available: https://ethereum.org/en/developers/docs/scaling/. [Accessed: Jan. 8, 2025]

work page 2024

Show all 19 references

[9]

Introduction,

Hyperledger Fabric Documentation, "Introduction," [Online]. Available: https://hyperledger-fabric.readthedocs.io/en/release-2.2/whatis.html. [Accessed: Jan. 10, 2025]

2025
[10]

Enterprise Interoperability with Dragonchain,

Dragonchain, "Enterprise Interoperability with Dragonchain," Dragonchain Blog, [Online]. Available: https://dragonchain.com/blog/enterprise-interoperability-with-dragonchain. [Accessed: Jan. 10, 2025]

2025
[11]

Kafka: A Distributed Messaging System for Log Processing,

J. Kreps, N. Narkhede, and J. Rao, "Kafka: A Distributed Messaging System for Log Processing," in *Proceedings of the NetDB*, Athens, Greece, 2011. [Online]. Available: https://notes.stephenholiday.com/Kafka.pdf. [Accessed: Jan. 10, 2025]. 31

2011
[12]

Bringing up a Kafka-based Ordering Service,

Hyperledger Fabric Documentation, "Bringing up a Kafka-based Ordering Service," [Online]. Available: https://hyperledger-fabric.readthedocs.io/en/release-2.5/kafka.html. [Accessed: Jan. 10, 2025]

2025
[13]

Hyperledger Indy,

LF Decentralized Trust, "Hyperledger Indy," [Online]. Available: https://www.lfdecentralizedtrust.org/projects/hyperledger-indy. [Accessed: Jan. 10, 2025]

2025
[14]

The Sybil Attack,

J. R. Douceur, "The Sybil Attack," in *Proceedings of the First International Workshop on Peer-to-Peer Systems (IPTPS '02)*, Cambridge, MA, USA, 2002, pp. 251-260. [Online]. Available: https://dl.acm.org/doi/10.5555/646334.687813. [Accessed: Jan. 11, 2025]

2002
[15]

Exploring the Attack Surface of Blockchain: A Systematic Overview,

M. Saad et al., "Exploring the Attack Surface of Blockchain: A Systematic Overview," *arXiv preprint arXiv:1904.03487*, 2019. [Online]. Available: https://arxiv.org/abs/1904.03487. [Accessed: Jan. 11, 2025]

1904 arXiv
[16]

Discovery through Gossip,

B. Haeupler, G. Pandurangan, D. Peleg, R. Rajaraman, and Z. Sun, "Discovery through Gossip," arXiv preprint arXiv:1202.2092, 2012. [Online]. Available: https://arxiv.org/abs/1202.2092. [Accessed: Jan. 11, 2025]

2012 arXiv
[18]

Sustainability of bitcoin and blockchains,

M. Vranken, "Sustainability of bitcoin and blockchains," *Current Opinion in Environmental Sustainability*, vol. 28, pp. 1-9, 2017. [Online]. Available: https://www.researchgate.net/publication/320123454_Sustainability_of_bitcoin_and_blockch ains. [Accessed: Jan. 15, 2025]

2017
[19]

What is the Fastest Blockchain and Why? Analysis of 43 Blockchains,

M. Raczyński, "What is the Fastest Blockchain and Why? Analysis of 43 Blockchains," Aleph Zero, 2023. [Online]. Available: https://alephzero.org/blog/what-is-the-fastest-blockchain-and-why-analysis-of-43-blockchains /. [Accessed: Jan. 15, 2025]

2023
[20]

Best Blockchain Performance: Results from Dartmouth Blockchain Study | SKALE,

SKALE Network, “Best Blockchain Performance: Results from Dartmouth Blockchain Study | SKALE,” SKALE , Aug. 23, 2024. Available: https://skale.space/blog/the-quest-for-the-best-blockchain-performance-results-from-dartmout h-blockchain-study. [Accessed: Jan. 15, 2025]. 32

2024

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.

[1] [1]

Bitcoin: A Peer-to-Peer Electronic Cash System,

S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System," 2008. [Online]. Available: https://bitcoin.org/bitcoin.pdf. [Accessed: Jan. 6, 2025]

work page 2008

[2] [2]

Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform,

V. Buterin, "Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform," 2013. [Online]. Available: https://ethereum.org/en/whitepaper/. [Accessed: Jan. 6, 2025]

work page 2013

[3] [3]

Bitcoin energy consumption worldwide 2017-2025

Statista, "Bitcoin energy consumption worldwide 2017-2025", 2024. [Online]. Available: https://www.statista.com/statistics/881472/worldwide-bitcoin-energy-consumption/. [Accessed: Jan. 6, 2025]

work page 2017

[4] [4]

Ministry of Finance, Government of Pakistan, "Energy," in *Pakistan Economic Survey 2023-24*, 2024, ch. 14, pp. 1-10. [Online]. Available: https://www.finance.gov.pk/survey/chapter_24/14_energy.pdf. [Accessed: Jan. 6, 2025]

work page 2023

[5] [5]

Ethereum 2.0,

K. Lau and Crypto.com, “Ethereum 2.0,” report, 2020. Available: https://assets.ctfassets.net/hfgyig42jimx/7j3AVp5aCnx2Ct2P6T6kY/e8991d5da1972d5d7602 33868f237609/Crypto.com_Macro_Report_-_Ethereum_2.0.pdf [Accessed: Jan. 8, 2025]

work page 2020

[6] [6]

The Latest Gossip on BFT Consensus,

E. Buchman, J. Kwon, and Z. Milosevic, "The Latest Gossip on BFT Consensus," arXiv, 2018. [Online]. Available: https://doi.org/10.48550/arxiv.1807.04938. [Accessed: Jan. 8, 2025]

arXiv doi:10.48550/arxiv.1807.04938 2018

[7] [7]

The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments,

J. Poon and T. Dryja, "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments," Jan. 2016. [Online]. Available: https://lightning.network/lightning-network-paper.pdf. [Accessed: Jan. 8, 2025]

work page 2016

[8] [8]

Scaling,

Ethereum Foundation, "Scaling," Ethereum.org, May 7, 2024. [Online]. Available: https://ethereum.org/en/developers/docs/scaling/. [Accessed: Jan. 8, 2025]

work page 2024