Skip to main content
European CommissionEBSI European Blockchain
Get Help

Understanding EBSI's Blockchain Ecosystem

Let's take a look at the technical intricacies of EBSI's blockchain foundation and what helps this advanced infrastructure drive public services innovation in Europe.

illustration regarding Understanding EBSI's Blockchain Ecosystemillustration regarding Understanding EBSI's Blockchain Ecosystem

What can you do with Blockchain?

Holder wallet illustration

Understanding the technology

Read More
Holder wallet illustration

Understanding how EBSI uses it

Read More

Why blockchain is important for EBSI

The European Blockchain Services Infrastructure (EBSI) is a cutting-edge blockchain network designed for public services. Developed over 5+ years, EBSI is now ready for production. It connects nearly 40 public bodies from all European countries through a unified blockchain network, sharing data seamlessly across a shared ledger.

EBSI is a peer-to-peer network that spans all 27 EU Member States as well as Norway and Liechtenstein, interconnecting various public institutions with the goal of enhancing access to cross-border public services.

Evolution of the network

Starting with just four initial nodes, EBSI has evolved into a stable network of 40 nodes (peers) distributed across Europe. This expansion has made it the largest pan-European blockchain designed specifically for cross border public services and aimed at serving all European citizens.

EBSI has evolved from a single environment to six distinct environments, each deployed with a specific scope. These environments, based on the nodes connected within the network of each environment, are divided into:

  • Environments fully hosted by the European Commission (EC):
    • Development: A temporary environmnent used for infrastructure tests.
    • Test: A permanent environment for testing developed EBSI services.
    • Conformance: A permanent environment for various conformance tests by Wallet Providers and other Application Providers.
  • Environments fully hosted by Node Operators in Member States (including Norway and Liechtenstein):
    • Pilot: An environment for piloting different use case applications. This is the environment where all EBSI services are deployed.
    • Pre-Production: An environment that serves as the staging area for services ready for production.
    • Production: The environment fully dedicated to all production-ready services and use case applications.

Taxonomy

EBSI is a public, permissioned blockchain network that offers public APIs for interacting with its ledger. It has a strict procedure for allowing nodes (peers) to join the network, either as regular nodes or validator nodes.

The network's read capabilities are publicly accessible, providing free access to ledger information, while write access is restricted to authorised parties to maintain data trustworthiness.

It's permissioned, allowing peer connection to authorised node operators only, following a rigorous onboarding process. Validator node status is granted through democratic voting among compliant nodes.

EBSI also employs a proof of authority (PoA) consensus mechanism, ensuring low power consumption per node (averaging 100Wh), making it highly energy efficient.

HyperLedger Besu

Hyperledger Besu is an enterprise-friendly Ethereum client suitable for both public and private permissioned blockchain network use cases. It is also EVM (Ethereum Virtual Machine) compatible, which signifies that EBSI can support the deployment of smart contracts written in Solidity, executable by the EVM in a decentralised manner.

Besu offers a command-line interface and JSON-RPC API for Ethereum node management, accessible via HTTP or WebSocket. It supports Pub/Sub and common smart contract development tools like Truffle, Remix, and web3js. While Besu does not support key management, Ethsigner can be used alongside Besu to access the keystore and sign transactions.

Licensed under Apache 2.0 and written in Java, Hyperledger Besu is an open-source Ethereum client maintained by a broad community and the Hyperledger Foundation. It's extensively used in enterprises to establish public or private blockchain networks, and was selected as the optimal solution for the EBSI initiative.

Configuration of EBSI

The EBSI public blockchain network is formed by Node Operators from all the EU Member States as well as Norway and Liechtenstein. A Node Operator is a public institution from a Member State that hosts a virtual machine where the full EBSI node stack is deployed.

There is a formal onboarding process for Node Operators per environment, allowing only authorised nodes to join the network. The EBSI blockchain network uses the QBFT consensus mechanism, where approved accounts, known as validators, validate transactions and blocks. All the validators take turns creating the next block, which requires a super-majority (greater than or equal to 2/3) of validators' signatures before the new block is added to the chain.

