Autor ｜ Shew，仙壤 GodRealmX

Recientemente, Hyperliquid ha atraído la atención del mercado y se ha convertido en uno de los exchanges de órdenes en cadena más influyentes, con un TVL que ha superado los 2 mil millones de dólares. Messari lo calificó como 'el Binance en cadena' y ha reavivado la narrativa de Layer3 y cadenas de aplicaciones que ya habían pasado al olvido. Con un FDV que alcanzó los 30 mil millones de dólares en apenas un mes desde el lanzamiento del token, Hyperliquid ha captado la atención de una amplia gama de usuarios, desde el público en general hasta los profesionales del sector. Al mismo tiempo, se han publicado numerosos informes de investigación sobre Hyperliquid, pero la mayoría de estos artículos se centran en las características de la funcionalidad del producto de libro de órdenes y el mecanismo de negociación, sin profundizar en la estructura técnica subyacente y los riesgos de seguridad.

El autor de este artículo pretende llenar este vacío, examinando Hyperliquid desde una perspectiva puramente técnica y de seguridad, para ayudar a más personas a comprender la estructura y los principios de este proyecto estrella. Abordaremos dos grandes aspectos: la construcción y los riesgos del contrato puente de Hyperliquid, y la construcción de doble cadena de HyperEVM y HyperL1, para ayudar a todos a entender mejor su arquitectura técnica y su modo de implementación.



Análisis del puente de HyperLiquid

Dado que HyperLiquid no ha abierto su componente central, pero sí ha hecho públicos los contratos puente relacionados, tenemos un mejor entendimiento de los riesgos asociados a los contratos puente. Hyperliquid ha desplegado un contrato puente en Arbitrum para almacenar los activos USDC depositados por los usuarios, y podemos observar algunas de las conductas de los nodos de Hyperliquid dentro del componente Bridge.

Conjunto de validadores

Desde la perspectiva de la identidad de los nodos, Hyperliquid cuenta con 4 grupos de validadores: hotValidatorSet, coldValidatorSet, finalizers y lockers, cada uno con diferentes funciones. El hotValidatorSet se utiliza para responder a acciones de retiro de los usuarios y otras actividades de alta frecuencia, generalmente utilizando wallets calientes para responder a las solicitudes de retiro de los usuarios de Hyperliquid en cualquier momento.

El coldValidatorSet se utiliza principalmente para modificar la configuración del sistema, como reescribir la lista de validadores del hotValidatorSet o lockers, o gestionar el estado de bloqueo del contrato puente. Además, el coldValidatorSet tiene el poder de invalidar directamente ciertas solicitudes de retiro.

Los lockers son un grupo de validadores con permisos especiales, similares a un 'comité de seguridad' común en Layer2, que deciden mediante votación si se debe pausar el funcionamiento del puente en situaciones de emergencia. Actualmente, el conjunto de lockers del puente de Hyperliquid incluye 5 direcciones, y solo se necesitan 2 votos de lockers para pausar el funcionamiento del contrato puente.



En cuanto a los finalizers, en realidad son también un grupo de validadores especiales, encargados de confirmar los cambios de estado del puente, centrándose principalmente en las transacciones de depósitos y retiros de los usuarios. El puente de Hyperliquid utiliza un mecanismo de 'envío-confirmación'; por ejemplo, después de que un usuario inicia una solicitud de retiro, esta no se ejecuta de inmediato, sino que debe esperar un período de tiempo (denominado período de disputa). Una vez que finaliza el período de disputa, los miembros del grupo de finalizers ejecutan la transacción de retiro, y esta puede ser ejecutada normalmente.

Si surge un problema en el puente, como que una solicitud de retiro declare que los activos a retirar son mayores que el saldo real del usuario, los nodos de Hyperliquid pueden usar los lockers para votar y pausar el funcionamiento del contrato puente durante el período de disputa, o el coldValidatorSet puede invalidar directamente la solicitud problemática de retiro.

Actualmente, Hyperliquid solo tiene 4 nodos validadores, por lo que el hotValidatorSet y el coldValidatorSet solo corresponden a 4 direcciones en cadena. Durante la inicialización, Hyperliquid registra automáticamente las direcciones dentro del hotValidatorSet como miembros de lockers y finalizers, mientras que el coldValidatorSet es controlado por Hyperliquid oficialmente, utilizando wallets frías para almacenar las claves.

