Comentario agudo sobre el mapa de ruta de Solana para el "Mercado de capitales de Internet": un "show de imitaciones" para alcanzar a Hyperliquid.

🚀 Introducción: los expertos de SOLANA se reúnen

Recientemente, ocurrió algo muy interesante en el ecosistema de Solana. Un grupo de expertos, incluidos la Fundación Solana, Anza, Jito Labs y otros, 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 pocas palabras, permitir que las aplicaciones en la cadena tengan el poder de ordenar transacciones de manera autónoma en milisegundos, creando un “Wall Street en la cadena” descentralizado.

Sin embargo, lo interesante es que, al leer todo el mapa de ruta, aunque no se menciona directamente a Hyperliquid, el diseño está casi en todas partes dirigido a las fortalezas de Hyperliquid. Es como si Solana dijera: “¡Lo que tú tienes en Hyperliquid, nosotros también lo queremos, y lo haremos mejor!”

Hay que saber que Hyperliquid ocupa una posición dominante en el mercado de contratos perpetuos en cadena, con un volumen de transacciones que llegó a representar alrededor del 65% del mercado de contratos perpetuos descentralizados. Evidentemente, frente a un competidor así, Solana no está dispuesta a ser superada por los recién llegados, por lo que ha lanzado esta hoja de ruta ICM.

Entonces, ¿qué es exactamente este “show de imitaciones”? ¿Puede Solana realmente alcanzar o incluso superar a Hyperliquid? Hoy vamos a profundizar en este tema.

📋 Contexto y contenido de ICM

¿Quién está liderando esta transformación?

Primero, veamos quién elaboró este mapa de ruta. Los participantes son todos jugadores pesados del ecosistema de Solana:

• Solana Foundation/Labs: Esto no necesita mucha explicación, 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, algo así como ConsenSys de Ethereum. Han asumido muchas tareas clave en esta hoja de ruta, como el nuevo protocolo de consenso Alpenglow.
• Jito Labs: Proveedor de infraestructura MEV en Solana, con una gran influencia, casi controla el “poder de vida y muerte” de todo el flujo MEV en Solana. Esta vez, lideran la provisión de soluciones de ordenamiento de transacciones como Block Assembly Marketplace (BAM).
• Multicoin Capital: una conocida institución de inversión en criptomonedas, también es un temprano apoyo de Solana. Debido a su gran cantidad de SOL y derechos sobre proyectos ecológicos, también tiene un considerable poder de 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 de contratos perpetuos líder en Solana. Anteriormente, Drift utilizaba un modelo de emparejamiento fuera de la cadena, y al enfrentar a Hyperliquid completamente en cadena, parecía un poco difícil. Esta vez, al participar en la formulación de la hoja de ruta, claramente espera aprovechar la actualización de la capa base para dar un giro.

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 actual de transacciones en cadena no es lo suficientemente amigable para los creadores de mercado. Esto significa que los Takers, que inician activamente las transacciones, obtienen ventajas, mientras que los Market Makers sufren al esperar la ejecución de sus órdenes. Esto se debe a que los Takers a menudo tienen la información más reciente y aumentan proactivamente las tarifas de transacción para garantizar que sus transacciones sean ejecutadas primero, mientras que los Makers a menudo no tienen tiempo para cancelar sus órdenes y se ven obligados a ejecutar a precios desfavorables.

Algunos comerciantes de arbitraje de alta frecuencia aprovecharán esta asimetría para lanzar un ataque de “tráfico tóxico”. Por ejemplo, si el precio en la cadena aún no se ha actualizado, pero el precio fuera de la cadena ya ha cambiado, el arbitrajista puede aprovechar el precio antiguo para ejecutar las órdenes de los creadores de mercado, haciendo que estos asuman pérdidas. El resultado es que el Maker, para protegerse, tiene que ampliar el diferencial de compra-venta o reducir la cantidad de órdenes pendientes, lo que lleva a una disminución de la liquidez del mercado en su conjunto.

La hoja de ruta de ICM busca equilibrar este patrón y atraer liquidez de alta calidad de regreso a la cadena.

El enfoque en tres pasos de ICM

Solana ha dividido este gran plan en tres etapas:

Corto plazo (1-3 meses): Principalmente se trata de optimizar la experiencia de transacciones en la cadena existente, hacer que las aplicaciones de tipo libro de órdenes sean más útiles 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. El significado de este módulo es proporcionar un sistema externo temporal antes del lanzamiento del ACE (Ejecución Controlada por Aplicación) definitivo, permitiendo que los contratos inteligentes en Solana tengan el derecho de ordenación de transacciones autónomo.
• El equipo de Anza optimiza la tasa de éxito de “entrada de transacciones en el mismo Slot”, reduciendo así el deslizamiento y las pérdidas por MEV.

Estas mejoras se espera que se implementen entre julio y septiembre de 2025.

Mediano plazo (3-9 meses): Introducción de redes de alta velocidad dedicadas y una nueva versión del consenso, reduciendo drásticamente la latencia y aumentando el rendimiento:

• Desplegar una red de fibra óptica dedicada DoubleZero, proporcionando a los validadores comunicación de alta velocidad con casi cero jitter y una reducción de hasta 100 ms en la latencia.
• Se lanza el protocolo de consenso Alpenglow, comprimiendo el tiempo de confirmación final de aproximadamente 12.8 segundos a aproximadamente 0.15 segundos.
• Desarrollo de Ejecución de Programas Asincrónicos ( Asynchronous Program Execution, APE ), reduce el bloqueo de la ejecución de transacciones en el consenso.

A largo plazo (9-30 meses): realizar una actualización revolucionaria de la arquitectura central de Solana, con el objetivo de lograrlo alrededor de 2027:

• Líderes Concurrentes Múltiples, MCL(: permite que múltiples validadores propongan transacciones simultáneamente en sus respectivos pipelines, y luego ordenen estos bloques paralelos según la tarifa de prioridad. Esto puede debilitar el monopolio de un solo empaquetador y fortalecer la resistencia a la censura.
• Ejecución controlada por la aplicación nativa )Application Controlled Execution, función ACE(: otorga verdaderamente a los contratos inteligentes en la cadena el poder de controlar el orden de ejecución de las transacciones.

Al analizar hasta aquí, el autor cree que la historia detrás de la propuesta del mapa de ruta ICM debería ser la siguiente: el antiguo DEX Drift en Solana ha sido superado por el recién llegado Hyperliquid, que ofrece una experiencia excepcional como “Binance en cadena”. Drift, incapaz de competir, se vio obligado a solicitar ayuda a “expertos” como Solana Labs, Anza y Jito. Los “expertos” propusieron un plan de transformación técnica como el ICM, afirmando que iban a replicar todas las habilidades distintivas de Hyperliquid para ayudar a Drift a volver a competir en el mercado de DEX. Sin embargo, los “expertos” también dijeron que esta transformación técnica es extremadamente difícil, por lo que el plan técnico se divide en una estrategia de tres pasos, y el equipo que se puede proporcionar a Drift en el corto plazo es solo el BAM de Jito, para que Drift se las arregle y compita inicialmente con Hyperliquid.

Una vez aclarado el trasfondo de la historia, en los próximos capítulos, el autor analizará en detalle qué habilidades distintivas de Hyperliquid ha imitado y replicado ICM.

) 🎭 Imitación uno: mecanismo de ordenamiento de transacciones

Problema: Como se mencionó antes, la cadena actual favorece a los takers, mientras que los makers sufren “tráfico tóxico”. Los usuarios que toman la iniciativa de comer órdenes pueden basarse en el último precio fuera de la cadena para iniciar transacciones instantáneamente sobre las órdenes en la cadena, y priorizar la ejecución aumentando las tarifas. Los creadores de mercado a menudo no tienen tiempo para actualizar o cancelar ó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: aplicación de ejecución controlada ###ACE(

El roadmap de ICM propone el concepto de ACE (Ejecución Controlada por Aplicaciones), que consiste en delegar el derecho de orden de las 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 Solana, que implementará ACE en el futuro, los contratos DeFi pueden establecer las siguientes reglas personalizadas para el orden de las transacciones:

