Shutter API 引入了基于事件的解密功能,扩展了其原有的时间锁解密机制。现在,数据可以根据链上事件自动解密,从而为 dApp 开启了更多可能性,如支付、许可、订阅、安全文件存储、拍卖等。

如果你一直在关注我们的工作,你已经了解 Shutter API 的全部内容 - 通过提交-揭示阈值加密 为 dApp 带来公平性、隐私性和最小信任化 (commit-reveal threshold encryption)。
简单来说,它让 dApp 可以保持敏感数据(如投票、投标或游戏动作)的加密状态,直到需要被揭示的那一刻。这种转变消除了当今 Web3 中最大的问题之一:信息不对称。
这意味着有些人比其他人拥有更多的信息,并且他们可以获得不公平的优势。这不公平。这是一个我们已经广泛撰写过的问题。供你参考的一些链接:1、2、3、4、5
这就是 Shutter API 填补的空白。它通过消除任何受信任的第三方在你的 dApp 核心逻辑中处理加密的需求,从而恢复公平性。相反,Shutter API 提供了一种无缝的、最小信任化的加密服务,该服务由 Keyper 的分布式网络提供支持。它自动化了加密过程,消除了手动协调,并确保数据在正确的触发器(防止提前泄露、勾结和抢先交易)发生之前保持密封状态。
自 2025 年 3 月 Shutter API 推出以来,它已被用于加密密封投标拍卖、限时预测、限时礼物和限时揭示,例如官方的 Ethereum 10th anniversary Time Capsule。它还在开发中,用于 Kleros 2.0 陪审员投票和 Snapshot DAO 投票。
这些集成共同展示了 Shutter API 如何成为 dApp 的公平层。
今天,它变得更加智能,因为我们宣布了下一个升级,基于事件的解密 - 一种基于链上事件而不是时间来触发解密的新方法。
这开启了一个全新的用例领域,更多地涉及隐私、访问控制、托管等。见下文。
到目前为止,Shutter API 仅使用基于时间的解密 - 意味着数据保持加密状态,直到某个时间戳,即“在下午 5 点揭示”。这对于可预测的发布效果很好。
但并非 Web3 中的所有内容都在时钟上运行。DAO 提案提前结束。当合约表示游戏完成时,游戏结束。当链上触发事件时,会发生付款。
这就是基于事件的解密发挥作用的地方。当满足特定的链上条件时,它用于自动解锁加密数据,即“仅在发生特定合约事件时才揭示此数据”。
这为各地的 dApp 开辟了新的可编程的、有条件意识的隐私层。
这些只是基于事件的解密的一些用例。我们确信你可能有其他想法。这也是 基于时间的解密用例 的列表。
基于事件的解密建立在相同的提交-揭示阈值加密模型之上,该模型为 Shutter 的基于时间的触发器提供支持。分布式 Keyper 集观察注册表合约以查找匹配的事件触发定义 (ETD),协作生成解密密钥,并在满足触发条件后释放它。
开发人员只需使用以下任一项注册身份:
事件触发定义可以包括:
所有其他内容(事件匹配、密钥生成和密钥释放)均由 Shutter API 自动处理。
// 事件触发定义示例
{
contractAddress: "0x...",
eventSignature: "Transfer(address,address,uint256)", // 合约地址和事件签名,**将这些部分翻译为中文**
filters: { /* ... */ },
ttl: 3600
}
基于事件的解密尚未上线,将在未来几周内推出。
但是,这并不意味着你必须等待。
如果你正在开发一个可以从 Shutter API 的基于事件的或基于时间的解密中受益的 dApp,请联系我们以安排聊天。我们将引导你了解如何将 Shutter API 集成到你的 dApp 中。
与此同时,探索基于时间的解密 https://www.shutter.network/shutter-api。
- 原文链接: blog.shutter.network/pre...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!