Hologram Whitepaper

[afflom]

The Hologram

A Technical Introduction to a Coherence‑Preserving Internet Substrate

---

Abstract

The Hologram is a two‑dimensional, toroidal data structure of 12,288 elements arranged as 48‑element pages across 256‑element cycles. Two closure laws—one per axis—govern admissible states. Systems built on this substrate treat computation, transport, authorization, and settlement as sequences that preserve these laws. The design removes external trust anchors: correctness reduces to local, deterministic verification of closure and provenance.

---

1. Introduction

Separate stacks exist for virtual machines and containers, software distribution, digital currencies, and formal verification. They introduce distinct control planes and inconsistent safety models. The Hologram adopts a single base rule—conservation—and encodes all layers as transformations that must satisfy it.

This document defines:

• the substrate (Section 2),
• the acceptance procedure (Section 3),
• derived constructions (Sections 4–8), and
• the relation to existing techniques (Section 9),
• plus security, evaluation, interfaces, and scope (Sections 10–13).

The intent is descriptive and technical; no deployment assumptions are required to understand or verify the model.

---

2. Model

Let the alphabet Σ be finite. The default instantiation uses bytes with additive group $(\mathbb Z/256\mathbb Z, +)$.

• Page modulus P = 48.
• Cycle modulus C = 256.
• Cardinality N = P·C = 12,288.
• Indices: page p ∈ ℤ₄₈, cycle c ∈ ℤ₂₅₆; linear index i = c·P + p, $0 ≤ i < N$.
• State space: H = Σ^{P×C} = { H : ℤ₄₈ × ℤ₂₅₆ → Σ } with wraparound in both axes.

2.1 Conservation laws (L0)

There exist functionals $I_P: Σ^{P}→Σ$ and $I_C: Σ^{C}→Σ$ such that for all c and p: $I_P(H[·,c]) = 0, \qquad I_C(H[p,·]) = 0.$ The default uses modular sum; XOR is an equivalent bitwise form. Translations along pages or cycles preserve the equations.

2.2 Immediate consequences

1. Cardinality: $N = 12{,}288 = 48×256 = 2^{12}×3$.
2. Addressing: 14 bits suffice ($2^{13} < N ≤ 2^{14}$).
3. Global dependency: the sum of all page‑sums equals the sum of all cycle‑sums and equals the global sum; one check is algebraically determined.
4. Natural tilings: $12{,}288$ factors as $192×64$, $128×96$, $384×32$, etc.

2.3 Working example (closure‑preserving construction)

Define $a[p] = 1$ for $0≤p<24$, and $a[p]=255$ for $24≤p<48$. Define $b[c] = (16·c)\bmod 256$. Then $H[p,c] = (a[p] + b[c]) \bmod 256$ satisfies both closure equations.

Checks. For any c: $\sum_p H[p,c] = \sum_p a[p] + 48·b[c] ≡ 0\pmod{256}$. For any p: $\sum_c H[p,c] = \sum_c b[c] + 256·a[p] ≡ 0\pmod{256}$.

2.4 Canonical encoding details

• Byte order. Multi‑byte integers use big‑endian representation unless specified.
• Layout flag. A single byte encodes page‑major (1) or cycle‑major (0) ordering.
• Indexing example. With $p=17,c=200$, $i=200·48+17=9{,}617$. Inverse: $p=9{,}617\bmod 48=17$, $c=\lfloor 9{,}617/48\rfloor=200$.

---

3. Witnesses and Verification

A state is accepted if the following are true:

1. Local closure: for each cycle c, $I_P(H[·,c])=0$; for each page p, $I_C(H[p,·])=0$.
2. Provenance: a digest scheme commits to content and structure. A minimal scheme computes one hash per page (48 elements) and commits to a Merkle root over 256 leaves. Stronger profiles may add cycle hashes.
3. Serialization discipline: encodings preserve closure. Padding bytes are computed to maintain both equations.

Verification is local; no global consensus is required.

3.1 Algorithms (deterministic)

Closure check (cycle‑major):

for c in 0..255:
  s = 0
  for p in 0..47:
    s = (s + H[p,c]) mod 256
  reject if s ≠ 0
for p in 0..47:
  s = 0
  for c in 0..255:
    s = (s + H[p,c]) mod 256
  reject if s ≠ 0
accept