• Actualización de precios de Oracle: Las aplicaciones DeFi pueden insertar una transacción para obtener el último precio del oráculo antes de emparejar grandes transacciones, asegurando que las órdenes se emparejen a precios razonables y actualizados, evitando que las cotizaciones de los creadores de mercado se basen en precios obsoletos y sean objeto de arbitraje.
• Prioridad de cancelación de órdenes: La aplicación puede establecer que las “solicitudes de cancelación” se ejecuten antes que las nuevas “transacciones de compra”, permitiendo al maker retirar sus órdenes a tiempo cuando el mercado es desfavorable.
• Subasta de cola: 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 el mayor beneficio al protocolo (o usuario), el protocolo DeFi permitirá que la transacción de esa persona se ejecute junto a la gran orden. Las aplicaciones DeFi pueden 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 lanzó una solución de transición llamada Block Assembly Marketplace ###BAM(. El flujo de trabajo de BAM es:

1. El usuario envía la transacción a un nodo que ejecuta el software BAM (en lugar de enviarla directamente al líder actual).
2. Los nodos BAM recopilan transacciones locales y ejecutan varios plugins )plugin( para realizar una reordenación de los paquetes de transacciones (Bundle) bajo protección de privacidad (los plugins se ejecutan en un entorno seguro de TEE y ocultan el contenido de las transacciones antes de la ejecución). A través de los plugins, los desarrolladores de aplicaciones pueden personalizar diversas reglas de ordenamiento para sus contratos, como prioridad en la cancelación de órdenes, actualización de precios de oráculos antes de la coincidencia, e incluso ejecutar subastas complejas dentro de la aplicación.
3. El Bundle de transacciones ordenado se envía nuevamente al Líder de Solana para ser empaquetado en la cadena.

BAM puede verse como el campo de pruebas antes de que ACE se implemente en la cadena, funcionalmente muy cercano al ACE definitivo, solo que funciona en una red independiente fuera de la cadena, y no está 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 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 ingresos. Esto, en cierta medida, es una “lanza” que se sitúa en oposició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 dañino y a mantener la equidad para los usuarios.

El lanzamiento de BAM sigue esta línea de pensamiento: en esencia, convierte el mecanismo de orden originalmente utilizado para el arbitraje de MEV en un “escudo” para proteger a los proveedores de liquidez como los creadores de mercado, por ejemplo, priorizando la retirada forzada para evitar que los creadores de mercado sufran pérdidas, e introduciendo incentivos de puja para reducir las ganancias por frontrunning. Los buscadores de MEV originales, si quieren ganar dinero, deberán cambiar de rol y desarrollar plugins de BAM para servir a los protocolos DeFi, ganando dinero a través de las tarifas de los plugins.

)# Consultar a HYPERLIQUID

El enfoque ACE/BAM mencionado anteriormente se puede ver como una forma de alcanzar el mecanismo de emparejamiento en la cadena de Hyperliquid. Hyperliquid es una Appchain### dedicada, creada específicamente para servir a DEX. Además, el HLP Vault operado oficialmente por Hyperliquid es en realidad uno de los mayores creadores de mercado de la plataforma, por lo que no es difícil entender que las reglas de la cadena de Hyperliquid están más orientadas hacia los proveedores de liquidez, y ya han implementado muchas protecciones para los creadores de mercado en la capa de la cadena, como por ejemplo:

• Prioridad en la protección de órdenes pendientes: Las órdenes de cancelación y las órdenes de maker son procesadas con prioridad, evitando que los creadores de mercado sean afectados por operaciones desfavorables sin su conocimiento. “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 precios más recientes de los oráculos y el estado de margen para realizar una “doble verificación”. Por ejemplo, cuando hay una orden pendiente que se empareja, el sistema vuelve a consultar el precio más reciente del oráculo para evaluar el margen de ambas partes, asegurando que no se genere riesgo debido a retrasos en los precios. Esto es similar a como ACE inserta actualizaciones de oráculos antes de la ejecución de la transacción.
• Protección contra transacciones de autoejecución: Si se encuentran operaciones de compra y venta en la misma dirección, Hyperliquid cancela automáticamente en lugar de emparejar, para evitar el lavado de operaciones o costos innecesarios.

El ACE/BAM de Solana ICM, sin duda, está “tomando nota” de Hyperliquid. Hyperliquid, como líder en CLOB en la cadena, ha implementado una serie de mecanismos favorables para los creadores de mercado a través de una cadena exclusiva. Ahora, Solana espera utilizar cadenas generales con módulos para replicar este efecto: es decir, permitir que cada aplicación tenga un control de orden de transacciones similar al de Hyperliquid.

