pith. sign in

arxiv: 2605.17401 · v1 · pith:WZE2JMRDnew · submitted 2026-05-17 · 💻 cs.DC · cs.PL

Send: Objects, History, and Transactions in a Single-Verb Kernel

Christopher Goes This is my paper

Pith reviewed 2026-05-19 22:54 UTC · model grok-4.3

classification 💻 cs.DC cs.PL
keywords kernel designobject capabilitiestransactionsimmutable historysend interfaceephemeral objectsdistributed coordinationappend-only log
0
0 comments X

The pith

A minimal kernel with one send verb and ephemeral-persistent distinction enforces six coordination properties as kernel invariants.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper shows how a kernel built from s-expressions, a uniform send operation, and transactions can make six structural properties jointly compatible in one mechanism. It distinguishes ephemeral objects, which inherit the caller's context, from persistent objects, which switch to a kernel-assigned identity and append-only log. The kernel classifies every send target into one of six cases without caller input, allowing intensional dispatch that refuses violating states. Under the assumption that the kernel follows its own semantics, all six properties—authenticated provenance, opaque encapsulation, atomic multi-object commit, deterministic replay, immutable history, and history-derived state—hold against arbitrary programs. This replaces separate layered mechanisms with a single primitive that the transition function itself enforces.

Core claim

The design holds all six properties as kernel-level invariants when the kernel faithfully runs its semantics: the transition function refuses any state that violates authenticated provenance, opaque encapsulation, atomic multi-object commit, deterministic replay, immutable history, or history-derived state. Append-only logs provide immutability, replay, and history-derived state; kernel-controlled persistent dispatch supplies authenticated provenance and opacity; transactions handle atomic coordination. Five of the six survive an unconstrained operator, while full opacity against the operator additionally requires that the operator access logs only via recall and neither censors nor reorders

What carries the argument

The kernel's structural classification of every send target into one of six cases, paired with the ephemeral versus persistent object distinction, which produces uniform caller interface and intensional dispatch that enforces the properties directly in the transition function.

If this is right

  • The kernel refuses any state violating any of the six properties.
  • Authenticated provenance and opacity arise from kernel-controlled persistent dispatch.
  • Immutable history, deterministic replay, and history-derived state rest on append-only logs.
  • Atomic multi-object coordination is supplied by transactions.
  • Operator-adversarial deployments remain possible via a cryptographic compiler.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same classification mechanism could be examined for its effect on message latency when the six cases are mapped to distinct dispatch paths.
  • History-derived state computed solely from the append-only log might be checked for consistency with external observers without trusting the kernel's current memory image.
  • The uniform send interface might allow existing capability systems to be re-expressed as special cases of the six-case dispatch.

Load-bearing premise

The kernel can classify every send target into one of six cases using only its own structural rules and without any information supplied by the caller.

What would settle it

A working kernel implementation in which the classification of a send target depends on caller-supplied data or in which the transition function accepts a state that violates one of the six properties.

read the original abstract

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. 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. Operator-adversarial deployments can be realized with a cryptographic compiler.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 2 minor

Summary. The manuscript presents a minimal kernel design for multi-party object coordination that unifies six structural properties—authenticated provenance, opaque encapsulation, atomic multi-object commit, deterministic replay, immutable history, and history-derived state—via s-expressions, a uniform 'send' interface, transactions, and a primitive distinction between ephemeral (context-inherited) and persistent (context-switching to kernel-assigned identity and append-only log) objects. The kernel structurally classifies every send target into one of six cases without caller input, enabling intensional dispatch; under kernel-faithful trust the transition function refuses violating states for arbitrary programs, while operator-faithful trust is additionally required for full opacity against the operator.

Significance. If the enforcement argument can be formalized, the result would be significant for distributed systems, object-capability security, and smart-contract platforms by offering a single-verb primitive that replaces fragile layered compositions of RPC, ACLs, transaction coordinators, and event journals. The clean separation of kernel-faithful versus operator-faithful trust models and the emphasis on append-only logs for replay and history-derived state are particularly elegant; the paper earns credit for articulating the six properties explicitly and for sketching a cryptographic-compiler path to operator-adversarial deployments.

major comments (1)
  1. [Abstract] Abstract and kernel-dispatch description: the central claim that the kernel's transition function refuses states violating any of the six properties rests on structural classification of every send target into one of six cases with no caller input. The manuscript supplies neither the classification criteria (which kernel-internal metadata or object fields determine the case) nor a model of the transition relation showing rejection of invalid states; without these it is impossible to verify kernel-level enforcement of atomic multi-object commit or authenticated provenance against arbitrary programs.
