Papers
Topics
Authors
Recent
Search
2000 character limit reached

InterBench Protocol: Blockchain & Interval Benchmark

Updated 19 March 2026
  • InterBench Protocol is a dual-framework benchmark that evaluates both multi-blockchain interoperability platforms and C/C++ interval libraries with standardized, deterministic protocols.
  • The blockchain benchmarking component deploys microservices in containers to coordinate cross-chain transactions, synchronize clocks within ±1 ms, and rigorously assess atomicity and performance.
  • The interval computation variant employs automated test drivers and scripts across heterogeneous platforms to measure arithmetic correctness, error bounds, and runtime performance.

InterBench Protocol denotes two distinct, rigorously specified benchmarking frameworks: one for evaluating multi-blockchain interoperability-facilitating platforms (IFPs) and another for benchmarking C/C++ interval computation libraries across heterogeneous platforms. Each variant offers a comprehensive architecture, deterministic execution protocol, formally defined metrics, and automation infrastructure to deliver reproducible, quantitative comparisons in their respective domains (Kazemi et al., 2021, &&&1&&&).

1. Architectural Composition

Multi-Blockchain IFP Benchmarking

InterBench is structured as a set of microservices, each deployable within Docker containers or Kubernetes pods, communicating via HTTP/REST or gRPC. The five principal components are:

  • Test Orchestrator: Parses benchmark specifications (JSON/YAML), spins up auxiliary services with parameter synchronization, coordinates experiments, and maintains NTP-synchronized clocks within ±1 ms.
  • Client Workload Generator (CWG): Generates timestamped, uniquely identified cross-chain requests according to the workload specification, supporting “No_Action,” “Cross-chain Transaction Processing,” and “ReadWrite_Extreme” types, and up to 10,000 concurrent requests using Poisson, constant-rate, or bursty arrivals.
  • IFP Interface Layer (IIL): Translates generic benchmark requests to IFP-native APIs (e.g., ICON JSON-RPC, AION REST), logs submission and commit timestamps, and collects per-node resource metrics.
  • Transaction Behavior Monitor (TBM): Verifies atomicity by tracking chain events, matches transactions across source and destination ledgers, and detects anomalies such as fork reorganizations and double-spend attempts.
  • Visualized Results Reporter (VSR): Aggregates experiment logs and presents time-series, CDFs, and heatmaps via web dashboards or CSV export.

The microservice pipeline is: Test Orchestrator → {CWG, IIL, TBM, VSR} → IFP network.

Interval Computation Library Benchmarking

The InterBench harness orchestrates:

  • Test Driver: Built per target environment (OS, architecture, compiler) using CMake or MSBuild, dynamically linking C/C++ interval libraries as plugins.
  • Test Categories: Basic arithmetic, transcendental, composite (hand-crafted/randomized), and application-level expressions, each evaluated over precomputed input sets.
  • Automation Scripts: Python tools dispatch build (run_benchmark.py), aggregate results (aggregate.py), and generate summary plots (plot.py).
  • Platform Matrix: Evaluates across x86-64/ARM64 on Windows/macOS/Linux; includes platform- and library-specific configuration files.

2. Formal Benchmark Protocols

IFP Cross-Chain Protocol

Each run executes a four-phase, deterministic protocol (pseudocode representation):

  1. Initialize services and synchronize configuration.
  2. Generate transaction workload (CWG).
  3. Parallel submission: For each request, record t_submit_start, submit via IIL, and log submit events.
  4. Status polling: Query transaction status until committed/aborted; record t_commit_end, verify atomicity, and capture metrics.
  5. TBM aggregates security data.
  6. VSR compiles final plots and statistics.

Interval Library Protocol

For each platform-library-expression triplet:

  1. Build the library plugin and test driver.
  2. For Nᶜ = 1,000,000 (correctness) or Nᵖ = 1,000 × 10,000 (performance) inputs, evaluate and log results.
  3. Compare output intervals against exact references computed with GMP and Mathematica: accept if the produced interval encloses the exact value.
  4. Summarize width, error, and timing statistics; output CSV and JSON per test.

3. Metric Definitions

IFP Performance and Security

  • Throughput (λ\lambda): λ=Ncommits/Trun\lambda = N_{\text{commits}} / T_{\text{run}}
  • Per-request Latency (LiL_i): Li=tcommit, end,itsubmit, start,iL_i = t_{\text{commit, end},i} - t_{\text{submit, start},i}
  • Mean and Percentile Latencies: L=(1/N)iLi\overline{L} = (1/N)\sum_i L_i, LpL_p is the minimal ll s.t.\ i:Lilp%N|{i : L_i \leq l}| \geq p\%·N
  • Consensus Finality Time (LfinalityL_{\text{finality}}): Submission to block-depth-α\alpha confirmation.
  • Atomicity (AA): A=1(Npartial/Ntotal)A = 1 - (N_{\text{partial}} / N_{\text{total}})
  • Consistency (CC): Normalized fork events per block.
  • Double-spend Resistance (DSRDSR): DSR=Ndetected double spends/NrequestsDSR = N_{\text{detected double spends}} / N_{\text{requests}}
  • Attack-tolerance (ϵ\epsilon): ϵ=(λcleanλadversarial)/λclean\epsilon = (\lambda_{\text{clean}} - \lambda_{\text{adversarial}}) / \lambda_{\text{clean}}
  • Resource Utilization: CPUi(t),MEMi(t),NETi(t),DISKi(t)CPU_i(t), MEM_i(t), NET_i(t), DISK_i(t) sampled every Δt\Delta t

