Je pensais que le navigateur pouvait générer une preuve de confidentialité en moins de 2 secondes, et que le problème de performance adopté par l’organisation serait alors en grande partie réglé. Après avoir re-trié les articles Hedger de @Dusk et l’état du produit aujourd’hui, je suis au contraire plus prudent : un joli benchmark ponctuel ne prouve pas que l’authentification, la compensation et l’audit d’autorisation sont déjà prêts pour un SLA de production engageant.
Il faut replacer cette contradiction dans un vrai flux de travail. Quand une institution soumet un ordre obligataire ou de fonds, elle ne veut pas divulguer les soldes, quantités, positions et intentions de transaction à l’ensemble du marché ; mais l’émetteur ou l’auditeur doit, lui, confirmer que la transaction est valide, que les participants sont qualifiés, et obtenir au besoin des preuves contrôlées. L’ancre technique principale de Hedger consiste à traiter des données chiffrées via un chiffrement homomorphe sans exposer les valeurs, puis à vérifier que le calcul est correct à l’aide d’une preuve à connaissance nulle, afin d’obtenir pour l’application DuskEVM un chemin de transactions confidentielles vérifiables.
Un article officiel de Dusk en 2025 a déjà indiqué que des circuits légers peuvent générer des preuves « inférieures à 2 secondes » côté navigateur. Cette donnée est importante : elle réfute le jugement grossier selon lequel toutes les interactions ZK seraient nécessairement trop lentes pour être utilisables, et montre que les preuves côté client pourraient se rapprocher de l’expérience d’attente des applications financières ordinaires.
Mais cela ne répond pas à quatre questions de production : sur du matériel bas de gamme, est-ce que c’est encore stable ? lorsque le parallélisme des ordres augmente, la latence en bout de chaîne devient-elle incontrôlable ? combien de calculs seront ajoutés par différents contrats et des règles plus complexes ? en cas d’échec de la preuve, peut-on récupérer sans que l’utilisateur doive reprendre tout le flux depuis le début.
Le point le plus clé : le temps de preuve n’est pas le temps de règlement. La documentation de DuskEVM décompose clairement le processus : la transaction est d’abord soumise au sequencer ; ensuite, le batcher publie les données sur DuskDS, et les engagements d’état ainsi que les fault proofs connectent ensuite les résultats à DuskDS pour le règlement. La documentation rappelle explicitement que l’inclusion et le settlement sont deux étapes distinctes : lorsqu’il y a de la valeur à travers des couches, il faut lire l’état du protocole ou du portefeuille, plutôt que d’inférer la finalité à partir du temps écoulé.
$DUSK délimite clairement l’usage officiel actuel : la transaction paie le gas, le staking protège le réseau. Hedger ne fera payer son coût de confidentialité sur la chaîne que si le passage des fonctionnalités de test à des tâches financières exécutées en continu se produit ; sinon, les 2 secondes restent une entrée de laboratoire, pas une preuve d’exigence.
Pensez-vous que la confidentialité au niveau institutionnel bloque d’abord à la latence de fin de file de la preuve A, l’exploitation et l’audit d’autorisation B, ou bien l’intégration dans une application réelle C ?#dusk
Il faut replacer cette contradiction dans un vrai flux de travail. Quand une institution soumet un ordre obligataire ou de fonds, elle ne veut pas divulguer les soldes, quantités, positions et intentions de transaction à l’ensemble du marché ; mais l’émetteur ou l’auditeur doit, lui, confirmer que la transaction est valide, que les participants sont qualifiés, et obtenir au besoin des preuves contrôlées. L’ancre technique principale de Hedger consiste à traiter des données chiffrées via un chiffrement homomorphe sans exposer les valeurs, puis à vérifier que le calcul est correct à l’aide d’une preuve à connaissance nulle, afin d’obtenir pour l’application DuskEVM un chemin de transactions confidentielles vérifiables.
Un article officiel de Dusk en 2025 a déjà indiqué que des circuits légers peuvent générer des preuves « inférieures à 2 secondes » côté navigateur. Cette donnée est importante : elle réfute le jugement grossier selon lequel toutes les interactions ZK seraient nécessairement trop lentes pour être utilisables, et montre que les preuves côté client pourraient se rapprocher de l’expérience d’attente des applications financières ordinaires.
Mais cela ne répond pas à quatre questions de production : sur du matériel bas de gamme, est-ce que c’est encore stable ? lorsque le parallélisme des ordres augmente, la latence en bout de chaîne devient-elle incontrôlable ? combien de calculs seront ajoutés par différents contrats et des règles plus complexes ? en cas d’échec de la preuve, peut-on récupérer sans que l’utilisateur doive reprendre tout le flux depuis le début.
Le point le plus clé : le temps de preuve n’est pas le temps de règlement. La documentation de DuskEVM décompose clairement le processus : la transaction est d’abord soumise au sequencer ; ensuite, le batcher publie les données sur DuskDS, et les engagements d’état ainsi que les fault proofs connectent ensuite les résultats à DuskDS pour le règlement. La documentation rappelle explicitement que l’inclusion et le settlement sont deux étapes distinctes : lorsqu’il y a de la valeur à travers des couches, il faut lire l’état du protocole ou du portefeuille, plutôt que d’inférer la finalité à partir du temps écoulé.
$DUSK délimite clairement l’usage officiel actuel : la transaction paie le gas, le staking protège le réseau. Hedger ne fera payer son coût de confidentialité sur la chaîne que si le passage des fonctionnalités de test à des tâches financières exécutées en continu se produit ; sinon, les 2 secondes restent une entrée de laboratoire, pas une preuve d’exigence.
Pensez-vous que la confidentialité au niveau institutionnel bloque d’abord à la latence de fin de file de la preuve A, l’exploitation et l’audit d’autorisation B, ou bien l’intégration dans une application réelle C ?#dusk
