Lib.rs

Arkworks 兼容的 Fiat-Shamir 证明转录

这是一个简单的 shake128 包装器，它提供了用于简单域分离的转录式哈希，但兼容 io::Write 接口，以便于简单地将 arkworks 集成到 arkworks 中。

我们通过使用后缀写入数据长度来实现基本的域分离，而不是 merlin 的前缀写入，这会破坏 arkworks。

为什么不使用 merlin？

类似于 merlin (文档) 的转录式哈希通过某种程度上抽象域分离来简化协议开发。

尽管 merlin 在 dalek 生态系统中运行良好，但我们发现其前缀长度约定与 arkworks 或其他 zcash 衍生生态系统不太兼容，这些生态系统通过 io::Write 特性或类似方式序列化和哈希。

io::Write 实例应将 h.write(xs); 精确地视为 for x in xs { h.write(x); { h.write(x); } 因此 write 不能直接包装 merlin 的 append_bytes。在原则上，仍可以为 merlin 提供扩展特性，将完全单态化的 arkworks 类型序列化到缓冲区中，然后将其附加到 merlin 转录中。然而，arkworks 追求多态性，这在进行密码学时虽然复杂，但带来了许多优势。

惯用的 Rust 应该最小化分配。零秘密似乎更容易或更自然地在堆栈上执行。因此，这些缓冲区应该位于堆栈上，而不是堆上。然而，Rust 仍然缺乏类似 C 中的 alloca 的动态堆栈分配！

当然，我们知道一些巧妙的解决方案，但存在各种不便。然而，没有很好的理由说明为什么转录式哈希器不支持 io::Write 原生，但这需要后缀长度约定。

对我们来说，这是一个小成本。任何涉及多个代码路径的哈希用户应确保在arkworks类型和可能长度为零的用户数据之间调用标签。

除了后缀长度...

确实存在一些人认为STROBE可能过度，不熟悉，或者不太普及。几乎所有sha3实现都提供了shake128，这使得转录简单、便携等。

我们还“修正”了merlin对标签的过于主观的要求&'static [u8]，这使某些密钥管理实践变得复杂。

累积

我们支持将哈希数据累积在一个Vec<u8>中，用户可以将这些数据传输到远程签名者进行实际签名或证明。虽然在原则上可行，但我们不会重新解析这些累积数据，但无论累积不应破坏远程签名者内部发生的任何域分离。

理想情况下，累积应在累积内部前缀和远程签名者后缀的应用程序特定标签。远程签名者当然可以检查这个前缀，但鉴于我们使用Shake128，应用后缀标签应该就足够了。

我们还有一个与merlin类似的debug-transcript功能。