{"id":"9b8dd668-bd6c-4b17-b2b4-d0b112072fb7","arxiv_id":"2505.08652","paper_version":1,"verdict":"UNVERDICTED","confidence":"MODERATE","novelty_score":0.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"The paper gives a qualitative, layer-by-layer comparison of Bitcoin, Ethereum, and Hyperledger Fabric without adding new data, analysis, or formal results.","lead":"This preprint is an introductory survey comparing Bitcoin, Ethereum, and Hyperledger Fabric across data, network, consensus, smart contract, scalability, and security layers. It repeats textbook knowledge about these platforms and contains no new measurements, experiments, or formal results.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Table 1's consensus row is the load-bearing weakness: it lists Ethereum as PoW/PoS and Fabric as PBFT/SBFT, but Ethereum has been PoS-only since 2022 and Fabric 2.x orders via Raft, so the central comparison is stale unless dated.","rationale":"The reader's weakest assumption already flags unverified documentation and inaccurate descriptions of Ethereum's consensus status as a central risk. My check confirms and sharpens that concern: the paper's Table 1 and Section 5 describe Ethereum as PoW-based with PoS as a future plan, which is not accurate for a 2025 preprint after The Merge, and describe Hyperledger Fabric as adopting PBFT/SBFT, which is not Fabric 2.x's actual ordering mechanism. This makes the central comparative table unreliable as a current-state comparison. The reason I keep the reader's UNVERDICTED verdict rather than moving to REJECT is that the paper is a survey with no novel research claim; under the stated rating semantics, a survey is not evaluable as an accept/reject research contribution. The factual staleness reinforces UNVERDICTED but does not change it. I also acknowledge that the paper does present textbook content on hash pointers, Merkle trees, PoW, and smart contracts that is broadly recognizable, which is why the concern is specifically about the comparative table's accuracy rather than about the entire tutorial content.","tokens_in":13152,"tokens_out":5664,"duration_ms":59251,"concrete_test":"Check Table 1's Consensus Layer row against primary sources as of the paper's date: Ethereum mainnet switched to proof-of-stake on 2022-09-15 (Ethereum.org consensus documentation), and Hyperledger Fabric 2.x defaults to etcd/Raft ordering (Fabric orderer documentation), not PBFT/SBFT. If the row changes to PoS for Ethereum and Raft/pluggable for Fabric, the central comparison requires revision; if the authors intended a historical snapshot, the covered date range must be stated explicitly.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is Table 1's comparative summary, and its Consensus Layer row is the least secure part. Section 5 says Ethereum 'uses the PoW consensus' and 'plans to adopt the PoS … protocol in the future'; Table 1 lists 'POW/POS'. But Ethereum mainnet completed The Merge on 2022-09-15 and has been proof-of-stake (Gasper) ever since, so a May 2025 paper calling PoW current is factually inconsistent with the publication date. Similarly, Table 1 lists Hyperledger Fabric consensus as 'PBFT/SBFT', and Section 5.3 says Fabric 'adopts PBFT'. Fabric 2.x does not use PBFT or SBFT; its ordering service is based on etcd/Raft (with Kafka as an earlier option), and PBFT was only an early v0.6-era design. Because Table 1 is the advertised structural comparison, an error in this row directly damages the central claim unless the paper is explicitly read as a historical snapshot of pre-2020 systems, which the abstract does not state. This is not a disagreement with current consensus; it is a correctness risk internal to the paper's own temporal presentation.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper is a comparative survey of three blockchain platforms—Bitcoin, Ethereum, and Hyperledger Fabric—organized around a five-layer architecture (data, network, consensus, smart contract, application). It provides a high-level comparison in Table 1 and discusses data structures, consensus algorithms, smart contracts, scalability, and security. The paper presents itself as an analysis of the principles and technologies of these platforms and highlights their similarities, differences, and trade-offs. Its central contribution is the layered comparative framing and the summary table, supported by descriptive sections on each layer.","tokens_in":13396,"tokens_out":3988,"duration_ms":37684,"significance":"If the descriptive claims were accurate and appropriately dated, the paper could serve as a useful introductory survey for students or practitioners seeking a broad-brush comparison of the three most influential blockchain platforms. The layered decomposition and the comparison of consensus families (PoW, PoS, PBFT) provide a helpful pedagogical structure. However, the paper contains no new experimental results, no formal analysis, and no machine-checked proofs; its value depends entirely on the correctness and timeliness of its descriptive statements. Those statements are currently undermined by stale and factually incorrect information, especially in the consensus layer and in historical claims about Bitcoin and Ethereum. Because the central Table 1 is the paper's main deliverable, these inaccuracies materially reduce its reliability as a reference.","major_comments":[{"comment":"The consensus-layer description is stale in a way that affects the central comparison. Section 5 states that Ethereum 'uses the PoW consensus' and 'plans to adopt the PoS ... protocol in the future,' and Table 1 lists Ethereum's consensus as 'POW/POS.' The Ethereum mainnet has been proof-of-stake since The Merge on 2022-09-15 (with Gasper as the finality gadget), so a May 2025 paper describing PoW as the current mechanism is factually incorrect. Similarly, Section 5.3 says Hyperledger Fabric 'adopts the PBFT algorithm' and Table 1 lists 'PBFT/SBFT,' but Fabric 2.x orders via etcd/Raft; PBFT was only an early v0.6-era design. Since Table 1 is the paper's advertised structural comparison, an error in this row directly weakens the central claim unless the paper is explicitly framed as a historical snapshot of pre-2020 systems, which the abstract does not state. The authors should update the consensus row to reflect current mechanisms and add a clear version/timestamp caveat to the comparison.","section":"Section 5 and Table 1"},{"comment":"The historical account of Bitcoin's block size is inaccurate. The paper claims that 'When Bitcoin was first created, the block size was not strictly limited,' that 'a block can be as large as 32MB,' and that 'Bitcoin later limited the block size to 1MB.' In fact, the original Bitcoin implementation included a 1MB maximum block size as a protocol constant, and later changes such as SegWit (2017) introduced a block-weight limit (with an effective maximum of about 4MB), not a 32MB early limit. This claim appears in the motivation for the scaling discussion, so it is load-bearing for the section's argument. The authors should correct this history or remove the unsupported claim.","section":"Section 8 (Scalability)"},{"comment":"Several Ethereum parameters are presented as current but are stale. The paper states that 'miners who generate new blocks are rewarded with five Ether,' that 'more than ten million Ether can be generated annually through mining,' and that the market price is 'exceeding 300 USD per Ether.' These figures are not accurate for the publication date of the manuscript: the block reward was reduced to 3 ETH (Byzantium), then 2 ETH (Constantinople), and became 0 after The Merge; annual issuance under proof-of-stake is on the order of hundreds of thousands to a few million ETH; and the market price has been well above $300 in recent years. The authors should either update these numbers to a cited snapshot or clearly label them as historical values.","section":"Section 6.3 (Operating Principle)"},{"comment":"The storage-layer description is internally inconsistent. Section 3.3 says 'Bitcoin, Ethereum, and Hyperledger Fabric all use Level DB databases to store index data,' and that Hyperledger Fabric 1.0 also supports CouchDB. Table 1, however, lists 'Blockchain Storage' as 'File Storage' for Bitcoin and Hyperledger Fabric and 'Level DB' for Ethereum. Because Table 1 is the paper's central comparative artifact, this contradiction between the table and the prose should be fixed. Either the table or the text is wrong, and the paper should present a single, dated description.","section":"Section 3.3 and Table 1"}],"minor_comments":[{"comment":"The Introduction's section references are off by one: it says 'Section 1 presents the overall system architecture,' but the architecture appears in Section 2, and subsequent references are similarly shifted. Please correct the cross-reference numbering.","section":"Introduction (section numbering)"},{"comment":"There are several typos and misspellings: 'Bitcion' and 'Etherum' in Table 1, 'Mrekle tree' in the caption of Figure 4, 'Merkle Bocket Tree' in Table 1 (should be 'Bucket'), and 'EDCSA' in Section 9.1 (should be 'ECDSA'). The paper would benefit from a careful proofreading pass.","section":"Throughout and Table 1"},{"comment":"The citation for Zero-Knowledge Proofs appears to be incorrect: reference [3] is listed as 'zerocash decentralized anonymous payments from bitcoin,' which is not the standard Zerocash paper (Ben-Sasson et al.) and does not match the sentence citing ZK-STARK. The authors should verify and correct this reference.","section":"Section 9.2 (Privacy)"},{"comment":"Table 2 contains duplicate rows: the entry 'Cannot verify the legality of many transactions, only can verify the legality of transactions related to itself' appears twice, and the row layout for light-node capabilities appears garbled. Please clean up the table.","section":"Table 2 (Full Node and Light Node)"},{"comment":"The five-layer model is asserted without argument or citation; the cited reference [49] is listed but the layer decomposition is presented as self-evident. Adding a brief justification or a more precise citation would strengthen the framing.","section":"Section 2 (System Architecture)"}],"recommendation":"major_revision","confidential_remarks":"The paper is clearly an introductory student-level survey. The main issue is factual accuracy and the lack of a clear temporal statement. The authors appear to be aware of the systems but have used secondary or dated sources without checking current protocol states. There is also an unusual concentration of self-citations to the same group's smart-contract security papers, which are mostly tangential to the comparison; I would suggest the editor ask the authors to justify or trim these. With corrections to the consensus row, the block-size history, the Ethereum parameters, and the storage table, the paper could become an acceptable tutorial-style contribution; without those corrections, it should not be published as a reference survey."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThis paper is a survey of Bitcoin, Ethereum, and Hyperledger Fabric organized around a five-layer architecture. There is no new method, data, or synthesis; what you see is textbook material assembled in one place. The one genuinely useful thing is the organization: Table 1 and the section-by-section walkthrough give a newcomer a readable map of where these systems differ. The high-level distinctions (public vs. consortium, UTXO vs. account, EVM vs. Docker) are standard but correctly stated.\n\nThe soft spots are real and not minor. The consensus layer, which is the load-bearing row of Table 1, is stale past the point of error. Ethereum is presented as PoW with a plan to adopt PoS; The Merge happened in September 2022, so a May 2025 paper calling PoW current is wrong. Hyperledger Fabric is listed as PBFT/SBFT; Fabric 2.x orders via Raft, and PBFT was only an early v0.6 design. Section 5.3 also describes Fabric 'adopting PBFT' as if current. Section 8 claims Bitcoin's block size was originally unlimited at 32MB and later limited to 1MB, but Bitcoin's original block size limit was 1MB; the 32MB figure is a confusion with the later block weight limit. Section 6.3 says miners are rewarded with five Ether per block, which was true only until Byzantium in 2017.\n\nThe citation pattern leans heavily on the authors' own smart-contract papers that have nothing to do with the compared properties; that inflates the reference list without adding support. The text also has typos (Bitcion, Mrekle, Bocket) that should have been caught.\n\nIf this were rewritten as an explicitly dated historical snapshot of ca. 2018 systems, much of the criticism would fall away. As it stands, the central comparative claim is factually inconsistent with the publication date, so I would not trust it as a reference without verification. That said, for a reader who wants a quick orientation to the basic architecture of these three platforms, the top half of the paper is fine.\n\nRecommendation: desk reject. A survey with no new result and load-bearing factual errors doesn't deserve referee time unless the venue is explicitly a tutorial outlet and the authors commit to fixing the consensus claims and dating the material. If it comes back revised, a quick check of Ethereum and Fabric consensus would settle it.","headline":"A stale, textbook-level survey of three blockchains; the layered comparison is clear for beginners but the consensus table is factually wrong for Ethereum and Fabric.","tokens_in":13893,"tokens_out":2096,"would_cite":false,"duration_ms":19920,"reading_group":"no","serious_thinker":"yes","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper claims that Bitcoin, Ethereum, and Hyperledger Fabric can be systematically compared through a five-layer blockchain architecture, and that their differences at the data, network, consensus, contract, and application layers…","keywords":["Blockchain","Bitcoin","Ethereum","Hyperledger Fabric","consensus mechanisms","smart contracts","scalability","blockchain security"],"falsifier":"Check the Ethereum mainnet's consensus mechanism today: if it is fully proof-of-stake, then the paper's statement that Ethereum plans to adopt proof of stake is outdated and the comparison table misdescribes the present system.","tokens_in":12944,"feed_emoji":"⛓️","tokens_out":6357,"duration_ms":57814,"temperature":0.7,"pith_summary":"The paper sets out to show that the three most influential blockchain platforms—Bitcoin, Ethereum, and Hyperledger Fabric—are not just different cryptocurrencies but structurally different systems. It organizes each platform into five layers (data, network, consensus, contract, and application) and compares them feature by feature, producing a single table that condenses the key distinctions. A sympathetic reader would care because the comparison offers a practical way to see why Bitcoin favors security and decentralization, Ethereum favors programmability, and Fabric favors enterprise throughput and privacy. The paper's central contribution is that map, not a new algorithm or measurement.","feed_headline":"Bitcoin, Ethereum, and Fabric differ at every layer","feed_subtitle":"A five-layer comparison maps how each platform trades decentralization, throughput, and privacy.","key_machinery":"The central object is the five-layer architecture (data, network, consensus, contract, application) set out in Figure 1. It carries the argument by providing a fixed grid onto which each platform is mapped: the data layer supplies the structure (Merkle tree versus Merkle Patricia tree versus Merkle bucket tree, and transaction-based versus account-based model), the network layer supplies the communication substrate (TCP-based, Kademlia-based, and HTTP/2-based P2P), the consensus layer supplies the agreement mechanism (proof of work, proof of work/stake with Casper, and Practical Byzantine Fault Tolerance), the contract layer supplies the execution environment (script, EVM, Docker), and the application layer supplies the use case (digital cash, decentralized applications, enterprise applications). The grid lets the paper translate scattered platform documentation into a single comparison table.","core_discovery":"The central claim is stated in Table 1: Bitcoin is a public chain with a transaction-based model using a Merkle tree; Ethereum is a public chain with an account-based model using a Merkle Patricia tree; Hyperledger Fabric is a consortium chain with an account-based model using a Merkle bucket tree. The paper argues these choices propagate upward: Bitcoin's scripted, non-Turing-complete contracts and proof-of-work consensus fit its simple digital-cash purpose; Ethereum's account model and Ethereum Virtual Machine enable smart contracts and decentralized applications but add gas costs and security risks; Fabric's permissioned membership allows Byzantine-fault-tolerant consensus, Docker-based chaincode, and multi-channel privacy. If the paper is right, the three systems occupy different points in a design space where decentralization, throughput, and privacy are coupled trade-offs.","pith_inferences":["Taken as a design-space map, the comparison implies that no single platform can simultaneously maximize decentralization, throughput, and privacy; every system must choose a corner.","The paper's snapshot of Ethereum as a proof-of-work system that plans to adopt proof of stake is already dated, so the comparison carries a time stamp and should be revised as platforms upgrade.","The same grid could be turned into a quantitative benchmark by measuring latency, throughput, fault tolerance, and privacy leakage layer by layer under standard workloads."],"forward_implications":["Bitcoin's UTXO and Merkle-tree design supports lightweight SPV verification, so light clients can check payments without storing the whole chain.","Ethereum's account-based state and gas metering make programmatic contracts feasible, but they also mean contract bugs can be exploited and failed executions still consume fees.","Hyperledger Fabric's permissioned membership and endorsement policies allow PBFT-style consensus, giving higher throughput at the cost of relying on trusted organizations.","The five-layer grid can be applied to any new blockchain to predict its scalability and security posture from its design choices."],"supporting_citations":[{"why":"Bitcoin whitepaper: establishes Bitcoin's transaction-based model, proof-of-work consensus, and block-chain structure that the comparison takes as baseline.","marker":"[39]"},{"why":"Ethereum whitepaper: supplies the account-based model, smart-contract concept, and EVM that define Ethereum's layer choices.","marker":"[9]"},{"why":"Hyperledger Fabric architecture: provides the consortium-chain design, membership service, and pluggable consensus used for Fabric.","marker":"[10]"},{"why":"Supplies a framework for analyzing private blockchains that the paper uses for Fabric's PBFT and throughput comparison.","marker":"[15]"},{"why":"Byzantine generals problem: frames the consensus challenge that both proof of work and PBFT are answering.","marker":"[27]"},{"why":"Ethereum's fork-choice and reward mechanism under proof of work, used to explain Ethereum deviations from Bitcoin.","marker":"[45]"},{"why":"Source for the widely cited figure that Bitcoin processes roughly seven transactions per second.","marker":"[48]"}],"fun_headline_variants":["Layer by layer: how Bitcoin, Ethereum, Fabric differ","Decentralization vs. privacy: the three-platform trade-off","Five layers, three platforms: where blockchains split","From PoW to PBFT: how blockchains pick their trade-offs"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The comparison assumes that every blockchain can be cleanly sliced into the same five layers and that the cited documentation accurately describes what each system currently does.","fun_headline_variants_meta":{"raw":{"variants":["Layer by layer: how Bitcoin, Ethereum, Fabric differ","Decentralization vs. privacy: the three-platform trade-off","Five layers, three platforms: where blockchains split","From PoW to PBFT: how blockchains pick their trade-offs"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000643,"raw_usage":{"total_tokens":2931,"prompt_tokens":890,"completion_tokens":2041,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":506,"completion_tokens_details":{"reasoning_tokens":1971}},"tokens_in":506,"tokens_out":2041,"duration_ms":15034,"temperature":1.0,"reasoning_tokens":1971,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T21:48:27.722655+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Check the Ethereum mainnet's consensus mechanism today: if it is fully proof-of-stake, then the paper's statement that Ethereum plans to adopt proof of stake is outdated and the comparison table misdescribes the present system.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Bitcoin whitepaper: establishes Bitcoin's transaction-based model, proof-of-work consensus, and block-chain structure that the comparison takes as baseline."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Hyperledger Fabric architecture: provides the consortium-chain design, membership service, and pluggable consensus used for Fabric."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies a framework for analyzing private blockchains that the paper uses for Fabric's PBFT and throughput comparison."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Byzantine generals problem: frames the consensus challenge that both proof of work and PBFT are answering."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Ethereum's fork-choice and reward mechanism under proof of work, used to explain Ethereum deviations from Bitcoin."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Source for the widely cited figure that Bitcoin processes roughly seven transactions per second."}],"review_version":1}