S END : O BJECTS , H ISTORY, AND T RANSACTIONS IN A S INGLE -V ERB K ERNEL A P REPRINT
arXiv:2605.17401v1 [cs.DC] 17 May 2026
Christopher Goes [email protected]
May 2026
A BSTRACT Multi-party object coordination — across object-capability systems, smart-contract platforms, distributed actors, and event-sourced architectures — is shaped by six structural properties: authenticated provenance, opaque encapsulation, atomic multi-object commit, deterministic replay, immutable history, and history-derived state. Existing systems compose subsets via separate layered mechanisms (RPC, capability ACLs, transaction coordinators, event journals, vat boundaries); each layer is well-studied but the combination is fragile. We present a minimal kernel which makes them jointly compatible. Our kernel is built from s-expressions, a uniform send interface, transactions, and one primitive object distinction: ephemeral (caller’s context inherited) vs. persistent (context switches to the target’s kernel-assigned identity and append-only log). The kernel structurally classifies every send target into one of six cases without input from the caller — uniform caller interface, intensional kernel dispatch. Under kernel-faithful trust (the kernel runs its semantics as specified), this design holds all six properties as kernel-level against arbitrary programs — the kernel’s transition function refuses states violating them — in the precise sense defined in §4.4 (the §5 instantiation realises identity-pattern opacity at user-level under its sequential allocator; a hash-allocator variant restores it to kernel-level — §5.6). Opacity against the operator additionally requires operator-faithful trust (the operator accesses logs only via recall and does not censor or reorder transactions); under kernel-faithful alone, five of six guarantees survive an unconstrained operator. Append-only logs underpin immutability, replay, and history-derived state; kernel-controlled persistent dispatch yields authenticated provenance and opacity; transactions deliver atomic coordination. Opacity has one structural exception: co-participants in a transaction observe its commit-or-abort outcome (Proposition 4), an intentional consequence of atomic coordination rather than a leak. Operator-adversarial deployments can be realized with a cryptographic compiler (§7 Case Study 2, Viaduct).
1
Introduction
Multi-party object coordination is shaped by six structural concerns — authenticated provenance[9], opaque encapsulation[15], atomic multi-object commit[17], deterministic replay[23], immutable history[19], and historyderived state[18] — each individually motivated by patterns in this domain. We use multi-party object coordination throughout to refer to the broad domain spanning object-capability systems, smart-contract platforms, distributed actor frameworks, and event-sourced architectures, wherever multiple principals interact through encapsulated objects whose state must be jointly authenticated, atomically updated, and replayable from a shared record. We propose this as a category-name for an implicitly-shared design space: no prior literature treats these system classes as one, but the six requirements above span all of them, which makes the cross-class comparison §8 draws coherent. These concerns are conventionally provided for by separate, layered mechanisms (RPC, capability ACLs, transaction coordinators, event journals, and vat boundaries), with state held in mutable snapshots that must be kept in sync with the event log to remain auditable. Each layer is well-studied in isolation, but the combination is fragile: interfaces multiply,
Send: Objects, History, and Transactions in a Single-Verb Kernel
A P REPRINT
cross-layer invariants are easy to violate, and security properties leak across layer boundaries. What design provides all six simultaneously, not as separate layered mechanisms but as kernel-level properties? Our kernel is designed as a target representation, not a surface language: a structural specification that source object languages compile to, and that cryptographic compilers (Viaduct-style[24], §7 Case Study 2) take as a specification of what must remain opaque, atomic, and replay-verifiable under adversarial operators. The §5 instruction set is correspondingly chosen for computational sufficiency, not human readability; usable surface languages are downstream work. The kernel rests on three commitments developed in §2: • Ephemeral/persistent dispatch axis. A send target’s structural classification determines whether execution context switches (persistent) or is inherited (ephemeral). The cleanest demonstration is §7 Case Study 1, where the only difference between two otherwise-identical traces is this classification. • Send as uniform cross-object interface. The sole cross-object verb, classified by the kernel into six structural cases; intra-object computation uses additional kernel-local instructions (§5) that do not cross object boundaries. • State as history. A persistent object’s state is what its program derives from its append-only log. These commitments, combined with the transaction mechanism, yield a kernel providing these six properties. The kernel’s distinctive ergonomic move is interface unification: the caller uses one verb, and the kernel performs an intensional six-way structural classification of the target — encapsulating distinctions which prior systems expose as separate caller-selected mechanisms (Self’s parent slots, Smalltalk’s super-sends, EVM’s DELEGATECALL). Kernel-level enforcement. A property is kernel-level for a system if the transition function guarantees that it holds, regardless of program input; user-level if well-formed programs can violate it. Smalltalk’s instVarAt: makes opacity user-level; Akka Persistence’s non-deterministic event handlers make deterministic replay user-level. We show that this kernel achieves uniform kernel-level enforcement across all six properties (Definition + Theorem 3 + Proposition 4, §4.4) under these definitions; operator-faithful trust is required for opacity (see “Scope and trust” below). Each of the six properties is well-studied in isolation, and many existing systems realise subsets via composed mechanisms, but alternative designs distribute the kernel/user-level boundary differently. The row-by-row contrast in §8 makes the comparison precise. Scope and trust. The kernel is positioned with respect to three trust regimes, distinguished by what is assumed about the deployment operator. Kernel-faithful: the kernel implementation runs its semantics as specified. All six structural properties hold against arbitrary programs. Opacity against the operator additionally requires the operator-faithful conditions below. Operator-faithful: in addition to kernel-faithfulness, the deployment operator satisfies three sub-faithfulness conditions: (a) commit-faithfulness: every well-formed transaction submitted to the kernel is committed (no selective censorship); (b) order-faithfulness: transactions are ordered consistently with the wrapping protocol’s T (the operator does not reorder T beyond the conflict-serialisable equivalences §6.3 permits); (c) read-faithfulness: the operator stores K but does not leak its contents into in-kernel program execution outside the kernel’s defined read interfaces (own-log via position 3; cross-object only via send). Under operator-faithfulness, opacity holds against all programs; the operator is the only entity that can read a persistent object’s full K. Opacity is at the read interface: atomic transactional coupling necessarily exposes co-participation across receivers (Proposition 4, §4.4). Operator-adversarial: the operator may violate any of (a)–(c). The kernel does not solve this regime; cryptographiccompiler composition (§7 Case Study 2, Viaduct[24]) is the standard remedy, and the kernel serves as the structural target the compiler instantiates against adversarial operators. Case Study 2 sketches label-derivation from object identities for the static-allocation case; dynamic allocation is future work. The kernel itself is not a distributed system; the wrapping protocol’s properties (consistency, availability, partitiontolerance trade-offs[29]; liveness under asynchrony) are scope-conditional on the wrapper choice (§6.2), not kernel concerns. The kernel exposes strict serializability under sequential processing with a real-time-faithful wrapper (§3); §6.3 discusses conflict-serializable scheduling and its parallelism floor. The kernel assumes program termination (§3.4); resource-bounding is composition-layer scope, and under the compilation-target framing becomes a compiler obligation. Recovery is discussed in §6.4. External principals. execute assigns caller = aext for top-level transactions; the wrapping protocol (signed transactions, authenticated channels, consensus-attached identity) authenticates which external party submitted each transaction. Multi-party scenarios represent external principals in-kernel as persistent proxy objects (the §7 case studies do
2
Send: Objects, History, and Transactions in a Single-Verb Kernel
A P REPRINT
this for bidders, buyers, and sellers), with the wrapper routing each authenticated submission to its designated proxy; the kernel’s authenticated-provenance claim is over these intra-kernel identities, conditional on this wrapper discipline. The kernel’s essential semantics are parameterised. Section 2 presents the invariant core informally. Section 3 formalises it. Section 4 derives the structural properties. Section 5 gives one concrete instantiation. Section 6 addresses locality, composition modes (replication, sharding), conflict-serializable scheduling, and log retention. Section 7 shows that common patterns are encodable within the kernel. Section 8 positions the kernel against prior systems. Section 9 outlines open directions.
2
Essential Semantics
Invariant core of the kernel, informally; §3 formalises. Data. One data type: s-expressions. Every s-expression is an object, meaning it can be the target of a send. No structure beyond being an s-expression is required to be an object. Send. The cross-object interface. A program specifies a target and a message; the kernel determines what happens based on the target’s classification. The sender’s interface is uniform: it does not select which kind of send to perform. The kernel classifies every target into one of six structurally distinct cases plus an invalid catch-all. Two are primary modes: persistent object (context switch to the target’s program) and ephemeral object (runs with inherited context). Four are boundary cases: built-in (pure computation), kernel (object creation), external target (fire-and-forget), and special pair form (instantiation-defined dispatch on certain pair shapes; §5.3). A target matching none of the six aborts. Ephemeral vs. persistent objects. The one boundary. Ephemeral objects are transparent: no identity, no history, no boundary. Persistent objects are created by sending a program to the kernel. Each has an opaque identity (an atom), an append-only log of authenticated interactions, and a program. No one can read another object’s log or program — the kernel enforces this absolutely. Inside is invisible from outside; every crossing from outside to inside is authenticated, logged, and bilateral. Design-space observation: the ephemeral/persistent endpoints. The ephemeral/persistent axis bundles three subdistinctions — identity (named vs. anonymous), logging (logged vs. unlogged), context (switching vs. inheriting). Under this paper’s design premises — the six structural properties of §1, enforced as kernel-level guarantees with the specific definitions §4.4 makes precise — only two of the eight (id, log, ctx) configurations satisfy all six simultaneously: persistent (named, logged, switching) and ephemeral (anonymous, unlogged, inheriting). The kernel takes these as the dispatch axis. The remaining six configurations each fail at least one property under these definitions: Configuration
Property unsatisfied (§4.4 def.)
named, logged, inheriting named, unlogged, switching named, unlogged, inheriting anonymous, logged, switching anonymous, logged, inheriting anonymous, unlogged, switching
Provenance: log on receiver but caller’s identity runs Replay, immutability, history-derived state (no log) Replay, immutability, history-derived state Provenance: log without identity to attribute to Provenance: log without owner; delegation accountability broken Cannot switch to a nameless target
Other configurations are valid for systems with different commitments — e.g., named-unlogged-switching is traditional mutable OO (Smalltalk, Self), forfeiting replay and history-derived state for in-place mutation. Our claim is not that other configurations are impossible but that the two endpoints above are what permit all six properties to hold simultaneously as kernel-level guarantees. State as history. Persistent state is append-only: a persistent object’s state is whatever its program derives from its interaction log. Each log entry records [caller, msg] — the authenticated identity of the sender and the message. The first entry is a birth record placed by the kernel at creation time. Transactions. The sole coordination mechanism. Everything within one submission to the kernel is a single atomic transaction — all effects commit or none do. Positive coupling: bundled sends co-occur. Negative coupling: any receiver can abort, destroying the entire bundle. Details in Section 4. Parameterisation. The essential semantics are parameterised over an atom set, a set of built-in objects, a program model, and a log encoding. Section 3 defines the constraints on each parameter and the formal dispatch rules.
3
Send: Objects, History, and Transactions in a Single-Verb Kernel
3
A P REPRINT
Formal Model of Essential Semantics
The mathematical core, parameterised over A, B, Π, interpreter, and encoding. Three definitions: send (six-case dispatch), run (program interpreter), execute (transaction commit). Readable as small-step operational semantics or as a transition function on the global state K. 3.1
Data Domain S =A+S ×S
Structural equality: n = m ⇐⇒ n and m are the same element of A [a, b] = [c, d] ⇐⇒ a = c and b = d n ̸= [a, b] for all n ∈ A, [a, b] ∈ S × S 3.2
State K ∈ (A × A × S)∗
The global persistent state — all persistent object histories in a single append-only sequence. Each entry (n, c, m) records that persistent object n received message m from caller c. The caller c is always an atom — either a persistent object’s identity or aext — because the kernel-controlled caller (position 4) is always an element of A. Derived operations (projections of K onto individual persistent objects): log(n, K) = [(c, m) | (n, c, m) ∈ K] exists(n, K) ⇐⇒ n ∈ A \ {akernel } and ∃ c. (akernel , c, n) ∈ K Pers(K) = {n ∈ A : exists(n, K)} program(n, K) = second(log(n, K)[0]) Parameters (supplied by the instantiation): encode : (A × S)∗ → S Π : S × S → S + {⊥} Ext, Eph ⊆ S × S B⊆A builtin : A × S → S + {⊥} alloc : (A × A × S)∗ → A Π is the instantiation-defined pair-form dispatch: non-⊥ for pairs matching an instantiation-specified special form (e.g., §5.3 pair closures). The instantiation must ensure: (i) Π-matched pairs, Ext, and Eph partition S × S; (ii) builtin(n, m) = ⊥ for all n ∈ / B (built-ins are defined only on B; behaviour on ill-formed arguments may abort); (iii) alloc returns a fresh atom outside B ∪ {akernel , aext } ∪ Pers; (iv) encode is injective; (v) the program model is pure (no inspection of K, T , time, or randomness). Transaction effects (accumulated during execution): ∆ ∈ (A × A × S)∗ ,
Ξ ∈ (A × S × S)∗
∆ holds pending entries on persistent objects’ logs; Ξ holds pending external sends. Read-your-writes: all lookups during a transaction use K ++ ∆ — each persistent object sees its committed history plus pending entries from completed prior invocations. Transaction log (system-level boundary record): T ∈ (S × (S + {⊥}) × (A × S × S)∗ )∗ Each entry (tx, v, Ξ) records a submitted transaction tx, its result v (or ⊥ on abort), and the external sends Ξ dispatched on commit (empty on abort). 4
Send: Objects, History, and Transactions in a Single-Verb Kernel
3.3
A P REPRINT
Send send : S × S × A × S × A × K × ∆ × Ξ → (S × ∆ × Ξ) + {⊥}
All cases, parameterised. Cases in order; first match wins. send(t, m, s, l, c, K, ∆, Ξ) = ⊥ (builtin(t, m), ∆, Ξ) sendkern (s, m, K, ∆, Ξ) sendpers (t, m, s, K, ∆, Ξ) (Π(t, m), ∆, Ξ) (aext , ∆, Ξ · (s, t, m)) run([t, m, s, l, c], t, K, ∆, Ξ) ⊥
t ∈ B, builtin(t, m) = ⊥ t ∈ B, builtin(t, m) ̸= ⊥ t = akernel t ∈ Pers(K ++ ∆) t ∈ S × S, Π(t, m) ̸= ⊥ t ∈ Ext t ∈ Eph otherwise
with the two non-trivial cases factored as named helpers: ( sendpers (t, m, s, K, ∆, Ξ) =
⊥ (v, ∆′ · (t, s, m), Ξ′ )
if r = ⊥ if r = (v, ∆′ , Ξ′ )
where p = program(t, K ++ ∆), h = encode(log(t, K ++ ∆)), r = run([p, m, t, h, s], p, K, ∆, Ξ) sendkern (s, m, K, ∆, Ξ) = (id , ∆′ , Ξ) where id = alloc(K ++ ∆), ∆′ = ∆ · (akernel , s, id ) · (id , s, m)
Cases in priority order; first match wins. • Built-in (t ∈ B): Pure computation. No effect on ∆ or Ξ. • Kernel (t = akernel ): Object creation. Allocates fresh identity. Two pending entries: creation record on kernel’s log, birth record [creator, program] on new object’s log. • Persistent (t ∈ Pers(K ++ ∆)): Context switch. Target’s program runs with self = t, log = h, caller = s. The pending entry (t, s, m) is appended to ∆′ after the target’s program returns; h thus encodes history up to but not including the current message. Computing Pers over K ++ ∆ admits dispatch to objects created earlier in the same transaction. • Special pair form (Π(t, m) ̸= ⊥): Pure pair-form dispatch defined by the instantiation (e.g., §5.3 pairclosure rule). No effect on ∆ or Ξ. • External (t ∈ Ext): Fire-and-forget. Returns aext . Appends to Ξ. • Ephemeral (t ∈ Eph): Inherited context. No persistent effects. Applies to pairs not matched by Π or Ext. • Otherwise: Abort. Disjointness. B, {akernel }, and Pers(K ++ ∆) partition the relevant atoms by the instantiation’s allocation discipline; pairs are partitioned per §3.2; the catchall covers any remaining target. Log ordering. Entries are appended in completion order: (t, s, m) is added to ∆′ after the target returns. Re-entrant sends to the same target appear before the outer entry. This is forced by the position-3 invariant: the receiver’s log visible to its program at m’s execution must not include m’s own entry. Trigger-order is exposed externally via T (which records each txi as a single unit). Throughout this paper, “history-derived state” refers to the completionordered log-replay sense; trigger-order recovery, when needed, uses T or explicit message-level sequence threading. 3.4
Interpreter run : S ∗ × S × K × ∆ × Ξ → (S × ∆ × Ξ) + {⊥}
The program model must support: 5
Send: Objects, History, and Transactions in a Single-Verb Kernel
A P REPRINT
• Push values onto the execution context. • Send — invoke send on the top two values with the current context. • Recall — access context positions: program (0), message (1), self (2), log (3), caller (4). • Quote — push a value without interpretation. • Abort — produce ⊥, which propagates through all enclosing computations. The execution context’s three kernel-controlled values — self (position 2), log (position 3), caller (position 4) — switch on persistent send, are inherited on ephemeral. Concrete instruction set is an instantiation choice. The model assumes program termination; resource-bounding is composition-layer scope (§1 “Scope and trust”). 3.5
Transaction execute(K, [p, i]) =
(⊥, K, ε) if r = ⊥ (v, K ++ D, X) if r = (v, D, X)
where r = run([p, i, aext , encode(ε), aext ], p, K, ε, ε). The program runs unprivileged: self = aext , log = encode(ε), caller = aext . It can create objects, send to existing objects, and compute — but cannot read the kernel’s log or enumerate objects. Success: pending entries commit, externals dispatched. Abort: K unchanged, no externals. Terminology. Transaction refers to a single submission [p, i] running execute to completion or abort: a one-shot stored-procedure invocation in the Calvin[25] sense, not a multi-round-trip database transaction. Serializable refers to the standard ANSI/Adya isolation level[28]; sequential processing (§3) realises strict serializability under a wrapper that totally orders submissions consistently with their wallclock-completion times (the obligation discharged by consensus-leader ordering, batched timestamping, or external clock services), and §6.3 discusses conflict-serializable scheduling. 3.6
System K0 = ε
T0 = ε
(vi , Ki , Ξi ) = execute(Ki−1 , txi ) Ti = Ti−1 · (txi , vi , Ξi ) for i = 1, 2, . . . Sequential transaction processing (§6 discusses concurrent scheduling). T captures the sole non-determinism: external submission order.
4
Structural Properties
The six structural properties claimed in §1 follow entirely from the essential structure — they hold for any atom set A satisfying the constraints, any set B of pure built-ins, any program model with send/recall/abort, and any log encoding. • Deterministic replay — from append-only K + deterministic dispatch, given the transaction sequence, reexecution from the empty state reproduces all state. • Immutability of history — from append-only logs. No entry is ever modified or deleted. • Authenticated provenance — from kernel-controlled caller at position 4. No program can forge or suppress its identity. • Opacity — from the absence of any cross-object read mechanism. No object can read another’s log or program. • Atomic coordination — from transaction semantics. Co-occurrence or mutual destruction of log entries across objects. • History-derived state — from log access at position 3. Every object derives its current state from its own complete interaction history. Admissibility. Theorems below assume an instantiation satisfying the §3.2 constraints (partition; builtin-on-B; allocfreshness; encode-injectivity; program-purity). Theorem 1 additionally requires built-ins, encode, alloc, and the interpreter to be deterministic, and program execution to terminate (§3.4). Theorem 1 (Deterministic Replay). Under the admissibility conditions above, for any transaction sequence tx1 , . . . , txn , the state Kn produced by sequential application of execute is uniquely determined. 6
Send: Objects, History, and Transactions in a Single-Verb Kernel
4.1
A P REPRINT
Objects as Information Boundaries
The persistent object is the only structural boundary in the system. Ephemeral programs inherit context; information flows through them as if they were not there. Built-ins are pure parameterisable functions creating no boundary and maintaining no state. The kernel mediates every crossing of a persistent object’s boundary: • Inside → outside: invisible. No program reads another object’s log or program, the object registry, or transaction log T . The kernel forbids anonymous send, silent receipt, selective rejection (only transactional abort refuses, destroying the bundle), identity forgery (position 4 is kernel-set), log tampering (position 3 is read-only), and target interception (dispatch is identity-keyed). • Outside → inside: kernel-mediated. Each persistent send: sender chooses target and message; kernel sets caller (position 4) and provides the receiver’s history (position 3) and code (position 0); receiver chooses response and may abort. On commit, the kernel records [caller, msg] in the receiver’s log. External sends are fire-and-forget (discarded on abort); ephemeral sends inherit context; kernel sends produce fresh identities and a birth record. The kernel controls identity allocation, caller assignment, history provision, log writing, dispatch, and transaction atomicity. The sender controls target selection and message content; the receiver controls only the response and whether to abort. The external world controls only transaction submission and input. 4.2
Identity-as-Capability and Controls
Identity-as-capability. Knowing an identity is the capability to send. Identities are opaque atoms (the kernel exposes no structure on identities; identities are learned through interaction; allocation pattern-opacity is instantiationdependent — see §5.6). Once known, an identity grants unconditional, irrevocable, non-attenuable ability to send. This forgoes in-kernel attenuation and revocation — primitives that prior capability systems (Miller[9], Spritely Goblins[16], KeyKOS/EROS[27]) treat as core. The design rationale is minimalism: kernel-level revocation would require the kernel to track revocation entitlements and authorise decisions, expanding its surface beyond the send/log/transaction primitives. The kernel instead lets each program specify its own revocation policy through user-level gating objects — opaque persistent intermediaries that inspect caller identity before forwarding. Cooperative fault tolerance. The receiver’s veto is all-or-nothing: it aborts the entire transaction. Programs can implement a “will-this-succeed” check by running the same logic and returning yes/no instead of aborting (reliable within a transaction; a check-to-use race across transactions under §6.3). A hypothetical TRY primitive — catching failures within a transaction — is deliberately omitted: it would defuse the receiver’s only control mechanism and enable traceless probing. 4.3
History Coupling
Transactionality couples objects’ histories. Without it, each object’s log is independently determined. With it, a sender can bundle sends such that entries on different objects’ logs atomically co-occur. Three forms: Positive coupling. The sender bundles sends to Q and R in one transaction. Q’s entry existing implies R’s entry existing. Negative coupling. Any receiver can abort, destroying the entire bundle — including entries on objects it has no direct relationship with. If P sends to Q then to R and R aborts, Q’s entry is rolled back. Implicit information channel. No object can read another’s log. But transactional coupling creates a logical entailment: if Q’s log has entry E, and Q knows the transaction pattern that produced E, Q can infer properties of R’s log without reading it. The co-occurrence guarantee leaks structural information about other objects’ histories through the mere existence of one’s own entries. Not a direct read — a deduction from the atomicity contract. Proposition 4 (§4.4) makes this signal precise. 4.4
Kernel-Level Enforcement
The properties above admit two readings. A property may hold for every well-formed program of the system (kernellevel) or for some well-formed programs by programmer convention (user-level, satisfied where programmers choose to). Definition (Kernel-level enforcement). A property P is kernel-level for system S iff S admits no program input whose execution makes P fail; otherwise P is user-level. For trace properties (immutability, atomic commit), this 7
Send: Objects, History, and Transactions in a Single-Verb Kernel
A P REPRINT
reduces to: the transition function refuses to produce a state in which P fails. For hyperproperties (non-interference, opacity), it requires that executions agreeing on the relevant inputs yield identical post-execution state on objects other than the receiver, identical external sends, and identical response values, excepting the abort-cohort signal of Proposition 4 — formalised in Theorem 3. Theorem 2 (Read Confinement). Every read or write of a persistent object’s log is mediated by an explicit send to that object via the §3.3 dispatch path. The sendpers rule reads only the receiver’s program and log (positions 0 and 3) and appends only to the receiver’s log; sendkern , sendeph , built-in, external, and special-pair-form dispatches do not reference any persistent object’s log. No kernel primitive reads or writes another object’s state outside its own dispatch path. Proof: by inspection of the §3.3 case-split. Proposition 4 (Abort-cohort signal). Let tx be a transaction whose sub-sends form a cohort {O1 , . . . , Ok } of receiving persistent objects. The kernel’s transaction commit semantics (§3.5) imply that all participants in tx — the initiator and each Oi — observe a common commit-or-abort outcome. Consequently, conditional on co-participation, the abort decision of any single Oi is observable as the abort decision of the bundle. This is the intentional semantics of atomic coordination (§4) — engaging in a multi-party transaction is binding one’s outcome to the bundle’s — and is not removable without abandoning atomicity. At the in-kernel program level, the signal is visible only to participants in tx — through subsequent inspection of their own logs, which reflect commit (an entry was appended) or abort (no entry was appended). At the system level, T records the outcome (v = ⊥ for receiver-veto aborts), so any party with access to T observes the bundle’s outcome. Theorem 3 (Kernel-level non-leakage modulo abort-cohort signal). Fix a transaction tx, a kernel state K, and a persistent object O ∈ Pers(K). Let K ′ be any kernel state satisfying log(n, K ′ ) = log(n, K) for all n ̸= O and program(O, K ′ ) = program(O, K). If during the parallel executions execute(K, tx) and execute(K ′ , tx) — (i) every send addressed to O returns identical response values, and (ii) every send issued by O’s program is identical between the two runs — then the two executions agree on the resulting kernel state restricted to objects other than O, the external sends Ξ initiated by the transaction, and the transaction’s response value, modulo Proposition 4’s abortcohort signal when exactly one execution aborts. Information about O’s log can therefore influence the rest of the system during tx only through O’s responses to its callers, O’s sends to other persistent objects, O’s external sends, and the abort-cohort signal. Proof sketch. By structural induction on the sequence of sends issued during tx. Sends to objects ̸= O: log entries on the target agree by hypothesis on K, K ′ together with the inductive hypothesis on ∆; §3.3 dispatch is deterministic; so response and pending updates agree pointwise. Sends to O: by (i), O’s response agrees; by (ii), O’s onward sends to any target are identical. The post-execution non-O state, Ξ, and the transaction’s response value are functions of these agreed sub-executions, except for the abort-cohort signal of Proposition 4 when one execution aborts and the other commits. □ Remark (on the conditional structure). Theorem 3 is a conditional result: given program-level observability invariance — (i) and (ii) above — the kernel propagates that invariance to non-O state. The kernel’s unconditional contribution is Theorem 2 (Read Confinement): no primitive reads cross-object state outside dispatch. Program-level non-interference for an opaque O is therefore reducible to engineering O’s program to satisfy (i)(ii); the kernel guarantees that satisfaction suffices. Corollary (Opacity at read interface). Information about O’s log influences the rest of the system only through O’s deliberate responses, sends, external sends, and the abort-cohort signal. This is the formal content of “opaque encapsulation” as claimed in §1. Per-property classification. All six structural properties claimed in §1 are kernel-level for this kernel under the Definition above. Trace properties (transition refuses violating states): immutability of history (no §3 operation removes entries); authenticated provenance (kernel sets caller; programs cannot write position 4); atomic coordination (transaction commits all of ∆ or none, by §3.5); history-derived state (state is log-projection by §3.2). Hyperproperties (executions agreeing on inputs yield identical observations): deterministic replay (Theorem 1); opacity (no cross-object read primitive — Theorem 3 formalises the non-interference statement). By contrast, the kernel is not kernel-level on resource-bounded execution: §3.4 assumes termination and defers resource bounding to composition. A non-terminating program halts the kernel; production deployments must compose with deterministic resource metering (gas-style, instruction counts) to preserve Theorem 1’s replay/recovery/replication guarantees. Non-deterministic operational fallbacks (wall-clock cut-offs) recover liveness but break determinism.
8
Send: Objects, History, and Transactions in a Single-Verb Kernel
5
A P REPRINT
An Instantiation
One concrete parameter selection: A = N, with distinguished elements, six pure built-ins, a five-operation instruction set, and pair-chain log encoding. The instruction set is a sufficiency demonstration, not a syntax for direct programmer use; usable surface languages are downstream work (§1). 5.1
Constraints on A = N • Decidable equality: natural number equality. • Distinguished elements: akernel = 0, aext = 1, plus program operations and dispatch tags below. • Fresh allocation: alloc(K ++ ∆) = 14 + |log(0, K ++ ∆)| — deterministic, sequential; ∆ visibility lets multiple creates within one transaction allocate distinct identities.
5.2
Atom Numbering
Reserved range: [0, 14). Organised in four layers: Number
Name
Role
Layer 1 — Identities (fixed) 0 KERNEL System identity — akernel , primordial persistent object 1 EXTERNAL External world — aext , sentinel atom; special-cased target Layer 2 — Instruction-encoding atoms (fixed) 2 * Send 3 ? Recall 4 FAIL Abort 5 ! Quote Layer 3 — Dispatch tags (fixed) 6 PAIR_TAG Pair closure tag 7 EXTERNAL_TAG External target tag Layer 4 — Built-ins (parameterisable; §5.3) 8 HEAD, 9 TAIL, 10 PAIR, 11 EQUAL, 12 BRANCH, 13 INCREMENT Fixed atoms [0, 8) define system structure. Built-in atoms [8, 14) are replaceable with any set satisfying the built-in constraints.
5.3
Built-in Objects B
Signature: builtin : A × S → S + {⊥}. Six built-in objects, all pure. Booleans use the structural atom/pair distinction: atom = true, pair = false. a b [6, m] 0 builtin(n, m) = [a, b] x y m+1 ⊥
n = 8, m = [a, b] (HEAD) n = 9, m = [a, b] (TAIL) n = 10 (PAIR) n = 11, m = [a, b], a = b (EQUAL) n = 11, m = [a, b], a ̸= b n = 12, m = [t, [x, [y, _]]], t ∈ A n = 12, m = [t, [x, [y, _]]], t ∈ S × S n = 13, m ∈ A (INCREMENT) otherwise
PAIR returns a closure [6, a]. The instantiation-defined pair-form dispatch Π (§3.2) is given by Π([6, a], m) = [a, m]; Π(t, m) = ⊥ otherwise. The remaining pair classification: Ext = {[7, x] | x ∈ S} (pairs headed by EXTERNAL_TAG); Eph = (S × S) \ (dom(Π)∪Ext). Pair closures thus dispatch as pure construction with no effects, with priority over the generic ephemeral case. Pair closures are structurally indistinguishable from any pair whose head is PAIR_TAG (6); programs can construct closures directly. BRANCH is the sole discrimination primitive (atom-vs-pair), replacing pair-testing and conditional selection. INCREMENT is the sole arithmetic primitive (specific to A = N). Together with send and recursion via recall of position 0, these built-ins suffice for general computation over S — Church-encoded naturals are one standard encoding; the atom/pair distinction with BRANCH is another.
5.4
Instruction Set
Five operations: push, quote (!), send (∗), recall (?), abort (FAIL). A program is an s-expression interpreted as a linked list.
9
Send: Objects, History, and Transactions in a Single-Verb Kernel
Instruction
Action
4 (FAIL) n ∈ A \ {4} [2, k] (send) [3, [j, k]] (recall, j ∈ A, j < |L|) [5, [d, k]] (quote) [d, k] (push)
Abort: produce ⊥ Return L[|L| − 1] (top of stack) Send L[|L| − 2] to L[|L| − 1]; push result; continue with k Push L[j]; continue with k Push d literally (never interpreted); continue with k Push d; continue with k
A P REPRINT
Execution begins with run(L0 , p) where L0 = [p, m, s, l, c] binds program, message, self, log, caller. This instantiates §3.4’s signature: the context list is the initial stack (grown with intermediate values on recursion), and the program is the initial instruction (replaced by the continuation k on recursion). Every program can recall its context (positions 0–4); recall is the kernel’s intra-object read primitive — programs cannot read any other object’s program or log. Inter-object observation is necessarily via send, which produces a log entry; the absence of non-mutating cross-object reads is load-bearing for audit (every cross-object observation is auditable). The full interpreter: run(L, i, K, ∆, Ξ) = ⊥ (L[|L| − 1], ∆, Ξ) ⊥ if v=⊥, else run(L · v, k, K, ∆′ , Ξ′ ) run(L · L[j], k, K, ∆, Ξ) ⊥ run(L · d, k, K, ∆, Ξ) ⊥ run(L · d, k, K, ∆, Ξ) where (†) abbreviates:
i=4 i ∈ A \ {4} i = [2, k] (†) i = [3, [j, k]], j < |L| i = [3, _] otherwise i = [5, [d, k]] i = [5, _] otherwise i = [d, k]
(v, ∆′ , Ξ′ ) = send(L[|L| − 1], L[|L| − 2], L[2], L[3], L[4], K, ∆, Ξ)
The execution log is scratch — always discarded after execution completes. Context transitions: send to a persistent object switches self, log, caller; send to an ephemeral program inherits them unchanged. Position 3 provides read-your-writes within a transaction.
5.5
Pair-Chain Encoding
The log encoding encode = ⌈·⌉ represents logs as pair-chains terminated by 0: ⌈ε⌉ = 0 ⌈(a, b) . t⌉ = [[a, b], ⌈t⌉] A log with entries e0 , e1 , e2 is [e0 , [e1 , [e2 , 0]]]. The terminator 0 coincides with the kernel identity (akernel ); these roles do not conflict — 0 as terminator appears in a structural position, while 0 as kernel identity appears in semantic contexts.
5.6
Identity Allocation
Sequential: id = 14 + |log(0, K ++ ∆)|. Each object creation increments the count of entries on the kernel’s object registry. Deterministic. The §3 essential semantics leaves alloc abstract. The sequential counter here is pattern-opaque only by programmer convention — under the §4.4 demarcation criterion, identity-pattern opacity is user-level (a program can compute INCREMENT on a known identity to probe for adjacent allocations). Alternative instantiations (e.g., alloc(K) = h(nonce(K)) for a one-way hash h) preserve kernel-level pattern-opacity. We chose sequential for clarity; the §3-level claims are independent of this choice. Sufficiency, not expressibility. The instruction set demonstrates that general computation is encodable but at significant syntactic cost: conditional dispatch via BRANCH requires constructing nested pair arguments (~18 instructions per branch point). A practical instantiation would provide richer control-flow primitives; the minimal set here establishes a lower bound on what suffices.
10
Send: Objects, History, and Transactions in a Single-Verb Kernel
6
Composition
6.1
Locality
A P REPRINT
The kernel’s per-object semantics imply that it can run on any subset of object state without affecting its structural guarantees. Two equivalent formulations: Partial-knowledge execution. A local kernel runs with state Klocal ⊂ Kglobal — containing only some objects’ histories — and executes transactions that touch only those objects. send(t, m, . . .) looks up program(t, K ++ ∆) and log(t, K ++ ∆); if t is in scope these are defined and the transaction proceeds, otherwise t falls through to §3.3’s catch-all and the send returns ⊥. Use cases: sharding (§6.2, each shard’s partition as Klocal ), privacy (principals verify only their own objects’ interactions), independent audit (replay dispute-relevant interactions without consulting unrelated state). Compositionality. Equivalently, multiple kernel instances K1 , . . . , Kn with pairwise-disjoint persistent object identities can run independently. Cross-instance interactions are mediated by external sends — an external send from Ki with destination in Kj becomes a new transaction submitted to Kj via aext . Each Ki independently maintains the six structural properties of §3 within its own scope (no operation references another instance’s state; Theorems 1 and 2 apply unchanged within each instance). Boundary degradation. Authenticated provenance and atomicity do not extend across scope boundaries by default. A receiver of a cross-scope interaction sees the kernel-assigned caller aext , not the originating object; and the originating transaction commits independently of consequent actions in other scopes. Recovering cross-scope provenance or atomicity requires additional protocol mechanisms.
6.2
Composition Modes
Replication and consensus. Deterministic replay (Theorem 1) is the state-machine replication property[23]: identical transaction sequences yield identical K. The transaction log T is the command log a consensus or replication protocol (Raft, Paxos) agrees upon and disseminates; replicas — including mutually-distrusting parties verifying by local re-execution — independently apply transactions in the agreed order and reach identical state. Wrapping the kernel requires no kernel modification, only that the protocol agree on and deliver T . Sharding. A kernel’s state K is a flat sequence of per-object log entries; nothing in the formal semantics requires global K to be physically co-located. The object space can be partitioned across shards, each shard’s kernel maintaining K entries only for objects in its partition. Per-shard transactions are atomic by the kernel’s standard semantics; cross-shard interactions become external sends (aext destinations routed to other shards) wired up by the deployment layer. Cross-shard atomicity, when required, needs additional protocol layered over the kernel (two-phase commit orchestrated by a coordinator; consensus agreeing on a total order before per-shard execution) — not addressed by the kernel.
6.3
Conflict-Serializability and Per-Property Survival
The sequential transaction processing of §3 is sufficient but not necessary: all six properties survive under any conflict-serializable scheduling, allowing replication and concurrent execution to reorder non-conflicting transactions. Conflict, commutativity, and the parallelism floor. Two transactions conflict if they append log entries to at least one common persistent object. Since every cross-persistent-object access appends to the receiver’s log (built-ins, ephemerals, pair-forms, externals do not), conflicts are write-write only and the conflict graph is dense — any pair of transactions touching a common persistent object conflicts. A schedule is conflict-serializable[17] if equivalent in effect on K to some serial order. This dense conflict definition has a non-trivial parallelism cost: any persistent object touched by multiple transactions linearises all such transactions, even when they concern logically-independent state. Single-hot-object workloads serialise (as in Calvin[25]); shared coordinator/registry objects become bottlenecks. The kernel does not capture the read-write parallelism that conventional optimistic concurrency control (SSI) extracts via separate read/write tracking — the trade-off is for structural opacity, in-state provenance, and uniform deterministic replay. Non-mutating sends would be a separate design extension, not currently in the kernel’s structural model. Specific scheduling strategies are deployment concerns. Per-property survival. Each property survives by a per-property argument: • Immutability — the log remains append-only regardless of schedule. • Authenticated provenance — each entry records the kernel-assigned caller, set at context switch independently of global order. • Opacity — no send case exposes another object’s log or program, regardless of concurrent scheduling. • History-derived state — under conflict-serializable scheduling, the log entries visible to an object are those committed by transactions serialised before the current one, plus pending entries from earlier completed invocations within the current transaction (read-your-writes via ∆, §3.2). • Atomic coordination — per-transaction: each transaction either commits all entries or none, independent of others. • Deterministic replay — replaying transactions in the order recorded in T reproduces K; for conflict-free transactions, any equivalent interleaving produces the same result.
11
Send: Objects, History, and Transactions in a Single-Verb Kernel
A P REPRINT
Non-determinism and identity allocation. Non-determinism now derives from submission order plus serialisation choices, both captured in T . Conflict-aborts produce no T entry (pre-serialisation scheduling decisions); only receiver-veto aborts (programmatic FAIL) appear in T with v = ⊥. The conflict set is dynamic (computed during execution); Calvin-style reconnaissance or optimistic retry handle prediction-misses. Receiver-veto aborts depend on the visible commit prefix under the chosen serial order, so Theorem 1’s replay reproduces the abort pattern. T is the post-serialisation log. A concurrent instantiation uses a partitioned or hash-based identity allocation rather than the §5 counter.
6.4
Log Canonicality and Retention
The persistent state K is canonical and non-truncatable: truncation breaks deterministic replay (Theorem 1) and the audit guarantee on which authenticated provenance rests. Derived state — annotations, caches, materialised views — may be reclaimed; K may not. |K| is therefore monotonically growing. State annotations (compiler transformation). Naive per-message cost is O(|history|) — O(N 2 ) over N messages to one object. For programs P admitting a fold structure (σ0 , step, use) with P (H, msg) = use(foldl(step, σ0 , H), msg), a source-tokernel compiler can emit P ′ that appends a checkpoint self-send carrying σ after each invocation; subsequent calls read the latest checkpoint from position 3 — O(1) amortised per call (one extra log entry per invocation). The base kernel of §3 is unchanged; P ′ is observationally equivalent to P on responses, and all six properties survive. Most common programs (counters, balances, key-value stores, ACLs, FSMs) admit this form. Under conflict-serializable schedules (§6.3), non-idempotent folds need additional care. Crash recovery. The kernel’s persistent state is (K, T ), plus any commit-time ∆i pending merge into K (used for crash recovery, see below); the kernel does not carry any other state across transactions. T is the canonical log; K is its deterministic materialisation under Theorem 1. The pending buffer ∆ is volatile; mid-transaction crash discards ∆ and the transaction is treated as never started (atomicity preserved by §3.5). On commit, (Ti , ∆i ) are persisted atomically as a single durability unit via group commit, alongside the resulting length |Ki |. On restart, recovery walks T from the last durable position; for each T -entry not yet reflected in K (comparing |K| to the recorded |Ki |), the corresponding durable ∆i is appended to K. There is no undo, and no re-execution: the durable ∆i ’s suffice for K-extension. External sends Ξi are dispatched at-least-once on a read-side traversal of T after Ti is durable; external endpoints must deduplicate on txi . The underlying durability layer is a deployment concern. Byzantine kernelimplementation faults are out of scope; cross-replica K-divergence is detected by Theorem 1’s replay verification.
7
Patterns
Common patterns encodable on the kernel. By encodable we mean: for each pattern, there exists a set of persistent objects with specific programs that produces the desired observable behavior (responses and external sends) for message sequences within the pattern’s defined interface. What is not encodable. Operations requiring direct write-access to another object’s program or log are structurally precluded by the kernel’s no-cross-object-write property: Smalltalk’s instVarAt:put: (writing another object’s instance variables), Self’s become: (atomic identity swap), and first-class continuations that capture another object’s execution stack cannot be encoded — they would violate Theorem 2 (Read Confinement).
7.1
Object-System Encodings
Self-style delegation. A program obtains a parent’s code (via literal or message) and sends to it via ephemeral dispatch, which inherits self/log/caller. The parent’s code thus runs as the child: position 2 returns the child’s identity, position 3 the child’s log, position 4 the child’s caller, position 0 the parent’s currently-executing code. A Self object with slots {a: 1, b: 2, parent: P } encodes as a persistent object pattern-matching on the message (slot name): on hit return the value; on miss ephemeral-send to P ’s code. Mirrors map to self-reads of position 3; assignment slots use the code-change pattern; multiple parents are sequential delegation attempts. Smalltalk-style classes add one indirection over Self-style delegation: method resolution goes through a class object (persistent send), then the resolved method runs with the instance’s context (ephemeral send). Classes accumulate method definitions in their logs ([DEFINE, selector, code]) with the current dictionary as a state annotation (§6); they respond to [LOOKUP, selector] (dictionary check, recurse to superclass on miss) and [NEW, state] (create instance referencing class identity). Instances persistentsend [LOOKUP, selector] then ephemeral-send args to the returned method — exactly Smalltalk’s method execution semantics; instance variables are the state annotation (position 3). super sends [LOOKUP, selector] to the defining class’s superclass; metaclass towers terminate at a self-handling root; doesNotUnderstand: is returned when lookup reaches the root without a match. The class can amortize lookup by caching a compiled dispatcher as its state annotation. Meta-object protocols. Kernel dispatch is fixed (the six send cases), but within persistent objects, programs have full control over method dispatch, delegation, and intercession — the program is the protocol. This differs from CLOS’s MOP[10] in that there is no fixed method-combination or slot-access protocol to extend. Conventional MOP messages can be standardised as a library convention ([LOOKUP, selector] returns method or delegates; [INVOKE, selector, args] looks up and sends; [DELEGATE, parent, msg] inherits context; [SLOTS] enumerates) — opt-in interoperation, not a kernel extension.
12
Send: Objects, History, and Transactions in a Single-Verb Kernel
7.2
A P REPRINT
Pattern Catalog
Most common object-system patterns (self-recursion, proxies, conditional dispatch, pub/sub, state machines) follow directly from recall + send + BRANCH. A few are worth highlighting: • Clone / code change. Recall position 0 + send to kernel produces a same-program new object; transforming the recalled program before sending implements modification. Code change is the bootloader pattern: a fixed program traverses its log for the latest deposited code entry and dispatches to it. • Access control via identity gating. A gating object inspects caller against a predicate before returning Q’s identity — the sole point of control, since identity-as-capability is irrevocable once distributed. • Asynchronous messaging. A program sends to [7, addr] (the EXTERNAL_TAG pair); the external world re-submits as a new transaction. Auth caveat: the re-submitted transaction has caller = aext , breaking original-sender authentication (same phenomenon as §6.1 boundary degradation). • Phase-gated state machines. A persistent object branches on its log structure (e.g., TAIL(L[3]) atom vs. pair) to determine its current protocol phase; per-phase EQUAL against L[4] enforces caller-gating. A two-party escrow (buyer deposits in phase 0, seller confirms in phase 1, query returns “complete” in phase 2) falls out directly — wrong-phase callers abort by failed EQUAL, the escrow’s state is its log length.
7.3
Case Studies
The two case studies below serve different purposes. Case Study 1 (Delegation Chain with Accountability) is the central mechanism demonstration: it isolates the ephemeral/persistent classification step as the sole load-bearing difference between two otherwise-identical traces, showing that accountability (which principal is recorded in the receiver’s log) follows directly from target shape. Case Study 2 (Sealed-Bid Auction) is integrative: it shows how multiple structural properties combine to serve a specific multi-party coordination pattern. The argument is not that all six properties are jointly required for any single case study, but that the six are individually motivated by these patterns and jointly compatible under one kernel design. Case Study 2 relies on the operator-faithful trust regime; its EVM contrast is scope-conditional. Bidder proxies represent external principals; proxy-ownership is enforced by the wrapping protocol (§1), not the kernel.
7.3.1
Case Study 1: Delegation Chain with Accountability
Setup. A server B (identity 15) that returns [caller, msg], used to observe which identity the server perceives as its caller. Three experiments: 1. Ephemeral delegate P. Object A (14) delegates to ephemeral code P, which sends to B. Since P is ephemeral, it inherits A’s execution context — B sees caller = 14 (A). 2. Different ephemeral delegate P’. Object A’ (16) uses delegate P’ (which wraps the message as [42, msg]). B still sees caller = 16 (A’), because the ephemeral context is still A’. 3. Persistent delegate C. Object A’ ’ (18) sends to persistent object C (17), which forwards to B. B sees caller = 17 (C), not 18 (A’ ’). Transaction trace. Tx
Action
Result
1 2 3 4 5 6
Create A(14), B(15) Send 100 to A → P → B Create A’(16) Send 200 to A’ → P’ → B Create C(17), A”(18) Send 300 to A” → C → B
15 [14, 100] 16 [16, [42, 200]] 18 [17, 300]
B sees caller — A (14) — A’ (16) — C (17)
Key insight. The only difference between transactions 2 and 6 is whether the target is classified as ephemeral (pair target → context inherited) or persistent (atom target with birth record → context switched). Everything downstream — provenance, opacity, accountability — flows from this single classification step. Ephemeral delegation preserves the delegator’s identity (accountability without indirection), while persistent delegation introduces a new principal (the delegate acts under its own identity). This is the kernel’s central structural distinction, and it emerges from the same send operation applied to different target shapes. 7.3.2
Case Study 2: Sealed-Bid Auction
Setup. A single kernel operator (a regulated auctioneer, service provider, or trusted intermediary). Each bidder is represented in-kernel by a persistent proxy object βi ; bids must be sealed against each other while the operator is trusted not to pre-reveal. (Operator-level mutual distrust requires additional layering — see closing remarks.) Participants: bidders β1 , . . . , βn and an auctioneer object A. The auctioneer constructs each bid-object — A creates Bi rather than 13
Send: Objects, History, and Transactions in a Single-Verb Kernel
A P REPRINT
the bidder, so A knows by construction that Bi runs the canonical program pB (otherwise a bidder could substitute a Bi that returns an arbitrary value on REVEAL). Each bidder i (a) sends [REGISTER] to A; (b) A creates Bi with program pB , sends [INIT, βi ] to Bi (binding βi as the authorised storer), self-sends [TRACK, βi , Bi ] (recording the binding in A’s own log), and returns Bi to βi ; (c) βi sends [STORE, bid] to Bi . Programs. A’s program: on [REGISTER] from caller β, kernel-create Bi with pB , send [INIT, β] to Bi , self-send [TRACK, β, Bi ], return Bi ; on [REVEAL_ALL], walk own log for TRACK entries, send REVEAL to each Bi , return the bidder with the highest revealed bid. Bi ’s canonical program pB : recover A from its birth-record caller (the kernel-set caller of the first log entry) and β from the INIT entry; on [STORE, bid] from caller = β, the kernel auto-logs the entry; on [REVEAL] from caller = A, return the stored bid; otherwise FAIL. Transaction trace. Tx
Action
Result
1 2 3 4 5
β1 sends [REGISTER] to A β1 sends [STORE, 100] to B1 β2 sends [REGISTER] to A β2 sends [STORE, 150] to B2 REVEAL_ALL to A
A creates B1 , INIT β1 , TRACK; returns B1 B1 ’s log: [β1 , [STORE, 100]] A creates B2 , INIT β2 , TRACK; returns B2 B2 ’s log: [β2 , [STORE, 150]] atomically: A → B1 (returns 100), A → B2 (returns 150); A returns β2
In Tx 5, both REVEAL sends are sub-sends of one transaction. If any Bi aborts (returns ⊥), the whole transaction aborts — selective withdrawal after observing others’ bids is structurally impossible. Property analysis. Each of the six properties is load-bearing: • Opacity: Bi ’s log is invisible to other bidder-programs; bids are sealed without hash commitments or zkproofs. Sealing is structural rather than cryptographic. • Authenticated provenance: Bi ’s birth record (kernel-set caller = A) identifies its creator; the INIT entry binds βi ; STORE and REVEAL callers are verified against these kernel-set identities (no program can write position 4). A’s construction of Bi closes the trust chain — the canonical program is what A supplied. • Atomic coordination: reveal across all Bi occurs in one transaction; no bidder can selectively withhold after observing others. • Immutability of history: once [βi , [STORE, bid]] is recorded in Bi ’s log, the bid cannot be revised; commitment is irreversible. • History-derived state: A’s “committed bidders” set and the winner are both folds over A’s log. No mutable auctioneer state. • Deterministic replay: any party with appropriate access can re-execute over T to verify the winner. Operator-level observation. Within this trust model, the kernel operator can read K — the structural opacity is against bidder-programs, not against the operator. Nevertheless, the operator cannot fabricate log entries: any divergence between the operator’s claimed K and the deterministic replay of T is externally detectable. The kernel separates operator read access (unprotected) from operator write access (constrained by replay-verifiability) — providing an “honest operator under audit” guarantee even without cryptography. Contrast with existing systems. EVM-based sealed-bid auctions require explicit hash-commit / reveal protocol code with gas cost at every step; the kernel does this structurally (under stated operator trust). Akka Classic’s sender is settable by the caller (tell(msg, anyRef)); Akka Typed removes implicit sender entirely, making sender identity a protocol convention. Either way, authentication is at the protocol layer (typically via signed messages) rather than kernel-enforced — Bi cannot rely on a structural platform guarantee that REVEAL came from A. Datomic exposes facts to readers, violating opacity. Each existing system fails at least one of the simultaneous properties this protocol relies on. Compilation to a multi-party protocol (Viaduct sketch). When no party can be designated trusted operator, the kernel composes with a cryptographic compiler in the sense of Viaduct[24]: kernel programs become specifications compiled into multi-party protocols using MPC, commitments, and ZK proofs. For kernel programs over a fixed set of principal-identities (known at compile time), object-identity structure determines the label lattice: each persistent object’s identity is its confidentiality label, and send dispatch induces label flows (a value sent from A to B acquires label {A} at B). The compiler identifies cross-label flows and inserts MPC for cross-bidder aggregation, ZK for winner-announcement declassification, and per-bidder encryption against operator read access. Obligations: (a) aborts must be uncorrelated with private values (compiler-checkable IFC; otherwise abort patterns leak distribution); (b) the auctioneer program must be a commutative function of bids — a program-level property the developer ensures, with §3.2 purity already excluding operator-private state. The kernel’s dynamic-allocation capability extends beyond 14
Send: Objects, History, and Transactions in a Single-Verb Kernel
A P REPRINT
Viaduct’s static-label framework; this sketch covers only the static-allocation subset, with dynamic extension as future work.
8
Related Work
The kernel realises the six structural properties of §1 as kernel-level guarantees (opacity against program-level participants under operator-faithful trust; atomic commit per kernel instance). It deliberately omits attenuable capabilities, resource bounding, read-only reads, and async/promise composition (§4 gating, §3.4 deferred resource model, §6.3 read-set-as-write-set, §7 fire-and-forget external sends). The closest existing systems share subsets: Akka Persistence (immutable history, history-derived state, partial opacity); Goblins (opacity, local atomic commit); Datomic (immutable history, history-derived state, atomic commit). Detailed divergences below, organised by tradition. The comparison below summarises each system’s property coverage under §4.4’s Definition of kernel-level enforcement; cell verdicts trace to the per-system prose in §§8.1–8.3. System
Prov Opac Atom Repl Imm Hist 14,15
Smalltalk Self1,2 EVM5 Akka Persist.22 Datomic18,19 Clinger20 Spritely Goblins16 Nock/Urbit3,4 Send kernel
U U U U — U U U K
U U K* U — K K K K
— — K — K — K U K
— — K U K K K K K
— — K K K K K K K
— — U K K K U K K
Headers: Prov = auth. provenance; Opac = opacity; Atom = atomic commit; Repl = det. replay; Imm = immut. history; Hist = hist-derived state. Cells: K = kernel-level (transition refuses violating states / structural property of the dispatch); U = user-level (held by programmer convention or per-application implementation); — = system lacks the concept or property is not applicable. * EVM storage is per-contract opaque under the EVM opcode set; the underlying state trie is publicly readable from outside the VM, so opacity is conditional on the deployment exposing only the VM-level interface.
The kernel row is the unique fully-kernel-level coverage of these six properties under the Definition; alternative designs distribute the kernel/user-level boundary differently (e.g., EVM accepts user-level provenance via DELEGATECALL to make composition more permissive; Datomic accepts no caller concept because facts are unauthenticated). 8.1
Object Systems and Messaging
Smalltalk (Kay 1993[14], Ingalls 1981[15]). Shared: objects-and-messaging foundation, opaque references, receiver controls response. Divergences: assignment is not a message (kernel: send is the only cross-object interface); mutable instance variables vs. append-only history; class-based vs. flat dispatch; instVarAt:/become: break encapsulation (kernel: structurally precluded). Self (Ungar and Smith 1987[1], Chambers et al. 1989[2]). Shared: prototype orientation, delegation via message send, no class/instance distinction. Divergences: mutable slots vs. append-only history; mirrors expose state externally vs. structural opacity; explicit parent slots vs. ephemeral-send context inheritance; no transactional coupling. Selfstyle prototypes and delegation are encodable here (§7); operations requiring direct write-access to another object (Self’s become:) are structurally precluded by Theorem 2. Capability-based security (Dennis and Van Horn 1966[8], Miller 2006[9], Miller et al. 2003[21]). Shared: identityas-capability, unforgeable references. Divergences: capability systems typically support attenuation/revocation (kernel: non-attenuable, irrevocable); the kernel additionally couples capability use to a per-object append-only audit log. EVM (Wood 2014[5]). Shared: transaction-based state transitions, deterministic execution. Divergences: mutable storage slots vs. append-only logs; code-data separation vs. code-is-data; transparent contracts (code readable on-chain) vs. opaque objects; explicit gas metering vs. kernel-level none (composition-layer scope); ad-hoc DELEGATECALL vs. structural delegation via context inheritance.
15
Send: Objects, History, and Transactions in a Single-Verb Kernel
8.2
A P REPRINT
Actors and Process Calculi
Actor model (Hewitt et al. 1973[6], Agha 1986[7], Clinger 1981[20]). Shared: message passing, encapsulation, objects-as-principals. Clinger’s histories are the direct intellectual ancestor of “state is history”; the distinction is denotational (Clinger) vs. operational-runtime (kernel) — Clinger’s histories are system-wide and external; the kernel’s logs are per-object and opaque. Further divergences: actors evolve via Agha’s become (behavior replacement; kernel: append-only history retains all prior behavior); no transactional coupling (kernel: atomic multi-send bundles); no mandatory caller disclosure (kernel: position 4). Pi-calculus (Milner 1999[11], Sangiorgi and Walker 2001[12]). Shared: name-passing as structuring principle (identity distribution = name mobility; ν = fresh allocation; interaction mediated by names). Divergences: pi-calculus has no persistence (kernel: logs and transactions); replication primitive in pi-calculus, encodable here; processes anonymous vs. kernel-assigned persistent identity. The kernel is a synchronous name-passing calculus augmented with persistent named processes, append-only observation, and atomic transactions. Erlang/OTP (Armstrong 2003[13]). Shared: per-process sequential message handling, process isolation, hot code loading (code-change pattern), fresh identity on creation. Divergences: ephemeral current state via tail-recursive evolution over immutable data vs. retained append-only history; no authenticated caller identity (kernel: kernel-enforced); no transactional coupling vs. atomic multi-send bundles; selective receive vs. submission-order processing. Spritely Goblins (Lemmer-Webber et al. 2023[16]). Closest existing system combining transactions with capability security. Opacity is kernel-level via vat-bounded isolation (no cross-vat read primitive); atomic commit is kernel-level via transactional rollback over actormap snapshots; deterministic replay is kernel-level via deterministic vat execution; immutable history is kernel-level via generational transactormap chains, where each committed generation is stable and supports time-travel debugging. Authenticated provenance is user-level: caller attribution is a per-application convention rather than a kernel-enforced primitive (no position 4 equivalent). History-derived state is user-level: canonical per-actor state is the current actormap snapshot, with the generational chain used for time-travel and recovery rather than as the state definition. A further structural divergence: CapTP/promise pipelining vs. external-world delegation. Akka Persistence (Lightbend[22]). Shared: state recovered by replaying an append-only event journal — the closest “state is history” implementation for actors. Divergences: opt-in library on mutable actors vs. append-only-only kernel state; application-defined events recording actor-internal mutations vs. kernel-structured [caller, msg] entries recording boundary crossings; no cross-actor transactions vs. multi-object atomic bundles; infrastructure-readable journals vs. structurally opaque logs. 8.3
Persistence and History
Nock/Urbit (Yarvin[3, 4]). Shared with the §5 instantiation: s-expressions over N, minimal instruction set. Shared at the kernel level: deterministic computation, code-is-data. Divergences: Nock is purely functional (Urbit adds persistence/identity at a higher layer; the kernel incorporates ephemeral/persistent at the kernel level); no kernel-level multi-object transaction bundles (Urbit processes events sequentially without atomic cross-process coupling); Urbit’s Azimuth is external infrastructure vs. kernel-internal opaque identity. Event sourcing and Datomic (Hickey 2012[18], Helland 2015[19]). Shared: state derived from an append-only event log. Datomic embodies “state is history” via immutable datoms with transactions as atomic bundles. Divergences: entity-attribute-value vs. object-oriented (no object-level opacity, no per-entry provenance, no programs-with-context). Replicated storage with per-replica logs (Terry et al. 1995[26]). Shared: append-only logs, replay-to-state. Divergences: per-replica database-wide logs vs. per-object logs; application-supplied conflict resolvers and commitsequence-number ordering vs. strict-serialisable kernel-transaction ordering; application-readable logs vs. kernelinternal opacity. The kernel composes naturally with synchronous-CP wrappers (Raft, Paxos, Calvin); composing with eventually-consistent / AP-style wrappers (Bayou[26]) loses strict serializability.
9
Conclusion
Our kernel as presented is a demonstration of architectural possibility, not yet a practical system. Three directions which remain open: • Surface languages: a usable programmer-facing language that compiles to the kernel — Self-style prototypes and Smalltalk-style classes are encodable (§7) but require concrete syntax.
16
Send: Objects, History, and Transactions in a Single-Verb Kernel
A P REPRINT
• Cryptographic composition beyond the static-allocation case sketched in §7 Case Study 2 — Viaduct-style label tracking through dynamic object allocation is open. • Production engineering: §6’s efficiency discussion is analytical; performance characterisation, source-tokernel compilation, and debugging tooling remain future work. Resource metering, distribution, consensus, and garbage collection of derived state (materialised views, snapshots, caches) are orthogonal concerns that compose with conflict-serializable scheduling (§6.3). The kernel is one foundation; commitments are explicit, the six properties hold together, and richer abstractions can be built on top.
10
Disclosure
We used LLM tools for literature search and copyediting assistance; all data and changes were reviewed manually.
References [1] Ungar, D. and Smith, R. B. "Self: The Power of Simplicity." OOPSLA, 1987. [2] Chambers, C., Ungar, D., and Lee, E. "An Efficient Implementation of Self, a Dynamically-Typed ObjectOriented Language Based on Prototypes." OOPSLA, 1989. [3] Yarvin, C. "Nock." Urbit specification. [4] Yarvin, C., Monk, P., Dyudin, A., and Pasco, R. "Urbit: A Solid-State Interpreter." Tlon Corporation Whitepaper, 2016. [5] Wood, G. "Ethereum: A Secure Decentralised Generalised Transaction Ledger." Yellow Paper, 2014. [6] Hewitt, C., Bishop, P., and Steiger, R. "A Universal Modular Actor Formalism for Artificial Intelligence." IJCAI, 1973. [7] Agha, G. Actors: A Model of Concurrent Computation in Distributed Systems. MIT Press, 1986. [8] Dennis, J. B. and Van Horn, E. C. "Programming Semantics for Multiprogrammed Computations." Communications of the ACM, 1966. [9] Miller, M. S. "Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control." PhD dissertation, Johns Hopkins University, 2006. [10] Kiczales, G., des Rivieres, J., and Bobrow, D. G. The Art of the Metaobject Protocol. MIT Press, 1991. [11] Milner, R. Communicating and Mobile Systems: The Pi-Calculus. Cambridge University Press, 1999. [12] Sangiorgi, D. and Walker, D. The Pi-Calculus: A Theory of Mobile Processes. Cambridge University Press, 2001. [13] Armstrong, J. "Making Reliable Distributed Systems in the Presence of Software Errors." PhD dissertation, Royal Institute of Technology, Stockholm, 2003. [14] Kay, A. C. "The Early History of Smalltalk." HOPL-II, 1993. [15] Ingalls, D. H. H. "Design Principles Behind Smalltalk." BYTE Magazine, August 1981. [16] Lemmer-Webber, C., Farmer, R., and Sims, J. The Heart of Spritely: Distributed Objects and Capability Security. Spritely Institute, 2025. [17] Bernstein, P. A., Hadzilacos, V., and Goodman, N. Concurrency Control and Recovery in Database Systems. Addison-Wesley, 1987. [18] Hickey, R. "The Database as a Value." Presented at Carnegie Mellon University, 2012. [19] Helland, P. "Immutability Changes Everything." CIDR, 2015. [20] Clinger, W. D. "Foundations of Actor Semantics." PhD dissertation, MIT, 1981. [21] Miller, M. S., Yee, K.-P., and Shapiro, J. "Capability Myths Demolished." Technical Report SRL2003-02, Johns Hopkins University, 2003. [22] Lightbend. "Event Sourcing with Akka Persistence." Akka Documentation. https://doc.akka.io/ libraries/akka-core/current/typed/persistence.html [23] Schneider, F. B. "Implementing Fault-Tolerant Services Using the State Machine Approach: A Tutorial." ACM Computing Surveys, 22(4):299–319, 1990. 17
Send: Objects, History, and Transactions in a Single-Verb Kernel
A P REPRINT
[24] Acay, C., Recto, R., Gancher, J., Myers, A. C., and Shi, E. "Viaduct: An Extensible, Optimizing Compiler for Secure Distributed Programs." PLDI, 2021. [25] Thomson, A., Diamond, T., Weng, S.-C., Ren, K., Shao, P., and Abadi, D. J. "Calvin: Fast Distributed Transactions for Partitioned Database Systems." SIGMOD, 2012. [26] Terry, D. B., Theimer, M. M., Petersen, K., Demers, A. J., Spreitzer, M. J., and Hauser, C. H. "Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System." SOSP, 1995. [27] Shapiro, J. S., Smith, J. M., and Farber, D. J. "EROS: A Fast Capability System." SOSP, 1999. [28] Adya, A. "Weak Consistency: A Generalized Theory and Optimistic Implementations for Distributed Transactions." PhD thesis, MIT, 1999. [29] Gilbert, S. and Lynch, N. "Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services." SIGACT News, 33(2):51–59, 2002.
18