CEX、Hyperliquid 与 Ethereum：从钱包签名到区块链架构

本文整理以下主题：

Hyperliquid DEX 是什么
钱包登录时的签名和授权弹窗
钱包、智能合约和区块链的关系
Hyperliquid L1、HyperEVM 与外部链的关系
Hyperliquid 的充值、交易、撮合和提现流程
Hyperliquid 的去中心化程度与信任边界
Ethereum 智能合约、节点、状态和存储
Layer 2 与混合架构的区别

1. CEX、DEX 与 Hyperliquid

CEX

CEX（Centralized Exchange，中心化交易所）由一个平台运营方维护账户账本、订单簿、撮合系统和提现系统。

典型流程是：

用户充值
   ↓
平台后台数据库增加余额
   ↓
平台内部撮合交易
   ↓
平台后台修改账户余额和仓位
   ↓
提现由平台控制

用户通常不直接控制交易所内部账户的私钥，而是相信平台会正确记录余额、撮合订单并处理提现。

DEX

DEX（Decentralized Exchange，去中心化交易所）通常让用户使用自己的钱包，并通过区块链协议或智能合约完成交易。

典型的链上 DEX 流程是：

钱包签名交易
   ↓
调用智能合约
   ↓
区块链节点执行合约
   ↓
交易写入区块
   ↓
余额和资产状态更新

Hyperliquid 的体验接近 CEX 的高性能订单簿，但它的核心交易状态由自己的 Hyperliquid L1 维护，因此通常被称为 DEX 或链上交易平台。

可以粗略理解为：

Hyperliquid 类似“链上的高性能合约交易所”，但它不是简单地把每笔订单都作为 Ethereum 上的 Solidity 合约调用。

2. Hyperliquid 是什么

Hyperliquid 主要用于：

加密资产永续合约交易
现货交易
杠杆交易
订单簿交易
保证金管理
清算

它的核心系统包括：

Hyperliquid L1：负责核心交易、订单簿、撮合、仓位、保证金和清算。
HyperEVM：EVM 兼容环境，用于部署和运行 Solidity 智能合约。
外部链与桥：用于充值、提现和跨链资产转移。
前端与 API：负责用户界面、请求传输、行情展示和数据查询。

3. 钱包登录和授权弹窗

钱包弹窗不能只看中文标题中的“授权”二字，需要查看具体动作。

3.1 登录消息签名

常见显示：

Sign message
Sign in
Login
Signature request
Sign-in with Ethereum

弹窗可能包含：

Sign in to Hyperliquid
URI: https://...
Wallet: 0x...
Nonce: ...
Issued At: ...

这通常表示：

钱包用私钥签署一段消息
   ↓
网站验证签名是否对应该钱包地址
   ↓
网站确认用户控制该钱包

通常具有以下特征：

不需要 Gas
不会直接转移资产
通常不调用智能合约
通常不会写入区块链
不会改变钱包余额

它类似于“用钱包签字登录”，而不是给网站转账。

3.2 `Approve` 代币授权

常见字段：

Token: USDC
Spender: 0x...
Amount: Unlimited

或中文：

授权代币：USDC
授权对象：某个合约地址
授权额度：无限

它通常调用 ERC-20 代币合约的：

approve(spender, amount)

含义是允许某个地址或合约在额度范围内使用你的代币。之后被授权方可能调用：

transferFrom(...)

把代币从你的地址转走。

Approve 通常是一笔链上交易，会：

调用智能合约
消耗 Gas
写入区块链
改变代币合约中的授权状态

3.3 `Permit` / `Permit2`

常见关键词：

Permit
Permit2
Token allowance
Signature transfer
离线授权

Permit 通常是先签署一份代币使用许可，签名本身可能不立即上链，之后由某笔交易把签名带给合约执行。

可以理解为：

Permit：签署一张授权单
Approve：直接把授权登记到链上

Permit 没有 Gas 不代表没有风险。如果弹窗显示了代币、额度、有效期或授权合约，应当按资产授权来审查，而不是当成普通登录。

3.4 转账或发送交易

常见字段：

From: 你的地址
To: 某个地址
Amount: 100 USDC
Network fee: ...

出现以下内容时，通常是真实的资产交易：

Send
Transfer
To
收款地址
Amount
Gas fee
Network fee

登录时一般不应该要求向某个地址发送资产。

3.5 合约交互

钱包可能显示：

Contract interaction
与合约交互
调用智能合约

需要进一步展开查看：

合约地址
函数名称
代币数量
Gas 费用
是否包含授权或转账

4. 钱包、智能合约和区块链的关系

可以分成三层：

