摘要：
... ACDE （Consensus Direction Meeting）是由以币圈的所有核心开发人员每两个星期召开一次的会议，主要是为了商讨和协调对 ECE (Electronic Layer，执行层）的改动。本次会议为第188次 ACDE会议，在此会议中，开发人员将就 Ebitz的管理层变更问题展开协商与合作。
会议讨论的主要内容有： Pectra的 API新功能， Geth的最小化要求， Pectra的网络0,1的发展， Pectra的分支区域，历史到期时间等等。在此基础上，双方就 Pectra升级计划的范围、进度、具体执行等问题展开了深入的探讨和沟通。
银河数码调研公司的副总 Christine Kim提供了这次会议的要点摘要，由 BlockBeasts翻译成以下内容：
20245月23日， Ebitz开发者聚集在 Zoom，参与“所有核心开发者执行”（ACDE）呼叫#188。ACDE会议是一个由 Tim Beiko，以币基金会的协议支持负责人所领导的每周一度的会议，在这个会议中，开发者们将对 Ether EntityExecutive Layer （EL）的变化进行商讨并进行协调。本周，开发人员讨论了下列问题：
将允许用户访问事务的“返回数据”（returndata）的新功能添加到执行 API
吉思的最小优先级小费需求
光谱设备0和1
光谱分叉的幅度
门户网络的过期历史数据集成失败。
他们同意将 EIP 3074从光谱设备网络0中删除，并且将 EIP 7702包括在面向开发人员的下一代光谱更新测试网络1中。
向交易记录添加返回数据（Returndata）
CharlesCooper是 Vyper的开发商， Vyper是智能合同程序设计语言，他建议对 API的一个端点进行修改，以便当用户获得一笔交易的收据时也能收到它的反馈信息。Cooper解释道，现在开发人员获得反馈信息的方式，比如利用事务追踪，还没有得到统一的规范，也不能在每个客户机上得到广泛的支持。Cooper说，基于 Reth这样的客户小组对他的建议的回馈，替代的方法是在运行时 API中创建一个新的端点，用来获得事务的返回值（returndata）。开发人员在会议上没能就这个建议取得一致意见。Beiko建议，开发人员可以在 GitHub上进行讨论，然后在 GitHub会议以外的地方进行异步修复。
矿工最低服务费用需求
之后， Geth的开发人员佩特·兹拉吉表示，用户对 Geth的客户机缺省配置表示关注。从 EIP 1559开始， Geth客户机就一直为每一笔交易强制默认的最小优先级支付请求。在整合之后，1 gwei的预设优先支付不起作用了， Szilá gyi的小组最近才找到并解决了这一问题。恢复这个缺省值之后， Geth的用户会发现 Geth的客户机生成的数据块要比其它的数据块空白得多，因为 Geth的客户机会把那些很少有优先权的数据块剔除掉。这就引起了人们的担心，即缺省值会对区块提出者和建立者的动力造成不利的影响，因为缺省值会使不具有优先级的事务的处理变慢。
Nethermind的开发人员 Tomasz K. Staš czak说 Geth的缺省的“最小优惠”条款是不相关的，而且协议的开发人员不应该试图将其规范化或者实施。EF的研究人员 Ansgar Dietrichs认为，由于当前 Ebitra的交易成本很低，所以应该减少预设的最小优先级小费。另一些开发人员则提出， Geth系统中的预设最小优先级小费不应该是一个固定的数字，而是应该是一个基于基本收费的百分比。但是， Beiko不同意这个观点，他争辩说，“优先支付”不是一种收费，不应该包括在一项交易中。它只应当用来确定在接下来的块中是否要包括该事务，如果根据基本成本的变动来设置预设的最小优先级，则由于某项事务的价值会体现在优先级中，因此有可能会歪曲基本成本的变动。
Beiko还表示，还有一个问题值得探讨，那就是鼓励开发者创造无提示的区块，并给提案人额外的报酬。无论缺省的最小优先级注释需求是存在还是不存在，都会出现这样的情形，但是设定缺省值可以提供一种规范，以促使开发者不会建立零注释的区块。Szilá gyi认为，在某些方面，架构师们是否应将“无提示”的事务包括在一个区块链中，这是个很有哲理的问题。这些事务在网络的观点中是有效的并且因而应当包括在块中。然而，在财政激励论者的角度，包括无小费的交易不会带来任何财政上的好处，所以不应包括在内。
开发人员一般都同意， Geth小组应当设定默认的最佳值。如果认证节点操作人员想要改变此缺省值，则可随意改变此缺省值，或使用其它执行层客户机。
光谱设备网-0
Parithosh Jayanthi是一位来自以太坊基金（EF）的开发者和运营工程师，他在 Pectra网站上发布了最新消息。上周，在肯尼亚，第一个开发小组在一个名为 Nyota Interop的以太币协议开发人员线下会议上成立。Jayanthi说，正在发展的 Web包含了所有的执行和协商阶段的客户机。但是，EIP3074还没有经过严格的试验，有一些缺陷有待修正。客户端小组正在为第二个 ProgrammingWebPectraDevnet 1的发布做着准备，该版本将包含对EIP2935的修改。
光谱范围更改
之后，开发人员对 Pectra的升级内容进行了讨论。独立的以太币协议开发人员 Danno Ferrin, Reth开发人员 Georgios Konstantopoulos，以及 Solidity小组的成员都赞成将 EOF包括在光谱中。Geth的开发人员 Marius van der Wijaden说他是 EOF规格的执行者。但是，他也强调，因为 EOF的复杂程度，加入 EOF无疑会延缓光谱更新的启动。Lodestar和 EthereumJS的开发人员 Gajinder Singh在 Zoom的一次谈话中说，与其扩展 Pectra的功能，还不如集中精力开发 Pectra的最新版本。英孚研究人员亚历克斯·斯托克斯和佩普·梅里姆对辛格的观点表示赞同。
讨论完 EOF，开发人员又对EIP7702进行了介绍。EIP7702是由 EIP 3074的另一种选择，它是由 EIP 3074的共同创立者 Vitalik Buterin创建的。EIP 7702与它的可撤消设计一样，有许多关键的细节问题还没有得到解决。一名叫“dror”的开发人员在 Zoom的聊天中说：“EIP7002是EIP3074的升级版，以前EIP7002只能使用“非”和“链接 ID”。现在删除了它们，我们必须再来谈谈为什么。我建议再一次就这些约束进行探讨。Besu的开发人员 Daniel Lehrner表示，在EIP7702的设计问题上，他希望能从钱包的开发人员那里得到更多的建议。Erigon的开发者安德鲁•阿什克明强调说，必须有一条途径，使使用者能够在不使用自己的钱包的情况下取消对 Erigon的授权。
Beiko建议将 EIP 7002的实现的详细内容在另一个分组中进行。同时，开发人员同意将EIP3074从设备网络0移除并且将EIP7702添加到设备网络1。
预定添加到光谱中的其它两个 EIP为 EIP 7623和 EIP 7212，所述 EIP 7623提供呼叫数据的额外开销，所述 EIP 7212提供secp256r1的曲线的预先汇编。EF研究人员托妮·瓦斯特特在EIP7623和EIP7212上与我们进行了交流，EIP7212则是由一个名为 Ulaš Erdoç an的智能合同钱包开发人员提供的。开发人员并未就是否将这两项 EIP包括在光谱中取得共识。
光谱计划预计日期
Konstantopoulos指出了开发商在启动 Pectra更新时应注意何时在以太网上启动。Reth客户端小组在一次会议前共享的文档中表示，2024年以前推出新版本“毫无意义”，开发商应该在2025年早些时候推出新版本。在此之前， EF潘达项目小组（EF开发和操作小组的一部分）也共享了关于光谱计划和规模的意见。他们建议把光谱分为2个分支，其中一个分支将在本年度启动，而包含 MaxEB, EOF以及 peerDAS的另外一个分支将在下一年早些时候启动。Jayanthi说 EF的 Panda Ops小组没有达成一致意见，但是他自己觉得应该把光谱划分为两个部分。他注意到，还没有对 Pectra和 EIP之间的相互作用进行测试。
EF Solidity的开发人员 Alex Beregszaszi对此表达了自己的关注，他认为 EOF不能加入到光谱中，那么 EOF所做的修改就不能加入到 Eureketz的更新中。Geth的开发人员 Marius van der Wijaden和 Guillaume Ballet不同意这一观点，他们认为 EOF的优势是如此之大，以至于 EOF的可用性甚至可以推迟到更晚的时候。
Beiko建议在决定其他升级步骤之前，先就 peerDAS和 blob的大小增加的优先级问题达成一致。他推荐下周所有核心开发人员交流大会的开发人员将重点放在该主题上。他希望在 ACDE的下次会议上，开发人员能够完成光谱的最后工作。
