Menschen landen im Allgemeinen in einem von zwei Lagern, wenn es darum geht, wie stark sich ein Protokoll tatsächlich ändern kann, nachdem es live ist. Entweder sie gehen davon aus, dass es im Grunde unveränderlich ist, dass Code das Gesetz ist und was einmal bereitgestellt wurde, für immer bereitgestellt bleibt – oder sie nehmen das Gegenteil an, dass irgendwo ein Team Admin-Keys hat und Dinge still und heimlich ändern kann, wann immer es will. Keine dieser Annahmen wird normalerweise groß hinterfragt; man entscheidet sich einfach für eine und macht weiter.
Newtons tatsächliche Antwort liegt zwischen diesen beiden, und sie ist konkreter, als es die Erwartungen beider Lager sind. Protokoll-Updates laufen über das, was sie ein „Transparent Proxy“-Muster mit zeitgesperrten Upgrades nennen. Änderungen sind nicht sofort und sie sind auch nicht geräuschlos, aber das System ist auch nicht für immer eingefroren. Es gibt ein Zeitfenster zwischen dem Zeitpunkt, an dem ein Upgrade vorgeschlagen wird, und dem Zeitpunkt, an dem es tatsächlich wirksam wird – und in diesem Fenster ist es sichtbar und anfechtbar, bevor es live geht.
Das ist eine ziemlich andere Garantie als jede der beiden Standardannahmen, die die meisten Leute mit sich herumtragen. Es ist nicht „es kann sich niemals etwas ändern“ und es ist nicht „jemand kann jederzeit einen Schalter umlegen, wenn ihm danach ist“. Es ist näher an „es kann sich etwas ändern, aber du bekommst ein Zeitfenster, um zu sehen, dass es kommt, und zu reagieren, bevor es tatsächlich passiert.“
Das hängt tatsächlich mit etwas zusammen, das Newton direkt über sich selbst sagt: dezentralisiert per Design — nicht nur dezentralisiert, weil das Operator-Netzwerk zufällig über mehrere Orte verteilt ist. Wenn diese Behauptung über die Policy-Engine selbst hinaus etwas bedeuten soll, dann muss sie sich auch darauf ausdehnen, wie sich das Protokoll im Laufe der Zeit verändert. Ein System kann ein vollständig dezentralisiertes Operator-Set haben, das Transaktionen auswertet, und trotzdem in dem Sinn still zentralisiert sein, wer tatsächlich kontrolliert, welche Aufgaben diese Operatoren ausführen. Der Upgrade-Mechanismus ist wirklich der Ort, an dem diese Behauptung getestet wird — nicht die tägliche Policy-Auswertung.
Hiermit sitze ich die ganze Zeit, das heißt: Ein Time-Lock schützt dich tatsächlich nur dann, wenn jemand in diesem Zeitraum aufmerksam ist. Dasselbe Problem ist mir auch begegnet, als ich über den Challenge-Mechanismus für umstrittene Attestationen nachdachte — eine Sicherheitsmaßnahme, die von Sichtbarkeit abhängt, funktioniert nur, wenn Sichtbarkeit auch tatsächlich genutzt wird. Wenn ein Upgrade vorgeschlagen wird und fast niemand genau in diesem Moment zusieht, schließt sich das Fenster auf die gleiche Weise, wie es sich schließen würde, wenn es überhaupt kein Fenster gäbe — nur langsamer und mit besseren optischen Effekten.
Außerdem stellt sich die Frage, wer überhaupt Upgrades vorschlagen darf — getrennt davon, wer sie überhaupt bemerken kann. In den Newton-Dokumenten wird Operator-Governance und Policy-Governance so beschrieben, dass sie Qualitätssicherung und Dezentralisierung gegeneinander abwägen, aber „abgleichen“ leistet in diesem Satz eine Menge Arbeit, ohne genau zu sagen, wo diese Balance tatsächlich sitzt. Ist es so, dass jede*r Operator technisch ein Upgrade vorschlagen kann? Oder läuft es in der Praxis über eine kleinere Gruppe — Stiftung, Core Team, irgendeinen Governance-Rat — selbst wenn der Mechanismus technisch für mehr Teilnehmer offen ist als nur diese Gruppe.
„Das verbindet sich direkt mit derselben Form, die du überall sonst auch siehst, wie Newton gebaut wurde. Das Operator-Netzwerk ist ausdrücklich dezentralisiert, um Neutralität zu gewährleisten, permissioniert für Qualität, aber nicht vollständig offen und nicht vollständig geschlossen. Protokoll-Upgrades scheinen diesem gleichen Mittelweg zu folgen. Das könnte tatsächlich ein ehrlicheres Design sein, als so zu tun, als könnte man in einem System, das mit echten regulatorischen Änderungen Schritt halten muss, reine Unveränderlichkeit haben — denn Compliance-Infrastruktur, die sich niemals aktualisieren kann, ist Compliance-Infrastruktur, die beim ersten Mal, wenn sich ein Gesetz ändert, veraltet.“
Was mir bislang noch keine gute Einschätzung erlaubt, ist, wie lange dieses Time-Lock-Fenster tatsächlich ist — und wer realistisch die Kapazität hat, ein vorgeschlagenes Upgrade währenddessen im Detail zu prüfen. Eine Woche ist eine sehr andere Garantie als ein Tag. Und eine Governance-Vorlage gut zu prüfen erfordert tatsächlich technischen Aufwand; die meisten Leute, die abstimmen oder zuschauen, werden das, was eine vorgeschlagene Änderung wirklich am Policy-Engine- oder Operator-Set macht, nicht unabhängig verifizieren. Sie werden darauf vertrauen, dass jemand anderes es schon überprüft hat.
Ich bin neugierig, ob irgendjemand tatsächlich verfolgt hat, wie viele vorgeschlagene Upgrades während des Fensters echte öffentliche Aufmerksamkeit bekommen, im Vergleich zu denen, die still „durchrutschen“, nur weil der Mechanismus existiert, aber niemand ihn nutzt.
#Bitcoin$60K$70KRangeHits307DayConsolidation $LAB $TAG
