Was wäre, wenn eine Transaktion nachweisen könnte, dass sie Ihre Regeln erfüllt hat, bevor Ihr Smart Contract überhaupt damit in Berührung kommt?
@NewtonProtocol hält daran fest, dass Autorisierung vor der Ausführung erfolgen sollte, nicht danach. Das klingt nach Kleinigkeiten, aber es verändert die Stelle, an der Entwickler Vertrauen setzen. Statt jede Bedingung direkt in einen Contract zu schreiben, entscheidet eine Policy darüber, ob eine Transaktion überhaupt weitermachen darf.
Die praktische Spannung $UP
Die meisten Smart Contracts sind nach der Bereitstellung statisch.
Geschäftsregeln sind nicht.
Ein Ausgabenlimit ändert sich. Eine Compliance-Anforderung ändert sich. Der Status eines Wallets ändert sich. Solidity jedes Mal zu aktualisieren ist langsam und teuer. Newton geht das anders an, indem es Transaktionsregeln von der Contract-Logik trennt.
Was sticht hervor
•Fakt: Newton bewertet Transaction Intents vor der Ausführung über einen Policy-Workflow, statt alles innerhalb von Solidity zu prüfen.
•Fakt: Policies können vor einer Entscheidung externe Informationen nutzen, die über WebAssembly (WASM)-Datenoracles bereitgestellt werden.
•Fakt: Operatoren liefern kryptografische Attestierungen, die vom on-chain PolicyClient vor der Ausführung verifiziert werden.
•Meinung: Das Interessante ist nicht die Policy-Sprache. Es geht darum, die Anzahl der Gründe zu reduzieren, aus denen ein Vertrag neu bereitgestellt werden muss, wenn sich Geschäftsregeln weiterentwickeln.
Eine Beobachtung, zu der ich immer wieder zurückkomme
#Newt versucht nicht, Verträge komplizierter zu machen.
Es versucht, sie weniger verantwortlich zu machen.
Der Vertrag verifiziert hauptsächlich eine Attestierung. Die Entscheidung selbst wurde bereits anderswo anhand vordefinierter Regeln ausgewertet.
Das schafft eine sauberere Trennung zwischen Ausführung und Autorisierung.
Ob das zu einem Vorteil wird, hängt von der Anwendung ab.
Die Zahlen, die man im Blick behalten sollte
•Etwa 30 Minuten, um eine WASM-Daten-Oracle zu erstellen.
•Etwa 20 Minuten, um eine Rego-Policy zu schreiben.
•Etwa 15 Minuten für das CLI-Deployment.
•Jeweils etwa 30 Minuten für die Integration von Smart Contracts und die Integration des Frontend-SDK.
Das sind Schätzungen aus der Dokumentation, keine Garantien. Reale Projekte dauern normalerweise länger, je nach Tests und Sicherheitsreviews.
Evtakeaway
•Newton ermöglicht es Entwicklern, Policies unabhängig von Verträgen bereitzustellen.
•Newton unterstützt externe Dateninputs während der Policy-Auswertung.
•Newton prüft BLS-signierte Attestierungen on-chain, bevor es zur Ausführung kommt.
•Für das Deployment von Policies im Mainnet ist ein Allowlisting erforderlich, statt vollständig permissionslos bereitzustellen.
Diese Details deuten darauf hin, dass Newton erwartet, dass die Autorisierungsinfrastruktur als produktionskritisch behandelt wird – nicht als optionale Funktion.
Wo ich denke, dass Newton interessant wird
Stell dir einen Treasury mit einem täglichen Überweisungslimit vor.
Morgen entscheidet der Vorstand, dass sich das Limit ändert.
Ohne Newton könnten Entwickler Verträge neu bereitstellen oder Governance-Komplexität hinzufügen.
Mit Newton ändern sich die Policies, während der Ausführungsvertrag gleich bleibt.
Das beseitigt keine Governance.
Es verändert, wo Governance stattfindet.
Kleine Unterscheidung.
Möglicherweise sinnvoll.
Was ich prüfen würde, bevor ich auf Newton aufbaue
•Woher kommen die externen Daten tatsächlich?
•Wer betreibt die Datenquelle?
•Wie oft wird diese Information aktualisiert?
•Kann sich die Policy-Logik ändern, ohne bestehende Annahmen zu beeinflussen?
•Wer steuert Policy-Upgrades?
•Sind Attestierungen leicht unabhängig zu prüfen?
•Hat die PolicyClient-Implementierung Sicherheitsscans erhalten?
•Was passiert, wenn die Policy-Auswertung vorübergehend nicht verfügbar ist?
Diese Fragen sind wichtiger als ob sich das SDK bequem anfühlt.
Risiken, die es wert sind, im Blick zu behalten
•Risiko für Smart Contracts: Selbst wenn Newton Attestierungen korrekt validiert, können Anwendungs-Contracts weiterhin Implementierungsfehler enthalten.
•Risiko durch externe Abhängigkeiten: Policy-Entscheidungen stützen sich auf die Off-Chain-Auswertung und die Datenverfügbarkeit. Wenn die unterstützende Infrastruktur ausfällt, könnte die Autorisierung der Transaktion verzögert werden.
•Operatives Risiko: Governance für Policy-Updates wird zu einer wichtigen Annahme für die Sicherheit.
•Dokumentationsschätzungen: Integrationszeiten sind Referenzwerte, keine Produktionszeitpläne.
Ausgewogene Designs nehmen selten das Risiko vollständig heraus.
Sie verschieben es normalerweise woanders hin.
Mein Fazit $ARX
$NEWT fühlt sich weniger wie ein weiteres Smart-Contract-Toolkit an und mehr wie der Versuch, die Person, die entscheidet, von der Person zu trennen, die ausführt. Diese Trennung könnte einige Anwendungen vereinfachen, aber auch neue operative Annahmen einführen. Ob dieser Trade-off den Aufwand wert ist, hängt wahrscheinlich weniger von Newton selbst ab und mehr davon, wie stark dein Projekt erwartet, dass sich seine Autorisierungsregeln nach dem Deployment ändern. Das ist der Teil, den ich im Blick behalten würde.