A Deep Dive into the Architecture and Potential Issues of Hyperliquid from a Technical Perspective

Hyperliquid, as one of the representatives of on-chain order book exchanges, has surpassed a TVL of 2 billion USD and is referred to as the "on-chain Binance." This article will delve into the architectural principles of Hyperliquid from the perspectives of technical construction and security.

Hyperliquid Cross-Chain Bridge Analysis

Hyperliquid has deployed a cross-chain bridge contract on Arbitrum to store users' USDC assets. The bridge contract includes four groups of validators:

• hotValidatorSet: handles high-frequency operations such as withdrawals
• coldValidatorSet: Modify system configuration to invalidate withdrawal requests
• lockers: can pause the bridge contract operation
• finalizers: Confirm cross-chain bridge status changes

Deposit Process

The Bridge Contract uses the Permit method of EIP-2612 to handle deposits, supporting batch operations. The deposit logic is simple and has lower security risks.

Withdrawal Process

Withdrawal requests must meet the following conditions:

1. Collect 2/3 of the voting weight from hotValidatorSet.
2. After a 200-second dispute period
3. Finally confirmed by members of finalizers

During the dispute period, lockers can suspend the bridge contract, and coldValidatorSet can invalidate withdrawals.

Bridge Contract Locking Mechanism

A total of 2 lockers' votes are required to lock the bridge contract. Unlocking requires 2/3 signature weight from the coldValidatorSet, and it can also update the validator set.

Validator Set Update

Updating the hotValidatorSet and coldValidatorSet requires signatures from all members of the hotValidatorSet, and will be confirmed by the finalizers after a 200-second dispute period.

potential risks

1. Once the coldValidatorSet is compromised, it can bypass security mechanisms to steal assets.
2. Finalizers may refuse to confirm withdrawal transactions.
3. Lockers may maliciously lock bridge contracts.

HyperEVM and Dual-Chain Interaction Architecture

Hyperliquid adopts a dual-chain architecture:

• Hyperliquid L1: Dedicated order book system, permission-based
• HyperEVM: EVM-compatible chain, permissionless

The two chains interact through Precompiles and Events:

• Precompiles: Allow HyperEVM to read L1 state
• Events: Allow HyperEVM to write data to L1

HyperBFT Consensus

Hyperliquid developed the HyperBFT consensus algorithm based on HotStuff, with a theoretical processing capacity of up to 2 million orders per second.

Developer Notes

1. msg.sender may be the address of a system contract.
2. EVM and L1 interaction is non-atomic, failure cases need to be handled.
3. The EVM contract address needs to create a mapped account on L1.
4. Cross-chain assets may be temporarily invisible and need to be handled properly.

Overall, HyperEVM is similar to an L1 layer two architecture but offers higher interoperability. Developers need to pay attention to the technical details brought by its unique dual-chain structure.