Dusk fait aujourd’hui un AMA Binance Square à 15:00 CEST et ça vaut la peine de dégager votre agenda. Vous aurez à la fois Emanuele Francioni, le PDG, et Hein Dauven, le CTO, dans la même session—ce qui est rare, c’est généralement l’un ou l’autre. Si vous suivez le DuskDS, le DuskEVM, la structure DuskVM et que vous avez encore des questions, c’est l’endroit pour les poser.
Pour l’instant, laissez-moi expliquer ce que j’ai appris. Je voyais sans cesse « privacy » mentionné par différentes chaînes, et honnêtement j’étais sceptique, parce que d’habitude, cela veut dire qu’on ajoute simplement un pool « shielded » à une chaîne par ailleurs publique. Je me suis donc renseigné sur la façon dont Dusk structure ça à travers sa pile, et ce n’était pas du tout ce à quoi je m’attendais.
En gros, Dusk répartit la tâche en trois couches au lieu d’essayer de tout faire tenir dans une seule. DuskDS se trouve tout en bas et gère le consensus de règlement ainsi que la disponibilité des données. Il exécute un système de preuve d’enjeu (proof of stake) appelé Succinct Attestation, qui fournit une finalité déterministe—ce qui compte lorsque vous réglez des actifs réglementés et que vous ne pouvez pas vous permettre une confirmation probabiliste.
Voici ce qui m’a surpris. Au-dessus, on trouve DuskEVM, construit comme un rollup OP Stack, afin que les développeurs Solidity aient des outils EVM « normaux ». La confidentialité y passe par quelque chose appelé Hedger : il combine le chiffrement homomorphe et des preuves à divulgation nulle (zero knowledge proofs), plutôt que de s’appuyer uniquement sur la ZK.
Ensuite, il y a DuskVM, l’environnement natif en Rust et en WASM : les contrats sont conçus pour être « privacy aware » dès le départ, au lieu d’ajouter la confidentialité plus tard.
C’est là que j’ai compris. Les garanties de règlement sont les mêmes en dessous, tout le long, mais chaque couche apporte la confidentialité d’une manière qui correspond vraiment à la façon dont les développeurs construisent, plutôt que de forcer une seule méthode partout.
#dusk $DUSK @Dusk
Sur quelle couche vous construiriez réellement ?
Pour l’instant, laissez-moi expliquer ce que j’ai appris. Je voyais sans cesse « privacy » mentionné par différentes chaînes, et honnêtement j’étais sceptique, parce que d’habitude, cela veut dire qu’on ajoute simplement un pool « shielded » à une chaîne par ailleurs publique. Je me suis donc renseigné sur la façon dont Dusk structure ça à travers sa pile, et ce n’était pas du tout ce à quoi je m’attendais.
En gros, Dusk répartit la tâche en trois couches au lieu d’essayer de tout faire tenir dans une seule. DuskDS se trouve tout en bas et gère le consensus de règlement ainsi que la disponibilité des données. Il exécute un système de preuve d’enjeu (proof of stake) appelé Succinct Attestation, qui fournit une finalité déterministe—ce qui compte lorsque vous réglez des actifs réglementés et que vous ne pouvez pas vous permettre une confirmation probabiliste.
Voici ce qui m’a surpris. Au-dessus, on trouve DuskEVM, construit comme un rollup OP Stack, afin que les développeurs Solidity aient des outils EVM « normaux ». La confidentialité y passe par quelque chose appelé Hedger : il combine le chiffrement homomorphe et des preuves à divulgation nulle (zero knowledge proofs), plutôt que de s’appuyer uniquement sur la ZK.
Ensuite, il y a DuskVM, l’environnement natif en Rust et en WASM : les contrats sont conçus pour être « privacy aware » dès le départ, au lieu d’ajouter la confidentialité plus tard.
C’est là que j’ai compris. Les garanties de règlement sont les mêmes en dessous, tout le long, mais chaque couche apporte la confidentialité d’une manière qui correspond vraiment à la façon dont les développeurs construisent, plutôt que de forcer une seule méthode partout.
#dusk $DUSK @Dusk
Sur quelle couche vous construiriez réellement ?
DuskEVM for familiar tooling
67%
DuskVM for native privacy
0%
Still deciding
33%
3 Votes • Vote fermé