系统交易
EVM 应用程序通过 eth_getLogs 等标准接口订阅链上活动。但是，在 Stable 上，一些最重要的操作（例如抵押完成解除绑定）发生在 SDK 模块内部，这些模块不会自然地发出 EVM 事件。系统交易弥补了这一可见性差距：协议本身提交 EVM 交易，这些交易为 SDK 层操作发出事件，使它们可以通过 dApp 已经使用的同一日志流进行索引。
为什么这很重要
考虑跟踪用户的代币何时完成解除绑定。如果没有系统交易，dApp 将需要：
- 运行一个单独的索引器，它会监视 SDK 事件并将其存储在自己的数据库中。这增加了操作开销并引入了一个新的故障点。
- 定期轮询 REST 端点。这会导致 5-10 秒的延迟，更高的 RPC 负载，并且需要维护两个客户端堆栈（web3 + REST）。
系统交易通过 dApp 已经用于 EVM 日志的同一 WebSocket 连接，向 dApp 提供实时事件通知。无需单独的索引器，也无需轮询 REST。
工作流程
1. 协议事件： SDK 层操作完成（例如，抵押解除绑定）。
2. 检测： x/stable EndBlocker 检测到事件并将其排队到状态中。
3. 系统交易： 在下一个区块的 PrepareProposal 中，协议生成一个
调用 StableSystem 预编译的系统交易。
4. EVM 发出： 预编译处理排队条目并发出标准
EVM 事件 — dApp 通过 eth_getLogs 和订阅看到它们。系统交易由验证者在区块提议期间创建，而不是由用户创建。它位于区块的开头，在任何用户交易之前。
StableSystem 预编译
事件流经 StableSystem 预编译，位于 0x0000000000000000000000000000000000009999。目前，它为质押解除绑定发出一个事件（UnbondingCompleted）。该协议旨在将此扩展到其他 SDK 操作（验证者佣金更改，治理执行），采用相同的模式。
安全模型
两个属性使事件流值得信赖：
- 仅限协议发送者。 系统交易使用
0x8888888888888888888888888888888888888888作为其发送者。EVM 状态转换规则只允许从该地址发送到StableSystem预编译的交易跳过签名验证。用户无法伪造事件或从自己的交易中调用受限的预编译函数。 - 确定性事件发送。 每个诚实的验证者都会为相同的协议事件生成相同的系统交易。除了标准共识之外，没有额外的信任假设。
批处理
为了限制区块大小，每个区块最多处理 100 个解除绑定完成。在 Stable 大约 700 毫秒的区块时间内，这大约是每分钟 9,000 个解除绑定完成，远高于典型的质押活动。如果爆发超出每个区块的限制，解除绑定完成将以 FIFO 顺序排队，并在后续区块中处理。
SDK 事件与 EVM 事件发出之间存在一个区块（约 700 毫秒）的延迟，这相对于 7 天的解除绑定期本身可以忽略不计。
ABI 查找位置
StableSystem 接口、事件签名和发送者授权规则位于 系统交易参考 中。