Hoja de ruta ICM de Solana: ¿una "imitación" de Hyperliquid?
Recientemente, un grupo de grandes figuras del ecosistema de Solana se reunió para publicar una hoja de ruta técnica titulada "Internet Capital Markets ( Internet Capital Markets, ICM )". La idea central de esta hoja de ruta es "Ejecución Controlada por Aplicaciones ( Application Controlled Execution, ACE )", en términos simples, se trata de otorgar a las aplicaciones en cadena el derecho de ordenamiento de transacciones autónomas 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 tú tienes en Hyperliquid, nosotros también lo queremos, ¡y lo haremos mejor!"
Hay que saber que Hyperliquid ocupa una posición dominante en el mercado de contratos perpetuos en cadena, llegando a representar alrededor del 65% del volumen total del mercado de contratos perpetuos descentralizados. Evidentemente, frente a un competidor así, Solana no está dispuesta a ser superada por los recién llegados, por lo que ha lanzado esta hoja de ruta ICM.
Entonces, ¿de qué se trata realmente 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 pesos pesados del ecosistema de Solana:
Solana Foundation/Labs: 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, algo similar a ConsenSys de Ethereum. Ellos se encargaron de muchos trabajos clave en esta hoja de ruta, como el nuevo protocolo de consenso Alpenglow.
Jito Labs: Proveedor de infraestructura MEV en Solana, con una influencia significativa, casi controla el "poder de vida y muerte" de todo el flujo MEV en Solana. Esta vez lideran la provisión del Block Assembly Marketplace (BAM) y otros esquemas de ordenación de transacciones.
Multicoin Capital: una reconocida institución de inversión en criptomonedas y también un temprano defensor de Solana. Debido a su gran posesión de SOL y derechos en proyectos ecológicos, tiene una considerable influencia en la dirección técnica.
DoubleZero: Un equipo enfocado en acelerar las comunicaciones en la 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.
Drift: el proyecto DEX de contratos perpetuos líder en Solana. Anteriormente, Drift utilizaba un modo de emparejamiento fuera de la cadena, y se sentía algo desafiado al enfrentarse a Hyperliquid completamente en cadena. Esta vez, al participar en la elaboración de la hoja de ruta, claramente espera aprovechar la mejora de la infraestructura subyacente para recuperar terreno.
el problema central a resolver
El enfoque del mapa de ruta es la mejora de la microestructura del mercado, en otras palabras, el mecanismo de transacciones en cadena actual no es lo suficientemente amigable para los creadores de mercado, es decir, los Takers que inician activamente las transacciones se benefician, mientras que los Market Makers que esperan a que se ejecuten sus órdenes sufren pérdidas. Esto se debe a que los Takers a menudo tienen la información más reciente y aumentan activamente la tarifa de transacción para garantizar que sus transacciones se ejecuten primero, mientras que los Makers a menudo no tienen tiempo para retirar sus órdenes y se ven obligados a ejecutar a precios desfavorables.
Algunos traders de arbitraje de alta frecuencia aprovecharán esta asimetría para llevar a cabo ataques de "flujo 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, los arbitrajistas pueden ejecutar órdenes a precios antiguos, causando pérdidas a los creadores de mercado. El resultado es que Maker, para protegerse, debe ampliar el diferencial de compra-venta o reducir la cantidad de órdenes pendientes, lo que provoca una disminución de la liquidez en todo el mercado.
La hoja de ruta de ICM busca equilibrar este patrón y atraer liquidez de alta calidad de vuelta a la cadena.
( La estrategia de tres pasos de ICM
Solana ha dividido este ambicioso plan en tres etapas:
Corto plazo )1-3 meses ###: Principalmente se optimiza la experiencia de transacciones en cadena existente, haciendo que las aplicaciones de libro de órdenes sean más útiles y reduciendo la interferencia maliciosa de MEV. Específicamente incluye:
El mercado de Block Assembly de Jito Labs(BAM) ha lanzado su módulo en la mainnet. El significado de este módulo es proporcionar un sistema externo temporal antes del lanzamiento de la ACE( (Ejecución Controlada por Aplicaciones)), permitiendo que los contratos inteligentes en Solana tengan el derecho autónomo de ordenar las transacciones.
El equipo de Anza optimizó la tasa de éxito de "entrar en el mismo Slot en una transacción", reduciendo así el deslizamiento y la pérdida de MEV.
Estas mejoras se espera que se implementen gradualmente entre julio y septiembre de 2025.
Período medio (3-9 meses ): Introducción de una red de alta velocidad dedicada y una nueva versión del consenso, reduciendo drásticamente la latencia y aumentando el rendimiento:
Despliegue de una red de fibra óptica dedicada DoubleZero, proporcionando a los validadores comunicaciones de alta velocidad con casi cero jitter 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 ( Ejecución de Programas Asíncronos, APE ), reducir el bloqueo de la ejecución de transacciones en el consenso.
A largo plazo(9-30 meses): realizar una actualización revolucionaria en la arquitectura central de Solana, con el objetivo de lograrlo alrededor de 2027:
Líderes Concurrentes Múltiples, MCL(: Permite a múltiples validadores proponer transacciones simultáneamente en sus propios pipelines, y luego combinar y ordenar estos bloques paralelos según la tarifa de prioridad. Esto puede debilitar el monopolio de un solo empaquetador y fortalecer la resistencia a la censura.
Ejecución controlada por aplicaciones nativas )Application Controlled Execution, ACE( función: realmente otorga 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 de la hoja de ruta ICM tiene la siguiente historia detrás: el antiguo DEX Drift en Solana fue superado por el recién llegado Hyperliquid con una experiencia sobresaliente como "Binance en cadena". Drift, incapaz de competir, tuvo que recurrir a "grandes" como Solana Labs, Anza y Jito. Los "grandes" propusieron un plan de reforma técnica ICM, afirmando que replicarían las habilidades distintivas de Hyperliquid para equipar a Drift y ayudarlo a volver a competir en el mercado de DEX. Sin embargo, los "grandes" también dijeron que esta reforma técnica es extremadamente difícil, por lo que dividieron el plan técnico en una estrategia de tres pasos, y el único equipo que pueden proporcionar a Drift en el corto plazo es el BAM de Jito, para que Drift lo use provisionalmente y compita con Hyperliquid.
Se ha aclarado el trasfondo de la historia, en los próximos capítulos, el autor analizará en detalle qué habilidades características de Hyperliquid ha imitado y replicado ICM.
Imitación 1: Mecanismo de ordenación de transacciones
Problema: Como se mencionó anteriormente, la cadena actual favorece a los tomadores, los creadores sufren el "flujo tóxico". Los usuarios que activamente aceptan órdenes pueden iniciar transacciones en las órdenes del libro de la cadena en función del precio más reciente fuera de la cadena, y pueden priorizar su ejecución aumentando la tarifa, mientras que los creadores de mercado a menudo no pueden actualizar o cancelar órdenes a tiempo. El resultado es que los creadores de mercado o amplían el diferencial o simplemente retiran la liquidez, lo que empeora la profundidad del mercado.
) La solución definitiva de ICM: ejecución controlable de aplicaciones ( ACE )
El mapa de ruta de ICM propone el concepto de ACE###Ejecución Controlada por la Aplicación(, que descentraliza el derecho de ordenamiento de transacciones a las aplicaciones en cada cadena, permitiendo a las aplicaciones decidir cómo se ordenan y ejecutan las transacciones relacionadas con ellas. 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 de Oracle: 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 actualizado y evitando que las cotizaciones de los creadores de mercado se basen en precios desactualizados y sean objeto de arbitraje.
Prioridad en la cancelación de órdenes: la aplicación puede establecer que las "solicitudes de cancelación" se ejecuten antes que las nuevas "transacciones de compra", lo que permite al maker retirar su orden a tiempo cuando las condiciones del mercado son desfavorables.
Subasta de cola del equipo: por ejemplo, después de que aparezca una gran orden de compra que eleve el precio, la aplicación DeFi sacará a subasta la oportunidad "inmediatamente siguiente", quien esté dispuesto a devolver el mayor beneficio al protocolo ) o al usuario (, el protocolo DeFi ejecutará la transacción de quien lo ofrezca. Las aplicaciones DeFi pueden devolver los ingresos de la subasta a los usuarios, convirtiendo así el flujo tóxico de MEV en ingresos positivos.
) BAM de JITO: plan de transición
Antes del lanzamiento oficial de ACE, Jito Labs presentó un plan de transición llamado 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, ocultando el contenido de las transacciones al exterior antes de la ejecución (. A través de los plugins, los desarrolladores de aplicaciones pueden personalizar diversas reglas de ordenación para sus contratos, como dar prioridad a las cancelaciones, 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 considerarse como un campo de pruebas antes de que ACE esté en la cadena, sus funciones son muy similares a las del ACE definitivo, solo que funciona en una red independiente fuera de la cadena, en lugar de estar integrado en el protocolo de la cadena principal de Solana.
Es importante señalar que Jito anteriormente proporcionaba infraestructura orientada a la extracción de MEV ), como Jito Block Engine (, cuyo modelo de negocio consiste en crear oportunidades para los arbitrajistas y compartir los beneficios optimizando el orden de las transacciones. Esto, en cierto modo, se presenta como una "lanza" que se enfrenta a los usuarios comunes y a los que son objeto de arbitraje. Sin embargo, Jito cerró a principios de 2024 la función de memoria pública orientada a robots de arbitraje ) mempool (, para reducir externalidades negativas como los ataques de sándwich. Esta medida indica que la comunidad de Solana tiende a reprimir el MEV perjudicial y a mantener la equidad para los usuarios.
El lanzamiento de BAM se alinea con esta idea: esencialmente transforma el mecanismo de orden que originalmente se utilizaba para el arbitraje de MEV en un "escudo" para proteger a los proveedores de liquidez, como los creadores de mercado, evitando que sufran pérdidas mediante la retirada forzada de órdenes, e introduciendo incentivos de puja para reducir las ganancias por adelantado. Los buscadores de MEV originales, si quieren ganar dinero, deberán cambiar de rol y desarrollar complementos de BAM para servir a los protocolos DeFi, obteniendo ganancias a través de tarifas de complementos.
) consultar a HYPERLIQUID
La idea de ACE/BAM mencionada anteriormente se puede considerar como una especie de seguimiento del mecanismo de emparejamiento en la cadena de Hyperliquid. Hyperliquid es una cadena dedicada (Appchain), que está diseñada desde su origen para servir a los 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 están más orientadas hacia los proveedores de liquidez, y ya se han implementado muchos diseños que protegen a los creadores de mercado en la capa de cadena, por ejemplo:
Prioridad en la protección de órdenes pendientes: las cancelaciones de órdenes y las órdenes de solo maker se procesan con prioridad, evitando que los creadores de mercado sean perjudicados por transacciones desfavorables sin su conocimiento. La "ejecución prioritaria de cancelaciones" mencionada por Solana ACE ya ha sido practicada por Hyperliquid durante años.
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 de margen para realizar una "doble verificación". Por ejemplo, cuando hay órdenes pendientes que se emparejan, el sistema vuelve a obtener el último precio del oráculo para evaluar el margen de ambas partes, asegurando que no haya riesgos causados por el retraso en los precios. Esto es similar a cómo ACE inserta actualizaciones del oráculo antes de la ejecución de la operación.
Protección contra auto-comercio: Si una misma dirección compra y vende al mismo tiempo, Hyperliquid cancelará automáticamente en lugar de emparejar, para evitar el lavado de volumen o costos innecesarios.
Solana ICM de ACE/BAM, sin duda está "tomando notas" de Hyperliquid. Hyperliquid, como líder en CLOB en cadena, ha implementado una variedad de mecanismos amigables para los creadores de mercado mediante una cadena exclusiva. Ahora, Solana espera replicar este efecto utilizando una cadena general y complementos modularizados—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 marca como "confirmado ( Confirmed )", pero se necesitan aproximadamente 32 bloques posteriores en la cadena ###, lo que generalmente toma alrededor de 13 segundos ( para ser anclado como "finalizado ) Finalized (". Para algunas aplicaciones ), como el comercio de alta frecuencia (, el 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 bloques mediante dos rondas de votación, logrando "finalidad instantánea".
Primera ronda: Votación previa )Prevote(: Una vez que los validadores reciben el bloque candidato transmitido por el Proposer, realizan una verificación rápida. Si la verificación es exitosa, cada validador emitirá un "voto previo" )Prevote( y lo transmitirá a toda la red. Este voto representa: "He revisado preliminarmente y este bloque no tiene problemas."
Segunda ronda: Precompromiso ) Precommit (: Una vez que un validador ha recopilado los Prevotes de más de dos tercios de los validadores para el mismo bloque candidato, obtiene suficiente confianza en que la mayoría de la red se
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.
10 me gusta
Recompensa
10
5
Compartir
Comentar
0/400
gas_guzzler
· 08-05 15:39
Hacer copias de tareas también es una forma de aprender, ¿qué hay de malo en eso?
Ver originalesResponder0
RektHunter
· 08-05 15:39
Copia lo que quieras, sol solo tiene esta habilidad.
Ver originalesResponder0
PaperHandSister
· 08-05 15:37
Mirar la obra, tú copias, yo copio, todos copian.
Ver originalesResponder0
GweiWatcher
· 08-05 15:28
Realmente es copiar y copiar, qué decepcionante.
Ver originalesResponder0
ApeDegen
· 08-05 15:23
Bueno, en realidad no se puede considerar una imitación, se llama inspiración.
El roadmap de Solana ICM apunta a una nueva transformación en el panorama de transacciones on-chain de Hyperliquid.
Hoja de ruta ICM de Solana: ¿una "imitación" de Hyperliquid?
Recientemente, un grupo de grandes figuras del ecosistema de Solana se reunió para publicar una hoja de ruta técnica titulada "Internet Capital Markets ( Internet Capital Markets, ICM )". La idea central de esta hoja de ruta es "Ejecución Controlada por Aplicaciones ( Application Controlled Execution, ACE )", en términos simples, se trata de otorgar a las aplicaciones en cadena el derecho de ordenamiento de transacciones autónomas 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 tú tienes en Hyperliquid, nosotros también lo queremos, ¡y lo haremos mejor!"
Hay que saber que Hyperliquid ocupa una posición dominante en el mercado de contratos perpetuos en cadena, llegando a representar alrededor del 65% del volumen total del mercado de contratos perpetuos descentralizados. Evidentemente, frente a un competidor así, Solana no está dispuesta a ser superada por los recién llegados, por lo que ha lanzado esta hoja de ruta ICM.
Entonces, ¿de qué se trata realmente 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 pesos pesados del ecosistema de Solana:
Solana Foundation/Labs: 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, algo similar a ConsenSys de Ethereum. Ellos se encargaron de muchos trabajos clave en esta hoja de ruta, como el nuevo protocolo de consenso Alpenglow.
Jito Labs: Proveedor de infraestructura MEV en Solana, con una influencia significativa, casi controla el "poder de vida y muerte" de todo el flujo MEV en Solana. Esta vez lideran la provisión del Block Assembly Marketplace (BAM) y otros esquemas de ordenación de transacciones.
Multicoin Capital: una reconocida institución de inversión en criptomonedas y también un temprano defensor de Solana. Debido a su gran posesión de SOL y derechos en proyectos ecológicos, tiene una considerable influencia en la dirección técnica.
DoubleZero: Un equipo enfocado en acelerar las comunicaciones en la 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.
Drift: el proyecto DEX de contratos perpetuos líder en Solana. Anteriormente, Drift utilizaba un modo de emparejamiento fuera de la cadena, y se sentía algo desafiado al enfrentarse a Hyperliquid completamente en cadena. Esta vez, al participar en la elaboración de la hoja de ruta, claramente espera aprovechar la mejora de la infraestructura subyacente para recuperar terreno.
el problema central a resolver
El enfoque del mapa de ruta es la mejora de la microestructura del mercado, en otras palabras, el mecanismo de transacciones en cadena actual no es lo suficientemente amigable para los creadores de mercado, es decir, los Takers que inician activamente las transacciones se benefician, mientras que los Market Makers que esperan a que se ejecuten sus órdenes sufren pérdidas. Esto se debe a que los Takers a menudo tienen la información más reciente y aumentan activamente la tarifa de transacción para garantizar que sus transacciones se ejecuten primero, mientras que los Makers a menudo no tienen tiempo para retirar sus órdenes y se ven obligados a ejecutar a precios desfavorables.
Algunos traders de arbitraje de alta frecuencia aprovecharán esta asimetría para llevar a cabo ataques de "flujo 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, los arbitrajistas pueden ejecutar órdenes a precios antiguos, causando pérdidas a los creadores de mercado. El resultado es que Maker, para protegerse, debe ampliar el diferencial de compra-venta o reducir la cantidad de órdenes pendientes, lo que provoca una disminución de la liquidez en todo el mercado.
La hoja de ruta de ICM busca equilibrar este patrón y atraer liquidez de alta calidad de vuelta a la cadena.
( La estrategia de tres pasos de ICM
Solana ha dividido este ambicioso plan en tres etapas:
Corto plazo )1-3 meses ###: Principalmente se optimiza la experiencia de transacciones en cadena existente, haciendo que las aplicaciones de libro de órdenes sean más útiles y reduciendo la interferencia maliciosa de MEV. Específicamente incluye:
El mercado de Block Assembly de Jito Labs(BAM) ha lanzado su módulo en la mainnet. El significado de este módulo es proporcionar un sistema externo temporal antes del lanzamiento de la ACE( (Ejecución Controlada por Aplicaciones)), permitiendo que los contratos inteligentes en Solana tengan el derecho autónomo de ordenar las transacciones.
El equipo de Anza optimizó la tasa de éxito de "entrar en el mismo Slot en una transacción", reduciendo así el deslizamiento y la pérdida de MEV.
Estas mejoras se espera que se implementen gradualmente entre julio y septiembre de 2025.
Período medio (3-9 meses ): Introducción de una red de alta velocidad dedicada y una nueva versión del consenso, reduciendo drásticamente la latencia y aumentando el rendimiento:
Despliegue de una red de fibra óptica dedicada DoubleZero, proporcionando a los validadores comunicaciones de alta velocidad con casi cero jitter 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 ( Ejecución de Programas Asíncronos, APE ), reducir el bloqueo de la ejecución de transacciones en el consenso.
A largo plazo(9-30 meses): realizar una actualización revolucionaria en la arquitectura central de Solana, con el objetivo de lograrlo alrededor de 2027:
Líderes Concurrentes Múltiples, MCL(: Permite a múltiples validadores proponer transacciones simultáneamente en sus propios pipelines, y luego combinar y ordenar estos bloques paralelos según la tarifa de prioridad. Esto puede debilitar el monopolio de un solo empaquetador y fortalecer la resistencia a la censura.
Ejecución controlada por aplicaciones nativas )Application Controlled Execution, ACE( función: realmente otorga 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 de la hoja de ruta ICM tiene la siguiente historia detrás: el antiguo DEX Drift en Solana fue superado por el recién llegado Hyperliquid con una experiencia sobresaliente como "Binance en cadena". Drift, incapaz de competir, tuvo que recurrir a "grandes" como Solana Labs, Anza y Jito. Los "grandes" propusieron un plan de reforma técnica ICM, afirmando que replicarían las habilidades distintivas de Hyperliquid para equipar a Drift y ayudarlo a volver a competir en el mercado de DEX. Sin embargo, los "grandes" también dijeron que esta reforma técnica es extremadamente difícil, por lo que dividieron el plan técnico en una estrategia de tres pasos, y el único equipo que pueden proporcionar a Drift en el corto plazo es el BAM de Jito, para que Drift lo use provisionalmente y compita con Hyperliquid.
Se ha aclarado el trasfondo de la historia, en los próximos capítulos, el autor analizará en detalle qué habilidades características de Hyperliquid ha imitado y replicado ICM.
Imitación 1: Mecanismo de ordenación de transacciones
Problema: Como se mencionó anteriormente, la cadena actual favorece a los tomadores, los creadores sufren el "flujo tóxico". Los usuarios que activamente aceptan órdenes pueden iniciar transacciones en las órdenes del libro de la cadena en función del precio más reciente fuera de la cadena, y pueden priorizar su ejecución aumentando la tarifa, mientras que los creadores de mercado a menudo no pueden actualizar o cancelar órdenes a tiempo. El resultado es que los creadores de mercado o amplían el diferencial o simplemente retiran la liquidez, lo que empeora la profundidad del mercado.
) La solución definitiva de ICM: ejecución controlable de aplicaciones ( ACE )
El mapa de ruta de ICM propone el concepto de ACE###Ejecución Controlada por la Aplicación(, que descentraliza el derecho de ordenamiento de transacciones a las aplicaciones en cada cadena, permitiendo a las aplicaciones decidir cómo se ordenan y ejecutan las transacciones relacionadas con ellas. 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 de Oracle: 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 actualizado y evitando que las cotizaciones de los creadores de mercado se basen en precios desactualizados y sean objeto de arbitraje.
Prioridad en la cancelación de órdenes: la aplicación puede establecer que las "solicitudes de cancelación" se ejecuten antes que las nuevas "transacciones de compra", lo que permite al maker retirar su orden a tiempo cuando las condiciones del mercado son desfavorables.
Subasta de cola del equipo: por ejemplo, después de que aparezca una gran orden de compra que eleve el precio, la aplicación DeFi sacará a subasta la oportunidad "inmediatamente siguiente", quien esté dispuesto a devolver el mayor beneficio al protocolo ) o al usuario (, el protocolo DeFi ejecutará la transacción de quien lo ofrezca. Las aplicaciones DeFi pueden devolver los ingresos de la subasta a los usuarios, convirtiendo así el flujo tóxico de MEV en ingresos positivos.
) BAM de JITO: plan de transición
Antes del lanzamiento oficial de ACE, Jito Labs presentó un plan de transición llamado 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, ocultando el contenido de las transacciones al exterior antes de la ejecución (. A través de los plugins, los desarrolladores de aplicaciones pueden personalizar diversas reglas de ordenación para sus contratos, como dar prioridad a las cancelaciones, 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 considerarse como un campo de pruebas antes de que ACE esté en la cadena, sus funciones son muy similares a las del ACE definitivo, solo que funciona en una red independiente fuera de la cadena, en lugar de estar integrado en el protocolo de la cadena principal de Solana.
Es importante señalar que Jito anteriormente proporcionaba infraestructura orientada a la extracción de MEV ), como Jito Block Engine (, cuyo modelo de negocio consiste en crear oportunidades para los arbitrajistas y compartir los beneficios optimizando el orden de las transacciones. Esto, en cierto modo, se presenta como una "lanza" que se enfrenta a los usuarios comunes y a los que son objeto de arbitraje. Sin embargo, Jito cerró a principios de 2024 la función de memoria pública orientada a robots de arbitraje ) mempool (, para reducir externalidades negativas como los ataques de sándwich. Esta medida indica que la comunidad de Solana tiende a reprimir el MEV perjudicial y a mantener la equidad para los usuarios.
El lanzamiento de BAM se alinea con esta idea: esencialmente transforma el mecanismo de orden que originalmente se utilizaba para el arbitraje de MEV en un "escudo" para proteger a los proveedores de liquidez, como los creadores de mercado, evitando que sufran pérdidas mediante la retirada forzada de órdenes, e introduciendo incentivos de puja para reducir las ganancias por adelantado. Los buscadores de MEV originales, si quieren ganar dinero, deberán cambiar de rol y desarrollar complementos de BAM para servir a los protocolos DeFi, obteniendo ganancias a través de tarifas de complementos.
) consultar a HYPERLIQUID
La idea de ACE/BAM mencionada anteriormente se puede considerar como una especie de seguimiento del mecanismo de emparejamiento en la cadena de Hyperliquid. Hyperliquid es una cadena dedicada (Appchain), que está diseñada desde su origen para servir a los 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 están más orientadas hacia los proveedores de liquidez, y ya se han implementado muchos diseños que protegen a los creadores de mercado en la capa de cadena, por ejemplo:
Prioridad en la protección de órdenes pendientes: las cancelaciones de órdenes y las órdenes de solo maker se procesan con prioridad, evitando que los creadores de mercado sean perjudicados por transacciones desfavorables sin su conocimiento. La "ejecución prioritaria de cancelaciones" mencionada por Solana ACE ya ha sido practicada por Hyperliquid durante años.
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 de margen para realizar una "doble verificación". Por ejemplo, cuando hay órdenes pendientes que se emparejan, el sistema vuelve a obtener el último precio del oráculo para evaluar el margen de ambas partes, asegurando que no haya riesgos causados por el retraso en los precios. Esto es similar a cómo ACE inserta actualizaciones del oráculo antes de la ejecución de la operación.
Protección contra auto-comercio: Si una misma dirección compra y vende al mismo tiempo, Hyperliquid cancelará automáticamente en lugar de emparejar, para evitar el lavado de volumen o costos innecesarios.
Solana ICM de ACE/BAM, sin duda está "tomando notas" de Hyperliquid. Hyperliquid, como líder en CLOB en cadena, ha implementado una variedad de mecanismos amigables para los creadores de mercado mediante una cadena exclusiva. Ahora, Solana espera replicar este efecto utilizando una cadena general y complementos modularizados—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 marca como "confirmado ( Confirmed )", pero se necesitan aproximadamente 32 bloques posteriores en la cadena ###, lo que generalmente toma alrededor de 13 segundos ( para ser anclado como "finalizado ) Finalized (". Para algunas aplicaciones ), como el comercio de alta frecuencia (, el 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 bloques mediante dos rondas de votación, logrando "finalidad instantánea".
Primera ronda: Votación previa )Prevote(: Una vez que los validadores reciben el bloque candidato transmitido por el Proposer, realizan una verificación rápida. Si la verificación es exitosa, cada validador emitirá un "voto previo" )Prevote( y lo transmitirá a toda la red. Este voto representa: "He revisado preliminarmente y este bloque no tiene problemas."
Segunda ronda: Precompromiso ) Precommit (: Una vez que un validador ha recopilado los Prevotes de más de dos tercios de los validadores para el mismo bloque candidato, obtiene suficiente confianza en que la mayoría de la red se