( ⚡ Imitación dos: finalización instantánea

)# Comparación de consensos existentes

Solana actualmente utiliza Tower BFT, la confirmación y la finalización son probabilísticas y progresivas: un bloque recibe 2/3 de los votos y se registra como “confirmado ### Confirmado ###”, pero se necesitan acumular aproximadamente 32 bloques posteriores en la cadena (generalmente alrededor de 13 segundos) para que se ancle como “finalizado ( Finalizado )”. 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, utiliza una confirmación de bloque de dos rondas de votación para lograr la “finalidad instantánea”.

• Primera ronda: Pre-votación (Prevote): Los validadores, al recibir el bloque candidato transmitido por el Proposer, realizarán una validación rápida. Si la validació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: “He revisado preliminarmente y este bloque no tiene problemas.”
• Segunda ronda: Precompromiso ( Precommit ): Una vez que un validador ha recopilado los Prevotes de más de dos tercios de los validadores para el mismo bloque candidato, obtiene suficiente confianza en que la mayoría de los miembros de la red aprueban este bloque. Así, el validador emitirá un voto de “precompromiso” ( Precommit ) más contundente y lo difundirá. 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 recibe 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(Finalized). Se añadirá de forma permanente e irreversible a la cadena de bloques.

Esto significa que cada bloque de Hyperliquid es un bloque final, sin posibilidad de bifurcación o retroceso, con un retraso en la generación de bloques extremadamente bajo en toda la cadena: la información oficial revela un retraso promedio en la confirmación de aproximadamente 0.2 segundos, y en el 99% de los casos no excede los 0.9 segundos. Esta certeza final en milisegundos es ideal para el trading de alta frecuencia, ya que una vez que se emite una transacción, se confirma rápidamente y no puede ser reestructurada, lo que aumenta enormemente la eficiencia del capital.

(# ALPENGLOW logra la finalización instantánea.

Alpenglow es un nuevo protocolo de consenso que Solana está preparando para lanzar, con el objetivo de acelerar la confirmación final de bloques a 1-2 slots (aproximadamente 150 ms), logrando una finalidad instantánea similar a HyperBFT. En Alpenglow, el componente responsable del consenso en lugar de TowerBFT se llama Votor, que es un sistema de votación de doble vía:

• Canal Rápido: Si en la primera ronda de votación de un bloque, más del 80% o igual de los “derechos” de la red (que se pueden entender como el peso del voto representado por la cantidad de tokens SOL apostados por los validadores) votan a favor de que este bloque es válido, entonces este bloque será confirmado inmediatamente como “finalizado” (Finalize).
• Canal lento: Si en la primera ronda de votación, la participación que está de acuerdo no alcanza el 80%, pero supera o es igual al 60%, Votor iniciará una segunda ronda de votación. Si después de que termine la segunda ronda de votación, la proporción de participación que está de acuerdo con el bloque se mantiene en 60% o más, entonces este bloque también será confirmado de manera definitiva.

Votor está diciendo: “Confirmamos que realizamos una ronda de votación por defecto, pero si las condiciones no son lo suficientemente perfectas, iniciamos un proceso de votación de dos rondas casi idéntico al de HyperBFT como seguro.” En realidad, es una imitación del mecanismo de votación de Hyperliquid.

)# El costo y las contramedidas de la finalización instantánea

Hyperliquid puede realizar dos rondas de votación, y hay un requisito importante: utiliza un conjunto de validadores muy reducido, donde en las primeras etapas menos de 5 entidades controlaban la mayoría de los nodos de validación, una red de escala limitada puede reducir enormemente los costos de comunicación del consenso BFT.

Pero si la cantidad de nodos se expande a decenas o cientos, la complejidad del proceso de votación aumentará rápidamente, porque la complejidad de cada ronda de votación es proporcional al cuadrado del número de nodos que participan en la comunicación. Solana tiene miles de nodos de validación, y lograr dos rondas de votación manteniendo un alto grado de descentralización presenta una dificultad técnica mucho mayor que Hyperliquid. Por lo tanto, Solana necesita hacer un gran trabajo en la comunicación de la red. En la hoja de ruta se mencionan varias medidas:

• En Alpenglow hay un componente Rotor que reemplaza el antiguo protocolo de distribución de datos Turbine. A diferencia de Turbine, que requiere múltiples niveles de retransmisión, Rotor utiliza un modo de “retransmisión de un solo salto”, permitiendo que los bloques de datos lleguen a los validadores objetivo a una velocidad mucho más rápida, reduciendo drásticamente la latencia de transmisión. Además, bajo el mecanismo actual de Turbine, la posición de los nodos en el árbol de distribución de datos se ordena principalmente según el peso del stake, donde los nodos con más stake son asignados a niveles más altos, recibiendo prioridad para recibir fragmentos de datos (shreds), pero también deben asumir más tareas de retransmisión descendente, consumiendo más ancho de banda. La suposición detrás de este diseño es que los nodos con más stake a menudo son “ricos”, lo que implica que tienen hardware más potente y más recursos de ancho de banda. Rotor actualiza esta lógica, ya que no depende únicamente del tamaño del stake, sino que considera de manera integral el ancho de banda real y el rendimiento de comunicación de cada nodo. Aquellos nodos que muestran un mejor desempeño en la red en tiempo real serán asignados dinámicamente a posiciones clave, creando así la ruta de propagación de datos más óptima para toda la red, logrando un servicio de “entrega” rápido y estable.
• Red de alta velocidad DoubleZero basada en una red de fibra óptica dedicada + tecnología de multicast, ofrece una comunicación de baja latencia que es un orden de magnitud más rápida que la de Internet público. Esto reduce la latencia y el jitter de los mensajes entre nodos geográficamente dispersos, haciendo que la base física para un consenso rápido sea más sólida.

Aun así, lograr que Solana tenga “alta descentralización + finalización en milisegundos” sigue siendo un gran desafío. Esta es también la razón por la que Alpenglow espera que se necesiten más de un año de desarrollo, con la expectativa de que se lance a principios de 2026 (solo podemos esperar que así sea).

🔄 Imitación Tres: Ejecución asíncrona de la tubería

La línea de flujo asíncrona de HYPERLIQUID

La blockchain tradicional es de un solo hilo, un bloque debe ser completamente ejecutado y validado antes de que el siguiente bloque pueda comenzar a procesarse. El objetivo de esto es eliminar la incertidumbre introducida por el multihilo, asegurando que todos los nodos obtengan el mismo resultado en un orden completamente idéntico. Pero la desventaja es que limita el rendimiento de los modernos CPU de múltiples núcleos.

Hyperliquid, por otro lado, rompe con la tradición al introducir múltiples hilos, desacoplando el flujo de trabajo en dos canalizaciones paralelas: “ordenación (consenso)” y “ejecución”. Su proceso de ejecución es el siguiente:

1. Punto de tiempo T1:

   • Línea de consenso: Los validadores llegan a un acuerdo sobre el contenido y el orden de las transacciones del bloque N-1.

2. Punto en el tiempo T2 (el lugar donde comienza la magia):

   • Pipeline de consenso: Comienza a procesar el bloque N. Agrupa y ordena las transacciones en la red, y vota y alcanza consenso sobre este orden. No le importa en absoluto el resultado de la ejecución del bloque N-1.
   • Ejecutar la línea de tiempo: Obtener el bloque N-1 que ya ha alcanzado el consenso en el momento T1 y comenzar a ejecutar las transacciones dentro de él.

3. Punto en el tiempo T3 (la línea de producción sigue funcionando):

   • Línea de consenso: Se completó el consenso del bloque N y se transmitió el resultado del consenso (una lista de transacciones ordenadas) a la línea de ejecución. Luego, comenzó a procesar el bloque N+1 sin pausa.
   • Ejecutar canal: Se completó la ejecución del bloque N-1 y se confirmó su estado. Luego, se conecta sin problemas y recibe inmediatamente el bloque N, que acaba de ser completado por el canal de consenso, y comienza a ejecutar sus transacciones.

En este modo de Pipeline, los diferentes núcleos de la CPU pueden ser utilizados de manera efectiva. Algunos núcleos pueden encargarse específicamente de los mensajes de red y de la votación de consenso (ordenación), mientras que otros núcleos pueden dedicarse completamente al cálculo de estado (ejecución), con ambas líneas de producción funcionando simultáneamente, maximizando la eficiencia del hardware.

El plan APE de ICM

ejecución

