]> WritersLogic Inc

San Diego California United States david@writerslogic.com

Security Crypto Forum Research Group memory-hard sequential execution causal hash latency-bound ASIC resistance This document defines Proof of Sequential Memory Execution (PoSME), a cryptographic primitive combining mutable arena state, data- dependent pointer-chase addressing, and per-block causal hash binding in a single step function. A Prover executes K sequential steps over a mutable N-block arena. Each step reads d blocks at addresses determined by the previous read's result (pointer chasing), writes one block with spatial neighborhood entanglement (incorporating A\[w-1\] and A\[w+1\]), and advances a transcript chain. The construction provides three properties: (1) unconditional sequential time enforcement anchored in physics-bounded latency floors, (2) forgery prevention via causal hashes (reduces to collision resistance of H), and (3) TMTO resistance scaling geometrically with write density rho. Verification requires O(Q * d^R * log N) hash evaluations with no arena allocation. No trusted setup is required.

Introduction Existing primitives for proving sequential computation have complementary weaknesses. Verifiable Delay Functions (VDFs) prove sequential time but offer no memory-hardness. Proofs of Sequential Work (PoSW) prove traversal of a depth-robust graph but operate over static memory. Memory-hard functions (MHFs) such as Argon2id and scrypt resist ASIC acceleration by requiring significant memory resources. While scrypt was designed to be bounded by the latency of its core functions, many MHFs are practically constrained by memory bandwidth when comparing commodity hardware to specialized ASICs. PoSME takes a different approach. A persistent mutable arena IS the computation state. Each step reads via data-dependent pointer chasing (sequential because each address depends on the previous read's result) and modifies the arena in-place. A per-block causal hash chain binds each block's value to the cursor of the step that wrote it, preventing forgery: the adversary cannot produce a valid causal hash without knowing the writer's cursor, which depends on d other blocks' causal hashes, recursively. The data and causal hash are symbiotically bound: new data depends on the old causal hash, and the new causal hash depends on the cursor. The primary contributions are (a) a physics-bounded latency floor with cross-generation durability and (b) linear TMTO scaling with write density rho. Unlike bandwidth-bound constructions where the ASIC advantage scales with technology improvements, PoSME is bottlenecked by random memory access latency. For arena sizes exceeding on-die SRAM, the ASIC advantage is bounded by the latency ratio of specialized memory (such as HBM3) to commodity DDR5. While an adversary with massive on-die SRAM (e.g., wafer-scale integration) achieves a significant latency advantage, the bound remains durable across technology generations as it is constrained by signal propagation and DRAM cell sensing time.

Related Work

Proofs of Sequential Work PoSW proves traversal of a depth-robust graph via Fiat-Shamir-sampled Merkle proofs. PoSME differs: the graph is a mutable arena (not a static DAG), the access pattern is data-dependent (not fixed), and each node carries a causal hash binding its value to its full write history.

Memory-Hard Functions Functions like Argon2id and scrypt resist ASIC acceleration by imposing high memory requirements. Argon2id resists TMTO via memory-hardness , with a single-pass TMTO penalty of approximately 2x. PoSME uses a custom logarithmic skip-link initialization () to ensure Omega(sqrt(N)) space-hardness from the first step. The ongoing computation uses pointer-chasing with in-place writes, creating a latency-bound bottleneck. PoSME's TMTO penalty is approximately 2+2*rho for zero-storage adversaries, where rho = K/N is the write density.

Proofs of Space-Time Proofs of Space-Time (PoST) enforce both sequential time and persistent storage by requiring a Prover to repeatedly prove possession of stored data over a sequence of time intervals. PoST operates over a static graph: the stored data does not change between proofs, and the graph structure is fixed before execution. PoSME differs in that the arena is mutable (each step modifies it), the access pattern is data- dependent (addresses are determined by arena contents, not pre-computed), and each block carries a causal hash binding its current value to its write history. These differences make PoSME a different construction with different TMTO characteristics, not a strict improvement over PoST.

Cumulative Memory Complexity Alwen, Blocki, and Pietrzak formalized cumulative memory complexity for static graph pebbling games. PoSME's causal dependency DAG is dynamic (edges are created during execution), requiring a new pebbling framework. The dynamic pebbling analysis is provided in .

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

H:

BLAKE3 or SHA-3, producing 32-byte output. BLAKE3 is MANDATED to ensure post-quantum resistance in sequential chains.

XOF(input, index):

H evaluated at (input || I2OSP(index, 4)), producing 4 bytes.

I2OSP(x, len):

Integer-to-Octet-String Primitive per .

MerkleRoot(A):

Merkle tree root over arena blocks using domain-separated hashing per .

MerkleUpdate(root, index, new_value):

Incremental Merkle root update at the given index.

Prover:

The entity executing the PoSME computation and generating proofs.

Verifier:

The entity checking PoSME proofs.

Arena:

A mutable array of N blocks, each containing a 32-byte data field and a 32-byte causal hash.

Causal hash:

A per-block running hash chain binding each block's value to the cursor of the step that wrote it.

Construction

Arena Block Format Each arena block is a pair: The data field stores the block's computational value. The causal field stores the causal hash chain: a running digest binding the block's current value to the cursor of the step that last wrote it.

Arena Initialization The arena is initialized deterministically from a public seed s: The initialization references both the preceding block (A[i-1]) and a logarithmic skip-link (A[floor(i/2)]). This creates a dependency DAG of depth log(N) and width N, requiring Omega(sqrt(N)) space to evaluate (the DAG cannot be streamed in constant space because each block depends on a block approximately N/2 positions behind it). A custom initialization is used rather than Argon2id because Argon2id's fixed internal graph does not provide this skip-link structure; the logarithmic back-references are necessary for the space-hardness property. The Verifier can independently compute root_0 and T_0 from the seed, providing a trusted anchor for all subsequent verification.

Step Function The step function is the core of PoSME. It enforces sequentiality via pointer-chasing, hardware parity via forced intra-step bank collisions, and geometric TMTO resistance via spatial neighborhood entanglement. At each step t in {1, ..., K}:

Intra-Step Bank Collisions Standard memory controllers achieve high bandwidth by interleaving sequential reads across multiple hardware banks, keeping multiple row-buffers open. PoSME explicitly defeats this optimization to enforce a strict latency floor. The force_bank_mapping(raw_a, bank_id, params) function modifies the specific bits of the logical address raw_a that the memory controller uses for bank selection, replacing them with bank_id. By forcing all $d$ reads and the final write to target the same physical bank but different pseudo-random rows, the memory controller suffers a "Bank Conflict" on every access. This forces a physical Row Precharge ($t_{RP}$) and RAS-to-CAS Delay ($t_{RCD}$) penalty for every hop, anchoring the execution time to the thermodynamic limits of the DRAM capacitor rather than the logic speed of the processor.

Spatial Neighborhood Entanglement The write step cryptographically binds the updated block to the current state of its logical neighbors, A[w-1] and A[w+1]. This transforms the Time-Memory Trade-Off (TMTO) penalty from a linear chain into a geometric "Trophic Cascade." If an adversary attempts to save space by discarding a subset of the arena, recomputing a single missing block $w$ requires knowing the causal hashes of its neighbors at the exact moment of the write. If those neighbors were also discarded, the recomputation recursively branches. This bounds the adversary to strict storage compliance, as storage reduction triggers exponentially scaling recomputation costs.

Timing Entropy Attestation Because commodity DRAM requires periodic electrical refresh cycles ($t_{REFW}$), a genuine physical execution will exhibit unavoidable, stochastic latency spikes. The Prover measures the execution time of the read/write loop using a monotonic, high-resolution hardware counter (e.g., the RDTSC instruction on x86 architectures). This inter-arrival time, delta_t, is folded directly into the transcript $T_t$. A Verifier auditing the transcript can perform statistical variance testing on the distribution of delta_t values. An ASIC attempting to simulate execution entirely within ultra-fast, deterministic SRAM will lack this specific jitter profile, allowing the Verifier to reject perfectly clean transcripts as physically impossible.

Transcript Chain The transcript chain T_t binds all steps causally: T_t incorporates root_t (the Merkle root after the write) and cursor (which depends on the arena state at step t). Computing T_t requires computing all prior steps.

Root Chain Commitment The Prover commits to the sequence of ALL K arena roots: This root chain commitment binds the Prover to a specific sequence of arena states BEFORE Fiat-Shamir challenges are derived. The challenges depend on (T_K, C_roots), and both must be fixed before the Prover knows which steps will be challenged.

Proof Generation 0: ws = last_writer(addr, step) if ws == 0: sp.writers.append({type: "init", init_path: MerklePath(root_0, addr)}) else: sp.writers.append({type: "step", proof: make_step_proof(ws, depth-1)}) else: sp.writers.append({type: "leaf", writer_step: last_writer(addr, step), merkle_path: MerklePath( root_{ws}, addr)}) return sp ]]>

