IPPAAS · EXPERIMENTAL BLOCK INSPECTION

Blockchain Explorer

Inspect Block H (History Block) canonical transition evidence and Block D (Data Block) current materialized state, including available experimental ciphertext. Read-only public interface; the inspection adapter must be verified before block data are exposed.

Experimental datasetRead-onlyVerification-aware

Inspect a Validator

Checking read-only block adapter…

Canonical Blocks

Waiting for canonical block index…

Full Block Body

Select a verified canonical block to view its available fields.

No block selected.

Synthetic Identity & Key Registry

Showcase identities are fully synthetic. NodeMaster is the proposed demo signature operator, while the same IPPAAS validation and erasure rules must apply as in production.

Loading approved demo-only identity manifest…

Key boundaries: Published recipient X25519 wrapping/decryption private keys are for approved synthetic ciphertext only. Signing private keys remain private while accepted for authorization. Never enter a real private key into this showcase.

Interactive Cryptographic Verification

DEMO NOT CONFIGURED — Awaiting a separately generated experimental key pair and test fragment verified against the canonical EBP encryption scheme.

This module will allow visitors to inspect ciphertext and verify decryption of an approved dummy fragment in their own browser. Operational keys, validator credentials, and active signing private keys must never be disclosed. Published demo recipient decryption keys intentionally make matching synthetic ciphertext locally decryptable, but do not establish retroactive revocation or confidentiality against a key holder. A successful decryption demonstrates an authenticated cryptographic round-trip, not blockchain consensus, authorization, or erasure.

Requires a qualified V3 envelope and a reviewed in-browser X25519/HKDF/ChaCha20-Poly1305 implementation. No private key is sent to any server.

No verified demo fragment selected.

Proof of Erasure (PoE)

Inspect erasure H-blocks and verify the proof returned by the canonical EBP protocol. This section distinguishes a committed erasure request from successfully verified Proof of Erasure.

Awaiting a canonical erasure block index and read-only PoE verification adapter.
Erasure H-block ID—
PoE identifier—
Final current root—
Verification statusNOT VERIFIED
Source / observed at—

Canonical PoE verifies ledger-derived prior existence, committed authorization and transition, current absence, valid terminal state and historical anchor preservation. Native read-only verification uses VERIFY_POE for a specific erasure H-block ID and reports POE_OK with poe_id and final_current_root. The public adapter must verify and explicitly attest this response; the UI does not infer PoE validity from COMMIT_ERASE journal entries, and does not expose historical erased fragments.

Verification Boundaries

Committed journal requests are not interchangeable with canonical Block H and Block D representations. Ledger-grounded Proof of Erasure (PoE) is not merely an unverified deletion receipt. A read-only inspection adapter must provide independently checked block identity, body, provenance and current erasure state. Historical erased payloads must not be resurrected from stale snapshots.