Ich habe versucht nachzuverfolgen, wo Privatsphäre tatsächlich in einer Solidity-Anwendung beginnt – bei @Dusk .
Ich ging davon aus, dass ein auf DuskEVM bereitgestellter Vertrag gewissermaßen die Privatsphäre von Dusk erbt, weil seine Daten und die Abwicklung irgendwann über DuskDS laufen.
So funktioniert der Stack jedoch nicht.
DuskEVM bietet Entwicklern eine vertraute EVM-Ausführung. Sie können Solidity, Hardhat, Foundry und bestehende Wallets nutzen. Unterhalb davon sitzt DuskDS als Abwicklungs- und Data-Availability-Basis.
Aber ein normaler Solidity-Vertrag kann seinen Zustand weiterhin wie jede andere EVM-Anwendung veröffentlichen.
Vertraulichkeit muss über Hedger in die Anwendung hineingedacht werden – oder näher an Dusk’ native Privatsphäre-Pfad über DuskVM und Phoenix ausgelagert werden. Sie wird nicht automatisch hinzugefügt, nur weil der Vertrag im Dusk-Ökosystem läuft.
Diese Grenze hat mich zum Innehalten gebracht.
Stell dir einen tokenisierten Anleihemarkt vor.
Der Marktpreis muss möglicherweise öffentlich bleiben.
Die Eignung der Anleger muss nur nachgewiesen werden.
Die Kontostände der Inhaber sollten wahrscheinlich privat bleiben.
Der Emittent oder der Regulator könnte einen kontrollierten Zugriff auf bestimmte Datensätze verlangen.
Diese vier Bausteine lassen sich nicht einfach in denselben öffentlichen Solidity-Status einbetten.
Hedger soll einen Teil davon lösen, indem Werte verschlüsselt bleiben, während Zero-Knowledge-Proofs verifizieren, dass die Transaktion die Regeln eingehalten hat. Aber der Entwickler muss dennoch festlegen, was in den verschlüsselten Ablauf fließt, was öffentlich bleibt und wer Offenlegungsrechte erhält.
Eine einzige schlechte Design-Entscheidung könnte sensible Finanzdaten freilegen, bevor überhaupt Kryptografie eine Chance hat, sie zu schützen.
Daher liegt mein Fokus weniger darauf, wie viele kryptografische Primitive Dusk unterstützt.
Ich beobachte, ob seine Tools die öffentliche/private Grenze klar genug machen, damit normale Solidity-Teams sie korrekt verwenden können.
Dusk kann die Privatsphäre-Routen bereitstellen. Diese Architekturentscheidung kann es jedoch nicht für jede Anwendung übernehmen.
#dusk $DUSK
Ich ging davon aus, dass ein auf DuskEVM bereitgestellter Vertrag gewissermaßen die Privatsphäre von Dusk erbt, weil seine Daten und die Abwicklung irgendwann über DuskDS laufen.
So funktioniert der Stack jedoch nicht.
DuskEVM bietet Entwicklern eine vertraute EVM-Ausführung. Sie können Solidity, Hardhat, Foundry und bestehende Wallets nutzen. Unterhalb davon sitzt DuskDS als Abwicklungs- und Data-Availability-Basis.
Aber ein normaler Solidity-Vertrag kann seinen Zustand weiterhin wie jede andere EVM-Anwendung veröffentlichen.
Vertraulichkeit muss über Hedger in die Anwendung hineingedacht werden – oder näher an Dusk’ native Privatsphäre-Pfad über DuskVM und Phoenix ausgelagert werden. Sie wird nicht automatisch hinzugefügt, nur weil der Vertrag im Dusk-Ökosystem läuft.
Diese Grenze hat mich zum Innehalten gebracht.
Stell dir einen tokenisierten Anleihemarkt vor.
Der Marktpreis muss möglicherweise öffentlich bleiben.
Die Eignung der Anleger muss nur nachgewiesen werden.
Die Kontostände der Inhaber sollten wahrscheinlich privat bleiben.
Der Emittent oder der Regulator könnte einen kontrollierten Zugriff auf bestimmte Datensätze verlangen.
Diese vier Bausteine lassen sich nicht einfach in denselben öffentlichen Solidity-Status einbetten.
Hedger soll einen Teil davon lösen, indem Werte verschlüsselt bleiben, während Zero-Knowledge-Proofs verifizieren, dass die Transaktion die Regeln eingehalten hat. Aber der Entwickler muss dennoch festlegen, was in den verschlüsselten Ablauf fließt, was öffentlich bleibt und wer Offenlegungsrechte erhält.
Eine einzige schlechte Design-Entscheidung könnte sensible Finanzdaten freilegen, bevor überhaupt Kryptografie eine Chance hat, sie zu schützen.
Daher liegt mein Fokus weniger darauf, wie viele kryptografische Primitive Dusk unterstützt.
Ich beobachte, ob seine Tools die öffentliche/private Grenze klar genug machen, damit normale Solidity-Teams sie korrekt verwenden können.
Dusk kann die Privatsphäre-Routen bereitstellen. Diese Architekturentscheidung kann es jedoch nicht für jede Anwendung übernehmen.
#dusk $DUSK