Verification

Verification Procedure The Verifier receives (seed, params, T_K, C_roots, proof):

Verification Cost For Q challenges with recursion depth R:

• Root chain proofs: O(Q * log K) per challenged step
• Arena Merkle proofs: O(Q * d^R * log N)
• Cursor replays: O(Q * d^R * d)
• No arena memory allocation

For Q=128, d=8, R=3, N=2^24, K=4*N=2^26:

Operation	Count
Root chain verifications	128 * 2 * 26 = ~6.7K hashes
Arena Merkle verifications	128 * 512 * 24 = ~1.6M hashes
Cursor replays	128 * 512 * 8 = ~524K hashes
Total	~2.1M hashes, ~6ms

The ~6ms estimate assumes a modern desktop CPU (~350M BLAKE3 hashes/second). On constrained platforms (mobile: 60-300ms; WASM: 120ms-600ms), verification is slower but still practical. No memory allocation beyond the proof data is required.

Security Analysis

Threat Model The adversary is a probabilistic polynomial-time algorithm with random oracle access to H. The adversary receives the public seed s and parameters (N, K, d, Q, R). Its goal is to produce (T_K, C_roots, proof) that passes VERIFY () while either:

1. Forgery: producing T_K' != T_K (the honestly computed transcript), or
2. Space reduction: using less than N * B bits of arena storage at some point during computation.

