Fuente del artículo: 仙壤GodRealmX

Autor: Shew,仙壤GodRealmX

Recientemente, Hyperliquid ha recibido una gran atención en el mercado y es uno de los intercambios de libros de órdenes más influyentes en la cadena, con un TVL que ha superado los 2,000 millones de dólares. Mientras es calificado por Messari como el 'Binance en la cadena', incluso ha reavivado la narrativa de Layer3 y cadenas de aplicaciones que ya habían desaparecido del foco público. Con los logros brillantes de aumentar su FDV a 30,000 millones de dólares en un mes desde el lanzamiento del token, Hyperliquid ha captado la atención de un amplio espectro de usuarios, desde usuarios comunes hasta profesionales del sector. Al mismo tiempo, han surgido numerosos informes de investigación sobre Hyperliquid en el mercado, pero estos artículos se centran principalmente en las características de la funcionalidad del producto de libros de órdenes y el mecanismo de negociación, sin profundizar en su construcción técnica subyacente y riesgos de seguridad.

El autor de este artículo tiene como objetivo llenar este vacío, examinando Hyperliquid desde la perspectiva de la construcción técnica y la seguridad, para ayudar a más personas a comprender la estructura y los principios de este proyecto estelar. Abordaremos la construcción y los riesgos del contrato del puente intercadena de Hyperliquid y la construcción de doble cadena HyperEVM y HyperL1, para ayudar a todos a comprender a fondo su arquitectura técnica y su forma de implementación.

(Actualmente, Hyperliquid ocupa el 67% de la oferta total de USDC en Arbitrum)

Análisis del puente intercadena HyperLiquid

Dado que HyperLiquid no ha abierto su componente central, pero ha hecho público el contrato del puente relacionado, tenemos mayor comprensión de los riesgos asociados al contrato del puente. Hyperliquid ha desplegado un contrato del puente en Arbitrum para almacenar los activos USDC depositados por los usuarios. Podemos ver algunas de las acciones de los nodos de Hyperliquid dentro del componente del puente.

Conjunto de validadores

Desde la perspectiva de la clasificación de identidades de los nodos, Hyperliquid tiene 4 grupos de validadores: hotValidatorSet, coldValidatorSet, finalizers y lockers, cada uno con diferentes funciones. El hotValidatorSet se utiliza para responder a operaciones de retiro de usuarios y otras acciones de alta frecuencia, generalmente utilizando billeteras 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 manejar el estado de bloqueo del contrato del puente. Además, el coldValidatorSet tiene la autoridad 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 votan para decidir si pausar el funcionamiento del puente intercadena en situaciones imprevistas. Actualmente, el conjunto de lockers del puente Hyperliquid incluye 5 direcciones y solo se requieren 2 votos de lockers para pausar el funcionamiento del contrato del puente.

En cuanto a los finalizers, también son un grupo de validadores especiales, principalmente responsables de confirmar los cambios de estado del puente intercadena. Desde la perspectiva del contrato, su principal tarea es confirmar depósitos y retiros de usuarios. El puente intercadena de Hyperliquid utiliza un mecanismo de 'envío-confirmación'; por ejemplo, después de que un usuario inicia un retiro, este no se ejecutará de inmediato, sino que deberá esperar un período de tiempo (este período se llama período de disputa). Una vez que finaliza el período de disputa, los miembros dentro de los finalizers ejecutan la transacción de retiro, que se puede llevar a cabo normalmente.

Y una vez que surja un problema con el puente intercadena, por ejemplo, si una declaración de retiro intenta retirar un activo mayor que el saldo real del usuario, los nodos de Hyperliquid pueden utilizar los lockers para votar y pausar la operación del contrato del puente durante el período de disputa, o el coldValidatorSet puede invalidar directamente las solicitudes de retiro problemáticas.

Actualmente, Hyperliquid solo tiene 4 nodos de validadores, por lo que el hotValidatorSet y el coldValidatorSet solo corresponden a 4 direcciones en la 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 directamente por Hyperliquid, utilizando una billetera fría para almacenar las claves.

Depósitos

