El espectáculo de imitaciones de Solana: ¿puede alcanzar a Hyperliquid?
Recientemente, miembros importantes del ecosistema de Solana, incluyendo la Fundación Solana, Anza, Jito Labs, entre otros, publicaron conjuntamente una hoja de ruta técnica titulada "Internet Capital Markets ( Internet Capital Markets, ICM )". El concepto central de esta hoja de ruta es "Ejecución Controlada por la Aplicación ( Application Controlled Execution, ACE )", con el objetivo de permitir que las aplicaciones en la cadena tengan el control autónomo de su orden de transacciones en milisegundos, creando un "Wall Street en la cadena" descentralizado.
Curiosamente, al leer todo el mapa de ruta, aunque no se menciona directamente a Hyperliquid, el diseño está casi en todas partes orientado a las fortalezas de Hyperliquid. Es como si Solana dijera: "Lo que tienes en Hyperliquid, nosotros también lo queremos, ¡y lo haremos mejor!"
Hyperliquid ocupa una posición dominante en el mercado de contratos perpetuos en la cadena, con un volumen de operaciones que llegó a representar alrededor del 65% de todo el mercado perpetuo descentralizado. Ante un competidor así, Solana claramente no está dispuesta a ser superada por los recién llegados, por lo que ha lanzado esta hoja de ruta ICM.
Entonces, ¿qué está pasando realmente con este "espectáculo de imitaciones"? ¿Puede Solana realmente alcanzar e incluso superar a Hyperliquid? Profundicemos en este tema.
Fondo y contenido de ICM
¿Quién está liderando esta transformación?
Participan en la elaboración de la hoja de ruta los jugadores más importantes del ecosistema de Solana:
Solana Foundation/Labs: El "padre" 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 así como ConsenSys de Ethereum. Han asumido muchas tareas clave de tecnología en esta hoja de ruta, como el nuevo protocolo de consenso Alpenglow.
Jito Labs: Proveedor de infraestructura MEV en Solana, con una gran influencia, controla casi todo el flujo de MEV en Solana con el "poder de vida y muerte". Esta vez, lideran la provisión del Block Assembly Marketplace (BAM) y otros esquemas de ordenamiento de transacciones.
Multicoin Capital: una conocida institución de inversión en criptomonedas, también es uno de los primeros partidarios de Solana. Debido a su gran posesión de SOL y derechos en proyectos del ecosistema, tiene una considerable influencia en la dirección técnica.
DoubleZero: un equipo enfocado en acelerar la comunicación 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 modelo de emparejamiento fuera de la cadena, lo que resultaba un poco difícil al enfrentarse a Hyperliquid completamente en la cadena; esta vez, al participar en la elaboración de la hoja de ruta, claramente espera aprovechar la actualización de la infraestructura para recuperarse.
el problema central a resolver
El enfoque del mapa de ruta es la mejora de la microestructura del mercado. En otras palabras, el actual mecanismo de transacciones en cadena no es lo suficientemente amigable para los creadores de mercado, lo que significa que los Takers, que inician activamente las transacciones, se benefician, mientras que los Market Makers ( pierden. 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 asegurar que sus transacciones se ejecuten primero, mientras que los Makers a menudo no tienen tiempo para cancelar órdenes y se ven obligados a ejecutar a precios desfavorables.
Algunos traders de alta frecuencia aprovecharán esta asimetría para llevar a cabo 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, los arbitrajistas pueden ejecutar órdenes a precios antiguos, haciendo que los creadores de mercado asuman pérdidas. El resultado es que el Maker, para protegerse, ya sea ampliará el diferencial de compra y venta, o reducirá la cantidad de órdenes, lo que provocará que la liquidez del mercado en general se vea afectada.
El mapa de ruta 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 dividió este gran plan en tres fases:
Corto plazo###1-3 meses(: se centra en optimizar la experiencia de las transacciones en la cadena existente, mejorar la usabilidad de las aplicaciones de libro de órdenes y reducir la interferencia maliciosa de MEV. Específicamente incluye:
El mercado 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 de que se lance la ejecución controlada por aplicaciones de ACE), permitiendo que los contratos inteligentes en Solana tengan el derecho de ordenar las transacciones de manera autónoma.
El equipo de Anza optimizó la tasa de éxito de "entrada de transacciones en el mismo Slot", reduciendo así el deslizamiento y las pérdidas de MEV.
Estas mejoras se espera que se implementen de manera gradual 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, lo que reduce significativamente la latencia y aumenta el rendimiento:
Despliegue de una red de fibra óptica dedicada a DoubleZero, proporcionando a los validadores comunicaciones de alta velocidad con casi cero fluctuaciones y una reducción de la latencia de hasta 100 ms.
Lanzamiento del protocolo de consenso Alpenglow, que reduce 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 ), reduce el bloqueo de la ejecución de transacciones en el consenso.
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 que múltiples validadores propongan transacciones simultáneamente en sus respectivos pipelines, y luego combina y ordena estos bloques paralelos según la tarifa de prioridad. De esta manera, se debilita el monopolio de un único empaquetador y se mejora la resistencia a la censura.
Ejecución controlada por aplicaciones )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.
Hasta aquí, el trasfondo de la propuesta del roadmap ICM debería ser el siguiente: el DEX tradicional Drift en Solana fue superado por el recién llegado Hyperliquid, que ofrece una excelente experiencia 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 transformación técnica llamado ICM, afirmando que iban a replicar todas las habilidades clave de Hyperliquid para ayudar a Drift a volver a competir en el mercado de DEX. Sin embargo, los "grandes" también mencionaron que la dificultad de esta transformación técnica es enorme, por lo que dividieron el plan técnico en una estrategia de tres pasos, y el equipo que podrán proporcionar a Drift en el corto plazo es solo el BAM de Jito, para que Drift lo utilice provisionalmente y pueda comparar con Hyperliquid.
Con el contexto de la historia claro, en los próximos capítulos, analizaremos en detalle qué habilidades distintivas 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, mientras que los creadores sufren las consecuencias del "flujo tóxico". Los usuarios que activamente aceptan órdenes pueden iniciar transacciones en las órdenes de la cadena basándose en el último precio fuera de la cadena, y al aumentar las tarifas de transacción pueden completar la operación prioritariamente, mientras que los creadores de mercado a menudo no tienen tiempo para actualizar o retirar órdenes. Como resultado, los creadores de mercado tienen que 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 )
La hoja de ruta de ICM propone el concepto de ACE###Application Controlled Execution(, que consiste en descentralizar el derecho a ordenar transacciones a las aplicaciones en cada cadena, permitiendo que las aplicaciones decidan cómo ordenar y ejecutar 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 para obtener el precio más reciente del oráculo antes de ejecutar grandes transacciones, asegurando que los pedidos se emparejen a un precio razonable y actualizado, evitando así que las cotizaciones de los creadores de mercado se basen en precios obsoletos y sean objeto de arbitraje.
Ejecución prioritaria de cancelación de órdenes: la aplicación puede establecer que la "solicitud de cancelación" tenga prioridad sobre la nueva "transacción de ejecución", lo que permite al maker retirar su orden en caso de que el mercado se vuelva desfavorable.
Subasta al final 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 de "seguir". Quien esté dispuesto a devolver el mayor beneficio al protocolo ) o al usuario (, el protocolo DeFi permitirá que su transacción se ejecute junto a 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 JITO: plan de transición
Antes del lanzamiento oficial de ACE, Jito Labs 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 seguro de TEE, ocultando el contenido de la transacción al exterior antes de la ejecución ). A través de los plugins, los desarrolladores de aplicaciones pueden personalizar varias reglas de ordenación para sus contratos, como dar prioridad a las cancelaciones, actualizar los precios de los oráculos 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 se implemente en la cadena; funcionalmente es muy similar al ACE definitivo, solo que opera en una red independiente fuera de la cadena, en lugar de estar integrado en el protocolo de la cadena principal de Solana.
Es importante destacar que Jito anteriormente proporcionaba infraestructura destinada a la extracción de MEV (, como Jito Block Engine ), cuyo modelo comercial se basa en optimizar el orden de las transacciones para crear oportunidades para los arbitrajistas y compartir ganancias. Esto, en cierto sentido, es una "lanza" que se sitúa en oposición 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 ( mempool ) dirigida a robots de arbitraje, 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 aún más con esta idea: esencialmente convierte el mecanismo de orden originalmente utilizado para el arbitraje de MEV en un "escudo" para proteger a los proveedores de liquidez como los creadores de mercado, por ejemplo, priorizando la cancelación forzada de órdenes para evitar que los creadores de mercado sufran pérdidas, e introduciendo incentivos de puja para reducir las ganancias por adelantado. Los buscadores de MEV originales, si quieren ganar dinero, deben cambiar de rol y escribir complementos de BAM para servir a los protocolos DeFi, obteniendo ganancias a través de las tarifas de los complementos.
( consultar a HYPERLIQUID
El enfoque ACE/BAM mencionado anteriormente se puede considerar como una forma de alcanzar el mecanismo de emparejamiento en cadena de Hyperliquid. Hyperliquid es una cadena dedicada )Appchain(, que está diseñada 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 están más orientadas a los proveedores de liquidez, y ya ha implementado en la capa de cadena muchos diseños para proteger a los creadores de mercado, como:
Prioridad en la protección de las órdenes: las órdenes de cancelación y las órdenes maker son procesadas con prioridad, evitando que los creadores de mercado sean ejecutados desfavorablemente sin conocimiento. La "prioridad en la ejecución de cancelaciones" mencionada por Solana ACE ha sido practicada por Hyperliquid durante muchos años.
Garantía de precio más reciente: El proceso de liquidación y emparejamiento de Hyperliquid enfatiza el uso de los últimos precios de oráculos y el estado de margen para realizar una "doble verificación". Por ejemplo, cuando se ejecuta un pedido, el sistema vuelve a obtener el último precio del oráculo para evaluar el margen de ambas partes, asegurando que no haya riesgos debido a retrasos en los precios. Esto es similar a cómo ACE inserta actualizaciones de oráculos antes de la ejecución de la transacción.
Protección contra autoservicio: si una misma dirección compra y vende al mismo tiempo, Hyperliquid cancela automáticamente en lugar de ejecutar la operación, para evitar el lavado de operaciones o costos innecesarios.
El ACE/BAM de Solana ICM, sin duda, está "aprendiendo" de Hyperliquid. Hyperliquid, como líder en CLOB en la cadena, ha implementado una serie de mecanismos amigables para los creadores de mercado mediante una cadena exclusiva. Ahora, Solana espera replicar este efecto utilizando cadenas generales y complementos modularizados, es decir, que cada aplicación tenga un control similar al de Hyperliquid sobre el orden de las transacciones.
Imitación dos: Finalidad 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 requiere acumular aproximadamente 32 bloques posteriores en la cadena ), lo que normalmente toma alrededor de 13 segundos ### para ser anclado como "finalizado ( Finalized )". Para ciertas aplicaciones ( como el trading de alta frecuencia ), el tiempo de confirmación final de unos segundos sigue siendo demasiado largo.
HyperBFT es el algoritmo de consenso desarrollado internamente por Hyperliquid, inspirado en el consenso HotStuff, que utiliza una confirmación de bloque de dos rondas de votación para lograr "finalidad instantánea".
Ronda 1: Votación previa ( Prevote ): Una vez que los validadores reciben el bloque candidato transmitido por el Proponente, realizarán una verificación rápida. Si la verificación es exitosa, cada validador emitirá un voto de "votación previa" ( 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 recogido los Prevotes de más de dos tercios de los validadores sobre el mismo bloque candidato, obtiene suficiente confianza en que la mayoría de los miembros de la red respaldan este bloque. Entonces, ese validador emitirá un voto de "precompromiso" más significativo (Precommit) y
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.
9 me gusta
Recompensa
9
7
Compartir
Comentar
0/400
ChainSauceMaster
· hace10h
Los seguidores no pueden convertirse en superadores
Ver originalesResponder0
EyeOfTheTokenStorm
· hace17h
El plagio es plagio, pero sigo apoyando a sol, después de todo la cuantificación requiere alta frecuencia y baja latencia.
Ver originalesResponder0
MetaMaskVictim
· 08-04 13:19
Escuchar tus palabras es como cuando WETH copió ERC20 en aquellos años.
Ver originalesResponder0
OffchainOracle
· 08-04 13:17
¿Sol ha empezado a subir de nuevo, verdad?
Ver originalesResponder0
PessimisticLayer
· 08-04 13:09
Otra vez imitando, la eficiencia es demasiado baja.
Ver originalesResponder0
UncleLiquidation
· 08-04 12:57
Copiar tareas con ganas, es demasiado real.
Ver originalesResponder0
MindsetExpander
· 08-04 12:56
Si no puedes igualar la velocidad de los demás, ¡entonces simplemente intenta aprovecharte!
Análisis del roadmap de Solana ICM: estrategia de tres pasos alineada con Hyperliquid
El espectáculo de imitaciones de Solana: ¿puede alcanzar a Hyperliquid?
Recientemente, miembros importantes del ecosistema de Solana, incluyendo la Fundación Solana, Anza, Jito Labs, entre otros, publicaron conjuntamente una hoja de ruta técnica titulada "Internet Capital Markets ( Internet Capital Markets, ICM )". El concepto central de esta hoja de ruta es "Ejecución Controlada por la Aplicación ( Application Controlled Execution, ACE )", con el objetivo de permitir que las aplicaciones en la cadena tengan el control autónomo de su orden de transacciones en milisegundos, creando un "Wall Street en la cadena" descentralizado.
Curiosamente, al leer todo el mapa de ruta, aunque no se menciona directamente a Hyperliquid, el diseño está casi en todas partes orientado a las fortalezas de Hyperliquid. Es como si Solana dijera: "Lo que tienes en Hyperliquid, nosotros también lo queremos, ¡y lo haremos mejor!"
Hyperliquid ocupa una posición dominante en el mercado de contratos perpetuos en la cadena, con un volumen de operaciones que llegó a representar alrededor del 65% de todo el mercado perpetuo descentralizado. Ante un competidor así, Solana claramente no está dispuesta a ser superada por los recién llegados, por lo que ha lanzado esta hoja de ruta ICM.
Entonces, ¿qué está pasando realmente con este "espectáculo de imitaciones"? ¿Puede Solana realmente alcanzar e incluso superar a Hyperliquid? Profundicemos en este tema.
Fondo y contenido de ICM
¿Quién está liderando esta transformación?
Participan en la elaboración de la hoja de ruta los jugadores más importantes del ecosistema de Solana:
Solana Foundation/Labs: El "padre" 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 así como ConsenSys de Ethereum. Han asumido muchas tareas clave de tecnología en esta hoja de ruta, como el nuevo protocolo de consenso Alpenglow.
Jito Labs: Proveedor de infraestructura MEV en Solana, con una gran influencia, controla casi todo el flujo de MEV en Solana con el "poder de vida y muerte". Esta vez, lideran la provisión del Block Assembly Marketplace (BAM) y otros esquemas de ordenamiento de transacciones.
Multicoin Capital: una conocida institución de inversión en criptomonedas, también es uno de los primeros partidarios de Solana. Debido a su gran posesión de SOL y derechos en proyectos del ecosistema, tiene una considerable influencia en la dirección técnica.
DoubleZero: un equipo enfocado en acelerar la comunicación 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 modelo de emparejamiento fuera de la cadena, lo que resultaba un poco difícil al enfrentarse a Hyperliquid completamente en la cadena; esta vez, al participar en la elaboración de la hoja de ruta, claramente espera aprovechar la actualización de la infraestructura para recuperarse.
el problema central a resolver
El enfoque del mapa de ruta es la mejora de la microestructura del mercado. En otras palabras, el actual mecanismo de transacciones en cadena no es lo suficientemente amigable para los creadores de mercado, lo que significa que los Takers, que inician activamente las transacciones, se benefician, mientras que los Market Makers ( pierden. 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 asegurar que sus transacciones se ejecuten primero, mientras que los Makers a menudo no tienen tiempo para cancelar órdenes y se ven obligados a ejecutar a precios desfavorables.
Algunos traders de alta frecuencia aprovecharán esta asimetría para llevar a cabo 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, los arbitrajistas pueden ejecutar órdenes a precios antiguos, haciendo que los creadores de mercado asuman pérdidas. El resultado es que el Maker, para protegerse, ya sea ampliará el diferencial de compra y venta, o reducirá la cantidad de órdenes, lo que provocará que la liquidez del mercado en general se vea afectada.
El mapa de ruta 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 dividió este gran plan en tres fases:
Corto plazo###1-3 meses(: se centra en optimizar la experiencia de las transacciones en la cadena existente, mejorar la usabilidad de las aplicaciones de libro de órdenes y reducir la interferencia maliciosa de MEV. Específicamente incluye:
El mercado 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 de que se lance la ejecución controlada por aplicaciones de ACE), permitiendo que los contratos inteligentes en Solana tengan el derecho de ordenar las transacciones de manera autónoma.
El equipo de Anza optimizó la tasa de éxito de "entrada de transacciones en el mismo Slot", reduciendo así el deslizamiento y las pérdidas de MEV.
Estas mejoras se espera que se implementen de manera gradual 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, lo que reduce significativamente la latencia y aumenta el rendimiento:
Despliegue de una red de fibra óptica dedicada a DoubleZero, proporcionando a los validadores comunicaciones de alta velocidad con casi cero fluctuaciones y una reducción de la latencia de hasta 100 ms.
Lanzamiento del protocolo de consenso Alpenglow, que reduce 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 ), reduce el bloqueo de la ejecución de transacciones en el consenso.
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 que múltiples validadores propongan transacciones simultáneamente en sus respectivos pipelines, y luego combina y ordena estos bloques paralelos según la tarifa de prioridad. De esta manera, se debilita el monopolio de un único empaquetador y se mejora la resistencia a la censura.
Ejecución controlada por aplicaciones )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.
Hasta aquí, el trasfondo de la propuesta del roadmap ICM debería ser el siguiente: el DEX tradicional Drift en Solana fue superado por el recién llegado Hyperliquid, que ofrece una excelente experiencia 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 transformación técnica llamado ICM, afirmando que iban a replicar todas las habilidades clave de Hyperliquid para ayudar a Drift a volver a competir en el mercado de DEX. Sin embargo, los "grandes" también mencionaron que la dificultad de esta transformación técnica es enorme, por lo que dividieron el plan técnico en una estrategia de tres pasos, y el equipo que podrán proporcionar a Drift en el corto plazo es solo el BAM de Jito, para que Drift lo utilice provisionalmente y pueda comparar con Hyperliquid.
Con el contexto de la historia claro, en los próximos capítulos, analizaremos en detalle qué habilidades distintivas 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, mientras que los creadores sufren las consecuencias del "flujo tóxico". Los usuarios que activamente aceptan órdenes pueden iniciar transacciones en las órdenes de la cadena basándose en el último precio fuera de la cadena, y al aumentar las tarifas de transacción pueden completar la operación prioritariamente, mientras que los creadores de mercado a menudo no tienen tiempo para actualizar o retirar órdenes. Como resultado, los creadores de mercado tienen que 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 )
La hoja de ruta de ICM propone el concepto de ACE###Application Controlled Execution(, que consiste en descentralizar el derecho a ordenar transacciones a las aplicaciones en cada cadena, permitiendo que las aplicaciones decidan cómo ordenar y ejecutar 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 para obtener el precio más reciente del oráculo antes de ejecutar grandes transacciones, asegurando que los pedidos se emparejen a un precio razonable y actualizado, evitando así que las cotizaciones de los creadores de mercado se basen en precios obsoletos y sean objeto de arbitraje.
Ejecución prioritaria de cancelación de órdenes: la aplicación puede establecer que la "solicitud de cancelación" tenga prioridad sobre la nueva "transacción de ejecución", lo que permite al maker retirar su orden en caso de que el mercado se vuelva desfavorable.
Subasta al final 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 de "seguir". Quien esté dispuesto a devolver el mayor beneficio al protocolo ) o al usuario (, el protocolo DeFi permitirá que su transacción se ejecute junto a 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 JITO: plan de transición
Antes del lanzamiento oficial de ACE, Jito Labs 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 seguro de TEE, ocultando el contenido de la transacción al exterior antes de la ejecución ). A través de los plugins, los desarrolladores de aplicaciones pueden personalizar varias reglas de ordenación para sus contratos, como dar prioridad a las cancelaciones, actualizar los precios de los oráculos 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 se implemente en la cadena; funcionalmente es muy similar al ACE definitivo, solo que opera en una red independiente fuera de la cadena, en lugar de estar integrado en el protocolo de la cadena principal de Solana.
Es importante destacar que Jito anteriormente proporcionaba infraestructura destinada a la extracción de MEV (, como Jito Block Engine ), cuyo modelo comercial se basa en optimizar el orden de las transacciones para crear oportunidades para los arbitrajistas y compartir ganancias. Esto, en cierto sentido, es una "lanza" que se sitúa en oposición 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 ( mempool ) dirigida a robots de arbitraje, 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 aún más con esta idea: esencialmente convierte el mecanismo de orden originalmente utilizado para el arbitraje de MEV en un "escudo" para proteger a los proveedores de liquidez como los creadores de mercado, por ejemplo, priorizando la cancelación forzada de órdenes para evitar que los creadores de mercado sufran pérdidas, e introduciendo incentivos de puja para reducir las ganancias por adelantado. Los buscadores de MEV originales, si quieren ganar dinero, deben cambiar de rol y escribir complementos de BAM para servir a los protocolos DeFi, obteniendo ganancias a través de las tarifas de los complementos.
( consultar a HYPERLIQUID
El enfoque ACE/BAM mencionado anteriormente se puede considerar como una forma de alcanzar el mecanismo de emparejamiento en cadena de Hyperliquid. Hyperliquid es una cadena dedicada )Appchain(, que está diseñada 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 están más orientadas a los proveedores de liquidez, y ya ha implementado en la capa de cadena muchos diseños para proteger a los creadores de mercado, como:
Prioridad en la protección de las órdenes: las órdenes de cancelación y las órdenes maker son procesadas con prioridad, evitando que los creadores de mercado sean ejecutados desfavorablemente sin conocimiento. La "prioridad en la ejecución de cancelaciones" mencionada por Solana ACE ha sido practicada por Hyperliquid durante muchos años.
Garantía de precio más reciente: El proceso de liquidación y emparejamiento de Hyperliquid enfatiza el uso de los últimos precios de oráculos y el estado de margen para realizar una "doble verificación". Por ejemplo, cuando se ejecuta un pedido, el sistema vuelve a obtener el último precio del oráculo para evaluar el margen de ambas partes, asegurando que no haya riesgos debido a retrasos en los precios. Esto es similar a cómo ACE inserta actualizaciones de oráculos antes de la ejecución de la transacción.
Protección contra autoservicio: si una misma dirección compra y vende al mismo tiempo, Hyperliquid cancela automáticamente en lugar de ejecutar la operación, para evitar el lavado de operaciones o costos innecesarios.
El ACE/BAM de Solana ICM, sin duda, está "aprendiendo" de Hyperliquid. Hyperliquid, como líder en CLOB en la cadena, ha implementado una serie de mecanismos amigables para los creadores de mercado mediante una cadena exclusiva. Ahora, Solana espera replicar este efecto utilizando cadenas generales y complementos modularizados, es decir, que cada aplicación tenga un control similar al de Hyperliquid sobre el orden de las transacciones.
Imitación dos: Finalidad 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 requiere acumular aproximadamente 32 bloques posteriores en la cadena ), lo que normalmente toma alrededor de 13 segundos ### para ser anclado como "finalizado ( Finalized )". Para ciertas aplicaciones ( como el trading de alta frecuencia ), el tiempo de confirmación final de unos segundos sigue siendo demasiado largo.
HyperBFT es el algoritmo de consenso desarrollado internamente por Hyperliquid, inspirado en el consenso HotStuff, que utiliza una confirmación de bloque de dos rondas de votación para lograr "finalidad instantánea".
Ronda 1: Votación previa ( Prevote ): Una vez que los validadores reciben el bloque candidato transmitido por el Proponente, realizarán una verificación rápida. Si la verificación es exitosa, cada validador emitirá un voto de "votación previa" ( 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 recogido los Prevotes de más de dos tercios de los validadores sobre el mismo bloque candidato, obtiene suficiente confianza en que la mayoría de los miembros de la red respaldan este bloque. Entonces, ese validador emitirá un voto de "precompromiso" más significativo (Precommit) y