当前位置: 首页 > article >正文

以太坊 MEV 提案续篇:一文了解 Execution Tickets 和 Execution Auction

撰文:Tia,Techub News

解决 MEV 问题的背后是区块空间分配规则的制定,事关以太坊区块生产供应链。在《当前以太坊共识与 MEV 的博弈,要从 PoW 转向 PoS 那天说起……》一文中,我们谈到了 Merge 前后以太坊关于处理 MEV 的一些提案(PBS、ePBS、PEPC),本篇我们将继续介绍另外两个提案—— Execution Tickets 和 Execution Auction。

被低估的以太坊提案的重要性

以太坊路线图和以太坊提案在以太坊生态发展中都起着引领方向的作用。其中关系到各利益相关方的利益问题。如今,以太坊已然成为一个公共物品,公共物品的治理已不应只停留在以太坊基金会和资深专业人士手中,其应当实现去中心化。规则方向的确定就像薛定谔的猫,一旦确定了路线,你就只能看到这个路线下所属黑盒子的结果。以太坊提案和路线图事关以太坊规则制定和战略方向,去中心化治理不仅仅是口号问题。

Execution Tickets

在协议层面,Execution Tickets 将构建区块的权利以票证的形式出售,如果想构建 execution payload 的话,必须先购买 Execution Tickets 才能获得构建权利,具体到区块的构建权则是通过随机选取。这里 Execution Tickets 相当于是一个区块构建权的入场券。构建区块的权利仅需通过购买 Tickets 即可获得,而无需质押并成为验证者。

Execution Tickets 的估价约为原本 proposer 提议区块的机会成本。假设验证者的资金成本为每年 3%,而发行奖励为每年 2%。那验证者每年的机会成本则为 1%。假设以太坊一年有 2,628,000 个区块,以及 890,000 个验证者,那每个验证者每年被选为 proposer 的机会约为 3 次。即成为成为 proposer 的成本约为 32 个 ETH 的 0.33%,0.11 ETH。这就是一张 Execution Tickets 的近似价格。Ticket 的价格将根据流通数量进行动态调整,Ticket 也可转售给协议来减少流通数量。未使用的 Ticket 可以流通,但一旦 ticket 被分配给某个位置,就不可在一级市场转售,只能在二级市场流通。出售 Ticket 的费用如何分配,暂时尚未确定,可能会分配给验证者,也可能被销毁以实现 mev-burn 的愿景。

总体来说,Execution Tickets 创建了区别于 PBS 的另一种市场规则,在 PBS 中,创建了一个市场规则,让 proposer 按利润大小选择 builder 中提交的区块,而在 Execution Tickets 中,proposer 的职责相较于 PBS 则更为简单,proposer 只负责提议被选中的拥有区块构建权的 Execution Ticketss 持有者所构建的区块。验证者将不作为 MEV 激励的直接参与者。这会大大降低 proposer 参与时序博弈的动机。因为 proposer 无法从提议中获取额外利润。(但如果加入了 IL 可能就不同了)。但就区块构建者而言,由于区块构建权是需要购买 ticket 并且 ticket 的价格还会波动,但 MEV 实际获取利润的高低可能是不确定的,因此可能存在一定风险。

Execution Auction

与 Execution Tickets 的随机抽取 ticket 持有者来获取区块构建权不同,Execution Auction 会提前 32 个 slot 拍卖 slot 的区块构建权,价格最高者获得该 slot 的区块构建权。proposer 则负责提议该区块,attester 对 proposer 提议的区块进行见证并确认区块内容是否为竞价最高者所构建的。

在 Execution Tickets 中,可能会存在一个 execution proposer 购买多个 tickets 的情况来提高获取构建区块的可能性。但 Execution Auction 则是单 slot 单 slot 地拍卖。

Execution Auction 和 Execution Tickets 都是都是为了保证 proposer 职责简单化——对最终获得构建权的权利方来进行提议。Execution Auction 的好处在于能某种程度上实现 precomfirm。从实现的简洁性来看,Execution Auction 会优于 Execution Tickets,这里跳过了 Execution Tickets 需要考虑的随机性问题,从机制实现的角度而言,Execution Auction 可行性更高一些。如果要对比这两个提案的 trade-off 还可以从协议收益的角度或是从所有利益相关方来看,哪个方案可能更优。


http://www.kler.cn/news/283550.html

相关文章:

  • 金融涉案账户压降行动的实施成效与挑战
  • <WPF> xaml代码如何使用c#编写
  • 深入理解 Java 中 Map 和 Set 接口的高级用法
  • 【Rust光年纪】Rust多媒体处理库全面比较:探索安全高效的多媒体处理利器
  • Docker私有镜像仓库Harbor安装并推拉镜像
  • uniapp APP版本更新
  • easyExcel 填充写时,动态合并单元格
  • SQL视图:简化复杂查询的利器
  • Django+Vue社区养老管理系统的设计与实现
  • 光庭信息半年报:营收利润「双」下降,汽车软件业务竞争加剧
  • 揭晓9款敏捷团队必备的协作工具选择
  • MAC上Homebrew常用命令
  • LeetCode49题的反思
  • 基于事件总线EventBus实现邮件推送功能
  • 一些零碎的关于合约测试,ERC20调用的知识
  • 复杂工件的高效测量方案:自动化三坐标测量与影像测量技术集成
  • 工作中常用的100个知识点
  • DDR test Tool for imx9
  • [Android常见View的用法] RecyleView基本用法
  • 群晖7.2.1 半洗白后安装AME
  • Python(R)均方根误差平均绝对误差导图
  • helm学习第三篇--结合 springboot 单做
  • 深度强化学习算法(六)(附带MATLAB程序)
  • 正弦波振荡器工作原理及频率稳定性条件
  • 【JVM】OOM与调优(二)
  • C++ 设计模式——代理模式
  • 桥接模式-多类型登录方式的思考
  • C语言入门基础知识(持续更新中)
  • 预处理详解(二)
  • vscode链接到远程