El contrato del puente Hyperliquid utiliza el método Permit de EIP-2612 para manejar las operaciones de depósito de los usuarios, y dentro del contrato del puente solo se permite a los usuarios depositar un tipo de activo, USDC. Permit es más simple y conveniente para soportar operaciones en lote en comparación con el tradicional modelo de Aprobar-Transferir.

El contrato del puente de Hyperliquid utiliza la función batchedDepositWithPermit para procesar múltiples depósitos en lote. Aquí, la acción de depósito es relativamente simple y no existe riesgo de seguridad de fondos; el proceso es muy sencillo, solo utiliza el método Permit para optimizar la experiencia del usuario.

Retiros

Comparado con los depósitos, los retiros son una operación de alto riesgo, por lo que la lógica de retiro es mucho más compleja que la de los depósitos. Cuando un usuario inicia una solicitud de retiro, los nodos de Hyperliquid llamarán a la función batchedRequestWithdrawals del contrato del puente. En este momento, el contrato del puente requerirá que cada solicitud de retiro obtenga el 2/3 del peso de firma del hotValidatorSet. Es importante notar que muchos documentos describen esto como 'reunir 2/3 de las firmas', pero en realidad, el contrato del puente verifica el 'peso de firma del 2/3'. Actualmente, HyperLiquid solo tiene 4 nodos con el mismo peso, por lo que verificar el peso de la firma y verificar la cantidad de firmas es lo mismo por ahora, pero en el futuro, HyperLiquid podría introducir nodos de mayor peso.

Después de que se inicia una solicitud de retiro, el puente intercadena no transferirá inmediatamente el USDC controlado por el contrato, sino que hay un 'período de disputa', similar al 'período de desafío' en protocolos de prueba de fraude. Actualmente, el período de disputa del contrato del puente Hyperliquid es de 200 segundos, durante el cual pueden ocurrir dos situaciones:

1. Los lockers consideran que la solicitud de retiro actual tiene problemas graves, por lo que pueden votar directamente para pausar/congelar el contrato;

2. Si los nodos consideran que algunas acciones de retiro tienen problemas, los miembros del coldValidatorSet pueden llamar a la función invalidateWithdrawals para hacer que el retiro sea inválido.

Si no hay problemas durante el período de disputa, al finalizar este período, los miembros dentro de los finalizers pueden llamar a la función batchedFinalizeWithdrawals en el contrato del puente para confirmar el estado final. Solo después de que se active esta función, el USDC será enviado a la dirección de la cartera del usuario en Arbitrum.

Por lo tanto, desde la perspectiva del modelo de seguridad, si un atacante malicioso quiere manipular el proceso de retiro de Hyperliquid, necesitará superar tres barreras:

1. Controlar el 2/3 del peso de firma dentro del hotValidatorSet, en otras palabras, obtener una cantidad suficiente de claves privadas o conspirar; actualmente, HyperLiquid solo tiene 4 validadores, lo que aumenta la posibilidad de que estén controlados o conspirados por atacantes.

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

3. Obtener la clave privada de al menos un miembro de finalizers, para que sus acciones de retiro sean confirmadas de forma definitiva. Actualmente, los miembros de finalizers son prácticamente los mismos que los miembros de hotValidatorSet, por lo que siempre que el atacante cumpla con la condición 1 mencionada anteriormente, automáticamente cumplirá con la condición 3.

Bloqueo del contrato del puente

Hemos mencionado varias veces que Hyperliquid ha establecido una función para bloquear el contrato del puente intercadena. En términos específicos, bloquear el puente intercadena requiere que los miembros de lockers llamen a la función voteEmergencyLock en el contrato del puente para votar. Actualmente, cuando 2 lockers llaman a esta función y dan su voto, el contrato del puente se bloqueará y su funcionamiento se detendrá.

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

La función emergencyUnlock, al desbloquear, también ingresará nuevos conjuntos de direcciones de validadores hotValidatorSet y coldValidatorSet, y se actualizará de inmediato.

Actualización del conjunto de validadores

En comparación con intentar superar las barreras existentes en el proceso de retiro, una mejor estrategia de ataque es usar directamente la función updateValidatorSet para actualizar el conjunto de validadores hotValidatorSet y coldValidatorSet. Esto requiere que el llamador proporcione la firma de todos los miembros del hotValidatorSet, y esta operación tiene un período de disputa de 200 segundos.

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

