Hyperliquid Technical Interpretation: HyperEVM and Its Potential Problems

Author: Shew, GodRealmX

Hyperliquid, which has attracted much attention in the market recently, is one of the most influential on-chain order book exchanges. Its TVL has exceeded 2 billion US dollars. While being evaluated by Messari as "Binance on the chain", it has even brought the Layer3 and application chain narratives that have faded out of the public's perspective back into the spotlight. With the brilliant achievement of FDV reaching 30 billion US dollars within one month of the launch of the token, Hyperliquid has received widespread attention from ordinary users to practitioners. At the same time, a large number of research reports on Hyperliquid have emerged on the market, but these articles basically focus on its characteristics in order book product functions and trading mechanisms, without in-depth exploration of the technical structure and security risks behind it.

The author of this article aims to fill this gap and examine Hyperliquid purely from the perspective of technical structure and security, to help more people understand the structure and principles of this star project. We will elaborate from two perspectives: the structure and hidden dangers of the Hyperliquid cross-chain bridge contract, and the dual-chain structure of HyperEVM and HyperL1, to help everyone deeply understand the technical architecture and implementation behind it.

(Currently Hyperliquid occupies 67% of the total supply of USDC on Arbitrum)

HyperLiquid cross-chain bridge analysis

Since HyperLiquid has not open sourced core components, but has open sourced related bridge contracts, we are more aware of the risks of bridge contracts. Hyperliquid has deployed a bridge contract on Arbitrum to store USDC assets deposited by users. We can see some behaviors of the Hyperliquid node in the Bridge component.

Validator Set

From the perspective of node identity division, Hyperliquid has 4 groups of validators, namely hotValidatorSet, coldValidatorSet, finalizers and lockers, corresponding to different functions. Among them, hotValidatorSet is used to respond to high-frequency behaviors such as user withdrawal operations, and generally uses hot wallets to respond to Hyperliquid users' withdrawal requests at any time.

And coldValidatorSet is mainly used to modify system configuration, such as rewriting the list of validator sets such as hotValidatorSet or lockers, or processing the lock status of the bridge contract, and coldValidatorSet has the right to directly invalidate certain withdrawal requests.

Lockers are a group of validators with special permissions, similar to the "security committee" commonly used by Layer2, who will vote to decide whether to suspend the operation of the cross-chain bridge in some emergencies. Currentlythe lockers set of the Hyperliquid bridgecontains5 addresses, and only 2 lockers need to voteto suspendthe operation of the bridge contract.

As for finalizers, they are actually a group of special validators, which are mainly used to confirm the state changes of the cross-chain bridge. From the contract level, they mainly confirm user deposits and withdrawals. Hyperliquid's cross-chain bridge usesthesubmit-confirm mechanism.For example, after a user initiates a withdrawal, it will not be executed immediately, but a period of time (this period of time is called the dispute period). After the dispute period ends, members in the finalizers execute withdrawal transactions, and withdrawals can be executed normally. Once a problem occurs in the cross-chain bridge, such as a withdrawal statement that the assets to be withdrawn are greater than the actual asset balance of the user, the Hyperliquid node can use lockers to vote to suspend the operation of the cross-chain bridge contract during the dispute period, or directly invalidate the problematic withdrawal request by coldValidatorSet.

Currently, Hyperliquid has only 4 validator nodes, so hotValidatorSet and coldValidatorSet only correspond to 4 on-chain addresses. When Hyperliquid is initialized, it automatically registers the addresses in hotValidatorSet as members of lockers and finalizers, while coldValidatorSet is controlled by Hyperliquid itself and uses cold wallets to store keys.

Deposit

Hyperliquid's bridge contract uses the Permit method of EIP-2612 to process user deposit operations, and the bridge contract only allows users to deposit USDC as an asset. Permit is simpler than the traditional Approve—Transfer model and is also convenient for supporting batch operations.

Hyperliquid's bridge contract uses the batchedDepositWithPermit function to batch process multiple deposits. The deposit action here is relatively simple, there is no risk of fund security, and the processing flow is very simple. It only uses the Permit method to optimize UX.

Withdrawal

