Was die Tests zeigen, und unter welchen Bedingungen.

Ein Fehler in einer Cell trifft nur diese Cell.

Das ist der Kern des Versprechens. Bis Oktober galt es an drei Stellen nicht vollständig; drei Änderungen, alle am 24.10.2026 übernommen, schliessen diese Lücken.

Prozessor-Ausnahmen

Führt ein Programm einen ungültigen Befehl aus, teilt durch null oder greift auf eine unzulässige Adresse zu, meldet der Prozessor eine Ausnahme. Bisher führte jede solche Ausnahme aus einer Cell zu einer Kernel-Panik; nur Seitenfehler waren abgefangen. Jetzt beendet der Kern nur die betroffene Cell und vermerkt die Art der Ausnahme im Systemprotokoll. Das Gate löst acht Ausnahmen in acht Cells auf zwei Prozessorkernen aus. Danach arbeiten die übrigen Cells weiter, und die Weboberfläche antwortet und zeigt die acht als beendet.

Werte, die eine Cell an den Kern übergibt

Eine Prüfung der Grenze zwischen Cells und Kern hat 14 Schwachstellen gefunden. An den meisten konnte ein falscher Wert, etwa eine Adresse ausserhalb des erlaubten Bereichs, den Kern zum Absturz bringen; an anderen konnte er fremden Speicher verändern oder den freien Speicher aufbrauchen. Jede dieser Stellen prüft den Wert jetzt, bevor sie etwas verändert, und antwortet mit einem bestehenden, benannten Fehlercode. Das Gate schickt 20 absichtlich falsche Aufrufe, einmal mit den Rechten einer gewöhnlichen App und einmal mit Verwaltungsrechten. Jeder bekommt den erwarteten Fehlercode, und der Kern läuft weiter.

Anmeldung

Wird ein Nutzer gelöscht oder bekommt er eine andere Rolle oder ein neues Passwort, enden seine Sitzungen sofort, in der Weboberfläche wie beim Zugang über MCP. Bisher galten sie bis zu 30 Minuten (Weboberfläche) oder bis zu 8 Stunden (MCP-Zugang) weiter. Die Sperre nach Fehlversuchen zählt jetzt je Nutzername und je Absender statt mit einem einzigen Zähler für alle. Wer fünfmal ein falsches Passwort für einen Namen eingibt, sperrt nur diesen Namen. Vorher hätten fünf beliebige Fehlversuche pro Minute alle Nutzer ausgesperrt.