1. 钱包：使用私钥签名，证明用户同意某个操作。

2. 智能合约：按照预先写好的代码执行规则。

3. 区块链：由节点验证并记录交易和状态变化。

登录签名

钱包签名
   ↓
网站验证
   ↓
登录成功

通常是链下行为，不产生区块链状态变化。

`Approve`

钱包签名授权交易
   ↓
调用代币合约 approve()
   ↓
区块链执行
   ↓
授权额度写入代币合约状态

转账

钱包签名转账交易
   ↓
节点验证余额、nonce 和签名
   ↓
执行转账
   ↓
区块确认余额变化

合约调用

钱包签名
   ↓
调用合约函数
   ↓
EVM 执行合约代码
   ↓
更新合约存储和账户状态

5. Hyperliquid 使用哪些区块链

Hyperliquid L1

Hyperliquid L1 是 Hyperliquid 的专用交易链，主要负责：

永续合约交易
现货交易
订单簿
撮合
账户余额
仓位
保证金
资金费率
清算

它不是一个普通的 Ethereum Solidity 合约集合，而是为高性能交易设计的专用 L1。

HyperEVM

HyperEVM 是 Hyperliquid 生态中的 EVM 兼容网络，主要用于：

Solidity 智能合约
ERC-20 代币
DEX
借贷
质押
NFT
DeFi 应用

在 HyperEVM 上通常会看到：

合约地址
approve
transfer
swap
deposit
withdraw
Contract interaction
Gas fee

外部链

充值、提现或跨链时可能涉及：

Arbitrum
Ethereum
其他官方支持的网络

具体支持网络和桥接方式应以 Hyperliquid 当前官方页面为准。

关系总结

Hyperliquid L1 = 核心交易系统
HyperEVM       = 运行传统智能合约的应用平台
外部链         = 充值、提现和跨链资产来源

6. Hyperliquid 的完整交易流程

6.1 登录

网站生成登录消息
   ↓
钱包用私钥签名
   ↓
网站验证签名
   ↓
识别钱包地址并登录

通常不转账、不支付 Gas，也不写入区块链。

6.2 充值

概念流程：

用户选择充值网络和资产
   ↓
从外部链发送 USDC 等资产
   ↓
外部链交易确认
   ↓
桥或充值系统检测存款
   ↓
Hyperliquid L1 给对应账户增加余额

外部链上可能发生：

代币转账
Approve
充值合约调用
桥接合约交互
产生外部链 Gas

Hyperliquid L1 上可能发生：

账户余额增加
充值状态记录
跨链处理状态更新

L1 上的账户余额和外部链上的真实 USDC 是不同网络中的状态，需要通过充值和提现机制保持对应关系。

6.3 下单

用户输入交易参数
   ↓
签署订单请求
   ↓
请求发送到 Hyperliquid API 或节点
   ↓
Hyperliquid L1 处理
   ↓
订单进入订单簿

下单不一定是传统 EVM 交易。通常不会像 Ethereum 或 HyperEVM 合约调用那样弹出 Gas 支付窗口。

订单被接受后，订单状态会成为 Hyperliquid 交易系统的协议状态，例如：

已挂单
已成交
部分成交
已撤销

6.4 撮合

当买方价格不低于卖方价格时，订单可以成交。系统计算：

成交价格
成交数量
手续费
保证金变化
平均持仓价格
未实现盈亏
强平价格
资金费率影响

6.5 撤单

用户发起撤单
   ↓
签署撤单请求
   ↓
发送到 Hyperliquid
   ↓
L1 确认撤单
   ↓
订单从订单簿移除

未成交订单撤单通常：

不产生成交手续费
不需要 Ethereum、Arbitrum 或 HyperEVM Gas
会改变 Hyperliquid L1 的订单簿状态

如果订单已经部分成交，则已成交部分会产生交易手续费。

6.6 持仓和清算

成交后，Hyperliquid L1 维护：

仓位方向
仓位数量
开仓均价
保证金
未实现盈亏
维持保证金要求
强平价格

当账户权益低于维持保证金要求时，可能触发清算：

账户权益下降
   ↓
低于维持保证金
   ↓
触发强平
   ↓
减少或关闭仓位
   ↓
更新账户状态

6.7 提现

用户选择提现网络和资产
   ↓
输入目标地址和数量
   ↓
签署提现请求
   ↓
Hyperliquid 检查余额和风险
   ↓
Hyperliquid L1 扣除账户余额
   ↓
桥或提现系统处理
   ↓
外部链向目标地址发送资产

L1 上的账户余额减少，外部链上最终出现真实资产转账。提现可能涉及等待时间、提现费、外部链 Gas 和桥接风险。