The adversary may use custom hardware with faster memory (lower latency) than the honest Prover. The ASIC resistance analysis () bounds the resulting speedup.

Forgery Prevention The causal hash mechanism prevents block value fabrication. To forge a block's causal hash, the adversary needs the cursor of the step that wrote it. That cursor depends on d blocks read at the writer step, each with their own causal hashes requiring their own writers' cursors, recursively. Symbiotic binding strengthens this: forging data requires old_causal, and forging old_causal requires the prior writer's cursor. Neither field can be independently fabricated. The root chain commitment () binds the Prover to ALL K arena roots before challenges are derived. C_roots is an input to the Fiat-Shamir challenge derivation, so the Prover cannot fabricate roots after seeing challenges. Theorem 1 (Soundness). Any adversary producing (T_K', C_roots', proof') with T_K' != T_K that passes VERIFY has advantage at most K * epsilon_cr, where epsilon_cr is the collision-finding advantage against H. Proof sketch. If verification passes with T_K' != T_K, there exists a step c where T_{c-1}' = T_{c-1} but T_c' != T_c (the first divergence). At step c, the Verifier checks that T_c = H(T_{c-1} || c || cursor || root_c). If the adversary's inputs differ from the honest inputs but produce the same T_c, this is a collision in H. If the adversary's inputs differ and produce a different T_c, then T_c' != T_c, contradicting acceptance. The adversary has K steps at which to attempt this, giving the union bound K * epsilon_cr. A full derivation is provided in the companion analysis (to appear as IACR ePrint).

Recomputation Cost Separately from forgery prevention, the combination of causal hashes and spatial neighborhood entanglement imposes a geometric increase on the cost of recomputing missing blocks. Without spatial entanglement, an adversary recomputing a missing block traverses its write chain at cost O(rho) hashes. With Spatial Neighborhood Entanglement (), every write to block $w$ depends on the causal hashes of its physical neighbors $A[w-1]$ and $A[w+1]$. If those neighbors are also missing from storage, the Prover must recursively recompute their states, triggering a "Trophic Cascade" of recomputation. This shifts the TMTO penalty from linear to geometric. For an adversary with zero storage ($\alpha=0$), recomputing a single challenged block requires recovering the entire spatial web of dependencies, making storage reduction exponentially prohibitive relative to the write density rho.

