一个把 Gas 费当工资单的提案
智能合约被成千上万人使用，开发者靠什么赚钱？代币、订阅、抽成额度是常见答案，它们有一个共同毛病：要么引入额外信任，要么让用户多付一笔明账。2023 年 5 月 1 日提出的 EIP-6968 提出一个几乎零新增流程的思路——用户本来就要为每次交互付 Gas，把其中固定的一小份直接按”谁的代码真的跑了”分给合约，开发者收入就嵌进了网络本身。这个机制被命名为 Contract Secured Revenue，合同收益分成，提案特指在 EVM 兼容的 Layer 2 网络上实施。按仓库当前标注，它停留在 Stagnant 状态，没有任何以太坊主网或主流 Layer 2 实现过它，正文里所有规则都是纸面规格。
五分之一怎么切：原文里的账本
分账公式在原文写得具体。提案引入常数 REVENUE_SHARE_QUOTIENT，取值为 5，意思是每 Gas 费用里按基础费除以 5 的那部分进入分账池。分给谁？不是简单地打给交易目标地址——一笔交易可能穿过聚合器、路由、金库好几层合约，钱该按”代码执行的贡献”流。于是规格要求每条区块执行时维护一张交易级的账本 gas_used_by_address：每执行一条指令，就把它的成本记到当前执行地址名下；遇到派生子调用帧的操作，把转给子帧的 Gas 从父帧账上扣除；子帧耗尽 Gas 报错时，剩余部分也计入出错地址。交易结束后，对账本里每个地址按其 Gas 份额乘以基础费除以 5 的单价，给它的收益接收人加余额。这套设计明确不分给普通外部账户——EOA 不写代码，不在分账逻辑里。
SETREVENUERECIPIENT：开发者唯一的开关
合约往往不直接持钱，收益该进哪个地址？提案给了一枚新指令 SETREVENUERECIPIENT，草案里占用操作码 0x49，从栈上取 20 字节低位作为本合约的收益收款人，成本 3 Gas。收款映射是交易级的临时表，每条交易开始时全部默认”自己的地址收自己的钱”，只有被这枚指令改写过的部分例外。这种临时映射的取舍原文专门解释过：若把收款人写进账户结构，状态树要加字段、部署流程要改，伤筋动骨；交易内临时表虽然每条交易重算一遍看似浪费，却换来改动面最小。顺带一提，操作码 0x49 在真实世界里已被坎昆升级的 BLOBHASH 用掉——这个编号在 6968 的草案语境里才成立，再次印证读提案必须以原文状态字段为准，不能拿草案常数当现实查号。
为什么限定 Layer 2
原文明确说不动以太坊主网的费用结构，只呼吁 L2 试验。这个边界不是谦虚：主网的费用要覆盖去中心化安全预算，改动牵扯质押者、排序器与协议收入的三方平衡；而 Layer 2 的排序与收入分配本来就是运营方的局部决策，拿其中五分之一做开发者激励，属于可逆的小范围实验。提案列的三个目标也都长在 L2 生态竞争上：给开发者新收入流、给公共物品一个自动抽水口、给项目方一个迁移诱饵。换句话说，6968 是商业与治理层面的方案裹了一层协议外衣——机制需要协议支持，动机却是生态战争。也正因此，它的停摆与技术难度关系不大，更多反映了这类分配方案的敏感性：动了排序器的收入蛋糕，还要在每条指令上记账，工程与政治两道账都不便宜。
用户侧现在能看到什么
截至本次按 EIPs 仓库核验时，用户在主网和主流 L2 上找不到任何与 CSR 对应的设置项、账单栏或费用字段——它没有部署。市面上若有产品宣称”Gas 返佣给开发者是本链原生机制”，那是各自运营层的产品条款，不是 6968 落地，判断时看客户端代码仓库有没有对应实现，别看营销页。这条提案真正给普通读者的启示在费用阅读法上：一笔交易的 Gas 费在不同网络、不同升级下会被拆成不同归属——主网基础费销毁、优先费给打包者，L2 还要多一层排序器收入——先问”这笔钱最终进了谁的口袋”，再评估产品话术。开发者视角的启示则更直白：分账提案的价值评估里，“谁被排除在分配外”与公式本身同样重要，6968 排除 EOA、按 Gas 而非按调用次数计酬，两处都写了价值判断。
风险提示
本文涉及的提案状态、常数与操作码草案值按 EIPs 官方仓库原文核验，均可能随社区推进变化，请以仓库当前内容为准。费用机制分析不构成投资建议；对任何宣称内置收益分成的产品，请以官方文档与客户端实现核实。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。