#nil $NIL @Nillion
Nillions Covenants werfen eine interessante Vertrauensfrage auf: Was stellt sicher, dass eine vertrauliche Anweisung freigegeben werden sollte?
Nillion beschreibt seine Architektur folgendermaßen: Ein Covenant bindet eine Nutzlast an eine Bedingung. Die verschlüsselten Anteile werden auf ein Komitee aus Nodes verteilt, sodass kein einzelner Betreiber die ursprüngliche Nutzlast allein rekonstruieren kann. Sobald die Bedingung erfüllt ist, veröffentlichen die Nodes ihre Anteile. Dadurch kann die Nutzlast rekonstruiert und auf Ethereum verifiziert werden, bevor die nachgelagerte Aktion erfolgt.
Entscheidend ist die Unterscheidung zwischen dem dokumentierten Mechanismus – eine Anweisung an eine Bedingung zu binden – und den weitergehenden Sicherheitsgarantien, die von der Implementierung und den Annahmen des Protokolls abhängen.
Betrachten wir einen bedingten Handel, der an einen Preisfeed geknüpft ist. Wenn dieser Feed verzögert oder ungenau ist, werden die auslösenden Daten nicht dadurch zuverlässig, dass die Anweisung verschlüsselt bleibt. Vertraulichkeit schützt die Strategie vor einer vorzeitigen Offenlegung; sie garantiert für sich genommen nicht, dass die Bedingung korrekt ausgewertet wird. Deshalb sind die Vertrauensannahmen rund um das Auslösen und Offenlegen ebenso wichtig wie der Datenschutzmechanismus.
Die tiefergehende Frage lautet: Was muss das System als vertrauenswürdig voraussetzen? Eine korrekte Bedingung, eine rechtmäßige Offenlegung und Vertraulichkeit sind voneinander getrennte Anforderungen. Der Schutz der Nutzlast beweist nicht automatisch, dass der Auslöser korrekt ausgewertet wurde oder dass die Offenlegung den vorgesehenen Regeln entsprach. Diese Garantien hängen vom Verifizierungsdesign des Protokolls und seinen Annahmen ab.
Was sollte am genauesten geprüft werden, damit eine bedingungsgesteuerte Ausführung praktikabel wird: die Zuverlässigkeit des Auslösers, die Integrität der Offenlegung oder die Annahmen, auf die sich das Protokoll stützt, um beides zu schützen?
$NIL
Nillions Covenants werfen eine interessante Vertrauensfrage auf: Was stellt sicher, dass eine vertrauliche Anweisung freigegeben werden sollte?
Nillion beschreibt seine Architektur folgendermaßen: Ein Covenant bindet eine Nutzlast an eine Bedingung. Die verschlüsselten Anteile werden auf ein Komitee aus Nodes verteilt, sodass kein einzelner Betreiber die ursprüngliche Nutzlast allein rekonstruieren kann. Sobald die Bedingung erfüllt ist, veröffentlichen die Nodes ihre Anteile. Dadurch kann die Nutzlast rekonstruiert und auf Ethereum verifiziert werden, bevor die nachgelagerte Aktion erfolgt.
Entscheidend ist die Unterscheidung zwischen dem dokumentierten Mechanismus – eine Anweisung an eine Bedingung zu binden – und den weitergehenden Sicherheitsgarantien, die von der Implementierung und den Annahmen des Protokolls abhängen.
Betrachten wir einen bedingten Handel, der an einen Preisfeed geknüpft ist. Wenn dieser Feed verzögert oder ungenau ist, werden die auslösenden Daten nicht dadurch zuverlässig, dass die Anweisung verschlüsselt bleibt. Vertraulichkeit schützt die Strategie vor einer vorzeitigen Offenlegung; sie garantiert für sich genommen nicht, dass die Bedingung korrekt ausgewertet wird. Deshalb sind die Vertrauensannahmen rund um das Auslösen und Offenlegen ebenso wichtig wie der Datenschutzmechanismus.
Die tiefergehende Frage lautet: Was muss das System als vertrauenswürdig voraussetzen? Eine korrekte Bedingung, eine rechtmäßige Offenlegung und Vertraulichkeit sind voneinander getrennte Anforderungen. Der Schutz der Nutzlast beweist nicht automatisch, dass der Auslöser korrekt ausgewertet wurde oder dass die Offenlegung den vorgesehenen Regeln entsprach. Diese Garantien hängen vom Verifizierungsdesign des Protokolls und seinen Annahmen ab.
Was sollte am genauesten geprüft werden, damit eine bedingungsgesteuerte Ausführung praktikabel wird: die Zuverlässigkeit des Auslösers, die Integrität der Offenlegung oder die Annahmen, auf die sich das Protokoll stützt, um beides zu schützen?
$NIL