Glossary

The vocabulary used across the codebase and this documentation, in one place.

Blockchain trilemma. The observation that a blockchain system trades off three properties — throughput (scalability), decentralisation, and security or reliability — and struggles to maximise all three at once. A normal run in BlockchainBench measures metrics along these axes.

Selfish mining / double-spending attack. An adversarial strategy where an attacker withholds or reorders blocks to win a fork and, in effect, spend the same funds twice. The attack mode runs the Palladio double-spending simulation and classifies each round’s outcome (attacker won, system won, or ambiguous).

Monte-Carlo simulation. Running the same configuration many times with randomised draws and aggregating the outcomes, reported as averages with a standard deviation and a coefficient of variation. Selected by simulationType = "Monte-Carlo" with numberOfMonteCarloRounds rounds. The alternative is a single deterministic run.

Nakamoto coefficient. A decentralisation measure: the smallest number of participants that together control a majority of some resource (for example hash rate). nakamotoCoefficientThreshold in the base configuration sets the evaluation threshold.

Shannon entropy. An information-theoretic measure of how evenly a resource is distributed across participants, used here as a decentralisation metric. Parameterised by shannonEntropyK.

Latin Hypercube Sampling (LHS). A stratified sampling method for exploring a parameter space efficiently. The experiment CSV files (optimized_deterministic_lhs_configurations*.csv) are generated this way; each row is one sampled configuration.

3SIM (Threesim). The Palladio simulation engine for blockchain systems that BlockchainBench drives. It provides the single and Monte-Carlo simulations, the blockchain-system factories, and the result serialisers used by the core factories.

BSCM. The blockchain-system component model: the Palladio metamodel describing a blockchain system — its network topology, node allocation, component repository, and related resources. A concrete model is loaded from a testmodels/threesim-<id>/ folder as an .blockchainsystem file plus co-located resources.

Palladio. The model-based software-architecture simulation framework the blockchain-systems tooling is built on. BlockchainBench uses it in standalone mode, outside a full Eclipse UI session.

EMF (Eclipse Modeling Framework). The modelling runtime that loads and resolves the BSCM models. It is not thread-safe, which is why the engine processes runs on a single worker thread.

Standalone initialisation. The step that prepares Palladio and EMF to run without the full Eclipse platform. BlockchainBench performs it through the tools.mdsd standalone-initialisation library, once per simulator mode, inside AbstractStandaloneSimulator.

OSGi bundle / Eclipse PDE plug-in. The unit of modularity here. Each of the four modules is a bundle with a MANIFEST.MF declaring its exported packages and required bundles. The Plug-in Development Environment builds and launches them.

IBlockchainBench. The single interface the front ends use to drive the engine: submit a group of runs, query its progress and results, set a fallback base configuration, and shut the worker down.

Base configuration (BaseConfig). The parameters shared by a whole submitted group: simulation type, length and round bounds, an optional group-wide model path, and the evaluation thresholds. Loaded from configuration.json.

Simulation configuration (SimulationConfig). One experiment — a single CSV row describing a blockchain-system configuration (hash-rate parameters, connection counts, validator and attacker counts, and so on).

Run and group. A group is one submit call, tracked by a SimulationInfo; it contains one run (RunInfo) per configuration. Both carry a RunStatus (QUEUED, RUNNING, FINISHED, ERROR).