As the hype subsides, explain Hyperliquid’s bridge contract, HyperEVM and its potential problems from a technical perspective

Author: Shew, GodRealmX

Hyperliquid, which has attracted widespread market attention 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 faded out of the public. The perspective of Layer 3 and application chain narrative are back in the spotlight. With the brilliant achievement of raising FDV to US$30 billion within one month of Token's launch, Hyperliquid has gained 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 are basically Focusing on its features in order book product functions and trading mechanisms, it did not delve into 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 safety, so as to help more people understand the structure and principles of this star project. We will elaborate on the structure and hidden dangers of the Hyperliquid cross-chain bridge contract and the double-chain structure of HyperEVM and HyperL1 to help everyone understand the technical architecture and implementation behind it.

 (Hyperliquid currently accounts for 67% of the total USDC supply on Arbitrum)

HyperLiquid cross-chain bridge analysis

Since HyperLiquid does not have open source core components, but has open sourced related bridge contracts, we have a better understanding of the risks associated with bridge contracts. Hyperliquid has deployed a bridge contract on Arbitrum to store USDC assets deposited by users. We can see part of the behavior of the Hyperliquid node in the Bridge component.

validator set

From the perspective of node identity division, Hyperliquid has four 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. Hot wallets are generally used to respond to Hyperliquid users' withdrawal requests at any time.

The coldValidatorSet is mainly used to modify the system configuration, such as rewriting the list of validator sets such as hotValidatorSet or lockers, or processing the locking 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" used by Layer 2. They will vote to decide whether to suspend the operation of the cross-chain bridge in some emergencies. Currently, the lockers set of the Hyperliquid bridge contains 5 addresses, and only 2 lockers are needed to vote to suspend the operation of the bridge contract.

As for finalizers, they are actually a group of special verifiers, mainly used to confirm the status changes of cross-chain bridges. From a contract perspective, the main confirmations are user deposits and withdrawals. Hyperliquid's cross-chain bridge uses a "submit-confirm" mechanism. For example, after a user initiates a withdrawal, it will not be executed immediately and needs to wait for a period of time (this period is called the dispute period). After the dispute period is over and members of the finalizers execute the withdrawal transaction, the withdrawal can be executed normally.

Once there is a problem with the cross-chain bridge, for example, a certain withdrawal statement states that the assets to be withdrawn are greater than the asset balance actually owned by the user, Hyperliquid nodes can use lockers to vote to suspend the operation of the cross-chain bridge contract during the dispute period, or directly use coldValidatorSet Invalidate problematic withdrawal requests.

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

deposit

Hyperliquid's bridge contract is based on the Permit method of EIP-2612 to handle user deposit operations, and the bridge contract only allows users to deposit USDC as an asset. Compared with the traditional Approve-Transfer mode, Permit is simpler and easier to support 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 process is very simple. It only uses the Permit method to optimize the UX.

Withdraw money

Compared with deposits, withdrawals are a highly risky operation, so the logic of withdrawals will be much more complicated than deposits. When a 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 collect 2/3 of the signature weight of hotValidatorSet. Note that many documents describe here as "collecting 2/3 of the signatures", but in fact the bridge contract checks " 2/3 signature weight”. Currently, HyperLiquid only has 4 nodes with the same weight, so checking the signature weight and checking the number of signatures are temporarily the same, but in the future, HyperLiquid may introduce nodes with high weights.

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", similar to the "challenge period" in the fraud proof protocol. The current dispute period of the Hyperliquid bridge contract is 200 seconds. During the dispute period, two situations may occur:

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 is a problem with some withdrawals. At this time, the coldValidatorSet member can call the invalidateWithdrawals function to invalidate the withdrawal.

If there are no problems during the dispute period, after the dispute period ends, members of the finalizers can call the batchedFinalizeWithdrawals function 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 a security model perspective, if a malicious attacker wants to manipulate Hyperliquid's withdrawal process, they need to break through three lines of defense:

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

2. During the dispute period, attackers should prevent their malicious transactions from being discovered. Once discovered, it is likely that lockers will lock the contract. We will discuss this part specifically below.

3. Obtain the private key of at least one finalizer member so that your withdrawal behavior can be finally confirmed. At present, the finalizers members and hotValidatorSet members are basically the same, so as long as the attacker meets the above condition 1, condition 3 is automatically met.

Bridge contract lock-in

We mentioned many times before that Hyperliquid has set up a function to lock cross-chain bridge contracts. Specifically, locking the cross-chain bridge requires locker members to call the voteEmergencyLock function in the cross-chain bridge contract to vote. Currently, when two lockers call this function to vote, the cross-chain bridge contract will be locked and suspended.

However, it should be noted that HyperLiquid's cross-chain bridge also provides the unvoteEmergencyLock function, allowing locker 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 more than 2/3 of the signature weights of coldValidatorSet members.

The emergencyUnlock function also enters the new hotValidatorSet and coldValidatorSet validator address sets while unlocking them, and is updated immediately.

Validator set update

Rather than trying to break through the existing defense lines 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 sign all hotValidatorSet members, and the operation has a 200-second dispute period.

When the dispute period is over, the finalizers members need to call the finalizeValidatorSetUpdate function to complete the final status update.

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

To summarize, Hyperliquid’s bridge contract contains the following risks:

1. After hackers control coldValidatorSet, they can ignore any obstruction and steal user assets. Because coldValidatorSet has the operation authority of the emergencyUnlock function, it can invalidate the locking action of the locker on the bridge contract and update the node list in real time. Currently, there are only 4 validator nodes in Hyperliquid, and the possibility of having the private key stolen is not low;