minor comments (2)
  1. [Abstract] The distinction between 'kernel-faithful trust' and 'operator-faithful trust' is introduced but its precise operational meaning (e.g., what the operator may or may not do with logs) would benefit from an early clarifying sentence or small example.
  2. [Abstract] A summary table or diagram listing the six cases, the dispatch rule for each, and which of the six properties it directly supports would improve readability.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive review and for recognizing the potential significance of the single-verb kernel design for distributed systems and object-capability security. We address the major comment below and will revise the manuscript accordingly to improve verifiability of the enforcement claims.

read point-by-point responses

  1. Referee: [Abstract] Abstract and kernel-dispatch description: the central claim that the kernel's transition function refuses states violating any of the six properties rests on structural classification of every send target into one of six cases with no caller input. The manuscript supplies neither the classification criteria (which kernel-internal metadata or object fields determine the case) nor a model of the transition relation showing rejection of invalid states; without these it is impossible to verify kernel-level enforcement of atomic multi-object commit or authenticated provenance against arbitrary programs.

    Authors: We agree that the abstract is high-level and that explicit classification criteria and a transition-relation model would strengthen the presentation. The full manuscript already defines the six cases via the ephemeral/persistent distinction together with transaction context and log presence, but does not enumerate the precise kernel-internal metadata fields or supply a formal transition relation. In the revision we will add (1) a table or subsection listing the six cases with the determining metadata (object-type flag, current-transaction identifier, and append-only-log reference) and (2) a concise formal model of the transition function that shows rejection of states violating any of the six properties. These additions will be placed in the main body or an appendix so that kernel-level enforcement can be verified directly from the text. revision: yes

Circularity Check

0 steps flagged

No circularity: new kernel construction with independent architectural claims

full rationale

The manuscript proposes a minimal kernel built from s-expressions, a uniform send interface, and an ephemeral/persistent object distinction that structurally classifies every send target into one of six cases. The six properties are presented as consequences of this design under kernel-faithful trust, with the transition function refusing violating states. No equations, fitted parameters, or self-citations appear in the provided text; the central claims do not reduce to inputs by definition or construction. The derivation is therefore self-contained as an architectural proposal rather than a closed loop of redefinitions or renamings.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The central claim depends on a new object distinction and kernel dispatch logic plus trust assumptions about kernel behavior; no free parameters are evident from the abstract.

axioms (1)
  • domain assumption Kernel-faithful trust: the kernel executes its specified semantics correctly
    Required for the transition function to refuse violating states and hold the six properties at kernel level.
invented entities (1)
  • Ephemeral versus persistent object distinction no independent evidence
    purpose: To allow context inheritance for ephemeral objects and context switch plus append-only log for persistent objects
    Introduced as the one primitive object distinction enabling the uniform send interface and kernel dispatch.

pith-pipeline@v0.9.0 · 5810 in / 1267 out tokens · 32587 ms · 2026-05-19T22:54:47.268161+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

