Dusk führt neben seiner nativen Chain eine EVM-kompatible Schicht ein
, und die genannte Logik ist
schlicht:
die Einstiegshürde für Entwickler senken, bestehende Solidity-
Tools andocken lassen, statt jeden Builder zu bitten, einen
neuen Stack von Grund auf zu lernen.
Auf den ersten Blick ist das der naheliegende Schritt — EVM-
Vertrautheit ist der größte Entwicklerpool im Krypto-
Bereich, und sich dem nicht entgegenzukommen ist der Grund, warum vielversprechende L1s dauerhaft eine Nische bleiben.
Was ich dabei immer wieder als Frage mit mir herumtrage, ist eine engere:
erbt eine EVM-kompatible Schicht Dusk's tatsächliche Datenschutzgarantien,
oder erbt sie EVMs Standard-Transparenz und sitzt nur neben Dusk's Datenschicht, ohne sie zu berühren?
Das ist nicht dasselbe, und der Unterschied
ist hier wichtiger als bei den meisten L1s,
die EVM-Kompatibilität hinzufügen, weil Datenschutz und compliance-bewusste Offenlegung genau der Grund sind, warum Dusk überhaupt existiert.
Wenn ein auf der EVM-Schicht bereitgestellter Contract sich
wie jeder andere EVM-Contract verhält — öffentlicher State, öffentliche
Calldata, das Standard-Transparenzmodell — dann sind "Dusk unterstützt EVM" und "Dusk's Datenschutzmodell erstreckt sich auf EVM" zwei verschiedene Behauptungen, und nur das Marketing neigt dazu, beides zugleich zu behaupten.
Die ehrliche Version dieses Kompromisses ist, dass EVM-Kompatibilität und native vertrauliche Berechnung strukturell ein Stück weit gegeneinander arbeiten.
EVMs Ausführungsmodell wurde nicht mit selektiver Offenlegung im Blick entworfen;
Dusk's Kernversprechen wurde genau darauf aufgebaut.
Die beiden gut zu verbinden — vertraute
Tools zu behalten und trotzdem vertrauliche
Transaktionen und compliance-bewusste Smart Contracts zu erhalten — ist ein wirklich schwieriges Integrationsproblem, kein Häkchen auf einer Checkliste.
Es ist möglich, dass Dusk das elegant gelöst hat.
Es ist auch möglich, dass "EVM-kompatibel" stillschweigend bedeutet: "EVM-kompatibel für den transparenten Teil der Chain",
während die eigentlichen datenschutzwahrenden Contracts weiterhin den nativen Stack, XSC, und die Lernkurve erfordern, die EVM-Kompatibilität eigentlich beseitigen sollte.
@Dusk #dusk $DUSK
, und die genannte Logik ist
schlicht:
die Einstiegshürde für Entwickler senken, bestehende Solidity-
Tools andocken lassen, statt jeden Builder zu bitten, einen
neuen Stack von Grund auf zu lernen.
Auf den ersten Blick ist das der naheliegende Schritt — EVM-
Vertrautheit ist der größte Entwicklerpool im Krypto-
Bereich, und sich dem nicht entgegenzukommen ist der Grund, warum vielversprechende L1s dauerhaft eine Nische bleiben.
Was ich dabei immer wieder als Frage mit mir herumtrage, ist eine engere:
erbt eine EVM-kompatible Schicht Dusk's tatsächliche Datenschutzgarantien,
oder erbt sie EVMs Standard-Transparenz und sitzt nur neben Dusk's Datenschicht, ohne sie zu berühren?
Das ist nicht dasselbe, und der Unterschied
ist hier wichtiger als bei den meisten L1s,
die EVM-Kompatibilität hinzufügen, weil Datenschutz und compliance-bewusste Offenlegung genau der Grund sind, warum Dusk überhaupt existiert.
Wenn ein auf der EVM-Schicht bereitgestellter Contract sich
wie jeder andere EVM-Contract verhält — öffentlicher State, öffentliche
Calldata, das Standard-Transparenzmodell — dann sind "Dusk unterstützt EVM" und "Dusk's Datenschutzmodell erstreckt sich auf EVM" zwei verschiedene Behauptungen, und nur das Marketing neigt dazu, beides zugleich zu behaupten.
Die ehrliche Version dieses Kompromisses ist, dass EVM-Kompatibilität und native vertrauliche Berechnung strukturell ein Stück weit gegeneinander arbeiten.
EVMs Ausführungsmodell wurde nicht mit selektiver Offenlegung im Blick entworfen;
Dusk's Kernversprechen wurde genau darauf aufgebaut.
Die beiden gut zu verbinden — vertraute
Tools zu behalten und trotzdem vertrauliche
Transaktionen und compliance-bewusste Smart Contracts zu erhalten — ist ein wirklich schwieriges Integrationsproblem, kein Häkchen auf einer Checkliste.
Es ist möglich, dass Dusk das elegant gelöst hat.
Es ist auch möglich, dass "EVM-kompatibel" stillschweigend bedeutet: "EVM-kompatibel für den transparenten Teil der Chain",
während die eigentlichen datenschutzwahrenden Contracts weiterhin den nativen Stack, XSC, und die Lernkurve erfordern, die EVM-Kompatibilität eigentlich beseitigen sollte.
@Dusk #dusk $DUSK