Glossary

The vocabulary used across the codebase and this documentation, organized by topic.

Blockchain and domain concepts

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

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

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.

Simulation and experimentation

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.

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.

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.

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.

Configuration and execution

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, CANCELLED).

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.

Metrics and evaluation

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.

Pareto front. The set of runs that no other run of the group dominates — the equally valid best compromises between the three axes. See How the Pareto calculation works.

Architecture and interfaces

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

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

Eclipse and modelling infrastructure

Eclipse. The development ecosystem in which the BlockchainBench components are implemented and packaged. The project makes use of Eclipse technologies including PDE, OSGi, and EMF.

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.

Eclipse PDE (Plug-in Development Environment). The Eclipse development environment used to build and launch the project’s OSGi bundles.

OSGi. The modularity framework underlying the Eclipse plug-in architecture. The project’s modules are packaged as OSGi bundles with declared dependencies and exported packages.