术语表

整理自 Michele Stefanelli 著《Due Diligence of a Layer 2 – The Bitcoin Hyper Case》附录 A。共 33 条术语,分为 12 类。

33 条术语

Anchoring

结算

指把 rollup 的状态承诺定期发布到比特币基础层(L1)。锚定会记录状态承诺,并使事后改动可被发现;但仅凭锚定并不能保证状态正确、数据可用或跨链桥安全。

第 11–12 章

OP_RETURN

Bitcoin L1

比特币脚本中的一个操作码(opcode),允许在交易里嵌入至多 80 字节的任意数据,并可证明由此产生的 output 不可花费。可用于状态承诺的锚定。

第 12 章

Taproot

Bitcoin L1

比特币的一次升级(BIP 341/342,于 2021 年 11 月激活),引入了 Schnorr 签名与 MAST。它提升了隐私性、效率与脚本的灵活性,也关系到更高效的锚定机制。

第 12 章

UTXO

Bitcoin L1

Unspent Transaction Output,即未花费交易输出。这是比特币的记账模型:没有“账户”,只有对应确定金额的“未花费输出”。它不同于 SVM 与以太坊所采用的账户模型。

第 1 章

Rollup

Layer 2

一类 Layer 2 方案:交易在链下执行,并定期把压缩后的状态发布到基础层(L1)。它把链下的可扩展性,与按所采用模型从 L1 继承而来的安全性结合起来。

第 4–6 章

Sidechain

Layer 2

一条独立的区块链,通过跨链桥与 L1 相连。它的安全性首先取决于自身的共识机制与桥的搭建方式,而不是直接来自 L1 的安全性。

第 4 章

Validium

Layer 2

与 rollup 相近的一种架构,区别在于重建状态所需的数据保存在 L1 之外。这可以降低成本、提升吞吐,但也引入了关于数据可用性的额外假设:一旦数据无法获取,用户可能既无法验证状态,也无法取回资金。

第 14 章

Optimistic Rollup

Layer 2

这类 rollup 默认状态转换是正确的——“optimistic(乐观)”之名即由此而来。它依靠欺诈证明(fraud proof),允许在设定的时间窗口内对错误的状态转换提出质疑——在以太坊上通常为七天。

第 6 章

ZK Rollup

Layer 2

这类 rollup 使用有效性证明——通常基于零知识密码学——来证明状态转换符合协议规则。相比 Optimistic Rollup,它可以缩短确认时间,不过实际的最终性同样取决于 L1 与系统本身的构造。

第 6 章

SVM (Solana Virtual Machine)

执行

由 Solana Labs 开发的运行环境(runtime)。它要求每笔交易显式声明所使用的账户,从而支持交易并行执行。据项目方说明,Bitcoin Hyper 以其作为执行环境。

第 7–8 章

Sealevel

执行

SVM 内部的并行处理引擎。它分析每笔交易所声明的账户,让互不重叠的交易得以并行执行。它是决定 Solana 吞吐能力的组件之一,据项目方说明,也是 Bitcoin Hyper 规划架构的一部分。

第 8 章

Anchor

执行

用于开发 SVM 程序的 Rust 框架。它提供宏、约定与测试工具,简化了 Solana 上的开发流程。据项目方说明,Bitcoin Hyper 将提供同等的工具链;实际兼容程度仍有待核实。

第 9 章

SPL (Solana Program Library)

执行

SVM 的标准程序库:代币(SPL Token)、质押、治理等。据项目方说明,Bitcoin Hyper 力求与 SPL 兼容,从而可以复用 Solana 上的代币与程序。

第 9 章

Sequencer

排序

rollup 中负责在执行前排定交易顺序的组件。排序器的运营方可以决定这一顺序,从而影响 MEV 与审查风险。Bitcoin Hyper 上线时,该组件为中心化运行。

第 15–17 章

MEV (Maximal Extractable Value)

排序

指通过重排、插入或剔除某个区块或批次中的交易而可获取的价值。中心化排序器在攫取或影响 rollup 的 MEV 方面,可能有相当大的操作空间。

第 15 章

Forced Inclusion

排序

