Die meisten Menschen bemerken Newton, wenn eine Transaktion genehmigt wird.
Was ich jedoch viel interessanter finde, ist alles, was schon richtig laufen muss, bevor diese Genehmigung überhaupt erfolgt.
Denk mal kurz darüber nach: Dutzende unabhängige Operatoren sollen die gleiche Entscheidung treffen, ohne sich auf einen zentralen Koordinator zu verlassen. Das ist viel schwieriger, als es klingt.
Die Schwachstelle liegt nicht in der Richtlinie selbst. Sondern darin sicherzustellen, dass jeder Operator exakt dieselbe Version dieser Richtlinie betrachtet. Wenn ein Knoten veraltete Regeln auswertet, während ein anderer die neueste Aktualisierung verwendet, verschwindet die Konsistenz ziemlich schnell.
Darum ist mir Newtons Einsatz von IPFS aufgefallen. Richtlinien sind mit einem bestimmten CID verknüpft, sodass Operatoren nicht nur darauf vertrauen, dass sie die richtige Version haben – sie können es überprüfen. Ändert man die Richtlinie, ändert sich auch der Identifier. Das ist eine kleine Einzelheit, aber sie nimmt sehr viele versteckte Annahmen aus dem Spiel.
Dieser gleiche Ansatz scheint sich auch auf externe Daten zu übertragen. Oracle-Feeds und andere Integrationen erhalten keinen unbegrenzten Zugriff. Sie sind über WASM-Plugins isoliert, wodurch externe Abhängigkeiten daran gehindert werden, den Ablauf zu stören, wie Richtlinien ausgewertet werden.
Für mich ist das einer der am häufigsten übersehenen Aspekte von Newton. Alle sprechen über Dezentralisierung, aber die deterministische Verteilung von Richtlinien ist es, die dezentraler Autorisierung erst echte Glaubwürdigkeit verleiht.
Als Nächstes würde ich gern verstehen, wie Richtlinien-Updates in der Praxis gehandhabt werden. Wenn eine neue CID eingeführt wird, während Anfragen noch verarbeitet werden, wie verhindert Newton, dass verschiedene Operatoren gleichzeitig unterschiedliche Versionen auswerten?
#newt $NEWT @NewtonProtocol #Newt
Was ich jedoch viel interessanter finde, ist alles, was schon richtig laufen muss, bevor diese Genehmigung überhaupt erfolgt.
Denk mal kurz darüber nach: Dutzende unabhängige Operatoren sollen die gleiche Entscheidung treffen, ohne sich auf einen zentralen Koordinator zu verlassen. Das ist viel schwieriger, als es klingt.
Die Schwachstelle liegt nicht in der Richtlinie selbst. Sondern darin sicherzustellen, dass jeder Operator exakt dieselbe Version dieser Richtlinie betrachtet. Wenn ein Knoten veraltete Regeln auswertet, während ein anderer die neueste Aktualisierung verwendet, verschwindet die Konsistenz ziemlich schnell.
Darum ist mir Newtons Einsatz von IPFS aufgefallen. Richtlinien sind mit einem bestimmten CID verknüpft, sodass Operatoren nicht nur darauf vertrauen, dass sie die richtige Version haben – sie können es überprüfen. Ändert man die Richtlinie, ändert sich auch der Identifier. Das ist eine kleine Einzelheit, aber sie nimmt sehr viele versteckte Annahmen aus dem Spiel.
Dieser gleiche Ansatz scheint sich auch auf externe Daten zu übertragen. Oracle-Feeds und andere Integrationen erhalten keinen unbegrenzten Zugriff. Sie sind über WASM-Plugins isoliert, wodurch externe Abhängigkeiten daran gehindert werden, den Ablauf zu stören, wie Richtlinien ausgewertet werden.
Für mich ist das einer der am häufigsten übersehenen Aspekte von Newton. Alle sprechen über Dezentralisierung, aber die deterministische Verteilung von Richtlinien ist es, die dezentraler Autorisierung erst echte Glaubwürdigkeit verleiht.
Als Nächstes würde ich gern verstehen, wie Richtlinien-Updates in der Praxis gehandhabt werden. Wenn eine neue CID eingeführt wird, während Anfragen noch verarbeitet werden, wie verhindert Newton, dass verschiedene Operatoren gleichzeitig unterschiedliche Versionen auswerten?
#newt $NEWT @NewtonProtocol #Newt