{
  "schema_version": "1.4.0",
  "rubric_version": "1.1",
  "license": "CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)",
  "record": {
    "id": "I-0020",
    "slug": "data-centre-memory-challenging",
    "title": "Data-centre memory challenging",
    "aliases": [
      "Memory challenging",
      "Memory-saturation challenges",
      "Response-time domains"
    ],
    "status": "draft",
    "last_reviewed": "2026-10-05",
    "review_interval_days": 90,
    "steward": null,
    "provenance": {
      "drafted_by": "ai",
      "reviewed_by": []
    },
    "risk_flags": [],
    "flags": [
      "provider-reported"
    ],
    "one_liner": "A proposed design that times answers from a data centre's memory, to confirm that declared data is present or that no free memory remains.",
    "summary": "Data-centre memory challenging is a design in Naci Cankaya's low-trust verification overview, published by the Machine Intelligence Research Institute. A probe near the memory sends challenges and times the answers. The design has two uses. One confirms that information is present where the prover says it is. The other confirms that no free memory or storage remains, by first filling capacity with incompressible noise and then sampling it at random. Response time is the main evidence, because each tier of memory answers at a different speed. The author treats the design as an optional addition to network taps. It has not been built. The author knows of no demonstration that a network-level probe can tell one server's memory from another's. Fast remote memory access must be ruled out by latency or by physical disconnection, and filling a pod's memory takes tens of minutes.",
    "category": "cryptographic-computational",
    "secondary_categories": [
      "off-chip-devices"
    ],
    "verifies": [
      {
        "claim": "C-0004",
        "role": "primary",
        "note": "A capacity-filling challenge bounds the free memory a hidden workload would need (S-0018)."
      }
    ],
    "threat_model": "adversarial",
    "adversarial_evaluation": "analysis",
    "hardware_requirement": "retrofit-device",
    "prover_cooperation": "required",
    "confidentiality": "preserving",
    "depends_on": [
      {
        "target": "M-0014",
        "note": "Remote memory access must be ruled out, by latency or by physical disconnection."
      }
    ],
    "readiness": {
      "assessment": true,
      "level": "R1",
      "scope": "confirming data presence and bounding free memory across data-centre servers",
      "rubric_version": "1.1",
      "rationale": "The design, its two uses and its assumptions are published, but nothing has been built or measured.\n\n- **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 [[S-0018]].\n- **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\" [[S-0018]]. The single-GPU residency result in [[I-0019]] is a separate implementation.\n\nConfidence is medium: the source is a working draft, and it lists the threat model for memory challenging as an open research question [[S-0018]].",
      "evidence": [
        "S-0018"
      ],
      "next_level_gaps": [
        "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."
      ],
      "confidence": "medium",
      "assessed_by": [
        "ai-draft"
      ],
      "assessed_on": "2026-10-05",
      "status": "current",
      "dispute": null
    },
    "flaws": [
      {
        "assessment": true,
        "title": "Remote memory narrows the timing margin",
        "kind": "theoretical-argument",
        "severity": "significant",
        "status": "open",
        "description": "A remote memory access round trip takes about 1–2 µs over InfiniBand or RoCE, against about 70–200 ns for a local DRAM read. The overview says verification of memory saturation depends on ruling out remote access, by response latency or by physical disconnection.",
        "sources": [
          "S-0018"
        ],
        "response": null
      },
      {
        "assessment": true,
        "title": "Presence does not show absence",
        "kind": "theoretical-argument",
        "severity": "significant",
        "status": "open",
        "description": "A check that data is present does not show that nothing else is stored. The overview notes that data could be staged into local memory before a challenge, which only an unpredictable, capacity-filling challenge rules out.",
        "sources": [
          "S-0018"
        ],
        "response": null
      }
    ],
    "blockers": [
      {
        "text": "No network-level probe has been shown to distinguish one server's memory contents from another's.",
        "theme": "adversarial-validation",
        "blocked_by": null,
        "sources": [
          "S-0018"
        ]
      },
      {
        "text": "Most of the design needs a probe in close proximity to the challenged memory.",
        "theme": "access-governance",
        "blocked_by": null,
        "sources": [
          "S-0018"
        ]
      },
      {
        "text": "Filling a pod's volatile memory takes tens of minutes, and on-board SSDs take hours.",
        "theme": "performance-compatibility",
        "blocked_by": null,
        "sources": [
          "S-0018"
        ]
      },
      {
        "text": "Remote memory access must be excluded during challenges.",
        "theme": "coverage-hidden-compute",
        "blocked_by": "M-0014",
        "sources": [
          "S-0018"
        ]
      }
    ],
    "challenge_themes": [
      "capacity-bounds",
      "coverage-hidden-compute",
      "adversarial-validation",
      "performance-compatibility",
      "access-governance"
    ],
    "organizations": [
      "O-0202"
    ],
    "people": [],
    "sources": [
      {
        "source": "S-0018",
        "supports": "the two uses; response-time domains; latency figures; probe placement; fill times; remote-access caveat; pre-staging; open research questions; optional status",
        "locator": "§5.1.2"
      }
    ],
    "concepts": [
      "K-0001",
      "K-0002",
      "K-0012",
      "K-0016",
      "K-0018",
      "K-0020"
    ],
    "kind": "proposed-architecture",
    "developer": [
      "O-0202"
    ],
    "realises": [
      "M-0016"
    ],
    "homepage": "https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf",
    "type": "implementation",
    "url": "https://trustbutveri.fyi/implementations/data-centre-memory-challenging/",
    "source_file": "content/implementations/data-centre-memory-challenging.md",
    "flags_all": [
      "provider-reported"
    ],
    "body_markdown": "## What it is\n\nData-centre memory challenging is a design in Naci Cankaya's system overview for low-trust AI compute verification, a working draft from the Machine Intelligence Research Institute's Technical Governance Team [[S-0018]]. It applies [[M-0016|timed challenge-response]] to the memory and storage of AI servers. The author considers it \"an optional evidence collection mechanism in addition to network taps\" [[S-0018]]. The whole system is covered in [[I-0012]].\n\n## How it works\n\nThe design has two uses: \"A) verifying presence of information B) verifying the absence of free memory/storage\" [[S-0018]].\n\n- **Presence.** The verifier challenges the prover about data that the prover claims to hold. Response time is the main evidence, because an answer fetched from another device arrives measurably later [[S-0018]].\n- **Absence.** Incompressible noise is loaded into the device until its capacity is full, and random samples are then challenged [[S-0018]].\n\nThe overview groups memory into response-time domains. A domain is \"any set of locations whose mutual latency differences fall below the measurement resolution at the location of the pinging device\" [[S-0018]].\n\nThe latency figures it gives set the margins [[S-0018]]:\n\n- A local DRAM read takes about 70–200 ns.\n- A fast data-centre SSD has an average read latency of a few microseconds.\n- A remote memory access round trip over InfiniBand or RoCE takes about 1–2 µs.\n\nThe author notes that most of these mechanisms need a probe close to the challenged memory [[S-0018]]. He expects that one probe per NVLink scale-up system would cost far less than the hardware it monitors [[S-0018]].\n\n## Evidence\n\n- **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\" [[S-0018]].\n- **Fill times.** The overview estimates tens of minutes to fill a whole pod's volatile memory, and hours for on-board SSDs [[S-0018]].\n- **Prior work.** The overview cites [[I-0021|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 [[S-0018]].\n\n## Limitations\n\n- **Remote access.** Verification \"depends on the ability to rule out RDMA, either via response latency or physical disconnection\" [[S-0018]].\n- **Pre-staging.** Data could be staged into local memory before a presence challenge. Only an unpredictable, capacity-filling challenge rules this out [[S-0018]].\n- **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 [[S-0018]].",
    "body_text": "What it is Data-centre memory challenging is a design in Naci Cankaya's system overview for low-trust AI compute verification, a working draft from the Machine Intelligence Research Institute's Technical Governance Team [S-0018]. It applies timed challenge-response to the memory and storage of AI servers. The author considers it \"an optional evidence collection mechanism in addition to network taps\" [S-0018]. The whole system is covered in Low-trust AI compute verification system overview. How it works The design has two uses: \"A) verifying presence of information B) verifying the absence of free memory/storage\" [S-0018]. - Presence. The verifier challenges the prover about data that the prover claims to hold. Response time is the main evidence, because an answer fetched from another device arrives measurably later [S-0018]. - Absence. Incompressible noise is loaded into the device until its capacity is full, and random samples are then challenged [S-0018]. The overview groups memory into response-time domains. A domain is \"any set of locations whose mutual latency differences fall below the measurement resolution at the location of the pinging device\" [S-0018]. The latency figures it gives set the margins [S-0018]: - A local DRAM read takes about 70–200 ns. - A fast data-centre SSD has an average read latency of a few microseconds. - A remote memory access round trip over InfiniBand or RoCE takes about 1–2 µs. The author notes that most of these mechanisms need a probe close to the challenged memory [S-0018]. He expects that one probe per NVLink scale-up system would cost far less than the hardware it monitors [S-0018]. 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\" [S-0018]. - Fill times. The overview estimates tens of minutes to fill a whole pod's volatile memory, and hours for on-board SSDs [S-0018]. - 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 [S-0018]. Limitations - Remote access. Verification \"depends on the ability to rule out RDMA, either via response latency or physical disconnection\" [S-0018]. - Pre-staging. Data could be staged into local memory before a presence challenge. Only an unpredictable, capacity-filling challenge rules this out [S-0018]. - 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 [S-0018].",
    "referenced_by": [
      {
        "id": "M-0016",
        "title": "Timed challenge-response and memory-occupation challenges",
        "url": "https://trustbutveri.fyi/mechanisms/timed-challenge-response/"
      },
      {
        "id": "I-0012",
        "title": "Low-trust AI compute verification system overview",
        "url": "https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/"
      },
      {
        "id": "I-0019",
        "title": "VRAM-residency challenge",
        "url": "https://trustbutveri.fyi/implementations/vram-residency-challenge/"
      }
    ]
  }
}