Nachdem ich recherchiert habe, wie das dezentrale Protokoll das Risiko von Live-Laufzeitaktualisierungen adressieren kann, bin ich zu dem Schluss gekommen, dass die kritischste Schwachstelle in dezentralen Smart Contracts darin besteht, dass eine dritte Partei aktive Regeln über Governance-Keys verändern kann. So adressiert Newton Protocol dieses spezielle Problem gezielt durch das Design – ohne dass dafür die Gesamtheit des eigenen Backend-Systems neu geschrieben werden muss.
Eine der grundlegenden Herausforderungen im Zusammenhang mit permissionless On-Chain-Automatisierung besteht darin, die Spielregeln im Laufe der Zeit aktualisieren zu können. Wenn der Governance-Vertrag oder das Multi-Sig-Konto, das für diese Entscheidungen verantwortlich ist, in böser Absicht handelt und Laufzeitbedingungen verändert, entsteht ein „Policy-Update-Vektor“ für einen Angriff.
Beispielsweise könnte ein Angreifer mit Zugriff auf ein solches Konto das Ausgabenlimit direkt erhöhen, bevor eine Transaktion durchläuft, oder einige der Compliance-Kontrollen lockern. Das Newton-Protokoll mindert diesen Angriffsvektor, indem es erzwingt, dass Zustandsübergänge mit einem kryptografischen Nachweis signiert werden, der sie an einen spezifischen historischen Root-Zustand bindet.
Um zu verstehen, warum dieser Ansatz notwendig ist, müssen wir das Problem erörtern, das Newton lösen will. Jedes System, das einen Operator dazu verpflichtet, Richtlinien in Echtzeit zu aktualisieren, steht vor einer ernsthaften Skalierungsherausforderung aufgrund der schieren Anzahl möglicher Zustandsübergänge. Wenn ein Operator beispielsweise etwas ändern möchte, muss das System sicherstellen, dass die Gültigkeit des neuen Zustands innerhalb der Bedingungen aller vorherigen Zustände liegt. Das kann sich als äußerst belastend für das Netzwerk erweisen, wenn ein Vorschlag eine Reihe komplizierter Sonderfälle enthält. Diese Zusatzlast kann Newton vermeiden, indem es einen Zustands-Root verwendet: Jede Änderung an der Richtlinie wird als eine einzelne atomare Operation festgeschrieben, die vom Netzwerk mit einer Prüfung der Linearen Temporallogik validiert wird. Die Idee ist, dass man das Netzwerk nicht fragt, ob neuer Code gültig ist oder nicht, sondern es bittet, eine bestimmte Menge von Änderungen als logische Erweiterung des aktuellen Zustands-Roots zu validieren.
Wenn eine Regeländerung oder ein Vorschlag zur Richtlinienaktualisierung an das Netzwerk übermittelt wird, starten die Validatorknoten einen Prozess zur Aggregation von Signaturen. So können sie feststellen, ob ausreichend Unterstützung für die Übernahme der neuen Regeln vorhanden ist. Wenn der Übergang gültig ist, bedeutet das, dass die Mehrheit der Validatorknoten der Änderung zustimmt, und sie wird bei der nächsten verfügbaren Gelegenheit als neuer Zustands-Root der Blockchain hinzugefügt.
Wenn andererseits die Validatorknoten den Übergang nicht erfolgreich durchführen können, weil die Unterschriften unzureichend sind oder mathematische Unstimmigkeiten mit dem bestehenden Zustands-Root vorliegen, wird das Update zurückgesetzt. Effektiv werden alle Änderungen am Systemvertrag, die keine strenge kryptografische Überprüfung bestehen, von vornherein abgelehnt. Dadurch werden böswillige Flash-Governance-Angriffe verhindert, die darauf abzielen, Einschränkungen vorübergehend zu lockern und sie dann wieder einzurasten.
Indem jede Änderung am Systemvertrag erforderlich macht, einen signierten Übergang vom aktuellen Zustands-Root einzuschließen, verhindert Newton Angriffe, die darauf abzielen, die Integrität erlaubnisloser On-Chain-Systeme zu untergraben. In diesem Modell müssen Entwickler keine fortgeschrittenen Sicherheitsmaßnahmen direkt in den Kernvertrag einbauen, um die Zuverlässigkeit von Governance-Vorschlägen sicherzustellen. Stattdessen können sie sich darauf konzentrieren, effiziente, deterministische Smart Contracts zu bauen, während volatilere Randbedingungen separat in Form von Richtlinien-Updates verwaltet werden.
