Análisis profundo de Hyperliquid: arquitectura técnica y riesgos potenciales
Hyperliquid, como un intercambio de libros de órdenes en cadena muy destacado, merece una profunda discusión sobre su arquitectura técnica y seguridad. Este artículo analizará la implementación técnica de Hyperliquid desde dos perspectivas: la estructura del contrato del puente cruzado y la arquitectura de doble cadena HyperEVM y HyperL1.
Análisis del puente entre cadenas Hyperliquid
Hyperliquid ha desplegado un contrato puente en Arbitrum para almacenar los activos USDC de los usuarios. Este contrato puente incluye cuatro conjuntos de validadores: hotValidatorSet, coldValidatorSet, finalizers y lockers, que son responsables de diferentes funciones.
mecanismo de validadores
hotValidatorSet: manejar operaciones de alta frecuencia como los retiros de usuarios
coldValidatorSet: modificar la configuración del sistema, puede invalidar solicitudes de retiro
lockers: se puede votar para pausar la ejecución del contrato puente
finalizadores: confirmar el cambio de estado del puente entre cadenas
Actualmente, Hyperliquid solo tiene 4 nodos validador, hotValidatorSet y coldValidatorSet corresponden a 4 direcciones cada uno.
Proceso de depósito
El contrato puente utiliza el método Permit de EIP-2612 para procesar depósitos, permitiendo solo el depósito de USDC. La función batchedDepositWithPermit puede manejar múltiples depósitos a la vez, y el proceso es bastante simple.
Proceso de retiro
Las solicitudes de retiro deben cumplir con las siguientes condiciones:
Obtener el peso de firma de 2/3 del hotValidatorSet
Después de un período de controversia de 200 segundos
Confirmado finalmente por los miembros de finalizers
Durante el período de controversia, los lockers pueden votar para suspender el contrato puente, y el coldValidatorSet puede invalidar las solicitudes de retiro.
mecanismo de bloqueo del contrato puente
Se requiere que 2 lockers voten para bloquear el contrato puente. Para desbloquear, se necesita el peso de la firma de 2/3 del coldValidatorSet, y al mismo tiempo se puede actualizar la dirección del validador.
Actualización del validador
La función updateValidatorSet puede actualizar hotValidatorSet y coldValidatorSet, requiere la firma de todos los miembros de hotValidatorSet y un período de disputa de 200 segundos.
Riesgos potenciales
coldValidatorSet controlado puede eludir todas las defensas y robar los activos de los usuarios.
los finalizadores pueden rechazar la confirmación de la transacción de retiro
lockers pueden bloquear maliciosamente el contrato puente
HyperEVM y la arquitectura de doble cadena
Hyperliquid adopta un "esquema de doble cadena", operando simultáneamente dos cadenas:
Hyperliquid L1: sistema de libro de órdenes dedicado, con licencia
HyperEVM: Cadena compatible con EVM, sin permiso
Las dos cadenas propagan datos a través del mismo protocolo de consenso, pero se ejecutan en diferentes entornos de ejecución. HyperEVM puede leer el estado de L1 y escribir datos en L1.
Precompiles
HyperEVM lee el estado de L1 a través de código precompilado. La dirección precompilada conocida 0x800 puede leer las posiciones de los contratos perpetuos de los usuarios del bloque L1 más reciente.
Eventos
HyperEVM escribe datos en L1 a través de Events. Los nodos L1 escuchan Events de la dirección específica (0x3333...3333) y convierten la intención del usuario en transacciones L1.
consenso HyperBFT
Hyperliquid utiliza el algoritmo de consenso HyperBFT basado en HotStuff, que teóricamente puede procesar 2 millones de órdenes por segundo.
Consideraciones de desarrollo
msg.sender puede ser la dirección del contrato del sistema L1
La interacción no atómica entre EVM y L1 puede llevar a la pérdida de activos
La dirección del contrato EVM debe tener una cuenta de mapeo en L1
Puede haber situaciones en las que no se pueda consultar temporalmente el saldo al realizar un cruce de cadenas de activos.
En general, HyperEVM es similar a una segunda capa basada en Hyperliquid L1, pero ofrece mayor interoperabilidad.
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.
Análisis técnico de Hyperliquid: arquitectura de puentes cross-chain y riesgos del sistema de doble cadena HyperEVM
Análisis profundo de Hyperliquid: arquitectura técnica y riesgos potenciales
Hyperliquid, como un intercambio de libros de órdenes en cadena muy destacado, merece una profunda discusión sobre su arquitectura técnica y seguridad. Este artículo analizará la implementación técnica de Hyperliquid desde dos perspectivas: la estructura del contrato del puente cruzado y la arquitectura de doble cadena HyperEVM y HyperL1.
Análisis del puente entre cadenas Hyperliquid
Hyperliquid ha desplegado un contrato puente en Arbitrum para almacenar los activos USDC de los usuarios. Este contrato puente incluye cuatro conjuntos de validadores: hotValidatorSet, coldValidatorSet, finalizers y lockers, que son responsables de diferentes funciones.
mecanismo de validadores
Actualmente, Hyperliquid solo tiene 4 nodos validador, hotValidatorSet y coldValidatorSet corresponden a 4 direcciones cada uno.
Proceso de depósito
El contrato puente utiliza el método Permit de EIP-2612 para procesar depósitos, permitiendo solo el depósito de USDC. La función batchedDepositWithPermit puede manejar múltiples depósitos a la vez, y el proceso es bastante simple.
Proceso de retiro
Las solicitudes de retiro deben cumplir con las siguientes condiciones:
Durante el período de controversia, los lockers pueden votar para suspender el contrato puente, y el coldValidatorSet puede invalidar las solicitudes de retiro.
mecanismo de bloqueo del contrato puente
Se requiere que 2 lockers voten para bloquear el contrato puente. Para desbloquear, se necesita el peso de la firma de 2/3 del coldValidatorSet, y al mismo tiempo se puede actualizar la dirección del validador.
Actualización del validador
La función updateValidatorSet puede actualizar hotValidatorSet y coldValidatorSet, requiere la firma de todos los miembros de hotValidatorSet y un período de disputa de 200 segundos.
Riesgos potenciales
HyperEVM y la arquitectura de doble cadena
Hyperliquid adopta un "esquema de doble cadena", operando simultáneamente dos cadenas:
Las dos cadenas propagan datos a través del mismo protocolo de consenso, pero se ejecutan en diferentes entornos de ejecución. HyperEVM puede leer el estado de L1 y escribir datos en L1.
Precompiles
HyperEVM lee el estado de L1 a través de código precompilado. La dirección precompilada conocida 0x800 puede leer las posiciones de los contratos perpetuos de los usuarios del bloque L1 más reciente.
Eventos
HyperEVM escribe datos en L1 a través de Events. Los nodos L1 escuchan Events de la dirección específica (0x3333...3333) y convierten la intención del usuario en transacciones L1.
consenso HyperBFT
Hyperliquid utiliza el algoritmo de consenso HyperBFT basado en HotStuff, que teóricamente puede procesar 2 millones de órdenes por segundo.
Consideraciones de desarrollo
En general, HyperEVM es similar a una segunda capa basada en Hyperliquid L1, pero ofrece mayor interoperabilidad.