EBSI: European Blockchain Services Infrastructure

• EBSI is a European public permissioned blockchain infrastructure that provides secure cross-border digital services such as self-sovereign identity and diploma certification.
• It employs a multi-layer architecture and projects like TrustVault and GLASS to operationalize verifiable credentials and decentralized data management.
• The network ensures robust security and regulatory compliance through hybrid consensus mechanisms, on-chain governance, and GDPR-aligned privacy measures.

The European Blockchain Services Infrastructure (EBSI) is a public permissioned blockchain operated under the European Blockchain Partnership to provide cross-border digital services such as self-sovereign identity, diploma certification, document notarization, social security, SME finance, and healthcare data sharing for EU citizens and institutions. EBSI establishes a multi-layered, permissioned blockchain protocol for secure credential lifecycle management, anchored governance, and privacy-preserving, citizen-centric data exchange. Key integration projects—including TrustVault and GLASS—demonstrate the operationalization of verifiable credentials, decentralized identifiers (DIDs), and distributed file management within this regulatory-aligned European infrastructure (Jacobino et al., 2022, Kasimatis et al., 2022).

1. Network Architecture and Governance

EBSI follows a multi-layer reference architecture:

Layer	Technical Components	Responsibilities
Business Application	Citizen/enterprise apps (wallets, diplomas, notary services)	Utilization and consumption of EBSI services
Core Services	Integration APIs, wallet SDK, smart contracts (DID, TIR, TSR)	Trusted registries, VC and revocation, policy
Chain & Storage	Permissioned public blockchain (IBFT, Quorum/Besu, Fabric), IPFS	Consensus, data storage (on/off-chain)
Infrastructure	Physical/virtual hosts (Kubernetes, Docker), EBSI nodes	Compute/network, validator operation

• The network comprises 25–27 equally privileged validator nodes (operated by EU/EEA states and accredited partners), all forming an IBFT2.0 consortium. Each Member State may operate multiple nodes in the Infrastructure layer; additional Fabric peers support private collections and IPFS endpoints (Kasimatis et al., 2022).
• Core on-chain registries include the DID Registry, Trusted Issuers Registry (TIR), and Trusted Schemas Registry (TSR), all implemented as smart contracts (Jacobino et al., 2022).
• Governance is enforced via foundation and EU Commission oversight, with steering committee representation from all Member States. On-chain policies (e.g., issuer and schema author inclusion) are codified and enforced in TIR/TSR smart contracts, and any protocol updates proceed via multi-party on-chain governance proposals with majority approval of validator operators (Jacobino et al., 2022).

2. Consensus Mechanisms and Security Model

EBSI’s blockchain backbone utilizes hybrid consensus mechanisms:

• IBFT 2.0 (Besu/Quorum): Validators run Istanbul BFT, which achieves deterministic finality in two phases (PREPARE/COMMIT) with safety ensured for $n \ge 3f + 1$ (where $f = \lfloor (n-1)/3 \rfloor$). Each block is proposed by round-robin; liveness and safety follow IBFT2.0 standard proofs (Kasimatis et al., 2022).
• Fabric Endorsement/Ordering: For off-chain private collections (notably the GLASS project), Fabric uses endorsement policies (e.g., OR logic on member roles), Raft ordering (CFT), and microservices for recording and validating private data (Kasimatis et al., 2022).

The chain is public permissioned: anyone may read chain state, but only permissioned peers can propose and sign blocks. Node membership changes and transaction write permissions are governed by on-chain smart contracts and a roles/attributes registry (Kasimatis et al., 2022).

3. Identity Management: DIDs, Verifiable Credentials, and Authorization

EBSI implements a digital identity framework conformant to W3C DIDs and Verifiable Credentials (VCs):

• Each citizen/entity is assigned a DID of the form $$\mathrm{did:ebsi:\langle network\rangle:\langle Base58(publicKey)\rangle}$$, with DID Documents (JSON-LD) recording authentication/public keys (Kasimatis et al., 2022).
• Credential structure follows the W3C VC model. Credentials are issued as JSON-LD, signed with elliptic-curve keys (typically secp256k1 or secp256r1) via JSON Web Signatures (JWS) (Jacobino et al., 2022).
• On-chain DID Registry and TIR/TSR contracts are used to discover issuer/verifier public keys and schema definitions. All credential lifecycle operations—issuance, verification, and revocation—occur through defined protocols (see credential lifecycle below) (Kasimatis et al., 2022).

Cryptographic infrastructure includes:

• ECDSA over secp256k1 for signature generation/verification, with standard key generation and signing algorithms formalized in LaTeX (Kasimatis et al., 2022).
• JSON-LD Proofs, Zero-Knowledge Proofs for predicate-enabled selective disclosure (BBS+, Camenisch–Lysyanský range proofs) (Jacobino et al., 2022).
• Attribute-based access control (ABAC) is evaluated via local Boolean policy trees, where per-file and hierarchical policies are expressed as Boolean expressions over credential subjects' attributes and enforced on the end device (Jacobino et al., 2022).

4. Credential Lifecycle: Issuance, Verification, Revocation

Credential management protocols in EBSI operate as follows:

• Issuance Protocol: The issuer $I$ forms $$\mathcal{C} = (\mathrm{did}_S, \mathrm{claims}, \mathrm{issuanceDate})$$, signs it to produce $\sigma_I = \mathrm{Sign}_{x_I}(H(\mathcal{C}))$, and publishes $$\langle \mathrm{did}_I, \mathrm{did}_S, H(\mathcal{C}), \sigma_I \rangle$$ to the ledger (Kasimatis et al., 2022).
• Verification Protocol: The verifier $V$ queries EBSI for the issuer's DID and public key $Q_I$, verifies $\mathrm{Verify}_{Q_I}(H(\mathcal{C}), \sigma_I)$, and checks that the credential is not revoked using the revocation registry (Kasimatis et al., 2022).
• Revocation Protocol: Issuers can revoke a credential hash $h$ via a designated transaction; verifiers check current status through the isRevoked view function on-chain (Kasimatis et al., 2022).

A summary of the credential flow ( Editors’ term: VC Lifecycle):

• Wallet onboarding: DID registration on EBSI by the holder.
• Issuance: JWT-signed VC requests, with responses received by digital wallets.
• Presentation: Verifiable Presentation (VP) with traceable holder and issuer DIDs.
• Validation: On-chain key/path resolution; JWS proofs.
• Revocation: On-chain registry lookup ensures real-time credential status verification (Kasimatis et al., 2022).

5. Decentralized Applications and TrustVault/GLASS Integration

Two major DApp integration models leverage EBSI for user-controlled, GDPR-aligned services:

• TrustVault: This mobile digital wallet and encrypted data vault executes ABAC-driven file sharing using EBSI credentials. TrustVault is architected as two tightly coupled agents: a data vault for encrypted storage plus policy evaluation, and a digital wallet for key management, DID onboarding, and VC management. Fine-grained, chain-driven access control and P2P data exchange (IPv8 overlay) obviate the need for Trusted Third Parties (TTPs) or centralized servers. ABAC policies are Boolean expression trees over VCs; enforcement occurs locally with ZKP-enabled predicate proofs for minimum data disclosure (Jacobino et al., 2022).
• GLASS: The GLASS H2020 project extends EBSI’s chain-based identity to integrate distributed file storage (IPFS) and privacy-preserving credential workflows. Process flow includes encryption of documents (e.g., diplomas via AES-GCM), Fabric private collections for triplet storage (CID, URI, EncKey), and EBSI-verifiable credential proofs for cross-domain verifications. Chaincode in Go-style enables granular tracking, storage, and lookup of document metadata and keys (Kasimatis et al., 2022).

The table below compares properties of these integration models:

Property	TrustVault	GLASS
Storage	On-device encrypted vault, P2P via IPv8	Off-chain (IPFS), Fabric private
Policy engine	Local ABAC, ZKP predicates	Chaincode policies, roles
Presentation mechanism	Verifiable Presentation (VP), fine-grained	VP; controlled access via CID
Revocation	On-chain, DID-based	On-chain, roles and CID

6. Evaluation, Performance, Privacy and Regulatory Compliance

Empirical studies across pilots and testbeds have demonstrated:

• Performance: IBFT2.0 achieves $\sim$50 TPS with 25 nodes and deterministic finality (prepare/commit). Fabric ordering approaches 350 TPS for private chaincode. Diploma verification pilots observed $<$5 second end-to-end issuance + verification, including sub-150ms network RTTs and $\sim$2s IBFT finality. TrustVault P2P file fetch (Wi-Fi) yields $\sim$260kB/s, with full file access in 780ms for 220kB files under light load (Jacobino et al., 2022, Kasimatis et al., 2022).
• Security Guarantees: Byzantine fault tolerant for $f < n/3$; data encrypted at rest (AES-CTR), in transit (EC-encrypted packets); audit logs on TrustChain; ZKPs for selective disclosure (Jacobino et al., 2022, Kasimatis et al., 2022).
• Privacy and Compliance: Full GDPR conformance: no third-party data processing, all sensitive personal data stored locally or in citizen-controlled applications; no incidents reported in >10,000 wallet pilot phase (Kasimatis et al., 2022).
• Operational limitations: Local-only wallets risk user-managed backup failures; UDP P2P congestion impacts TrustVault performance under concurrent load; system trust is contingent on EBSI public node uptime (Jacobino et al., 2022).

7. Significance and Use Cases

EBSI provides the infrastructural basis for cross-border digital public services throughout Europe, supporting eIDAS-qualified digital signatures and high-assurance, issuer-verifiable credentials in domains including academia, health, finance, asylum, and social services (Kasimatis et al., 2022). Notable pilots confirm the feasibility and regulatory fitness of these implementations, as evidenced by diploma management and Self-Sovereign Identity services, where over 1,000 diplomas were issued (zero on-chain validation failures) and 10,000 wallets registered without GDPR incidents (Kasimatis et al., 2022). The open, permissionless application architecture supports third-party DApps, with access policies and cryptographic proofs evaluated under strict regulatory and availability constraints (Jacobino et al., 2022, Kasimatis et al., 2022).