客户端验证提交验证库

这是LNPBP-8一次性密封抽象的实现。具体来说，它提供了一组特质，允许实现Peter的Todd 一次性密封模式。此文件中的信息部分包含在“进一步阅读”部分列出的Peter的作品的摘录。

该库是更通用的client_side_validation库的一部分，该库涵盖了其他客户端验证标准。客户端验证是基于证明发布/提交介质层的一种分布式计算模式，该层可能是比特币区块链或其他类型的分布式共识系统。

该库的开发得到LNP/BP标准协会的支持，并在其GitHub页面上执行。

该库最低支持的Rust版本（MSRV）是1.66和2021版Rust。

文档

有关库的详细开发人员及API文档，请访问https://docs.rs/single_use_seals/

要了解由库启用的技术，请查看我们的技术演示文稿幻灯片和LNP/BP技术会谈视频

用法

要使用该库，您只需在项目的Cargo.toml文件中的[dependencies]部分引用最新版本即可。

single_use_seals = "1"

如果您正在使用其他客户端验证库，请考虑只导入一个将所有这些库（包括当前库）重新导出的单个client_side_validation库。

该库不公开任何功能标志，并且只依赖于amplify_derive包，该包由LNP/BP协会创建和支持。

更多信息

一次性密封定义

类似于现实世界中用于安全运输集装箱的物理一次性密封，一次性密封原语是一个唯一对象，可以正好对一个消息进行一次封闭。简而言之，一次性密封是一种抽象机制，用于防止双重支出。

一次性密封实现支持两种基本操作

• Close(l,m) → w — 在消息m上封闭密封l，生成一个见证w。
• Verify(l,w,m) → bool — 验证密封l是否封闭在消息m上。

如果攻击者无法使同一密封（即使存在多个见证也是可以接受的，尽管不是最佳情况）对两个不同的消息m1, m2的Verify函数返回true，则一次性密封实现是安全的。

实际的单一用途密封实现显然还需要某种生成新的单一用途密封的方法

• Gen(p)→l — 基于某些密封定义数据p生成新的密封。

术语

一次性密封：对某些（可能是未知的）消息的承诺。第一个承诺（即一次性密封）必须是一个定义良好的（即完全指定并在某些空间中不可区分，如时间/地点或在一个给定的形式化信息系统中）。密封消息：第一个承诺的履行：在密封的不可区分定义的形式下创建对某些消息的实际承诺。见证：在封闭一次性密封时产生的数据，对于独立一方验证该密封确实封闭在给定的消息上（即根据密封定义创建了消息的承诺）是必需的和充分的。

注意：虽然可以确定性地定义一个给定的密封是否封闭，但还可能无法确定密封是否打开；即密封状态可能是“封闭消息”或“未知”。一些特定的一次性密封实现可能定义了确定性地证明一个给定的密封未封闭（即打开）的程序，但这不是规范的一部分，我们不应该在所有情况下都依赖这种可能性。

特质结构

该模块定义了一个可以用于实现一次性密封的特质SealProtocol，该特质包含密封关闭和验证的方法。实现该特质的类型仅使用消息（表示为任何可以表示为字节序列的类型，即实现AsRef<[u8]>的类型）和见证（表示为相关类型SealProtocol::Witness）。同时，SealProtocol不能自行定义密封。