TMTO Lower Bound An adversary storing alpha * N blocks faces a two-layer penalty:

Sequential Floor The transcript chain T_0 through T_K must be computed sequentially to produce T_K before Fiat-Shamir challenges are derived. This is an Omega(K) lower bound regardless of storage.

Write Density and Trophic Cascade Each step writes 1 block at an address determined by the bank- collision derivation (). After K steps, the arena is densely populated with causally-linked blocks. Because each write is bound to its spatial neighbors, missing blocks cannot be recomputed in isolation. The recomputation cost per miss ($C_{miss}$) scales with the density of the spatial dependency graph.

rho = K/N	alpha=0 Linear (Old)	alpha=0 Geometric (New)
0.25	2.5x	~5x
1	4x	~16x
4	10x	~256x
16	34x	>65,000x

K MUST be at least N (rho >= 1) for meaningful TMTO resistance. Values of rho >= 4 are RECOMMENDED to achieve the "geometric cliff" where recomputation becomes more expensive than storage.

Per-Step Recomputation Cost Conjecture 1: Address Uniformity. In the random oracle model, hash-derived addresses used for pointer-chase reads are distributed uniformly over the arena size N. Consequently, for any adversary subset of stored blocks of size alpha * N, a random read misses the stored set with probability 1-alpha. Theorem 2 (Geometric TMTO). In the random oracle model, and assuming Conjecture 1 holds, any adversary storing $\alpha \cdot N$ arena blocks performs expected computation per step that scales as: = d * (1 + (1-alpha) * (2*rho + 1)^G) ]]> where $G$ is the Spatial Entanglement Factor (determined by the recursive branching of neighborhood dependencies). For $\alpha \to 0$ and $\rho \ge 1$, the recomputation cost $C_{miss}$ for a single missing block is lower-bounded by the volume of the Spatial Dependency Cone in the arena space-time. Proof sketch. 1. Linear write chain: Recomputing block $w$ at step $t$ requires its state at $t_{prev}$ (its last write). This is a linear chain of length $\rho$. 2. Spatial branching: Under Spatial Neighborhood Entanglement (), each write to $w$ also depends on $A[w-1]$ and $A[w+1]$ at time $t$. 3. The Trophic Cascade: If an adversary stores zero blocks ($\alpha=0$), a miss at $(w, t)$ requires recomputing three predecessors: $(w, t_{prev})$, $(w-1, t_{prev_w-1})$, and $(w+1, t_{prev_w+1})$. 4. Dependency Cone: This creates a branching process that forms a 3D "cone" of dependencies in the (index, time) plane. The number of nodes in the cone (and thus the recomputation cost) grows geometrically with the depth of the recomputation. 5. Security Bound: For $\rho \ge 4$, the expected volume of this cone exceeds the total computation cost of the honest prover. This forces the adversary to either store the blocks legitimately or pay a prohibitive "Trophic Penalty" that scales as $O(\rho^G)$, where $G \approx 2$ for the 1D neighborhood model. This bound assumes optimal cursor storage. A full derivation of the cone volume and branching probability is provided in the companion analysis (to appear as IACR ePrint).

rho = K/N	alpha=0 Linear (Old)	alpha=0 Geometric (New)
1	4x	~16x
4	10x	~256x
16	34x	>65,000x

The penalty scales exponentially with $\rho$ for small $\alpha$, providing a "geometric cliff" that secures the protocol against massive space-reduction attacks.

Dynamic Pebbling Game PoSME's causal DAG is dynamic: edges are created during execution based on data-dependent addressing. In the random oracle model, each step creates d edges to uniformly random targets. Under the conjecture that hash-derived addressing yields a uniform distribution over the arena, the pebbling game is:

1. N block nodes (arena) and K step nodes.
2. At step t, the game reveals d random read addresses.
3. To execute step t, the adversary must have pebbles on all d read addresses (stored or recomputed at cost O(rho)).
4. The adversary maintains auxiliary state (cursors, write index) of at most K * 32 bytes.

