在EVM的指令表里，0x40开头的一段被划给了区块信息：BLOCKHASH读历史区块哈希，COINBASE读受益地址，TIMESTAMP、NUMBER、DIFFICULTY、GASLIMIT各读各的。2017年8月，Cody Burns提交了EIP-698，想把这张清单补上最后一格——0x46，BLOCKREWARD，返回一个已定局区块的总奖励，数值包含协议基础奖励、叔块付款和这个区块收到的全部手续费。提案状态停在Stagnant。它想解决的问题很小，牵出的问题空间却很大。
谁需要在一个块尘埃落定后问它值多少钱
动机部分给出的第一类用户是矿池。矿池分账的教科书算法——按份额计酬、按比例分账、按最近若干份额滚动结算——全部建立在一个输入上：这一轮池子真的从链上拿到了多少钱。提案原文列出的公式里，每一笔收益都等于区块奖励乘以一个份额比例，而这个B（扣费后的块收益）如果只能靠池子自己上报，分账合约就退化成对运营方的信任测试。BLOCKREWARD的设想是让结算合约自己去链上查数：块定局了，奖励数字写在那里，合约读出来按公式分，运营方失去做账空间。动机点到的第二类用户是有类似需求的合并挖矿与质押分账结构，本质同样：凡是要把“这个块发了多少”当事实输入的合约逻辑，都需要一个可信的读数口。
它和已经存在的那几格有什么不同
有人会说，奖励数字合约也能算出来——发行规则公开，叔块规则公开，手续费在区块里也能逐笔求和。理论上对，工程上贵：把整套发行公式复刻进合约，等于每次协议调发行都要改一遍所有分账合约，而EIP-698引用的那份路线图提案恰恰说明发行量会周期性变化。另一个近似答案是COINBASE指令，但受益地址和受益金额是两回事——知道钱进了谁的口袋，不知道进了多少。BLOCKREWARD填的正是这一格：一个客户端替你算好的汇总数，按基础Gas费计价读一次。
为什么停在了草稿时代
这条提案没能挤进任何一次升级清单，原因可以摊开成三层。第一层是时代转向：提案押注的是矿池与合并挖矿的长期需求，而以太坊在2022年转向权益证明，出块奖励结构整体重排，矿池这个用户群体在以太坊上直接消失。第二层是读取对象的尴尬：奖励从来不是区块头里的字段，它是共识规则的推论，要把它做成操作码，等于要求每个客户端额外维护一份“历史块奖励账”，而这份账本本可由发行规则推出——加一个数就加一条共识表面积，收益却只覆盖少数合约。第三层是同类需求的分流：后来的分账场景大多用预言机喂价、用外部结算层记账，或者直接读代币合约的入账记录，绕开了在虚拟机里复刻发行公式这条路。一个操作码的命运，就这样被共识转型和替代方案两头夹住了。
一张账单的两种查法
把同一个需求放进两个世界。假设一个诚实证明型的分账合约要按块结算：有BLOCKREWARD的世界里，合约读一次操作码拿到数字，套公式转账，全部成本是常数级Gas。没有它的世界里，合约要么调用一个外部预言机——多信一个数据源，多一条被操纵的路径；要么接收发行人提交的奖励声明并附带计算——多一套校验逻辑，多一批边界案例；要么自己复刻发行曲线——每次路线图调整都要部署新合约迁移逻辑。三种替代都不致命，但都说明同一件事：协议没提供的读数，生态会用信任或代码把它补回来，补法的质量参差不齐。
快速问答
问：BLOCKREWARD返回的数字含手续费吗？ 答：按提案规格，含基础奖励、叔块付款和区块内交易手续费三部分汇总，即出块者该拿的总额。 问：合并之后还需要查区块奖励吗？ 答：以太坊的出块收益改由共识层记账，执行层合约没有对应的读取需求，这也是该提案失去主要用户的原因之一。 问：操作码0x46现在被占用了吗？ 答：它长期属于未分配的空白空间，协议规范对空白段的态度是不承诺、不预留，未来另有他用也完全正常。
风险提示：本文回顾协议提案历史，不构成任何投资建议，也不涉及任何资产的买卖时机判断。发行与奖励规则以以太坊官方文档与EIP原文为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。