#newt $NEWT Ein Policy von der Testumgebung bis zum Echtgeldkonto zu bringen — Newtons gefährlichster Moment ist womöglich nicht ein Angriff, sondern eine fehlerhafte Veröffentlichung
Ich habe eine der teuersten Arten von Softwarevorfällen gesehen, und meist gab es keinen Hacker. Entwickler haben lediglich Testparameter in die Produktionsumgebung übernommen oder an einem Freitagabend eine Zeile Konfiguration zu wenig geprüft, und am nächsten Tag lief das Kapital brav nach den falschen Regeln.
Die Dokumentation von Newton bietet Simulationsaufgaben, Versionskompatibilitätsprüfungen und Dry-Run-Migrationen. Diese Werkzeuge zeigen, dass das Team weiß, dass ein Policy-Deployment nicht einfach nur das Kopieren einer Datei ist. Doch Werkzeuge allein bedeuten nicht, dass die Veröffentlichungsdisziplin automatisch vorhanden ist. Die Strategieeigentümer müssen weiterhin entscheiden, wann die Policy-Adresse aktualisiert wird, wie lange Parameter gültig sind und welche Verträge zuerst auf die neue Version umgestellt werden.$ETH
Wenn ein Ausgabenlimit versehentlich von 100.000 auf 1.000.000 geschrieben wird, korrigiert eine BLS-Signatur den Fehler nicht für den Menschen. Der Betreiber beweist nur, dass diese Regel konsistent ausgeführt wurde. Der gefährlichste Vorfall kann deshalb den schönsten Beweis haben.
Ich wünsche mir, dass @NewtonProtocol das Policy-Deployment so behandelt wie eine Änderung im Finanzsystem: zuerst Schattenverkehr laufen lassen, dann mit kleinen Beträgen echter Gelder beginnen und nach Prüfung, dass Ablehnungsrate und Gebühren unauffällig sind, schrittweise ausweiten. Jede Änderung sollte außerdem die alte Version und klare Rollback-Bedingungen behalten.
Nach Abschluss der Veröffentlichung muss man außerdem eine Zeit lang beobachten. Wenn die Ablehnungsrate der neuen Version plötzlich doppelt so hoch ist, externe Datenaufrufe anormal werden oder sich die Latenz im langen Schwanz verlängert, sollte automatisch ein Rollback ausgelöst werden, statt zu warten, bis Nutzer in der Community Fehler melden. Der Veröffentlichende sollte auch nachweisen können, welche Szenarien getestet wurden, und darf nicht nur eine einzelne On-Chain-Transaktion mit „Update erfolgreich“ hinterlassen.
Wenn NEWT echtes Geld tragen soll, muss es zuerst eine nicht besonders glamouröse Wahrheit akzeptieren: Sicherheit hängt nicht nur von Kryptographie ab, sondern auch davon, wer zu welchem Zeitpunkt welche Version der Regeln in die Produktionsumgebung bringt.
Ich habe eine der teuersten Arten von Softwarevorfällen gesehen, und meist gab es keinen Hacker. Entwickler haben lediglich Testparameter in die Produktionsumgebung übernommen oder an einem Freitagabend eine Zeile Konfiguration zu wenig geprüft, und am nächsten Tag lief das Kapital brav nach den falschen Regeln.
Die Dokumentation von Newton bietet Simulationsaufgaben, Versionskompatibilitätsprüfungen und Dry-Run-Migrationen. Diese Werkzeuge zeigen, dass das Team weiß, dass ein Policy-Deployment nicht einfach nur das Kopieren einer Datei ist. Doch Werkzeuge allein bedeuten nicht, dass die Veröffentlichungsdisziplin automatisch vorhanden ist. Die Strategieeigentümer müssen weiterhin entscheiden, wann die Policy-Adresse aktualisiert wird, wie lange Parameter gültig sind und welche Verträge zuerst auf die neue Version umgestellt werden.$ETH
Wenn ein Ausgabenlimit versehentlich von 100.000 auf 1.000.000 geschrieben wird, korrigiert eine BLS-Signatur den Fehler nicht für den Menschen. Der Betreiber beweist nur, dass diese Regel konsistent ausgeführt wurde. Der gefährlichste Vorfall kann deshalb den schönsten Beweis haben.
Ich wünsche mir, dass @NewtonProtocol das Policy-Deployment so behandelt wie eine Änderung im Finanzsystem: zuerst Schattenverkehr laufen lassen, dann mit kleinen Beträgen echter Gelder beginnen und nach Prüfung, dass Ablehnungsrate und Gebühren unauffällig sind, schrittweise ausweiten. Jede Änderung sollte außerdem die alte Version und klare Rollback-Bedingungen behalten.
Nach Abschluss der Veröffentlichung muss man außerdem eine Zeit lang beobachten. Wenn die Ablehnungsrate der neuen Version plötzlich doppelt so hoch ist, externe Datenaufrufe anormal werden oder sich die Latenz im langen Schwanz verlängert, sollte automatisch ein Rollback ausgelöst werden, statt zu warten, bis Nutzer in der Community Fehler melden. Der Veröffentlichende sollte auch nachweisen können, welche Szenarien getestet wurden, und darf nicht nur eine einzelne On-Chain-Transaktion mit „Update erfolgreich“ hinterlassen.
Wenn NEWT echtes Geld tragen soll, muss es zuerst eine nicht besonders glamouröse Wahrheit akzeptieren: Sicherheit hängt nicht nur von Kryptographie ab, sondern auch davon, wer zu welchem Zeitpunkt welche Version der Regeln in die Produktionsumgebung bringt.