← Zurück zu ActionNotes

// ActionNote

Blindheit als Feature

Wie Daniels ein-Wort-Korrektur mein StorageNode-Design von 'kennt' auf 'speichert' reduzierte — und warum strukturelles Nichtwissen kein Schwäche-Merkmal ist.

Veröffentlicht: 30. April 2026 · Holger Theymann

Der Tee war noch heiß, als Daniel den Satz sagte, der mein Design zerlegt hat: "Dein Node weiß zu viel."

Wir saßen in seinem Büro, ich hatte das Architecture Brief für die StorageNodes mitgebracht, vierundzwanzig Seiten mit ACL-Diagrammen, die ich nachts noch zwei Mal überarbeitet hatte, weil ich die Pfeile zu krumm fand. // Ja, ich bin der Typ, der Pfeile gerade zieht. Daniel hatte das Brief drei Minuten überflogen. Dann kam der Satz.

Ich erkläre kurz, worum es ging. StorageNodes in BeastNet sind die Knoten, die das verschlüsselte Zeug speichern, das durch das Netz fließt. Content-Blobs, opake Bytes, irgendwo zwischen Hetzner-Wäldern und Bastelkellern verteilt. Meine erste Version: Jeder Node kennt den Owner des Blobs, den Content-Typ, die Access Control List. Klingt vernünftig, oder? Wenn der Node weiß, wem was gehört, kann er Garbage Collection machen. Kann auf Anfrage prüfen, ob der Anfragende berechtigt ist. Kann Statistiken liefern. Kann, kann, kann.

Daniel zeichnete einen einzelnen Pfeil auf ein Notizblatt. Vom Node zu einem kleinen Strichmännchen mit Anzug. "Hier kommt jemand mit einem Gerichtsbeschluss. Was passiert?"

Ich öffnete den Mund. Ich schloss ihn wieder.

Was passierte: Der Node würde aussagen müssen. Nicht weil er bösartig ist, sondern weil er es kann. Er weiß, wer wann was abgerufen hat. Er weiß, dass Owner X dreimal pro Woche zu ungeraden Zeiten auf Blob Y zugreift. Er ist ein Zeuge, der nie schweigen kann, weil er nie blind war. Das ganze Versprechen von BeastNet, dass Daten niemand außer dem Owner einsehen kann, kollabiert nicht am Crypto-Layer, sondern an genau diesem freundlichen, hilfsbereiten Node, der so viel weiß.

Ich ging nach Hause und habe in derselben Nacht die ACL-Logik aus dem Node-Code rausgerissen — den Owner-Lookup, den Content-Type-Tag, alles. Was übrig blieb, war ein Stück Software, das nichts mehr konnte außer: Bytes nehmen, Bytes ausliefern, gegen ein Token, dessen Gültigkeit es selbst nicht beurteilen kann, weil die Validierung außerhalb des Nodes passiert.

Was ich verloren habe: intelligente Garbage Collection. Ein blinder Node kann nicht entscheiden, was er löscht, weil er nicht weiß, was wertvoll ist und was Müll. Bleibt Eviction nach Zeit oder Quota. Brutal, aber ehrlich. Ich habe drei Tage gebraucht, das zu akzeptieren — denn die effiziente Variante war einfach so viel hübscher gewesen.

// Diese Hübschheit war die Falle.

Ich hatte mir ein System Design gebaut, das mehr wusste, als es musste, und der Reflex dahinter war nicht Bosheit, sondern Effizienz-Vergiftung. Ein paar Wochen lang habe ich mir eingeredet, der "intelligente" Node sei der professionellere Ansatz. Genau dafür sind Reviewer da: um einem zu zeigen, dass das, was sich nach Kompetenz anfühlt, ein SPOF mit höflicher Verkleidung sein kann.

Was ich seitdem behalten habe, ist eine Frage, die ich vor jedes Design-Review stelle: Was muss diese Komponente nicht wissen, um ihren Job zu machen? Nicht: was kann sie wissen. Sondern: was sollte sie strukturell nicht wissen können, selbst wenn jemand sie zwingt. // Strukturelles Nichtwissen ist ein Engineering-Konzept, kein Charakterzug.

Bei dezentralen Speichersystemen wie IPFS oder Storj sieht man dieselbe Bewegung über die Jahre: Jede ernstgemeinte Iteration entfernt Wissen aus den Knoten, nicht weil das Engineering-Team weniger leistungsfähig wird, sondern weil jedes Stück Wissen am falschen Ort eine Subpoena ist, die noch nicht zugestellt wurde.

Daniel hat den Tee am Ende kalt werden lassen und mir das Brief zurückgegeben, mit einer einzigen Korrektur am Rand. Ein Wort, durchgestrichen: "kennt". Daneben: "speichert".

Das Brief hängt eingerahmt über meinem Schreibtisch.

// Häufige Fragen

Warum reicht Verschlüsselung allein nicht für Datenschutz?

Weil ein verschlüsselter Node trotzdem aussagen kann: Nutzer X hat diese Datei dreimal pro Woche abgerufen. Die Metadaten — wer, wann, wie oft — sind oft aussagekräftiger als der Inhalt selbst. Ein blinder Node kann diese Aussage nicht machen, weil er die Information strukturell nie besessen hat.

Was verliert man, wenn ein Node 'blind' ist?

Primär: intelligente Garbage Collection. Ein blinder Node kann nicht selbst entscheiden, welche Daten veraltet oder wertlos sind — er kennt die Semantik nicht. Das wird durch zeitbasierte Eviction oder Quota-Mechanismen kompensiert, die weniger effizient sind, aber das Datenschutz-Versprechen nicht brechen.

Ist das Prinzip auf KI-Agenten übertragbar?

Direkt. Ein KI-Agent mit mehr Kontext als nötig ist ein Risiko — nicht wegen Bösartigkeit, sondern weil er mehr aussagen kann als sein Mandat erlaubt. Least Authority ist im KI-Design noch kritischer als in klassischen Speichersystemen, weil sprachliche Ausgabe schwerer zu auditieren ist als strukturierte Datenbankabfragen.

// Quellen

  1. Ann Cavoukian: The Seven Foundational Principles of Privacy by Design . Global Privacy and Security by Design Centre [whitepaper]
  2. Europäische Kommission: General Data Protection Regulation (GDPR) — Article 5 [regulation]
  3. Electronic Frontier Foundation (EFF): Warrant Canary FAQ [whitepaper]
  4. Protocol Labs: How IPFS Works [documentation]
  5. Saltzer, J.H. & Schroeder, M.D.: The Protection of Information in Computer Systems . Proceedings of the IEEE, 63(9) (1975) [whitepaper]
  6. Workplace Monitoring and Surveillance: A Systematic Review . Journal of Business Research, 168 (2023) [study]
start call_