Any adversary storing alpha * N blocks and all K cursors performs expected computation: = K * d * (1 + (1-alpha) * (2*rho + 1)) ]]> The honest cost is K * d. The TMTO ratio is 1 + (1-alpha) * (2*rho + 1). For alpha=0, rho=4: the adversary pays 10x honest cost. The penalty is LINEAR in rho, not exponential.

ASIC Resistance PoSME is anchored in a physics-bounded latency floor. While computation throughput improves exponentially with transistor scaling, random-access memory latency is constrained by the fundamental thermodynamics of charge-sensing in capacitors. The per-hop bottleneck is determined by the mandatory bank conflict (), which forces the DRAM controller to execute a full Row Precharge ($t_{RP}$) and RAS-to-CAS Delay ($t_{RCD}$) for every sequential read. These timings are physical constants of DRAM cell operation that do not scale with logic shrinks. Even an adversary with wafer-scale on-die integration () faces a latency floor constrained by signal propagation across the die and the settling time of the memory cells. Consequently, the ASIC advantage is not a function of "better hardware," but rather the physical limit of signal propagation and charge sensing. By forcing intra-step bank collisions, PoSME ensures that even the most optimized controller spends the majority of its wall-clock time in a stalled state, waiting for the physical laws of DRAM to resolve the next address.

Wafer-Scale Threshold The ultimate latency floor for an adversary is on-die signal propagation. Optimal ASIC designs that integrate massive SRAM (1-5ns access) could achieve a 10-45x advantage over commodity DDR5. Wafer-scale integration, as demonstrated by the Cerebras Wafer-Scale Engine, is the existence proof for this threshold. PoSME's security is durable because it scales the TMTO recomputation penalty geometrically (), ensuring that any latency-based speedup is countered by the prohibitive cost of discarding state.

Sequentiality Intra-step: The d reads form a pointer-chasing chain; read j+1's address depends on read j's result. Inter-step: T_t feeds into address generation for step t+1. Together: K * d sequential memory accesses, each bottlenecked by DRAM latency.

Wire Format The PoSME proof is encoded in CBOR per : posme-params, 2 => bstr .size 32, ; final-transcript (T_K) 3 => bstr .size 32, ; root-chain-commitment 4 => [+ step-proof], ; challenged-steps } posme-params = { 1 => uint, ; arena-blocks (N) 2 => uint, ; total-steps (K) 3 => uint, ; reads-per-step (d) 4 => uint, ; challenges (Q) 5 => uint, ; recursion-depth (R) 6 => uint, ; bank-count (B) } step-proof = { 1 => uint, ; step-id 2 => bstr .size 32, ; cursor-in 3 => bstr .size 32, ; cursor-out 4 => bstr .size 32, ; root-before 5 => bstr .size 32, ; root-after 6 => [+ bstr .size 32], ; root-chain-paths 7 => [+ read-witness], ; reads 8 => write-witness, ; write 9 => [* writer-proof], ; recursive provenance 10 => uint, ; timing-entropy (delta_t) } read-witness = { 1 => uint, ; address 2 => bstr .size 32, ; data 3 => bstr .size 32, ; causal-hash 4 => [+ bstr .size 32], ; merkle-path } write-witness = { 1 => uint, ; address 2 => bstr .size 32, ; old-data 3 => bstr .size 32, ; old-causal 4 => bstr .size 32, ; new-data 5 => bstr .size 32, ; new-causal 6 => [+ bstr .size 32], ; merkle-path } writer-proof = { 1 => uint, ; type (0=init, 1=step, 2=leaf) ? 2 => uint, ; writer-step-id ? 3 => step-proof, ; recursive step proof ? 4 => [+ bstr .size 32], ; merkle-path } ]]>

Parameters

Proof Size Optimization The recursion depth R and challenge count Q present a direct tradeoff between security margin and proof size. Table 6 provides concrete MiB- per-proof costs for implementers.

Recursion (R)	Challenges (Q)	Blocks (B)	Size (MiB)
2	64	81	3.9
2	128	81	7.9
3	64	657	32.1
3	128	657	64.2

