什么是Client-Side Validation？定义、背景与来源

01什么是Client-Side Validation？

参与者无需向全球公开全部合约数据，而是在 off-chain 传递所需历史、自行验证规则，并在 Bitcoin 上检查密码学 commitments 与 single-use seals 的关闭。

02核心

每位接收者按具体协议的规则，只验证通向所接收状态的那部分历史。这属于部分复制：其他参与者无需知道或保存合约的整个私有图。 [4]

03机制

所需数据以历史与证明包的形式在 Bitcoin 之外传递。接收者不能只接受当前余额；必须核验状态转换一直追溯到可信起点的连续性，并确认每一步都绑定相应的 on-chain commitment。 [4]

04要解决的问题

Single-use seal 是一种抽象 commitment，只能在选定消息上有效关闭一次。Bitcoin UTXO 可充当这种封条：花费它是公开且由 consensus 排序的关闭证明，而 Bitcoin 不判断私有数据的含义。 [3]

05安全模型

Proof-of-Publication 将紧凑 commitment 锚定到公开交易顺序，使同一封条被用于不相容转换的尝试可被发现。Miner 与 full node 验证的是 Bitcoin 规则，而非 hash 背后隐藏的业务逻辑。 [2]

06部署状态

Client-Side Validation 是通用设计模型，并非 RGB 的同义词。LNP/BP 注册表把 LNPBP-9 列为信息性 draft，相关库提供 commitments、序列化和 single-use seals 接口；具体协议在此之上定义自己的状态与规则。 [5]

07限制

隐私和扩容把保存数据的责任转移给数据所有者。如果发送方未交付完整历史，或接收者遗失任何必要部分，公共 blockchain 无法从 commitment 还原数据，本地验证可能因缺少可证明状态而终止。 [4]

08Atlas 中的关联

公众通常只能看到 Bitcoin 交易和短 commitment，看不到完整合约。这降低了全局数据负担，却不保证匿名：时序、交易对手、数据传递方式和可识别的 anchor 结构都可能形成 metadata。 [1]

09如何核验相关说法

核验时必须知道确切协议、可信 genesis 或 schema、seal 定义、commitment scheme、完整连续历史、Bitcoin 交易状态和软件版本。仅有 hash 出现在 on-chain，不能证明资产的有效性、价值或所有权。 [5]

每位接收者按具体协议的规则，只验证通向所接收状态的那部分历史。
所需数据以历史与证明包的形式在 Bitcoin 之外传递。
Single-use seal 是一种抽象 commitment，只能在选定消息上有效关闭一次。
Proof-of-Publication 将紧凑 commitment 锚定到公开交易顺序，使同一封条被用于不相容转换的尝试可被发现。
Client-Side Validation 是通用设计模型，并非 RGB 的同义词。
隐私和扩容把保存数据的责任转移给数据所有者。
公众通常只能看到 Bitcoin 交易和短 commitment，看不到完整合约。
核验时必须知道确切协议、可信 genesis 或 schema、seal 定义、commitment scheme、完整连续历史、Bitcoin 交易状态和软件版本。
参与者无需向全球公开全部合约数据，而是在 off-chain 传递所需历史、自行验证规则，并在 Bitcoin 上检查密码学 commitments 与 single-use seals 的关闭。

结合上下文阅读

要获得更完整的理解，请将本词条与以下词条结合阅读： UTXO, 双重支付, Hash, Taproot, Sidechain, 共识规则. 反向关联还来自： RGB Protocol, Taproot Assets.

?实用问题

01Bitcoin full node 会执行 Client-Side Validation 吗？

不会。Full node 验证 Bitcoin 交易及其 consensus 规则；接收者使用相应客户端在本地验证私有数据及其规则。

02Client-Side Validation 需要 soft fork 吗？

该模型可使用现有 Bitcoin 交易、commitments 与 UTXO 花费，无需改变 consensus；具体协议仍须准确公开额外假设和规则。