7. 撮合到底是不是在链上

最准确的说法是：

Hyperliquid 的撮合由专用交易引擎执行，并由 Hyperliquid L1 的共识确认；它不是完全依赖中心化后台，也不是传统 EVM DEX 的逐笔 Solidity 合约撮合。

下单请求阶段

网页或客户端
   ↓
签名订单请求
   ↓
API 或节点接收

这部分是网络请求，订单还可能被拒绝、过期或尚未确认。

撮合执行阶段

订单进入交易系统
   ↓
订单簿匹配
   ↓
计算成交数量和价格
   ↓
更新余额、仓位和保证金

这些计算由验证者节点本地执行，并由网络确认结果。

区块确认阶段

订单被接受或成交后，最终状态会反映在 Hyperliquid L1 的区块和协议状态中。

因此：

下单请求传输：可能是链下通信
撮合本地计算：在验证者节点执行
撮合结果确认：由 Hyperliquid L1 共识确认
余额、仓位和成交结果：成为 L1 协议状态

8. 撮合中间过程是否公开，源代码是否公开

需要区分：

1. 撮合输入是否公开

2. 撮合结果是否公开

3. 撮合引擎源代码是否公开

公开的内容

通常可以查询：

订单状态
成交价格和数量
成交记录
撤单记录
账户余额变化
仓位变化
手续费
清算结果
区块和交易动作

不一定逐步公开的内容

区块链不会通常记录：

比较订单 1
比较订单 2
移动订单指针
计算成交数量
扣除手续费
更新某个内存结构

这些是验证者本地执行的中间步骤。公开的主要是输入、最终结果和状态承诺。

核心源代码的公开程度

不能把 Hyperliquid 核心撮合引擎理解成像 Uniswap 智能合约一样，完整源代码公开并可以在区块浏览器中逐行审计。

公开可见的内容包括 API、协议接口、交易数据和账户状态，但核心节点软件、订单簿实现、撮合引擎以及部分共识执行逻辑的完整公开程度不同于 Ethereum 的公开 EVM 客户端和智能合约生态。

因此用户可以验证很多输入和输出，但仍需要信任：

核心交易引擎实现
验证者软件
验证者网络
运营方和协议升级机制

9. Hyperliquid 的去中心化程度

Hyperliquid 可以称为去中心化交易所，但“去中心化”不是全有或全无。

去中心化的部分

有多个验证者参与共识
交易状态由 L1 网络维护
区块和部分交易状态可公开验证
用户通常用自己的钱包签名
不是单个公司数据库直接维护全部交易状态

更集中的部分

验证者集合和准入可能比 Ethereum 更集中
核心交易系统由专用协议实现
核心撮合代码的公开程度不等同于完全开源智能合约
前端和 API 可能是中心化服务
充值提现依赖桥和运营流程
协议升级可能更依赖核心团队和验证者

Hyperliquid 的定位更接近：

有公开区块链状态和多验证者共识的高性能专用交易链，但不是完全开放、完全无需信任的 Ethereum 级通用公链。

10. 虚假充值和“凭空记账”的风险

Hyperliquid L1 上的账户余额和外部链上的真实 USDC 是两个概念：

L1 账户余额：协议账本里的数字
外部链 USDC：真实存在于外部链地址或桥合约里的资产

理论上，如果充值验证机制或 L1 状态处理被恶意控制，可能出现：

Hyperliquid L1：账户 +1,000,000 USDC
外部链储备：没有对应的 1,000,000 USDC

但虚假余额无法自动变成外部链上的真实 USDC。提现时必须面对真实储备：

内部账本显示有余额
   ↓
用户申请提现
   ↓
外部链无法足额支付
   ↓
暴露偿付能力或桥流动性问题

因此需要信任的对象包括：

Hyperliquid L1 验证者和共识机制
充值和提现逻辑
跨链桥
外部链资产储备
运营方和相关私钥

用户可以检查：

官方充值和桥地址
外部链上的充值交易
外部链上的提现到账交易
桥合约资产余额
充值数量与 L1 入账数量是否一致

11. EVM 是什么

EVM 是 Ethereum Virtual Machine，即以太坊虚拟机。

它不是一条区块链，而是一套运行智能合约的标准化虚拟计算环境：

EVM = 运行智能合约的标准化虚拟电脑

开发者使用 Solidity 等语言编写合约，编译成 EVM 字节码后部署。Ethereum、Arbitrum、Optimism、Base、BNB Chain 和 HyperEVM 都支持 EVM 或兼容 EVM。

EVM 可以运行：