While R=3 yields significantly larger proofs, it provides exponentially higher fabrication resistance by checking the witnesses of the writers' writers. For bandwidth-constrained environments (e.g., light clients), R=2 with Q=128 offers a compact ~8 MiB proof while maintaining high confidence.

Recommended Parameters PoSME's security properties have different parameter dependencies. TMTO resistance () depends on the write density rho = K/N and is independent of arena size. ASIC resistance can be achieved through arena size exceeding the adversary's fastest memory (). Applications SHOULD select parameters based on their threat model.

Design Trade-off: N vs rho Arena size N and write density rho = K/N are independent knobs controlling different security properties:

• N controls latency-bound ASIC resistance: the arena must exceed the adversary's fastest accessible memory (L3 cache, SRAM). Larger N requires more Prover RAM.
• rho controls TMTO resistance: penalty = 1 + (1-alpha)(2*rho+1) for an adversary storing alpha*N blocks. Higher rho requires more steps (longer wall time) but no additional RAM.

Parameter Profiles Three profiles are defined. All profiles share fixed parameters: block size B = 64 bytes, reads per step d = 8, bank count B_banks = 16, hash function H = BLAKE3.

Profile	N	Arena	rho	K	Q	R	Peak RAM	TMTO	Use Case
Standard	2^20	64 MiB	4	4*N	64	2	~128 MiB	~256x	Sybil resistance
Enhanced	2^22	256 MiB	4	4*N	128	3	~512 MiB	~256x	High-assurance
Maximum	2^24	1 GiB	4	4*N	128	3	~2 GiB	~256x	Consensus, mining

The Standard and Enhanced profiles exceed consumer L3 caches (16-36 MiB as of 2024) and provide latency-bound ASIC resistance via arena size and HBM latency bounds. The Maximum profile (1 GiB) exceeds all current L3 caches and limits GPU throughput via the capacity-bandwidth bound.

Memory Budget The Prover's peak memory comprises three components:

Component	Size	Notes
Arena	N * 64 bytes	Required for computation
Merkle tree	2 * N * 32 bytes	Required for root updates
Root chain	(K + 1) * 32 bytes	Sequential; MAY be streamed to disk

The root chain is written sequentially during pass 1 and read sequentially during pass 2. Implementations MAY stream the root chain to persistent storage to reduce peak RAM by K * 32 bytes, at the cost of additional I/O. Peak RAM by profile (with root chain streaming):

Profile	Arena + Merkle	Root chain (disk)	Peak RAM
Standard	128 MiB	128 MiB	~128 MiB
Enhanced	512 MiB	512 MiB	~512 MiB
Maximum	2 GiB	2 GiB	~2 GiB

Parameter Validation Verifiers MUST reject proofs with parameters below these minimums:

Parameter	Minimum	Rationale
N	2^18	Below this, arena is too small for meaningful pointer-chase depth
K	N	Below N, most blocks are never written; TMTO is trivial
K/N (rho)	4	Below this, TMTO penalty < 10x
d	4	Below this, causal fan-out is insufficient
Q	64	Below this, detection probability < 2^{-64}
R	2	Below this, causal verification is shallow

Performance Estimates The following properties are machine-independent:

Property	Standard	Maximum
TMTO penalty (alpha=0)	~256x	~256x
ASIC resistance mechanism	Physics-Bound Floor	Physics-Bound Floor
Proof size	~3.9 MiB	~64 MiB

Reference timings (Apple M-series, DDR5; will vary by hardware):

Profile	Per-step	Wall time	Prover peak RAM
Standard (64 MiB)	~1500 ns	~6 seconds	~128 MiB
Enhanced (256 MiB)	~2200 ns	~37 seconds	~512 MiB
Maximum (1 GiB)	~2750 ns	~185 seconds	~2 GiB (disk)

Verifier time is independent of profile (depends on Q, d, R, N):

Metric	Desktop	Enhanced/Maximum
Desktop	~2 ms	~6 ms
Mobile	20-100 ms	60-300 ms

A reference benchmark with pre-compiled binaries is provided as ancillary material (anc/README.md).

Security Considerations

