Ich habe heute Abend Zeit darauf verwendet, mich damit zu beschäftigen, wie Newton die tatsächliche Berechnung für diese Richtlinienprüfungen mit sensiblen Eingaben handhabt. Die Ausführung stützt sich für Tempo und Isolation auf TEEs, wenn Offchain-Daten eingebunden werden, und wird dabei mit ZK-Beweisen kombiniert, die belegen, dass die Rego-Auswertung die Regeln korrekt befolgt hat.
Es erstellt diese doppelte Prüfung. Der TEE-Teil sorgt dafür, dass alles effizient läuft, ohne dabei alles öffentlich offenzulegen. Die ZK-Seite ermöglicht es jeder Person, das Ergebnis herauszufordern und onchain zu verifizieren, falls etwas verdächtig wirkt.
°EIN WICHTIGER PUNKT IST, DASS
TEEs tragen weiterhin Risiken auf Hardware-Ebene. Ein Kompromiss in der vertrauenswürdigen Umgebung könnte Inputs beeinflussen, noch bevor der ZK-Beweis überhaupt greift. Ein weiteres Problem ist die hinzugefügte Komplexität. Die Abstimmung beider Ebenen über ein verteiltes Betreiberset hinweg könnte während hoher Auslastung oder bei Updates neue Ausfallmodi mit sich bringen.
Ich habe immer wieder darüber nachgedacht, wie ein Tresor institutionelle Positionen verwaltet. Eine Richtlinie könnte eine Übertragung anhand von Jurisdiktionsdaten oder Risikoschwellen kennzeichnen, ohne die Details offenzulegen. Das System bewertet das offchain über das Hybridmodell, fügt die Bestätigung hinzu, und der Vertrag schreitet nur fort, wenn er sie verifiziert. Das fühlt sich konkret für echte Compliance-Anforderungen an, hängt jedoch weiterhin davon ab, dass die TEE-Bestätigungen über die Zeit hinweg zuverlässig bleiben.
Die größere Frage für mich ist, wie dieses Hybridmodell standhält, wenn ein primitiver Baustein unter Stress gerät. Reine Ansätze haben deutlichere Schwächen, aber diese Aufteilung gibt etwas an Einfachheit auf, um mehr Abdeckung zu erreichen. Sie lässt mich darauf achten, wie Betreiber in der Praxis die Aktualität der Bestätigungen handhaben.@NewtonProtocol #Newt $NEWT
