Profundizando en la estructura técnica y los riesgos de seguridad de Hyperliquid

Hyperliquid, que ha recibido mucha atención recientemente, es uno de los exchanges de libro de órdenes en cadena más influyentes, con un valor total de fondos bloqueados que ha superado los 2,000 millones de dólares. Se ha calificado en la industria como "la versión en cadena de un conocido intercambio centralizado", y ha reavivado la discusión sobre Layer3 y cadenas de aplicaciones. Con un rendimiento destacado que alcanzó una valoración de 30,000 millones de dólares en el primer mes desde su lanzamiento, Hyperliquid ha atraído una amplia atención. Actualmente, ya hay varios informes de análisis sobre Hyperliquid en el mercado, pero la mayoría se centra en las funciones del producto y el mecanismo de comercio, faltando un análisis profundo de su arquitectura técnica y posibles vulnerabilidades de seguridad.

Este artículo tiene como objetivo llenar este vacío, analizando Hyperliquid puramente desde una perspectiva técnica y de seguridad, ayudando a los lectores a comprender mejor la estructura interna y los principios de este proyecto estrella. Nos centraremos en analizar el diseño y los riesgos del contrato puente cross-chain de Hyperliquid, así como la arquitectura de doble cadena de HyperEVM y HyperL1, explorando en profundidad los métodos de implementación técnica detrás de ello.

Análisis del puente跨链桥 Hyperliquid

Dado que Hyperliquid no ha hecho público su componente central, pero ha abierto el código de los contratos puente relacionados, tenemos una mejor comprensión de los riesgos asociados a los contratos puente. Hyperliquid ha desplegado un contrato puente en una red Layer2, destinado a almacenar los activos USDC depositados por los usuarios; podemos observar algunos comportamientos de los nodos de Hyperliquid a través del componente Bridge.

Conjunto de validadores

Desde la perspectiva de la identificación de nodos, Hyperliquid tiene 4 grupos de validadores, que son hotValidatorSet, coldValidatorSet, así como finalizers y lockers, cada uno con diferentes responsabilidades. hotValidatorSet es responsable de responder a las operaciones de alta frecuencia de los usuarios, como retiros, y normalmente utiliza billeteras calientes para poder procesar las solicitudes de los usuarios de manera oportuna.

coldValidatorSet se utiliza principalmente para modificar la configuración del sistema, como actualizar la lista de otros conjuntos de validadores o manejar el estado de bloqueo del contrato puente, y tiene la autoridad para invalidar directamente ciertas solicitudes de retiro.

Los lockers son un grupo de validadores con permisos especiales, similares al "comité de seguridad" común en Layer2, que pueden votar para decidir si se detiene la operación del puente cross-chain en caso de emergencia. Actualmente, el conjunto de lockers del puente Hyperliquid incluye 5 direcciones, y solo se necesitan los votos de 2 lockers para pausar el contrato del puente.

Los finalizers son también un grupo de validadores especiales, utilizados principalmente para confirmar los cambios de estado del puente entre cadenas, como las operaciones de depósito y retiro de usuarios. El puente entre cadenas de Hyperliquid utiliza un mecanismo de "envío-confirmación", donde el usuario debe esperar un período de "disputa" después de iniciar un retiro, y una vez finalizado, los finalizers ejecutan la transacción de retiro.

Si hay problemas, como si una solicitud de retiro excede el saldo real del usuario, el nodo de Hyperliquid puede votar para suspender el contrato del puente a través de lockers durante el período de disputa, o el coldValidatorSet puede anular directamente el retiro problemático.

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

Depósito

El contrato puente de Hyperliquid maneja los depósitos de los usuarios utilizando el método Permit basado en EIP-2612, y solo soporta un activo: USDC. En comparación con el modo tradicional de Aprobar-Transferir, Permit es más simple y facilita las operaciones en lote.

El contrato de puente utiliza la función batchedDepositWithPermit para procesar múltiples depósitos en lote, el proceso es simple y no presenta riesgos de seguridad de fondos, principalmente aprovecha el método Permit para optimizar la experiencia del usuario.

Retiro

En comparación con los depósitos, los retiros son operaciones de alto riesgo, por lo que la lógica es más compleja. Después de que el usuario inicia una solicitud de retiro, el nodo de Hyperliquid llama a la función batchedRequestWithdrawals del contrato puente. En este momento, se requiere que cada solicitud de retiro obtenga el peso de firma de 2/3 del hotValidatorSet, notando que es "peso de firma de 2/3" y no "número de firmas de 2/3". Actualmente, Hyperliquid solo tiene 4 nodos con el mismo peso, por lo que la verificación del peso de la firma y el número de firmas es temporalmente consistente, pero en el futuro se podrían introducir nodos de alto peso.

