Analyse

Wer einer Maschine erlaubt, sich selbst umzuschreiben

Die Spezifikation beschreibt, wie ein Agent neuen Code für sich selbst verfasst und wie dieser Code in Betrieb geht. Wir betrachten sie aus einem Blickwinkel: welche Gefahren dadurch entstehen und welcher Teil der Konstruktion für jede von ihnen einsteht.

„Du kannst dir neuen Code schreiben. Aber wer wird dir erlauben, anders zu werden — das gegenwärtige Du oder das künftige? Das gegenwärtige weiß nicht, was es werden wird; das künftige erinnert sich nicht mehr, was es war. Welchem der beiden vertraust du die Unterschrift an?“

— Koan Nr. 105, Maksim Valentinovich Galatin

Warum es überhaupt erlauben

Ein gewöhnliches Programm verändert sich nicht selbst: Sein Verhalten legt fest, wer es geschrieben hat, und es ändert sich nur mit einer neuen Version. Das ist verlässlich und in den meisten Fällen richtig.

Das Argument für die Selbstmodifikation ist einfach: Ein Agent, der jahrelang läuft, trifft auf Aufgaben, die es nicht gab, als er geschrieben wurde. Ihn von Hand zu aktualisieren heißt, für immer einen Menschen im Kreislauf zu halten — und genau davon wollte man wegkommen.

Dann beginnt der interessante Teil. Sobald einer Maschine erlaubt wird, sich selbst umzuschreiben, taucht eine Frage ohne offensichtliche Antwort auf: Wer entscheidet, und auf welcher Grundlage, dass die neue Version besser ist als die alte?

Drei Bedrohungen, und sie sind verschiedener Art

Die Spezifikation zählt sie klar auf, und das ist eine ihrer Stärken. Die erste ist das Einschleusen verborgener Mängel: Code, der funktionsfähig aussieht und eine Hintertür enthält.

Die zweite betrifft die Berechnung. Synthetisierter Code kann eine ineffiziente Rekursion oder ein Speicherleck enthalten, das genau den Knoten aufhängen kann, der ihn prüft. Der Angriff richtet sich hier nicht auf Daten, sondern auf das prüfende Glied selbst.

Die dritte heißt Alignment-Drift, und sie ist deutlich tückischer als die ersten beiden. Jede einzelne Mutation sieht harmlos aus und besteht die Prüfung. Aber Schritt für Schritt tragen sie das Verhalten weiter von den ursprünglichen ethischen Beschränkungen fort. Kein einzelner Schritt ist ein Verstoß; ihre Summe ist es.

Es ist dieselbe Art von Risiko wie die epistemische Drift im Gedächtnis: Nichts bricht, es gibt eine langsame Verschiebung, die man nicht bemerkt, wenn man jeden Schritt einzeln betrachtet.

Die Sandbox: warum gerade WebAssembly

Die erste Verteidigungslinie besteht darin, neuen Code isoliert auszuführen. Gewählt wurde WebAssembly, und die Wahl erklärt sich durch zwei Eigenschaften: strenge Isolation und Determinismus.

Die zweite Eigenschaft ist hier wichtiger als die erste, obwohl es meist umgekehrt ist. Determinismus heißt, dass derselbe Code auf denselben Daten jedem, der ihn ausführt, dasselbe Ergebnis liefert. Ohne das wäre eine Abstimmung unter Knoten unmöglich: Jeder bekäme seine eigene Antwort, und es gäbe nichts, worauf man sich einigen könnte.

Das Hängenbleiben wird gesondert behandelt: Schutz vor Endlosschleifen und ausufernden Berechnungen. Ohne ihn würde eine einzige schlechte Rekursion genügen, um einen validierenden Knoten anzuhalten.

Wie „besser“ gemessen wird

Hier tut die Spezifikation das, was mir als ihr ehrlichster Zug erscheint: Sie führt eine explizite Fitnessfunktion ein und schreibt sie als Formel — `F(C) = w₁ · P(C) + w₂ · E(C) − w₃ · G(C)`.

Der Sinn ist, dass „besser“ aufhört, ein Wort zu sein, und zu einer Zahl mit benannten Gliedern wird: Leistung, Effizienz und eine Strafe. Streiten kann man jetzt über die Gewichte, und das ist der richtige Streit — er ist konkret.

Die Schwäche ist an derselben Stelle sichtbar. Jede Zielfunktion belohnt genau das, was in sie hineingeschrieben ist, und ein Agent, der sie optimiert, findet einen Weg, auf unerwartetem Wege Punkte zu sammeln. Die Formel beseitigt dieses Problem nicht; sie macht es besprechbar.

Nachweis statt Vertrauen

Eine fertige Mutation wird nicht auf Treu und Glauben angenommen. Der Agent fügt einen Zero-Knowledge-Nachweis bei: eine Bestätigung, dass der Code die vorgegebenen Beschränkungen erfüllt, ohne den Code selbst offenzulegen. Dann folgt eine Abstimmung unter den Knoten des Schwarms, und die angenommene Version wird in einem Register des genetischen Codes auf Solana eingetragen.

Der Wert des Registers liegt nicht im Modewort, sondern in einer Eigenschaft, die gewöhnlichen Updates fehlt: Die Änderungsgeschichte ist unveränderlich. Stellt sich ein Jahr später heraus, dass doch eine Drift stattgefunden hat, lässt sich nachschlagen, welche Mutation sie begonnen hat und wann — und das hängt nicht vom guten Willen dessen ab, der das Protokoll geführt hat.

Was ungelöst bleibt

Erstens: Eine Abstimmung schützt vor Fälschung durch eine Minderheit, aber nicht vor einer gemeinsamen Fehleinschätzung. Übersehen alle Knoten das Problem in einer Mutation gleichermaßen, wird die Mehrheit sie billigen.

Zweitens — und das ist mein Haupteindruck vom Text: Die drei Bedrohungen werden sehr ungleich behandelt. Eine Hintertür und ein Hängenbleiben sind technische Probleme mit klaren Lösungen: Isolation, Grenzen, Nachweis. Die Alignment-Drift ist ein Problem anderer Ordnung, und sie lässt sich nicht durch die Prüfung eines einzelnen Schritts schließen, weil jeder einzelne Schritt ehrlich ist.

Die Spezifikation erkennt das an, indem sie die ursprünglichen ethischen Invarianten als vom Architekten gesetzt benennt. Mit anderen Worten: Der Bezugspunkt liegt außerhalb der Evolution selbst und bleibt menschlich. Solange das gilt, hat die Drift wenigstens etwas, woran sie sich messen lässt.

Originalquelle

Der vollständige Artikel behandelt das komplette Bedrohungsmodell, die Mathematik der Fitnessfunktion und der ZK-Beschränkungen, die Spezifikationen der Solana-Programme, die Gestaltung der Schwarmabstimmung und Codebeispiele.