Skip to content
Ephernity

§ 04 · Reference architecture

Architecture — how the parts fit.

Ephernity is built from small, well-defined modules. The storage pillar holds tamper-evident entries; the compute pillar runs deterministic contracts whose every step is itself an entry. Each module has a single job; together they compose the protocol's two pillars on one substrate.

Reference deployment · single host

SUBSTRATE DENSE flat-KVM · DEMIX Firecracker · Native host STORAGE MemStore · BadgerDB RFC-EPH-003 VAULT AES-256-GCM per-entry keys crypto-shred CHAIN-ANCHOR OpenTimestamps · L2 · EBSI RFC-EPH-007 CORE · micro-ledger blake3 · ed25519 · falcon append · read · verify · shred · promote PROOFS Merkle checkpoints RFC-6962 · BLAKE3 inclusion + consistency TRUST HATP root → tenant → host measured boot + offline-verifiable chain NETWORK libp2p gossip · Raft replication strong consistency per ledger § ARCH · 01 Ephernity node, one host.

§ 04.02

The modules.

blake3shim

RFC-EPH-002

BLAKE3-256 content addressing; tree-hashing for incremental verification.

ledgercodec

RFC-EPH-003

The 131-byte canonical EntryHeader encoder/decoder. Cycle-counted.

ledgerstore

RFC-EPH-003

MemStore + BadgerDB backends behind a small storage interface.

merkle

RFC-EPH-004

RFC-6962-BLAKE3 trees; inclusion + consistency proofs.

hatp

RFC-EPH-005

Three-level trust delegation with offline verification.

vault

RFC-EPH-006

AES-256-GCM per-entry key store — the unit of crypto-shred.

tiers

RFC-EPH-006

Tier policy + TTL sweep + promotion semantics.

chainanchor

RFC-EPH-007

Proof-only anchoring: OpenTimestamps + L2 backends.

falcon

RFC-EPH-010

Falcon-1024 CGO shim for post-quantum signing on durable tiers.

denseverify

RFC-EPH-009

Crypto-verify path inside a flat KVM guest — microsecond-class.

ledger

—

The core: Append / Read / VerifyChain / Shred / Promote.

network

RFC-EPH-008

libp2p gossip hub + Raft consensus per ledger.

§ 04.03

Three substrates — same source.

The same Borz source compiles to three execution targets. Each one is matched to a tier — but the wire format is identical, so an entry produced on one substrate verifies on any other.

borz listing 
DENSE   flat-KVM         microsecond hot path; many ledgers per host    → T0, T1, verify
DEMIX   Firecracker MVM  per-tenant isolation, snapshot hot-pool          → T1, T2
Native  Go host          Raft + Badger, libp2p gossip                     → T2, T3, T4
The substrate triple

DENSE, DEMIX, and the surrounding mesh are published as a separate product family at decentedge.com; Ephernity references them as substrates without requiring them.

§ 04.04

The compute pillar, on the same substrate.

A deterministic contract is an actor whose persistent state lives as entries on a state-ledger. Every step reads the head of the state-ledger, consumes a message from the input-ledger, and writes the next state plus any responses as further ledger entries. The same hash chain, same HATP attestation, same Merkle checkpoint apply.

borz listing 
input-ledger:    [..., msg_n]                 // append: signed inbound message
                          │
                          ▼
contract.step(prior_state, msg_n, env)
                          │   reads head(state-ledger)
                          │   forbids non-determinism
                          ▼
state-ledger:    [..., state_{k+1}]            // append: next state
output-ledger:   [..., response_n]             // append: response
                          │
                          ▼
verifier:        replay step(prior_state, msg_n)
                 assert blake3(next_state) == header(state_{k+1}).payload_cid
                 → proof
A contract step, as committed entries

Per-call accounting ( RFC-EPH-CMP-003 ) tallies bytes-in, bytes-out, and deterministic operations on each step. Pricing is set by the operator and is outside the protocol; the unit-of-work is inside.