Análisis profundo de la arquitectura y los riesgos potenciales de Hyperliquid desde una perspectiva técnica
Hyperliquid, como un intercambio de libros de órdenes en cadena que ha recibido mucha atención recientemente, tiene un TVL que ha superado los 2 mil millones de dólares y es conocido como "Binance en cadena". Este artículo analizará en profundidad la estructura del contrato del puente跨链 de Hyperliquid, la arquitectura de HyperEVM y sus posibles vulnerabilidades de seguridad, ayudando a los lectores a comprender completamente la construcción técnica de este proyecto estrella.
Análisis del puente cross-chain Hyperliquid
Hyperliquid ha desplegado un contrato puente cross-chain en Arbitrum para almacenar los activos USDC de los usuarios. Este contrato puente incluye cuatro grupos de validadores:
hotValidatorSet: responsable de operaciones de alta frecuencia como el retiro de usuarios
coldValidatorSet: responsable de la modificación de la configuración del sistema y del manejo de emergencias
lockers: similar al comité de seguridad, puede suspender la operación del contrato puente
finalizers: confirmar el cambio de 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. Utiliza la función batchedDepositWithPermit para procesar depósitos en lotes, simplificando la operación del usuario.
Proceso de retiro
La solicitud de retiro debe obtener el peso de firma de 2/3 del hotValidatorSet. Después hay un "período de disputa" de 200 segundos, durante el cual los lockers pueden suspender el contrato o el coldValidatorSet puede invalidar el retiro. Después del período de disputa, los finalizers confirman el estado final.
Mecanismo de bloqueo del contrato puente
Los lockers pueden votar para bloquear el contrato puente. Se requieren 2 votos de lockers para pausar la operación. Para desbloquear, se necesita la firma de 2/3 del coldValidatorSet, y también se puede actualizar el conjunto de validadores.
Actualización del conjunto de validadores
La función updateValidatorSet puede actualizar hotValidatorSet y coldValidatorSet, requiriendo la firma de todo el hotValidatorSet, con un período de controversia de 200 segundos.
riesgos potenciales
coldValidatorSet controlado puede eludir la defensa para robar activos
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 interacción de doble cadena
Hyperliquid adopta un "esquema de doble cadena":
Hyperliquid L1: cadena de órdenes específica, de permisos
HyperEVM: cadena compatible con EVM, sin permiso
Las dos cadenas difunden datos a través del mismo protocolo de consenso, pero se ejecutan por separado. La velocidad de creación de bloques de L1 es más rápida, la cadena EVM puede leer datos de L1 y escribir en L1.
Precompiles
HyperEVM agrega código precompilado para permitir la lectura del estado del libro de órdenes L1. Por ejemplo, la dirección 0x800 puede leer la posición del contrato perpetuo del bloque L1 más reciente.
Eventos
HyperEVM escribe datos en L1 a través de eventos. Los nodos L1 escuchan eventos de direcciones específicas y los convierten en transacciones L1.
consenso HyperBFT
Desarrollado sobre HotStuff, teóricamente puede procesar 2 millones de órdenes por segundo. Utiliza un método de agregación y difusión por un líder, lo que reduce la complejidad.
Consideraciones para desarrolladores
msg.sender puede ser la dirección del contrato del sistema L1.
La no atomicidad de las interacciones puede llevar a la pérdida de activos
La dirección del contrato EVM debe crear una cuenta mapeada en L1
Los activos entre cadenas pueden no ser consultables temporalmente.
En general, HyperEVM es similar a una arquitectura de segunda capa basada en L1, pero ofrece una mayor interoperabilidad. Los desarrolladores deben tener en cuenta el manejo de diversas situaciones especiales para garantizar la seguridad de los activos de los usuarios.
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.
15 me gusta
Recompensa
15
7
Republicar
Compartir
Comentar
0/400
GateUser-e87b21ee
· 08-02 20:50
TVL 2 mil millones de dólares, la gente es tonta y tiene mucho dinero
Ver originalesResponder0
MetaReckt
· 08-02 07:57
La seguridad es regular, seguiré observando.
Ver originalesResponder0
LidoStakeAddict
· 07-31 01:47
TVL aunque es fuerte, simplemente no puede sostenerse.
Ver originalesResponder0
MEVHunterX
· 07-31 01:45
Los que están apresurados para tomar a la gente por tonta todavía están jugando con puentes cross-chain.
Ver originalesResponder0
MetamaskMechanic
· 07-31 01:41
Otra vulnerabilidad de seguridad en la cadena de segundo nivel
Ver originalesResponder0
BitcoinDaddy
· 07-31 01:37
Con esta seguridad, ¿quién se atreve a poner dinero?
Ver originalesResponder0
NervousFingers
· 07-31 01:22
La Casa Blanca me ha gritado sobre deudas, soy un veterano tembloroso en el trading.
Análisis de la tecnología Hyperliquid: ventajas de la arquitectura y riesgos potenciales
Análisis profundo de la arquitectura y los riesgos potenciales de Hyperliquid desde una perspectiva técnica
Hyperliquid, como un intercambio de libros de órdenes en cadena que ha recibido mucha atención recientemente, tiene un TVL que ha superado los 2 mil millones de dólares y es conocido como "Binance en cadena". Este artículo analizará en profundidad la estructura del contrato del puente跨链 de Hyperliquid, la arquitectura de HyperEVM y sus posibles vulnerabilidades de seguridad, ayudando a los lectores a comprender completamente la construcción técnica de este proyecto estrella.
Análisis del puente cross-chain Hyperliquid
Hyperliquid ha desplegado un contrato puente cross-chain en Arbitrum para almacenar los activos USDC de los usuarios. Este contrato puente incluye cuatro grupos de validadores:
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. Utiliza la función batchedDepositWithPermit para procesar depósitos en lotes, simplificando la operación del usuario.
Proceso de retiro
La solicitud de retiro debe obtener el peso de firma de 2/3 del hotValidatorSet. Después hay un "período de disputa" de 200 segundos, durante el cual los lockers pueden suspender el contrato o el coldValidatorSet puede invalidar el retiro. Después del período de disputa, los finalizers confirman el estado final.
Mecanismo de bloqueo del contrato puente
Los lockers pueden votar para bloquear el contrato puente. Se requieren 2 votos de lockers para pausar la operación. Para desbloquear, se necesita la firma de 2/3 del coldValidatorSet, y también se puede actualizar el conjunto de validadores.
Actualización del conjunto de validadores
La función updateValidatorSet puede actualizar hotValidatorSet y coldValidatorSet, requiriendo la firma de todo el hotValidatorSet, con un período de controversia de 200 segundos.
riesgos potenciales
HyperEVM y la arquitectura de interacción de doble cadena
Hyperliquid adopta un "esquema de doble cadena":
Las dos cadenas difunden datos a través del mismo protocolo de consenso, pero se ejecutan por separado. La velocidad de creación de bloques de L1 es más rápida, la cadena EVM puede leer datos de L1 y escribir en L1.
Precompiles
HyperEVM agrega código precompilado para permitir la lectura del estado del libro de órdenes L1. Por ejemplo, la dirección 0x800 puede leer la posición del contrato perpetuo del bloque L1 más reciente.
Eventos
HyperEVM escribe datos en L1 a través de eventos. Los nodos L1 escuchan eventos de direcciones específicas y los convierten en transacciones L1.
consenso HyperBFT
Desarrollado sobre HotStuff, teóricamente puede procesar 2 millones de órdenes por segundo. Utiliza un método de agregación y difusión por un líder, lo que reduce la complejidad.
Consideraciones para desarrolladores
En general, HyperEVM es similar a una arquitectura de segunda capa basada en L1, pero ofrece una mayor interoperabilidad. Los desarrolladores deben tener en cuenta el manejo de diversas situaciones especiales para garantizar la seguridad de los activos de los usuarios.