Compared to deposit, withdrawal is a highly risky operation, so the withdrawal logic is much more complicated than deposit. When the user initiates a withdrawal request, the Hyperliquid node will call the batchedRequestWithdrawals function of the bridge contract. At this time, the bridge contract will require that each withdrawal request must gather 2/3 signature weights of the hotValidatorSet. Note that many documents describe this as "collecting 2/3 signatures", but in fact the bridge contract checks "2/3 signature weights". Currently, HyperLiquid has only 4 nodes with the same weight, so the check signature weight and check signature quantity are temporarily consistent, but in the future, HyperLiquid may introduce high-weight nodes.

When a withdrawal request is initiated, the cross-chain bridge will not immediately transfer the USDC controlled by the contract, but there will be a "dispute period", which is similar to the "challenge period" in the fraud proof protocol. Currently, the dispute period of the Hyperliquid bridge contract is 200 seconds. Two situations may occur during the dispute period: 1. lockers believe that there are serious problems with the current withdrawal request. At this time, they can directly vote to suspend/freeze the contract; 2. The node believes that there are problems with some withdrawal behaviors. At this time, the coldValidatorSet members can call the invalidateWithdrawals function to invalidate the withdrawal.

If no problems arise during the dispute period, after the dispute period ends, members in finalizers can call the batchedFinalizeWithdrawalsfunction in the bridge contract to finalize the final status. Only after this function is triggered will USDC be transferred to the user's wallet address in Arbitrum.

So from the perspective of the security model, if a malicious attacker wants to tamper with Hyperliquid's withdrawal process, he needs to break through three lines of defense:

1. Master 2/3 of the signature weight in hotValidatorSet, in other words, you need to obtain a certain number of private keys or collude; currently HyperLiquid has only 4 validators, and the possibility of being controlled or colluded by the attacker is not low;

2. During the dispute period, the attacker should avoid being discovered by his malicious transactions. Once discovered, it is very likely that lockers will lock the contract. We will discuss this in detail below.

3. Obtain the private key of at least one finalizers member to have your withdrawal behavior finally confirmed. Currently, the finalizers members are basically the same as the hotValidatorSet members, so as long as the attacker meets the above condition 1, condition 3 is automatically met.

Bridge Contract Locking

We have mentioned many times before that Hyperliquid has set up a function to lock the cross-chain bridge contract. Specifically, locking the cross-chain bridge requires lockers members to call the voteEmergencyLock function in the cross-chain bridge contract to vote. Currently, when two lockers call the function and give a vote, the cross-chain bridge contract will be locked and suspended. However, it should be noted that HyperLiquid's cross-chain bridge also provides an unvoteEmergencyLock function, which allows lockers members to withdraw their votes. Once the cross-chain bridge contract is successfully locked, it can only be unlocked through a function called emergencyUnlock, which requires collecting signatures of more than 2/3 of the members of coldValidatorSet.

emergencyUnlock function will also input new hotValidatorSet and coldValidatorSet validator address sets while unlocking, and will be updated immediately.

Validator Set Update

Compared to trying to break through the existing defenses in the withdrawal process, a better attack method is to directly use the updateValidatorSet function to update the hotValidatorSet and coldValidatorSet validator sets. This requires the caller to give the signatures of all hotValidatorSet members, and the operation has a 200-second dispute period.

After the dispute period ends, the finalizers member needs to call the finalizeValidatorSetUpdate function to complete the final status update.

So far, we have introduced most of the details of Hyperliquid's cross-chain bridge. This article does not introduce the update logic of lockers and finalizers. The update of both requires the signature of hotValidatorSet, and the removal of a member requires the signature of coldValidatorSet.

In summary, Hyperliquid's bridge contract contains the following risks:

1. Hackers can ignore any obstacles to steal user assets after controlling coldValidatorSet. Because coldValidatorSet has the operation permission of emergencyUnlock function, it can invalidate the locking action of lockers on the bridge contract and update the node list in real time. Currently, Hyperliquid only has 4 validator nodes, and the possibility of having private keys stolen is not low;

2.finalizers refuse to make final confirmation of the user's withdrawal transaction and launch a review attack; in this case, the user's assets will not be stolen, but they may not be able to withdraw from the bridge contract;

3.lockers maliciously target the cross-chain bridge. At this time, all withdrawal transactions cannot be executed and can only wait for coldValidatorSet to be unlocked;

HyperEVM and dual-chain interaction architecture