Hasta aquí, hemos introducido la mayor parte de los detalles del puente intercadena Hyperliquid. Este artículo no abarca la lógica de actualización de los lockers y finalizers, cuya actualización requiere la firma del hotValidatorSet, mientras que la eliminación de un miembro requiere la firma del coldValidatorSet.

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

1. Si un hacker controla el coldValidatorSet, puede ignorar cualquier obstáculo para robar activos del usuario. Esto se debe a que el coldValidatorSet tiene el privilegio de operar la función emergencyUnlock, que puede invalidar las acciones de bloqueo del contrato del puente por parte de los lockers, y también puede actualizar de inmediato la lista de nodos. Actualmente, solo hay 4 nodos de validadores en Hyperliquid, lo que aumenta la posibilidad de que las claves privadas sean robadas.

2. Los finalizers se niegan a confirmar la transacción de retiro del usuario, llevando a cabo ataques de revisión; en este caso, los activos del usuario no serán robados, pero puede que no se puedan retirar del contrato del puente;

3. Si los lockers bloquean maliciosamente el puente intercadena, entonces todas las transacciones de retiro no podrán ejecutarse y solo podrán esperar a que el coldValidatorSet desbloquee;

Arquitectura de interacción de doble cadena HyperEVM

Para hacer que las transacciones de libros de órdenes sean programables, como introducir transacciones privadas que requieren contratos inteligentes, Hyperliquid ha lanzado una solución llamada HyperEVM. En comparación con el EVM tradicional, HyperEVM tiene dos ventajas especiales: primero, puede leer el estado del libro de órdenes de HyperLiquid; segundo, los contratos inteligentes dentro de HyperEVM pueden interactuar con el sistema de libros de órdenes de Hyperliquid, lo que amplía significativamente los escenarios de aplicación de Hyperliquid.

Por poner un ejemplo simple, si un usuario necesita garantizar la privacidad de las operaciones de pedidos, puede usar un contrato inteligente similar a Tornado Cash en HyperEVM para agregar una capa de privacidad y luego activar la acción de pedido en el sistema de libros de órdenes de HyperLiquid a través de una interfaz específica.

Antes de presentar HyperEVM, necesitamos presentar la arquitectura especial que Hyperliquid ha preparado para HyperEVM. Dado que Hyperliquid tiene un sistema de libros de órdenes de alto rendimiento personalizado, la velocidad de procesamiento de transacciones en el entorno EVM es mucho más lenta. Para evitar que la velocidad de trabajo del sistema de libros de órdenes se vea afectada, Hyperliquid utiliza un 'sistema de doble cadena', que en esencia permite que los nodos de Hyperliquid ejecuten simultáneamente dos cadenas de bloques a nivel de software, cada nodo almacena localmente los datos de ambas cadenas y procesa las transacciones de ambas cadenas por separado.

Hyperliquid ha establecido una cadena dedicada para su sistema de libros de órdenes personalizado, y también ha agregado una cadena compatible con EVM (HyperEVM). Los datos de estas dos cadenas se propagan entre los nodos a través del mismo protocolo de consenso, existiendo como un estado unificado, pero funcionando en diferentes entornos de ejecución. Llamamos a la cadena dedicada para libros de órdenes Hyperliquid L1 (L1), que es una cadena con control de acceso; mientras que la cadena para HyperEVM es HyperEVM (EVM), que es sin control de acceso, permitiendo que cualquier persona despliegue contratos, los cuales pueden acceder a la información dentro de L1 a través de código precompilado.

Es importante tener en cuenta que la velocidad de generación de bloques de Hyperliquid L1 es mayor que la de la cadena EVM, pero estos bloques aún se ejecutarán en secuencia. Los contratos en la cadena EVM pueden leer datos de bloques anteriores en L1 y escribir datos en futuros bloques de L1. Como se muestra en la imagen:

Para lograr la interacción entre HyperL1 y HyperEVM, Hyperliquid utiliza dos técnicas: Precompilados y Eventos.

Precompilados