一种机制,允许用户绕过实施审查的排序器,通过比特币 L1 强行让某笔交易被纳入。截至 2026 年 4 月 28 日,该功能在 Bitcoin Hyper 中仍在开发。

第 21 章

Canonical Bridge

跨链桥

Bitcoin Hyper 的官方跨链桥,用于在 L1 与 rollup 之间转移 BTC。上线阶段采用联盟式或中心化托管,并因此带来相应的信任假设。路线图称将逐步去中心化,这一点仍有待核实。

第 31、34 章

Forced Exit

跨链桥

一种机制,允许用户在排序器或跨链桥不配合的情况下,仍能通过比特币 L1 把资金从 rollup 中取回。这是一项关键的安全功能,目前仍在开发中。

第 21 章

Data Availability (DA)

数据可用性

指所有交易数据都能被公开获取的保证。没有这些数据,任何人都无法重建 rollup 的状态。就 Bitcoin Hyper 而言,最终方案仍在评估中。

第 14 章

State Commitment

结算

对 rollup 某一时刻完整状态的压缩表示,通常是一个 Merkle 根。它会被定期发布到比特币上作为锚定;但发布本身并不等同于对状态的完整验证。

第 11 章

Merkle Tree

密码学

一种树形数据结构,每个父节点都是其子节点的哈希值。它可以高效地构造证明(Merkle proof),表明某个元素属于某个集合,而无需公开整个集合。

附录 A

$HYPER

代币经济学

项目文档中作为 Bitcoin Hyper 原生代币提出的代币。公布的总供应量为 210 亿枚。按已公布的文档,它将用于支付、参与质押,并在后续阶段用于治理。公布的分配比例为:国库 25%、开发 30%、市场推广 20%、奖励 15%、上所 10%。

第 30–33 章

Vesting

代币经济学

指代币按时间逐步解锁的机制。按已公布的预售条件,$HYPER 的解锁期为七天。

第 33 章

TGE (Token Generation Event)

代币经济学

指某个代币首次发行并分发的事件。按白皮书说明,安全审计将在 Bitcoin Hyper 的 TGE 之前完成。

第 33 章

TVL (Total Value Locked)

DeFi

指存入某个网络 DeFi 协议中的资产总值。这是一个用于衡量生态被采用程度与市场信任度的指标。

附录 A

AMM (Automated Market Maker)

DeFi

一类 DeFi 协议,用数学公式(通常是 x*y=k)来决定兑换价格,从而不再需要传统的订单簿。

附录 A

Oracle

DeFi

把现实世界的数据(价格、事件等)引入区块链的服务。它对 DeFi 至关重要:借贷、衍生品及许多其他合约,都依赖可靠的外部价格数据。

附录 A

Fraud Proof

安全

一种密码学证明,用于证明某次状态转换是错误的。Optimistic Rollup 用它在质疑窗口期内对造假的状态提出挑战。

第 19 章

Security audit

安全

由独立专家审阅源代码,以发现潜在漏洞。就 Bitcoin Hyper 而言,项目方宣布会在 TGE 之前公布安全审计;截至 2026 年 4 月 28 日,未能证实存在任何针对协议或跨链桥的公开审计报告。

第 34 章

Finality

结算

指按系统的规则与前提假设,一笔交易自此被视为不可逆转的时点。在 Bitcoin Hyper 所描述的架构中,状态承诺发布后会在比特币上累积确认;但仅凭这一点,并不能保证状态有效,也不能保证资金可以取回。

第 13 章

Lightning Network

竞品

建立在比特币之上、基于通道的支付网络。它首先面向快速低成本的支付,并不提供可与虚拟机相比的通用智能合约环境。自 2018 年起投入实际运行。

第 25–26 章

Stacks

竞品

通过 PoX(Proof of Transfer)机制与比特币相连的智能合约网络。它拥有自己的语言 Clarity,并把区块数据记录到比特币上。

第 27 章

Rootstock (RSK)

竞品

比特币的侧链,兼容 EVM,采用合并挖矿。gas 以 RBTC 代币支付——这是一种与 BTC 锚定的资产。自 2018 年起运行。

第 28 章