Depósito

El contrato puente de Hyperliquid utiliza el método Permit de EIP-2612 para manejar las operaciones de depósito de los usuarios, y dentro del contrato puente solo se permite que los usuarios depositen un tipo de activo: USDC. El método Permit es más sencillo que el tradicional modelo Approve-Transfer, y facilita el soporte para operaciones en lote.

El contrato puente de Hyperliquid utiliza la función batchedDepositWithPermit para manejar múltiples depósitos en lote. Aquí, la acción de depósito es bastante sencilla y no presenta riesgos de seguridad de fondos, y el flujo de procesamiento es muy sencillo, simplemente se utiliza el método Permit para optimizar la experiencia del usuario.



Retiro

En comparación con el depósito, el retiro es una operación altamente riesgosa, por lo que la lógica de retiro es mucho más compleja que la de depósito. Cuando un usuario inicia una solicitud de retiro, los nodos de Hyperliquid llaman a la función batchedRequestWithdrawals del contrato puente. En este momento, el contrato puente requiere que cada solicitud de retiro reúna el 2/3 del peso de firma del hotValidatorSet. Cabe destacar que muchos documentos describen esto como 'reunir 2/3 de las firmas', pero en realidad, el contrato puente verifica el 'peso de firma del 2/3'. Actualmente, HyperLiquid solo tiene 4 nodos con el mismo peso, por lo que la verificación del peso de firma y el conteo de firmas son iguales por el momento, pero en el futuro, HyperLiquid podría introducir nodos con mayor peso.

Al iniciar una solicitud de retiro, el puente no transferirá de inmediato los USDC controlados por el contrato, sino que habrá un 'período de disputa', similar al 'período de desafío' en un protocolo de prueba de fraude. Actualmente, el período de disputa del contrato puente de Hyperliquid es de 200 segundos, y pueden ocurrir dos situaciones durante este período:

1. Los lockers consideran que la solicitud de retiro actual presenta un problema grave, y pueden votar para pausar/congelar el contrato;
2. Los nodos consideran que algunas acciones de retiro presentan problemas, y los miembros del coldValidatorSet pueden llamar a la función invalidateWithdrawals para invalidar esa solicitud de retiro.

Si no hay problemas durante el período de disputa, una vez que este termina, los miembros del grupo de finalizers pueden llamar a la función batchedFinalizeWithdrawals del contrato puente para finalizar el estado, y solo entonces los USDC se transferirán a la dirección de la wallet del usuario en Arbitrum.



Por lo tanto, desde la perspectiva del modelo de seguridad, si un atacante malicioso quiere manipular el flujo de retiro de Hyperliquid, necesitará superar tres líneas de defensa:

1. Controlar el 2/3 del peso de firma dentro del hotValidatorSet, es decir, necesitará obtener una cierta cantidad de claves privadas o conspirar; actualmente, HyperLiquid solo tiene 4 validadores, lo que hace que la posibilidad de que un atacante los controle o conspire sea bastante alta.

2. Durante el período de disputa, el atacante debe evitar que su transacción maliciosa sea descubierta; si se descubre, es muy probable que los lockers actúen para congelar el contrato. Discutiremos esta parte más adelante.

3. Obtener al menos una clave privada de un miembro de los finalizers para que su acción de retiro sea confirmada finalmente. Actualmente, los miembros de los finalizers son prácticamente los mismos que los miembros del hotValidatorSet, por lo que si un atacante cumple con la condición 1, automáticamente cumple con la condición 3.

Bloqueo del contrato puente

Hemos mencionado varias veces que Hyperliquid ha establecido una función para bloquear el contrato puente. En concreto, para bloquear el puente, los miembros de lockers deben llamar a la función voteEmergencyLock del contrato puente para votar. Actualmente, cuando 2 lockers llaman a esta función y votan, el contrato puente se bloqueará y su funcionamiento se pausará.

Sin embargo, es importante señalar que el puente de HyperLiquid también proporciona la función unvoteEmergencyLock, que permite a los miembros de lockers retirar su voto. Una vez que el contrato puente se ha bloqueado con éxito, solo se puede desbloquear mediante la función llamada emergencyUnlock, que requiere reunir más del 2/3 del peso de firma de los miembros del coldValidatorSet.

