Ich hab wieder in Dusk hineingeschnuppertđ und merke immer wieder, wie ich die Frage mitten im Satz Ă€ndere. Ich habe mit PrivatsphĂ€re angefangen. Dann habe ich mich gefragt, wie PrivatsphĂ€re aussieht, wenn das, was geschĂŒtzt werden soll, Teil eines regulierten Finanzsystems ist. Das fĂŒhlt sich fĂŒr mich viel schwieriger an als nur eine Transaktion zu verbergen.
Der niederlĂ€ndische Regulierungsaustausch hat mich darauf gebracht. Ich fand es interessant, dass die Idee der kontrollierten Offenlegung aus einem regulatorischen Umfeld kam â nicht daraus, dass Dusk seine eigene Architektur erklĂ€rt. Das hat mich zum Nachdenken gebracht. Vielleicht sind PrivatsphĂ€re und Compliance nicht von Natur aus im Konflikt. Vielleicht ist das eigentliche Problem zu entscheiden, was privat bleiben sollte, was nachgewiesen werden muss und wer den Nachweis sehen darf.
Das hat auch meine Sicht auf den Vorfall beim 10,9M DUSK-Bridge umgelenkt. Die Konsensschicht war nicht kompromittiert; kompromittiert war das signierende Wallet rund um die Bridge. Ich denke immer wieder ĂŒber diese Unterscheidung nach, weil sie zeigt, wie viel gröĂer die tatsĂ€chliche Sicherheitsgrenze ist. Eine Kette kann ihren Konsens schĂŒtzen, wĂ€hrend die umliegenden Bridges, Keys, Relayer und Verarbeitungdienste eine zusĂ€tzliche Vertrauensebene einfĂŒhren.
Das Redesign interessiert mich aus demselben Grund. Das Trennen des Signierens von der Ereignisverarbeitung und das Verfolgen von Migrationen ĂŒber ZustĂ€nde wie âĂŒbermitteltâ, âabgeschlossenâ, âfehlgeschlagenâ oder âhĂ€ngen gebliebenâ ist nicht spektakulĂ€r. Aber ich glaube, genau deshalb ist es so wichtig. Es behandelt Fehler als etwas, das das System sehen und einkapseln können sollte â nicht als etwas, das man einfach voraussetzt.
Also hat sich meine Frage wieder verschoben: Wenn Dusk PrivatsphĂ€re, Compliance und grenzĂŒbergreifendes Finanzwesen nebeneinander ermöglichen will, wo sollte dann eigentlich das Vertrauen verankert sein? Ich arbeite noch daran, und ich weiĂ, dass ich nicht das vollstĂ€ndige Bild habe. Ich wĂŒrde wirklich gern von Menschen hören, die diese Architektur noch tiefer verstehen.
#dusk $DUSK @Dusk
$VELVET
$UAI
Der niederlĂ€ndische Regulierungsaustausch hat mich darauf gebracht. Ich fand es interessant, dass die Idee der kontrollierten Offenlegung aus einem regulatorischen Umfeld kam â nicht daraus, dass Dusk seine eigene Architektur erklĂ€rt. Das hat mich zum Nachdenken gebracht. Vielleicht sind PrivatsphĂ€re und Compliance nicht von Natur aus im Konflikt. Vielleicht ist das eigentliche Problem zu entscheiden, was privat bleiben sollte, was nachgewiesen werden muss und wer den Nachweis sehen darf.
Das hat auch meine Sicht auf den Vorfall beim 10,9M DUSK-Bridge umgelenkt. Die Konsensschicht war nicht kompromittiert; kompromittiert war das signierende Wallet rund um die Bridge. Ich denke immer wieder ĂŒber diese Unterscheidung nach, weil sie zeigt, wie viel gröĂer die tatsĂ€chliche Sicherheitsgrenze ist. Eine Kette kann ihren Konsens schĂŒtzen, wĂ€hrend die umliegenden Bridges, Keys, Relayer und Verarbeitungdienste eine zusĂ€tzliche Vertrauensebene einfĂŒhren.
Das Redesign interessiert mich aus demselben Grund. Das Trennen des Signierens von der Ereignisverarbeitung und das Verfolgen von Migrationen ĂŒber ZustĂ€nde wie âĂŒbermitteltâ, âabgeschlossenâ, âfehlgeschlagenâ oder âhĂ€ngen gebliebenâ ist nicht spektakulĂ€r. Aber ich glaube, genau deshalb ist es so wichtig. Es behandelt Fehler als etwas, das das System sehen und einkapseln können sollte â nicht als etwas, das man einfach voraussetzt.
Also hat sich meine Frage wieder verschoben: Wenn Dusk PrivatsphĂ€re, Compliance und grenzĂŒbergreifendes Finanzwesen nebeneinander ermöglichen will, wo sollte dann eigentlich das Vertrauen verankert sein? Ich arbeite noch daran, und ich weiĂ, dass ich nicht das vollstĂ€ndige Bild habe. Ich wĂŒrde wirklich gern von Menschen hören, die diese Architektur noch tiefer verstehen.
#dusk $DUSK @Dusk
$VELVET
$UAI
