Die Protokolländerungen dieser Woche enthalten Entscheidungen ohne Rückweg

Victoria Shinder27 September 2026, 19:512 Min. Lesezeit

Die meisten Einstellungen in Software lassen sich später ändern. Drei Meldungen dieser Woche sind wegen derer bemerkenswert, bei denen das nicht geht - und wegen der Art, wie das jeweilige Projekt damit umgeht.

Ein Flag, das ein Geschäftsmodell festlegt. Auf dem XRP Ledger kann ein Emittent von Multi-Purpose-Token, der nach XLS-96 vertrauliche Guthaben einschaltet, nie eine native prozentuale Transfergebühr erheben, und das Flag lässt sich nicht löschen. Wer bereits eine Gebühr erhebt, kann Vertraulichkeit nur durch Neuemission einführen. Eine am 22. September eröffnete Diskussion weist darauf hin, dass der Zielkonflikt nur in den Detailabschnitten der Spezifikation steht, und bittet um einen klaren FAQ-Eintrag.

Eine Einstellung, die beim Anlegen feststeht. Erigon 3.7 speichert in neuen Datenverzeichnissen Belege standardmäßig, was Log-Abfragen beschleunigt und Speicherplatz kostet. Die Einstellung bei einem bestehenden Verzeichnis zu ändern, erfordert ein neues; die Entscheidung gehört also zum Aufsetzen. Die Release-Notizen sagen das im Abschnitt über inkompatible Änderungen.

Eine Regel, die im Zweifel sperrt. Ein Bitcoin-Entwurf zur Einteilung, welche Outputs ihren öffentlichen Schlüssel preisgeben, löst Unsicherheit in eine Richtung auf: Wo die Daten zwei Stufen nicht unterscheiden, gilt die stärker gefährdete. Das ist keine Unumkehrbarkeit im selben Sinn, aber eine bewusste Wahl, welchen Fehler man bei fehlender Information macht.

Das Muster

Unumkehrbare Entscheidungen sind manchmal unvermeidlich. Eine Datenschutzgarantie, die sich abschalten ließe, wäre kaum eine, und Speicherformate zu migrieren ist teuer. Unterschiedlich ist, wie sichtbar die Kosten dargestellt werden. Erigon setzt seine Grenze dorthin, wo Betreiber vor einem Update nachsehen. Der Bitcoin-Entwurf nennt seine Sperrregel als Erstes. Der XRPL-Fall zeigt, was passiert, wenn eine endgültige Folge richtig ist, aber in einem Abschnitt steht, den die meisten Emittenten vor dem Handeln nicht lesen.

Eine Checkliste, die daraus folgt

Wer solche Funktionen entwirft oder übernimmt: jede Einstellung auflisten, die sich nicht zurücknehmen lässt, das neben dem Schalter sagen statt nur in der Spezifikation, und als Voreinstellung die Wahl setzen, die die meisten Nutzer nicht bereuen würden. Wer einen solchen Schalter umlegt: den Abschnitt "Einschränkungen" oder "inkompatible Änderungen" vorher lesen, nicht danach.