[Cryptography] DSM: deterministic edge state machine (post-quantum, no public ledger/consensus)
cryptskii at proton.me
cryptskii at proton.me
Fri Aug 28 13:46:36 EDT 2026
Hi all,
A concise overview of the offline model as well as the actual implementation:
Decentralized state transitions in offline environments have historically struggled to reconcile two competing paradigms: retroactive double spend detection and hardware enforced prevention.
The retroactive lineage, pioneered by David Chaum, Amos Fiat, and Moni Naor in 1988, and given an elegant construction by Stefan Brands in 1993, mathematically strips a spender's anonymity if they double spend a coin. While secure, it defers enforcement to a post facto deposit step, which is poorly suited for general purpose state execution or non monetary coordination.
To prevent double spending outright at the offline edge, we historically rely on David Chaum and Torben Pedersen's "Wallet Databases with Observers" in 1992, also situated in Brands' work. In the Observer model, a tamper resistant physical chip, the Observer, co signs each payment and is trusted to act as the transaction authority by refusing to sign the same coin index twice.
We believe the Observer model is fundamentally flawed. Making hardware the transaction authority makes the hardware's physical silicon attack surface the entire protocol's attack surface. If an attacker glitches a chip's internal clock or registers, they bypass the double signing check and destroy the entire ledger's integrity. Furthermore, relying on transient slot states in commercial secure elements is structurally fragile; for instance, cryptographic slot states, such as MAC based or PIN verification slots, are often host restorable by replaying known inputs, meaning they carry no true forward only, non rewindable lineage.
The Deterministic State Machine protocol, or DSM, introduces a clean separation of concerns that inverts Chaum's model:
* Software enforces state transition correctness and transfer uniqueness.
* Hardware, the Anchor, serves strictly to verify the uniqueness of the physical device instance.
In DSM, the hardware is semantics blind and never acts as a transaction authority. The receiver's offline acceptance predicate reads no live chip state, no live host state, no raw hardware counter, no relay session, no verifier slot, no boot ticket, and no MAC output. Instead, double spend prevention is a pure mathematical property of whole state consumption in software.
The entire device state is committed inside a sparse Merkle tree, or SMT. A parent state root is consumed as a whole, admitting exactly one accepted and executed successor at an honest acceptance point. The hardware's only job is to prove that this software transition was executed on the one, uniquely enrolled physical device, rather than a software clone.
To achieve this without letting hardware dictate transaction validity, DSM binds offline bearer transfers to a three factor identity witness over a single root advance message:
1. Factor 1, User Entropy: A signature under seed derived keys proving user intent, using the DSM device signature scheme.
2. Factor 2, Silicon Identity: An Ed25519 signature executed inside a TROPIC01 secure element under a resident key pair generated in slot at birth. The private half is non exportable and protected at rest by the silicon's Physically Unclonable Function, or PUF.
3. Factor 3, Host Firmware: A signature generated inside the secure partition of the RP2350 microcontroller.
The Role of the RP2350 Measurement Gate
In a standard secure element setup, the secure chip cannot verify if the host platform has been compromised; it signs whatever raw bytes are sent over the SPI bus. If an attacker gains root access on the host, they can convert the secure element into an oracle for fraudulent transitions.
DSM blocks this through measurement gating. At appliance birth, the RP2350 host partition key is generated under a partition seal p0. The unsealing gate is the enrolled firmware measurement. Only firmware whose measurement matches the enrolled policy hash may obtain the host signing service. Firmware replacement therefore does not give an attacker a programmable signing oracle: rogue firmware receives an unsealing failure and cannot produce the host witness. The chip and host witnesses are minted at commit, after the one way counter decrement, so no valid release witness for an origin exists while that origin is still spendable. Under enrolled firmware, the appliance is single threaded, maintains one active state, permits at most one prepared record per frontier, exports no release before commit, and recovery only re emits the same committed release. Therefore a single enrolled appliance cannot originate two distinct valid offline releases from the same origin, including to disconnected first contact receivers.
Demoting the Monotonic Counter to a Tripwire
DSM does include a monotonic counter, but its placement is radically different from the Observer literature.
The authoritative register is a monotone counter committed directly as a leaf of the device SMT, making the software state position explicit inside the consumed state. The physical counter inside the TROPIC01 merely tracks the SMT counter one to one where the anchor counter coordinate ui equals H0 minus H.
The physical counter is not an acceptance authority. It acts strictly as:
* A non rewind floor to reject stale software image rollbacks.
* A budget cap on offline exposure.
If an attacker restores a backup of their old software state root to attempt a double spend, the old software image records an older coordinate. The hardware appliance detects this desynchronization during recovery and permanently refuses offline operations, failing closed.
The Single Appliance Execution Guard
To prevent a malicious host from executing prepare abort cycles to harvest multiple signed certificates for a single state origin, DSM enforces a strict Commit Discipline:
* Prepare Phase: The appliance checks the parent root and counter synchronization but mints no signatures. Prepare stores only the staged fields, producing no signed release certificates.
* Commit Phase: The appliance stores the committed candidate, re pins the counter, executes exactly one physical raw counter update, and only then mints the chip and host signatures over the root advance message.
Because witnesses come into existence only after the irreversible physical counter step, single use of the host witness is a physical timing property of the hardware counter, rather than a confidentiality property of host storage.
Under enrolled firmware, the single appliance maintains one active state, permits at most one prepared record per frontier, and exports nothing before commit. Consequently, a single physical appliance cannot mathematically or physically emit two distinct valid offline releases from the same origin, ensuring that disconnected first contact receivers are completely protected against double spending.
The full specification paper and the active TLA specification sketch can be found in our repository. We welcome academic review and adversarial feedback.
You can view the full development workspace, specifications, and papers here:
GitHub Repository: https://github.com/deterministicstatemachine/dsm
Project Website: https://www.deterministicstatemachine.org/DSM_Software_Authority_Hardware_Identity.pdf
Community: https://t.me/+agb3_DHBcCI5MTkx
Thanks for checking it out,
Brandon
More information about the cryptography
mailing list