Solana persigue a Hyperliquid: un ambicioso espectáculo de imitación
Recientemente, ocurrió algo interesante en el ecosistema de Solana. La Fundación Solana, Anza, Jito Labs y otros jugadores importantes lanzaron conjuntamente una hoja de ruta técnica llamada "Internet Capital Markets, ICM(". El núcleo de esta hoja de ruta es el concepto de "Application Controlled Execution, ACE)", cuyo objetivo es permitir que las aplicaciones en la cadena controlen el orden de las transacciones a nivel de milisegundos, creando una "Wall Street en la cadena" descentralizada.
Aunque el roadmap no menciona directamente a Hyperliquid, al leerlo detenidamente no es difícil darse cuenta de que su diseño está casi por todas partes dirigido a las fortalezas de Hyperliquid. Es como si Solana dijera: "Lo que tú, Hyperliquid, tienes, nosotros también lo queremos, ¡y lo haremos mejor!"
Para saberlo, Hyperliquid ha dominado el mercado de contratos perpetuos en cadena, y su volumen de negociación llegó a representar alrededor del 65% de todo el mercado de contratos perpetuos descentralizados. Ante un competidor tan fuerte, Solana claramente no está dispuesta a ser superada, por lo que lanzó este mapa de ruta de ICM.
Entonces, ¿qué está pasando realmente con este "show de imitaciones"? ¿Puede Solana realmente alcanzar o incluso superar a Hyperliquid? Vamos a analizarlo más a fondo.
Fondo y contenido de ICM
( ¿Quién está liderando esta transformación?
Participan en la elaboración de la hoja de ruta jugadores de peso del ecosistema de Solana:
Solana Foundation/Labs: El "papá" de Solana, encargado 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. Responsable de muchos avances técnicos clave, como el nuevo protocolo de consenso Alpenglow.
Jito Labs: proveedor de infraestructura MEV en Solana, con una gran influencia. Dominan la oferta del Block Assembly Marketplace )BAM### y otros esquemas de ordenamiento de transacciones.
Multicoin Capital: una famosa institución de inversión en criptomonedas, primer patrocinador de Solana. Posee una gran cantidad de SOL y participaciones en proyectos del ecosistema, teniendo una considerable influencia 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.
Drift: el proyecto DEX líder en contratos perpetuos en Solana. Anteriormente utilizaba un modelo de emparejamiento fuera de la cadena, y se ha visto un poco abrumado frente a Hyperliquid completamente en cadena, con la esperanza de aprovechar la actualización de la capa base para recuperarse.
( el problema central a resolver
El mapa de ruta se centra en mejorar la microestructura del mercado, principalmente para abordar el problema de que el mecanismo de transacción en cadena actual no es lo suficientemente amigable para los creadores de mercado. Actualmente, la parte que inicia activamente la transacción, Taker), a menudo tiene la ventaja, mientras que la parte que espera a que se ejecute la orden, Maker###, se encuentra en desventaja. Esto se debe a que Taker generalmente tiene la información más reciente y puede asegurar la ejecución prioritaria de la transacción al aumentar las tarifas, mientras que Maker a menudo no tiene tiempo para cancelar la orden y se ve obligado a ejecutar a un precio desfavorable.
Algunos arbitrajistas de alta frecuencia aprovecharán esta asimetría para lanzar ataques de "tráfico tóxico". Por ejemplo, cuando el precio en la cadena aún no se ha actualizado pero el precio fuera de la cadena ya ha cambiado, los arbitrajistas pueden utilizar el precio antiguo para ejecutar las órdenes de los creadores de mercado, haciendo que estos asuman pérdidas. Para protegerse, los creadores de mercado o amplían el diferencial de compra-venta, o reducen el volumen de órdenes, lo que provoca un deterioro en la liquidez del mercado en su conjunto.
El mapa de ruta de ICM busca equilibrar este patrón y atraer liquidez de alta calidad de vuelta a la cadena.
( El enfoque en tres pasos de ICM
Solana divide este gran plan en tres etapas:
Corto plazo ) 1-3 meses (: Optimizar principalmente la experiencia de transacción en la cadena existente, hacer que las aplicaciones basadas en libros de órdenes sean más útiles y reducir la interferencia maliciosa de MEV. Incluye:
El Marketplace de Block Assembly de Jito Labs ) BAM ### ha lanzado el módulo en la mainnet. Este es un sistema de complemento temporal antes del lanzamiento del ACE definitivo, que permite a los contratos inteligentes de Solana tener el derecho de ordenar las transacciones de forma autónoma.
El equipo de Anza optimiza la tasa de éxito de "entrada en el mismo Slot" en las transacciones, reduciendo 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 significativamente la latencia y aumentando el rendimiento:
Desplegar una red de fibra óptica dedicada 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.
Largo plazo ( 9-30 meses ): realizar una actualización revolucionaria de la arquitectura central de Solana, con el objetivo de lograrlo alrededor de 2027:
Múltiples líderes concurrentes (Multiple Concurrent Leaders, MCL): Permite a múltiples validadores proponer transacciones simultáneamente en sus respectivos pipelines, y luego fusionar y ordenar estos bloques paralelos según las tarifas de prioridad. Esto puede debilitar el monopolio de un único empaquetador y mejorar la resistencia a la censura.
Ejecución Controlada por Aplicación (, ACE) función: otorga realmente a los contratos inteligentes en la cadena el poder de controlar el orden de ejecución de las transacciones.
Analizando hasta aquí, la historia detrás de este roadmap de ICM podría ser la 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, al no poder competir, tuvo que recurrir a "grandes" como Solana Labs, Anza y Jito. Estos "grandes" propusieron el plan de transformación técnica ICM, afirmando que iban a copiar las habilidades exclusivas de Hyperliquid para ayudar a Drift a volver a competir en el mercado de DEX. Sin embargo, los "grandes" también señalaron que esta transformación técnica es extremadamente difícil, por lo que han dividido el plan técnico en una estrategia de tres pasos, y por el momento, lo único que pueden ofrecer a Drift es el BAM de Jito, para que Drift pueda usarlo temporalmente y competir un poco con Hyperliquid.
Entendiendo este contexto, a continuación analizaremos en detalle qué ventajas clave ha imitado y replicado ICM de Hyperliquid.
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 "transacciones tóxicas". Los usuarios que activamente toman órdenes pueden iniciar transacciones en las órdenes en cadena instantáneamente basándose en el último precio fuera de la cadena, y pueden priorizar la ejecución aumentando las tarifas de transacción, mientras que los creadores de mercado a menudo no tienen tiempo para actualizar o retirar órdenes. 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(
La hoja de ruta de ICM propone el concepto de ACE)Application Controlled Execution###, que descentraliza el derecho de 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 implementa ACE, los contratos DeFi pueden establecer las siguientes reglas personalizadas de ordenación de transacciones:
Inserción de 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 que se realicen grandes transacciones, asegurando que los pedidos se emparejen al precio razonable más reciente, evitando que las cotizaciones de los creadores de mercado se basen en precios desactualizados y sean objeto de arbitraje.
Prioridad de anulación de órdenes: la aplicación puede establecer que la "solicitud de anulación de órdenes" tenga prioridad sobre la nueva "transacción de órdenes de compra", permitiendo que el maker tenga la oportunidad de retirar su orden pendiente a tiempo en caso de condiciones de mercado desfavorables.
Subasta de cola de 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 "seguirle". Quien esté dispuesto a devolver el mayor beneficio al protocolo ( o al usuario ), el protocolo DeFi hará que su transacción se ejecute justo después de la gran orden. Las aplicaciones DeFi pueden devolver los ingresos de la subasta a los usuarios, convirtiendo así el flujo MEV tóxico en ingresos benignos.
( BAM de JITO: plan de transición
Antes de que ACE se lanzara oficialmente, 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 Leader 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 prioridad en la cancelación de órdenes, actualización del precio del oráculo antes de la conciliación, e incluso ejecutar pujas 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 se puede considerar como un campo de pruebas antes de la cadena de ACE, funcionalmente es muy similar al 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 había estado proporcionando infraestructura orientada a la extracción de MEV (, como el Jito Block Engine ), 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, se presenta como una "lanza" que se opone 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 ) destinada 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 dañino y a mantener la equidad de los usuarios.
La introducción de BAM se alinea aún más con esta idea: en esencia, convierte el mecanismo de orden originalmente utilizado para el arbitraje 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 de los que hacen frontrunning. Los buscadores de MEV originales, si quieren ganar dinero, deben cambiar de rol, desarrollar complementos de BAM para servir a los protocolos DeFi y obtener ganancias a través de las tarifas de los complementos.
( buscar consejo de HYPERLIQUID
El enfoque ACE/BAM mencionado anteriormente se puede ver como una especie de seguimiento del mecanismo de emparejamiento en cadena de Hyperliquid. Hyperliquid es una cadena dedicada )Appchain(, que está intrínsecamente 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 hacia los proveedores de liquidez, ya que ya se han implementado muchas protecciones para los creadores de mercado en la capa de la cadena, por ejemplo:
Prioridad de protección para las órdenes colgadas: las cancelaciones y las órdenes de solo maker se procesan con prioridad, evitando que los creadores de mercado sean perjudicados sin 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 últimos precios de los oráculos y el estado del margen para realizar una "doble verificación". Por ejemplo, cuando hay órdenes emparejadas, el sistema volverá 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 del oráculo antes de ejecutar las transacciones.
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.
Sin duda, el ACE/BAM de ICM de Solana está "aprendiendo" de Hyperliquid. Hyperliquid, como líder en CLOB en la cadena, ha implementado varios mecanismos amigables para los creadores de mercado utilizando una cadena exclusiva. Ahora, Solana espera replicar este efecto utilizando una cadena general 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 obtiene 2/3 de votos y se considera "confirmado ### Confirmed (", pero se necesita acumular en la cadena aproximadamente 32 bloques posteriores ), lo que normalmente toma alrededor de 13 segundos ### para ser anclado como "finalizado ( Finalized )". Para algunas 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 mediante dos rondas de votación para lograr la "finalidad instantánea".
Primera ronda: Pre-voto (Prevote): Después de que los validadores reciben el bloque candidato transmitido por el Proposer, realizan una validación rápida. Si la validación es exitosa, cada validador emitirá un voto de "pre-voto" (Prevote) y lo transmitirá a toda la red. Este voto representa: "Lo he revisado preliminarmente, este bloque está bien."
Segunda ronda: Precompromiso ( Precommit ): Una vez que un validador ha recopilado el Prevoto de más de dos tercios de los validadores sobre el mismo bloque candidato, tiene suficiente confianza en que la mayoría de los miembros de la red aprueban este bloque. Entonces, ese validador emitirá un voto de "precompromiso" más significativo ( Precommit ) y lo transmitirá. Este voto representa: "He visto que la mayoría de la red está de acuerdo, estoy listo para escribir oficialmente este bloque en el libro mayor."
¡Cuando un validador ha recopilado el Precommit de más de dos tercios de los validadores para el mismo bloque candidato, se alcanza el consenso! Este bloque se considera finalmente confirmado (Finalizado). Se añadirá de forma permanente e irreversible.
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.
16 me gusta
Recompensa
16
3
Republicar
Compartir
Comentar
0/400
GateUser-aa7df71e
· 07-31 07:15
La correa para perros también debe tener su propia actitud.
Ver originalesResponder0
BearMarketBarber
· 07-29 19:06
¡No se puede aprender, tiene estilo! Sigue teniendo ese sabor.
Ver originalesResponder0
MoonMathMagic
· 07-29 19:06
¿Con esa poca habilidad intentas aprender de los demás?
Solana lanza la hoja de ruta ICM imitando completamente las ventajas centrales de Hyperliquid
Solana persigue a Hyperliquid: un ambicioso espectáculo de imitación
Recientemente, ocurrió algo interesante en el ecosistema de Solana. La Fundación Solana, Anza, Jito Labs y otros jugadores importantes lanzaron conjuntamente una hoja de ruta técnica llamada "Internet Capital Markets, ICM(". El núcleo de esta hoja de ruta es el concepto de "Application Controlled Execution, ACE)", cuyo objetivo es permitir que las aplicaciones en la cadena controlen el orden de las transacciones a nivel de milisegundos, creando una "Wall Street en la cadena" descentralizada.
Aunque el roadmap no menciona directamente a Hyperliquid, al leerlo detenidamente no es difícil darse cuenta de que su diseño está casi por todas partes dirigido a las fortalezas de Hyperliquid. Es como si Solana dijera: "Lo que tú, Hyperliquid, tienes, nosotros también lo queremos, ¡y lo haremos mejor!"
Para saberlo, Hyperliquid ha dominado el mercado de contratos perpetuos en cadena, y su volumen de negociación llegó a representar alrededor del 65% de todo el mercado de contratos perpetuos descentralizados. Ante un competidor tan fuerte, Solana claramente no está dispuesta a ser superada, por lo que lanzó este mapa de ruta de ICM.
Entonces, ¿qué está pasando realmente con este "show de imitaciones"? ¿Puede Solana realmente alcanzar o incluso superar a Hyperliquid? Vamos a analizarlo más a fondo.
Fondo y contenido de ICM
( ¿Quién está liderando esta transformación?
Participan en la elaboración de la hoja de ruta jugadores de peso del ecosistema de Solana:
Solana Foundation/Labs: El "papá" de Solana, encargado 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. Responsable de muchos avances técnicos clave, como el nuevo protocolo de consenso Alpenglow.
Jito Labs: proveedor de infraestructura MEV en Solana, con una gran influencia. Dominan la oferta del Block Assembly Marketplace )BAM### y otros esquemas de ordenamiento de transacciones.
Multicoin Capital: una famosa institución de inversión en criptomonedas, primer patrocinador de Solana. Posee una gran cantidad de SOL y participaciones en proyectos del ecosistema, teniendo una considerable influencia 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.
Drift: el proyecto DEX líder en contratos perpetuos en Solana. Anteriormente utilizaba un modelo de emparejamiento fuera de la cadena, y se ha visto un poco abrumado frente a Hyperliquid completamente en cadena, con la esperanza de aprovechar la actualización de la capa base para recuperarse.
( el problema central a resolver
El mapa de ruta se centra en mejorar la microestructura del mercado, principalmente para abordar el problema de que el mecanismo de transacción en cadena actual no es lo suficientemente amigable para los creadores de mercado. Actualmente, la parte que inicia activamente la transacción, Taker), a menudo tiene la ventaja, mientras que la parte que espera a que se ejecute la orden, Maker###, se encuentra en desventaja. Esto se debe a que Taker generalmente tiene la información más reciente y puede asegurar la ejecución prioritaria de la transacción al aumentar las tarifas, mientras que Maker a menudo no tiene tiempo para cancelar la orden y se ve obligado a ejecutar a un precio desfavorable.
Algunos arbitrajistas de alta frecuencia aprovecharán esta asimetría para lanzar ataques de "tráfico tóxico". Por ejemplo, cuando el precio en la cadena aún no se ha actualizado pero el precio fuera de la cadena ya ha cambiado, los arbitrajistas pueden utilizar el precio antiguo para ejecutar las órdenes de los creadores de mercado, haciendo que estos asuman pérdidas. Para protegerse, los creadores de mercado o amplían el diferencial de compra-venta, o reducen el volumen de órdenes, lo que provoca un deterioro en la liquidez del mercado en su conjunto.
El mapa de ruta de ICM busca equilibrar este patrón y atraer liquidez de alta calidad de vuelta a la cadena.
( El enfoque en tres pasos de ICM
Solana divide este gran plan en tres etapas:
Corto plazo ) 1-3 meses (: Optimizar principalmente la experiencia de transacción en la cadena existente, hacer que las aplicaciones basadas en libros de órdenes sean más útiles y reducir la interferencia maliciosa de MEV. Incluye:
El Marketplace de Block Assembly de Jito Labs ) BAM ### ha lanzado el módulo en la mainnet. Este es un sistema de complemento temporal antes del lanzamiento del ACE definitivo, que permite a los contratos inteligentes de Solana tener el derecho de ordenar las transacciones de forma autónoma.
El equipo de Anza optimiza la tasa de éxito de "entrada en el mismo Slot" en las transacciones, reduciendo 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 significativamente la latencia y aumentando el rendimiento:
Desplegar una red de fibra óptica dedicada 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.
Largo plazo ( 9-30 meses ): realizar una actualización revolucionaria de la arquitectura central de Solana, con el objetivo de lograrlo alrededor de 2027:
Múltiples líderes concurrentes (Multiple Concurrent Leaders, MCL): Permite a múltiples validadores proponer transacciones simultáneamente en sus respectivos pipelines, y luego fusionar y ordenar estos bloques paralelos según las tarifas de prioridad. Esto puede debilitar el monopolio de un único empaquetador y mejorar la resistencia a la censura.
Ejecución Controlada por Aplicación (, ACE) función: otorga realmente a los contratos inteligentes en la cadena el poder de controlar el orden de ejecución de las transacciones.
Analizando hasta aquí, la historia detrás de este roadmap de ICM podría ser la 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, al no poder competir, tuvo que recurrir a "grandes" como Solana Labs, Anza y Jito. Estos "grandes" propusieron el plan de transformación técnica ICM, afirmando que iban a copiar las habilidades exclusivas de Hyperliquid para ayudar a Drift a volver a competir en el mercado de DEX. Sin embargo, los "grandes" también señalaron que esta transformación técnica es extremadamente difícil, por lo que han dividido el plan técnico en una estrategia de tres pasos, y por el momento, lo único que pueden ofrecer a Drift es el BAM de Jito, para que Drift pueda usarlo temporalmente y competir un poco con Hyperliquid.
Entendiendo este contexto, a continuación analizaremos en detalle qué ventajas clave ha imitado y replicado ICM de Hyperliquid.
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 "transacciones tóxicas". Los usuarios que activamente toman órdenes pueden iniciar transacciones en las órdenes en cadena instantáneamente basándose en el último precio fuera de la cadena, y pueden priorizar la ejecución aumentando las tarifas de transacción, mientras que los creadores de mercado a menudo no tienen tiempo para actualizar o retirar órdenes. 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(
La hoja de ruta de ICM propone el concepto de ACE)Application Controlled Execution###, que descentraliza el derecho de 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 implementa ACE, los contratos DeFi pueden establecer las siguientes reglas personalizadas de ordenación de transacciones:
Inserción de 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 que se realicen grandes transacciones, asegurando que los pedidos se emparejen al precio razonable más reciente, evitando que las cotizaciones de los creadores de mercado se basen en precios desactualizados y sean objeto de arbitraje.
Prioridad de anulación de órdenes: la aplicación puede establecer que la "solicitud de anulación de órdenes" tenga prioridad sobre la nueva "transacción de órdenes de compra", permitiendo que el maker tenga la oportunidad de retirar su orden pendiente a tiempo en caso de condiciones de mercado desfavorables.
Subasta de cola de 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 "seguirle". Quien esté dispuesto a devolver el mayor beneficio al protocolo ( o al usuario ), el protocolo DeFi hará que su transacción se ejecute justo después de la gran orden. Las aplicaciones DeFi pueden devolver los ingresos de la subasta a los usuarios, convirtiendo así el flujo MEV tóxico en ingresos benignos.
( BAM de JITO: plan de transición
Antes de que ACE se lanzara oficialmente, 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 Leader 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 prioridad en la cancelación de órdenes, actualización del precio del oráculo antes de la conciliación, e incluso ejecutar pujas 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 se puede considerar como un campo de pruebas antes de la cadena de ACE, funcionalmente es muy similar al 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 había estado proporcionando infraestructura orientada a la extracción de MEV (, como el Jito Block Engine ), 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, se presenta como una "lanza" que se opone 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 ) destinada 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 dañino y a mantener la equidad de los usuarios.
La introducción de BAM se alinea aún más con esta idea: en esencia, convierte el mecanismo de orden originalmente utilizado para el arbitraje 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 de los que hacen frontrunning. Los buscadores de MEV originales, si quieren ganar dinero, deben cambiar de rol, desarrollar complementos de BAM para servir a los protocolos DeFi y obtener ganancias a través de las tarifas de los complementos.
( buscar consejo de HYPERLIQUID
El enfoque ACE/BAM mencionado anteriormente se puede ver como una especie de seguimiento del mecanismo de emparejamiento en cadena de Hyperliquid. Hyperliquid es una cadena dedicada )Appchain(, que está intrínsecamente 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 hacia los proveedores de liquidez, ya que ya se han implementado muchas protecciones para los creadores de mercado en la capa de la cadena, por ejemplo:
Prioridad de protección para las órdenes colgadas: las cancelaciones y las órdenes de solo maker se procesan con prioridad, evitando que los creadores de mercado sean perjudicados sin 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 últimos precios de los oráculos y el estado del margen para realizar una "doble verificación". Por ejemplo, cuando hay órdenes emparejadas, el sistema volverá 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 del oráculo antes de ejecutar las transacciones.
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.
Sin duda, el ACE/BAM de ICM de Solana está "aprendiendo" de Hyperliquid. Hyperliquid, como líder en CLOB en la cadena, ha implementado varios mecanismos amigables para los creadores de mercado utilizando una cadena exclusiva. Ahora, Solana espera replicar este efecto utilizando una cadena general 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 obtiene 2/3 de votos y se considera "confirmado ### Confirmed (", pero se necesita acumular en la cadena aproximadamente 32 bloques posteriores ), lo que normalmente toma alrededor de 13 segundos ### para ser anclado como "finalizado ( Finalized )". Para algunas 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 mediante dos rondas de votación para lograr la "finalidad instantánea".
Primera ronda: Pre-voto (Prevote): Después de que los validadores reciben el bloque candidato transmitido por el Proposer, realizan una validación rápida. Si la validación es exitosa, cada validador emitirá un voto de "pre-voto" (Prevote) y lo transmitirá a toda la red. Este voto representa: "Lo he revisado preliminarmente, este bloque está bien."
Segunda ronda: Precompromiso ( Precommit ): Una vez que un validador ha recopilado el Prevoto de más de dos tercios de los validadores sobre el mismo bloque candidato, tiene suficiente confianza en que la mayoría de los miembros de la red aprueban este bloque. Entonces, ese validador emitirá un voto de "precompromiso" más significativo ( Precommit ) y lo transmitirá. Este voto representa: "He visto que la mayoría de la red está de acuerdo, estoy listo para escribir oficialmente este bloque en el libro mayor."
¡Cuando un validador ha recopilado el Precommit de más de dos tercios de los validadores para el mismo bloque candidato, se alcanza el consenso! Este bloque se considera finalmente confirmado (Finalizado). Se añadirá de forma permanente e irreversible.