时间:2024-05-11|浏览:257
编译:Alex Liu ,Foresight News
以太坊成功带来了一个蓬勃发展的去中心化应用生态,但它的可扩展性挑战也日益严峻。开发人员面临着一个艰难的选择:限制其应用程序的功能和数据丰富性,或者忍受高昂的 Gas 费用和 Gas 用量限制。如果开发人员有办法绕过这些限制,会怎么样?
RISC Zero 是主要的 zkVM 开发商之一,如果你常在耳边听到 zkEVM,但并不了解一字之差的 zkVM 是什么,可以参考这篇文章。RISC Zero 最新推出了 Steel,它是基于 Alloy 的视图调用证明库,为开发人员与以太坊 L1 或其他 EVM 链交互方式带来巨大转变。利用零知识证明和 RISC Zero zkVM,Steel 使开发人员能够以可扩展、安全且经济高效的方式执行视图调用并可证明地读取和计算以太坊的状态。
Steel 弥合了以太坊应用开发和零知识技术之间的距离,使开发人员更容易在其智能合约中利用 ZK 的力量。结合 RISC Zero zkVM 的功能,Steel 使开发人员能够在以太坊 L1 或任何 EVM 等效链上构建更安全、可扩展且高效的应用程序。
借助 Steel,开发人员能够:
使用 Steel,执行视图调用像指定所需的 Solidity 方法一样简单。无论是检索 ERC-20 代币余额 (example) 还是访问以太坊状态等各个方面,Steel 都可以通过与 RISC Zero zkVM 无缝集成来简化流程,同时确保安全性和效率。测试表明,Steel 有能力在单个视图调用中处理超过 100K SLOAD 操作,这节省了主网上数千美元的 Gas 费用。我们可以使用 Bonsai 在大约 15 分钟内证明它,这至少需要 210M 的 Gas,超出区块限制 7 倍。
下面的代码片段演示了使用 Steel 证明以太坊上部署的 ERC-20 合约的特定地址余额的过程。此示例展示了开发人员如何利用 Steel 在 zkVM 内与以太坊链上数据进行交互。完整代码可在此处查看。
定义视图函数签名
首先,使用 sol! 宏来定义 ERC-20 的 balanceOf 函数签名。这将解析 Solidity 语法以生成相应的 Rust 结构体,该结构体实现了 SolCall trait,可用于调用 balanceOf 方法,该方法接受一个账户地址并返回关联的 ERC-20 代币余额。
准备调用
接下来,通过用目标账户地址实例化 balanceOfCall 结构体来设置调用。同时,为希望查询的合约地址和调用者的地址定义常量。
在 Main 中执行调用
主函数在 zkVM 中执行,生成零知识证明。它首先读取输入环境,然后构造一个 ViewCallEnv 对象,确保当前状态与预期的状态根匹配。在提交相关区块哈希和编号后,执行视图调用,并打印余额。
Steel 通过三个步骤在 RISC Zero zkVM 中证明 Solidity 代码,简化了执行的过程:
使用传统的存储证明,开发人员必须手动选择其智能合约使用的存储槽,并重新实现智能合约逻辑。而使用 Steel,所有存储槽都会根据视图调用执行自动发现和获取。这为开发人员节省了大量时间,减少了实施错误的可能性,从而减少了出现安全漏洞的机会。
在以太坊智能合约中使用 blockhash 操作码进行验证时,验证的 commitment 必须引用不超过 256 个区块旧的区块哈希。考虑到平均区块时间为 12 秒,这就设置了一个约为 50 分钟的狭窄时间范围,用于完成证明生成并确认验证交易已包含在一个区块中。
当需要在链上获取一个早于 256 个区块的已验证的区块哈希时,可以使用以下几种策略之一:
设想未来链下计算将与链上验证无缝集成。 Steel 使开发人员能够在 zkVM 内可靠地访问和计算以太坊的完整历史,从而能创建出下一代数据丰富且功能更强大的链上应用程序,为实现这一愿景做出不小的贡献。