2. Finalizers refuse to finalize the user’s withdrawal transaction and launch censorship attacks; in this case, the user’s assets will not be stolen, but the user may not be able to withdraw money 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 the coldValidatorSet to be unlocked;

HyperEVM and dual-chain interaction architecture

In order to make order book transactions programmable, such as introducing private transactions and other scenarios that require smart contracts, Hyperliquid launched a solution called HyperEVM. It has two special advantages compared to traditional EVM: First, HyperEVM can read HyperLiquid's order book status, and second, the smart contracts 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 pending order operations, they can implement a layer of privacy on HyperEVM through a smart contract similar to Tornado Cash, and then trigger the pending order action in HyperLiquid's order book system through a specific interface.

Before introducing HyperEVM, we need to introduce the special architecture prepared by Hyperliquid for HyperEVM. Since Hyperliquid has a customized ultra-high-performance order book system, the transaction processing speed in the EVM environment is much slower. In order to prevent the order book system from slowing down, Hyperliquid uses a "dual-chain solution", which essentially allows the Hyperliquid node device to run two blockchains simultaneously at the software level, and each node stores the data of the two chains locally. Transactions on the two chains are processed separately.

Hyperliquid has specially set up a chain for its customized order book system, and also added an EVM-compatible chain (HyperEVM). The data of these two chains are spread among the node groups through the same consensus protocol and exist as a unified state, but run separately in different execution environments. We call the order book dedicated chain Hyperliquid L1 (L1), which is permissioned; and the chain used for HyperEVM is HyperEVM (EVM), which is permissionless and anyone can deploy contracts. These Contracts can access information in L1 through precompiled code.

It should be noted that the block generation speed of Hyperliquid L1 is greater than that of the HyperEVM chain, but these blocks will still be executed in order. Contracts on the EVM chain can read data in past L1 blocks and write data to future L1 blocks. As shown below:

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

Precompiles

The so-called precompiles (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 underlying layer, and to move calculation processes that are unfriendly to Solidity and are more troublesome to regular smart contracts. For external processing, this type of precompiled code can be implemented in C, C++ and other languages ​​that are closer to the underlying device than Solidity.

The pre-compiled method allows EVM to support more advanced and complex functions to easily support the needs of smart contract developers. In form, 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 the instruction is located at the 0x01 address.

It is currently a mainstream practice to use precompilation to add some special functions. 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)

In line with this current mainstream solution, HyperEVM has also added a series of precompiled codes to enable EVM to read the status of the Hyperliquid order book system. A currently known Hyperliquid precompiled code address is 0x000000000000000000000000000000000000800. This precompiled address can read the user's perpetual contract position in the latest L1 block.

Events

We mentioned above that HyperEVM can write data to the HyperL1 block, 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 (such as front-end applications or listeners) during execution, so that the outside world can monitor the running status of smart contracts.

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

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

Known information indicates that HyperLiquid nodes will listen

0x333333333333333333333333333333333333 (event address) Events, know the user's intention based on the information included by Events, and transform the intention into a transaction action according to 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 the 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 a pending order operation in Hyper L1.

HyperBFT

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

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

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

The figure below shows the message delivery method of HyperBFT consensus in a non-parallel situation. It can be seen that all messages are summarized and broadcast uniformly by the Leader, which eliminates the step of exchanging messages between nodes and greatly reduces the complexity.

To put it simply, HyperBFT is a consensus protocol in which the current leader produces a block, all nodes participate in voting and the voting results are uniformly sent to the leader, and then the next leader is rotated. In fact, the specific details involved in Hotstuff and Tendermint are much more complicated. This article is limited by the length and focus and will not go into details here.

Points to note for developers

The above-mentioned data reading mechanism based on Precompiles is relatively perfect. Solidity developers do not need to write corresponding code when reading the Hyper L1 status, but they need to pay attention to the problem of msg.sender. Similar to most Ethereum second layers, HyperLiquid also allows users to directly interact 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 It was found that msg.sender corresponds to the address of the HyperL1 system contract, not the address of the user 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 the interaction. If the user indirectly places an order in L1 through the aforementioned event address on HyperEVM, but there are not sufficient assets in L1, then the transaction will definitely fail, but the user calls the event address. There will be no error return prompt when the function is used. Problems with the non-atomicity of interactions can cause the user's assets to be compromised. At this time, developers need to manually handle the failure of pending orders on the EVM smart contract side. Moreover, the smart contract in the EVM should have a function for final fund recovery to prevent user assets from never being withdrawn in L1.

Secondly, the contract address corresponding to EVM must have a mapping account in L1. After the user deploys the smart contract in EVM, he needs to transfer a small amount of USDC to the mapping address in L1, forcing L1 to create an account for the contract address. This part of the operation may be related to HyperLiquid's underlying consensus, which is clearly required in Hyperliquid's documentation.

Finally, developers need to pay attention to some special situations, especially the balance of tokens. Hyper L1 has a special address for asset transfer, but when users send assets to this special address, the assets will be transferred from L1 to the HyperEVM chain. Since the HyperLiquid node actually executes the EVM chain and the L1 chain at the same time, it may be that HyperEVM has not produced a block for a long time after the user transfers the assets. At this time, the user cannot read his or her balance on the EVM chain.

To put it simply, the user assets at this time are stuck in the cross-chain bridge and cannot be queried in either the L1 or the EVM chain. The protocol built by the developer should handle the above special situations to avoid users from panic.

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 within HyperEVM or conduct cross-chain assets. But unlike the general Layer1-Layer2 architecture, Hyperliquid provides higher interoperability for HyperEVM.

References

Hyperliquid: The Hyperoptimized Order Book L1

hyperliquid-dex/contracts

The Not-So-Definitive guide to Hyperliquid Precompiles.

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