# vorher: ein ungültiger Befehl in einer Cell
[PANIC] panicked at crates/arkane-kernel/src/arch/x86/interrupts.rs:227:1:
[EXCEPTION] #UD INVALID OPCODE (vector 0x06)
# jetzt: dieselbe Cell, derselbe Befehl, der Kern läuft weiter
[fault] ring-3 #UD vector=0x6 rip=0x8000000048 err=0x0 cell=29
# die Verwaltung startet die Cell neu (neue Nummer 0), sie scheitert erneut
[fault] ring-3 #UD vector=0x6 rip=0x8000000048 err=0x0 cell=0
[sched] cell 0 DEAD (fault) code=0x86 (#UD)

Messrahmen. Ausnahmen: drei Läufe unter TCG und zwei unter KVM auf dem Messrechner, alle bestanden; der Gegenlauf ohne die Korrektur, der die Kernel-Panik zeigt, ist nur unter TCG belegt. Abgedeckt sind ungültiger Befehl, Division durch null, vier Arten von Schutzverletzung und der Einzelschritt; weitere Ausnahmearten belegen nur Komponententests ausserhalb der virtuellen Maschine. Fehler im Kern selbst und einige Hardware-Ausnahmen bleiben fatal. Den Grund, warum eine Cell beendet wurde, zeigt bisher nur das Systemprotokoll, nicht die Weboberfläche. Werte an den Kern: ein Lauf unter TCG und der volle Testlauf mit 68 Gates, dazu zwei Läufe unter KVM; drei der 14 Stellen lassen sich mit dem Gate nicht auslösen und sind nur durch Komponententests und Code-Prüfung belegt. Anmeldung: nur unter TCG geprüft. In der Testumgebung kommen alle Verbindungen von derselben Adresse; dass die Sperre Absender wirklich trennt, zeigen nur Komponententests. Ein Angreifer kann einen bekannten Namen gezielt bis zu 15 Minuten sperren.

Ein Modell muss nicht mehr in den Arbeitsspeicher passen.

Das Gate gibt einer Cell ein Budget von 4 GiB Arbeitsspeicher und ein Modell von 6 GiB, und der Lauf geht bis zum Ende durch. Zwei Mechanismen tragen das, beide einzeln geprüft.

Nachladen bei Bedarf

Arkane lädt das Modell nicht vorab. Greift die Cell auf einen Teil zu, der noch nicht im Speicher liegt, meldet der Prozessor einen Seitenfehler. Der Kern liest dann das umliegende Stück von 2 MiB von der Platte, prüft es gegen seine Prüfsumme und blendet es erst danach nur lesend ein. Ein Stück, das nicht zu seiner Prüfsumme passt, wird nie eingeblendet: Das Gate verändert eines auf der Platte, das Nachladen wird verweigert, die Cell endet, das übrige System läuft weiter.

Auslagern

Jede Cell hat ein Speicherbudget. Ist es voll, gehen die ältesten Stücke zuerst. Bevor ihr Speicher frei wird, löscht der Kern die zwischengespeicherten Adressübersetzungen auf allen Prozessorkernen, damit kein Kern noch auf zurückgegebenen Speicher zeigt. Das Gate prüft den Höchststand, nicht die Absicht: Das Budget wurde genau erreicht und nie überschritten. Unter Speicherdruck lagert Arkane inzwischen vorausschauend aus, statt auf den nächsten Seitenfehler zu warten; das hat die übersprungenen Vorausladungen von 1089 auf 8 gesenkt.

Protokollausgabe

Dass ein Durchlauf länger dauerte als das Nachladen selbst, lag an der Protokollausgabe. Der Kern schreibt zu jedem Nachladen und Auslagern eine Zeile auf die emulierte serielle Schnittstelle, und unter KVM kostet jeder Zugriff darauf einen Wechsel in den Emulator, bisher zwei pro Zeichen. Heute füllt der Kern den Puffer der Schnittstelle in einem Zug: rund ein Zugriff pro Zeichen. Derselbe Durchlauf mit denselben 1390 Auslagerungen dauert damit 31.8 statt 51 Sekunden.

Ablageformat

Darunter beschreibt das Ablageformat einen Block als wenige zusammenhängende Bereiche statt als Liste einzelner Speicherseiten: ein Block von 512 MiB braucht 64 Byte Verwaltung statt 1 MiB. Längen stehen in 48 Bit, das Format adressiert damit 256 TiB je Block. Ablagen im älteren Format bleiben byte-genau lesbar.

Messrahmen. Ein Rechner, KVM, AMD Ryzen 7 5700G. Der Durchlauf vom 13.10. belegt die Hardware-Virtualisierung aus der echten QEMU-Befehlszeile; der Kern ist im Gate wie immer im dev-Profil gebaut, und die Zahlen sind ein Lauf gegen einen Lauf, kein Mittelwert. «Läuft durch» belegt die Kapazität, nicht die Geschwindigkeit: Ein Modell, das von der Platte nachlädt, ist langsamer als eines, das in den Speicher passt, und wie schnell es dann Text erzeugt, ist nicht gemessen. 256 TiB ist, was das Format adressiert; das grösste geprüfte Modell hat 6 GiB. Auch nach der Verbesserung kostet jedes ausgegebene Zeichen noch einen Wechsel in den Emulator; allein die Protokollzeilen zum Nachladen brauchen 19.9 der 31.8 Sekunden. Ein Protokollkanal ohne diesen Umweg ist geplant, nicht gebaut.

Eine Datenbank als Cell, gemessen gegen SQLite.

ArkDB ist mit dem Bausatz für eigene Apps gebaut und läuft wie jede App als Cell. Gemessen wird sie gegen SQLite in einem Linux-Gast auf demselben Rechner, unter KVM, mit Release-Builds auf beiden Seiten. Eine Testreihe vergleicht vorher jedes Ergebnis mit dem von echtem SQLite; erst wenn beide dasselbe liefern, ist ein Geschwindigkeitsvergleich sinnvoll.

Zu Beginn der Arbeit brauchte ArkDB für das Lesen eines einzelnen Eintrags 1624-mal so lange wie SQLite. Heute liest ArkDB einen einzelnen Eintrag in 0.79 der Zeit von SQLite. Suchen mit Bedingung, Sortierung und Limit dauern 1.63-mal so lange wie bei SQLite, vorher 3.55-mal. Der Weg dahin war Zerlegen, nicht Raten: weniger Systemaufrufe je Lesevorgang, Seiten-Cache in der Cell, geprüfte Seiten geteilt statt kopiert. Verbesserungen, die sich nicht messen liessen, wurden zurückgenommen.

Jeder Abschluss ist im Standard gesichert: Der Einstiegspunkt der Daten wird auf die Platte geschrieben und gespült, bevor die Antwort hinausgeht. Ein einzelnes Schreiben kostet so 25.4-mal so viel wie bei SQLite. Wer auf das Spülen bewusst verzichtet (PRAGMA synchronous = NORMAL), zahlt 2.61-mal so viel. Anweisungen innerhalb einer Transaktion kosten 0.096 eines Einzel-Schreibvorgangs; SQLite fasst stärker zusammen (0.042), je Anweisung in einer Transaktion liegt ArkDB damit beim 57.9-fachen.

Messrahmen. Der Vergleich beim Schreiben ist ungleich, und das steht hier: SQLite läuft im Gast ohne Plattenkosten, sein Spülen trifft keine Platte. ArkDB spült im Standard bei jedem Abschluss eine echte Platte. «Gesichert» heisst heute: Der Einstiegspunkt ist fest auf der Platte, die Inhalte folgen danach. Inhalte vor der Antwort vollständig zu sichern, ist geplant, nicht gebaut. Scheitert das Schreiben auf die Platte, meldet der Kern das heute nicht zuverlässig zurück; die Korrektur ist in Arbeit. Suchen bleiben langsamer, weil ArkDB dafür mehrere Stellen im Baum ansteuern muss, SQLite ein zusammenhängendes Blatt liest. Ein Lauf im dev-Profil ergab 0.92 beim Suchen und 0.74 beim Lesen; dev- und Release-Zahlen werden nicht gemischt, oben steht der Release-Lauf.

Leser warten nicht auf den Schreiber.

Die Datenbank für KI-Agenten lässt Leser auf einem festen Abbild arbeiten: einer gleichbleibenden, nur lesbaren Sicht, die in die lesende Cell eingeblendet wird, während der Schreiber schon den nächsten Stand erzeugt. Das Gate lässt drei Leser auf getrennten Prozessorkernen gegen einen Schreiber laufen, der nie anhält. Jeder Leser schafft rund 105 000 Lesevorgänge pro Sekunde.

Welcher Stand gilt, ist keine Vertrauensfrage: Der Stand der Datenbank wird in die Protokollkette geschrieben, und arkctl db pin und arkctl db diff weisen ihn offline nach, allein von der Platte. Seit Oktober geht das auch aus einer App heraus mit einem einzigen Aufruf.

Messrahmen. Unter KVM. Drei Leser sind das Geprüfte, keine gefundene Obergrenze. Dieselbe Messung hat einen Entwurf verworfen: Ein neues Abbild je Abschluss kostet ein Vielfaches einer gewöhnlichen Lesenachricht, deshalb werden Lese-Kopien nicht so gebaut. Leser auf fremden Prozessorkernen erreichen die Datenbank nur über das eingeblendete Abbild, nicht über Nachrichten.

Eine KI betreibt das System, mit denselben Regeln wie ein Mensch.

Die Verwaltungs-Cell gw-admin bietet 13 Werkzeuge über MCP an, auf POST /mcp an Port 9443, hinter Anmeldung, Rollen und Protokoll. Als Zugangsschlüssel dient das Token aus der Anmeldung. Die Rollen sind streng: Wer nur lesen darf, sieht 7 Werkzeuge, wer betreibt oder verwaltet, alle 13.

deploy_diff nennt die geplanten Änderungen; deploy_apply verlangt sie als expect_ops zurück und bricht ab, wenn sich der Zustand inzwischen geändert hat. So handelt kein Agent auf einer veralteten Annahme. Für Stoppen, Starten und Neustarten gelten dieselben Schutzregeln wie in der Weboberfläche; die Verwaltungs-Cell kann sich nicht selbst stoppen, das verweigert der Kern. Jede Änderung steht im Protokoll, bevor sie wirkt.

Ein Schalter in der Weboberfläche schaltet den Zugang ab. Er ist im Standard an, übersteht einen Absturz und einen Neustart, und ausgeschaltet antwortet jeder Aufruf mit 403 ARK_MCP_DISABLED.

Messrahmen. Vier Gates, grün unter KVM und TCG. Die Vorführung (make mcp-ops-demo) lässt eine KI eine Cell einrichten und ihre Protokolle lesen, ohne Weboberfläche und ohne Menschen. Zwei Vertrauensstufen bleiben getrennt: gw-mcp bietet die Werkzeuge der Apps an, gw-admin die Verwaltung. Offen: Ein vor dem Abschalten ausgestelltes Token gilt nach dem Wiedereinschalten weiter, und sehr langsame Gegenstellen können die Verwaltung heute noch aufhalten.

Ein erster Datenpunkt, auf demselben Rechner gemessen.

Der erste Start unter KVM war zugleich die erste Messung, die etwas über Geschwindigkeit sagt. Arkane und Linux liefen auf derselben Maschine, gemessen mit demselben Zähler im selben Lauf. Ein einfacher Systemaufruf brauchte bei Arkane im Median 224 Taktzyklen, bei Linux (getpid) 1393. Eine Nachricht hin und zurück war mit 36 850 gegen 40 864 Zyklen rund 10 % schneller als über einen Linux-Socket (AF_UNIX).

Die Messung hat uns auch korrigiert. Unter TCG war derselbe Nachrichtenweg 3.5-mal langsamer als bei Linux, ein Fehler der Emulation. Beim Ausliefern von Antworten ging der grösste Teil der ersten Wartezeit auf unsere eigene Protokollausgabe; ohne sie liegt Arkane beim 0.98- bis 1.34-fachen von Linux.

Messrahmen. Ein Rechner, dev-Profil, zwei Läufe, Version 0.24: ein erster Datenpunkt, keine Testreihe. Für andere Hardware oder Release-Builds folgt daraus nichts. Der erste Start unter KVM fand drei Fehler im Kern, die unter TCG nicht aufgefallen waren, obwohl alle Gates grün waren.

Eine Dienstgruppe wird neu gestartet, die Anfragen laufen weiter.

Läuft ein Dienst in mehreren Kopien, startet arkctl cell rollout sie nacheinander neu und wartet jeweils, bis die neue Kopie bereit ist; die Gruppe fällt nie auf null. Das Gate schickt dabei ohne Pause Anfragen und startet die Gruppe dreimal hintereinander neu. 802 Anfragen, keine einzige fehlgeschlagen.

Stirbt eine Cell, die über ein Manifest eingerichtet wurde, startet die Verwaltungs-Cell sie aus ihrem signierten Abbild neu. Die Verwaltungs-Cell selbst, die Ablage und die Schlüsselverwaltung überwacht eine kleine eigene Cell und startet sie nach ihrem signierten Startrezept neu; die Schlüsselverwaltung kommt dabei gesperrt zurück, bis jemand sie wieder entsperrt.

Messrahmen. Neustart unter Last: TCG, Version 0.23. Das Gate sucht die Marker für Beginn, Schritt, Bereit und Ende im Systemprotokoll und darf nie einen Abbruch sehen. Start bis zum fertig eingerichteten System ohne Eingriff: 7.4 Sekunden unter TCG. Ausfallsicherheit heisst heute: Kopien auf demselben Rechner. Die Zugangs-Cells für öffentliche Anfragen und für App-Werkzeuge werden nach einem Absturz nicht neu gestartet; ihr Port bleibt bis zum nächsten Neustart des Systems weg.

Fälschungen fallen auf, Daten liegen verschlüsselt auf der Platte.

Jedes sicherheitsrelevante Ereignis, vom Start einer Cell über einen Absturz bis zu jeder Änderung über die Weboberfläche oder MCP, wird ein Block in einer Kette, in der jeder Block die Prüfsumme seines Vorgängers trägt. Die Kette wird auf die Platte gespiegelt und lässt sich ohne laufendes System prüfen: Ein verändertes Byte meldet arkctl audit verify mit der Nummer des betroffenen Blocks.

Daten von Apps werden verschlüsselt, bevor sie auf die Platte gehen (XChaCha20-Poly1305). Der Schlüssel liegt nur im Arbeitsspeicher einer Cell, die keinen Netzzugang hat. Nach einem vollen Schreib-Durchlauf findet strings auf der Platte keinen Klartext.

$ arkctl audit verify --store store.img --list
audit chain OK: 23 blocks, head seq=22 hash=6b01c4…
# ein Byte auf der Platte verändert
$ arkctl audit verify --store store.img
audit verify FAILED: TAMPER: block seq=4 does not
hash to its stored id (content was modified)
$ strings store.img | grep -c "secret note body"
0

Messrahmen. Die Kette weist Veränderungen und Lücken nach ihrem letzten geprüften Ankerpunkt nach. Wer den Kern vor dem ersten Ankerpunkt kontrolliert, kann die Geschichte bis dahin umschreiben; Ankerpunkte ausserhalb des Systems sind geplant. «Auf der Platte» heisst: Im Arbeitsspeicher liegen die Daten unverschlüsselt, solange das System läuft. Die Protokollkette selbst ist absichtlich nicht verschlüsselt.

Wie gemessen wurde, und was daraus nicht folgt.

• Rechner

  Ein Desktop-PC mit AMD Ryzen 7 5700G unter KVM. Kein Labor, kein Verbund mehrerer Rechner. Reine TCG-Läufe laufen zusätzlich auf einer weiteren virtuellen Maschine (AMD EPYC).

• TCG und KVM

  TCG belegt Verhalten, nie Geschwindigkeit. Es hat uns zweimal getäuscht: beim Nachrichtenweg (scheinbar 3.5-mal langsamer) und bei den Prüfsummen im dev-Profil. Zahlen zur Geschwindigkeit stammen nur aus KVM.

• Profile

  Zahlen aus dem dev- und dem Release-Build werden nie gemischt. ArkDB: Release-Build beidseitig. Systemaufruf und Nachrichtenweg: dev-Profil, zwei Läufe, als erster Datenpunkt gekennzeichnet.

• Gates

  Jedes Gate startet das echte Abbild, spielt die Funktion durch und sucht die Marker im Systemprotokoll. Neue Gates zeigen heute zuerst ohne die Änderung, dass sie scheitern, und erst danach mit ihr, dass sie bestehen. Muss ein Gate wiederholt werden, wird das als Befund festgehalten.

• Rücknahmen

  Verbesserungen ohne messbare Wirkung werden zurückgenommen, nicht als Verbesserung ausgeliefert.

• Nicht gemessen

  Wie schnell ein Modell Text erzeugt, wenn es von der Platte nachlädt. Die höchste Last beim Ausliefern. Mehr als drei Leser auf der Agenten-Datenbank. Betrieb direkt auf der Hardware.