Il y a quelque temps, je suis tombé sur cette phrase dans une page publicitaire : « une preuve en 2 secondes ». Je suis resté bloqué. Le texte est agencé avec une taille deux fois plus grande que celle de la description à côté, mais il ne précise pas à quelle étape correspondent ces 2 secondes. Quand je lis ce genre de chiffres, j’ai l’habitude de demander d’abord : 2 secondes pour quelle étape ? Ceux qui ont déjà utilisé la fonction de confidentialité savent que la preuve n’est qu’une case dans toute la transaction. Avant, le portefeuille doit se synchroniser ; ensuite, la transaction doit être enregistrée on-chain. Aucune de ces cases n’avance plus vite. Sans ancrer un chiffre dans un périmètre clair, plus il est mis en avant, plus il mérite d’être disséqué.
En regardant la documentation officielle, j’ai aussi fait le test avec un portefeuille moi-même. Il est écrit que la génération de la preuve côté navigateur prend moins de 2 secondes : ce libellé ne laisse pas vraiment de marge d’interprétation. Si l’on isole cette case, en réalité, 2 secondes est le chiffre le plus honnête de toute la chaîne. J’ai testé un transfert : l’étape navigateur donne un résultat après deux « tours », ce qui correspond globalement à la formulation sur le papier @Dusk . L’engagement de la première case est tenu sans réduction, mais pour les comptes situés hors de cette première case, on ne retrouve pas de chiffre prêt à l’emploi dans la page.
Le problème vient des deux autres cases. La synchronisation du portefeuille engloutit 3 secondes : et ça, ce n’est même pas le pire. Je fixe le nombre de tours affiché dans la barre d’état ; la troisième seconde passe, et le tour continue de tourner. La vraie attente, elle, se fait au moment de l’enregistrement on-chain : pour chaque transfert, il faut attendre la confirmation finale, et 40 minutes est la norme ; on n’a pas forcément vu aussi que ce soit sans cas où ça déborde sur le lendemain. Pendant cette attente, j’ai compté le nombre de fois où la hauteur de bloc change ; plus je comptais, plus je comprenais que l’attente n’a strictement rien d’édulcoré. En décomposant le temps total soi-même, on voit que les « 2 secondes » dans le bilan temporel ne représentent au fond qu’une petite fraction, presque négligeable. Les deux cases additionnées correspondent à l’attente réelle ressentie par l’utilisateur : la page publicitaire n’a retenu que la première case. Ce qui manque, ce n’est pas la performance : c’est le périmètre.
À partir de là, j’ai enfin compris l’enjeu : la page publicitaire ne ment pas, elle prend seulement la plus petite case pour en faire l’ensemble. La réponse à « c’est rapide ou pas » se cache aux limites du périmètre. Pour juger si une transaction de confidentialité vaut le coup, la réponse ne dépend pas de la taille du chiffre : il faut d’abord voir où est tracée la frontière. Ce jugement vaut plus que le chiffre lui-même, et tient mieux dans le temps que n’importe quelle image promotionnelle. $DUSK
Revenons à la phrase du début : « une preuve en 2 secondes ». Ce chiffre n’appartient qu’à ce petit pas dans le navigateur, mais vous le prenez comme l’engagement de toute la transaction. Le chiffre de la page publicitaire n’est pas le temps que vous attendez. L’équation n’est pas compliquée ; ce qui est difficile, c’est de décider, avant d’ouvrir le portefeuille, de la calculer d’abord une fois. #dusk
En regardant la documentation officielle, j’ai aussi fait le test avec un portefeuille moi-même. Il est écrit que la génération de la preuve côté navigateur prend moins de 2 secondes : ce libellé ne laisse pas vraiment de marge d’interprétation. Si l’on isole cette case, en réalité, 2 secondes est le chiffre le plus honnête de toute la chaîne. J’ai testé un transfert : l’étape navigateur donne un résultat après deux « tours », ce qui correspond globalement à la formulation sur le papier @Dusk . L’engagement de la première case est tenu sans réduction, mais pour les comptes situés hors de cette première case, on ne retrouve pas de chiffre prêt à l’emploi dans la page.
Le problème vient des deux autres cases. La synchronisation du portefeuille engloutit 3 secondes : et ça, ce n’est même pas le pire. Je fixe le nombre de tours affiché dans la barre d’état ; la troisième seconde passe, et le tour continue de tourner. La vraie attente, elle, se fait au moment de l’enregistrement on-chain : pour chaque transfert, il faut attendre la confirmation finale, et 40 minutes est la norme ; on n’a pas forcément vu aussi que ce soit sans cas où ça déborde sur le lendemain. Pendant cette attente, j’ai compté le nombre de fois où la hauteur de bloc change ; plus je comptais, plus je comprenais que l’attente n’a strictement rien d’édulcoré. En décomposant le temps total soi-même, on voit que les « 2 secondes » dans le bilan temporel ne représentent au fond qu’une petite fraction, presque négligeable. Les deux cases additionnées correspondent à l’attente réelle ressentie par l’utilisateur : la page publicitaire n’a retenu que la première case. Ce qui manque, ce n’est pas la performance : c’est le périmètre.
À partir de là, j’ai enfin compris l’enjeu : la page publicitaire ne ment pas, elle prend seulement la plus petite case pour en faire l’ensemble. La réponse à « c’est rapide ou pas » se cache aux limites du périmètre. Pour juger si une transaction de confidentialité vaut le coup, la réponse ne dépend pas de la taille du chiffre : il faut d’abord voir où est tracée la frontière. Ce jugement vaut plus que le chiffre lui-même, et tient mieux dans le temps que n’importe quelle image promotionnelle. $DUSK
Revenons à la phrase du début : « une preuve en 2 secondes ». Ce chiffre n’appartient qu’à ce petit pas dans le navigateur, mais vous le prenez comme l’engagement de toute la transaction. Le chiffre de la page publicitaire n’est pas le temps que vous attendez. L’équation n’est pas compliquée ; ce qui est difficile, c’est de décider, avant d’ouvrir le portefeuille, de la calculer d’abord une fois. #dusk