Analyse approfondie des goulets d'étranglement technologiques des DEX à carnet de commandes principaux : pourquoi "l'architecture hybride" pourrait être la réponse finale ?

Auteur : Alex

De la "courbe de prix" de l'AMM aux "carnets d'ordres" d'achat et de vente, il ne s'agit pas seulement d'un changement d'interface utilisateur, mais d'une étape clé dans l'évolution des DEX, passant d'un "paradis pour les petits investisseurs" à un "marché de trading professionnel". Le carnet d'ordres, avec sa précision dans la découverte des prix et son efficacité capitalistique extrême, est largement considéré comme l'avenir des DEX.

Cependant, une réalité brutale est que presque tous les DEX à livre de commandes mainstream ont rencontré un mur invisible dans leur mise en œuvre technique. Ils ont été contraints de faire un compromis douloureux entre performance, coût et sécurité pour "décentraliser" un produit intrinsèquement centralisé comme le livre de commandes.

Pour comprendre l'avenir des DEX, nous devons d'abord analyser en profondeur les principales voies de réalisation, ainsi que les goulots d'étranglement technologiques auxquels elles sont confrontées.

Chemin 1 : La "tragédie de la performance" du carnet de commandes purement on-chain

Représentants typiques : les premiers Serum (basés sur Solana), ainsi que quelques DEX natifs sur L2.

Mode de réalisation : Toutes les logiques de stockage, d'ordres, d'annulations, de correspondance, etc. de l'ensemble du livre d'ordres sont entièrement exécutées dans un contrat intelligent sur la chaîne.

Bottleneck technique :

Plafond de performance : c'est le goulot d'étranglement le plus mortel. Peu importe à quel point le TPS de la blockchain sous-jacente est élevé, il ne peut pas répondre aux exigences des opérations "millisecondes" sur le carnet de commandes pour le trading à haute fréquence. Chaque interaction nécessite d'attendre la confirmation du bloc, ce qui est inacceptable dans le trading professionnel.

Coûts élevés : Chaque ordre placé ou annulé nécessite le paiement de frais de Gas. Cela représente un coût astronomique pour les market makers et les traders haute fréquence qui doivent ajuster fréquemment leurs offres, ce qui limite fondamentalement l'approvisionnement en liquidités.

Zone de catastrophe MEV : Tous les ordres sont publiés en tant que transactions dans la mémoire tampon (Mempool), créant un "terrain de chasse" parfait pour les robots MEV pour des attaques de frontrunning et de sandwich.

Chemin deux : Les "inquiétudes de sécurité" du livre de commandes de la chaîne d'application

Représentants typiques : dYdX v4, Hyperliquid

Mode de réalisation : Afin de se libérer complètement des contraintes de performance des chaînes publiques, construire à partir de zéro une chaîne d'application (Appchain) indépendante, née pour les transactions.

Bottleneck technologique :

Réduction de la dimension du modèle de sécurité : c'est son compromis central. Sa sécurité, qui est assurée par la "sécurité partagée" garantie par des chaînes publiques comme Ethereum, est réduite à la "sécurité souveraine" garantie par son propre réseau de validateurs. Cela signifie que le plafond de sa sécurité est limité par la capitalisation boursière de son propre jeton et le degré de décentralisation de ses validateurs, créant ainsi un "plafond de confiance".

Île écologique : La rupture avec l'écosystème principal entraîne une modularité presque nulle, et les entrées et sorties d'actifs dépendent fortement de la sécurité du pont inter-chaînes.

« Architecture hybride » : le « coup de génie » d'une déconstruction et reconstruction.

Lorsque ces deux voies se retrouvent dans leur propre "cul-de-sac", une troisième voie, plus élégante et plus logique, émerge. C'est ce qu'on appelle l'"architecture hybride" représentée par QuBitDEX.

Ce n'est pas un compromis, mais une déconstruction et une reconstruction profondes de l'acte de "trading" basé sur les premiers principes. Cela pose une question fondamentale : dans l'ensemble du processus de trading, quelles étapes doivent être garanties par la blockchain, et lesquelles ne le doivent pas ?

La réponse est :

"Processus" recherchant l'efficacité : La soumission, la correspondance et la mise à jour des commandes constituent un processus à haute fréquence et en constante évolution. Ce processus vise une efficacité maximale. Par conséquent, il est placé dans un moteur de correspondance hors chaîne performant. Cela résout fondamentalement les "maux de performance" et les "maux de coût".

"Résultat" recherche la sécurité : le règlement final des transactions et la livraison des actifs sont des résultats peu fréquents, mais qui doivent garantir une sécurité absolue et une immutabilité. Ce résultat vise une sécurité et une finalité extrêmes. Ainsi, il est ancré sur la couche de règlement de la chaîne la plus sécurisée grâce à des technologies telles que ZK-Rollup. Cela résout fondamentalement le "souci de la sécurité".

L'essence de l'"architecture hybride" est un parfait "partage des tâches professionnelles". Elle permet à la blockchain de revenir à ce qu'elle sait faire le mieux et ce qu'elle devrait faire - devenir une "couche de règlement final" décentralisée et sans confiance et une "cour des faits", plutôt qu'un "serveur universel" maladroit qui tente de tout gérer.

Ce n'est plus une nouvelle itération technique. C'est un saut de pensée. Cela nous fait comprendre que l'avenir des DEX ne réside pas dans l'utilisation de chaînes plus puissantes pour "supporter" les exigences de performance du livre de commandes, mais dans l'utilisation d'architectures plus intelligentes pour "décomposer" les besoins du livre de commandes.

Et cela, peut-être, est la réponse finale que nous pouvons envisager pour les DEX à livre de commandes.