In order to make order book transactions programmable, such as introducing privacy transactions and other scenarios that require smart contracts to implement, Hyperliquid launched a solution calledHyperEVM. It has two special advantages over the traditional EVM: one is that HyperEVM can read the order book status of HyperLiquid, and the other is that the smart contract in HyperEVM can interact with the Hyperliquid order book system, which greatly expands the application scenarios of Hyperliquid.

To give a simple example, if the user needs to ensure the privacy of the pending order operation, a layer of privacy can be set on HyperEVM through a smart contract similar to Tornado Cash, and then the pending order action can be triggered in the HyperLiquid order book system through a specific interface.

Before introducing HyperEVM, we need to introduce the special architecture that Hyperliquid has prepared for HyperEVM. Because Hyperliquid has a customized ultra-high-performance order book system, the transaction processing speed in the EVM environment is much slower. In order to avoid the order book system from slowing down, Hyperliquid uses a "dual-chain solution", which essentially allows Hyperliquid node devices to run two blockchains at the same time at the software level. Each node stores the data of the two chains locally and processes the transactions of the two chains separately. Hyperliquid has set up a chain specifically for its customized order book system, and added an EVM-compatible chain (HyperEVM). The data of these two chains is propagated between the node groups through the same consensus protocol, existing as a unified state, but running separately in different execution environments. We call the chain dedicated to the order book Hyperliquid L1 (L1), which is permissioned; the chain used for HyperEVM is HyperEVM (EVM), which is permissionless and anyone can deploy contracts that can access information in L1 through precompiled code. It should be noted that the block generation rate of Hyperliquid L1 is faster than that of the HyperEVM chain, but the blocks will still be executed in sequence. Contracts on the EVM chain can read data from past L1 blocks and write data to future L1 blocks. As shown below:

In order to enable interaction between HyperL1 and HyperEVM, Hyperliquid uses two technical means, Precompiles and Events.

Precompiles

The so-called precompile (Precompiles), to put it bluntly, is to move some operations that are difficult to implement and have high complexity in smart contracts directly to the bottom layer for implementation, and move the calculation process that is not friendly to Solidity and is more troublesome to the outside of the conventional smart contract for processing. This type of precompiled code can be implemented in languages ​​​​such as C and C++ that are closer to the bottom layer of the device than Solidity.

The precompilation method allows EVM to support more advanced and complex functions, which is convenient for supporting the needs of smart contract developers. In terms of expression, precompilation is essentially a set of special smart contracts. Other smart contracts can directly call these special contracts, pass in parameters and obtain the return results of precompiled execution. Currently, the ecRecover instruction is implemented in the native EVM through precompilation. You can check whether the secp256k1 signature is correct inside the EVM, and this instruction is located at the 0x01 address.

Using precompilation to add some special functions is the current mainstream practice. For example, Base has added P256 precompiled code to facilitate users to perform WebAuth identity authentication operations.

（This picture comes from the Rollup Codes website）

Consistent with this current mainstream solution, HyperEVM also adds a series ofprecompiledcodes to enable EVM to read the status of the Hyperliquid order booksystem. A currently known precompiled code address for Hyperliquid is 0x0000000000000000000000000000000000000000800, which can read the position of the user's perpetual contract in the most recent L1 block.

Events

As mentioned above, HyperEVM can write data to HyperL1 blocks, and the writing behavior depends on Events. Events is a native concept in EVM, which allows smart contracts to send log information to the outside world (such as front-end applications or listeners) during execution, so that the outside world can monitor the operation of smart contracts.

For example, when a user uses the token transfer function of the ERC-20 contract, the contract will throw the corresponding Event of Transfer, so that front-end applications such as block browsers can know the token transfer situation. These Events information will be included in the block, and there are a lot of mature solutions for monitoring and retrieving Events logs.

Nowadays, many cross-chain related scenarios will use Events to pass cross-chain parameters. For example, Arbitrum is deployed in the bridge contract on the Ethereum mainnet. Users can call related functions to throw events to trigger transactions on Arbitrum.

Known information shows that the HyperLiquid node will listen to the Events thrown by

0x3333333333333333333333333333333333333333 (event address), learn the user's intention based on the information contained in the Events, and convert the intention into a transaction action based on this, and write it into the future Hyperliquid L1 block.

