ETHSHANGHAI

活动 09 / 调研补充与独立分析

Reactive 深读：事件自动化，究竟把信任放在哪里

拆开事件订阅、ReactVM、跨链回调与费用支付，理解自动执行为什么仍需要权限、幂等和故障恢复。

执行架构回调授权费用与欠款重组与幂等上线核验
本篇内容导航自动触发，不是合约凭空主动ReactVM要放在明确的版本范围内回调是一条消息，授权必须落在接收端自动化仍有两本费用账重组、重复投递与失败不是同一种问题我的分析：把执行链条做透明，比宣称零信任更重要上线前可验证清单资料与延伸阅读

01自动触发，不是合约凭空主动

活动09用事件驱动连接自动化与Agent。下面依据官方文档作独立技术补充，不把文档的新变化写成现场嘉宾已经讲过的实现。Reactive合约订阅特定链、合约与事件，网络把匹配日志交给react()，Solidity逻辑判断后再提出目标链调用请求。它更像接入了投递系统的业务规则，而不是能自行感知世界的程序。[1][3]

例如借贷系统发出风险事件，反应式逻辑可以申请补充抵押品；但事件必须先存在，目标账户也必须有资产和授权。传递一条跨链指令不等于完成资产跨链，更不意味着两条链上的操作构成同一笔原子交易。这是理解后续安全边界的起点。

02ReactVM要放在明确的版本范围内

官网目前同时提供Legacy与非Legacy文档。Legacy的ReactVM页描述双状态架构：同一份字节码分别运行在Reactive Network与ReactVM，前者处理账户交互，后者处理事件，状态并不共享。同一部署者的合约可共享ReactVM；订阅应在网络侧管理，在ReactVM内调用subscribe()不生效。[2]

这意味着不能在网络侧设置一个暂停变量，就想当然地认为事件执行侧同时暂停。工程上必须确认两侧状态如何同步以及哪个入口真正阻止回调。ReactVM的“私有执行环境”也不应直接解读为数据获得密码学保密。

非Legacy的Reactive Contracts页则描述普通合约部署和系统合约投递事件，没有沿用上述双状态说明。因此本文用Legacy解释ReactVM概念，但不宣称所有现网版本仍采用它；上线前必须把文档、库版本、部署字节码与网络升级状态逐项对应。[1][2]

03回调是一条消息，授权必须落在接收端

Legacy流程通过发出Callback事件指定目标链、目标合约、gas限制及编码参数，网络随后向目的链提交交易。首个地址参数预留给RVM ID，系统将其替换为部署者地址。目标合约应同时检查调用者是不是预期的Callback Proxy，以及载荷里的RVM ID是不是获准的来源。[3][4]

只验其中一项都不足以表达完整权限：来源地址不能由普通外部调用者自行声称，合法代理转来的其他用户回调也不应获准操作你的资产。另一个细节是同一部署者可有多个合约，RVM ID不是每份策略独有的身份，业务仍需订单、方法和额度检查。[2]

补仓示例中，接收端还应限定代币、账户、单次金额、总预算与有效期，并在执行时重查仓位。事件发生后价格可能已变化；过期的正确指令，也可能是当下错误的交易。以上是独立的防护设计建议，不是官方已经替应用实现的承诺。

04自动化仍有两本费用账

Reactive侧需要REACT资金，目的链回调也需要相应资金。官方费用页区分合约余额、代理或系统合约中的储备与欠款；depositTo()与coverDebt()分别涉及充值、结清欠款，资金不足可能使合约失去执行资格。因此“程序已部署”和“程序还能工作”是两回事。[5][6]

计费时点存在明确版本差异：Legacy写的是RVM先执行、后按后续区块费用结算；非Legacy页写的是系统调用react()时同步计费。回调还取决于目的链gas价格、用量及附加定价项，不能拿一条链的gas费估算整个服务。[5][6]

实际运营应分别监控两侧余额、欠款与失败率，设置充值告警和预算熔断。若高波动时gas上涨，自动补仓可能恰好在最需要它时停摆；单次演示成功并不能证明费用储备足以覆盖压力场景。

05重组、重复投递与失败不是同一种问题

Legacy文档称ReactVM区块记录来源区块号与哈希，以跟踪和处理链重组。但这不足以证明已经在目的链成交的动作会被自动撤销，也没有给出适用于所有来源链的统一终局等待时间。设计者必须单独确认事件何时可被视为足够稳定，以及深度重组后的处置责任。[2]

重复消息需要幂等处理：可以结合来源链ID、区块哈希、交易哈希、日志序号识别日志，再用业务订单号限制只能完成一次。仅用区块号不够；仅做日志去重，也未必能阻止重组后同一业务被再次执行。事件结构确实提供上述日志字段，但幂等策略属于应用责任。[3]

回调发出、交易上链、业务成功必须分开记账。示例里的triggered=true只表示逻辑已发出请求，不能替代目标链成功回执。应模拟重复与乱序、余额不足、目标revert和超时，明确重试何时安全；对不可逆成交，补偿操作也不等于撤销原交易。[3]

06我的分析：把执行链条做透明，比宣称零信任更重要

我的分析：Reactive的价值在于把分散脚本中的事件响应规则变得可部署、可检查，但依赖没有凭空消失。来源链共识、事件采集与投递、网络执行、回调代理、目的链排序，以及管理员和资金补给，都属于信任与可用性边界。应比较依赖是否更透明，而不是宣传完全不用信任。

如果我是应用方，会先让自动化处理低额度、可暂停、能对账的动作，再逐步增加权限。Agent可提出策略，但最终资产权限应由确定性的规则把守。验证一个错误事件最多损失多少，比展示一次快速跨链调用更能说明产品是否可用。

07上线前可验证清单

以下项目都应有代码、交易记录或故障测试结果，不能只用“去中心化自动化”回答。

  • 版本与权限：记录文档版本、部署代码与代理地址；分别测试错误代理、错误RVM ID和越权业务参数必定被拒绝。[1][4]
  • 终局与幂等：明确各来源链确认策略，重放同一订单并模拟重组；证明不会重复扣款，列出无法自动补偿的情形。
  • 资金与恢复：耗尽两侧预算，观察停用、告警、充值和恢复；核对回调请求与目标链业务回执，而非只统计发出次数。[5][6]

资料与延伸阅读

下列资料支持技术与制度背景；分析、方案设计和示例推演由本篇作者给出，并非对现场发言的逐句复述。

  1. Reactive Contracts（非Legacy文档）Reactive Network
  2. ReactVM（Legacy）Reactive Network
  3. Events & Callbacks（Legacy）Reactive Network
  4. Origins & Destinations（Legacy）Reactive Network
  5. Economy（Legacy）Reactive Network
  6. Economy（非Legacy文档）Reactive Network