ERC-20 代币
DEX
借贷协议
NFT
质押协议
DAO
跨链桥
链游

12. HyperEVM 的用途

HyperEVM 是 Hyperliquid 生态中的 EVM 兼容执行环境，用于运行传统 Solidity 智能合约。

在 HyperEVM 上，开发者可以部署：

ERC-20 代币
DEX
借贷协议
质押协议
NFT
收益策略
其他 DeFi 应用

典型流程是：

MetaMask 或 Rabby 连接 HyperEVM
   ↓
调用 Solidity 合约
   ↓
签署交易
   ↓
支付 HyperEVM Gas
   ↓
交易写入 HyperEVM 区块

Hyperliquid L1 与 HyperEVM

Hyperliquid L1 = 核心订单簿、撮合、仓位和清算
HyperEVM       = 运行 Solidity 智能合约和 DeFi 应用

在 Hyperliquid 核心交易页面下单，通常不是调用 HyperEVM 上的普通 Solidity 合约；在 HyperEVM DeFi 应用中进行 approve、swap 或借贷，则是标准 EVM 合约交互。

13. Ethereum 智能合约如何保存在区块链上

部署合约时，Solidity 源代码会先编译成 EVM 字节码：

Solidity 源代码
   ↓ 编译
EVM 字节码
   ↓ 部署交易
合约地址和运行时代码进入 Ethereum 状态

链上真正执行的是字节码，不是 Solidity 源代码。区块浏览器显示的 Solidity 源码通常是项目方额外提交并经过字节码匹配验证的版本。

合约状态包括：

合约字节码
合约存储变量
代币余额映射
授权额度
DeFi 仓位
管理员地址

14. 每个节点是否都有一份数据库备份

可以粗略这样理解，但更准确的说法是：

多个节点根据相同区块和规则，独立维护或验证相同的 Ethereum 状态副本。

这不是单个数据库复制出来的备份，而是多个节点独立执行：

相同的旧状态
   +
相同的区块交易
   ↓
相同的 EVM 执行
   ↓
相同的新状态

如果某个节点私自修改本地合约代码，执行结果可能与其他节点不同，最终状态根不一致，其他节点会拒绝错误结果。

但不是每种节点都保存完全相同的数据：

普通全节点可能修剪旧状态
归档节点保存更多历史状态
轻节点只保存较少的区块头和证明数据

15. Ethereum 的节点类型和存储内容

15.1 普通执行层全节点

保存或能够访问：

执行层区块
交易
交易回执
日志
当前账户状态
当前合约代码
当前合约存储

通常不保存每个历史区块对应的完整状态。

15.2 完整 Ethereum 节点

通常由：

执行层客户端 + 共识层客户端

组成。

执行层负责：

交易
EVM
智能合约
账户和合约状态

共识层负责：

PoS 共识
验证者
Attestation
区块提议
分叉选择
最终确定性
奖励和惩罚

15.3 归档节点

归档节点还保存历史状态，例如：

某个历史区块时的 ETH 余额
某个历史区块时的 ERC-20 余额
某个历史区块时的合约存储变量
某个历史区块时的 DeFi 仓位

15.4 高级归档节点

“高级归档节点”不是严格的 Ethereum 协议分类，通常指在归档节点基础上还提供：

内部交易
调用树
调试追踪
自建索引
地址和代币历史
交易资金流向
大量查询接口

这类服务常用于区块浏览器、数据分析平台、审计工具和 DeFi 研究。

节点对比

|---|---:|---:|---:|---:|---|

| 执行层全节点 | 有 | 部分修剪 | 有 | 无 | 执行交易和验证执行层 |

| 完整节点 | 有 | 部分修剪 | 有 | 有 | 参与完整网络验证 |

| 归档节点 | 有 | 基本完整 | 有 | 通常有 | 历史查询和审计 |

| 高级归档节点 | 有 | 完整或更丰富 | 有 | 有 | 区块浏览器和数据分析 |

验证者节点不一定是归档节点。验证者主要需要正确参与当前共识，不一定需要保存所有历史状态。

16. Ethereum 如何知道当前状态

每个区块的交易都会把旧状态转换为新状态：

旧状态 + 本区块交易
   ↓
执行 EVM
   ↓
新状态

区块中包含状态根 stateRoot，它承诺执行该区块之后的全局状态。

节点不一定从创世区块逐个执行到最新区块。实践中可以使用：

状态快照
Snap sync
快速同步
同步检查点

先获得较新的状态，再从较近的区块开始验证。

节点需要执行新收到区块中的交易，但不需要每个新区块都重新执行全部历史交易。

