[Paper] iblock: Accurate and Scalable Bitcoin Simulations with OMNeT++

Source: arXiv - 2512.20402v1

Overview

The paper introduces iblock, a C++‑based library that brings high‑fidelity Bitcoin network simulation to the OMNeT++ framework. By leveraging a compiled language and tight integration with OMNeT++’s modular ecosystem, iblock delivers faster, more scalable experiments than existing blockchain simulators that are typically written in Python or JavaScript, while still supporting the same level of protocol detail.

Key Contributions

• A native C++ simulation library for Bitcoin that plugs directly into OMNeT++, eliminating the overhead of interpreted languages.
• Performance gains: Benchmarks show iblock runs up to 5× faster than the leading blockchain simulator at comparable detail.
• Scalability: Able to simulate thousands of nodes and realistic network topologies without prohibitive memory or CPU consumption.
• Modular extensibility: Seamless reuse of other OMNeT++ modules (e.g., custom network layers, traffic generators) for richer, cross‑domain experiments.
• Validation suite: Reproduces canonical Bitcoin behavior (block propagation latency, fork rates) and correctly models the selfish‑mining attack, matching analytical predictions.

Methodology

1. Design on OMNeT++ – iblock implements Bitcoin’s peer‑to‑peer protocol as a set of OMNeT++ modules (nodes, miners, network links).
2. C++ core – All consensus logic (block creation, validation, mempool handling) is written in native C++, giving deterministic execution and low‑level control over timing.
3. Event‑driven simulation – OMNeT++’s discrete‑event engine schedules messages (e.g., block announcements) exactly as they would travel over a real network, allowing fine‑grained latency modeling.
4. Benchmarking – The authors compare iblock against a popular Python‑based blockchain simulator by measuring wall‑clock time, memory usage, and the number of simulated blocks per second under identical network topologies.
5. Scenario validation – Two test cases are run: (a) a baseline Bitcoin network under honest mining, and (b) a selfish‑mining adversary controlling a fraction of hash power. Results are plotted against theoretical formulas from the literature.

Results & Findings

• Speed: iblock processes ~2 M simulated blocks per hour on a modest laptop, versus ~0.4 M blocks per hour for the Python baseline.
• Memory footprint: Peak RAM usage stays under 1 GB for 5 k‑node simulations, whereas the comparator exceeds 3 GB.
• Accuracy: Measured fork rates (≈0.1 % for honest mining) and block propagation delays (≈2 s median) align with real‑world Bitcoin measurements.
• Selfish mining: When the attacker controls 30 % of hash power, iblock reproduces the expected revenue boost (~1.2×) and increased orphan rate, confirming the model’s correctness.

Practical Implications

• Protocol research – Researchers can prototype and evaluate new consensus tweaks, fee mechanisms, or network layer optimizations at scale without waiting for costly test‑net deployments.
• Security testing – Developers of wallet software or mining pools can simulate attack vectors (e.g., selfish mining, eclipse attacks) to assess mitigation strategies before implementation.
• Network planning – ISPs and blockchain infrastructure providers can model how changes in latency, bandwidth, or node distribution affect block propagation and overall throughput.
• Education & training – The open‑source library can be used in university courses to give students hands‑on experience with blockchain dynamics in a controlled environment.
• Cross‑domain simulations – Because iblock runs inside OMNeT++, it can be combined with IoT, vehicular, or 5G network models, enabling studies of Bitcoin’s behavior in emerging edge‑computing scenarios.

Limitations & Future Work

• Protocol scope – iblock currently implements the original Bitcoin protocol (pre‑SegWit, no Lightning Network). Extending it to newer consensus rules and layer‑2 solutions will be necessary for broader relevance.
• Real‑world network fidelity – While OMNeT++ can model latency and packet loss, the simulator does not yet capture ISP‑level routing policies or churn dynamics that affect real Bitcoin nodes.
• Parallel execution – The current implementation runs on a single simulation thread; scaling to multi‑core or distributed simulation could further reduce runtime for massive networks.
• User ergonomics – Setting up complex scenarios still requires familiarity with OMNeT++’s NED language and C++ code, which may be a barrier for non‑research developers. Future work could provide higher‑level configuration tools or Python bindings.

Authors

• Niccolò Scatena
• Pericle Perazzo
• Giovanni Nardini

Paper Information

• arXiv ID: 2512.20402v1
• Categories: cs.CR, cs.SE
• Published: December 23, 2025
• PDF: Download PDF