这几天被 @VitalikButerin 转发评论的 @brevis_zk 这个zkvm 很热，尤其最近他们推出了实时证明，平均6.9秒的证明速度。之前也分享过这个项目，今天系统分享下实时证明对ETH的重要性以及@brevis_zk 的整体研究分享。 为什么实时证明重要？实时证明到底有什么价值？和ETH L1扩容有什么关系？ 1）ETH L1计算和容量仍然有限，所以V神和基金会团队规划的ETH L1扩容已经箭在弦上，虽然有不同的模块，但是ZKVM在这里起到的作用比较核心，未来的ETH L1将是以ZK为核心，共识层会避免重复计算来做验证，而是只用计算一次，生成证明，其他节点验证证明后达成共识的新机制。并且zkvm客户端为了避免单一节点和实现的电路漏洞，所以一定是支持多样实现版本的，所以像Brevis等ZKVM都有机会分一杯羹。 2）zkVM 在 L1 扩容中的作用机制： 传统以太坊 L1 的验证者需要： -重新执行交易（EVM interpreter） -检查状态转换是否合法 这部分计算成本高、阻碍扩容。 3）zkVM 则允许“用证明代替重算”： -zkVM 在链下完整执行交易逻辑（EVM 字节码或更高层 VM 指令） -生成一个 zk proof（证明状态转换正确） -L1 上的合约（Verifier）用常数时间验证该证明 -即使 EVM 逻辑复杂，验证仍然是 O(1) 4）通过zkvm客户端，则就变成了，所有交易并非要全部执行，只需要执行后生成证明，其他节点进行验证证明即可，避免了所有节点重复执行的低效率，这将对L1带来很大的效率提升，这个提升主要是需要实时证明的支持，那多实时才叫实时证明呢？ 简单先看下ETH的共识层的一些机制： 以太坊共识层（Beacon Chain） 的时隙时间 slot time = 12 秒 决定的。 以太坊每 12 秒产生一个新区块（即一个时隙 slot）。 这个时隙内，共识客户端（consensus client） 要完成： -接收新区块； -执行区块中的交易； -验证执行结果是否正确； -在网络上传播签名、投票、汇总。 因此，如果 ZK 证明系统要替代执行层（Execution Client）的验证逻辑，就必须在 12 秒窗口内完成证明生成（proof generation），否则共识层无法实时确认新区块。 5）最新的Pico Prism，使用 64 个 RTX 5090 GPU，99.6% 的区块在 12 秒内得到证明，平均 6.9 秒 下面详细研究下 http://Brevis.network： 支持实时证明的 - AI/Web3的可验证计算层http://Brevis.network 定位：http://Brevis.network 是AI和Web3的可验证计算层 http://Brevis.network 有三款主要产品： 1）Pico RISC-V ZKVM（已支持实时证明）： Pico是一款RISC-V的ZKVM，并且为了应对证明系统的快速发展和业务逻辑的不变变化，Pico是基于模块化ZKVM的设计，支持可插拔后端证明系统，以及业务协处理器，Brevis的技术基础来自于Pico，最新已经支持实时证明。 另外相比其他ZKVM在实际落地业务场景上，Brevis有两款已经落地几十家DEFI客户的产品，他们分别是Brevis data Coprocessor和Incentra。 2）Brevis data Coprocessor： Brevis data Coprocessor 是一款高效的零知识证明协处理器（Brevis链），它使智能合约能够读取所支持的区块链的完整历史链上数据，并以完全无需信任的方式运行可定制的计算，传统方法要么使用中心化方案，要么链上计算则需要付出昂贵的gas成本（基本无法承担的成本），而Brevis data Coprocessor凭借无需信任的历史数据，Brevis可以支持数据驱动的 DeFi、用户留存和参与功能、无需信任的主动流动性管理、基于全链活动的身份等等。目前合作的客户包括PancakeSwap ，Usual Money ，MetaMask，Linea ，Uniswap Foundation，OpenEden ，Trusta AI，0G 等等 3）Incentra可验证的 DeFi 协议激励分配平台： 通过zkCoprocessor支持的可验证激励平台，如传统的空投的计算都是黑盒子，都是项目方私下里计算给发放奖励，Incentra支持奖励直接在零知识证明电路中计算，并直接在链上验证，确保无需信任、透明且可验证的奖励计算。用户可以独立验证奖励金额，无需依赖任何中心化机构。 下面主要介绍下核心基础设施Pico RISC-V zkvm的架构设计： Pico 一款开源零知识虚拟机 (zkVM)，他是一款模块化设计的RISC-V的ZKVM，核心提出是 “glue-and-coprocessor” + 模块化 架构 —— 即 VM 本身作为 “胶水”（glue），负责通用逻辑、控制流、状态转换；而高频或复杂操作由专门的协处理器（coprocessor）处理以提升性能，目前有AI推理协处理器，链上数据协处理器等。 另外这几年证明系统发展非常快速，一旦代码绑定了哪个证明系统，可能对于证明系统最新的技术进步的跟进就会缓慢，所以Pico设计是一个可插拔的模块化架构，支持可插拔证明系统以及业务电路逻辑的可插拔。 Glue 层 / VM 核心： 管理执行流程、状态转移、函数调用、异常、内存 & 设备访问 通用的、应用无关的逻辑在这里处理，VM的核心 预编译 / 内建函数： 对于常见操作（如哈希、加密、签名、算术扩展）提供高效实现。扩展了 RISC-V 指令集，加速哈希计算、签名验证等底层操作。Pico 支持开发者根据需求自定义预编译模块，同时也提供开箱即用的优化方案，避免这些操作被展开为通用电路，从而减少成本 Coprocessor（协处理器）： 为特定场景（如链上数据访问、交易逻辑、复杂代数运算等）提供专门电路加速 可按需定制或替换。 后端 / 证明流水线（可插拔的证明系统）： 1）支持多种证明系统 / 素数域 / 优化策略 如STARK（KoalaBear、BabyBear），CircleSTARK（Mersenne 31），Pico 支持 可选模块化后端，即开发者可以选择不同的证明系统、素数域，或调整证明流水线 以优化性能／证明大小／验证时间等权衡 2）例如，Poseidon2 哈希函数主要应用于 zkVM 递归证明。在 STARK 系统下，KoalaBear 证明效率远超 BabyBear，仅需更换证明后端即可大幅提升性能，而无需修改计算逻辑 Pico 还将这一架构拓展至可验证 AI 推理（AI推理协处理器）： 这是Pico另外一个有潜力的方向，现在很多ai的api生意里，一个Router的服务方，来协调多模型或自动根据成本路由模型。这本身是一个不错的服务，但是服务方往往会根据利润等来以次充好。比如用户明明调用了10次GPT5，router服务方为了提升利润，这里面6次给你GPT5，4次给你另一个低成本的模型，这时就需要可验证的AI推理服务了。 Pico Prism 的分布式 / 多 GPU 架构： Brevis 推出了 Pico Prism，是对原有 Pico 架构的重大拓展，采用 分布式、多 GPU 的设计，以支撑更大规模、更实时的 Ethereum 区块证明。 Brevis如何参与： 1）Brevis Spark 积分活动：https://proving-grounds.brevis.network/qypDX6 2）discor获得角色 实时证明研究资料： https://blog.ethereum.org/2025/07/10/realtime-proving(头雁)