Interval Arithmetic Evaluation

  • Addition: [a,b]+[c,d]=[a+c,b+d][a, b] + [c, d] = [a+c, b+d]
  • Subtraction: [a,b][c,d]=[ad,bc][a, b] - [c, d] = [a-d, b-c]
  • Multiplication: [a,b]×[c,d]=[min(ac,ad,bc,bd),max(ac,ad,bc,bd)][a, b] \times [c, d] = [\min(ac,ad,bc,bd), \max(ac,ad,bc,bd)]
  • Division (if 0[c,d]0\notin[c,d]): [a,b]/[c,d]=[min(a/c,a/d,b/c,b/d),max(a/c,a/d,b/c,b/d)][a, b] / [c, d] = [\min(a/c, a/d, b/c, b/d), \max(a/c, a/d, b/c, b/d)]
  • Interval Width: w(I)=baw(I) = b - a
  • Midpoint: m(I)=a+b2m(I) = \frac{a + b}{2}
  • Error bound: e(I)=max(am,bm)e(I)=\max(|a-m^*|,|b-m^*|), where m=m^*= exact value.
  • Performance: Per-input runtime (ns), mean/median/stddev per batch.
  • Statistical Reports: % correct intervals, width distributions, histogram ratios to reference width.

4. Supported Workloads, Scenarios, and Platforms

Application Domain Principal Workloads/Tests Supported Platforms
Blockchain IFP No_Action, CTP, RWE, Adversarial (DDoS, Sybil, Network Partition) ICON, AION, Wanchain, Fabric, Ethereum, (planned Corda)
Interval Libraries Basic/Transcendental/Composite expressions, CCD queries x86-64/ARM64, Windows/macOS/Linux, MSVC/Clang/GCC

IFP benchmarking includes baseline, scaling, read/write mix, smart contract logic transfer, and multiple adversarial injections (e.g., 200 Mbps DDoS, 30% Sybil insertion, link failures). Interval computation benchmarking orchestrates basic to application-level expressions, running exhaustive and performance-tuned evaluations under diverse system configurations (Kazemi et al., 2021, Tang et al., 2021).

5. Automation and Implementation

IFP InterBench

  • Repositories and Components: Open-source under Apache 2.0. Python asyncio orchestrator (/orchestrator), Go workload generator (/cw_gen), Java IFP adapters (/ifp_adapters), Node.js TBM (/tbm), React/D3-based reporter (/vrs).
  • Automation: Deployable via Docker Compose, Helm; command-line launching (“interbench” CLI) from YAML.
  • Data Aggregation: All events logged in JSON-lines to ElasticSearch; aggregation via Spark jobs, visualized through Kibana; CSV/JSON exports standardize metrics per run.

Interval Computation InterBench

  • Directory Structure: Standard layout with config/, expressions/, inputs/, reference/, build/, results/, and scripts/.
  • Integration: New interval libraries register via libraries.json, specifying headers, CMake hooks, namespaces, and modes; example code fragments ensure API conformance.
  • Build Automation: Python scripts invoke platform-appropriate builds, execute, and collect outputs.
  • Reporting: Post-run aggregation and plotting tools enable bar charts, runtime lines, and histograms for all benchmarks.

6. Real-World Use and Comparative Analyses

Outcomes from InterBench execution—by maintaining identical benchmark specifications—facilitate side-by-side performance, security, and scalability analyses. For IFPs, architects can trace trade-offs such as throughput versus atomicity (e.g., λAION>λICON\lambda_{\text{AION}} > \lambda_{\text{ICON}} with AICON=1.0A_{\text{ICON}}=1.0 vs.\ AAION=0.995A_{\text{AION}}=0.995 under adversarial conditions), plot percentile latency against concurrency, or chart attack-tolerance degradation (ϵ\epsilon) under stress. For interval arithmetic, one can systematically compare correctness rates, error distributions, and runtime profiles of competing libraries per system configuration (Kazemi et al., 2021, Tang et al., 2021).

7. Extensibility and Standardization

Both variants employ configuration-driven extensibility. In IFP benchmarking, new relay and blockchain adapters are pluggable, with all microservices independently deployable and scalable. For interval computation, library integration necessitates only minimal C++ API compliance and an update to configuration JSON files; the protocol’s data-driven workflow underpins rapid onboarding and uniform evaluation of future arithmetic systems. The standardized metric definitions and open-source automation enable reproducible, fair, and transparent benchmarking across diverse research and production settings.


References: (Kazemi et al., 2021) Towards Automated Benchmark Support for Multi-Blockchain Interoperability-Facilitating Platforms (Tang et al., 2021) A Cross-Platform Benchmark for Interval Computation Libraries

Definition Search Book Streamline Icon: https://streamlinehq.com
References (2)

Topic to Video (Beta)

No one has generated a video about this topic yet.

Whiteboard

No one has generated a whiteboard explanation for this topic yet.

Follow Topic

Get notified by email when new papers are published related to InterBench Protocol.