Première fois que je vois @Dusk : faire en même temps deux modèles de transactions, Moonlight et Phoenix. En réalité, j’ai eu une question très directe :
Puisque tu mets en avant la confidentialité, pourquoi ne pas tout simplement tout faire avec des transactions privées ?
Transparence d’un côté, confidentialité de l’autre… ça ne fait pas doublon ?
Plus tard, en relisant attentivement le livre blanc, j’ai au contraire l’impression que ce côté « bancal » est peut-être ce qui s’approche le plus de la finance réelle.
Moonlight est plutôt simple : il fonctionne sur un modèle de comptes, similaire à Ethereum. Les éléments comme le solde, le nonce et l’état des transactions sont publics, et la transaction repose sur une vérification par signature.
Phoenix repose sur une logique totalement différente.
Il s’agit d’un modèle UTXO, qui introduit des stealth addresses, des nullifiers et des preuves à divulgation nulle de connaissance (ZK). Le réseau n’a pas besoin de voir directement quelle transaction tu fais, ni ton solde : il lui suffit de vérifier la preuve ZK. Ainsi, il peut confirmer que tu possèdes bien les actifs, que le solde est suffisant, qu’il n’y a pas de double dépense, et que la transaction n’a pas été falsifiée.
À première vue, on dirait qu’on complique le système.
Mais la finance, dans la réalité, n’est pas non plus un « niveau d’accès » unique.
Pour les dépôts et retraits en bourse, un compte public peut être plus adapté.
Entre institutions, les transferts de titres, les positions d’actifs et les transactions clients, eux, peuvent nécessiter de la confidentialité.
Et lors des audits, il faut pourtant pouvoir divulguer.
Si on force toute activité dans un seul modèle de transaction, on finit soit avec une confidentialité insuffisante, soit avec une conformité difficile à assurer.
C’est pourquoi Moonlight + Phoenix me donne l’impression d’être comme une banque où coexistent à la fois un « hall » et un « coffre-fort ».
Dans le hall, il n’est pas nécessaire de tout cacher.
Dans le coffre-fort, il n’y a pas lieu d’exposer les informations au public.
L’enjeu n’est donc pas d’être entièrement transparent ou entièrement privé : c’est d’utiliser des règles différentes pour des types d’argent différents.
Et ça explique aussi pourquoi Dusk, aujourd’hui, continue à développer à la fois un L1 natif et, en parallèle, DuskEVM et Hedger. DuskEVM propose aux développeurs Solidity un parcours EVM familier, tandis que Hedger s’appuie ensuite sur le chiffrement homomorphe et les preuves à divulgation nulle pour compléter des flux de transactions confidentielles.
À titre personnel, je trouve même que cette trajectoire est plus réaliste que l’idée selon laquelle « tous les développeurs doivent absolument réapprendre tout un nouveau système ».
Bien sûr, le problème est évident aussi.
Plus il y a de modules, plus le système devient complexe. Native L1, DuskEVM, Hedger, Dusk Trade : pourront-ils vraiment former une boucle fermée, au lieu que quatre produits racontent chacun leur histoire ? C’est précisément ce point que je continuerai à surveiller.
$DUSK #dusk
Puisque tu mets en avant la confidentialité, pourquoi ne pas tout simplement tout faire avec des transactions privées ?
Transparence d’un côté, confidentialité de l’autre… ça ne fait pas doublon ?
Plus tard, en relisant attentivement le livre blanc, j’ai au contraire l’impression que ce côté « bancal » est peut-être ce qui s’approche le plus de la finance réelle.
Moonlight est plutôt simple : il fonctionne sur un modèle de comptes, similaire à Ethereum. Les éléments comme le solde, le nonce et l’état des transactions sont publics, et la transaction repose sur une vérification par signature.
Phoenix repose sur une logique totalement différente.
Il s’agit d’un modèle UTXO, qui introduit des stealth addresses, des nullifiers et des preuves à divulgation nulle de connaissance (ZK). Le réseau n’a pas besoin de voir directement quelle transaction tu fais, ni ton solde : il lui suffit de vérifier la preuve ZK. Ainsi, il peut confirmer que tu possèdes bien les actifs, que le solde est suffisant, qu’il n’y a pas de double dépense, et que la transaction n’a pas été falsifiée.
À première vue, on dirait qu’on complique le système.
Mais la finance, dans la réalité, n’est pas non plus un « niveau d’accès » unique.
Pour les dépôts et retraits en bourse, un compte public peut être plus adapté.
Entre institutions, les transferts de titres, les positions d’actifs et les transactions clients, eux, peuvent nécessiter de la confidentialité.
Et lors des audits, il faut pourtant pouvoir divulguer.
Si on force toute activité dans un seul modèle de transaction, on finit soit avec une confidentialité insuffisante, soit avec une conformité difficile à assurer.
C’est pourquoi Moonlight + Phoenix me donne l’impression d’être comme une banque où coexistent à la fois un « hall » et un « coffre-fort ».
Dans le hall, il n’est pas nécessaire de tout cacher.
Dans le coffre-fort, il n’y a pas lieu d’exposer les informations au public.
L’enjeu n’est donc pas d’être entièrement transparent ou entièrement privé : c’est d’utiliser des règles différentes pour des types d’argent différents.
Et ça explique aussi pourquoi Dusk, aujourd’hui, continue à développer à la fois un L1 natif et, en parallèle, DuskEVM et Hedger. DuskEVM propose aux développeurs Solidity un parcours EVM familier, tandis que Hedger s’appuie ensuite sur le chiffrement homomorphe et les preuves à divulgation nulle pour compléter des flux de transactions confidentielles.
À titre personnel, je trouve même que cette trajectoire est plus réaliste que l’idée selon laquelle « tous les développeurs doivent absolument réapprendre tout un nouveau système ».
Bien sûr, le problème est évident aussi.
Plus il y a de modules, plus le système devient complexe. Native L1, DuskEVM, Hedger, Dusk Trade : pourront-ils vraiment former une boucle fermée, au lieu que quatre produits racontent chacun leur histoire ? C’est précisément ce point que je continuerai à surveiller.
$DUSK #dusk