Pith. sign in

REVIEW 4 major objections 5 minor 2 cited by

Comparative Analysis of Blockchain Systems

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

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

Pith's one-line read 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…

desk verdict 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. read the letter →

arxiv 2505.08652 v1 pith:XXEIYGLQ submitted 2025-05-13 cs.CR

Jiaqi Huang , Yuanzheng Niu , Xiaoqi Li , Zongwei Li This is my paper · ORCID
classification cs.CR
keywords BlockchainBitcoinEthereumHyperledgerFabricconsensusmechanismssmartcontractsscalabilitysecurity
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 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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

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

  • 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.
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.

Referee Report

4 major / 5 minor

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.

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 (4)
  1. [Section 5 and Table 1] 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.
  2. [Section 8 (Scalability)] 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.
  3. [Section 6.3 (Operating Principle)] 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.
  4. [Section 3.3 and Table 1] 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.
minor comments (5)
  1. [Introduction (section numbering)] 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.
  2. [Throughout and Table 1] 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.
  3. [Section 9.2 (Privacy)] 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.
  4. [Table 2 (Full Node and Light Node)] 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.
  5. [Section 2 (System Architecture)] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the comparison is an externally anchored survey; self-citations are background references, not load-bearing.

full rationale

The paper makes no derived prediction or fitted quantity. Its central claim, Table 1's layered comparison, is asserted from primary documentation and standard references for Bitcoin, Ethereum, and Hyperledger Fabric, not derived from its own inputs. The five-layer architecture is adopted as an expository frame rather than proven, and no equation in the paper is constructed to force the tabulated entries. The authors' self-citations concern smart-contract vulnerability detection, NFT wash trading, and adjacent security topics; none of these is used to justify the comparative claims about consensus, data structures, or data models. The cited external sources independently anchor the comparison. Accuracy concerns such as Ethereum's post-Merge consensus status or Fabric 2.x Raft ordering are correctness risks, not circularity, because the claims are checkable against external facts rather than being equivalent to the paper's assumptions by construction.

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

The survey introduces no new quantities. Its central comparison rests on an assumed layer model and on the accuracy of secondary sources. It has no free parameters and postulates no new entities.

assumptions (3)
  • domain assumption A five-layer decomposition (data, network, consensus, contract, application) is a valid general model of blockchain systems.
    Adopted uncritically from reference [49] in Section 2 and used as the paper's organizational skeleton; its validity is not argued.
  • domain assumption Public documentation and prior literature cited in the references accurately describe Bitcoin, Ethereum, and Hyperledger Fabric as of the writing.
    Most factual statements in Sections 3 through 9 are asserted without primary verification; for example, Section 8's block size history and Section 6.3's throughput claim have no source.
  • ad hoc to paper Qualitative comparison of consensus algorithms (PoW, PoS, PBFT) is sufficient to characterize the security and scalability of the platforms.
    The paper presents no formal model, measurements, or benchmarks; Table 3 ranks algorithms on qualitative indicators without a defined metric.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Comparative Analysis of Blockchain Systems." pith.science (2026). https://pith.science/paper/XXEIYGLQ

@misc{pith2026250508652,
  author       = {Pith},
  title        = {Pith review of: Comparative Analysis of Blockchain Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XXEIYGLQ}},
  note         = {Machine review of arXiv:2505.08652}
}
read the original abstract

Blockchain is a type of decentralized distributed database. Unlike traditional relational database management systems, it does not require management or maintenance by a third party. All data management and update processes are open and transparent, solving the trust issues of centralized database management systems. Blockchain ensures network-wide consistency, consensus, traceability, and immutability. Under the premise of mutual distrust between nodes, blockchain technology integrates various technologies, such as P2P protocols, asymmetric encryption, consensus mechanisms, and chain structures. Data is distributed and stored across multiple nodes, maintained by all nodes, ensuring transaction data integrity, undeniability, and security. This facilitates trusted information sharing and supervision. The basic principles of blockchain form the foundation for all related research. Understanding the working principles is essential for further study of blockchain technology. There are many platforms based on blockchain technology, and they differ from one another. This paper will analyze the architecture of blockchain systems at each layer, focusing on the principles and technologies of blockchain platforms such as Bitcoin, Ethereum, and Hyperledger Fabric. The analysis will cover their scalability and security and highlight their similarities, differences, advantages, and disadvantages.