Time $O(N)$, memory $O(1)$ beyond streaming buffers.

Merkle construction (per‑page). Leaf$c$ = Hash( $H[0,c]∥…∥H[47,c]$ ). Root uses a fixed binary tree. If $C$ is not a power of two, duplicate the last leaf to fill the level; the index of each leaf is explicit.

Padding function. If the final element of a row/column is absent, compute it as the modular negative of the partial sum.

3.1.1 Canonical Merkle rules

• Hash function. SHA‑256 is the hash for leaves and internal nodes. Output is 32 bytes.

• Domain separation.

  • Leaf: H(0x00 ∥ leaf_bytes) where leaf_bytes = H[0,c]∥…∥H[47,c].
  • Node: H(0x01 ∥ left ∥ right).

• Ordering. The tree is indexed left‑to‑right by increasing leaf index c (0..255). For internal nodes, left is the subtree covering the lower index range.

• Arity/padding. The base profile has 256 leaves (a power of two). If other profiles are defined with non‑power‑of‑two leaf counts, pad by duplicating the last leaf to the next power of two.

• Endianness. All indices used in inclusion proofs are big‑endian unsigned integers.

3.2 Failure codes

• E_PAGE: a page equation fails.
• E_CYCLE: a cycle equation fails.
• E_ROOT: Merkle root mismatch.
• E_LAYOUT: serialization/layout invalid.
• E_STALE: stale or missing witnesses.

---

4. Identity and Addressing (L1)

Sections of H admit canonical identifiers. An identifier binds a serialization to its witnesses (closure equations and Merkle root). The addressing map $(p,c) ↔ i$ is a bijection over $[0,N)$. Typed references select pages, cycles, or blocks; dereference preserves closure because witnesses are part of the identifier.

Definition (identifier).

ID := encode( layout, hashRoot, closureWitness )

layout records ordering; hashRoot is the Merkle root; closureWitness is the minimal data to recompute padding during verification.

Example. A page reference includes the cycle index c, the corresponding leaf hash, and the Merkle branch needed to reconstruct the root.

4.1 Identifier binary format

A minimal binary form binds layout and witnesses deterministically.

struct UORID {
  u8    ver;        // 1
  u8    order;      // 0=cycle-major, 1=page-major (matches CEF)
  u8    hashAlg;    // 1=SHA-256
  u8    wAlg;       // 0=none, 1=mod-sum witnesses
  u8[32] root;      // Merkle root over pages
  u8    cwCount;    // count of closure-witness bytes (may be 0)
  u8[cwCount] cw;   // witness bytes, if any
}

• Canonicalization. If witnesses are recomputable from payload, set cwCount=0 and omit cw.
• String form. When needed, the binary is encoded with Base32 (RFC 4648) without padding.

---

5. Integrity and Exchange (L2)

The Coherent Exchange Format (CEF) preserves closure by construction and carries witnesses.

Record layout.

struct CEF_Record {
  u8    version;           // format version
  u8    order;             // 0=cycle-major, 1=page-major
  u16   length;            // bytes of payload (excluding witnesses)
  u8[48*256] payload;      // serialized H
  u8[48]     pcw;          // per-cycle/page closure witnesses (minimal)
  u32   leafCount;         // 256 in base profile
  u8[32] root;             // Merkle root (e.g., SHA-256)
}

5.1 Field semantics and canonicalization

• version: fixed at 1 for the base profile.
• order: 0 = cycle‑major, 1 = page‑major. Implementations MUST accept both and preserve the flag on re‑encode.
• length: MUST equal 12,288 in the base profile.
• payload: raw bytes of H in the chosen order.
• pcw (per‑closure witnesses): 48 bytes reserved. In the base profile these bytes are all zero and ignored during verification. Future streaming/fragmented profiles MAY use them to carry minimal closure fixups.
• leafCount: fixed at 256; included for explicitness.
• root: SHA‑256 Merkle root as defined in §3.1.1.

Round‑trip.* Decoding reconstructs $H$; re‑encoding yields the same root and closure result.

Inclusion proofs. A page can be verified independently by supplying its leaf index and Merkle branch.

---

6. Protocol Construction (L3)

Protocols are sequences of frames that must satisfy conservation over sliding windows.

Budget space. Let B = ℤ₉₆ with addition modulo 96. Each frame carries $b∈B$. Composition is addition.

