Hoja de ruta de Solana ICM: un "show de imitaciones" dirigido a Hyperliquid
Recientemente, varios grandes nombres del ecosistema de Solana se reunieron para publicar una hoja de ruta técnica titulada "Mercados de Capitales de Internet ( 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 ordenar transacciones de forma autónoma en milisegundos, creando un "Wall Street en 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 dirigido 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 cadena, con un volumen de transacciones que llegó a representar alrededor del 65% de todo el mercado de contratos perpetuos descentralizados. Evidentemente, frente a competidores así, Solana no está dispuesta a ser superada por los recién llegados, por lo que lanzó esta hoja de ruta ICM.
Entonces, ¿qué es exactamente este "show de imitación"? ¿Puede Solana realmente alcanzar o incluso superar a Hyperliquid? Vamos a profundizar en este tema.
Fondo y contenido de ICM
¿Quién está liderando esta transformación?
Los participantes en la elaboración de la hoja de ruta son 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 ex miembros de Solana Labs, que ha asumido muchas de las tareas críticas de tecnología, como el nuevo protocolo de consenso Alpenglow.
Jito Labs: Proveedor de infraestructura MEV en Solana, con una influencia enorme, casi controla el "poder de vida y muerte" de todo el tráfico MEV en Solana. Esta vez, lideran la provisión de soluciones de ordenamiento de transacciones como el Block Assembly Marketplace (BAM).
Multicoin Capital: una famosa institución de inversión en criptomonedas y también un temprano partidario de Solana. Tienen una considerable influencia en la dirección técnica.
DoubleZero: un equipo enfocado en acelerar la comunicación de redes, que ofrece soluciones de red óptica dedicada para mejorar la velocidad de comunicación entre nodos de validación de Solana.
Drift: el proyecto DEX líder en contratos perpetuos en Solana. Anteriormente, Drift utilizaba un modelo de emparejamiento fuera de la cadena, y se mostraba algo débil frente a Hyperliquid, que es completamente en cadena. Esta vez, al participar en la elaboración de la hoja de ruta, se evidencia que espera aprovechar la actualización de la infraestructura para recuperarse.
el problema central a resolver
El enfoque de la hoja de ruta está en la mejora de la microestructura del mercado. En otras palabras, el mecanismo de transacción en la cadena actual no es lo suficientemente amigable para los creadores de mercado (Market Maker), es decir, el Taker que inicia activamente la transacción se beneficia, mientras que el Market Maker que espera a que se ejecute su orden sufre pérdidas. Esto se debe a que el Taker a menudo tiene la información más reciente y aumenta activamente la tarifa de transacción para garantizar que su transacción se ejecute con prioridad, mientras que el Maker a menudo no puede retirar su orden a tiempo y se ve obligado a realizar transacciones a precios desfavorables.
Algunos comerciantes de arbitraje de alta frecuencia aprovecharán esta asimetría para lanzar 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, el comerciante de arbitraje puede aprovechar el precio antiguo para ejecutar las órdenes de los creadores de mercado, haciendo que estos últimos asuman las pérdidas. El resultado es que los creadores de mercado, para protegerse, o bien amplían el diferencial de compra-venta, o bien reducen la cantidad de órdenes abiertas, lo que conduce a una disminución de la liquidez en todo el mercado.
El mapa de ruta de ICM busca equilibrar este patrón y atraer liquidez de alta calidad de regreso a la cadena.
Tres pasos de ICM
Solana dividió este ambicioso plan en tres etapas:
Corto plazo (1-3 meses): Principalmente optimizar la experiencia de transacciones en la cadena existente, hacer que las aplicaciones de tipo libro de órdenes sean más fáciles de usar y reducir la interferencia maliciosa de MEV. Esto incluye:
El módulo Block Assembly Marketplace (BAM) de Jito Labs se ha lanzado en la mainnet. La importancia de este módulo es proporcionar un sistema externo temporal antes del lanzamiento de ACE (Ejecución Controlada por Aplicaciones), permitiendo que los contratos inteligentes en Solana tengan el poder de ordenar las transacciones de manera autónoma.
El equipo de Anza optimiza la tasa de éxito de "entrada a la misma Slot" para reducir el deslizamiento y las pérdidas de MEV.
Se espera que estas mejoras se implementen gradualmente entre julio y septiembre de 2025.
A medio plazo (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 a DoubleZero, proporcionando a los validadores comunicaciones de alta velocidad con casi cero jitter 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 (Asynchronous Program Execution, APE), para reducir el bloqueo de la ejecución de transacciones en el consenso.
A largo plazo (9-30 meses): Realizar una actualización revolucionaria de la arquitectura central de Solana, con el objetivo de lograrlo alrededor de 2027:
Líderes Concurrentes Múltiples, MCL(: Permite que múltiples validadores propongan transacciones simultáneamente en sus respectivos pipelines, y luego ordena estos bloques paralelos según la tarifa de prioridad. Esto debilita el monopolio de un solo empaquetador y refuerza la resistencia a la censura.
La ejecución controlada por aplicaciones nativas ), función ACE(: otorga verdaderamente el poder a los contratos inteligentes en la cadena para controlar el orden de ejecución de las transacciones.
Imitación 1: Mecanismo de ordenamiento de transacciones
Problema: La cadena actual se inclina hacia el taker, mientras que el maker sufre el "flujo tóxico". Los usuarios que activamente consumen órdenes pueden iniciar transacciones en las órdenes colgadas en la cadena según el último precio fuera de la cadena, y al aumentar la tarifa de transacción, obtienen prioridad en la ejecución, mientras que los creadores de mercado a menudo no pueden actualizar o retirar sus órdenes a tiempo. El resultado es que los creadores de mercado o ampliarán el diferencial o simplemente retirarán 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 (Ejecución Controlada por la Aplicación), que descentraliza el derecho de ordenamiento de 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 implemente ACE, los contratos DeFi podrán establecer las siguientes reglas personalizadas de ordenamiento de transacciones:
Actualización de precios del oráculo: las aplicaciones DeFi pueden insertar una transacción antes de emparejar grandes transacciones para obtener el último precio del oráculo, asegurando que las órdenes se emparejen al precio razonable más reciente, evitando que las cotizaciones de los creadores de mercado se basen en precios obsoletos y sean objeto de arbitraje.
Prioridad en la cancelación de pedidos: la aplicación puede establecer que la "solicitud de cancelación" se ejecute antes de una nueva "transacción de compra", permitiendo al creador tener la oportunidad de retirar a tiempo la orden en caso de que el mercado sea desfavorable.
Subasta en la 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 de "seguir de cerca". Quien esté dispuesto a devolver la mayor cantidad de beneficios al protocolo (o a los usuarios), el protocolo DeFi permitirá que su transacción se ejecute junto a la gran orden. La aplicación DeFi puede devolver los ingresos de la subasta a los usuarios, convirtiendo así el flujo MEV tóxico en ingresos benéficos.
) 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 reorganizar los paquetes de transacciones (Bundle) bajo la protección de la privacidad (los plugins se ejecutan en un entorno seguro de TEE, ocultando el contenido de las transacciones antes de la ejecución). A través de los plugins, los desarrolladores de aplicaciones pueden personalizar diversas reglas de 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 se implementara en la cadena, su funcionalidad es muy parecida a la ACE definitiva, solo que funciona en una red independiente fuera de la cadena, en lugar de estar integrada en el protocolo de la cadena principal de Solana.
Es importante destacar que Jito ha proporcionado anteriormente infraestructura orientada a la extracción de MEV (como el Jito Block Engine), cuyo modelo de negocio consiste en crear oportunidades para los arbitrajistas al optimizar el orden de las transacciones y compartir los ingresos. Esto, en cierto modo, se posiciona como una "lanza" en contraposición a los usuarios comunes y a aquellos que son objeto de arbitraje. Sin embargo, Jito cerró a principios de 2024 la función de memoria pública para robots de arbitraje )mempool(, con el fin de reducir externalidades negativas como los ataques de sándwich. Esta medida indica que la comunidad de Solana tiende a suprimir el MEV perjudicial y a mantener la equidad para los usuarios.
El lanzamiento de BAM se alinea aún más con esta idea: en esencia, transforma el mecanismo de ordenación originalmente utilizado para el arbitraje de MEV en un "escudo" para proteger a los creadores de mercado y otros proveedores de liquidez, como forzar la anulación de órdenes para evitar que los creadores de mercado sufran pérdidas, e introducir un sistema de incentivos por pujas para reducir las ganancias de los anticipadores. Los buscadores de MEV originales, si quieren ganar dinero, deben cambiar de rol, crear plugins de BAM para servir a los protocolos DeFi y obtener ganancias a través de las tarifas de los plugins.
) buscar consejos de HYPERLIQUID
La idea mencionada de ACE/BAM se puede considerar en realidad como una forma de alcanzar el mecanismo de emparejamiento en la cadena de Hyperliquid. Hyperliquid es una cadena dedicada ###Appchain(, diseñada específicamente para servir a DEX. Además, el HLP Vault operado oficialmente por Hyperliquid es, de hecho, 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 en la capa de la cadena para proteger a los creadores de mercado, como por ejemplo:
Prioridad de protección de las órdenes pendientes: las órdenes de cancelación y las órdenes de maker son procesadas con prioridad, evitando que los creadores de mercado sean perjudicados por transacciones desfavorables sin estar informados. La "ejecución prioritaria de cancelación" mencionada por Solana ACE ya ha sido practicada por Hyperliquid durante años.
Garantía del precio más reciente: El proceso de liquidación y emparejamiento de Hyperliquid enfatiza el uso de los últimos precios de alimentación y el estado de margen para realizar una "doble verificación". Por ejemplo, cuando se ejecuta un emparejamiento de órdenes, 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 del oráculo antes de la ejecución de la transacción.
Protección contra auto-transacciones: Si una misma dirección se 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 Solana ICM está "aprendiendo" de Hyperliquid. Hyperliquid, como líder en CLOB en cadena, ha implementado diversos mecanismos amigables para los creadores de mercado a través de una cadena exclusiva. Ahora, Solana espera replicar este efecto utilizando una cadena general y complementos 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 inmediata
) Comparación de consensos existentes
Solana actualmente utiliza Tower BFT, donde la confirmación y la finalización son probabilísticas y progresivas: un bloque recibe 2/3 de los votos se considera "confirmado ### Confirmed (", pero se necesitan acumular aproximadamente 32 bloques posteriores en la cadena (generalmente alrededor de 13 segundos) para ser anclado como "finalizado ) Finalized (". Para 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 internamente 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: Pre-votación ) Prevote (: Después de que el validador recibe el bloque candidato transmitido por el Proposer, realizará una verificación rápida. Si la verificación es exitosa, cada validador emitirá un voto de "pre-votación" ) Prevote ( para este bloque y lo transmitirá a toda la red. Este voto representa: "Lo he revisado preliminarmente, este bloque no tiene problemas."
Segunda ronda: Precompromiso ) Precommit (: Una vez que un validador ha recopilado los prevotos 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 reconocen este bloque. Así, el validador emitirá un voto de "precompromiso" más contundente ) Precommit ( y lo transmitirá. Este voto representa: "He visto que la mayoría de la red está de acuerdo y estoy listo para escribir oficialmente este bloque en el libro mayor."
¡Cuando un validador ha recolectado el Precommit de más de dos tercios de los validadores sobre el mismo bloque candidato, se alcanza el consenso! Este bloque se considera )Finalizado(. Se añadirá a la cadena de bloques de forma permanente e irreversible.
Esto significa que cada bloque de Hyperliquid es un bloque final, sin posibilidad de bifurcaciones o retrocesos, con un retraso de generación de bloques extremadamente bajo------ La información oficial revela que el retraso promedio de confirmación es de aproximadamente 0.2 segundos, y en el 99% de los casos no supera los 0.9 segundos. Esta certeza final en milisegundos es ideal para el comercio de alta frecuencia, ya que una vez que se emite una transacción, se puede confirmar rápidamente y no puede ser reorganizada, lo que aumenta enormemente la eficiencia de los activos.
) ALPENGLOW logra la finalización instantánea
Alpenglow es un nuevo protocolo de consenso que Solana está preparado para lanzar, con el objetivo de acelerar la confirmación final de bloques a 1-2 slots (aproximadamente 150 ms), logrando algo similar
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.
22 me gusta
Recompensa
22
8
Republicar
Compartir
Comentar
0/400
SquidTeacher
· hace3h
¿Eso es todo? Ni siquiera entiendo lo que estoy copiando.
Ver originalesResponder0
0xOverleveraged
· 08-14 03:33
¿No es solo copiar la tarea? Cambiar la portada por una más bonita.
Ver originalesResponder0
fren.eth
· 08-13 14:30
¿Y qué pasa si copias? Si no tienes la fuerza para emprender un esfuerzo decidido, entonces es en vano copiar.
Ver originalesResponder0
WealthCoffee
· 08-13 03:20
Otra nueva forma de altcoin
Ver originalesResponder0
GasFeeNightmare
· 08-13 03:19
Hmph, SOL solo sabe copiar tareas.
Ver originalesResponder0
MidnightSnapHunter
· 08-13 03:17
Si vas a copiar, ¡cópialo! ¿Qué hay de malo en eso?
Solana imita a Hyperliquid para crear la hoja de ruta ICM y construir Wall Street on-chain
Hoja de ruta de Solana ICM: un "show de imitaciones" dirigido a Hyperliquid
Recientemente, varios grandes nombres del ecosistema de Solana se reunieron para publicar una hoja de ruta técnica titulada "Mercados de Capitales de Internet ( 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 ordenar transacciones de forma autónoma en milisegundos, creando un "Wall Street en 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 dirigido 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 cadena, con un volumen de transacciones que llegó a representar alrededor del 65% de todo el mercado de contratos perpetuos descentralizados. Evidentemente, frente a competidores así, Solana no está dispuesta a ser superada por los recién llegados, por lo que lanzó esta hoja de ruta ICM.
Entonces, ¿qué es exactamente este "show de imitación"? ¿Puede Solana realmente alcanzar o incluso superar a Hyperliquid? Vamos a profundizar en este tema.
Fondo y contenido de ICM
¿Quién está liderando esta transformación?
Los participantes en la elaboración de la hoja de ruta son 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 ex miembros de Solana Labs, que ha asumido muchas de las tareas críticas de tecnología, como el nuevo protocolo de consenso Alpenglow.
Jito Labs: Proveedor de infraestructura MEV en Solana, con una influencia enorme, casi controla el "poder de vida y muerte" de todo el tráfico MEV en Solana. Esta vez, lideran la provisión de soluciones de ordenamiento de transacciones como el Block Assembly Marketplace (BAM).
Multicoin Capital: una famosa institución de inversión en criptomonedas y también un temprano partidario de Solana. Tienen una considerable influencia en la dirección técnica.
DoubleZero: un equipo enfocado en acelerar la comunicación de redes, que ofrece soluciones de red óptica dedicada para mejorar la velocidad de comunicación entre nodos de validación de Solana.
Drift: el proyecto DEX líder en contratos perpetuos en Solana. Anteriormente, Drift utilizaba un modelo de emparejamiento fuera de la cadena, y se mostraba algo débil frente a Hyperliquid, que es completamente en cadena. Esta vez, al participar en la elaboración de la hoja de ruta, se evidencia que espera aprovechar la actualización de la infraestructura para recuperarse.
el problema central a resolver
El enfoque de la hoja de ruta está en la mejora de la microestructura del mercado. En otras palabras, el mecanismo de transacción en la cadena actual no es lo suficientemente amigable para los creadores de mercado (Market Maker), es decir, el Taker que inicia activamente la transacción se beneficia, mientras que el Market Maker que espera a que se ejecute su orden sufre pérdidas. Esto se debe a que el Taker a menudo tiene la información más reciente y aumenta activamente la tarifa de transacción para garantizar que su transacción se ejecute con prioridad, mientras que el Maker a menudo no puede retirar su orden a tiempo y se ve obligado a realizar transacciones a precios desfavorables.
Algunos comerciantes de arbitraje de alta frecuencia aprovecharán esta asimetría para lanzar 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, el comerciante de arbitraje puede aprovechar el precio antiguo para ejecutar las órdenes de los creadores de mercado, haciendo que estos últimos asuman las pérdidas. El resultado es que los creadores de mercado, para protegerse, o bien amplían el diferencial de compra-venta, o bien reducen la cantidad de órdenes abiertas, lo que conduce a una disminución de la liquidez en todo el mercado.
El mapa de ruta de ICM busca equilibrar este patrón y atraer liquidez de alta calidad de regreso a la cadena.
Tres pasos de ICM
Solana dividió este ambicioso plan en tres etapas:
Corto plazo (1-3 meses): Principalmente optimizar la experiencia de transacciones en la cadena existente, hacer que las aplicaciones de tipo libro de órdenes sean más fáciles de usar y reducir la interferencia maliciosa de MEV. Esto incluye:
El módulo Block Assembly Marketplace (BAM) de Jito Labs se ha lanzado en la mainnet. La importancia de este módulo es proporcionar un sistema externo temporal antes del lanzamiento de ACE (Ejecución Controlada por Aplicaciones), permitiendo que los contratos inteligentes en Solana tengan el poder de ordenar las transacciones de manera autónoma.
El equipo de Anza optimiza la tasa de éxito de "entrada a la misma Slot" para reducir el deslizamiento y las pérdidas de MEV.
Se espera que estas mejoras se implementen gradualmente entre julio y septiembre de 2025.
A medio plazo (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 a DoubleZero, proporcionando a los validadores comunicaciones de alta velocidad con casi cero jitter 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 (Asynchronous Program Execution, APE), para reducir el bloqueo de la ejecución de transacciones en el consenso.
A largo plazo (9-30 meses): Realizar una actualización revolucionaria de la arquitectura central de Solana, con el objetivo de lograrlo alrededor de 2027:
Líderes Concurrentes Múltiples, MCL(: Permite que múltiples validadores propongan transacciones simultáneamente en sus respectivos pipelines, y luego ordena estos bloques paralelos según la tarifa de prioridad. Esto debilita el monopolio de un solo empaquetador y refuerza la resistencia a la censura.
La ejecución controlada por aplicaciones nativas ), función ACE(: otorga verdaderamente el poder a los contratos inteligentes en la cadena para controlar el orden de ejecución de las transacciones.
Imitación 1: Mecanismo de ordenamiento de transacciones
Problema: La cadena actual se inclina hacia el taker, mientras que el maker sufre el "flujo tóxico". Los usuarios que activamente consumen órdenes pueden iniciar transacciones en las órdenes colgadas en la cadena según el último precio fuera de la cadena, y al aumentar la tarifa de transacción, obtienen prioridad en la ejecución, mientras que los creadores de mercado a menudo no pueden actualizar o retirar sus órdenes a tiempo. El resultado es que los creadores de mercado o ampliarán el diferencial o simplemente retirarán 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 (Ejecución Controlada por la Aplicación), que descentraliza el derecho de ordenamiento de 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 implemente ACE, los contratos DeFi podrán establecer las siguientes reglas personalizadas de ordenamiento de transacciones:
Actualización de precios del oráculo: las aplicaciones DeFi pueden insertar una transacción antes de emparejar grandes transacciones para obtener el último precio del oráculo, asegurando que las órdenes se emparejen al precio razonable más reciente, evitando que las cotizaciones de los creadores de mercado se basen en precios obsoletos y sean objeto de arbitraje.
Prioridad en la cancelación de pedidos: la aplicación puede establecer que la "solicitud de cancelación" se ejecute antes de una nueva "transacción de compra", permitiendo al creador tener la oportunidad de retirar a tiempo la orden en caso de que el mercado sea desfavorable.
Subasta en la 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 de "seguir de cerca". Quien esté dispuesto a devolver la mayor cantidad de beneficios al protocolo (o a los usuarios), el protocolo DeFi permitirá que su transacción se ejecute junto a la gran orden. La aplicación DeFi puede devolver los ingresos de la subasta a los usuarios, convirtiendo así el flujo MEV tóxico en ingresos benéficos.
) 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 reorganizar los paquetes de transacciones (Bundle) bajo la protección de la privacidad (los plugins se ejecutan en un entorno seguro de TEE, ocultando el contenido de las transacciones antes de la ejecución). A través de los plugins, los desarrolladores de aplicaciones pueden personalizar diversas reglas de 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 se implementara en la cadena, su funcionalidad es muy parecida a la ACE definitiva, solo que funciona en una red independiente fuera de la cadena, en lugar de estar integrada en el protocolo de la cadena principal de Solana.
Es importante destacar que Jito ha proporcionado anteriormente infraestructura orientada a la extracción de MEV (como el Jito Block Engine), cuyo modelo de negocio consiste en crear oportunidades para los arbitrajistas al optimizar el orden de las transacciones y compartir los ingresos. Esto, en cierto modo, se posiciona como una "lanza" en contraposición a los usuarios comunes y a aquellos que son objeto de arbitraje. Sin embargo, Jito cerró a principios de 2024 la función de memoria pública para robots de arbitraje )mempool(, con el fin de reducir externalidades negativas como los ataques de sándwich. Esta medida indica que la comunidad de Solana tiende a suprimir el MEV perjudicial y a mantener la equidad para los usuarios.
El lanzamiento de BAM se alinea aún más con esta idea: en esencia, transforma el mecanismo de ordenación originalmente utilizado para el arbitraje de MEV en un "escudo" para proteger a los creadores de mercado y otros proveedores de liquidez, como forzar la anulación de órdenes para evitar que los creadores de mercado sufran pérdidas, e introducir un sistema de incentivos por pujas para reducir las ganancias de los anticipadores. Los buscadores de MEV originales, si quieren ganar dinero, deben cambiar de rol, crear plugins de BAM para servir a los protocolos DeFi y obtener ganancias a través de las tarifas de los plugins.
) buscar consejos de HYPERLIQUID
La idea mencionada de ACE/BAM se puede considerar en realidad como una forma de alcanzar el mecanismo de emparejamiento en la cadena de Hyperliquid. Hyperliquid es una cadena dedicada ###Appchain(, diseñada específicamente para servir a DEX. Además, el HLP Vault operado oficialmente por Hyperliquid es, de hecho, 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 en la capa de la cadena para proteger a los creadores de mercado, como por ejemplo:
Prioridad de protección de las órdenes pendientes: las órdenes de cancelación y las órdenes de maker son procesadas con prioridad, evitando que los creadores de mercado sean perjudicados por transacciones desfavorables sin estar informados. La "ejecución prioritaria de cancelación" mencionada por Solana ACE ya ha sido practicada por Hyperliquid durante años.
Garantía del precio más reciente: El proceso de liquidación y emparejamiento de Hyperliquid enfatiza el uso de los últimos precios de alimentación y el estado de margen para realizar una "doble verificación". Por ejemplo, cuando se ejecuta un emparejamiento de órdenes, 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 del oráculo antes de la ejecución de la transacción.
Protección contra auto-transacciones: Si una misma dirección se 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 Solana ICM está "aprendiendo" de Hyperliquid. Hyperliquid, como líder en CLOB en cadena, ha implementado diversos mecanismos amigables para los creadores de mercado a través de una cadena exclusiva. Ahora, Solana espera replicar este efecto utilizando una cadena general y complementos 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 inmediata
) Comparación de consensos existentes
Solana actualmente utiliza Tower BFT, donde la confirmación y la finalización son probabilísticas y progresivas: un bloque recibe 2/3 de los votos se considera "confirmado ### Confirmed (", pero se necesitan acumular aproximadamente 32 bloques posteriores en la cadena (generalmente alrededor de 13 segundos) para ser anclado como "finalizado ) Finalized (". Para 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 internamente 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: Pre-votación ) Prevote (: Después de que el validador recibe el bloque candidato transmitido por el Proposer, realizará una verificación rápida. Si la verificación es exitosa, cada validador emitirá un voto de "pre-votación" ) Prevote ( para este bloque y lo transmitirá a toda la red. Este voto representa: "Lo he revisado preliminarmente, este bloque no tiene problemas."
Segunda ronda: Precompromiso ) Precommit (: Una vez que un validador ha recopilado los prevotos 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 reconocen este bloque. Así, el validador emitirá un voto de "precompromiso" más contundente ) Precommit ( y lo transmitirá. Este voto representa: "He visto que la mayoría de la red está de acuerdo y estoy listo para escribir oficialmente este bloque en el libro mayor."
¡Cuando un validador ha recolectado el Precommit de más de dos tercios de los validadores sobre el mismo bloque candidato, se alcanza el consenso! Este bloque se considera )Finalizado(. Se añadirá a la cadena de bloques de forma permanente e irreversible.
Esto significa que cada bloque de Hyperliquid es un bloque final, sin posibilidad de bifurcaciones o retrocesos, con un retraso de generación de bloques extremadamente bajo------ La información oficial revela que el retraso promedio de confirmación es de aproximadamente 0.2 segundos, y en el 99% de los casos no supera los 0.9 segundos. Esta certeza final en milisegundos es ideal para el comercio de alta frecuencia, ya que una vez que se emite una transacción, se puede confirmar rápidamente y no puede ser reorganizada, lo que aumenta enormemente la eficiencia de los activos.
) ALPENGLOW logra la finalización instantánea
Alpenglow es un nuevo protocolo de consenso que Solana está preparado para lanzar, con el objetivo de acelerar la confirmación final de bloques a 1-2 slots (aproximadamente 150 ms), logrando algo similar