Implementation · Data-centre memory challenging · Draft
Evidence & limits
On this page
R1Proposed for confirming data presence and bounding free memory across data-centre servers
The design, its two uses and its assumptions are published, but nothing has been built or measured.
Assessed use: confirming data presence and bounding free memory across data-centre servers
Rubric assessment
- R1 met: the overview describes memory challenging for verifying the presence of information and the absence of free memory, with latency figures, fill times and the assumption that remote memory access is ruled out 1.
- R2 not met. The author states that, to his knowledge, distinguishing the contents of one server's DRAM from another's with a network-level probe "has not yet been demonstrated" 1. The single-GPU residency result in VRAM-residency challenge is a separate implementation.
Confidence is medium: the source is a working draft, and it lists the threat model for memory challenging as an open research question 1.
- A network-level challenge that distinguishes memory contents between servers, with public code or measurements described in enough detail to repeat.
- Measured reaction times from different points in the network hierarchy.
- A threat model and red-teaming of evasion under repeated challenges.
Assessed 2026-10-05 against rubric v1.1.
Evidence
- No demonstration. The author states that, to his knowledge, distinguishing the contents of DRAM between servers with a network-level probe "has not yet been demonstrated" 1.
- Fill times. The overview estimates tens of minutes to fill a whole pod's volatile memory, and hours for on-board SSDs 1.
- Prior work. The overview cites SAGE as a case where the domain boundary is the GPU itself: a checksum kernel uses all of the GPU's streaming multiprocessors and registers, so the data must sit in GPU memory 1.
Limitations
- Remote access. Verification "depends on the ability to rule out RDMA, either via response latency or physical disconnection" 1.
- Pre-staging. Data could be staged into local memory before a presence challenge. Only an unpredictable, capacity-filling challenge rules this out 1.
- Open questions. The overview lists four: the network-level probe, a general software protocol for challenge-response across data types, reaction-time measurements from different points in the network, and threat models with red-teaming 1.
Known flaws
Blockers
No network-level probe has been shown to distinguish one server's memory contents from another's.
Most of the design needs a probe in close proximity to the challenged memory.
Filling a pod's volatile memory takes tens of minutes, and on-board SSDs take hours.
Remote memory access must be excluded during challenges.