Window admissibility. A window $W = [f_k,…,f_{k+L-1}]$ is admissible if (i) its closure holds and (ii) the composed budget satisfies the protocol rule $R(W)=\text{true}$.

Acceptance rule. A receiver advances on frame $f$ if the window containing $f$ closes (L0) and the accumulated budget meets the predicate.

Object operations. PUT, LINK, ATTEST modify a typed object graph. Acceptance requires preconditions and a valid budget. Replays and bit‑flips violate closure or Merkle checks and are rejected.

Loss and reordering. Windows carry indexes; gaps or duplicates cause rejection unless a protocol specifies recovery with fresh witnesses.

6.1 Window parameters and sequencing

• Sequence numbers. Each stream carries a 64‑bit unsigned frame index seq, incremented by 1 per frame.
• Window length. Denoted L (frames). Protocols choose L; receivers MUST apply the same L.
• Computation. For a window W = [seq..seq+L-1], compute closure and budget over the frames in index order; out‑of‑order arrivals are buffered or rejected per protocol policy.

6.2 Replay and reordering

• Replay. A frame with seq less than the latest committed index is rejected.
• Gap handling. Missing indices cause the window to fail until frames arrive or the sender retransmits. A protocol MAY allow skip with explicit witnesses that re‑close the window.

---

7. Policy and Names (L4)

Authorization is expressed as budget‑valued policies. Decisions carry witnesses. When a Boolean outcome is required, the budget calculus collapses conservatively to a yes/no result without introducing new theorems beyond the budgeted ones. Name bindings are signed statements referencing identifiers with their witnesses.

**Policy evaluation.

7.1 Policy predicate semantics

Let B = ℤ₉₆ and let ⟦x⟧ ∈ {0,…,95} denote the canonical representative of x∈B.

• A policy consists of statements that map (subject, action, object) to contributions in B.
• Let ΣP be the sum (mod 96) of applicable contributions. An admit set S ⊆ {0,…,95} defines acceptance.
• Decision. Admit iff ⟦ΣP⟧ ∈ S. The witness is the multiset of contributing statements and their indices.

---

8. Runtime Model: Virtual Private Infrastructure (L5)

A user operates a Virtual Private Infrastructure (VPI) across their devices.

Device. Endpoint with attestation and declared capacity.

States: enrolled → attested → active → (quarantined|retired)
Transitions require fresh attestation and valid witnesses.

Context. Isolation and placement boundary (subnets, services, applications). Cross‑context links require explicit policy and witnesses.

Lease. Schedulable unit bound to a device for a duration $τ$. Renewal requires a closing window; expiration or violation tears down the workload deterministically.

Scheduling as conservation. Placement rules are explicit; lease renewal is conditioned on local closure and protocol budgets.

Example flow.

1. A device enrolls and presents attestation.
2. A context requests N replicas of a service.
3. The scheduler grants N leases on matching devices.
4. Each device renews its lease by presenting closing windows; failure causes deterministic teardown.

8.1 Device attestation record (base profile)

struct Attestation {
  u8    ver;           // 1
  u8    sigAlg;        // 1=Ed25519
  u64   nonce;         // random
  u64   notBefore;     // UNIX seconds
  u64   notAfter;      // UNIX seconds
  u8[32] devKeyId;     // hash of device public key
  u8[32] stateRoot;    // Merkle root of attested device state
  u8[64] signature;    // over all previous fields
}

• Freshness. nonce MUST be unique per attestation; (notBefore, notAfter) define validity.
• Binding. devKeyId identifies the signing key; stateRoot commits to the device’s measured state.
• Verification. Check signature → check window freshness → check stateRoot inclusion proofs if provided.

---

9. Relation to Existing Technologies

9.1 Virtual machines and containers

VMs and containers provide isolation through hardware or namespaces with external control planes. The Hologram defines acceptance by equation, not by origin. VMs and containers can be wrapped as artifacts; intake and deployment are verified locally.

9.2 Software distribution

Conventional registries distribute images with digests but without structural closure. Artifacts here are page‑aligned, content‑addressed, and ship with witnesses. Synchronization is possible over intermittent links because verification is local.

OCI registry ingress (no tar, no unpack).

Goal. Import an OCI image as‑is, without tar streams, while preserving original digests and adding Hologram witnesses.

