J’ai fissuré ce matin le pipeline d’exécution de Dusk — et j’ai réalisé que la plupart des chaînes ne font que greffer de la confidentialité sur une base EVM conçue pour la transparence. Dusk a reconstruit la pile depuis le circuit vers le haut.
DuskVM exécute du bytecode WASM, pas de l’EVM. Les contrats sont compilés en WASM et passent par un tampon d’arguments de 64 Ko. Les résultats d’exécution doivent être identiques sur chaque nœud, sinon la validation par consensus échoue. C’est une exécution déterministe imposée au niveau du protocole, et non une hypothèse.
Le pipeline de règlement fait tourner en parallèle deux modèles natifs de transactions — Moonlight pour les transferts publics, basés sur des comptes, et Phoenix pour les transferts protégés, de type UTXO, avec des preuves ZK. Les deux règlent sur la même chaîne via le contrat de transfert, qui accepte les deux types de données, les oriente vers la logique de vérification et empêche les doubles dépenses. Coordination d’état au niveau du protocole, pas une option d’interface.
Pile cryptographique : BLS12-381 pour les signatures agrégées et le seuil BLS, JubJub pour des circuits ZK efficaces, Poseidon pour un hachage optimisé pour les circuits, PLONK pour des preuves réutilisables, vérifiables on-chain. Le tout en Rust pur. L’attestation concise se finalise en trois rondes déterministes — proposition, validation, ratification — avec des validateurs sélectionnés aléatoirement. Pas de réorganisation (reorg). Pas de finalité probabiliste. Temps moyen de bloc : ~2 secondes.
Ce qui n’est pas abordé : si le pipeline d’exécution WASM avec une confidentialité intégrée en ZK maintient le débit sous des volumes de trading institutionnels, ou si la surcharge des circuits devient le prochain goulot d’étranglement.
Ce avec quoi je me retrouve : Dusk n’a pas forké une chaîne. Il a construit un environnement d’exécution où la confidentialité, la conformité et le règlement sont le même problème d’ingénierie — résolu au niveau du circuit avant même qu’une première transaction ne soit réglée.
@Dusk #DUSK
#dusk $DUSK $WAL $ACE
DuskVM exécute du bytecode WASM, pas de l’EVM. Les contrats sont compilés en WASM et passent par un tampon d’arguments de 64 Ko. Les résultats d’exécution doivent être identiques sur chaque nœud, sinon la validation par consensus échoue. C’est une exécution déterministe imposée au niveau du protocole, et non une hypothèse.
Le pipeline de règlement fait tourner en parallèle deux modèles natifs de transactions — Moonlight pour les transferts publics, basés sur des comptes, et Phoenix pour les transferts protégés, de type UTXO, avec des preuves ZK. Les deux règlent sur la même chaîne via le contrat de transfert, qui accepte les deux types de données, les oriente vers la logique de vérification et empêche les doubles dépenses. Coordination d’état au niveau du protocole, pas une option d’interface.
Pile cryptographique : BLS12-381 pour les signatures agrégées et le seuil BLS, JubJub pour des circuits ZK efficaces, Poseidon pour un hachage optimisé pour les circuits, PLONK pour des preuves réutilisables, vérifiables on-chain. Le tout en Rust pur. L’attestation concise se finalise en trois rondes déterministes — proposition, validation, ratification — avec des validateurs sélectionnés aléatoirement. Pas de réorganisation (reorg). Pas de finalité probabiliste. Temps moyen de bloc : ~2 secondes.
Ce qui n’est pas abordé : si le pipeline d’exécution WASM avec une confidentialité intégrée en ZK maintient le débit sous des volumes de trading institutionnels, ou si la surcharge des circuits devient le prochain goulot d’étranglement.
Ce avec quoi je me retrouve : Dusk n’a pas forké une chaîne. Il a construit un environnement d’exécution où la confidentialité, la conformité et le règlement sont le même problème d’ingénierie — résolu au niveau du circuit avant même qu’une première transaction ne soit réglée.
@Dusk #DUSK
#dusk $DUSK $WAL $ACE