La función emergencyUnlock, al desbloquear, también introducirá un nuevo conjunto de direcciones de validadores para hotValidatorSet y coldValidatorSet, y se actualizará de inmediato.



Actualización del conjunto de validadores

En lugar de intentar romper las defensas ya establecidas en el flujo de retiro, una mejor forma de ataque es actualizar directamente el conjunto de validadores utilizando la función updateValidatorSet para hotValidatorSet y coldValidatorSet. Esto requiere que el llamador proporcione la firma de todos los miembros del hotValidatorSet y dicha operación tiene un período de disputa de 200 segundos.

Al finalizar el período de disputa, los miembros de los finalizers deben llamar a la función finalizeValidatorSetUpdate para completar la actualización final del estado.

Hasta aquí, hemos presentado la mayoría de los detalles del puente de Hyperliquid. Este artículo no ha abordado la lógica de actualización de lockers y finalizers, ya que ambas actualizaciones requieren la firma del hotValidatorSet, y para eliminar a un miembro se requiere la firma del coldValidatorSet.

En resumen, el contrato puente de Hyperliquid presenta los siguientes riesgos:


1. Si un hacker controla el coldValidatorSet, puede ignorar cualquier obstáculo para robar los activos de los usuarios. Como el coldValidatorSet tiene el permiso para operar la función emergencyUnlock, puede invalidar las acciones de bloqueo del contrato puente realizadas por los lockers y puede actualizar la lista de nodos de inmediato. Actualmente, Hyperliquid solo cuenta con 4 nodos validadores, lo que aumenta la posibilidad de que se roben las claves privadas.

2. Los finalizers se niegan a confirmar la transacción de retiro del usuario, llevando a cabo un ataque de revisión; en tal caso, los activos del usuario no serán robados, pero pueden no ser retirados del contrato puente.

3. Los lockers actúan maliciosamente bloqueando el puente, impidiendo que todas las transacciones de retiro se ejecuten, y solo pueden esperar a que el coldValidatorSet desbloquee.

HyperEVM

Para hacer que el comercio en el libro de órdenes sea programable, por ejemplo, al introducir operaciones privadas que requieren contratos inteligentes, Hyperliquid lanzó una solución llamada HyperEVM. Esta tiene dos ventajas especiales sobre el EVM tradicional: primero, HyperEVM puede leer el estado del libro de órdenes de HyperLiquid; segundo, los contratos inteligentes dentro de HyperEVM pueden interactuar con el sistema de libro de órdenes de Hyperliquid, lo que amplía significativamente el ámbito de aplicación de Hyperliquid.

Por ejemplo, si un usuario necesita garantizar la privacidad de las órdenes, puede envolver la operación de orden en HyperEVM mediante un contrato inteligente similar a Tornado Cash y luego activar la acción de orden en el sistema del libro de órdenes de HyperLiquid a través de una interfaz específica.

Antes de presentar HyperEVM, debemos abordar la arquitectura especial que Hyperliquid ha preparado para HyperEVM. Dado que Hyperliquid tiene un sistema de libro de órdenes personalizado de alto rendimiento, la velocidad de procesamiento de transacciones en un entorno EVM es mucho más lenta. Para evitar que el sistema de libro de órdenes se desacelere, Hyperliquid utiliza un 'sistema de doble cadena', que en esencia permite a los nodos de Hyperliquid ejecutar simultáneamente dos cadenas de bloques a nivel de software, almacenando datos de ambas cadenas localmente y procesando las transacciones de cada cadena por separado.

Hyperliquid ha establecido una cadena dedicada para su sistema de libro de órdenes, así como una cadena compatible con EVM (HyperEVM). Los datos de estas dos cadenas se propagan entre los nodos a través de un protocolo de consenso común, existiendo como un estado unificado, pero operando en diferentes entornos de ejecución. Llamamos a la cadena dedicada al libro de órdenes Hyperliquid L1 (L1), que es una cadena de permisos; mientras que la cadena utilizada para HyperEVM es HyperEVM (EVM), que es sin permisos, permitiendo a cualquiera desplegar contratos que pueden acceder a la información dentro de L1 a través de código precompilado.

Cabe señalar que la velocidad de creación de bloques de Hyperliquid L1 es mayor que la de HyperEVM, pero estos bloques aún se ejecutan en orden. Los contratos en la cadena EVM pueden leer datos de bloques anteriores de L1 y escribir datos en futuros bloques de L1. A continuación se muestra un gráfico:



Para permitir la interacción entre HyperL1 y HyperEVM, Hyperliquid utiliza dos técnicas: Precompiles y Events.

Precompiles

Lo que se denomina precompilación (Precompiles) significa que algunas operaciones que son difíciles de implementar en contratos inteligentes y que tienen una alta complejidad se realizan directamente a nivel de infraestructura, moviendo los procesos de cálculo que son problemáticos para Solidity fuera de los contratos inteligentes convencionales. Este tipo de código precompilado se puede implementar en lenguajes como C, C++, que están más cerca del nivel del dispositivo que Solidity.

El uso de precompilaciones permite que EVM soporte funciones más avanzadas y complejas, facilitando las necesidades de los desarrolladores de contratos inteligentes. En términos de forma, la precompilación es esencialmente un conjunto de contratos inteligentes especiales, que otros contratos inteligentes pueden llamar directamente, pasando parámetros y obteniendo los resultados de la ejecución de la precompilación. Actualmente, EVM nativo ha implementado el comando ecRecover a través de precompilaciones, que puede verificar si una firma secp256k1 es correcta, y dicho comando se encuentra en la dirección 0x01.

Agregar funciones especiales mediante precompilaciones es la práctica actual más común, por ejemplo, Base ha agregado código precompilado P256 para facilitar a los usuarios la operación de autenticación de identidad WebAuth.



De manera coherente con esta solución actual, HyperEVM también ha agregado una serie de códigos precompilados para permitir que EVM lea el estado del sistema de libro de órdenes de Hyperliquid. Actualmente, se conoce una dirección de código precompilado de Hyperliquid, que es 0x0000000000000000000000000000000000000800, que puede leer la situación de las posiciones de contratos perpetuos de los usuarios en el último bloque de L1.



Events

Hemos mencionado anteriormente que HyperEVM puede escribir datos en los bloques de HyperL1; la escritura depende de la implementación de Events. Events es un concepto nativo en EVM que permite a los contratos inteligentes enviar información de registro a externos (como aplicaciones front-end o escuchadores) durante su ejecución, facilitando la supervisión del estado de ejecución del contrato inteligente.

Por ejemplo, cuando un usuario utiliza la función de transferencia de tokens del contrato ERC-20, el contrato emitirá el evento Transfer correspondiente para informar a aplicaciones front-end, como exploradores de bloques, sobre la situación de la transferencia de tokens. Esta información de Events se incluirá en el bloque, y existen numerosas soluciones maduras para escuchar y recuperar registros de Events.

Actualmente, muchos escenarios relacionados con el cruce de cadenas utilizan Events para transmitir parámetros de cruce, por ejemplo, en el contrato puente de Arbitrum desplegado en la red principal de Ethereum, los usuarios pueden llamar a funciones relacionadas para emitir eventos y activar transacciones en Arbitrum.



La información conocida hasta ahora indica que los nodos de HyperLiquid escucharán los Events emitidos por la dirección 0x3333333333333333333333333333333333333333 (denominada dirección de eventos a continuación), y convertirán la intención del usuario en acciones de transacción, escribiéndolas en futuros bloques de Hyperliquid L1.

Por ejemplo, la dirección de eventos mencionada anteriormente proporcionará una función, que al ser llamada por el usuario, emitirá un evento llamado IocOrder. Cuando se genere un bloque en Hyper L1, los nodos de HyperLiquid primero consultarán los Events emitidos por la dirección de eventos en HyperEVM; al encontrar un nuevo evento IocOrder, lo convertirán en una acción de orden en Hyper L1.

HyperBFT

A nivel de protocolo de consenso, Hyperliquid utiliza un protocolo llamado HyperBFT, que es un método derivado basado en HotStuff. Actualmente, HutStuff-2 ya es uno de los protocolos de consenso con la complejidad más baja y más actualizados.

Según los datos, inicialmente HyperLiquid utilizó el algoritmo de consenso Tendermint, que es el algoritmo de consenso predeterminado utilizado en el sistema Cosmos, pero este algoritmo tiene una eficiencia relativamente baja, ya que requiere un intercambio de mensajes All-to-All en cada fase, donde cada nodo debe enviar mensajes a todos los demás nodos, lo que resulta en una complejidad de comunicación de O(n²), donde n es el número de nodos.