Lo que se conoce como precompilados (Precompiles) es, en pocas palabras, trasladar operaciones que son difíciles de implementar en contratos inteligentes y que tienen una alta complejidad directamente a un nivel inferior, moviendo los procesos de cálculo que no son amigables con Solidity y son problemáticos al exterior de los contratos inteligentes convencionales. Este tipo de código precompilado se puede implementar en lenguajes más cercanos a la capa de hardware, como C o C++.

El método de precompilados permite que EVM soporte funciones más avanzadas y complejas, facilitando las necesidades de los desarrolladores de contratos inteligentes. En su forma, los precompilados son en realidad un conjunto de contratos inteligentes especiales que otros contratos inteligentes pueden llamar directamente, pasando parámetros y obteniendo resultados de ejecución de los precompilados. Actualmente, el EVM nativo ha implementado la instrucción ecRecover a través de precompilados, que puede verificar si la firma secp256k1 es correcta, y esa instrucción se encuentra en la dirección 0x01.

Usar precompilados para agregar funciones especiales es la práctica corriente, por ejemplo, Base ha agregado código precompilado P256 para facilitar a los usuarios realizar operaciones de autenticación de identidad WebAuth.

(Esta imagen proviene del sitio web Rollup Codes)

En línea 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 libros de órdenes de Hyperliquid. Se conoce que una dirección de código precompilado de Hyperliquid es 0x0000000000000000000000000000000000000800, que puede leer la situación de las posiciones de los contratos perpetuos de los usuarios en el bloque más reciente de L1.

Eventos

Como mencionamos anteriormente, HyperEVM puede escribir datos en el bloque HyperL1, y esta acción de escritura depende de los eventos. Los eventos son un concepto nativo en EVM que permite a los contratos inteligentes enviar información de registro a fuentes externas (como aplicaciones front-end o escuchadores) durante su ejecución, facilitando que el exterior monitoree el estado de funcionamiento del contrato inteligente.

Por ejemplo, cuando un usuario utiliza la función de transferencia de tokens de un contrato ERC-20, el contrato lanzará un evento correspondiente a Transfer, para que los exploradores de bloques y otras aplicaciones front-end puedan conocer el estado de la transferencia de tokens. Esta información de eventos se incluirá en el bloque, y existen muchas soluciones maduras para escuchar y recuperar registros de eventos.

Ahora muchos escenarios relacionados con la interconexión de cadenas utilizan eventos para transmitir parámetros intercadena. Por ejemplo, en el contrato del puente desplegado en la red principal de Ethereum por Arbitrum, los usuarios pueden llamar a funciones relacionadas para lanzar eventos y desencadenar transacciones en Arbitrum.

La información conocida indica que los nodos de HyperLiquid escucharán

0x3333333333333333333333333333333333333333 (dirección de evento) lanza eventos, y a partir de la información contenida en los eventos se puede conocer la intención del usuario y convertir esa intención en acciones de transacción que se escribirán en futuros bloques de Hyperliquid L1.

Por ejemplo, la dirección de evento mencionada anteriormente proporcionará una función. Cuando un usuario llama a esta función, la dirección de evento lanzará un evento llamado IocOrder. Cuando se genera un bloque en Hyper L1, los nodos de HyperLiquid consultarán primero los eventos lanzados por la dirección de evento en HyperEVM. Cuando se detecta un nuevo evento IocOrder, se convertirá en una operación de pedido en Hyper L1.

HyperBFT

A nivel del protocolo de consenso, Hyperliquid utiliza un protocolo llamado HyperBFT, que es un método derivado de HotStuff. Actualmente, HotStuff-2 es uno de los protocolos de consenso con la menor complejidad más reciente.

Según la información disponible, en un principio HyperLiquid utilizó el algoritmo de consenso Tendermint, que es el algoritmo de consenso predeterminado en el sistema Cosmos. Sin embargo, este algoritmo tiene una eficiencia relativamente baja, ya que cada fase requiere un intercambio de mensajes de Todos a Todos, y 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 utiliza Tendermint, Hyperliquid puede procesar hasta 20,000 órdenes por segundo. Para alcanzar la velocidad de un intercambio centralizado, el equipo de HyperLiquid desarrolló el algoritmo HyperBFT basado en HotStuff, implementándolo en Rust. Teóricamente, puede procesar hasta 2 millones de órdenes por segundo.