29 extracted references · 29 canonical work pages

  1. [1]

    Self: The Power of Simplicity

    Ungar, D. and Smith, R. B. "Self: The Power of Simplicity."OOPSLA, 1987

    work page 1987

  2. [2]

    An Efficient Implementation of Self, a Dynamically-Typed Object- Oriented Language Based on Prototypes

    Chambers, C., Ungar, D., and Lee, E. "An Efficient Implementation of Self, a Dynamically-Typed Object- Oriented Language Based on Prototypes."OOPSLA, 1989

    work page 1989

  3. [3]

    "Nock." Urbit specification

    Yarvin, C. "Nock." Urbit specification

    work page

  4. [4]

    Urbit: A Solid-State Interpreter

    Yarvin, C., Monk, P., Dyudin, A., and Pasco, R. "Urbit: A Solid-State Interpreter." Tlon Corporation Whitepaper, 2016

    work page 2016

  5. [5]

    Ethereum: A Secure Decentralised Generalised Transaction Ledger

    Wood, G. "Ethereum: A Secure Decentralised Generalised Transaction Ledger." Yellow Paper, 2014

    work page 2014

  6. [6]

    A Universal Modular Actor Formalism for Artificial Intelligence

    Hewitt, C., Bishop, P., and Steiger, R. "A Universal Modular Actor Formalism for Artificial Intelligence."IJCAI, 1973

    work page 1973

  7. [7]

    Agha, G.Actors: A Model of Concurrent Computation in Distributed Systems.MIT Press, 1986

    work page 1986

  8. [8]

    Programming Semantics for Multiprogrammed Computations

    Dennis, J. B. and Van Horn, E. C. "Programming Semantics for Multiprogrammed Computations."Communica- tions of the ACM, 1966

    work page 1966

  9. [9]

    Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control

    Miller, M. S. "Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control." PhD dissertation, Johns Hopkins University, 2006

    work page 2006

  10. [10]

    G.The Art of the Metaobject Protocol.MIT Press, 1991

    Kiczales, G., des Rivieres, J., and Bobrow, D. G.The Art of the Metaobject Protocol.MIT Press, 1991

    work page 1991

  11. [11]

    Milner, R.Communicating and Mobile Systems: The Pi-Calculus.Cambridge University Press, 1999

    work page 1999

  12. [12]

    and Walker, D.The Pi-Calculus: A Theory of Mobile Processes.Cambridge University Press, 2001

    Sangiorgi, D. and Walker, D.The Pi-Calculus: A Theory of Mobile Processes.Cambridge University Press, 2001

    work page 2001

  13. [13]

    Making Reliable Distributed Systems in the Presence of Software Errors

    Armstrong, J. "Making Reliable Distributed Systems in the Presence of Software Errors." PhD dissertation, Royal Institute of Technology, Stockholm, 2003

    work page 2003

  14. [14]

    The Early History of Smalltalk

    Kay, A. C. "The Early History of Smalltalk."HOPL-II, 1993

    work page 1993

  15. [15]

    Design Principles Behind Smalltalk

    Ingalls, D. H. H. "Design Principles Behind Smalltalk."BYTE Magazine, August 1981

    work page 1981

  16. [16]

    Spritely Institute, 2025

    Lemmer-Webber, C., Farmer, R., and Sims, J.The Heart of Spritely: Distributed Objects and Capability Security. Spritely Institute, 2025

    work page 2025

  17. [17]

    A., Hadzilacos, V ., and Goodman, N.Concurrency Control and Recovery in Database Systems

    Bernstein, P. A., Hadzilacos, V ., and Goodman, N.Concurrency Control and Recovery in Database Systems. Addison-Wesley, 1987

    work page 1987

  18. [18]

    The Database as a Value

    Hickey, R. "The Database as a Value." Presented at Carnegie Mellon University, 2012

    work page 2012

  19. [19]

    Immutability Changes Everything

    Helland, P. "Immutability Changes Everything."CIDR, 2015

    work page 2015

  20. [20]

    Foundations of Actor Semantics

    Clinger, W. D. "Foundations of Actor Semantics." PhD dissertation, MIT, 1981

    work page 1981

  21. [21]

    Capability Myths Demolished

    Miller, M. S., Yee, K.-P., and Shapiro, J. "Capability Myths Demolished." Technical Report SRL2003-02, Johns Hopkins University, 2003

    work page 2003

  22. [22]

    Event Sourcing with Akka Persistence

    Lightbend. "Event Sourcing with Akka Persistence." Akka Documentation.https://doc.akka.io/ libraries/akka-core/current/typed/persistence.html

    work page

  23. [23]

    Implementing Fault-Tolerant Services Using the State Machine Approach: A Tutorial

    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 KernelA PREPRINT

    work page 1990

  24. [24]

    Viaduct: An Extensible, Optimizing Compiler for Secure Distributed Programs

    Acay, C., Recto, R., Gancher, J., Myers, A. C., and Shi, E. "Viaduct: An Extensible, Optimizing Compiler for Secure Distributed Programs."PLDI, 2021

    work page 2021

  25. [25]

    Calvin: Fast Distributed Transac- tions for Partitioned Database Systems

    Thomson, A., Diamond, T., Weng, S.-C., Ren, K., Shao, P., and Abadi, D. J. "Calvin: Fast Distributed Transac- tions for Partitioned Database Systems."SIGMOD, 2012

    work page 2012

  26. [26]

    Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System

    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

    work page 1995

  27. [27]

    EROS: A Fast Capability System

    Shapiro, J. S., Smith, J. M., and Farber, D. J. "EROS: A Fast Capability System."SOSP, 1999

    work page 1999

  28. [28]

    Weak Consistency: A Generalized Theory and Optimistic Implementations for Distributed Transac- tions

    Adya, A. "Weak Consistency: A Generalized Theory and Optimistic Implementations for Distributed Transac- tions." PhD thesis, MIT, 1999

    work page 1999

  29. [29]

    Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services

    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

    work page 2002