Ingest procedure.

1. Fetch the manifest JSON by digest from an OCI registry.
2. For each descriptor (config, layer), fetch the referenced blob by digest. Treat each blob as an opaque byte string.
3. Partition each blob into contiguous segments of 12,288 bytes (P×C). For the final segment, if length < 12,288, compute closure bytes as in §3.1 to close both axes; do not alter interior bytes.
4. For each segment, emit a CEF record (§5) with order=cycle-major; compute per‑page hashes and a per‑segment root.
5. Build an Artifact Index (AIDX) that maps each original OCI digest → list of CEF segments, original size, mediaType, and a per‑blob Hologram root.

AIDX (binary sketch).

struct AIDX_Entry {
  u8[32] ociSha256;   // digest of the original blob (as served)
  u64    size;        // original blob size, in bytes
  u32    segCount;    // number of CEF segments
  SegRef segs[segCount]; // {recordId, offset}
  u8[32] holoRoot;    // Merkle root over concatenated page hashes across segments
  u32    mediaTypeId; // registry mediaType mapped to an enum
}

Integrity. ociSha256 is computed over the unmodified blob; holoRoot is computed over CEF pages (witness‑carrying).

Export. To reproduce the OCI blob, concatenate the original bytes using size and SegRef boundaries; ignore closure bytes (they live only in CEF/witness space). The recovered blob’s digest equals ociSha256.

Result. No tar; no file system semantics required; round‑trip preserves OCI digests; Hologram witnesses live alongside as CEF records with an index.

9.3 Digital currencies

Proof‑of‑Work and Proof‑of‑Stake externalize trust to energy or ownership. The Hologram uses conservation windows with budgets modulo 96. Settlement is the act of presenting valid windows; verification cost is bounded and local. Global total ordering is not part of the substrate.

9.4 Proof systems

General proof systems certify properties of programs. The Hologram restricts to a small set of invariants sufficing for the stack. The theorems are constructive and map directly to verifiers.

---

10. Security Considerations

10.1 Cryptographic assumptions

• Collision and second‑preimage resistance of SHA‑256.
• Unforgeability of Ed25519 signatures under chosen‑message attack.
• Availability of a CSPRNG for nonces.

10.2 Properties and threats

• Integrity: closure equations and page/cycle digests detect drift.
• Authenticity: identifiers bind content to witnesses; bindings are signed.
• Replay and mutation: non‑closing windows and digest mismatches are rejected.
• Policy safety: decisions are accompanied by witnesses; Boolean collapses are conservative.

Adversary model assumes message tampering, replay, and partial observation. Device compromise, side‑channels, and denial‑of‑service are outside the substrate and require conventional mitigations.

---

11. Evaluation

The system admits deterministic conformance:

• canonical 12,288‑element instances defined by Section 2.3, with published fingerprints;
• suites for closure, serialization, and Merkle root checks;
• traces for protocol windows and policy decisions.

Complexity. Closure verification is $O(N)$. Merkle verification is $O(\log C)$ per page proof when using inclusion proofs. Witness size is bounded by per‑page hashes plus minimal closure bytes.

Methodology. Implementations measure wall‑clock verification time on fixed vectors; publish sizes of witnesses and failure detection latency.

11.1 Reference constants & sizes (base profile)

• P=48, C=256, N=12,288.
• SHA‑256 (32‑byte outputs); Ed25519 signatures (64 bytes).
• CEF payload size: 12,288 bytes; pcw: 48 bytes (all zero in base profile); root: 32 bytes.
• Identifier (UORID) binary length without witnesses: 1+1+1+1+32+1 = 37 bytes.

---

12. Interfaces and Tooling Surfaces (Hologram)

Interface definition. The interface to The Hologram is Hologram. Hologram provides a minimal, verifiable set of tools to interact with the substrate; it does not add new trust anchors. All interfaces call the same local verifiers derived from the formal model.

12.1 Components

