Hoja de ruta del ICM de Solana: un "espectáculo de imitaciones" dirigido a Hyperliquid
Introducción: Los grandes de Solana se reúnen
Recientemente, ocurrió algo interesante en el ecosistema de Solana. Importantes miembros, incluyendo la Fundación Solana, Anza y un conocido laboratorio, se reunieron para publicar una hoja de ruta técnica llamada "Internet Capital Markets (Internet Capital Markets, ICM )". El concepto central de esta hoja de ruta es "Application Controlled Execution (ACE )", en términos simples, se trata de otorgar a las aplicaciones en cadena el derecho de ordenar transacciones de forma autónoma en milisegundos, creando una "Wall Street en cadena" descentralizada.
Curiosamente, al leer todo el mapa de ruta, aunque no se menciona directamente a Hyperliquid, el diseño está casi en todas partes dirigido a las fortalezas de Hyperliquid. Es como si Solana dijera: "¡Lo que tiene Hyperliquid, nosotros también queremos tenerlo, y hacerlo mejor!"
Hay que saber que Hyperliquid ocupa una posición dominante en el mercado de contratos perpetuos en cadena, con un volumen de operaciones que llegó a representar alrededor del 65% de todo el mercado descentralizado de contratos perpetuos. Está claro que, frente a competidores así, Solana no está dispuesta a ser superada por los recién llegados, por lo que lanzó este mapa de ruta ICM.
Entonces, ¿qué es exactamente este "show de imitaciones"? ¿Puede Solana realmente alcanzar e incluso superar a Hyperliquid? Hoy vamos a profundizar en este tema.
Fondo y contenido de ICM
¿Quién está liderando esta transformación?
Primero, veamos quién elaboró este mapa de ruta. Los participantes son todos jugadores de peso del ecosistema Solana:
Fundación/Labs Solana: esto no necesita mucha explicación, el "papá" de Solana, responsable de la coordinación general y el desarrollo del protocolo central.
Anza: una empresa de desarrollo fundada por exmiembros de Solana Labs, similar a ConsenSys de Ethereum. Ellos se encargaron de muchas de las tareas clave en esta hoja de ruta, como el nuevo protocolo de consenso Alpenglow.
Un laboratorio conocido: el proveedor de infraestructura MEV en Solana, con una gran influencia, casi controla todo el flujo MEV en Solana y tiene el "poder de vida y muerte". Esta vez, lideran la provisión del Block Assembly Marketplace (BAM) y otros esquemas de ordenamiento de transacciones.
Cierto capital conocido: una famosa institución de inversión en criptomonedas, también es uno de los primeros patrocinadores de Solana. Debido a su posesión de una gran cantidad de SOL y derechos sobre proyectos ecológicos, también tiene un considerable poder de decisión en la dirección técnica.
DoubleZero: un equipo enfocado en acelerar la comunicación en red, que ofrece soluciones de red de fibra óptica dedicadas para mejorar la velocidad de comunicación entre los nodos de validación de Solana.
Una plataforma de contratos perpetuos: el proyecto DEX de contratos perpetuos líder en Solana. Anteriormente, esta plataforma utilizaba un modelo de emparejamiento fuera de la cadena, lo que resultaba un poco difícil al enfrentarse a Hyperliquid completamente en la cadena. Esta vez, participar en la elaboración de la hoja de ruta es claramente un intento de aprovechar la actualización de la capa base para dar un giro.
el problema central a resolver
El enfoque del roadmap es la mejora de la microestructura del mercado. En pocas palabras, el actual mecanismo de transacciones en cadena no es lo suficientemente amigable para los Market Makers, es decir, los que colocan órdenes de espera para ser ejecutadas, mientras que los Takers, que inician activamente las transacciones, se benefician. Esto se debe a que los Takers a menudo tienen la información más reciente y aumentan proactivamente las tarifas de transacción para garantizar que sus transacciones se ejecuten con prioridad, mientras que los Makers a menudo no tienen tiempo para retirar sus órdenes y se ven obligados a ejecutar a precios desfavorables.
Algunos arbitrajistas de alta frecuencia aprovecharán esta asimetría para lanzar ataques de "tráfico tóxico". Por ejemplo, si el precio en la cadena aún no se ha actualizado, pero el precio fuera de la cadena ya ha cambiado, el arbitrajista podrá aprovechar el viejo precio para ejecutar las órdenes de los creadores de mercado, haciendo que estos últimos asuman las pérdidas. El resultado es que el Maker, para protegerse, tendrá que ampliar el diferencial entre compra y venta o reducir la cantidad de órdenes pendientes, lo que llevará a que la liquidez del mercado en su conjunto se vea afectada.
El roadmap de ICM busca equilibrar este patrón y atraer liquidez de alta calidad de vuelta a la cadena.
El plan de tres pasos de ICM
Solana ha dividido este gran plan en tres etapas:
Corto plazo (1-3 meses): principalmente optimizar la experiencia de transacciones en la cadena existente, hacer que las aplicaciones de libro de órdenes sean más útiles y reducir la interferencia maliciosa del MEV. Específicamente incluye:
Se lanza el módulo Block Assembly Marketplace (BAM) de un conocido laboratorio en la mainnet. El significado de este módulo es proporcionar un sistema externo temporal antes del lanzamiento del ACE (Ejecución Controlada por Aplicaciones) definitivo, permitiendo que los contratos inteligentes en Solana tengan autonomía en el orden de las transacciones.
El equipo de Anza optimizó la tasa de éxito de "entrar en el mismo Slot de negociación", reduciendo así el deslizamiento y las pérdidas de MEV.
Se espera que estas mejoras se implementen gradualmente entre julio y septiembre de 2025.
Medio plazo (3-9 meses): Introducción de una red de alta velocidad dedicada y una nueva versión de consenso, reduciendo drásticamente la latencia y aumentando el rendimiento:
Desplegar una red de fibra óptica dedicada de DoubleZero, proporcionando a los validadores una comunicación de alta velocidad con casi cero fluctuación y una reducción de la latencia de hasta 100 ms.
Se lanzó el protocolo de consenso Alpenglow, reduciendo el tiempo de confirmación final de aproximadamente 12.8 segundos a aproximadamente 0.15 segundos.
Desarrollo de la Ejecución de Programas Asíncronos ( Asynchronous Program Execution, APE ), reduce el bloqueo de la ejecución de transacciones en el consenso.
A largo plazo (9-30 meses): realizar una actualización revolucionaria de la arquitectura central de Solana, con el objetivo de lograrlo alrededor de 2027:
Varios Líderes Concurrentes (Multiple Concurrent Leaders, MCL): Permiten que varios validadores propongan transacciones simultáneamente en sus respectivos pipelines y luego ordenen estos bloques paralelos según la tarifa de prioridad. Esto debilita el monopolio de un único empaquetador y mejora la resistencia a la censura.
Ejecución controlada por la aplicación (, ACE ) función: otorga verdaderamente a los contratos inteligentes en la cadena el poder de controlar el orden de ejecución de las transacciones.
Analizando hasta aquí, el autor considera que la propuesta del mapa de ruta ICM tiene la siguiente historia detrás: el antiguo DEX en Solana fue superado por el recién llegado Hyperliquid debido a la "excelente experiencia de una plataforma de intercambio en cadena". El antiguo DEX, incapaz de competir, tuvo que pedir ayuda a los "grandes" como Solana Labs y Anza. Los "grandes" propusieron un plan de transformación técnica ICM, afirmando que replicarían las habilidades distintivas de Hyperliquid para equipar completamente al antiguo DEX, ayudándolo a volver a competir en el mercado de DEX. Sin embargo, los "grandes" también dijeron que esta transformación técnica es extremadamente difícil, por lo que dividieron el plan técnico en una estrategia de tres pasos, y el equipo que se puede proporcionar al antiguo DEX en el corto plazo es solo el BAM de un laboratorio conocido, para que el antiguo DEX pueda hacer frente y compararse temporalmente con Hyperliquid.
Habiendo aclarado el contexto de la historia, en los próximos capítulos, el autor analizará en detalle qué habilidades distintivas de Hyperliquid ha imitado y replicado ICM.
Imitación 1: Mecanismo de orden de transacciones
Problema: Como se mencionó anteriormente, la cadena actual favorece a los takers, mientras que los makers sufren el "flujo tóxico". Los usuarios que activamente toman órdenes pueden basarse en el precio más reciente fuera de la cadena para iniciar una transacción en las órdenes de la cadena al instante, y al aumentar las tarifas de transacción, pueden ser atendidos con prioridad, mientras que los creadores de mercado a menudo no tienen tiempo para actualizar o cancelar sus órdenes. El resultado es que los creadores de mercado deben ampliar el diferencial o simplemente retirar la liquidez, lo que empeora la profundidad del mercado.
La solución definitiva de ICM: aplicación de ejecución controlada ( ACE )
El roadmap de ICM propone el concepto de ACE (Application Controlled Execution), que delega el derecho de ordenar transacciones a las aplicaciones en cada cadena, permitiendo que cada aplicación decida cómo ordenar y ejecutar las transacciones relacionadas con ella. Por ejemplo, en el futuro, en Solana, que implementará ACE, los contratos DeFi podrán establecer las siguientes reglas personalizadas de ordenamiento de transacciones:
Actualización de precios del oráculo: las aplicaciones DeFi pueden insertar una transacción antes de que se realicen grandes operaciones para obtener el precio más reciente del oráculo, asegurando que las órdenes se ejecuten al precio razonable más reciente y evitando que las cotizaciones de los creadores de mercado se basen en precios desactualizados y sean objeto de arbitraje.
Prioridad de ejecución de cancelación de pedido: la aplicación puede establecer que la "solicitud de cancelación" tenga prioridad sobre la nueva "ejecución de orden de compra", permitiendo al maker retirar su orden a tiempo cuando el mercado es desfavorable.
Subasta en la cola del equipo: por ejemplo, después de que aparece una gran orden de compra que eleva el precio, la aplicación DeFi saca a subasta la oportunidad de "seguir inmediatamente"; quien esté dispuesto a devolver la mayor cantidad de beneficios al protocolo (o a los usuarios), el protocolo DeFi permitirá que su transacción se ejecute justo detrás de la gran orden. La aplicación DeFi puede devolver los ingresos de la subasta a los usuarios, convirtiendo así el tráfico MEV tóxico en ingresos benignos.
BAM de un laboratorio conocido: plan de transición
Antes del lanzamiento oficial de ACE, un conocido laboratorio presentó una solución de transición llamada Block Assembly Marketplace (BAM). El flujo de trabajo de BAM es:
El usuario envía la transacción a un nodo que ejecuta el software BAM (en lugar de enviarla directamente al líder actual).
Los nodos BAM recopilan transacciones locales y ejecutan varios plugins (plugin) para reordenar los paquetes de transacciones (Bundle) bajo protección de privacidad (los plugins se ejecutan en un entorno TEE seguro y ocultan el contenido de las transacciones antes de la ejecución). A través de los plugins, los desarrolladores de aplicaciones pueden personalizar diversas reglas de orden para sus contratos, como priorizar la cancelación de órdenes, actualizar el precio del oráculo antes de la coincidencia, e incluso ejecutar subastas complejas dentro de la aplicación.
El Bundle de transacciones ordenado se envía al Líder de Solana para ser empaquetado en la cadena.
BAM puede verse como un campo de pruebas antes de que ACE esté en la cadena, su funcionalidad es muy similar a la de ACE definitivo, solo que funciona en una red independiente fuera de la cadena, en lugar de estar incorporado en el protocolo de la cadena principal de Solana.
Es importante señalar que un conocido laboratorio había estado proporcionando infraestructura orientada a la extracción de MEV (como un motor de bloques), cuyo modelo de negocio consiste en crear oportunidades para los arbitrajistas mediante la optimización del orden de las transacciones y compartir los beneficios. Esto, en cierta medida, representa una "lanza" que se opone a los usuarios comunes y a aquellos que son objeto de arbitraje. Sin embargo, el laboratorio cerró a principios de 2024 la función de memoria pública para robots de arbitraje (mempool) para reducir externalidades negativas como los ataques de sándwich. Esta medida indica que la comunidad de Solana tiende a suprimir el MEV perjudicial y a mantener la equidad para los usuarios.
El lanzamiento de BAM sigue esta línea de pensamiento: en esencia, convierte el mecanismo de orden originalmente utilizado para el arbitraje de MEV en un "escudo" para proteger a los creadores de mercado y otros proveedores de liquidez, como forzar la retirada de órdenes prioritarias para evitar pérdidas a los creadores de mercado, e introducir reembolsos por pujas para reducir las ganancias de los que se adelantan. Los buscadores de MEV originales, si quieren ganar dinero, deben cambiar de rol y desarrollar complementos de BAM para servir a los protocolos DeFi, obteniendo ganancias a través de las tarifas de los complementos.
consultando a Hyperliquid
La idea de ACE/BAM mencionada anteriormente se puede considerar como una forma de alcanzar el mecanismo de emparejamiento en la cadena de Hyperliquid. Hyperliquid es una cadena dedicada (Appchain), creada específicamente para servir a DEX. Además, el HLP Vault, operado oficialmente por Hyperliquid, es en realidad uno de los mayores creadores de mercado de la plataforma, por lo que no es difícil entender que las reglas de la cadena de Hyperliquid tienden a favorecer a los proveedores de liquidez, habiendo implementado en la capa de la cadena muchos diseños que protegen a los creadores de mercado, tales como:
Prioridad en la protección de órdenes pendientes: las órdenes de cancelación y las órdenes de maker son procesadas con prioridad, evitando que los creadores de mercado sean afectados negativamente por transacciones desfavorables sin su conocimiento. La "ejecución prioritaria de cancelaciones" mencionada por Solana ACE ha sido practicada durante años por Hyperliquid.
Garantía de precio más reciente: El proceso de liquidación y emparejamiento de Hyperliquid enfatiza el uso de los precios de alimentación más recientes y el estado del margen para realizar una "doble verificación". Por ejemplo, cuando hay órdenes pendientes que se emparejan, el sistema vuelve a solicitar el precio del oráculo más reciente para evaluar el margen de ambas partes, asegurando que no haya riesgos debido a la desactualización de precios. Esto es similar a cómo ACE inserta actualizaciones del oráculo antes de ejecutar una operación.
Protección contra auto-negociación: Si la misma dirección compra y vende al mismo tiempo, Hyperliquid cancela automáticamente en lugar de emparejar, para evitar el lavado de operaciones o costos innecesarios.
El ACE/BAM de Solana ICM, sin duda, está "tomando nota" de Hyperliquid. Hyperliquid, como líder en CLOB en cadena, ha implementado una serie de mecanismos amigables para los creadores de mercado a través de una cadena exclusiva. Ahora, Solana espera replicar este efecto utilizando una cadena general y complementos modulares, es decir, permitir que cada aplicación tenga un control sobre el orden de las transacciones similar al de Hyperliquid.
Imitación dos: finalización instantánea
Comparación de consensos existentes
Solana actualmente utiliza Tower BFT, la confirmación y la finalización son probabilísticas y progresivas: un bloque recibe 2/3 de los votos y se considera "confirmado(Confirmed)", pero se necesitan acumular aproximadamente 32 bloques posteriores en la cadena (generalmente alrededor de 13 segundos) para ser anclado como "finalizado(Finalized)". Para ciertas aplicaciones (como el comercio de alta frecuencia), un tiempo de confirmación final de unos segundos sigue siendo demasiado largo.
HyperBFT es el algoritmo de consenso desarrollado por Hyperliquid, inspirado en el consenso HotStuff, que utiliza una confirmación de bloque de dos rondas de votación para lograr la "finalidad instantánea".
Primera ronda: Pre-voto (Prevote): Después de que el validador recibe el bloque candidato transmitido por el Proposer, realizará una verificación rápida. Si la verificación es exitosa, cada validador emitirá un voto de "pre-voto" (Prevote) para este bloque y lo transmitirá a toda la red. Este voto representa: "He revisado preliminarmente.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Solana ICM hoja de ruta vs Hyperliquid: batalla de transacciones on-chain
Hoja de ruta del ICM de Solana: un "espectáculo de imitaciones" dirigido a Hyperliquid
Introducción: Los grandes de Solana se reúnen
Recientemente, ocurrió algo interesante en el ecosistema de Solana. Importantes miembros, incluyendo la Fundación Solana, Anza y un conocido laboratorio, se reunieron para publicar una hoja de ruta técnica llamada "Internet Capital Markets (Internet Capital Markets, ICM )". El concepto central de esta hoja de ruta es "Application Controlled Execution (ACE )", en términos simples, se trata de otorgar a las aplicaciones en cadena el derecho de ordenar transacciones de forma autónoma en milisegundos, creando una "Wall Street en cadena" descentralizada.
Curiosamente, al leer todo el mapa de ruta, aunque no se menciona directamente a Hyperliquid, el diseño está casi en todas partes dirigido a las fortalezas de Hyperliquid. Es como si Solana dijera: "¡Lo que tiene Hyperliquid, nosotros también queremos tenerlo, y hacerlo mejor!"
Hay que saber que Hyperliquid ocupa una posición dominante en el mercado de contratos perpetuos en cadena, con un volumen de operaciones que llegó a representar alrededor del 65% de todo el mercado descentralizado de contratos perpetuos. Está claro que, frente a competidores así, Solana no está dispuesta a ser superada por los recién llegados, por lo que lanzó este mapa de ruta ICM.
Entonces, ¿qué es exactamente este "show de imitaciones"? ¿Puede Solana realmente alcanzar e incluso superar a Hyperliquid? Hoy vamos a profundizar en este tema.
Fondo y contenido de ICM
¿Quién está liderando esta transformación?
Primero, veamos quién elaboró este mapa de ruta. Los participantes son todos jugadores de peso del ecosistema Solana:
Fundación/Labs Solana: esto no necesita mucha explicación, el "papá" de Solana, responsable de la coordinación general y el desarrollo del protocolo central.
Anza: una empresa de desarrollo fundada por exmiembros de Solana Labs, similar a ConsenSys de Ethereum. Ellos se encargaron de muchas de las tareas clave en esta hoja de ruta, como el nuevo protocolo de consenso Alpenglow.
Un laboratorio conocido: el proveedor de infraestructura MEV en Solana, con una gran influencia, casi controla todo el flujo MEV en Solana y tiene el "poder de vida y muerte". Esta vez, lideran la provisión del Block Assembly Marketplace (BAM) y otros esquemas de ordenamiento de transacciones.
Cierto capital conocido: una famosa institución de inversión en criptomonedas, también es uno de los primeros patrocinadores de Solana. Debido a su posesión de una gran cantidad de SOL y derechos sobre proyectos ecológicos, también tiene un considerable poder de decisión en la dirección técnica.
DoubleZero: un equipo enfocado en acelerar la comunicación en red, que ofrece soluciones de red de fibra óptica dedicadas para mejorar la velocidad de comunicación entre los nodos de validación de Solana.
Una plataforma de contratos perpetuos: el proyecto DEX de contratos perpetuos líder en Solana. Anteriormente, esta plataforma utilizaba un modelo de emparejamiento fuera de la cadena, lo que resultaba un poco difícil al enfrentarse a Hyperliquid completamente en la cadena. Esta vez, participar en la elaboración de la hoja de ruta es claramente un intento de aprovechar la actualización de la capa base para dar un giro.
el problema central a resolver
El enfoque del roadmap es la mejora de la microestructura del mercado. En pocas palabras, el actual mecanismo de transacciones en cadena no es lo suficientemente amigable para los Market Makers, es decir, los que colocan órdenes de espera para ser ejecutadas, mientras que los Takers, que inician activamente las transacciones, se benefician. Esto se debe a que los Takers a menudo tienen la información más reciente y aumentan proactivamente las tarifas de transacción para garantizar que sus transacciones se ejecuten con prioridad, mientras que los Makers a menudo no tienen tiempo para retirar sus órdenes y se ven obligados a ejecutar a precios desfavorables.
Algunos arbitrajistas de alta frecuencia aprovecharán esta asimetría para lanzar ataques de "tráfico tóxico". Por ejemplo, si el precio en la cadena aún no se ha actualizado, pero el precio fuera de la cadena ya ha cambiado, el arbitrajista podrá aprovechar el viejo precio para ejecutar las órdenes de los creadores de mercado, haciendo que estos últimos asuman las pérdidas. El resultado es que el Maker, para protegerse, tendrá que ampliar el diferencial entre compra y venta o reducir la cantidad de órdenes pendientes, lo que llevará a que la liquidez del mercado en su conjunto se vea afectada.
El roadmap de ICM busca equilibrar este patrón y atraer liquidez de alta calidad de vuelta a la cadena.
El plan de tres pasos de ICM
Solana ha dividido este gran plan en tres etapas:
Corto plazo (1-3 meses): principalmente optimizar la experiencia de transacciones en la cadena existente, hacer que las aplicaciones de libro de órdenes sean más útiles y reducir la interferencia maliciosa del MEV. Específicamente incluye:
Se lanza el módulo Block Assembly Marketplace (BAM) de un conocido laboratorio en la mainnet. El significado de este módulo es proporcionar un sistema externo temporal antes del lanzamiento del ACE (Ejecución Controlada por Aplicaciones) definitivo, permitiendo que los contratos inteligentes en Solana tengan autonomía en el orden de las transacciones.
El equipo de Anza optimizó la tasa de éxito de "entrar en el mismo Slot de negociación", reduciendo así el deslizamiento y las pérdidas de MEV.
Se espera que estas mejoras se implementen gradualmente entre julio y septiembre de 2025.
Medio plazo (3-9 meses): Introducción de una red de alta velocidad dedicada y una nueva versión de consenso, reduciendo drásticamente la latencia y aumentando el rendimiento:
Desplegar una red de fibra óptica dedicada de DoubleZero, proporcionando a los validadores una comunicación de alta velocidad con casi cero fluctuación y una reducción de la latencia de hasta 100 ms.
Se lanzó el protocolo de consenso Alpenglow, reduciendo el tiempo de confirmación final de aproximadamente 12.8 segundos a aproximadamente 0.15 segundos.
Desarrollo de la Ejecución de Programas Asíncronos ( Asynchronous Program Execution, APE ), reduce el bloqueo de la ejecución de transacciones en el consenso.
A largo plazo (9-30 meses): realizar una actualización revolucionaria de la arquitectura central de Solana, con el objetivo de lograrlo alrededor de 2027:
Varios Líderes Concurrentes (Multiple Concurrent Leaders, MCL): Permiten que varios validadores propongan transacciones simultáneamente en sus respectivos pipelines y luego ordenen estos bloques paralelos según la tarifa de prioridad. Esto debilita el monopolio de un único empaquetador y mejora la resistencia a la censura.
Ejecución controlada por la aplicación (, ACE ) función: otorga verdaderamente a los contratos inteligentes en la cadena el poder de controlar el orden de ejecución de las transacciones.
Analizando hasta aquí, el autor considera que la propuesta del mapa de ruta ICM tiene la siguiente historia detrás: el antiguo DEX en Solana fue superado por el recién llegado Hyperliquid debido a la "excelente experiencia de una plataforma de intercambio en cadena". El antiguo DEX, incapaz de competir, tuvo que pedir ayuda a los "grandes" como Solana Labs y Anza. Los "grandes" propusieron un plan de transformación técnica ICM, afirmando que replicarían las habilidades distintivas de Hyperliquid para equipar completamente al antiguo DEX, ayudándolo a volver a competir en el mercado de DEX. Sin embargo, los "grandes" también dijeron que esta transformación técnica es extremadamente difícil, por lo que dividieron el plan técnico en una estrategia de tres pasos, y el equipo que se puede proporcionar al antiguo DEX en el corto plazo es solo el BAM de un laboratorio conocido, para que el antiguo DEX pueda hacer frente y compararse temporalmente con Hyperliquid.
Habiendo aclarado el contexto de la historia, en los próximos capítulos, el autor analizará en detalle qué habilidades distintivas de Hyperliquid ha imitado y replicado ICM.
Imitación 1: Mecanismo de orden de transacciones
Problema: Como se mencionó anteriormente, la cadena actual favorece a los takers, mientras que los makers sufren el "flujo tóxico". Los usuarios que activamente toman órdenes pueden basarse en el precio más reciente fuera de la cadena para iniciar una transacción en las órdenes de la cadena al instante, y al aumentar las tarifas de transacción, pueden ser atendidos con prioridad, mientras que los creadores de mercado a menudo no tienen tiempo para actualizar o cancelar sus órdenes. El resultado es que los creadores de mercado deben ampliar el diferencial o simplemente retirar la liquidez, lo que empeora la profundidad del mercado.
La solución definitiva de ICM: aplicación de ejecución controlada ( ACE )
El roadmap de ICM propone el concepto de ACE (Application Controlled Execution), que delega el derecho de ordenar transacciones a las aplicaciones en cada cadena, permitiendo que cada aplicación decida cómo ordenar y ejecutar las transacciones relacionadas con ella. Por ejemplo, en el futuro, en Solana, que implementará ACE, los contratos DeFi podrán establecer las siguientes reglas personalizadas de ordenamiento de transacciones:
Actualización de precios del oráculo: las aplicaciones DeFi pueden insertar una transacción antes de que se realicen grandes operaciones para obtener el precio más reciente del oráculo, asegurando que las órdenes se ejecuten al precio razonable más reciente y evitando que las cotizaciones de los creadores de mercado se basen en precios desactualizados y sean objeto de arbitraje.
Prioridad de ejecución de cancelación de pedido: la aplicación puede establecer que la "solicitud de cancelación" tenga prioridad sobre la nueva "ejecución de orden de compra", permitiendo al maker retirar su orden a tiempo cuando el mercado es desfavorable.
Subasta en la cola del equipo: por ejemplo, después de que aparece una gran orden de compra que eleva el precio, la aplicación DeFi saca a subasta la oportunidad de "seguir inmediatamente"; quien esté dispuesto a devolver la mayor cantidad de beneficios al protocolo (o a los usuarios), el protocolo DeFi permitirá que su transacción se ejecute justo detrás de la gran orden. La aplicación DeFi puede devolver los ingresos de la subasta a los usuarios, convirtiendo así el tráfico MEV tóxico en ingresos benignos.
BAM de un laboratorio conocido: plan de transición
Antes del lanzamiento oficial de ACE, un conocido laboratorio presentó una solución de transición llamada Block Assembly Marketplace (BAM). El flujo de trabajo de BAM es:
El usuario envía la transacción a un nodo que ejecuta el software BAM (en lugar de enviarla directamente al líder actual).
Los nodos BAM recopilan transacciones locales y ejecutan varios plugins (plugin) para reordenar los paquetes de transacciones (Bundle) bajo protección de privacidad (los plugins se ejecutan en un entorno TEE seguro y ocultan el contenido de las transacciones antes de la ejecución). A través de los plugins, los desarrolladores de aplicaciones pueden personalizar diversas reglas de orden para sus contratos, como priorizar la cancelación de órdenes, actualizar el precio del oráculo antes de la coincidencia, e incluso ejecutar subastas complejas dentro de la aplicación.
El Bundle de transacciones ordenado se envía al Líder de Solana para ser empaquetado en la cadena.
BAM puede verse como un campo de pruebas antes de que ACE esté en la cadena, su funcionalidad es muy similar a la de ACE definitivo, solo que funciona en una red independiente fuera de la cadena, en lugar de estar incorporado en el protocolo de la cadena principal de Solana.
Es importante señalar que un conocido laboratorio había estado proporcionando infraestructura orientada a la extracción de MEV (como un motor de bloques), cuyo modelo de negocio consiste en crear oportunidades para los arbitrajistas mediante la optimización del orden de las transacciones y compartir los beneficios. Esto, en cierta medida, representa una "lanza" que se opone a los usuarios comunes y a aquellos que son objeto de arbitraje. Sin embargo, el laboratorio cerró a principios de 2024 la función de memoria pública para robots de arbitraje (mempool) para reducir externalidades negativas como los ataques de sándwich. Esta medida indica que la comunidad de Solana tiende a suprimir el MEV perjudicial y a mantener la equidad para los usuarios.
El lanzamiento de BAM sigue esta línea de pensamiento: en esencia, convierte el mecanismo de orden originalmente utilizado para el arbitraje de MEV en un "escudo" para proteger a los creadores de mercado y otros proveedores de liquidez, como forzar la retirada de órdenes prioritarias para evitar pérdidas a los creadores de mercado, e introducir reembolsos por pujas para reducir las ganancias de los que se adelantan. Los buscadores de MEV originales, si quieren ganar dinero, deben cambiar de rol y desarrollar complementos de BAM para servir a los protocolos DeFi, obteniendo ganancias a través de las tarifas de los complementos.
consultando a Hyperliquid
La idea de ACE/BAM mencionada anteriormente se puede considerar como una forma de alcanzar el mecanismo de emparejamiento en la cadena de Hyperliquid. Hyperliquid es una cadena dedicada (Appchain), creada específicamente para servir a DEX. Además, el HLP Vault, operado oficialmente por Hyperliquid, es en realidad uno de los mayores creadores de mercado de la plataforma, por lo que no es difícil entender que las reglas de la cadena de Hyperliquid tienden a favorecer a los proveedores de liquidez, habiendo implementado en la capa de la cadena muchos diseños que protegen a los creadores de mercado, tales como:
Prioridad en la protección de órdenes pendientes: las órdenes de cancelación y las órdenes de maker son procesadas con prioridad, evitando que los creadores de mercado sean afectados negativamente por transacciones desfavorables sin su conocimiento. La "ejecución prioritaria de cancelaciones" mencionada por Solana ACE ha sido practicada durante años por Hyperliquid.
Garantía de precio más reciente: El proceso de liquidación y emparejamiento de Hyperliquid enfatiza el uso de los precios de alimentación más recientes y el estado del margen para realizar una "doble verificación". Por ejemplo, cuando hay órdenes pendientes que se emparejan, el sistema vuelve a solicitar el precio del oráculo más reciente para evaluar el margen de ambas partes, asegurando que no haya riesgos debido a la desactualización de precios. Esto es similar a cómo ACE inserta actualizaciones del oráculo antes de ejecutar una operación.
Protección contra auto-negociación: Si la misma dirección compra y vende al mismo tiempo, Hyperliquid cancela automáticamente en lugar de emparejar, para evitar el lavado de operaciones o costos innecesarios.
El ACE/BAM de Solana ICM, sin duda, está "tomando nota" de Hyperliquid. Hyperliquid, como líder en CLOB en cadena, ha implementado una serie de mecanismos amigables para los creadores de mercado a través de una cadena exclusiva. Ahora, Solana espera replicar este efecto utilizando una cadena general y complementos modulares, es decir, permitir que cada aplicación tenga un control sobre el orden de las transacciones similar al de Hyperliquid.
Imitación dos: finalización instantánea
Comparación de consensos existentes
Solana actualmente utiliza Tower BFT, la confirmación y la finalización son probabilísticas y progresivas: un bloque recibe 2/3 de los votos y se considera "confirmado(Confirmed)", pero se necesitan acumular aproximadamente 32 bloques posteriores en la cadena (generalmente alrededor de 13 segundos) para ser anclado como "finalizado(Finalized)". Para ciertas aplicaciones (como el comercio de alta frecuencia), un tiempo de confirmación final de unos segundos sigue siendo demasiado largo.
HyperBFT es el algoritmo de consenso desarrollado por Hyperliquid, inspirado en el consenso HotStuff, que utiliza una confirmación de bloque de dos rondas de votación para lograr la "finalidad instantánea".