Ich habe etwas Zeit damit verbracht, mir anzusehen, wie Newton tatsächlich mit Privatsphäre umgeht, und eine Designentscheidung stach stärker heraus als ich erwartet hatte: Es setzt sowohl auf vertrauenswürdige Ausführungsumgebungen als auch auf Zero-Knowledge-Beweise — nicht auf das eine oder das andere. Die meisten Systeme zur Wahrung der Privatsphäre, die ich gelesen habe, scheinen sich für eine Richtung zu entscheiden. Newton wirkt, als fahre es beides, je nach Richtlinie.
Das ist eine pragmatische Entscheidung, aber auch ein stilles Eingeständnis. TEEs sind schneller und einfacher zu implementieren, aber sie beruhen auf Hardware-Vertrauensannahmen — man vertraut den Isolationsgarantien des Chip-Herstellers, nicht nur der Mathematik. ZK-Beweise sind vertrauenslos, aber schwerer, und schwieriger für beliebige Logik aufzubauen. Beides zu verwenden deutet darauf hin, dass Newton dafür optimiert, was sich heute tatsächlich bereitstellen lässt, nicht dafür, was theoretisch am reinsten ist.
Aus Sicht der Infrastruktur-Bedeutung spielt das eine größere Rolle, als es klingen mag. Ein Großteil der datenschutzfreundlichen Krypto-Infrastruktur kommt ins Stocken, weil Teams darauf bestehen, einen einzigen „korrekten“ kryptografischen Ansatz zu wählen, und am Ende nichts ausliefern. Das Mischen von TEEs und ZK ist zwar weniger elegant, aber es ist genau die Art von Entscheidung, die vermuten lässt, dass sie versuchen, reale Institutionen jetzt zum Leben zu bringen — nicht später einen Reinheitswettbewerb zu gewinnen.
Ich bin allerdings nicht sicher, wie dieser Zielkonflikt von den Compliance-Teams bewertet wird, für die das tatsächlich gebaut ist. Prüfer sind möglicherweise weniger nachsichtig gegenüber „wir haben für diesen Teil TEEs verwendet“ als gegenüber einem Whitepaper.
Würde ein Risiko-Komitee tatsächlich eine Hardware-Vertrauensannahme akzeptieren, die still neben einem kryptografischen Beweis steht, oder schafft das Mischen der beiden nur eine neue Frage darüber, welche jeweils gilt?
$NEWT @NewtonProtocol #Newt
#Velvet #tag #TAC #Labs
Das ist eine pragmatische Entscheidung, aber auch ein stilles Eingeständnis. TEEs sind schneller und einfacher zu implementieren, aber sie beruhen auf Hardware-Vertrauensannahmen — man vertraut den Isolationsgarantien des Chip-Herstellers, nicht nur der Mathematik. ZK-Beweise sind vertrauenslos, aber schwerer, und schwieriger für beliebige Logik aufzubauen. Beides zu verwenden deutet darauf hin, dass Newton dafür optimiert, was sich heute tatsächlich bereitstellen lässt, nicht dafür, was theoretisch am reinsten ist.
Aus Sicht der Infrastruktur-Bedeutung spielt das eine größere Rolle, als es klingen mag. Ein Großteil der datenschutzfreundlichen Krypto-Infrastruktur kommt ins Stocken, weil Teams darauf bestehen, einen einzigen „korrekten“ kryptografischen Ansatz zu wählen, und am Ende nichts ausliefern. Das Mischen von TEEs und ZK ist zwar weniger elegant, aber es ist genau die Art von Entscheidung, die vermuten lässt, dass sie versuchen, reale Institutionen jetzt zum Leben zu bringen — nicht später einen Reinheitswettbewerb zu gewinnen.
Ich bin allerdings nicht sicher, wie dieser Zielkonflikt von den Compliance-Teams bewertet wird, für die das tatsächlich gebaut ist. Prüfer sind möglicherweise weniger nachsichtig gegenüber „wir haben für diesen Teil TEEs verwendet“ als gegenüber einem Whitepaper.
Würde ein Risiko-Komitee tatsächlich eine Hardware-Vertrauensannahme akzeptieren, die still neben einem kryptografischen Beweis steht, oder schafft das Mischen der beiden nur eine neue Frage darüber, welche jeweils gilt?
$NEWT @NewtonProtocol #Newt
#Velvet #tag #TAC #Labs