Análisis profundo de Hyperliquid desde una perspectiva técnica: contratos puente, HyperEVM y problemas potenciales

Hyperliquid, como un intercambio de libro de órdenes en cadena muy destacado, tiene una arquitectura técnica y seguridad que merecen un análisis profundo. Este artículo analizará tres aspectos: la estructura de los contratos de puente entre cadenas, las características técnicas de HyperEVM y las posibles vulnerabilidades de seguridad.

Análisis del puente cross-chain Hyperliquid

Hyperliquid ha desplegado un contrato de puente entre cadenas en Arbitrum para almacenar los activos USDC de los usuarios. Desde la perspectiva de la identificación de nodos, Hyperliquid tiene cuatro grupos de validadores:

• hotValidatorSet: se encarga de manejar operaciones de alta frecuencia como retiros de usuarios
• coldValidatorSet: responsable de modificar la configuración del sistema y manejar situaciones excepcionales
• lockers: similar a un comité de seguridad, se puede votar para pausar el contrato puente
• finalizers: confirmar cambios en el estado del puente entre cadenas

Proceso de depósito

El contrato puente utiliza el método Permit de EIP-2612 para manejar depósitos, permitiendo solo el depósito de USDC. La operación de depósito es bastante sencilla, principalmente se gestiona a través de la función batchedDepositWithPermit.

Proceso de retiro

El proceso de retiro es bastante complejo:

1. El usuario inicia una solicitud de retiro
2. Confirmación del peso de firma de 2/3 del hotValidatorSet
3. Período de disputa de 200 segundos
4. confirmación final de los miembros de finalizers

Durante el período de disputa, los lockers pueden votar para congelar el contrato, y el coldValidatorSet puede invalidar algunos retiros.

Mecanismo de bloqueo del contrato puente

Los miembros de lockers pueden llamar a la función voteEmergencyLock para votar, se requieren 2 votos de miembros para bloquear el contrato puente. Para desbloquear, se necesita la firma de 2/3 del coldValidatorSet.

Actualización del conjunto de validadores

A través de la función updateValidatorSet se actualizan hotValidatorSet y coldValidatorSet, se requiere la firma de todos los miembros de hotValidatorSet, hay un período de disputa de 200 segundos.

Puntos de riesgo principales

1. coldValidatorSet controlado puede eludir todas las defensas y robar activos
2. los finalizadores pueden rechazar la confirmación de las transacciones de retiro, lo que impide que los activos del usuario sean retirados.
3. contratos puente de lockers maliciosos que obstaculizan los retiros

HyperEVM y la arquitectura de interacción de doble cadena

Para lograr la programabilidad del comercio en el libro de órdenes, Hyperliquid ha lanzado la solución HyperEVM. Sus características son:

1. Se puede leer el estado del libro de órdenes de Hyperliquid
2. Puede interactuar con el sistema de libro de órdenes de Hyperliquid

Hyperliquid utiliza un "plan de doble cadena", funcionando simultáneamente en dos cadenas:

• Hyperliquid L1: cadena dedicada al libro de órdenes, con licencia
• HyperEVM: Cadena compatible con EVM, sin permisos

Las dos cadenas interactúan a través de Precompiles y Eventos:

• Precompilados: código precompilado, permite que EVM lea el estado de L1
• Eventos: EVM lanza eventos, nodo L1 escucha y ejecuta las operaciones correspondientes

consenso HyperBFT

Hyperliquid utiliza un algoritmo de consenso HyperBFT mejorado basado en HotStuff, que teóricamente puede procesar 2 millones de órdenes por segundo.

Avisos para desarrolladores

1. msg.sender puede ser la dirección de un contrato del sistema, no la dirección de un usuario
2. La interacción EVM con L1 no es atómica, se deben manejar las situaciones de fallo.
3. La dirección del contrato EVM debe crear una cuenta de mapeo en L1
4. Durante el proceso de cruce de cadenas de activos, el saldo puede no ser visible temporalmente.

Resumen

Hyperliquid combina un libro de órdenes de alto rendimiento con programabilidad a través de una arquitectura de doble cadena y mecanismos de interacción innovadores. Sin embargo, su complejo mecanismo de validadores e interacciones entre cadenas también presenta posibles riesgos de seguridad que merecen una mayor atención y optimización.