La siguiente imagen muestra el método de transmisión de mensajes del consenso HyperBFT en situaciones no paralelas. Se puede ver que todos los mensajes son recopilados y transmitidos uniformemente por el líder, eliminando la necesidad de que los nodos intercambien mensajes entre sí, lo que reduce significativamente la complejidad.

En resumen, HyperBFT es actualmente un protocolo de consenso en el que el líder actual genera el bloque, todos los nodos participan en la votación y envían de manera uniforme los resultados de la votación 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, y este artículo no se extiende sobre eso debido a limitaciones de espacio y enfoque.

Puntos clave que los desarrolladores deben tener en cuenta

El mecanismo de lectura de datos basado en precompilados mencionado anteriormente es bastante perfecto; los desarrolladores de Solidity no necesitan escribir código específico al leer el estado de Hyper L1, pero deben tener en cuenta el problema de msg.sender. Al igual que en la mayoría de las capas dos de Ethereum, HyperLiquid también permite a los usuarios interactuar directamente con los contratos del sistema en Hyper L1, desencadenando indirectamente acciones de transacción en la cadena HyperEVM. En este caso, si el contrato inteligente lee el campo msg.sender dentro de esta transacción, encontrará que msg.sender corresponde a la dirección del contrato del sistema de 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 el problema de la no atomicidad de la interacción. Si un usuario hace un pedido indirecto en L1 a través de la dirección de evento mencionada anteriormente en HyperEVM, pero no hay suficientes activos en L1, entonces la transacción seguramente fallará, pero el usuario no recibirá ningún mensaje de error al llamar a la función de la dirección de evento. El problema de la no atomicidad de la interacción puede causar daños a los activos del usuario. En este momento, para el desarrollador, es necesario manejar manualmente la situación de fallo del pedido en el lado del contrato inteligente en EVM. Además, el contrato inteligente dentro de EVM debe tener una función para la recuperación final de fondos, evitando que los activos del usuario queden atrapados en L1 de manera indefinida.

En segundo lugar, la dirección del contrato correspondiente a EVM debe tener una cuenta mapeada en L1. Después de que el usuario despliegue un contrato inteligente en EVM, necesita transferir una pequeña cantidad de USDC a la dirección mapeada en L1, obligando a L1 a crear una cuenta para la dirección del contrato. Esta parte de la operación puede estar relacionada con el consenso subyacente de HyperLiquid, que está claramente definido en la documentación de Hyperliquid.

Finalmente, los desarrolladores deben tener en cuenta algunas situaciones especiales, especialmente en lo que respecta a los saldos de los tokens. Hyper L1 tiene una dirección especial para la transferencia de activos, pero cuando un usuario envía activos a esa dirección especial, los activos se trasladan de L1 a la cadena HyperEVM. Dado que los nodos de HyperLiquid ejecutan simultáneamente la cadena EVM y la cadena L1, puede suceder que, después de que el usuario transfiera activos, HyperEVM no genere bloques durante un tiempo prolongado. En ese momento, el usuario no podrá ver su saldo en la cadena EVM.

En resumen, los activos del usuario están atrapados en el puente intercadena y no se pueden consultar ni en L1 ni en la cadena EVM. El protocolo construido por los desarrolladores debe manejar estas situaciones especiales para evitar que los usuarios se sientan ansiosos.

En resumen, HyperEVM es similar a una capa dos basada en Hyperliquid L1. HyperEVM depende del código precompilado para leer el estado de L1 y también depende de eventos para interactuar con Hyper L1. L1 también tiene algunos contratos del sistema que ayudan a los usuarios a desencadenar transacciones dentro de HyperEVM o realizar transferencias de activos entre cadenas. Sin embargo, a diferencia de la arquitectura típica de Layer1-Layer2, Hyperliquid proporciona una mayor interoperabilidad para HyperEVM.

Referencias

Hyperliquid: El L1 de libros de órdenes hiperoptimizado

hyperliquid-dex/contracts

La guía no tan definitiva sobre los Precompilados de Hyperliquid.

¿Cuál es la diferencia entre PBFT, Tendermint, HotStuff y HotStuff-2?