Figures

Figures reproduced from arXiv: 2505.08652 by the authors.

Figure 1
Figure 1. Blockchain System Architecture 3 Data Layer Blockchain technology[33] utilizes two important concepts from cryptography[23]: hash functions and signatures. Hash functions have three characteristics: 2 [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Blockchain Data Structure of the Bitcoin System [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. The content of the entire block is hashed together, creating a tamper-evident log. This means that if a value in any block is altered, the hash values of all subsequent blocks will also change, triggering a domino effect where a small change causes a chain reaction. If the hash value of the last block is known, it can be used to verify whether any previous block has been tampered with. P P H( ) Ordinary Pointer Hash… view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Mrekle tree The values of every two child nodes are connected, and then hashed to record them in the parent node. The final root hash of the transactions is stored in the Bitcoin block header. To confirm whether a specific transaction exists in the block [30], only the…
Figure 5
Figure 5. Figure 5: Operational Principle of Smart Contracts [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Securing High-Concurrency Ticket Sales: A Framework Based on Microservice

    cs.SE 2025-12 reject novelty 2.0 of 10

    A railway ticketing system built from standard Spring Cloud components is reported to reach 817 req/s on a train-query interface, but only under a 100-thread local VM test with inconsistent purchase-interface data.

  2. A Comprehensive Evaluation and Practice of System Penetration Testing

    cs.CR 2025-10 conditional novelty 2.0 of 10

    A survey-style paper that proposes a weighted tool-scoring rubric, then demonstrates routine host and web penetration tests on vulnerable virtual machines.

Reference graph

Works this paper leans on

50 extracted references · 39 canonical work pages · cited by 2 Pith papers

  1. [1]

    O’Reilly Media, Inc

    J Chris Anderson, Jan Lehnardt, and Noah Slater. 2010. CouchDB: the definitive guide: time to relax . " O’Reilly Media, Inc. "

    work page 2010

  2. [2]

    O’Reilly Media, Inc

    Andreas M Antonopoulos. 2014. Mastering Bitcoin: unlocking digital cryptocurrencies . " O’Reilly Media, Inc. "

    work page 2014

  3. [3]

    Maria Apostolaki, Aviv Zohar, and Laurent Vanbever. 2017. zerocash decentralized anonymous payments from bitcoin. (2017)

    work page 2017

  4. [4]

    James Aspnes, Collin Jackson, and Arvind Krishnamurthy. 2005. Exposing computationally-challenged Byzantine impostors. Technical Report. Technical Report YALEU/DCS/TR-1332, Yale University Department of Computer

    work page 2005

  5. [5]

    G BitFury. 2015. Proof of stake versus proof of work. White paper, Sep 810 (2015)

    work page 2015

  6. [6]

    Jiuyang Bu, Wenkai Li, Zongwei Li, Zeng Zhang, and Xiaoqi Li. 2025. Enhancing Smart Contract Vulnerability Detection in DApps Leveraging Fine-Tuned LLM. arXiv preprint arXiv:2504.05006 (2025)

    arXiv 2025

  7. [7]

    Jiuyang Bu, Wenkai Li, Zongwei Li, Zeng Zhang, and Xiaoqi Li. 2025. SmartBugBert: BERT-Enhanced Vulnerability Detection for Smart Contract Bytecode. arXiv preprint arXiv:2504.05002 (2025)

    arXiv 2025

  8. [8]

    Vitalik Buterin. 2016. Ethereum: platform review. Opportunities and challenges for private and consortium blockchains 45 (2016), 1–45

    work page 2016

Show all 50 references
  1. [9]

    Vitalik Buterin et al. 2014. A next-generation smart contract and decentralized application platform. white paper 3, 37 (2014), 2–1

    2014

  2. [10]

    Christian Cachin et al. 2016. Architecture of the hyperledger blockchain fabric. In Workshop on distributed cryptocur- rencies and consensus ledgers , Vol. 310. Chicago, IL, 1–4

    2016

  3. [11]

    Christopher D Clack, Vikram A Bakshi, and Lee Braine. 2016. Smart contract templates: foundations, design landscape and research directions. arXiv preprint arXiv:1608.00771 (2016)

    2016 arXiv

  4. [12]

    Michael Coblenz. 2017. Obsidian: a safer blockchain programming language. In 2017 IEEE/ACM 39th international conference on software engineering companion (ICSE-C) . IEEE, 97–99

    2017

  5. [13]

    Chris Dannen et al. 2017. Introducing Ethereum and solidity . Vol. 1. Springer

    2017

  6. [14]

    Alan Demers, Dan Greene, Carl Hauser, Wes Irish, John Larson, Scott Shenker, Howard Sturgis, Dan Swinehart, and Doug Terry. 1987. Epidemic algorithms for replicated database maintenance. In Proceedings of the sixth annual ACM Symposium on Principles of distributed computing . 1–12

    1987

  7. [15]

    Tien Tuan Anh Dinh, Ji Wang, Gang Chen, Rui Liu, Beng Chin Ooi, and Kian-Lee Tan. 2017. Blockbench: A framework for analyzing private blockchains. In Proceedings of the 2017 ACM international conference on management of data . 1085–1100

    2017

  8. [16]

    John R Douceur. 2002. The sybil attack. In International workshop on peer-to-peer systems . Springer, 251–260

    2002

  9. [17]

    Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. 1988. Consensus in the presence of partial synchrony. Journal of the ACM (JACM) 35, 2 (1988), 288–323

    1988

  10. [18]

    Cynthia Dwork and Moni Naor. 1992. Pricing via processing or combatting junk mail. InAnnual international cryptology conference. Springer, 139–147

    1992

  11. [19]

    Christopher K Frantz and Mariusz Nowostawski. 2016. From institutions to code: Towards automated generation of smart contracts. In IEEE 1st International Workshops on Foundations and Applications of Self Systems . IEEE, 210–215

    2016

  12. [20]

    Steven D Gribble, Alon Y Halevy, Zachary G Ives, Maya Rodrig, and Dan Suciu. 2001. What can database do for peer-to-peer?. In WebDB, Vol. 1. 31–36

    2001

  13. [21]

    Akshita Jain, Sherif Arora, Yashashwita Shukla, T Patil, and S Sawant-Patil. 2018. Proof of stake with casper the friendly finality gadget protocol for fair validation consensus in ethereum. International Journal of Scientific Research in Computer Science, Engineering and Info...

    2018

  14. [22]

    Ghassan O Karame, Elli Androulaki, and Srdjan Capkun. 2012. Double-spending fast payments in bitcoin. InProceedings of the 2012 ACM conference on Computer and communications security . 906–917

    2012

  15. [23]

    Jonathan Katz and Yehuda Lindell. 2007. Introduction to modern cryptography: principles and protocols . Chapman and hall/CRC

    2007

  16. [24]

    Shiho Kim and Ganesh Chandra Deka. 2020. Advanced applications of blockchain technology . Vol. 60. Springer

    2020

  17. [25]

    Sunny King and Scott Nadal. 2012. Ppcoin: Peer-to-peer crypto-currency with proof-of-stake. self-published paper, August 19, 1 (2012). 15

    2012

  18. [26]

    Dechao Kong, Xiaoqi Li, and Wenkai Li. 2024. Characterizing the Solana NFT ecosystem. In Companion Proceedings of the ACM Web Conference. 766–769

    2024

  19. [27]

    Leslie Lamport, Robert Shostak, and Marshall Pease. 2019. The Byzantine generals problem. In Concurrency: the works of leslie lamport. 203–226

    2019

  20. [28]

    Wenkai Li, Xiaoqi Li, Zongwei Li, and Yuqing Zhang. 2024. Cobra: interaction-aware bytecode-level vulnerability detector for smart contracts. In Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering. 1358–1369

    2024

  21. [29]

    Wenkai Li, Zhijie Liu, Xiaoqi Li, and Sen Nie. 2024. Detecting Malicious Accounts in Web3 through Transaction Graph. In Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering . 2482–2483

    2024

  22. [30]

    Xiaoqi Li et al. 2021. Hybrid analysis of smart contracts and malicious behaviors in ethereum. Hong Kong Polytechnic University

    2021

  23. [31]

    Xiaoqi Li, Ting Chen, Xiapu Luo, and Chenxu Wang. 2021. CLUE: towards discovering locked cryptocurrencies in ethereum. In Proceedings of the 36th Annual ACM Symposium on Applied Computing . 1584–1587

    2021

  24. [32]

    Xiaoqi Li, L Yu, and XP Luo. 2017. On Discovering Vulnerabilities in Android Applications. In Mobile Security and Privacy. Elsevier, 155–166

    2017

  25. [33]

    Zongwei Li, Wenkai Li, Xiaoqi Li, and Yuqing Zhang. 2024. StateGuard: Detecting State Derailment Defects in Decentralized Exchange Smart Contract. In Companion Proceedings of the ACM Web Conference . 810–813

    2024

  26. [34]

    Zongwei Li, Xiaoqi Li, Wenkai Li, and Xin Wang. 2025. SCALM: Detecting Bad Practices in Smart Contracts Through LLMs. arXiv preprint arXiv:2502.04347 (2025)

    2025

  27. [35]

    Zekai Liu and Xiaoqi Li. 2025. SoK: Security Analysis of Blockchain-based Cryptocurrency. arXiv preprint arXiv:2503.22156 (2025)

    2025 arXiv

  28. [36]

    Zekai Liu, Xiaoqi Li, Hongli Peng, and Wenkai Li. 2024. GasTrace: Detecting Sandwich Attack Malicious Accounts in Ethereum. In IEEE International Conference on Web Services (ICWS) . IEEE, 1409–1411

    2024

  29. [37]

    Yingjie Mao, Xiaoqi Li, Wenkai Li, Xin Wang, and Lei Xie. 2024. SCLA: Automated Smart Contract Summarization via LLMs and Semantic Augmentation. arXiv preprint arXiv:2402.04863 (2024)

    2024 arXiv

  30. [38]

    Donald R Morrison. 1968. PATRICIA—practical algorithm to retrieve information coded in alphanumeric. Journal of the ACM (JACM) 15, 4 (1968), 514–534

    1968

  31. [39]

    Satoshi Nakamoto and A Bitcoin. 2008. A peer-to-peer electronic cash system. Bitcoin.–URL: https://bitcoin. org/bitcoin. pdf 4, 2 (2008), 15

    2008

  32. [40]

    Arvind Narayanan, Joseph Bonneau, Edward Felten, Andrew Miller, and Steven Goldfeder. 2016. Bitcoin and cryptocur- rency technologies: a comprehensive introduction . Princeton University Press

    2016

  33. [41]

    Yuanzheng Niu, Xiaoqi Li, Hongli Peng, and Wenkai Li. 2024. Unveiling wash trading in popular NFT markets. In Companion Proceedings of the ACM Web Conference . 730–733

    2024

  34. [42]

    Robert Norvill, Beltran Borja Fiz Pontiveros, Radu State, and Andrea Cullen. 2018. Visual emulation for Ethereum’s virtual machine. In NOMS IEEE/IFIP Network Operations and Management Symposium . IEEE, 1–4

    2018

  35. [43]

    Shentu Qing-Chun. 2017. Development guide of blockchain

    2017

  36. [44]

    Madhusudan Singh and Shiho Kim. 2019. Blockchain technology for decentralized autonomous organizations. In Advances in computers. Vol. 115. Elsevier, 115–140

    2019

  37. [45]

    Yonatan Sompolinsky and Aviv Zohar. 2013. Accelerating bitcoin’s transaction processing. fast money grows on trees, not chains. Cryptology ePrint Archive (2013)

    2013

  38. [46]

    Nick Szabo. 1997. Formalizing and securing relationships on public networks. First monday (1997)

    1997

  39. [47]

    Yishun Wang, Xiaoqi Li, Shipeng Ye, Lei Xie, and Ju Xing. 2024. Smart contracts in the real world: A statistical exploration of external data dependencies. arXiv preprint arXiv:2406.13253 (2024)

    2024

  40. [48]

    Roger Wattenhofer. 2017. Distributed ledger technology: The science of the blockchain . CreateSpace Independent Publishing Platform

    2017

  41. [49]

    Yong Yuan, Fei-Yue Wang, et al. 2016. Blockchain: the state of the art and future trends. Acta automatica sinica 42, 4 (2016), 481–494

    2016

  42. [50]

    Huanhuan Zou, Zongwei Li, and Xiaoqi Li. 2025. Malicious Code Detection in Smart Contracts via Opcode Vectorization. arXiv preprint arXiv:2504.12720 (2025). 16

    2025

Pith tools

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