An In-Depth Technical Analysis of Hyperliquid's Architecture and Potential Issues

A certain on-chain order book exchange that has recently gained significant attention has become one of the most influential projects, with its total locked value of (TVL) surpassing 2 billion USD, being described as "the on-chain version of a well-known centralized exchange." This project has even brought the concepts of Layer 3 and application chains back into the public eye. With a remarkable achievement of reaching a valuation of 30 billion USD within a month of its launch, the project has garnered widespread attention. Numerous research reports have emerged in the market, but most focus on product functions and trading mechanisms, with few delving into its technical structure and security risks.

This article aims to fill this gap by examining the project purely from the perspective of technical structure and security, helping more people understand its structure and principles. We will elaborate on two main aspects: the construction and risks of cross-chain bridge contracts and the dual-chain structure, deeply analyzing the underlying technical architecture and implementation methods.

Cross-Chain Bridge Contract Analysis

The project has deployed a cross-chain bridge contract on a certain Layer2 network to store the USDC assets deposited by users. Some behaviors of the nodes can be observed from the contract.

Validator Set

The project has 4 groups of validators, namely hot validator set, cold validator set, as well as the adjudicator and the staker, corresponding to different functions:

• Hot validators are used to respond to high-frequency user operations such as withdrawals, using hot wallets to respond to user requests at any time.

• The cold validator set is mainly used to modify system configurations, such as changing the validator list, handling the locking status of bridge contracts, and can directly invalidate certain withdrawal requests.

• The locking person is similar to an "Emergency Committee" and can vote to suspend the cross-chain bridge in emergencies. Currently, there are 5 addresses, and only 2 votes are needed to suspend the bridge contract.

• The confirmer mainly verifies the status changes of the cross-chain bridge, such as user deposits and withdrawals.

Deposit

The bridge contract handles user deposits based on the Permit method of EIP-2612, allowing only USDC deposits. It uses a batch deposit function to process multiple deposits, ensuring a simple process with no capital risk.

Withdrawal

Withdrawals are high-risk operations with a complex process:

1. After the user initiates the withdrawal request, they need to gather 2/3 of the signature weight from the hot validators set.

2. There is a "dispute period" of 200 seconds, during which the locked-in person can vote to freeze the contract, and cold validators can invalidate withdrawals.

3. After the dispute period ends, the adjudicator can confirm the final status, and USDC will be transferred to the user's wallet.

Bridge Contract Lock

The lock-in participants can vote to lock the bridge contract. After 2 lock-in participants vote, the contract will be suspended. Lock-in participants can also withdraw their votes. Once the contract is locked, it can only be unlocked by signatures from 2/3 of the cold validators. The validator list will be updated upon unlocking.

Validator Update

The update of the validator requires signatures from all hot validators, with a 200-second dispute period. After the period expires, the finalizer must confirm the completion of the update.

Main Risks

1. Hackers controlling cold validators can ignore obstacles to steal user assets.

2. The decision-maker may refuse to confirm withdrawal transactions and initiate a review attack.

3. Malicious locking of the bridge contract by the locking person, suspending all withdrawals.

Dual-chain Interactive Architecture

To achieve programmability in order book trading, the project has launched a special EVM solution. Its advantages include the ability to read the order book status, allowing smart contracts to interact with the order system and expand application scenarios.

The project adopts a "dual-chain solution", with nodes running two chains simultaneously:

1. Order Book Dedicated Chain: Permissioned, High Performance

2. EVM-compatible chains: permissionless, smart contracts can be deployed, access dedicated chain data through precompiled contracts.

The two chains propagate data through the same consensus protocol, but execute separately. The EVM chain can read past dedicated chain block data and write data to future blocks.

Interactive Mechanism

1. Pre-compilation: Add special contracts to allow EVM to read the state of dedicated chains.

2. Event: EVM contracts can trigger events, and nodes perform corresponding operations on the dedicated chain.

Consensus Protocol

Based on the HotStuff protocol, the HyperBFT protocol can theoretically process 2 million orders per second.

Development Notes

1. msg.sender may be a system contract address

2. Non-atomic interactions may lead to asset loss

3. The EVM contract address needs to be mapped on the dedicated chain.

4. It may not be possible to check the balance temporarily when assets are cross-chain.

In summary, the EVM chain of this project is similar to a dedicated layer two, but offers higher interoperability. Its innovative architecture provides new ideas for the combination of high-performance order books and smart contracts, but also brings some potential risks and development challenges.