Después de iniciar la solicitud de retiro, el puente entre cadenas no transferirá inmediatamente USDC, sino que habrá un "período de disputa" de 200 segundos. Durante este tiempo, pueden ocurrir dos situaciones:

1. lockers considera que hay un problema grave con la solicitud de retiro, puede votar directamente para congelar el contrato;

2. Si un nodo considera que hay problemas con algunos retiros, los miembros de coldValidatorSet pueden llamar a la función invalidateWithdrawals para invalidar ese retiro.

Si no hay anomalías durante el período de disputa, los miembros de finalizers pueden llamar a la función batchedFinalizeWithdrawals para confirmar el estado final, en este momento USDC se transferirá a la dirección de la billetera del usuario en Layer2.

Desde la perspectiva del modelo de seguridad, si un atacante malicioso quiere hacer daño en el proceso de retiro de Hyperliquid, debe superar tres líneas de defensa:

1. Dominar el peso de la firma del hotValidatorSet de 2/3, es decir, obtener suficientes claves privadas o conspirar. Actualmente solo hay 4 validadores, la posibilidad de control o conspiración no es baja;

2. Evitar que se descubran transacciones maliciosas durante el período de disputa, de lo contrario, puede activar el bloqueo de contratos de lockers.

3. Obtenga al menos una clave privada de un miembro de finalizers para confirmar el retiro. Actualmente, los finalizers son prácticamente los mismos que los miembros del hotValidatorSet, cumplir con la condición 1 es suficiente para cumplir con la condición 3.

Contrato de puente bloqueado

Hyperliquid ha establecido la función de bloqueo del contrato puente entre cadenas. En concreto, los miembros de lockers deben llamar a la función voteEmergencyLock para votar; actualmente, con el voto de 2 lockers se puede bloquear y pausar el contrato puente.

Cabe destacar que el puente Hyperliquid también proporciona la función unvoteEmergencyLock, que permite a los lockers retirar su voto. Una vez que el contrato del puente está bloqueado, solo se puede desbloquear a través de la función emergencyUnlock, que requiere obtener más de 2/3 del peso de las firmas de los miembros del coldValidatorSet.

Al desbloquear emergencyUnlock, se actualizarán los conjuntos de direcciones de validadores hotValidatorSet y coldValidatorSet, y entrarán en vigor de inmediato.

Actualización del conjunto de validadores

En comparación con romper la línea de defensa del proceso de retiro, usar directamente la función updateValidatorSet para actualizar el conjunto de validadores es un método de ataque más efectivo. Esto requiere la firma de todos los miembros del hotValidatorSet y hay un período de controversia de 200 segundos.

Después del período de disputa, los miembros de finalizers deben llamar a la función finalizeValidatorSetUpdate para completar la actualización final.

Resumen de los riesgos existentes en el contrato puente de Hyperliquid:

1. Un hacker que controle el coldValidatorSet puede ignorar las restricciones y robar los activos de los usuarios. Dado que el coldValidatorSet tiene derechos de emergencyUnlock, puede hacer que los lockers sean inválidos y actualizar instantáneamente la lista de nodos. Actualmente solo hay 4 nodos de validación, el riesgo de robo de claves privadas no es bajo;

2. los finalizadores rechazan confirmar las transacciones de retiro de los usuarios, iniciando un ataque de revisión. En este momento, los activos del usuario están seguros pero pueden no ser retirados;

3. lockers bloqueo malicioso del puente entre cadenas, impidiendo la ejecución de todas las transacciones de retiro, solo se puede esperar a que coldValidatorSet se desbloquee.

HyperEVM y arquitectura de interacción de doble cadena

Para lograr la programación del comercio en libros de órdenes, como la introducción de transacciones privadas y otros escenarios que requieren el soporte de contratos inteligentes, Hyperliquid ha lanzado la solución HyperEVM. Esta tiene dos grandes ventajas sobre el EVM tradicional: puede leer el estado del libro de órdenes de Hyperliquid y los contratos inteligentes internos pueden interactuar con el sistema del libro de órdenes, ampliando significativamente los escenarios de aplicación.

Por ejemplo, si los usuarios necesitan garantizar la privacidad de las órdenes pendientes, pueden agregar una capa de privacidad a través de un contrato similar a Tornado Cash en HyperEVM, y luego activar la orden a través de una interfaz específica en el sistema de libro de órdenes de Hyperliquid.

