Build and run

BlockchainBench is a set of Eclipse PDE bundles. Building and running it means importing the bundles into an Eclipse workspace with a target platform that provides the Palladio blockchain systems plug-ins, then launching one of the two applications as an Eclipse Application.

Prerequisites

• Eclipse with the Plug-in Development Environment.
• A target platform that supplies the required plug-ins declared in the core bundle’s MANIFEST.MF: the Palladio org.palladiosimulator.blockchainsystems.* bundles (bscm, core, threesim, doublespending, plugin, loggers, kotlin-deps), the tools.mdsd.library.standalone.initialization* bundles, and the usual supporting libraries (Gson, Guava, log4j, commons-math, JGraphT).
• A Java 21 runtime; every bundle declares JavaSE-21.
• The JavaFX runtime on the module or class path for the desktop bundle.

The bundles

Bundle	Kind	Notable manifest entries
org.blockchainbench.utils	shared library	exports models and services; requires Gson and log4j
org.blockchainbench.core	engine	exports simulation; requires the Palladio and mdsd bundles and Utils
org.blockchainbench.desktop	application	contributes an Eclipse application; requires Core and Utils
org.blockchainbench.server	application	contributes an Eclipse application; requires Core and Utils

Running

Both runnable bundles register an application through their plugin.xml. The resulting application ids are:

• Desktop: org.blockchainbench.desktop.id1 (runs Launcher, which boots the JavaFX UI).
• Server: org.blockchainbench.server.id1 (runs SimulationApplication, a headless batch).

Launch either with a Run As → Eclipse Application configuration that selects the corresponding application. The desktop opens the configuration screen; the server runs one default batch and exits after printing a result summary.

The process working directory must contain the data/ folder, because all configuration and model paths are resolved relative to it.

Data layout

data/
  configuration.json                              # BaseConfig (shared parameters)
  optimized_deterministic_lhs_configurations.csv  # SimulationConfig rows (default CSV)
  testmodels/
    threesim-<config_id>/                          # one model folder per configuration
      Net.blockchainsystem
      Net.p2pnetwork
      Net.nodeallocation
      Net.bscmrepository
      Net.transactions
      ...

Each configuration has exactly one model folder, threesim-<config_id>, holding the BlockchainSystem model and its co-located EMF resources. The deterministic fallback in ConfigManager.pickModelPath maps a config_id onto testmodels/threesim-<config_id>/Net.blockchainsystem.

Configuration formats

The base configuration is a JSON object. Numeric values may be written as JSON strings; Gson coerces them onto the typed BaseConfig fields.

{
  "simulationType": "Monte-Carlo",
  "maxAllowedBlockchainLength": "10",
  "numberOfMonteCarloRounds": "9",
  "blockchainSystemModelFilePath": ".../threesim-net-base/Net.blockchainsystem",
  "failureThroughputThreshold": "1.0",
  "shannonEntropyK": "1.0",
  "nakamotoCoefficientThreshold": "50.0",
  "reliabilityObservationTimespan": "24.0"
}

simulationType selects the simulation kind: the value Monte-Carlo runs a Monte-Carlo simulation with numberOfMonteCarloRounds rounds; any other value runs a single simulation. The four thresholds feed the Threesim evaluation metrics.

The experiment set is a CSV whose header names bind directly to SimulationConfig fields. One row is one configuration:

config_id,Hnode,Hlink,block_creation_interval,hashrate_concentration,max_block_size,inbound_connections,outbound_connections,validator_count,number_of_attackers
1,6.079354535,9.010945456,429,0.344605264,4,50,3,4908,25

The repository ships several CSV variants (a default, split subsets 1 and 2, and bookkeeping files for used and skipped configurations) and a large testmodels/ set of ready-made model folders.

Outputs

Runs write one JSON document per run, under indiv_json/ for normal runs and result_selfishmining/ for attack runs, named result_run_<simId>_<runId>.json. Each document is a typed SimulationRun as described in Utils. The same objects are also available in memory through SimulationInfo.results once a group has finished.