Sin embargo, lograr una ejecución segura en paralelo/asíncrona en una cadena descentralizada es un desafío ingenieril extremadamente difícil: para que todos los nodos en el mundo lleguen a un consenso total sobre el resultado de la transacción, es necesario eliminar cualquier factor que pueda provocar resultados diferentes debido a diferentes órdenes de ejecución.

La razón por la que el esquema de canalización asíncrona ha tenido éxito en Hyperliquid es que Hyperliquid, como una appchain de función única, tiene un modelo de estado simple y claro (principalmente el libro de órdenes de los mercados de intercambio y las posiciones de los usuarios). El equipo de desarrollo puede dividir claramente qué operaciones pueden ser paralelas y cuáles tienen dependencias, y en base a eso diseñar una canalización eficiente.

Sin embargo, Solana, como una cadena de propósito general, tiene relaciones de dependencia en las transacciones que son mucho más complejas que un sistema de libro de órdenes. Por lo tanto, para que Solana reproduzca el rendimiento de Hyperliquid en un entorno general, los desafíos de ingeniería son mucho más difíciles y se necesita volver a desarrollar mucho código, lo cual no se puede lograr a corto plazo. Por eso, en la hoja de ruta de ICM, también se clasifica como una planificación a medio plazo. Aun así, el lanzamiento real de APE todavía debe superar una serie de problemas:

• Complejidad extrema del código: Hacer que un sistema distribuido soporte la ejecución asíncrona en paralelo requiere una gran transformación a nivel de base. Una vez que se introduce la paralelización multihilo, la complejidad del software del cliente de nodo de validación de Solana aumentará exponencialmente, y el riesgo de errores desconocidos también se disparará. Una condición de carrera mal manejada podría provocar un error de consenso, y el resultado será catastrófico.
• Requisitos de hardware mejorados: La ejecución en paralelo requiere un potente CPU multinúcleo y más memoria para ejecutar múltiples hilos de ejecución simultáneamente, mantener múltiples estados temporales y puntos de retroceso. Los nodos de Solana ya tienen un umbral alto, y si se incrementa aún más, afectará la descentralización de la red.
• Manejo de la peor situación: La peor situación de la ejecución en paralelo es que un gran número de transacciones compita por el mismo estado. Por ejemplo, al encontrarse con ciertos contratos populares (como DEX populares o contratos de compra rápida) que provocan que todas las transacciones lean y escriban en la misma cuenta, el programador en paralelo seguirá detectando conflictos, retrocediendo y volviendo a ejecutar, lo que podría resultar incluso más lento que la ejecución en serie. Cómo degradar elegantemente en la peor situación, sin que el sistema caiga en un estado de bloqueo o en un colapso de rendimiento, es un desafío en el diseño de la arquitectura.
• Dificultad de desarrollo y auditoría: La verificación de seguridad en un entorno asíncrono y multihilo es muy difícil. La comunidad de Solana necesita invertir recursos adicionales para auditar el nuevo modelo de ejecución y prevenir que las vulnerabilidades de consenso causadas por la paralelización sean explotadas maliciosamente.

🤔 ¿Tendrá éxito este espectáculo de imitaciones?

En resumen, la hoja de ruta de Solana ICM es en realidad un profundo “espectáculo de imitación” de la arquitectura tecnológica de Hyperliquid. El equipo central de Solana planea replicar todas las habilidades distintivas de Hyperliquid y equiparlas a Drift, para ayudarle a competir nuevamente en el mercado DEX con Hyperliquid. Sin embargo, no soy optimista sobre las perspectivas de este espectáculo de imitación.

Aumento exponencial en la dificultad técnica

El éxito de Hyperliquid se basa en gran medida en sus favorables condiciones innatas:

• Como una cadena dedicada, puede optimizar el consenso y la ejecución en torno a una única aplicación, sin necesidad de considerar diferentes necesidades de contratos inteligentes en su diseño;
• Como una cadena emergente, incluso puede sacrificar cierto grado de descentralización a cambio de rendimiento (los validadores iniciales son controlados por el equipo, y la mayoría de los usuarios también consienten esto).