For example, the above event address will provide a function. When the user calls this function, the event address will throw an Event named IocOrder. When a Hyper L1 block is generated, the HyperLiquid node will first query the Events thrown by the recent event address in HyperEVM. When a new IocOrder event is retrieved, it will be converted into an order operation in Hyper L1.

HyperBFT

At the consensus protocol level, Hyperliquid uses a protocol called HyperBFT, which is a derivative method based on HotStuff.Currently, HutStuff-2 is one of the latest consensus protocols with the lowest complexity.

According to the data, HyperLiquid initially used the Tendermint consensus algorithm, which is the default consensus algorithm in the Cosmos system, but the algorithm is inefficient and requires all-to-all message exchange at each stage. Each node must send messages to all other nodes, and the communication complexity is O(n²), where n is the number of nodes.

If Tendermint is used, Hyperliquid can process up to 20,000 orders per second. In order to reach the speed of centralized exchanges, the HyperLiquid team developed the HyperBFT algorithm based on HotStuff and implemented it in Rust, which can theoretically process up to 2 million orders per second.

The following figure shows the message transmission method of HyperBFT consensus in a non-parallel situation. It can be seen that all messages are summarized and broadcasted uniformly by the Leader, eliminating the step of exchanging messages between nodes and greatly reducing the complexity.

In short, HyperBFT is a consensus protocol in which the current leader produces blocks, all nodes participate in voting and send the voting results to the Leader, and then the next leader rotates. In fact, the specific details involved in Hotstuff and Tendermint are much more complicated. Due to the limited length and focus of this article, I will not go into details here.

Key points for developers

The above data reading mechanism based on Precompiles is relatively perfect. Solidity developers do not need to write corresponding code to read the Hyper L1 state, but they need to pay attention to the msg.sender problem. Similar to most Ethereum second layers, HyperLiquid also allows users to interact directly with the system contract in Hyper L1 and indirectly trigger transaction actions on the HyperEVM chain. At this time, if the smart contract reads the msg.sender field in the transaction, it will be found that msg.sender corresponds to the address of the HyperL1 system contract, not the user address who initially initiated the transaction on HyperL1.

As for the interaction between EVM and L1, developers need to pay attention to a series of issues. The first problem is the non-atomicity of interaction.If the user places an order indirectly in L1 through the aforementioned event address on HyperEVM, but there are not enough assets in L1, then the transaction will definitely fail, but there will be no error return prompt when the user calls the function of the event address.The non-atomicity of interaction may cause the user's assets to be damaged. At this time, for developers, it is necessary to manually handle the failure of placing orders on the EVM smart contract side.In addition, the smart contract in EVM should have a function for the final fund recovery to prevent the user's assets from being unable to be withdrawn in L1 forever.

Secondly, the contract address corresponding to EVM must have amappedaccount in L1.After the user completes the deployment of the smart contract in EVM, it is necessary to transfer a small amount of USDC to the mapping address in L1 to force L1 to create an account for the contract address. This part of the operation may be related to the underlying consensus of HyperLiquid, and there are clear requirements in the Hyperliquid documentation.

Finally, developers need to pay attention to some special cases, especially the balance of tokens. Hyper L1 has a special address for asset transfer, but when the user sends the asset to this special address, the asset will cross from L1 to the HyperEVM chain. Since the HyperLiquid node actually executes the EVM chain and the L1 chain at the same time, HyperEVM may not produce a block for a long time after the user transfers the asset. At this time, the user cannot read his balance on the EVM chain.

In short, the user's assets are stuck in the cross-chain bridge at this time, and they cannot be queried in either the L1 or the EVM chain. The protocol built by the developer should handle the above special cases to avoid panic among users.

In summary, HyperEVM is similar to the second layer based on Hyperliquid L1. HyperEVM relies on precompiled code to read L1 status, and also relies on Events to interact with Hyper L1. L1 also has some system contracts to help users trigger transactions in HyperEVM or cross-chain assets. However, unlike the general Layer1-Layer2 architecture, Hyperliquid provides HyperEVM with higher interoperability.

References

1. Hyperliquid: The Hyperoptimized Order Book L1

2. hyperliquid-dex/contracts

3. The Not-So-Definitive guide to Hyperliquid Precompiles.

4. What is the difference between PBFT, Tendermint, HotStuff, and HotStuff-2?