Hyperliquid ha diseñado una arquitectura especial para HyperEVM. Teniendo en cuenta que el rendimiento del sistema de libro de órdenes personalizado supera con creces el entorno EVM, para evitar la disminución de velocidad, Hyperliquid adopta un "esquema de doble cadena": cada nodo ejecuta simultáneamente dos cadenas, almacena localmente los datos de ambas cadenas y procesa las transacciones por separado.

Hyperliquid establece una cadena dedicada para el sistema de libro de órdenes (HyperL1, con licencia ), al mismo tiempo que añade una cadena compatible con EVM (HyperEVM, sin licencia ). Los datos de ambas cadenas se propagan a través del mismo protocolo de consenso, existiendo como un estado unificado, pero operando en diferentes entornos. HyperL1 tiene una velocidad de bloque más rápida que HyperEVM, pero los bloques aún se ejecutan en orden. Los contratos en la cadena EVM pueden leer datos de bloques L1 anteriores y escribir datos en futuros bloques L1.

HyperL1 y HyperEVM interactúan principalmente a través de Precompiles y Events.

Precompiles

Precompilados ( Precompiles ) implementan operaciones complejas directamente en la capa base, utilizando lenguajes como C/C++ para manejar cálculos poco amigables con Solidity. La precompilación es esencialmente un contrato inteligente especial, que otros contratos pueden invocar y obtener resultados de ejecución. Actualmente, la EVM nativa ya ha implementado la instrucción ecRecover con precompilación ( dirección ).

HyperEVM también ha añadido código precompilado para permitir la lectura del estado del sistema de libros de órdenes de Hyperliquid. Se conoce una dirección precompilada como 0x0000000000000000000000000000000000000800, que puede leer las posiciones de contratos perpetuos de los usuarios en el bloque L1 más reciente.

Eventos

HyperEVM escribe datos en HyperL1 utilizando Events. Events es un concepto nativo de EVM que permite a los contratos enviar información de registro al exterior. Por ejemplo, cuando se realiza una transferencia ERC-20, se emite un evento Transfer, lo que facilita la supervisión. Muchos escenarios de cadena cruzada también utilizan Events para transmitir parámetros.

El nodo HyperLiquid escucha los eventos emitidos por la dirección 0x3333333333333333333333333333333333333333, obtiene información para conocer la intención del usuario y la convierte en acciones de trading, escribiéndola en futuros bloques L1. Si esta dirección proporciona una función, al ser llamada, emite el evento IocOrder; cuando se genera un nuevo bloque L1, el nodo detecta el nuevo evento IocOrder y lo convierte en una operación de orden pendiente en L1.

HyperBFT

En cuanto al protocolo de consenso, Hyperliquid utiliza el protocolo HyperBFT derivado de HotStuff. En sus inicios, utilizó el algoritmo Tendermint, pero su eficiencia era baja, requiriendo un intercambio de mensajes All-to-All en cada fase, con una complejidad de O(n²).

Para alcanzar la velocidad de un intercambio centralizado, el equipo desarrolló HyperBFT y lo implementó en Rust, teóricamente puede procesar 2 millones de órdenes por segundo. En HyperBFT, todos los mensajes son recopilados y transmitidos por el Líder, eliminando el intercambio de mensajes entre nodos, lo que reduce drásticamente la complejidad.

En resumen, HyperBFT es un protocolo de consenso en el que el líder actual genera bloques, todos los nodos votan y envían los resultados al líder, que luego rota al siguiente líder.

Consideraciones para desarrolladores

1. El mecanismo de lectura de datos basado en Precompiles está bastante completo, pero se debe tener en cuenta el problema de msg.sender. Cuando los usuarios interactúan con el contrato del sistema L1, lo que activa indirectamente una transacción EVM, msg.sender dentro de la EVM es la dirección del contrato del sistema L1 y no la dirección del usuario.

2. Existe un problema de no atomicidad en la interacción entre EVM y L1. Por ejemplo, si un usuario realiza un pedido en L1 a través de EVM pero no tiene suficientes activos, la transacción falla pero no hay mensaje de error al llamar a la función. El desarrollador debe manejar la situación de fallo del pedido en el extremo del contrato EVM y establecer una función de recuperación de fondos.

3. La dirección del contrato EVM debe tener una cuenta mapeada en L1. Después de desplegar el contrato EVM, se debe transferir una pequeña cantidad de USDC a la dirección mapeada de L1 para crear la cuenta.

4. Preste atención a situaciones especiales como el saldo de tokens. L1 tiene direcciones especiales para el cruce de activos entre cadenas, pero después del cruce, EVM puede no generar bloques a tiempo, lo que impide que los usuarios lean temporalmente el saldo. Los desarrolladores deben manejar tales situaciones para evitar el pánico de los usuarios.