智能合约也不是持续运行的程序。只有被交易调用时才执行：

合约部署但无人调用：不持续运行
收到调用交易：EVM 执行对应字节码

17. 区块链存储增长和不可删除性

区块链的历史数据会持续增长，包括：

区块头
交易
交易回执
日志
状态变化

已部署的合约通常不能像服务器文件一样随意删除，因为：

历史部署交易不能消失
其他合约可能引用该地址
删除会破坏状态一致性
不同节点需要对历史达成一致

现代 Ethereum 也不能简单依赖 selfdestruct 删除任意已部署合约。即使某些当前状态数据被清理，过去的交易和区块历史仍然存在。

普通节点可以修剪旧状态，归档节点通常保存更多甚至全部历史状态。

18. 把 5 GB 电影放到区块链上

技术上可以把文件拆成大量交易或存储槽，但实践上几乎不可行。

写入 calldata 的粗略估算

5 GB 约等于：

5,000,000,000 字节

Ethereum 交易数据大致按：

非零字节：16 Gas
零字节：4 Gas

压缩电影可以粗略按非零数据估算：

5,000,000,000 × 16
≈ 80,000,000,000 Gas

即约 800 亿 Gas，不包括交易本身和拆分开销。

粗略成本：

| Gas 价格 | 约需 ETH |

|---:|---:|

| 1 gwei | 80 ETH |

| 10 gwei | 800 ETH |

| 30 gwei | 2,400 ETH |

| 100 gwei | 8,000 ETH |

成本公式：

总成本 = Gas 数量 × Gas 价格(gwei) × 10^-9 × ETH 价格

写入合约存储

5 GB 大约需要：

5,000,000,000 ÷ 32
≈ 156,250,000 个 32 字节存储槽

如果首次写入每个槽位粗略按 20,000 Gas：

156,250,000 × 20,000
≈ 3,125,000,000,000 Gas

也就是约 3.125 万亿 Gas，通常比 calldata 方案更昂贵。

此外还会受到：

单笔交易大小限制
区块 Gas 上限
区块传播压力
节点存储压力

的限制。

实际方案通常是：

电影文件：对象存储、IPFS 或 Arweave
区块链：保存哈希、CID、所有权和时间戳

区块链更适合证明某个文件在某个时间点对应某个哈希，而不是直接承担 5 GB 文件存储。

19. Ethereum 区块数据增长速度

Ethereum 每十几秒产生一个区块，因此每年会产生数千万个区块。实际存储增长取决于：

区块使用率
交易数量
交易数据大小
日志数量
智能合约状态写入量
客户端数据库和索引

粗略理解：

区块、交易、回执和日志等历史数据：每年可能增加数百 GB
普通全节点：通常需要 TB 级 SSD，并持续增长
归档节点：可能达到十几 TB 或更多

EIP-4844 的 blob 数据需要单独看。Blob 主要用于 Layer 2 数据提交，成本较低，但通常不是永久保存在所有节点的普通状态中，旧 blob 可以在一段时间后被修剪。因此不能把 blob 增长量简单等同于永久区块存储增长。

20. 混合架构不等于 Layer 2

这是两个不同层级的概念。

混合架构

混合架构是一个大类别，意思是：

部分功能放在区块链上
部分功能放在链下服务器、数据库或存储系统上

例如：

视频：对象存储
推荐系统：传统服务器
用户资料：数据库
资产所有权：智能合约
支付结算：区块链

这不需要使用 L2。

Layer 2

Layer 2 是建立在某条主链之上的特定扩展网络：

用户交易
   ↓
L2 快速执行
   ↓
批量提交数据、状态承诺或证明
   ↓
Ethereum L1 最终验证或结算

因此：

所有 L2 都可以看作某种混合架构，但不是所有混合架构都是 L2。

侧链和专用应用链

侧链通常有自己的验证者和共识，不一定继承 Ethereum 的安全性。

Hyperliquid L1 是专用应用链，不是 Ethereum L2。它有自己的：

区块
验证者
共识
交易状态
撮合逻辑

Hyperliquid 的整体系统可以是混合架构，但 Hyperliquid L1 本身不是 Ethereum Layer 2。

21. Layer 2 是什么

Layer 2（L2）是在 Ethereum 等主链之上运行的扩展网络，目标是：

提高吞吐量
降低费用
承载更多交易
尽量继承主链安全性

Optimistic Rollup

代表项目包括 Arbitrum、Optimism 和 Base。

基本逻辑是：

L2 执行交易
   ↓
提交状态结果到 Ethereum
   ↓
在挑战期内允许提出错误证明
   ↓
没有有效挑战后确认

ZK Rollup