Profundidad拆解主流订单簿DEX的技术瓶颈：为什么“混合架构”可能是最终答案？

Autor: Alex

Desde la "curva de precios" de AMM hasta el "libro de órdenes" de la oferta y demanda, esto no es solo un cambio en la interfaz de usuario, sino un paso clave en la evolución de DEX de un "paraíso para minoristas" a un "mercado de trading profesional". El libro de órdenes, con su precisión en el descubrimiento de precios y su máxima eficiencia de capital, se considera ampliamente el futuro de DEX.

Sin embargo, una cruel realidad es que casi todos los DEX de libro de órdenes principales se han encontrado con una "pared" invisible en su implementación técnica. Para descentralizar este producto intrínsecamente centralizado que es el libro de órdenes, se han visto obligados a hacer un doloroso compromiso entre rendimiento, costo y seguridad.

Para entender el futuro de DEX, primero debemos desglosar en profundidad estas rutas de implementación principales y los cuellos de botella técnicos que enfrentan.

Ruta uno: la "tragedia del rendimiento" del libro de órdenes puramente en cadena.

Representantes típicos: Serum en sus primeras etapas (basado en Solana) y algunos DEX nativos en L2.

Método de implementación: Toda la lógica de almacenamiento del libro de órdenes, órdenes abiertas, cancelaciones, emparejamiento, etc., se ejecuta completamente en un contrato inteligente en la cadena.

Barrera tecnológica:

Límite de rendimiento: este es el cuello de botella más fatal. No importa cuán alto sea el TPS de la cadena pública subyacente, no puede satisfacer la demanda de operaciones "en milisegundos" en el libro de órdenes para el trading de alta frecuencia. Cada interacción requiere esperar la confirmación del bloque, lo cual es inaceptable en el trading profesional.

Costos elevados: Cada orden de compra y venta requiere el pago de tarifas de Gas. Esto representa un costo astronómico para los creadores de mercado y los traders de alta frecuencia que necesitan ajustar sus cotizaciones con frecuencia, lo que inhibe fundamentalmente la oferta de liquidez.

Zona de desastre de MEV: todos los pedidos se publican como transacciones en el pool de memoria (Mempool), creando el lugar perfecto para que los bots de MEV realicen ataques de front-running y sándwich.

Ruta dos: "Preocupaciones de seguridad" del libro de órdenes de la cadena de aplicaciones

Representantes típicos: dYdX v4, Hyperliquid

Método de implementación: Para liberarse por completo de las limitaciones de rendimiento de las cadenas públicas, se construye desde cero una cadena de aplicaciones (Appchain) independiente, diseñada para transacciones.

Cuello de botella técnico:

Reducción de dimensiones del modelo de seguridad: Este es su compromiso central. Su seguridad, que se basa en la "seguridad compartida" garantizada por cadenas públicas como Ethereum, se reduce a la "seguridad soberana" garantizada por su propia red de validadores. Esto significa que el límite superior de su seguridad está condicionado por la capitalización de mercado de su propio token y por el grado de descentralización de los validadores, lo que conlleva un "techo de confianza".

Islote ecológico: La separación del ecosistema principal resulta en que su combinabilidad sea casi cero, y la entrada y salida de activos depende en gran medida de la seguridad de los puentes entre cadenas.

"Arquitectura Híbrida": un toque de genio en la deconstrucción y reestructuración.

Cuando ambos caminos anteriores se encuentran en sus respectivos "callejones sin salida", surge un tercer camino más elegante y lógico. Este es el "arquitectura híbrida" representada por QuBitDEX.

No es un compromiso, sino una profunda deconstrucción y reorganización del acto de "transacción" basada en principios fundamentales. Se plantea una pregunta fundamental: ¿qué etapas del proceso de transacción deben ser garantizadas por la blockchain y cuáles no?

La respuesta es:

"Proceso" busca eficiencia: la presentación, coincidencia y actualización de pedidos es un proceso de alta frecuencia y rápido cambio. Este proceso busca la máxima eficiencia. Por lo tanto, se coloca en un potente motor de emparejamiento fuera de la cadena. Esto, en esencia, resuelve los problemas de "rendimiento" y "coste".

"Resultados" persiguen la seguridad: El asentamiento final de las transacciones y la entrega de activos es un proceso de baja frecuencia, pero debe garantizar un resultado absolutamente seguro e inmutable. Este resultado busca la máxima seguridad y finalización. Por lo tanto, se asegura a través de tecnologías como ZK-Rollup en la capa de asentamiento más segura de la cadena. Esto resuelve fundamentalmente la "preocupación por la seguridad".

La esencia de la "arquitectura híbrida" es una perfecta "división del trabajo". Permite que la blockchain regrese a lo que mejor sabe hacer y lo que debería hacer: convertirse en una "capa de liquidación final" y un "tribunal de hechos" descentralizado y sin necesidad de confianza, en lugar de ser un "servidor universal" torpe que intenta manejarlo todo.

Esto ya no es otra iteración técnica. Es un salto mental. Nos hace entender que el futuro de DEX no radica en usar cadenas más potentes para "soportar" las demandas de rendimiento del libro de órdenes, sino en utilizar arquitecturas más inteligentes para "descomponer" las necesidades del libro de órdenes.

Y esto, quizás, sea la respuesta final que podemos prever para un DEX de libro de órdenes.