Dans les communiqués officiels, on vante sans cesse que, grâce à zkSync Hyperchain, on peut obtenir des réponses de transactions à un niveau extrême, en millisecondes (voir même sub-millisecondes). On dirait presque que ça va “aller sur la lune”. Mais en allant directement consulter la documentation de l’architecture sous-jacente, j’ai découvert que la plupart des gens se sont fait avoir par des tours de passe-passe consistant à détourner des concepts. La soi-disant “vitesse ultra-rapide” de la part du projet ne concerne en réalité que le temps de réponse de leur moteur de matching centralisé hors chaîne. Ce n’est absolument pas la même chose que la latence de règlement sur une vraie blockchain.
Une fois qu’une transaction a été matchée avec succès via le moteur centralisé, elle doit être empaquetée en une racine d’état et une preuve de connaissance zéro (ZKP) doit être générée, avant d’être synchronisée de manière asynchrone avec l’AppChain. Lors de mes backtests techniques, ce qui m’intéresse le plus, c’est précisément cet écart de temps. En cas de fortes fluctuations sur le marché, des milliers d’agents IA et de robots de trading quantitatifs lancent en même temps des requêtes haut débit et en concurrence vers l’AppChain ; en conséquence, la latence de réponse des nœuds RPC au niveau inférieur augmente de façon exponentielle.
À ce moment-là, le prix de matching hors chaîne et la véritable racine d’état on-chain ne correspondent plus du tout. Si, à cause de la forte concurrence, la chaîne cible “se bloque” au moment de la confirmation des blocs, côté front-end l’utilisateur peut croire que ses transactions ont abouti, alors qu’en réalité, sur la chaîne, elles restent dans un état non confirmé, en “free-fall” sans protection. Habiller le “côté rapide” du matching hors chaîne pour le faire passer pour un “côté stable” de l’infrastructure d’une blockchain publique : ce genre de promesse technique, au moment où le marché devient un broyeur à gros volumes, peut provoquer des blocages dus à la latence élevée, et faire exploser instantanément les comptes des utilisateurs très fortement levier. #grvt @grvt_io
Une fois qu’une transaction a été matchée avec succès via le moteur centralisé, elle doit être empaquetée en une racine d’état et une preuve de connaissance zéro (ZKP) doit être générée, avant d’être synchronisée de manière asynchrone avec l’AppChain. Lors de mes backtests techniques, ce qui m’intéresse le plus, c’est précisément cet écart de temps. En cas de fortes fluctuations sur le marché, des milliers d’agents IA et de robots de trading quantitatifs lancent en même temps des requêtes haut débit et en concurrence vers l’AppChain ; en conséquence, la latence de réponse des nœuds RPC au niveau inférieur augmente de façon exponentielle.
À ce moment-là, le prix de matching hors chaîne et la véritable racine d’état on-chain ne correspondent plus du tout. Si, à cause de la forte concurrence, la chaîne cible “se bloque” au moment de la confirmation des blocs, côté front-end l’utilisateur peut croire que ses transactions ont abouti, alors qu’en réalité, sur la chaîne, elles restent dans un état non confirmé, en “free-fall” sans protection. Habiller le “côté rapide” du matching hors chaîne pour le faire passer pour un “côté stable” de l’infrastructure d’une blockchain publique : ce genre de promesse technique, au moment où le marché devient un broyeur à gros volumes, peut provoquer des blocages dus à la latence élevée, et faire exploser instantanément les comptes des utilisateurs très fortement levier. #grvt @grvt_io