Al observar Solana, mantener la versatilidad de una cadena pública general y el grado de descentralización al mismo tiempo que se alcanza el nivel de Hyperliquid presenta un aumento exponencial en la dificultad técnica. Por ejemplo, el consenso HyperBFT de Hyperliquid puede operar con un retraso de 0.2 segundos con menos de 5 nodos, mientras que Solana, para que 2000 nodos alcancen el mismo retraso, debe superar los límites de comunicación de la red; el motor de emparejamiento de Hyperliquid solo sirve la lógica de su propio intercambio, mientras que el ACE/BAM de Solana debe adaptarse a los diversos protocolos DeFi.

Se puede decir que Solana está tomando clases de Hyperliquid, y la dificultad del curso es mucho más alta que la que experimentó Hyperliquid en su momento, que “no se sabe hasta dónde ha llegado”. La hoja de ruta de ICM descompone estas tareas hasta 2027, lo que demuestra que la oficialidad también es consciente de que no es un trabajo de un día.

La contradicción entre la descentralización y la eficiencia

Otra diferencia entre Solana y Hyperliquid radica en el ritmo de gobernanza y actualizaciones. El equipo de Hyperliquid es pequeño, la toma de decisiones es centralizada y no hay controles externos de gobernanza, lo que les permite actuar con gran rapidez. En marzo de este año, cuando Hyperliquid enfrentó el evento de manipulación del contrato JELLY, el equipo tomó decisiones inmediatas y deslistó los mercados relacionados en cuestión de horas, protegiendo la seguridad de los fondos, lo que demuestra que la toma de decisiones centralizada, aunque “políticamente incorrecta”, es realmente efectiva y útil en momentos críticos.

Solana, como cadena pública, tiene una fundación, desarrollo central y múltiples partes interesadas de la comunidad, lo que hace que el proceso de actualización sea relativamente lento y conservador. Por ejemplo, el muy esperado Firedancer (cliente de Solana de alto rendimiento desarrollado por Jump) ha estado en pruebas desde su lanzamiento en 2022 hasta ahora (mediados de 2025), y aún no se ha lanzado completamente; cualquier cambio relacionado con el consenso requiere largos períodos de auditoría y funcionamiento en la red de pruebas. Además, los cambios en la planificación de la hoja de ruta de ICM son aún mayores: cambiar el algoritmo de consenso central, introducir una nueva ejecución paralela y descentralizar el poder clave, con dificultades y riesgos que solo aumentan. Se puede prever que, en los próximos dos o tres años, el equipo de Solana necesitará avanzar gradualmente en estas actualizaciones, y cada paso puede encontrar problemas técnicos inesperados o resistencia de la comunidad.

Por ejemplo, para que BAM lanzado por Jito realmente beneficie a los usuarios, la mayoría de los validadores deben cambiar a un cliente que soporte BAM. De lo contrario, las transacciones de los usuarios a veces pasarán por BAM y a veces no, lo que llevará a una experiencia inconsistente e incluso a vulnerabilidades de arbitraje. El problema es que Solana no puede obligar a los nodos de validación a actualizar el cliente. Por lo tanto, incluso si BAM se desarrolla con éxito, su velocidad de promoción será difícil de prever. Por lo tanto, el cronograma en ICM es solo una planificación optimista, y su realización probablemente se retrasará una y otra vez, sin saber cuándo se alcanzarán todos los objetivos.

Incluso si todo va bien, para 2027 Solana habrá implementado ACE y otros, lo que será solo un “éxito en la recuperación” — alcanzando las funciones que Hyperliquid ya ofreció en 2023-2024. Y Hyperliquid en sí no se detendrá: por ejemplo, la propuesta HIP-3 se lanzará en la segunda mitad de 2025, permitiendo a la comunidad listar de forma independiente el mercado de contratos perpetuos. Estas innovaciones ampliarán aún más la cobertura del mercado de Hyperliquid. Cuando Solana finalmente logre implementar las funciones actuales de Hyperliquid, tal vez Hyperliquid ya habrá abierto una nueva ventaja competitiva.

Superar la competencia tecnológica

A pesar de que este artículo se centra en comparar el enfrentamiento técnico entre Solana y Hyperliquid, también debemos reconocer que el éxito de Hyperliquid no se debe únicamente a factores técnicos. Hyperliquid tiene muchas ventajas en su operación y ecosistema:

• Por ejemplo, en la economía de tokens, Hyperliquid no tiene financiación de VC, más del 76% de los tokens se distribuyen a la comunidad. Las ganancias de las tarifas que gana la plataforma se pueden utilizar para recomprar tokens HYPE, logrando realmente compartir los beneficios con los usuarios, sin que los capitalistas exploten en exceso a los usuarios. Este aspecto ha ganado a Hyperliquid la reputación de tener muchos usuarios leales.
• Además, el equipo de Hyperliquid captura de manera extremadamente aguda la demanda del mercado: cuando los NFT están de moda, lanzaron el índice de NFT; cuando SocialFi está en auge, lanzaron el índice FriendTech; HIP-2 resolvió el problema de “dificultades de arranque en frío y falta de liquidez inicial” para nuevos tokens; Hyperps resolvió el problema de proporcionar trading de futuros para activos que aún no se han lanzado oficialmente; la actualización HIP-3 planificada para este año apoyará a cualquier proyecto para emitir su propio mercado de contratos perpetuos. La innovación en productos no para de surgir, y estas ricas categorías de trading y formas innovadoras aumentan enormemente la atracción de Hyperliquid como plataforma de trading —— los usuarios vienen aquí no solo por la rapidez, sino también por las oportunidades de ganar dinero que no se encuentran en otros lugares.

En contraste con la pista de DEX de Solana, Drift y otros DEX nativos de Solana actualmente no tienen ventajas evidentes en el diseño del producto y los mecanismos de incentivos. Simplemente replicar con éxito la tecnología de Hyperliquid y igualar el rendimiento de la cadena no traerá automáticamente un gran regreso de usuarios si no se resuelven las funciones distintivas que abordan los puntos de dolor de los usuarios, después de todo, la migración de usuarios también tiene un costo.

Por lo tanto, si solo se imita ciegamente el camino de Hyperliquid, siempre se estará detrás de ellos comiendo polvo. La verdadera oportunidad del roadmap de Solana ICM no está en el ámbito de contratos perpetuos o libros de órdenes. En el ecosistema de Solana hay muchos campos que Hyperliquid aún no ha explorado, como el campo de lanzamiento de MEME, protocolos de préstamos, etc., estos campos también pueden aprovechar las mejoras que trae ICM para crear una experiencia de usuario más fluida. Si Solana puede innovar en estas áreas y resolver los puntos de dolor de los usuarios, entonces, incluso si no puede recuperar terreno de inmediato en el mercado de contratos perpetuos, aún podrá consolidar la realización de su visión de “mercados de capital de Internet”. Después de todo, por fuerte que sea Hyperliquid, sigue siendo una cadena de aplicaciones en un campo vertical, mientras que Solana tiene un vasto y diverso mapa de aplicaciones, que es su mayor capital a largo plazo.

🏁 Conclusión: imitar es fácil, superar es difícil

El mapa de ruta de ICM de Solana destaca la determinación de la comunidad de Solana de no rendirse y de esforzarse por alcanzar a los demás. Desde ACE hasta Alpenglow y luego APE, cada uno corresponde a las características distintivas de Hyperliquid, lo que realmente implica una “imitación específica”.

Sin embargo, imitar es fácil, superar es difícil. Para que Solana tenga éxito en esta imitación, necesita hacer un esfuerzo integral en la superación técnica, la colaboración ecológica y la estrategia de mercado. A corto plazo, Solana quizás pueda mejorar la experiencia de transacciones en cadena a través de BAM y recuperar algunos usuarios. Pero para realmente desafiar la posición de liderazgo de Hyperliquid, podría necesitar más tiempo y más innovación.

Al menos por ahora, Hyperliquid sigue expandiendo su territorio gracias a su ventaja en la cuota de mercado, mientras que Solana continúa acelerando el proceso de transformación de su motor, y es probable que este proceso de transformación tome un tiempo considerable.

El futuro que dibuja la hoja de ruta de ICM es prometedor, pero si se podrá lograr un “adelantamiento en la curva”, aún está por verse. Como usuarios comunes, podemos esperar que esta competencia traiga una mejor experiencia de transacciones en la cadena: sin importar quién gane al final, los usuarios son los beneficiarios.

Este artículo se basa en información pública y no constituye un consejo de inversión. La inversión en criptomonedas conlleva un gran riesgo, por favor, tome decisiones con precaución, DYOR.

Si te gusta este artículo, ¡no dudes en seguir, dar me gusta y compartir para apoyar!