Existing validators can propose and vote to add or remove validators. A validator is added to the network once more than 50% of existing validators vote in favour, allowing the new validator to start validating blocks. Conversely, a validator is removed from the pool when more than 50% of existing validators vote for their removal, ceasing the validators' ability to validate blocks. Each environment represents a separate EBSI blockchain network with different network IDs.

Each EBSI network contains two types of nodes:

  • Validator nodes: Propose and sign new blocks.
  • Regular nodes: Maintain a copy of the ledger and stay in sync with the network.

A minimum of 4 validators is needed to start the network, but at least 15 are needed to ensure the security of the network and ledger. There are no technical limitations on the minimum or maximum number of regular nodes needed in the network, but a minimum of 10 is preferred for network reliability, ensuring sufficient peers to handle API calls.

Based on internal tests, we were able to successfully validate a network with up to 120 validators. A higher number is possible, but was not tested in the context of EBSI.

Configuration of the Besu client

As the Besu client has multiple configuration options, the specific configurations for each of the three public environments in the EBSI Blockchain Network are listed below:

Besu ConfigurationEBSI Pilot EnvironmentEBSI PreProd EnvironmentEBSI Prod Environment
Blockchain Network ID617961806177
Operate with free gas (for the moment)YESYESYES
Sync mode - store the full ledgerYESYESYES

Additional network details are specified in the genesis file, which is unique to each environment or network. This file includes the following specifications:

  • The chain id (network id) is specified in the genesis file, ensuring the Besu client connects to the correct network.
  • The period between two blocks is set to 8 seconds, providing enough time for synchronisation across the pan-European, heterogeneous network.
  • 75M EBSI ether minted to a multisig wallet address, currently held in reserve for potential future use.
  • The maximum size for deployed contracts is capped at 24KB.
  • The maximum gas limit per block is 20M.

Furthermore, interaction with the Besu client is allowed only through APIs. This method prevents unauthorised calls to the Besu client, as the authentication process allows only authorised actors to write data on the ledger (to submit blockchain transactions).

Smart Contracts deployed in EBSI

EBSI exposes a set of APIs for users to interact with its blockchain ledger, but the core functionality is managed through Smart Contracts. These contracts act as gatekeepers, ensuring that operations proceed only when specific conditions are met. EBSI has strict control over these contracts to guarantee that only legitimate operations are executed and only authorised administrators can make updates. For example, the Smart Contracts ensure that only accredited trusted issuers are able to record transactions on the trusted issuers' registry.

All EBSI's Smart Contracts were audited by specialised experts and passed all security checks.

Smart ContractBrief Description
DID-REGISTRY-V4A repository for storing and managing DID documents.
Ownership: DID transactions like register/update did document are signed by legal entities.
TRUSTED-ISSUERS-REGISTRYA service anchor for Trusted Issuers, enabling verification of issuer DIDs and their authorisations.
Ownership: TIR transactions like register/updates authorisations are signed by trusted issuers.
TRUSTED-SCHEMAS-REGISTRYA service anchor for verifying trusted schemas and their statuses.
Ownership: TSR transactions like register/update schemas are signed by EBSI's support office or developers.
TRUSTED-APPS-REGISTRYAn anchor of trust, listing trusted apps and their details for access management across EBSI services.
Ownership: TAR transactions like register/update apps are signed by EBSI's support office or developers.
TRUSTED-POLICIES-REGISTRYA service facilitating authorisation across the project by defining the policies applicable to all the EBSI services.
Ownership: TPR transactions like register/update policy are signed by EBSI's support office or developer.
TIMESTAMPA service for storing versioned hashes.
Ownership: Timestamp transactions like register/update a hash are signed by legal entities.
BOOTSTRAPA set of libraries used throughout the project.
A set of smart contracts that provides different utilities for all the above smart contracts, like paginations and upgradeability.
PROXYA service offering proxy functionality, delegating calls to other smart contract deployed on the network but keeping the context in the current contract, hence, the implementation contracts can access the storage of the proxy contract and write to it. It is used to be able to update the logic (deploy new implementation contracts) without changing the address of the contract that stores data (the proxy).