ERC-2746 规则引擎合约：部署一次，之后用规则树改行为

智能合约的常识是逻辑随字节码固化，改规则就得升级或迁移。2020 年 6 月 20 日创建的 ERC-2746 提供另一个思路：把”规则”本身做成数据存进合约，部署一次引擎，之后增删改的都是规则记录而不是代码。仓库状态 Stagnant。这份标准的直接动机写得很实在——哪怕改一行逻辑也要重新部署、重新审计、重新验证合约，对小迭代是沉重负担；如果常见判断可以表示为规则树，一次调用就能执行整条流水线。

四个术语搭出的语法

原文给了明确的术语定义，理解这层语法就理解了整个接口。属性是注册进数据域的一个数据点，可以存在于引擎合约内部，也可以指向外部来源；规则是对单个属性的一次判断动作，标准举的例子是检查名为 TokenAmt 的属性是否低于右值 10；规则集是若干规则的集合，调用它产生一个布尔结果，这个布尔值决定执行流在规则树里的走向；规则树是规则集的层级组合，规则集里还能再嵌规则集。四者合起来是一门”如果则否则”的分支语言，语义相当于把决策表写成了合约存储里的数据。

函数表与此对应：addAttribute 登记数据点；addRule、addRuleSet、addRuleTree 三个注册函数把规则元素写进合约，配套 getRuleProps、getRuleSetProps、getRuleTreeProps 读回属性；executeRuleTree 执行一棵树，removeRuleTree 移除整棵树。标准特别注明执行应当发出事件，事件里的 ruler 字段标识树的编号与所有者。

原子执行是卖点也是雷点

“一次调用执行整棵流水线”是标准反复强调的卖点：规则链中间步骤失败则整体回滚，外部看到的是要么全做、要么没做的交易。省 gas 之外，这给治理流程一种新形态——风控条件、版税分配、白名单判断都可以从代码降级成可编辑的数据表。

风险恰好长在同一个地方。规则即数据，意味着改规则不需要重新部署，也绕开了每次变更的审计与验证仪式。一条规则集的布尔结果会决定资金路径的分叉方向，能增删规则的人就等于掌握了逻辑本身，却不必经历合约升级那种公开透明的流程。标准的执行事件设计其实是在为这种权力留日志，但日志解决追责，不解决事前约束。

停在纸面的原因与影子

ERC-2746 需要用户先信任一种新语法，而当时的以太坊生态正被现成的代理与模块化模式占据，规则树这种解释器式合约多出来的 gas 开销与调试难度劝退了实践者。它没死透：DAO 参数治理把决策做成链上可投票的数据项、自动化协议的条件触发表达式、风控策略引擎，都共享”逻辑数据化、变更走流程”的精神。

事件设计上有一处值得称道的细节：标准规定规则树执行时发出调用事件，事件里的 ruler 字段同时承载树的编号与所有者身份，并特意注明这个字段多半就是交易者本人。含义是引擎不替人隐身——每一条被执行的条件流水线，链上都能追到树的归属者。对观察者来说，这是理解这类合约的关键入口：想知道某笔资金变动依据了哪些规则，顺着执行事件找到树编号，再顺着树的注册事件链重建这棵树的判断结构，比读代码注释诚实得多。

给读者的迁移提醒很具体：凡遇到宣称”无需升级合约即可更新规则”的系统——版税开关、白名单逻辑、风控阈值——都请把它当作合约升级来看待，查谁有权调用规则变更函数、变更是否即时生效、有没有延时与公开事件。逻辑搬进数据，审计负担没有消失，只是从部署时挪到了每一次调用前。本文为机制说明，不构成任何投资建议。