Si se utilizara Tendermint, Hyperliquid podría procesar un máximo de 20,000 órdenes por segundo. Para alcanzar la velocidad de un exchange centralizado, el equipo de HyperLiquid desarrolló el algoritmo HyperBFT basado en HotStuff, que teóricamente puede procesar hasta 2 millones de órdenes por segundo.

La siguiente imagen muestra el método de transmisión de mensajes de consenso HyperBFT en condiciones no paralelas, donde se puede observar que todos los mensajes son recopilados por el líder y se difunden de manera unificada, eliminando el paso de intercambio de mensajes entre nodos y reduciendo significativamente la complejidad.



En términos simples, HyperBFT se basa en que el líder actual crea bloques, todos los nodos participan en la votación y envían un resultado de votación unificado al líder, y luego se rota al siguiente líder. En realidad, los detalles específicos de Hotstuff y Tendermint son mucho más complejos, pero este artículo se limita a su extensión y no profundiza en este aspecto.

Puntos a tener en cuenta para los desarrolladores

El mecanismo de lectura de datos basado en Precompiles mencionado anteriormente es bastante perfecto, los desarrolladores de Solidity no necesitan escribir código específico para leer el estado de Hyper L1, pero deben tener cuidado con el problema de msg.sender. Al igual que la mayoría de las soluciones de segunda capa de Ethereum, HyperLiquid permite a los usuarios interactuar directamente con los contratos del sistema dentro de Hyper L1, activando indirectamente las acciones de transacción en la cadena HyperEVM; en este caso, si un contrato inteligente lee el campo msg.sender en esa transacción, descubrirá que corresponde a la dirección del contrato del sistema HyperL1, y no a la dirección del usuario que inició la transacción en HyperL1.

En cuanto a la interacción entre EVM y L1, los desarrolladores deben tener en cuenta una serie de problemas. El primer problema es la no atomicidad de la interacción; si un usuario en HyperEVM realiza una orden indirectamente en L1 a través de la dirección de eventos mencionada anteriormente, pero no tiene suficientes activos en L1, esa transacción fracasará, pero no habrá un mensaje de error al llamar a la función de la dirección de eventos. El problema de la no atomicidad de la interacción puede llevar a la pérdida de activos del usuario. En este caso, será necesario que los desarrolladores manejen manualmente las situaciones de fallo de orden en el contrato inteligente de EVM. Además, el contrato inteligente de EVM debe tener una función para la recuperación final de fondos, para evitar que los activos del usuario queden atrapados indefinidamente en L1.

En segundo lugar, la dirección del contrato correspondiente a EVM debe existir en la cuenta mapeada en L1. Cuando el usuario despliega un contrato inteligente en EVM, debe transferir una pequeña cantidad de USDC a la dirección mapeada en L1, forzando a L1 a crear una cuenta para la dirección del contrato. Esta operación puede estar relacionada con el consenso subyacente de HyperLiquid, como se indica claramente en la documentación de Hyperliquid.

Por último, los desarrolladores deben estar atentos a algunas situaciones especiales, especialmente en relación con los saldos de tokens. Hyper L1 tiene una dirección especial para la transferencia de activos, pero cuando los usuarios envían activos a esta dirección especial, los activos cruzan de L1 a la cadena HyperEVM. Dado que los nodos de HyperLiquid ejecutan simultáneamente ambas cadenas, puede suceder que después de que el usuario transfiera activos, HyperEVM no genere bloques durante un largo tiempo, y en ese momento el usuario no podrá ver su saldo en la cadena EVM.

En resumen, en este caso, los activos del usuario quedan atrapados en el puente cruzado, y no pueden ser consultados ni en L1 ni en la cadena EVM. Los protocolos construidos por los desarrolladores deben manejar estas situaciones especiales para evitar que los usuarios se sientan angustiados.

En resumen, HyperEVM es similar a una segunda capa basada en Hyperliquid L1. HyperEVM depende del código precompilado para leer el estado de L1 y también de Events para interactuar con Hyper L1. L1 también tiene algunos contratos del sistema que ayudan a los usuarios a activar transacciones dentro de HyperEVM o realizar cruces de activos. Sin embargo, a diferencia de la arquitectura general de Layer1-Layer2, Hyperliquid ofrece una mayor interoperabilidad para HyperEVM.