Work vs. Time PoSME proves sequential memory execution, not elapsed time. An adversary with faster memory (lower latency) completes the same computation in less wall-clock time. The ASIC advantage is bounded (approximately 2x) but nonzero. Applications requiring temporal guarantees MUST combine PoSME with an external time-binding mechanism such as hardware-attested timestamps. Hardware-independent time-binding is impossible: deterministic computation produces identical output regardless of hardware speed, and self-reported timing is forgeable.

Seed Requirements The seed MUST be externally fixed or derived from an unpredictable source. A Prover-controlled seed enables grinding for favorable arena initializations with reduced effective working sets.

Verification Complexity We conjecture that O(1) verification under hash-only assumptions is not achievable for sequential pointer-chasing computations of the type PoSME specifies. The verification complexity in this document is O(Q * d^R * log N). O(log^2 K) verification is believed achievable via FRI/STARK-based commitment (requiring field arithmetic but no trusted setup) and is left as a future optimization. A formal impossibility proof for constant-size hash-only verification of PoSME remains open.

Verifier Resource Limits Verifiers SHOULD implement rate limiting and MUST reject proofs with parameters exceeding configured thresholds before allocating resources for verification.

Open Problems The dynamic pebbling game () provides a framework for TMTO analysis, but a machine-checked proof of the space-time lower bound remains open. The adversary's optimal caching strategy (which blocks to store, when to checkpoint) has not been formally optimized. Block access distribution uniformity under hash-derived addressing requires formal characterization (see Conjecture 1); skewed distributions may enable hot-block caching. Host-as- critical-path mechanisms for ASIC resistance at cache-resident arena sizes (where arena fits within on-die SRAM) are out of scope for this draft. Such mechanisms require the host's computation to gate the next prover step rather than supply ancillary entropy. This is deferred to future work. The tight relationship between committed step frequency C, write density rho, and the optimal adversary strategy requires further analysis.

Implementation Considerations

Bank Mapping and Conflicts The effectiveness of intra-step bank collisions () depends on the accuracy of the force_bank_mapping logic. Memory controllers typically use specific physical address bits for bank selection (e.g., bits 13-16 on many DDR4/DDR5 platforms). Prover implementations SHOULD use platform-specific knowledge or calibration loops to identify these bits. If the exact mapping is unknown, the Prover MAY use a XOR-sum of multiple candidate bit ranges to increase the probability of a physical bank conflict. Verifiers DO NOT check physical mapping accuracy; they only check the logical consistency of the derived addresses according to the protocol parameters.

Timing Counters Provers MUST use the highest-resolution monotonic hardware counter available to capture delta_t.

• x86_64: The RDTSC or RDTSCP instructions.
• AArch64: The CNTPCT_EL0 system register.

The resulting delta_t SHOULD NOT be normalized or filtered. Raw cycle counts are required to preserve the stochastic jitter profile arising from DRAM refresh cycles ($t_{REFW}$) and OS-level noise.

Cache Management To ensure the arena computation is bottlenecked by DRAM latency rather than CPU cache hits, the arena size $N$ SHOULD be configured to exceed the Prover's L3 cache capacity. For Standard and Maximum profiles, the arena sizes (64 MiB to 1 GiB) are specifically chosen to exceed the 16-96 MiB caches typical of commodity processors. Provers MAY use cache-bypass instructions (e.g., MOVNTI on x86) for arena writes to further enforce DRAM-bounded execution.

IANA Considerations This document has no IANA actions.

References Normative References This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. Informative References This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer-oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. JEDEC Solid State Technology Association JEDEC Solid State Technology Association Chia Network Spacemesh Team

Acknowledgements The author thanks the CFRG for foundational work on memory-hard functions. The authors of Argon2 are acknowledged for the design principles that inspired PoSME's custom skip-link initialization.

Changes from -00

• Removed Compact profile pending further analysis of cache-resident-arena security.
• Removed Jitter Entanglement section pending further analysis of host-as-critical-path constructions.
• Restated Theorem 2 (TMTO) conditionally on a stated Address Uniformity Conjecture.
• Tightened ASIC resistance framing to a single physics-bounded latency floor.
• Reconciled §3.2 Related Work against §4.2 arena initialization.
• Editorial cleanup throughout.