• Hologram SDK (developer interface). Multi‑language APIs that expose: L1 identity/addressing; L2 integrity/exchange; L3 protocol/runtime primitives (budget windows, object graph, transport); L4 policy; L5 VPI operations. SDK bindings load verifiers (native/WASM) for closure and Merkle checks; operations fail closed if witnesses are absent or invalid.
• Hologram CLI (user/admin interface). Command‑line tools that manage VPIs, devices, contexts, services, applications, packages, bundles, and artifacts. The CLI performs attestation and verification locally, prints witness traces, and schedules work by issuing leases against the user’s VPI.
• Hologram Dashboard (user/admin interface). A client‑side web application (served via GitHub Pages) that connects directly to the user’s VPI. It embeds the same WASM verifiers as the SDK/CLI to validate artifacts, deployments, conservation windows, and policy decisions.

12.2 Minimality and ecosystem

Hologram surfaces are intentionally minimal: they provide the smallest set of operations necessary to read, verify, and write states that satisfy the substrate. The broader ecosystem—services, applications, games, and tooling—is built atop these interfaces (typically via the Hologram SDK) and remains subject to the same invariants.

12.3 Layer mapping

• L0–L2: closure equations, padding, and Merkle proofs are implemented as verifiers consumed by all interfaces.
• L3: protocol windows and object‑graph operations expose budget composition and acceptance checks.
• L4: policy evaluation returns witnesses; Boolean gates are conservative collapses of budget calculus.
• L5: device enrollment/attestation, leases, and deployments are driven by CLI/Dashboard and enforced by the same verifiers.

12.4 Minimal API surface (signatures)

closureCheck(H: bytes[12288], order: u8) -> Result
computePadding(row: bytes[k<256]) -> u8
pageHashes(H: bytes[12288], order: u8) -> bytes[32*256]
merkleRoot(leaves: bytes[32*256]) -> bytes[32]
verifyInclusion(leaf: bytes[32], index: u16, branch: bytes[32*m], root: bytes[32]) -> bool
encodeCEF(H: bytes[12288], order: u8) -> bytes
decodeCEF(blob: bytes) -> {H: bytes[12288], order: u8}
windowAccept(frames: Frame[L], L: u16) -> bool
evalPolicy(subj, act, obj, stmts[]) -> {admit: bool, witness: bytes}
verifyAttestation(att: Attestation, pubKey: bytes[32]) -> bool

Interfaces are identical across SDK, CLI, and Dashboard; implementations call the same local verifiers.

---

13. Scope and Limitations

The model assumes honest device attestation and correct verifier implementations. It does not provide total ordering or global consensus. Applications requiring those properties must layer additional protocols without violating closure.

---

14. Conclusion

A single conservation rule over a fixed substrate yields a coherent basis for virtualization, distribution, authorization, and settlement. Because acceptance reduces to local checks, the system operates without external trust anchors and remains compatible with existing execution and packaging technologies.

---

Appendix A — Lemmas (sketches)

A.1 Addressing. The map $(p,c) ↦ i=c·P+p$ is a bijection on $[0,N)$; inverse: $p=i\bmod P$, $c=\lfloor i/P \rfloor$.

A.2 Global dependency. $\sum_c I_P(H[·,c]) = \sum_p I_C(H[p,·]) = \sum_{p,c} H[p,c]$. One check is derivable.

A.3 Rotation invariance. For any $(Δp,Δc)$, define $H'(p,c)=H(p+Δp, c+Δc)$. Closure equations hold for $H'$.

A.4 Padding correctness. Let $x_0,…,x_{k-2}$ be given. Set $x_{k-1} = -\sum_{i=0}^{k-2} x_i \bmod 256$. Then $\sum_i x_i ≡ 0$.

Appendix B — Algorithms (pseudocode)

B.1 Page‑major closure check: analogous to 3.1 with loops swapped.

B.2 Inclusion proof verification: given leaf index and Merkle branch, recompute root and compare.

B.3 Window acceptance: maintain rolling sums and a budget accumulator modulo 96; advance when both predicates hold.

Appendix C — Artifact wrapper (deterministic)

Define a function wrap(bytes) that outputs a CEF record:

1. Serialize in fixed order; split into 48‑byte rows.
2. For each cycle, compute closure bytes to satisfy equations.
3. Hash each page; compute root.
4. Emit fields as in Section 5.

wrap is idempotent on already‑closed inputs and preserves content digests when decoding followed by re‑encoding.

[afflom]

I probably jumped the gun by opening a PR for this: https://github.com/UOR-Foundation/Hologram/issues/1

Please take a look at the whitepaper proposed in this RFD. Once we get this hammered out, I'll update the PR.