Author: Shew, Xianyang GodRealmX

Hyperliquid 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 included Layer 3 and application chains that have faded out of the public eye. Narratives are thrust back into 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 structure of this star project. principle. 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)< /p>

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.

Verifier set

From the perspective of node identity division, Hyperliquid has 4 groups Validators, respectively hotValidatorSet, coldValidatorSet>And 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.

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

And lockers is a group of verifiers with special permissions, similar to the "security committee" used by Layer2, which will be used in some emergencies. In the event of a problem, a vote is used to decide whether to suspend the operation of the cross-chain bridge. Currently, the lockers set of the Hyperliquid bridge contains 5 addresses, and only 2 locker votes are needed to suspend the operation of the bridge contract.

As for finalizers, they are actually a special group of verifiers , mainly used to confirm the status changes of the cross-chain bridge. From the contract level, the main confirmation is 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 ends, members within finalizers execute the withdrawal transaction, and then the withdrawal can be executed normally.

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

Currently Hyperliquid only has 4validator 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 Hyperliquid officially controls it itself and uses cold wallets to store keys.

Deposit

Hyperliquid's bridge contract is based on the Permit method of EIP-2612 to handle the user's Deposit operation, 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 and there is no fund security. Risk, the processing process is very simple, only using the Permit method to optimize the UX.

Withdrawal is a highly dangerous operation compared to deposit, so the logic of withdrawal will be much more complicated than that of deposit. 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 upper bridge contract checks the "signature weight of 2/3". 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 fraud proof protocol. "Challenge Period". The current dispute period for the Hyperliquid bridge contract is 200 seconds, two situations may occur during the dispute period:

1.lockers believes that there are serious problems with the current withdrawal request, At this time, you can directly vote to suspend/freeze the contract;

2. The node believes that there is a problem with some withdrawal behaviors. At this time, coldValidatorSet members Can be called The invalidateWithdrawals function invalidates the withdrawal.

If no problems occur during the dispute period, after the dispute period ends, members within finalizers can call in the bridge contract The >batchedFinalizeWithdrawals function is used 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 use Hyperliquid To manipulate the withdrawal process, you need to break through three lines of defense:

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

2. During the dispute period, the attacker should avoid the discovery of his malicious transactions. Once discovered, it is very likely to cause < code>lockers locks the contract. We will discuss this part specifically below.

3. Obtain the private key of at least one finalizers member so that your withdrawal behavior can be 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 mentioned many times before that Hyperliquid has set up a function to lock cross-chain bridge contracts. Specifically, locking the cross-chain bridge requires lockers members to call the voteEmergencyLock function in the cross-chain bridge contract to vote. Currently, when 2 lockers call After this function gives a vote, the cross-chain bridge contract will be locked and suspended.

But it should be noted that HyperLiquid's cross-chain bridge also provides the unvoteEmergencyLock function, allowing lockers members to withdraw vote. Once the cross-chain bridge contract is successfully locked, it can only be unlocked through a function named emergencyUnlock, which requires collecting more than 2/3 of the signature weights of coldValidatorSet members.

emergencyUnlock function will also input new hotValidatorSet and coldValidatorSet while unlocking A collection of validator addresses, and will be updated immediately.

Verifier set update Compared with 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 provide the signatures of 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 lockers and finalizers, both updates require hotValidatorSet signature, and removing a member requires coldValidatorSet Signature.

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

1. Hackers control coldValidatorSet can steal user assets regardless of any obstruction. Because coldValidatorSet has the operating authority of the emergencyUnlock function, it can invalidate the locking action of lockers 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 private keys being stolen is not low;

2.finalizersRejected Finalize the user's withdrawal transaction and launch a censorship attack; 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 determines 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 private transactions and other scenarios that require smart contracts to be implemented, Hyperliquid has launched a solution called HyperEVM. It has two special advantages compared to traditional EVM: First, HyperEVM can read the order book status of HyperLiquid, 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 the pending order operation, at this time, he can use something like Tornado Cash on HyperEVM.The smart contract is covered with a layer of privacy, and then the pending order action is triggered 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), this chain is permissioned; and the chain used for HyperEVM is HyperEVM (EVM), this chain is permissionless, and any Anyone can deploy contracts, and 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 Precompiles and Events are two technical means.

Precompiles

The so-called precompiles (Precompiles), to put it bluntly, is to compile some files in the intelligent The operations that are difficult to implement and have high complexity in the contract are directly moved to the bottom layer, and the calculation process that is not friendly to Solidity and is more troublesome is moved to outside the conventional smart contract for processing. This kind of precompiled code can be used in C, C++, etc. Closer to the bottom of the device than Soliditylanguage to achieve.

The pre-compilation method allows EVM to support more advanced and complex functions to facilitate 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 0x01 code> within the address.

Using precompilation to add some special functions is currently a mainstream practice. For example, Base has added P256 precompiled code to facilitate users. WebAuth identity authentication operation.

(This picture comes from the Rollup Codes website)

Consistent with this current mainstream solution, HyperEVM has also added a series of precompiled codes to enable EVM to read the Hyperliquid order book system status. A currently known Hyperliquid precompiled code address is 0x00000000000000000000000000000000000800. 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 an ERC-20 contract, the contract will throw an Event corresponding to Transfer so that front-end applications such as block browsers can learn about 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.

Many cross-chain related scenarios now use Events to pass cross-chain parameters. For example, if Arbitrum is deployed in the bridge contract on the Ethereum mainnet, users can call relevant functions to throw events to trigger transactions on Arbitrum.

Known information shows that HyperLiquid nodes will listen

0x3333333333333333333333333333333333 (things address), the opvents thrown by the information contained in Events, and transform the intention into transaction actions according to this, write the future HyperLiQUID In L1 block.

For example, the above event address will provide a function. When the user calls this function, the event address will throw an object named IocOrder Event. 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 an event in Hyper L1. Pending order operation.

HyperBFT

At the consensus protocol level, Hyperliquid adopts a protocol called HyperBFT, which It 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 less efficient and each stage All-to-All message exchange is required. Each node has to send messages to all other nodes. 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 based on HotStuffHyperBFT algorithm, implemented in Rust, can theoretically process up to 2 million orders per second.

The following figure 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, eliminating the need for It eliminates the steps of exchanging messages between nodes, greatly reducing the complexity.

Simply put, HyperBFT means that the current leader produces blocks, and all nodes participate in voting and A consensus protocol that uniformly sends the voting results to the Leader and then allows the next leader to rotate. 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 that developers need to pay attention to

The above data reading based on Precompiles The mechanism 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 msg.sender in the transaction field, you will find 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, EVM corresponds toThe contract address 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 developers built The protocol should handle the above special situations 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 communicate with Hyper L1 generate interaction. 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.

Reference materials

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?