控制反转

考虑一个场景，在没有控制反转的情况下，如果你想实现自动化（例如：当币价跌到 100 时自动卖出），你必须依赖外部实体：

传统方案的局限：你需要设置一个中心化的“机器人 (Bot)”来监控链上数据。这个机器人持有你的私钥，并在满足条件时替你签名发送交易。
IoC 的优势：
- 无需机器人：不再需要托管额外的实体来模拟人类签名。
- 去中心化自动化：只要输入和输出都在链上，逻辑就可以在去中心化的网络中完全自主运行。
- 消除单点故障：避免了因机器人服务器宕机或私钥泄露导致的风险。
传统模式：执行逻辑由外部力量（普通用户 EOA 或中心化机器人）启动。合约是“被动”的，没有外部指令它就是死的。
睿应模式：执行逻辑由合约自身根据预设事件决定何时运行。控制权从外部转移到了合约内部。
为什么要“反转”？ 传统的自动化需要你运行一个中心化机器人，给它私钥，让它不断扫描链上状态并签名发交易。这不仅存在单点故障风险，还引入了私钥管理的安全性挑战。RCs 允许你在完全去中心化的环境下运行这种逻辑。

![[Pasted image 20260309191204.png]]

运作机制

一个睿应合约的生命周期包含三个关键环节：

监听定义：在创建 RC 时，你首先需要指定关心的链、合约地址以及事件（Topic 0）。这包括转账、DEX 交易、贷款、投票等任何智能合约活动。
有状态处理 (Stateful)：当监听到目标事件时，Reactive Network 会自动执行你写的逻辑。RCs 是有状态的，这意味着它可以存储历史数据。例如，它不只是看当前这一笔交易，还可以结合过去一小时的数据进行计算。
自动触发：根据计算结果，RC 会更新状态并自主在目标链上发起交易。

1. 订阅与配置 (Input / Monitoring)

在创建一个 RCs 时，开发者首先需要定义“感兴趣的事件”。

指定目标：开发者需明确要监控的区块链（Chains）、合约地址（Contracts）以及具体的事件主题（Topic 0）。
监控范围：监控的活动可以包括代币转账、DEX 兑换、借贷记录、投票、大户（Whale）变动或任何智能合约的活动。
实时捕获：睿应网络（Reactive Network）会持续监测这些地址，一旦检测到匹配的事件，便会启动执行流程。

2. 逻辑处理与状态管理 (Processing / Stateful Logic)

一旦检测到事件，睿应网络会自动运行开发者编写的逻辑。

有状态执行 (Stateful)：RCs 具有“状态”属性，这意味着它们不仅能处理当前数据，还能存储并更新数值。
数据聚合：合约可以在状态中累积历史数据。当“历史数据”与“新链上事件”的组合满足特定标准时，才会触发动作。
逻辑计算：RCs 可以执行复杂的计算，例如计算 Uniswap 池中的流动性和实时汇率，或者聚合来自多个预言机的数据并取平均值。

3. 自主执行交易 (Output / Action)

这是 RCs 区别于传统合约的关键点：

自动触发交易：基于逻辑计算的结果，RCs 会自动更新其状态，并可以在目标 EVM 区块链上发起交易。
无需外部签名：整个过程在睿应网络内通过去中心化的方式运行，不需要人类用户或中心化机器人（Bot）持私钥签名发起交易。
信任最小化：执行过程是去中心化且不可篡改的，确保了响应的自动化、快速和可靠。

应用场景

多预言机数据聚合

我们设定一个航班延误险自动理赔的场景，目标是如果某航班延误超过 2 小时，自动给投保人赔付 1 ETH。

数据源（预言机）：为了防止单一数据源被操纵，我们需要聚合三个来源：

Chainlink（在以太坊上）：提供官方民航数据。
Pyth Network（在 Polygon 上）：提供实时机场雷达数据。
第三方商业预言机（在 Arbitrum 上）：提供航空公司官方 API 数据。

在传统 EVM 中，由于合约无法主动获取跨链数据，你必须：

依赖机器人：雇佣一个运行在中心化服务器（如 AWS）上的 Python 脚本。
手动中转：机器人要盯着三条链，等三个预言机都更新后，由机器人拿着你的私钥，算好平均值，再发一笔交易到保险合约触发理赔。
风险：如果机器人服务器断电了，或者私钥被黑了，理赔就永远不会发生。

而使用 Reactive Contracts (RCs)，整个流程变成了全自动的：

主动监听：一个 RC 合约同时订阅以太坊、Polygon 和 Arbitrum 上这三个预言机的“数据更新”事件。
自主决策：当 RC 发现三个数据都到齐了，它在睿应层内部自动计算：“3 个中有 2 个显示延误 > 2 小时吗？”。
自动理赔：一旦结论为“是”，RC 直接向目标链发起理赔交易。全程不需要任何人工或外部机器人干预。

在多预言机场景下，最难的不是“获取数据”，而是“谁来决定什么时候该聚合数据”。在睿应层，这个决定权反转到了合约自己手里。

Uniswap 止损单

在传统的去中心化交易所（DEX）如 Uniswap 中，“止损单”是很复杂的。如果你想在 $2500 卖出 ETH 止损，由于以太坊合约是被动的，它无法感知时间或价格的变化。你必须编写一个运行在中心化服务器上的 Python/JS 机器人（Bot）。这同样有上述说的私钥和中心化的风险。

而使用Reactive，步骤就变为十分简单的三步：

监听：RC 订阅 Uniswap 池中的 Swap 事件。
计算：每当有人在 Uniswap 交易，RC 会在睿应层内实时计算当前兑换率和流动性。
触发：一旦计算结果显示价格跌破 $2500，RC 自动向目标链发起卖出交易。

DEX套利

我们先假设一个具体的套利场景：ETH 的价格在 Ethereum 的 Uniswap 还是 $2500，但在 Polygon 的 QuickSwap 已经涨到了 $2510。这里存在 $10 的利差。

传统方案中，你需要在服务器上运行一个脚本，不断通过 API 轮询（Polling）两个链的价格。发现差价后，脚本指挥你的钱包分别在两条链发起交易。这中间比较严重的问题是，轮询 API 有延迟，等你发现机会并发送交易时，机会可能已被抢走。

而部署一个 Reactive Contract (RC)，它像神经末梢一样直接“长”在区块链的事件流上。RC 在睿应层内部是秒级感知的，并且自动判断获利空间。如果满足，它通过控制反转 (IoC) 机制，自主向目标链发起套利交易。

自动资金池再平衡

在一个多链生态中，同一个项目的流动性往往分布在多个不同的区块链上（例如以太坊、Polygon 和 Arbitrum）。

痛点：由于各链的交易量不均，某些链的资金可能会被买空（流动性枯竭），而另一些链的资金却处于闲置状态。
目标：根据实时需求，自动将资金从“溢出”的链搬运到“短缺”的链，以维持最优的流动性效率。

传统方案中，通常需要项目方运行一个复杂的后端脚本。该脚本不断调取各链节点的 API，对比余额，然后由项目方控制的多签钱包或管理员私钥发起跨链转账。

在Reactive中，思路如下

全局监控：RC 同时订阅所有相关链上的流动性变动事件（如 Mint、Burn、Swap）。
有状态分析：RC 是有状态的（Stateful），它会实时记录并更新各链的资金比例。
自主决策：一旦某个链的流动性低于阈值，RC 内部逻辑自动触发。
跨链回调：RC 自动向目标链发出指令，执行资金拨付或重组。

L1.1 - Reactive Contracts

beautifulremi