执行层会议 60

ethereum
发布于 2024-12-10 16:36
阅读 64

本次会议主要讨论了以太坊 Cancun 升级的潜在 EIP，重点关注 EIP-4844（blob 交易）、SELFDESTRUCT 操作码的移除（EIP-6780）以及与 SSZ 相关的 EIP。

## 执行层会议 #60
#### 会议日期/时间：2023 年 4 月 27 日，14:00-15:30 UTC
#### 会议时长：1 小时 30 分钟
#### GitHub 议程
#### 会议视频
#### 主持人：Tim Bieko
#### 笔记：Alen (Santhosh)

| 决策项目 | 描述 |
| --- | --- |
| 160.1 | **EIP 6780：** 更改 SELFDESTRUCT 操作码的功能，以便该操作将帐户中的所有 ETH 发送到调用者，除非在创建合约的同一交易中调用该操作码。 |
| 160.2 | **EIP 6475：** 一种新的简单序列化 (SSZ) 类型，用于表示可选值。这使得 EIP 4844 的实现与即将到来的更大的以太坊 EL 的 SSZ 更新更加兼容。 |
| 160.3 | **EIP 1153：** 添加新的操作码来操作状态，这些状态的行为与存储操作码相同，但在每次交易后都会被丢弃。 |
| 160.4 | **EIP 6913：** 引入 SETCODE 指令，该指令允许合约替换其代码而不清除其内部状态。 |
| 160.5 | **EIP 6493：** 定义了 SSZ 编码交易的签名方案。这也将有助于使以太坊与即将到来的更大的 SSZ 更新更加兼容。 |
| 160.6 | **EIP 4788：** 在 EL 区块头中公开信标链区块根，以允许在以太坊虚拟机 (EVM) 中进行 CL 状态的证明。这将提高Staking池、重新Staking结构、智能合约桥、MEV 协议等的信任假设。 |
| 160.7 | **EIP 2537：** 添加 BLS12-381 曲线作为预编译，以有效执行 BLS 签名和 SNARK 验证等操作。这些操作对于包括账户抽象、Layer-2 rollups 和 CL 轻客户端开发在内的各种应用程序非常有用。 |
| 160.8 | **EIP 5656：** 引入了一个新的 EVM 指令，用于复制内存区域，以提供构建数据结构和在以太坊上部署计算密集型操作的有效方法。 |
| 160.9 | **Big EOF：** 一系列 EIP，本可以对 EVM 进行全面改进，其中主要改进之一是将代码与数据分离。 |
| 160.10 | **EVMMAX：** 与 EOF 实现相关的一组 EIP，它为模块化算术参数和内存空间创建新的存储逻辑，以将这些参数中的值移入和移出 EVM。 |
| 160.11 | **SELFDESTRUCT 弃用：** 开发人员同意在审计结果在一个月左右准备好后重新评估 EIP 6780 的候选资格，并考虑是否将 EIP 6780 与 EIP 6913 捆绑在一起。无论结果如何，Dankrad Feist 和 Andrew Ashikhmin 等开发人员都申明，为将 EIP 6780 纳入 Cancun 所做的努力将与为准备 EIP 4844 所做的努力正交且独立，这意味着 EIP 6780 不会延迟或对 EIP 4844 的进展产生负面影响。 |

### 介绍
**Tim Beiko**
* 大家好。欢迎来到 ACDE #160。我刚刚在聊天中发布了议程。我想我们今天应该做的最重要的事情是，讨论 Cancun 的潜在 EIP，是的，在 4844 成为我们正在做的主要事情的背景下。然后在 4844 的最前沿，我认为有两个对话，我们想继续进行。一个只是关于 blob 交易的重组，重组处理。
* 其次，我知道我们本周一直在进行最后的 4844 **devnet**，所以我们可以分享一个关于它的更新以及它的进展情况。是的，我想也许为了开始，关于 Cancun 方面，到目前为止我们只有 4844，它被包括在内。
* 我们还有一堆其他的东西，以前是 CFI，还有一堆其他的，甚至更多其他的被提议了但仍然没有完全 cfi。我在 Eth magicians 上整理了一个列表。但也许为了开始，我很想听听来自不同客户端团队的意见，比如你们都认为在 Cancun 中最重要的事情是什么？
* 是的，我们可以从那里开始。我知道，我认为 Nethermind 可能是唯一一个之前回答过 Async 的人，所以也许从 Nethermind 开始是有意义的，然后其他人可以加入。

**Lukasz**
* 所以，我认为这或多或少就是我们在 Eth magicians call tread 上回答的内容，所以绝对是 4844。绝对地，我们看到了 6780 的需求。还有什么？ 1153。我们希望继续这样做，因为这已经从上海推迟了，而且已经准备好了。所以，我不认为有很多努力要把它推出去。
* 我不认为有理由延迟它。然后在更多可能的状态中，2537、4788 和 5920，而像 EOF 这样更大的东西，更多关于 SSZ 的东西，如果它们不是必需的，并且认为像 EVM max 这样的东西，我会考虑用于接下来的一些硬分叉。

**Tim Beiko**
* 知道了。谢谢你。

**Matt**
* Tim，我是 Matt。我认为从 Besu 方面来看，实际上与我们几乎完全一致。我们对这个列表有非常相似的想法，可能除了 4788 之外，但除此之外，它与 Nethermind 提供的列表几乎相同

**Tim Beiko**
* 你对 4788 有什么看法？你认为它比 Nethermind 说的更重要还是更不重要？

**Matt**
* 这很相似，就像在方面，你知道，我们认为它非常有用，但是范围方面，你知道，可能与像 weekly support 类似的一类。

**Tim Beiko**
* 好的。Geth、Aragon 有人吗？

**Andrew Ashikhmin**
* 是的，对于 Aragon 来说，重要的是获得 6780，即 self-destruct 的移除，而且，我认为与 4844 一起交付 EOF 是不现实的。所以我会将 EOF 推迟到 Prague。是的，现在，否则我认为我们可以做一些更小的 EIP。

**Tim Beiko**
* 好的。除了 self-destructed 4844 之外，你还有什么偏好吗？

**Andrew Ashikhmin**
* 没有偏好。我可以问团队成员更多，但我认为我们还没有强烈的偏好。

**Tim Beiko**
* 明白了。谢谢你。Guests？

**Peter**
* 是的，就我们而言，我的意思是我们还没有真正考虑过，具体要发布哪些 EIP 或不发布哪些 EIP。就我个人而言，优先事项是发布 4844。所以，在我看来，除了它之外，任何大的东西都是不现实的。考虑一下 EOF，更小的东西。我的意思是，self-destruct 肯定，以及任何其他更小的东西。
* 我不一定认为这有什么问题，但我有点觉得 4844 应该是每个人关注的事情，其余的有点像是锦上添花。

**Tim Beiko**
* 明白了。谢谢你。所以似乎，是的，从这四个来看，显然 self-destruct 是第二重要的，或者说，是第二个被提及的 EIP，仅次于 4844。而且，关于 6780，我们已经聘请了一家审计公司来分析它对链的影响。所以在接下来的几周内，我们也应该有一些数据，比如哪些合约可能会受到影响等等。但我认为这可能是值得正式包含的一个。
* 我看到 Danny 和 Lightclient，你们都举手了。是的，如果这是关于 self-destruct 的，请继续，否则我认为这可能是我们在深入研究其余内容之前可以完成的一个。好的。所以我想，有人反对包含 6780 吗，所以这个 self-destruct 和这个版本是允许 self-destruct，只有当它与创建调用位于同一个交易中时，否则你实际上使用像 sendal 这样的语义，你只是返回资金但不销毁合约。

**Danny**
* 这是否取决于分析没有发现我们还不知道的任何东西？如果我们发现了，我们至少会开始讨论吗？

**Tim Beiko**
* 是的，我想值得强调的是，还有另一个关于 self-destruct 的提案略有不同。我认为 Acik 把那个放在一起了，它是你做一种虚假的 self-destruct，你实际上隐藏了存储和数据，但你不，你不把它从状态中删除。是的。
* 而且，是的，那将是另一种前进的道路。看起来人们现在不太喜欢它，但是，是的，我想我很想知道，是的，来自客户端团队，有人对 Danny 的问题有什么看法吗？就像如果我们发现什么，什么会是我们发现的，你知道，可能会阻止我们这样做？

**Danny**
* 我不知道，William，我的意思是，我很难说，我只是，我只是承诺在这个调用中重新审视报告。是的，这似乎是做报告的目的，你知道，一个是给社区提供信息，一个是让其他人给我们提供信息。因此，我只想，如果我们现在继续这样做，就承诺一起查看报告。

**Tim Beiko**
* 是的，我认为我们肯定会这样做。我想问题是，人们是否想在报告发布之前做出这个承诺，或者，我认为这可能需要大约三四周的时间。所以，比如，你知道，从现在开始一个月左右，我们可能会知道，人们是否更喜欢从现在开始一个月后再做出那个决定？

**Lightclient**
* 我认为如果每个人都同意，现在做出决定是有意义的，然后在报告发布后重新审视它。

**Tim Beiko**
* 有人不同意吗？我知道 Dankrad，William，你们都举手了，所以如果这与 self-destruct 有关，请。

**Dankrad**
* 我的意思是，我只是想说，很难相信报告会什么都找不到。就像，我认为我们很可能会在某个地方找到一些合约，这些合约会以某种方式被破坏。问题是，我们是否对以下情况做出判断，是的，杀死该合约，因为我们认为它的价值太低，无关紧要，或者所有者可以做其他事情并挽救他们的资金等等。就像，基本上，是的，就像，我的意思是，这很可能我们会发现一些东西。
* 我想说的是，是的，我的意思是，如果我们现在开始构建一些东西，并且我们看到有机会，即使讨论可能都不会朝着我们无法做到的方向发展，但可能会因为我们需要与很多人交谈而被推迟，那么我们可能应该以这样一种方式来设计它，以便我们可以以没有该实现的方式进行转移。我认为这在很大程度上应该与 4844 相关。但是的，这就是我的评论。

**Tim Beiko**
* 明白了。谢谢。Lightclient 或 William，你们想补充什么吗？

**William**
* 是的，所以我们正在阉割 self-destruct，因为移除所有帐户存储的范围是无限的。在我们的垂直树中，问题变得更糟，因为垂直树是扁平的，但垂直树实际上并不阻止代码更改。因此，如果修改了 self-destruct，我希望保留帐户保留更改其代码的能力，并改进执行方式。在我的职业生涯中，我曾与三种不同的升级模式进行过交互。我编写了一些最早的合约，可以使用委托调用进行升级，并且我编写了一个帐户所有权系统来方便 self-destruct 升级。
* 我的建议是设置代码，以保留该能力，如果我们必须从 self-destruct 中删除它。也就是说，如果我们不这样做，Axes 的提议只会将螺母更改为帐户并将其用作标记。因此，设置代码通过更改，允许一种创建清晰存储的方式，或者在更改帐户时不清空存储，从而改进了 self-destruct 升级模式。因此，我们不想能够清除存储，因为这是无限的。因此，它只是简单地提供了一种以安全方式更改代码的方式。它与所有其他当前的升级模式一样安全，并且应该是一个简单的更改，可以添加到任何 self-destruct 移除中。

**Tim Beiko**
* 所以这个设置代码，只是为了确保我理解，你可以更改帐户中的代码，但不能更改存储。正确。这意味着你可以拥有一个合约，其语义，你知道，它更改了语义，但是，保留了以前的存储，对吗？

**William**
* 是的，这是正确的。而且，这优于当前的 self-destruct 升级模式，因为没有执行开销。委托调用仍然有用，因为你可以使用它来绕过帐户代码大小限制。因此，如果你需要一个合约，或者一个帐户，其实施代码为 10 万字节，你可以只需使用委托调用将其分布到多个合约中。但是，如果你需要，替换帐户本身的代码，那么这会保留该功能，没有执行开销的好处至关重要。
* 如果没有它，许多用户可能会为了节省 gas，而更喜欢迁移他们所有的 token，例如，创建一个新帐户并将他们所有的 token 所有权和身份转移到新帐户。这不好。例如，如果你是一个 dex，并且想要更改你的代码，又不想产生调用另一个合约所需的 gas 开销，

**Dankrad**
* 是的，我理解开销的论点，但是，从功能上讲，我不知道，比如如果我们能够减轻开销，我们应该更多地考虑开销，但是，通过这种 self-destruct 停用，在同一个地址上始终具有相同的代码或没有代码，可能会带来许多可能的未来优势，这些优势目前不存在，或者将来可能存在。所以我喜欢你，我们应该权衡一下这一点，与的好处。

**Tim Beiko**
* 我觉得，拥有，我认为 Axe six，不是当前的 self-destruct 提案，而是之前的那个，如果我没记错的话，实际上具有相同的语义。而且我们，所以基本上它会允许你在该地址重新创建合约，但是，它不会在此期间更改存储。这样做面临的挑战是，人们担心类似他们的攻击风险，你知道，你部署一个智能合约，然后，你知道，人们以某种方式使用它，你对其进行更改，你可以保留现有存储，你知道，可能会更改合约的整个功能。因此，我不知道，**我很好奇，是的，其他人对此有何看法。因为它有点像几个月前我们进行的讨论，除非我记错了这个问题。

**Andrew Ashikhmin**
* 我认为，从每个人的角度来看，我们都想避免拥有多个版本的 self-destruct 移除版本，因为我们已经有了那些场景，我们称之为化身，它们使代码变得非常复杂。因此，除非我们绝对必须这样做，否则我更喜欢更简单的解决方案，就像在我看来，6780 是简单性和有限的向后兼容性之间的良好折衷方案。
* 因此，也许我们可以等到报告出来，然后我们可以重新考虑一下，但是我们可以暂时同意我们正在包含某种 self-destruct 移除变体，例如 6780，如果与此同时其他人提出了不同的建议，我们可以重新审视这一点。这在很大程度上与 4844 无关，因此我们可以几乎独立地重新审视它。

**Tim Beiko**
* 好的。我想这与 light client 所说的有点一致，但基本上我们将包含 6780，当我们收到报告时，我们可以分析影响，看看是否值得对规范进行重大更改。但是，你知道，今天基本上做出那个承诺，你知道，如果我们看到什么，可能会更改 EIP 的实际语义。但是，从高层次的，你知道，设计角度来看，似乎所有客户端团队都赞成做出这个改变。这样说有道理吗？

**Andrew Ashikhmin**
* 是的，对我来说是的。

**Tim Beiko**
* 任何，好吧。任何，我想最后的机会，是的。

**William**
* 因此，代码可变性不会对用户空间产生太大影响，因为代码仍然可以通过代理基本上进行修改。但是，从 Aragon 方面来看，这样做有什么优势？你说它使你的实施变得复杂。当状态、路由和所有内容仍然应该起作用时，怎么会这样？

**Andrew Ashikhmin**
* 好吧，只是，我们有这个额外的每个参数的化身，因此除了帐户地址之外，我们总是携带这个化身，我们必须，例如，必须确保，在重组的情况下，我们应该到达，就像所有不同的节点都应该到达相同的化身或帐户代码版本，否则如果它成为状态的一部分，那么你可能会有不同的状态等等。因此，一切都是可行的和可行的。这只是一个额外的复杂性。问题是，这个额外的复杂性是否值得，但我认为如果，如果有另一个，比如你说我可能错过了重点是你是否在说已经有另一种方法解决了，那是一个更好的选择，或者你是在谈论你脑海中的一个新想法？

**William**
* 因此，由于创建和创建两个，帐户代码已经可以在重组时更改。因此，当那些被重组时，帐户代码也会更改。

**Andrew Ashikhmin**
* 是的，但是，如果移除 self-destruct，我们将不会有这种情况。

**William**
* 我特别是指设置代码，作为一种维护 ca 代码可变性的方式。

**Andrew Ashikhmin**
* 并且，它是 EOF 的一部分吗，还是你的一个新功能？有什么想法吗？

**William**
* 它是 EIP 6913。

**Tim Beiko**
* 因此，我想，显然我并不认为大多数客户端团队的人都非常熟悉这一点。也许我建议这样做，我们将在一个月后当我们收到报告时继续推进 6780。
* 显然，我们将不得不重新评估这一点。我认为这也可以让人们有时间阅读 6913，我们可以，你知道，同时做出决定，就像，我们是否想根据报告更改 6780，我们是否想将 6913 与其一起添加。但是，似乎所有团队都非常支持，你知道，继续进行 self-destruct 移除。而且我们可能没有足够的信息来超越这一点，是的，今天，所以我想，是的，有人反对包括 6780 吗？
* 我们重新审视报告，或者重新审视，对不起，在一个月后收到报告时。与此同时，我们也可以查看 6913，并从中开始。好的。Marius 有一个基本上说我也会做同样事情的评论。太棒了，让我们这样做。
* 我将在这次通话后更新规范，但是 6780 包含在内。并且只是为了实施人员，请注意，你知道，可能会对此规范进行更改，具体取决于分析的结果，以及你知道，人们在未来几周内阅读 6913 等内容。是的，感谢 William 也分享你的观点。
* Light client 和 Charles，你们都举手了，而且已经举手很久了。哦，现在 Danny 也举手了。

**Lighclient**
* 是的，我想，是的，对不起，我只是想，是的，我只是想在我们在讨论 self-destruct 之前说一些关于 Cancun 的一般 CFI EIP 的事情。而且我很想认真地看看这些 SSZ EIP，因为我不想陷入这样一种境地，即我们为了 4844 而做任何绝对最快的事情，并打算在之后的分叉或两个分叉中更改它。因此，我确实认为重要的是，尝试弄清楚可以完成的最小工作量是多少，以便它与这个作为 SSZ 世界的未来兼容，因为这是我们几年来一直在讨论的事情。而不是仅仅在 RPL 或 hackmd 中发布一些东西

**Tim Beiko**
* 是的。我认为现在讨论它可能是有意义的，因为如果我们有 4844，它已经很大了。 self destruct 是一种中等大小的 EIP，如果确实需要进行一些 SSZ 更改，那么在决定做其他任何事情之前，最好先了解一下这些更改是什么。是的，我看到，我不知道，你和 Etan 都举手了。你们中的任何一个想分享你们的想法吗，你知道，我们应该作为 Cancun 的一部分进行的最小或最佳更改集是什么？特别是考虑到 4844 是升级的维护者。

**Andrew Ashikhmin**
* 因此，绝对应该研究的两个 EIP 是 6493 和 6475。第一个，6 4 93，定义了签名的计算方式，以便它们不会与可能为相同交易类型使用 RLP 的其他链冲突。另一个 6475，是一个很小的。
* 它只是定义了我们希望如何表示可选值，因为 4844 有一个可选地址，用于交易的目的地。现在它们在任何地方都不存在，我们应该决定它们应该像今天的联合一样，还是应该更紧凑或其他什么。
* 其余的，区块内部的那些树如何通过试验、收据和交易来构建，我们也可以稍后做，这对 4844 兼容性来说并不重要。就像，6493 与规范化交易方法和 SSZ 联合方法都兼容。所以这一个，就像这三个，它们不是 Cancun 的必需品。我们可以稍后做，没有任何缺点。

**Tim Beiko**
* 知道了。谢谢你。Andrew，我看到你举手了。

**Andrew Ashikhmin**
* 是的，关于 66475 SSZ 的可选问题。因此，如果我理解，如果我们在 Cancun 中采用并实施它，那么会影响 4844，对吗？因为 4844 有一些可选的，两个地址是可选的，对吗？在 SSZ 交易中？

**Etan (Nimbus)**
* 是的，完全正确。我的意思是现在它们被定义为使用联合类型，但从语义上讲，它们应该是可选的。它们可能以我们想要的相同方式序列化，但也可能存在一些小的变化。因此，至少我们需要保持一致，并将它们同时切换到新的表示形式，以便我们保持兼容。

**Andrew Ashikhmin**
* 那么是否有人认为将来我们需要 union 并在其中声明零？因为如果我们不需要，那么我认为仅仅针对可选值采用这种更有限的解决方案是有意义的。

**Etan (Nimbus)**
* 现在我们不使用它们。将来可能会有一些设计使用它们，但无论如何，可选值是一种更受限制的类型，因为它只能是 none 或 some，对吧。但 union 是一种更复杂的类型。因此，例如，在 Nimbus 实施中，这两个是非常不同的代码路径。但当然，也可以将可选值编码为 union 的一个特例。
* 因此，这只是一个语法的确保让读者清楚地知道它的含义。现在，6475 与 union 不兼容，因为它不发出选择器，而是使用长度，如果它是空的，它是 none，否则它是 sum。但是 union 也用于序列化，我认为它有点 underspecified，因为它没有定义如何序列化非值。所以是的，今天不使用 union，但如果我们需要它们，我们也需要决定我们希望它们看起来如何。

**Dankrad**
* 当然，抱歉，我认为它已经指定好了。我认为它只是选择器等于零并且估计值

**Andrew Ashikhmin**
* 好的。像这样，0 和 10，我想之后没有别的了，是的。

**Dankrad**
* 是的。因此，一个想法是，就像如果我们真的喜欢，如果我们只是保持开放的选择，我们可以简单地实施，如果目前没有人使用 union，那么我们可以按照你指定的方式实施可选值，并打算如果我们稍后引入 union，我们将使它们成为可选值的超集。

**Andrew Ashikhmin**
* 好的。那么区别在于，我想 6475 需要进行更新，以便允许将来扩展多个案例，但例如，非值可以简化为只是空值，例如那里的零不提供任何值，但 sum 会有一个前导 1，对吗？这将是最小值。

**Dankrad**
* 可能是的。我的意思是理论上你甚至可以不必，对吧？你也可以说，如果只有两个选项，比如 none 或 something，那么你也不需要添加 1，对吧？

**Andrew Ashikhmin**
* 这是真的。是的。如果它是 none，而另一个选项，

**Dankrad**
* 我想你必须保证这一点。是的。那么你需要，好吧，我想你需要做一种特殊情况，即第二部分是非零长度。我不知道是否总是保证这一点，也许总是保证这一点。是的。有些事情需要仔细考虑，但有可能使 union 成为你已经指定的内容的严格超集。

**Andrew Ashikhmin**
* 是的。另一个问题是，当你更新规范时，比如当一个分叉向 union 添加另一个案例，并且你从两个变为三个时，你将无法再使用旧值进行分析，是的，这实际上是一个好点。

**Dankrad**
* 是的，这可能是添加 1 的一个优势，因为这意味着你可以更轻松地使用其他选项升级现有的 SSZ 字段，对吧？

**Andrew Ashikhmin**
* 是的，完全正确。因此，我将更新 6475，以便在 sum 案例中包含 1，并且在 none 案例中我保持为空，然后也更改现有的以使用此时间。

**Tim Beiko**
* 因此，如果我们对 6475 进行这些更新，我们是否完全满意它的状态？我们应该考虑，我们应该包括它，你知道，在进行这些修改之前？

**Andrew Ashikhmin**
* 我想是的。

**Tim Beiko**
* 好的。所以有人不同意吗？

**Andrew Ashikhmin**
* 并且我认为，我们还需要更新 4844 以使用 6475，对吗？对于可选的，寻址。

**Tim Beiko**
* 是的，我相信至少有一半（如果不是全部）的 4844 作者都在这次通话中。因此，如果其中一位可以在我们完成 6475 更改后，对 6475 进行 PR，那就太好了。好吧，6475 就是这样，然后是 6493。因此，签名方案，我想这也是我们必须包括的。
* 抱歉，我正在努力阅读评论。是的，所以我想，好吧，所以是的，有人反对 6493，即 SSZ 交易的签名方案吗？

**Lightclient**
* 这是否会创建交易 ID 与交易哈希这两个概念，还是仅与签名有关？

**Andrew Ashikhmin**
* 它还包括交易 ID 的概念。

**Lightclient**
* 是的，我已经有一段时间没有研究这个了，但我记得我非常反对通过这个交易 ID 概念来引用交易，并且它与交易哈希不同。

**Andrew Ashikhmin**
* 我的意思是，它是一样的，就像它不是一个 catch，而是一个哈希根，对吧？

**Roberto B**
* 一个缺点是，它现在涉及将 ssy 的非规范化方面引入执行层，而现在我们还没有那个小东西，但是，是的。

**Lightclient**
* 但我认为我们需要它最终。

**Tim Beiko**1
* 是的。

**Tim Beiko**
* 好吧，我想这可能是一个愚蠢的问题，但是如果 4844 交易类型是 SSZ 交易，我想它的签名方案是作为 4844 的一部分定义的。

**Roberto B**
* 现在它只是带有前缀类型的实现。

**Tim Beiko**
* 知道了。抱歉，我听不清你在说什么。我打断了你。

**Lightclient**
* 不，我只是在思考。

**Tim Beiko**
* 好的。因此，我认为抱歉，我认为我在这里有些误解了。我以为这也是 4844 的一种要求，但似乎并非如此。

**Lightclient**
* 因此我们可以继续前进，我的意思是，我们现在有 4844 的实施，但我认为以正确的方式做事是最好的，而且我们实际上没有对 SSZ 序列化值进行哈希处理的概念。我认为这有点奇怪。因此，这就是为什么我们一直在讨论拥有哈希树根的原因，但是一旦我们开始拥有哈希树根，我们就开始遇到其他问题，比如，我们如何，你知道，使签名方案安全？

**Andrew Ashikhmin**
* 此外，对于 6404，如果我们稍后使用基于 SSZ 的交易，那么它将有 Tier 8，即那些哈希和 ID 匹配，如果我们从 Geth 开始以正确的方式做。如果是规范化的方法，老实说并不重要，因为哈希无论如何都是树中的一个单独的叶子。所以是的，也有这个小优势。

**Tim Beiko**
* 因此，我认为也许这里的一个好的下一步是，我们在周一进行 4844 通话。是否有可能在周一之前，在那个通话之前，完成 6475 和 4844 中的更改，以便人们可以在周一之前查看它，并在 4844 的背景下讨论 6493，并且基本上，你知道，在那个通话中对齐这两者。
* 好的，我看到周一是假期，Etan 是谁。是否有其他人你认为可以加入并为 EIP 辩护？

**Andrew Ashikhmin**
* 我的意思是，主要是为了审查，对吗？是的。6493，对吗？

**Tim Beiko**
* 是的，是的。

**Andrew Ashikhmin**
* 就像，我们必须在通话期间进行审查，还是我们可以只是，

**Tim Beiko**
* 因此，我想，是的。是的，而且我们绝对不应该在不包括它的情况下在 4484 通话中做出决定，但我认为，是的，如果人们想审查它，我们可以在周一的通话中进行，你知道，第一次对话，至少，是的，如果人们在审查期间有疑问或想法，我们可以在那里解决其中的一些问题，但似乎人们没有足够的背景信息来在今天做出关于此的决定。好的。
* 让我们这样做。因此，让我们包括 6475，如果 Ethan 可以在周一之前进行更改，那将是太棒了。我们还需要对 EIP 4844 进行更改，以反映这一点，如果人们想讨论更多，我们可以在周一的通话中提出这个问题，并且两周后 हम 可以希望在这次通话中做出最终决定。
* 好的。关于 SSZ 还有其他想法、担忧吗？好的，Daniel，你举手了很长时间了。只是不小心举起来的吗？

**Danny**
* 哦，对不起，我。是的。是的。我只是想在开始时当我们从客户团队那里获取信号时说，跨层的 4478 得到了共识层团队的支持，你知道，看到它具有适度高的优先级，以开放无信任池设计并降低在执行层中创建池的门槛。
* 并且人们愿意接受它。显然它是跨层的，所以需要双方合作。我只是想确保这里浮出水面了这些信息。

**Tim Beiko**
* 知道了。谢谢。是的，我认为实际覆盖这个问题和 BLS 预编译可能是有意义的，因为在过去，我的意思是 BLS 的情况是几年，而在 4788 的情况下至少是几个月，我们已经谈论了很多。是的，我想我很想听听来自像 EL 客户团队的意见，似乎大多数团队都有胃口，你知道，可能除了 4844 self-destructed 之外还添加一两个较小的 EIP，现在，一些 SSZ 更改，但是，你知道，我想 4788，BLS 或者是，我知道 1153 是另一个经常出现的，就像，是的，人们认为如何在这些可能较小的 EIP 之间进行优先级排序，以及人们是否感到必须拥有或，你知道，非常重要的事情？

**发言人 0**
* 是的，我不会说我们认为 1153 是必须拥有的，但我们基本上仍然非常强烈地支持它。

**Tim Beiko**
* 好的。这是否意味着如果它已经完成，你会优先考虑它而不是像 4788 这样的事情？

**Matt Nelson**
* 因此，这主要是测试开销。明白了。至少要按压力量。情况并非如此。

**Tim Beiko**
* 知道了。然后 Marek 有一个评论，我想也说 1153 对他们来说会稍高一些。**Andrew Ashikhmin**
* 好的，我想，我们会做5920。这是一个简单的可用性改进。是的。

**Tim Beiko**
* 好的。所以我想这就是我们讨论4788、2537和1153的地方，这三个我认为是中等优先级的，一些客户端团队至少对此感觉强烈。我不确定我们今天是否需要就这些做出决定，
* 但是，我很好奇，是否有人可能乐于说这就是Cancun的全部范围，也许我们可以做的就是从CFI中删除所有其他内容，除了这三个，即1153、2537、4788。当我们开始处理DevNet和实施其余EIP时，我们可以重新审视这三个，是的，我看到了，是的，所以，是的，我想我们从这里开始。
* 是否有人乐于现在将此CFI限制在这三个提议上，这意味着基本上删除所有EOF内容，我认为这是CFI中唯一的其他内容。好的。然后，是的，聊天中有一些关于其他小型操作码的评论，也许我们将来也可以添加这些，但至少我认为我们可以删除EOF内容，是的，保留这三个。所以11 53、25、37 已经是cfid。我们可以考虑47 88。
* 然后，如果出现一些小的事情或其他补充，我们可以决定。我知道Charles，你举手很久了，想谈论其中一件小事，如果你想继续，我们可以这样做，然后给人们提供背景信息。

**Charles C***
* 当然。这实际上是我第一次参加ACD会议，所以我不知道规则是什么，好的，协议是什么，但我不想破坏一切，但首先，我认为1153和5920非常有用，如果你们已经在讨论这个了。
* 所以我想提出mcopy EIP 5656，从编译器的角度来看，它非常有用。它可以让我们减少大量的样板代码，而且拥有它也很有意义，有调用数据复制，有代码复制，甚至有X代码复制，但没有mem copy，我不认为关于规范或其有用性存在任何争议。甚至在Geth上还有一个开放的门户请求来实现它。
* 而且它看起来很简单，所以我不认为会有任何问题，是的，它会非常有用。

**Tim Beiko**
* 好的。谢谢你。所以我想我们可以，是的，我们可以把它放在列表中，我们可以潜在地，或者我们，你知道，让人们看看它，并在另一次会议上进行CFI，当大家有时间审查它时。一般来说，我们尽量不在第一次展示时就对某件事进行CFI，这样人们可以有一些时间来消化它。
* 但是，我看到你发布在Eth Magicians thread中了，所以人们可以在那里查看它。Andrew，Daniel，我看到你们都举手了，先是Andrew。

**Andrew Ashikhmin**
* 好的，我只是认为，因为我们已经定义1153很长时间了，并且我们把它从上海移到了坎昆等等，而且它似乎是一个小型EIP，大多数人都赞成。我认为把它包括进来是公平的，否则我们只是，是的，我们已经，已经有很多机会让人们去了解它，而且我们普遍认为它是有意义的，所以为什么不呢？而且它足够小。

**Tim Beiko**
* 是的。有人反对吗？确实如此。它已经被讨论了很长时间。我知道有些人从设计的角度来看是反对的，但是，现在看来大多数客户端团队都赞成。
* 是的。有人反对吗？好的，所以我想，所以我们，好吧，这意味着我们将1123与上海一起包括在内，以及4844和自毁以及小的SSD更改，以及人们之前提到的其他两个潜在的权衡，即4788，这些将被cfid，但暂时不包括在内。这对大家有意义吗？好的。所以我们也可以将1153移到包含的列表中，Daniel，我看到你举手了。

**Danno Ferrin**
* 是的，所以我支持将EOF从Cancun中移除。这将给我们更多的时间来解决一些核心的深度问题，对吗？我们仍在研究关于Geth可观察性是否应该包含的问题，以及关于create应该如何处理的问题，以及其他一些问题，将其从Cancun中移除可以缓解很多时间压力。
* 这样我们就可以专注于把它做好，而不是准备好在第三季度发布。尽管这很让人难受，但我认为这是一个正确的决定。

**Tim Beiko**
* 好的。Ansgar？

**Ansgar**
* 是的，我总体上赞同这种观点。我只想说，因为我认为为长期路线图设定一些大致的期望总是有帮助的。我个人更希望我们至少在事后能够以EOF为重点进行分叉，并希望在Cancun之后相对较快地进行，而不是试图将其与其他内容合并。
* 我知道，并且希望在Cancun之后9个月或更长时间再进行分叉。
* 这似乎是因为如果我们一直试图将其与其他重要内容合并，我认为它只会一直推迟，因为它太大了，基本上无法在分叉中占据第二位。所以我认为在某个时候我们只需要说，好吧，它会自行分叉，因为到时候大多数限制都将准备好，这将是一个快速的分叉。

**Tim Beiko**
* 是的。所以，我认为这样考虑是有意义的，我不想让我们今天就强烈承诺某件事，因为我们甚至还没有Cancun的实现。但是，是的，似乎EOF和垂直树是接下来两个潜在的重要内容，EOF可能更小且进展更快，这几乎就像我们对合并和提款所做的那样，你有一个包含4844的大型分叉，然后是一个包含EOF的小型分叉。所以，是的，我们肯定可以讨论这个问题。
* 我认为，就像我们对Cancun有一个清晰的蓝图一样，这可能是需要做出的最高级别的决策，这样我们就可以让团队并行工作。Lucas？是的，要清楚的是，我并不是说EOF很小。我是说，尽管提款并非微不足道，但如果你有合并和提款，合并比提款大得多，而且感觉我们与484和EOF有类似的情况，4844更大。显然，实际上与EOF的组合不太可能，是的，EOF也很大，也许可以是一个较小的重要内容，基本上是下一个分叉。是的。Greg，哦，Greg，你静音了。

**Greg**
* 我想重申，我们承诺在某个时候将EOF纳入其中。基本功能与我在2016年提出的EIP 615相同。所以我们已经讨论了七年了。是时候了。我认为我必须要做一些我想在EVM上做七年的工作，但在它加入之前我无法做。

**Tim Beiko**
* 是的，我的意思是，我认为所有客户端团队都非常支持EOF，但EOF太大了，无法与Cancun一起包含。我认为我们能做出的最强烈的承诺是将其作为下一个分叉的主要内容。但即使是这样，我们今天也可能无法百分之百地同意。聊天中也有一些相关的评论。是的，好的，所以我认为我们已经涵盖了几乎所有提议的EIP，也许可以简单地回顾一下，我们最终达成的共识。所以4844显然是Cancun的一部分，包括在内。6780。这是一个自毁移除EIP。我们也同意包含这个，在一个月左右的时间内，当我们发布影响分析时再对其进行审查。同时，我们也可以看看set code EIP，即6913，然后我们同意包含6475，即SSZ可选类型。
* 仍然需要对它进行一些更改。Etan将在未来几天内完成这些更改，我们将更新4844以反映这些更改。最后，我们同意将1153也包含在内。所以这将是Cancun的当前范围。我们已经，好吧，2735，BLS已经是cfid，它仍然存在。Liz 4788。
* 我们也对其进行了CFI，然后我们从cfid中删除了所有EOF EIP，这基本上是，哦，是的，我们也应该对签名方案进行CFI。6493。但我们还没有完全同意。这对大家有意义吗？好的。
* 好的。是的，所以在周一的会议上，我们可以在周一的会议上更多地讨论6493 EIP。然后两周后，我们可以再次在这里提出它。

### EIP-4844 blob re-orgs & newPayload(context) [50.50](https://youtu.be/ajLQVC3E_mk?t=3477)
* 好了，议程上还有两件事。首先是，也与4844相关，关于blob重组和新的payloads规范的对话。我知道Peter和Danny，我们上周在CL会议上讨论过这个问题。我不知道你们俩是否有任何更新，或者，是的，我没有更新。

**Danny**
* 我知道Peter想花更多的时间思考这个问题，我也知道可能其他没有过多考虑这个问题的人也想花一些时间思考这个问题。所以我们可以现在讨论，也可以在会议之前讨论。如果我们走这条路线，这将是对引擎API的重大更改。所以我们需要尽快解决这个问题，而不是以后。

**Tim Beiko**
* Peter，你有什么想法吗？你取消了静音，但我们听不到你说话。至少我听不到。哦，不，我们听不到。

**Peter**
* 所以本质上我想说的是，我正在研究4844，但不是这个特定部分，所以我真的没有任何更新。

**Tim Beiko**
* 好的。我们会看到。我们也可以在discord上继续讨论这个问题，因为它会出现的，但我们应该意识到这一点。是的，基本上，我们需要就这个设计达成一致。

### 4844 devnet-5 更新 [59.19](https://youtu.be/ajLQVC3E_mk?t=3559)
**Tim Beiko**
* 然后，我们议程上的最后一件事，是DevNet 5。本周在这方面有很多工作。我不知道是否有人想快速更新一下，分享一下目前的情况。

**Barnabas Busa**
* 当然，我可以做到。基本上，DevNet 5，我们上周五开始进行了driver on测试，然后在昨天进行了实际启动。主要的utc。我们正在使用1000个验证器运行它。我们有三个工作的CL客户端，lighthouse和Prism，以及四个左右的EL客户端。另一个是mine JS，以及everyone的分支和geth的分支。
* 目前我们有工作的block scout，相关的工具正在上线，我们还没有工作的BL扫描器，但希望它能在本周末上线。很好。我们目前不做任何fuzzing，但我对此持开放态度。而且，可能的时间表是，我不知道，一两周，也许更长，但我希望看到更多的客户端加入。你们是否还在运行dead net force？如果没有任何异议，我们希望在本周末关闭它。

**Tim Beiko**
* 似乎我们可以，是的。继续关闭它。是的，谢谢分享更新。还有其他人有想法吗？问题？

**Barnabas Busa**
* 我还在聊天中链接了如果你想参与所需的规范。

**Tim Beiko**
* 很好，谢谢你。好吧，我想就是这样了。今天还有其他人想聊些什么吗？好的，如果没有，那么我想，是的，下次会议，确定SSZ内容，是的，如果还有其他想讨论的小型EIP，这可能是开始考虑它们的最后机会。
* 是的，所以请将它们添加到Eth Magician thread中，这样我们就可以，是的，这样我们就可以跟踪它们。好的，谢谢大家。我们很快再和大家聊天。

* 谢谢你。谢谢你。谢谢你。

---
#### 出席者
* Tim Beiko
* Danny Ryan
* Pooja Ranjan
* Mikhail Kalinin
* Marius
* Wesley
* Barnabas
* Saulius
* Danno
* Lightclient
* Pari
* Ethan
* Mario
* Tomasz
* Oleg
* Kasey
* Marek
* Crypdough
* Fabio Di
* Terence
* Andrew
* Roman
* Marcin
* Pop
* Guilaume
* Protolambda
* Carlbeek
* Mike
* Gajinder
* Stefan
* Hsiao-Wei
* Josh
* Phil Ngo
* Alexey
* Holger Drewes
* Dankrad
* Guillaume
* Proto
* Holder Drewes
* Stokes
* Peter Szilagyi
* Sean
* Micah Zoltu
* Jiri Peinlich
* Marius Van Der Wijden
* Potuz
* Evan Van Ness
* Moody
* Tynes
* Alex Beregszaszi
* Marek Moraczyński
* Justin Florentine
* Ben Edgington
* Lion Dapplion
* Mrabino1
* Barnabas Busa
* Łukasz Rozmej
* Péter Szilágyi
* Danno Ferrin
* Andrew Ashikhmin
* Hdrewes
* Crypdough.eth
* Ameziane Hamlat
* Liam Horne
* Georgios Konstantopoulos
* Mehdi Aouadi
* Bob Summerwill
* Jesse Pollak
* Stefan Bratanov
* Sara Reynolds
* Caspar Schwarz-Schilling
* Ahmad Bitar
* Marcin Sobczak
* Kasey Kirkham
* Sean Anderson
* Saulius Grigaitis
* Ruben
* George Kadianakis
* Dankrad Feist
* Andrei Maiboroda
* Gcolvin
* Ansgar Dietrichs
* Jared Wasinger
* Diego López León
* Daniel Celeda
* Trent
* Mario Vega
* Kamil Chodoła
* Ziogaschr
* Kevaundray
* Antonio Sanso
* Oleg Jakushkin
* Leo
* Nishant Das
* Pote
* Sam
* Tomasz K. Stanczak
* Matt Nelson
* Gary Schulte
* Rory Arredondo

---

### 下次会议
2023年5月11日，14:00-15:30 UTC

>- 原文链接： [github.com/ethereum/pm/b...](https://github.com/ethereum/pm/blob/master/AllCoreDevs-EL-Meetings/Meeting%20160.md)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

执行层会议 #60

会议日期/时间：2023 年 4 月 27 日，14:00-15:30 UTC

会议时长：1 小时 30 分钟

GitHub 议程

会议视频

主持人：Tim Bieko

笔记：Alen (Santhosh)

决策项目	描述
160.1	EIP 6780：更改 SELFDESTRUCT 操作码的功能，以便该操作将帐户中的所有 ETH 发送到调用者，除非在创建合约的同一交易中调用该操作码。
160.2	EIP 6475：一种新的简单序列化 (SSZ) 类型，用于表示可选值。这使得 EIP 4844 的实现与即将到来的更大的以太坊 EL 的 SSZ 更新更加兼容。
160.3	EIP 1153：添加新的操作码来操作状态，这些状态的行为与存储操作码相同，但在每次交易后都会被丢弃。
160.4	EIP 6913：引入 SETCODE 指令，该指令允许合约替换其代码而不清除其内部状态。
160.5	EIP 6493：定义了 SSZ 编码交易的签名方案。这也将有助于使以太坊与即将到来的更大的 SSZ 更新更加兼容。
160.6	EIP 4788：在 EL 区块头中公开信标链区块根，以允许在以太坊虚拟机 (EVM) 中进行 CL 状态的证明。这将提高Staking池、重新Staking结构、智能合约桥、MEV 协议等的信任假设。
160.7	EIP 2537：添加 BLS12-381 曲线作为预编译，以有效执行 BLS 签名和 SNARK 验证等操作。这些操作对于包括账户抽象、Layer-2 rollups 和 CL 轻客户端开发在内的各种应用程序非常有用。
160.8	EIP 5656：引入了一个新的 EVM 指令，用于复制内存区域，以提供构建数据结构和在以太坊上部署计算密集型操作的有效方法。
160.9	Big EOF：一系列 EIP，本可以对 EVM 进行全面改进，其中主要改进之一是将代码与数据分离。
160.10	EVMMAX：与 EOF 实现相关的一组 EIP，它为模块化算术参数和内存空间创建新的存储逻辑，以将这些参数中的值移入和移出 EVM。
160.11	SELFDESTRUCT 弃用：开发人员同意在审计结果在一个月左右准备好后重新评估 EIP 6780 的候选资格，并考虑是否将 EIP 6780 与 EIP 6913 捆绑在一起。无论结果如何，Dankrad Feist 和 Andrew Ashikhmin 等开发人员都申明，为将 EIP 6780 纳入 Cancun 所做的努力将与为准备 EIP 4844 所做的努力正交且独立，这意味着 EIP 6780 不会延迟或对 EIP 4844 的进展产生负面影响。

介绍

Tim Beiko

大家好。欢迎来到 ACDE #160。我刚刚在聊天中发布了议程。我想我们今天应该做的最重要的事情是，讨论 Cancun 的潜在 EIP，是的，在 4844 成为我们正在做的主要事情的背景下。然后在 4844 的最前沿，我认为有两个对话，我们想继续进行。一个只是关于 blob 交易的重组，重组处理。
其次，我知道我们本周一直在进行最后的 4844 devnet，所以我们可以分享一个关于它的更新以及它的进展情况。是的，我想也许为了开始，关于 Cancun 方面，到目前为止我们只有 4844，它被包括在内。
我们还有一堆其他的东西，以前是 CFI，还有一堆其他的，甚至更多其他的被提议了但仍然没有完全 cfi。我在 Eth magicians 上整理了一个列表。但也许为了开始，我很想听听来自不同客户端团队的意见，比如你们都认为在 Cancun 中最重要的事情是什么？
是的，我们可以从那里开始。我知道，我认为 Nethermind 可能是唯一一个之前回答过 Async 的人，所以也许从 Nethermind 开始是有意义的，然后其他人可以加入。

Lukasz

所以，我认为这或多或少就是我们在 Eth magicians call tread 上回答的内容，所以绝对是 4844。绝对地，我们看到了 6780 的需求。还有什么？ 1153。我们希望继续这样做，因为这已经从上海推迟了，而且已经准备好了。所以，我不认为有很多努力要把它推出去。
我不认为有理由延迟它。然后在更多可能的状态中，2537、4788 和 5920，而像 EOF 这样更大的东西，更多关于 SSZ 的东西，如果它们不是必需的，并且认为像 EVM max 这样的东西，我会考虑用于接下来的一些硬分叉。

Tim Beiko

知道了。谢谢你。

Matt

Tim，我是 Matt。我认为从 Besu 方面来看，实际上与我们几乎完全一致。我们对这个列表有非常相似的想法，可能除了 4788 之外，但除此之外，它与 Nethermind 提供的列表几乎相同

Tim Beiko

你对 4788 有什么看法？你认为它比 Nethermind 说的更重要还是更不重要？

Matt

这很相似，就像在方面，你知道，我们认为它非常有用，但是范围方面，你知道，可能与像 weekly support 类似的一类。

Tim Beiko

好的。Geth、Aragon 有人吗？

Andrew Ashikhmin

是的，对于 Aragon 来说，重要的是获得 6780，即 self-destruct 的移除，而且，我认为与 4844 一起交付 EOF 是不现实的。所以我会将 EOF 推迟到 Prague。是的，现在，否则我认为我们可以做一些更小的 EIP。

Tim Beiko

好的。除了 self-destructed 4844 之外，你还有什么偏好吗？

Andrew Ashikhmin

没有偏好。我可以问团队成员更多，但我认为我们还没有强烈的偏好。

Tim Beiko

明白了。谢谢你。Guests？

Peter

是的，就我们而言，我的意思是我们还没有真正考虑过，具体要发布哪些 EIP 或不发布哪些 EIP。就我个人而言，优先事项是发布 4844。所以，在我看来，除了它之外，任何大的东西都是不现实的。考虑一下 EOF，更小的东西。我的意思是，self-destruct 肯定，以及任何其他更小的东西。
我不一定认为这有什么问题，但我有点觉得 4844 应该是每个人关注的事情，其余的有点像是锦上添花。

Tim Beiko

明白了。谢谢你。所以似乎，是的，从这四个来看，显然 self-destruct 是第二重要的，或者说，是第二个被提及的 EIP，仅次于 4844。而且，关于 6780，我们已经聘请了一家审计公司来分析它对链的影响。所以在接下来的几周内，我们也应该有一些数据，比如哪些合约可能会受到影响等等。但我认为这可能是值得正式包含的一个。
我看到 Danny 和 Lightclient，你们都举手了。是的，如果这是关于 self-destruct 的，请继续，否则我认为这可能是我们在深入研究其余内容之前可以完成的一个。好的。所以我想，有人反对包含 6780 吗，所以这个 self-destruct 和这个版本是允许 self-destruct，只有当它与创建调用位于同一个交易中时，否则你实际上使用像 sendal 这样的语义，你只是返回资金但不销毁合约。

Danny

这是否取决于分析没有发现我们还不知道的任何东西？如果我们发现了，我们至少会开始讨论吗？

Tim Beiko

是的，我想值得强调的是，还有另一个关于 self-destruct 的提案略有不同。我认为 Acik 把那个放在一起了，它是你做一种虚假的 self-destruct，你实际上隐藏了存储和数据，但你不，你不把它从状态中删除。是的。
而且，是的，那将是另一种前进的道路。看起来人们现在不太喜欢它，但是，是的，我想我很想知道，是的，来自客户端团队，有人对 Danny 的问题有什么看法吗？就像如果我们发现什么，什么会是我们发现的，你知道，可能会阻止我们这样做？

Danny

我不知道，William，我的意思是，我很难说，我只是，我只是承诺在这个调用中重新审视报告。是的，这似乎是做报告的目的，你知道，一个是给社区提供信息，一个是让其他人给我们提供信息。因此，我只想，如果我们现在继续这样做，就承诺一起查看报告。

Tim Beiko

是的，我认为我们肯定会这样做。我想问题是，人们是否想在报告发布之前做出这个承诺，或者，我认为这可能需要大约三四周的时间。所以，比如，你知道，从现在开始一个月左右，我们可能会知道，人们是否更喜欢从现在开始一个月后再做出那个决定？

Lightclient

我认为如果每个人都同意，现在做出决定是有意义的，然后在报告发布后重新审视它。

Tim Beiko

有人不同意吗？我知道 Dankrad，William，你们都举手了，所以如果这与 self-destruct 有关，请。

Dankrad

我的意思是，我只是想说，很难相信报告会什么都找不到。就像，我认为我们很可能会在某个地方找到一些合约，这些合约会以某种方式被破坏。问题是，我们是否对以下情况做出判断，是的，杀死该合约，因为我们认为它的价值太低，无关紧要，或者所有者可以做其他事情并挽救他们的资金等等。就像，基本上，是的，就像，我的意思是，这很可能我们会发现一些东西。
我想说的是，是的，我的意思是，如果我们现在开始构建一些东西，并且我们看到有机会，即使讨论可能都不会朝着我们无法做到的方向发展，但可能会因为我们需要与很多人交谈而被推迟，那么我们可能应该以这样一种方式来设计它，以便我们可以以没有该实现的方式进行转移。我认为这在很大程度上应该与 4844 相关。但是的，这就是我的评论。

Tim Beiko

明白了。谢谢。Lightclient 或 William，你们想补充什么吗？

William

是的，所以我们正在阉割 self-destruct，因为移除所有帐户存储的范围是无限的。在我们的垂直树中，问题变得更糟，因为垂直树是扁平的，但垂直树实际上并不阻止代码更改。因此，如果修改了 self-destruct，我希望保留帐户保留更改其代码的能力，并改进执行方式。在我的职业生涯中，我曾与三种不同的升级模式进行过交互。我编写了一些最早的合约，可以使用委托调用进行升级，并且我编写了一个帐户所有权系统来方便 self-destruct 升级。
我的建议是设置代码，以保留该能力，如果我们必须从 self-destruct 中删除它。也就是说，如果我们不这样做，Axes 的提议只会将螺母更改为帐户并将其用作标记。因此，设置代码通过更改，允许一种创建清晰存储的方式，或者在更改帐户时不清空存储，从而改进了 self-destruct 升级模式。因此，我们不想能够清除存储，因为这是无限的。因此，它只是简单地提供了一种以安全方式更改代码的方式。它与所有其他当前的升级模式一样安全，并且应该是一个简单的更改，可以添加到任何 self-destruct 移除中。

Tim Beiko

所以这个设置代码，只是为了确保我理解，你可以更改帐户中的代码，但不能更改存储。正确。这意味着你可以拥有一个合约，其语义，你知道，它更改了语义，但是，保留了以前的存储，对吗？

William

是的，这是正确的。而且，这优于当前的 self-destruct 升级模式，因为没有执行开销。委托调用仍然有用，因为你可以使用它来绕过帐户代码大小限制。因此，如果你需要一个合约，或者一个帐户，其实施代码为 10 万字节，你可以只需使用委托调用将其分布到多个合约中。但是，如果你需要，替换帐户本身的代码，那么这会保留该功能，没有执行开销的好处至关重要。
如果没有它，许多用户可能会为了节省 gas，而更喜欢迁移他们所有的 token，例如，创建一个新帐户并将他们所有的 token 所有权和身份转移到新帐户。这不好。例如，如果你是一个 dex，并且想要更改你的代码，又不想产生调用另一个合约所需的 gas 开销，

Dankrad

是的，我理解开销的论点，但是，从功能上讲，我不知道，比如如果我们能够减轻开销，我们应该更多地考虑开销，但是，通过这种 self-destruct 停用，在同一个地址上始终具有相同的代码或没有代码，可能会带来许多可能的未来优势，这些优势目前不存在，或者将来可能存在。所以我喜欢你，我们应该权衡一下这一点，与的好处。

Tim Beiko

我觉得，拥有，我认为 Axe six，不是当前的 self-destruct 提案，而是之前的那个，如果我没记错的话，实际上具有相同的语义。而且我们，所以基本上它会允许你在该地址重新创建合约，但是，它不会在此期间更改存储。这样做面临的挑战是，人们担心类似他们的攻击风险，你知道，你部署一个智能合约，然后，你知道，人们以某种方式使用它，你对其进行更改，你可以保留现有存储，你知道，可能会更改合约的整个功能。因此，我不知道，**我很好奇，是的，其他人对此有何看法。因为它有点像几个月前我们进行的讨论，除非我记错了这个问题。

Andrew Ashikhmin

我认为，从每个人的角度来看，我们都想避免拥有多个版本的 self-destruct 移除版本，因为我们已经有了那些场景，我们称之为化身，它们使代码变得非常复杂。因此，除非我们绝对必须这样做，否则我更喜欢更简单的解决方案，就像在我看来，6780 是简单性和有限的向后兼容性之间的良好折衷方案。
因此，也许我们可以等到报告出来，然后我们可以重新考虑一下，但是我们可以暂时同意我们正在包含某种 self-destruct 移除变体，例如 6780，如果与此同时其他人提出了不同的建议，我们可以重新审视这一点。这在很大程度上与 4844 无关，因此我们可以几乎独立地重新审视它。

Tim Beiko

好的。我想这与 light client 所说的有点一致，但基本上我们将包含 6780，当我们收到报告时，我们可以分析影响，看看是否值得对规范进行重大更改。但是，你知道，今天基本上做出那个承诺，你知道，如果我们看到什么，可能会更改 EIP 的实际语义。但是，从高层次的，你知道，设计角度来看，似乎所有客户端团队都赞成做出这个改变。这样说有道理吗？

Andrew Ashikhmin

是的，对我来说是的。

Tim Beiko

任何，好吧。任何，我想最后的机会，是的。

William

因此，代码可变性不会对用户空间产生太大影响，因为代码仍然可以通过代理基本上进行修改。但是，从 Aragon 方面来看，这样做有什么优势？你说它使你的实施变得复杂。当状态、路由和所有内容仍然应该起作用时，怎么会这样？

Andrew Ashikhmin

好吧，只是，我们有这个额外的每个参数的化身，因此除了帐户地址之外，我们总是携带这个化身，我们必须，例如，必须确保，在重组的情况下，我们应该到达，就像所有不同的节点都应该到达相同的化身或帐户代码版本，否则如果它成为状态的一部分，那么你可能会有不同的状态等等。因此，一切都是可行的和可行的。这只是一个额外的复杂性。问题是，这个额外的复杂性是否值得，但我认为如果，如果有另一个，比如你说我可能错过了重点是你是否在说已经有另一种方法解决了，那是一个更好的选择，或者你是在谈论你脑海中的一个新想法？

William

因此，由于创建和创建两个，帐户代码已经可以在重组时更改。因此，当那些被重组时，帐户代码也会更改。

Andrew Ashikhmin

是的，但是，如果移除 self-destruct，我们将不会有这种情况。

William

我特别是指设置代码，作为一种维护 ca 代码可变性的方式。

Andrew Ashikhmin

并且，它是 EOF 的一部分吗，还是你的一个新功能？有什么想法吗？

William

它是 EIP 6913。

Tim Beiko

因此，我想，显然我并不认为大多数客户端团队的人都非常熟悉这一点。也许我建议这样做，我们将在一个月后当我们收到报告时继续推进 6780。
显然，我们将不得不重新评估这一点。我认为这也可以让人们有时间阅读 6913，我们可以，你知道，同时做出决定，就像，我们是否想根据报告更改 6780，我们是否想将 6913 与其一起添加。但是，似乎所有团队都非常支持，你知道，继续进行 self-destruct 移除。而且我们可能没有足够的信息来超越这一点，是的，今天，所以我想，是的，有人反对包括 6780 吗？
我们重新审视报告，或者重新审视，对不起，在一个月后收到报告时。与此同时，我们也可以查看 6913，并从中开始。好的。Marius 有一个基本上说我也会做同样事情的评论。太棒了，让我们这样做。
我将在这次通话后更新规范，但是 6780 包含在内。并且只是为了实施人员，请注意，你知道，可能会对此规范进行更改，具体取决于分析的结果，以及你知道，人们在未来几周内阅读 6913 等内容。是的，感谢 William 也分享你的观点。
Light client 和 Charles，你们都举手了，而且已经举手很久了。哦，现在 Danny 也举手了。

Lighclient

是的，我想，是的，对不起，我只是想，是的，我只是想在我们在讨论 self-destruct 之前说一些关于 Cancun 的一般 CFI EIP 的事情。而且我很想认真地看看这些 SSZ EIP，因为我不想陷入这样一种境地，即我们为了 4844 而做任何绝对最快的事情，并打算在之后的分叉或两个分叉中更改它。因此，我确实认为重要的是，尝试弄清楚可以完成的最小工作量是多少，以便它与这个作为 SSZ 世界的未来兼容，因为这是我们几年来一直在讨论的事情。而不是仅仅在 RPL 或 hackmd 中发布一些东西

Tim Beiko

是的。我认为现在讨论它可能是有意义的，因为如果我们有 4844，它已经很大了。 self destruct 是一种中等大小的 EIP，如果确实需要进行一些 SSZ 更改，那么在决定做其他任何事情之前，最好先了解一下这些更改是什么。是的，我看到，我不知道，你和 Etan 都举手了。你们中的任何一个想分享你们的想法吗，你知道，我们应该作为 Cancun 的一部分进行的最小或最佳更改集是什么？特别是考虑到 4844 是升级的维护者。

Andrew Ashikhmin

因此，绝对应该研究的两个 EIP 是 6493 和 6475。第一个，6 4 93，定义了签名的计算方式，以便它们不会与可能为相同交易类型使用 RLP 的其他链冲突。另一个 6475，是一个很小的。
它只是定义了我们希望如何表示可选值，因为 4844 有一个可选地址，用于交易的目的地。现在它们在任何地方都不存在，我们应该决定它们应该像今天的联合一样，还是应该更紧凑或其他什么。
其余的，区块内部的那些树如何通过试验、收据和交易来构建，我们也可以稍后做，这对 4844 兼容性来说并不重要。就像，6493 与规范化交易方法和 SSZ 联合方法都兼容。所以这一个，就像这三个，它们不是 Cancun 的必需品。我们可以稍后做，没有任何缺点。

Tim Beiko

知道了。谢谢你。Andrew，我看到你举手了。

Andrew Ashikhmin

是的，关于 66475 SSZ 的可选问题。因此，如果我理解，如果我们在 Cancun 中采用并实施它，那么会影响 4844，对吗？因为 4844 有一些可选的，两个地址是可选的，对吗？在 SSZ 交易中？

Etan (Nimbus)

是的，完全正确。我的意思是现在它们被定义为使用联合类型，但从语义上讲，它们应该是可选的。它们可能以我们想要的相同方式序列化，但也可能存在一些小的变化。因此，至少我们需要保持一致，并将它们同时切换到新的表示形式，以便我们保持兼容。

Andrew Ashikhmin

那么是否有人认为将来我们需要 union 并在其中声明零？因为如果我们不需要，那么我认为仅仅针对可选值采用这种更有限的解决方案是有意义的。

Etan (Nimbus)

现在我们不使用它们。将来可能会有一些设计使用它们，但无论如何，可选值是一种更受限制的类型，因为它只能是 none 或 some，对吧。但 union 是一种更复杂的类型。因此，例如，在 Nimbus 实施中，这两个是非常不同的代码路径。但当然，也可以将可选值编码为 union 的一个特例。
因此，这只是一个语法的确保让读者清楚地知道它的含义。现在，6475 与 union 不兼容，因为它不发出选择器，而是使用长度，如果它是空的，它是 none，否则它是 sum。但是 union 也用于序列化，我认为它有点 underspecified，因为它没有定义如何序列化非值。所以是的，今天不使用 union，但如果我们需要它们，我们也需要决定我们希望它们看起来如何。

Dankrad

当然，抱歉，我认为它已经指定好了。我认为它只是选择器等于零并且估计值

Andrew Ashikhmin

好的。像这样，0 和 10，我想之后没有别的了，是的。

Dankrad

是的。因此，一个想法是，就像如果我们真的喜欢，如果我们只是保持开放的选择，我们可以简单地实施，如果目前没有人使用 union，那么我们可以按照你指定的方式实施可选值，并打算如果我们稍后引入 union，我们将使它们成为可选值的超集。

Andrew Ashikhmin

好的。那么区别在于，我想 6475 需要进行更新，以便允许将来扩展多个案例，但例如，非值可以简化为只是空值，例如那里的零不提供任何值，但 sum 会有一个前导 1，对吗？这将是最小值。

Dankrad

可能是的。我的意思是理论上你甚至可以不必，对吧？你也可以说，如果只有两个选项，比如 none 或 something，那么你也不需要添加 1，对吧？

Andrew Ashikhmin

这是真的。是的。如果它是 none，而另一个选项，

Dankrad

我想你必须保证这一点。是的。那么你需要，好吧，我想你需要做一种特殊情况，即第二部分是非零长度。我不知道是否总是保证这一点，也许总是保证这一点。是的。有些事情需要仔细考虑，但有可能使 union 成为你已经指定的内容的严格超集。

Andrew Ashikhmin

是的。另一个问题是，当你更新规范时，比如当一个分叉向 union 添加另一个案例，并且你从两个变为三个时，你将无法再使用旧值进行分析，是的，这实际上是一个好点。

Dankrad

是的，这可能是添加 1 的一个优势，因为这意味着你可以更轻松地使用其他选项升级现有的 SSZ 字段，对吧？

Andrew Ashikhmin

是的，完全正确。因此，我将更新 6475，以便在 sum 案例中包含 1，并且在 none 案例中我保持为空，然后也更改现有的以使用此时间。

Tim Beiko

因此，如果我们对 6475 进行这些更新，我们是否完全满意它的状态？我们应该考虑，我们应该包括它，你知道，在进行这些修改之前？

Andrew Ashikhmin

我想是的。

Tim Beiko

好的。所以有人不同意吗？

Andrew Ashikhmin

并且我认为，我们还需要更新 4844 以使用 6475，对吗？对于可选的，寻址。

Tim Beiko

是的，我相信至少有一半（如果不是全部）的 4844 作者都在这次通话中。因此，如果其中一位可以在我们完成 6475 更改后，对 6475 进行 PR，那就太好了。好吧，6475 就是这样，然后是 6493。因此，签名方案，我想这也是我们必须包括的。
抱歉，我正在努力阅读评论。是的，所以我想，好吧，所以是的，有人反对 6493，即 SSZ 交易的签名方案吗？

Lightclient

这是否会创建交易 ID 与交易哈希这两个概念，还是仅与签名有关？

Andrew Ashikhmin

它还包括交易 ID 的概念。

Lightclient

是的，我已经有一段时间没有研究这个了，但我记得我非常反对通过这个交易 ID 概念来引用交易，并且它与交易哈希不同。

Andrew Ashikhmin

我的意思是，它是一样的，就像它不是一个 catch，而是一个哈希根，对吧？

Roberto B

一个缺点是，它现在涉及将 ssy 的非规范化方面引入执行层，而现在我们还没有那个小东西，但是，是的。

Lightclient

但我认为我们需要它最终。

Tim Beiko1

是的。

Tim Beiko

好吧，我想这可能是一个愚蠢的问题，但是如果 4844 交易类型是 SSZ 交易，我想它的签名方案是作为 4844 的一部分定义的。

Roberto B

现在它只是带有前缀类型的实现。

Tim Beiko

知道了。抱歉，我听不清你在说什么。我打断了你。

Lightclient

不，我只是在思考。

Tim Beiko

好的。因此，我认为抱歉，我认为我在这里有些误解了。我以为这也是 4844 的一种要求，但似乎并非如此。

Lightclient

因此我们可以继续前进，我的意思是，我们现在有 4844 的实施，但我认为以正确的方式做事是最好的，而且我们实际上没有对 SSZ 序列化值进行哈希处理的概念。我认为这有点奇怪。因此，这就是为什么我们一直在讨论拥有哈希树根的原因，但是一旦我们开始拥有哈希树根，我们就开始遇到其他问题，比如，我们如何，你知道，使签名方案安全？

Andrew Ashikhmin

此外，对于 6404，如果我们稍后使用基于 SSZ 的交易，那么它将有 Tier 8，即那些哈希和 ID 匹配，如果我们从 Geth 开始以正确的方式做。如果是规范化的方法，老实说并不重要，因为哈希无论如何都是树中的一个单独的叶子。所以是的，也有这个小优势。

Tim Beiko

因此，我认为也许这里的一个好的下一步是，我们在周一进行 4844 通话。是否有可能在周一之前，在那个通话之前，完成 6475 和 4844 中的更改，以便人们可以在周一之前查看它，并在 4844 的背景下讨论 6493，并且基本上，你知道，在那个通话中对齐这两者。
好的，我看到周一是假期，Etan 是谁。是否有其他人你认为可以加入并为 EIP 辩护？

Andrew Ashikhmin

我的意思是，主要是为了审查，对吗？是的。6493，对吗？

Tim Beiko

是的，是的。

Andrew Ashikhmin

就像，我们必须在通话期间进行审查，还是我们可以只是，

Tim Beiko

因此，我想，是的。是的，而且我们绝对不应该在不包括它的情况下在 4484 通话中做出决定，但我认为，是的，如果人们想审查它，我们可以在周一的通话中进行，你知道，第一次对话，至少，是的，如果人们在审查期间有疑问或想法，我们可以在那里解决其中的一些问题，但似乎人们没有足够的背景信息来在今天做出关于此的决定。好的。
让我们这样做。因此，让我们包括 6475，如果 Ethan 可以在周一之前进行更改，那将是太棒了。我们还需要对 EIP 4844 进行更改，以反映这一点，如果人们想讨论更多，我们可以在周一的通话中提出这个问题，并且两周后 हम 可以希望在这次通话中做出最终决定。
好的。关于 SSZ 还有其他想法、担忧吗？好的，Daniel，你举手了很长时间了。只是不小心举起来的吗？

Danny

哦，对不起，我。是的。是的。我只是想在开始时当我们从客户团队那里获取信号时说，跨层的 4478 得到了共识层团队的支持，你知道，看到它具有适度高的优先级，以开放无信任池设计并降低在执行层中创建池的门槛。
并且人们愿意接受它。显然它是跨层的，所以需要双方合作。我只是想确保这里浮出水面了这些信息。

Tim Beiko

知道了。谢谢。是的，我认为实际覆盖这个问题和 BLS 预编译可能是有意义的，因为在过去，我的意思是 BLS 的情况是几年，而在 4788 的情况下至少是几个月，我们已经谈论了很多。是的，我想我很想听听来自像 EL 客户团队的意见，似乎大多数团队都有胃口，你知道，可能除了 4844 self-destructed 之外还添加一两个较小的 EIP，现在，一些 SSZ 更改，但是，你知道，我想 4788，BLS 或者是，我知道 1153 是另一个经常出现的，就像，是的，人们认为如何在这些可能较小的 EIP 之间进行优先级排序，以及人们是否感到必须拥有或，你知道，非常重要的事情？

发言人 0

是的，我不会说我们认为 1153 是必须拥有的，但我们基本上仍然非常强烈地支持它。

Tim Beiko

好的。这是否意味着如果它已经完成，你会优先考虑它而不是像 4788 这样的事情？

Matt Nelson

因此，这主要是测试开销。明白了。至少要按压力量。情况并非如此。

Tim Beiko

知道了。然后 Marek 有一个评论，我想也说 1153 对他们来说会稍高一些。Andrew Ashikhmin
好的，我想，我们会做5920。这是一个简单的可用性改进。是的。

Tim Beiko

好的。所以我想这就是我们讨论4788、2537和1153的地方，这三个我认为是中等优先级的，一些客户端团队至少对此感觉强烈。我不确定我们今天是否需要就这些做出决定，
但是，我很好奇，是否有人可能乐于说这就是Cancun的全部范围，也许我们可以做的就是从CFI中删除所有其他内容，除了这三个，即1153、2537、4788。当我们开始处理DevNet和实施其余EIP时，我们可以重新审视这三个，是的，我看到了，是的，所以，是的，我想我们从这里开始。
是否有人乐于现在将此CFI限制在这三个提议上，这意味着基本上删除所有EOF内容，我认为这是CFI中唯一的其他内容。好的。然后，是的，聊天中有一些关于其他小型操作码的评论，也许我们将来也可以添加这些，但至少我认为我们可以删除EOF内容，是的，保留这三个。所以11 53、25、37 已经是cfid。我们可以考虑47 88。
然后，如果出现一些小的事情或其他补充，我们可以决定。我知道Charles，你举手很久了，想谈论其中一件小事，如果你想继续，我们可以这样做，然后给人们提供背景信息。

**Charles C***

当然。这实际上是我第一次参加ACD会议，所以我不知道规则是什么，好的，协议是什么，但我不想破坏一切，但首先，我认为1153和5920非常有用，如果你们已经在讨论这个了。
所以我想提出mcopy EIP 5656，从编译器的角度来看，它非常有用。它可以让我们减少大量的样板代码，而且拥有它也很有意义，有调用数据复制，有代码复制，甚至有X代码复制，但没有mem copy，我不认为关于规范或其有用性存在任何争议。甚至在Geth上还有一个开放的门户请求来实现它。
而且它看起来很简单，所以我不认为会有任何问题，是的，它会非常有用。

Tim Beiko

好的。谢谢你。所以我想我们可以，是的，我们可以把它放在列表中，我们可以潜在地，或者我们，你知道，让人们看看它，并在另一次会议上进行CFI，当大家有时间审查它时。一般来说，我们尽量不在第一次展示时就对某件事进行CFI，这样人们可以有一些时间来消化它。
但是，我看到你发布在Eth Magicians thread中了，所以人们可以在那里查看它。Andrew，Daniel，我看到你们都举手了，先是Andrew。

Andrew Ashikhmin

好的，我只是认为，因为我们已经定义1153很长时间了，并且我们把它从上海移到了坎昆等等，而且它似乎是一个小型EIP，大多数人都赞成。我认为把它包括进来是公平的，否则我们只是，是的，我们已经，已经有很多机会让人们去了解它，而且我们普遍认为它是有意义的，所以为什么不呢？而且它足够小。

Tim Beiko

是的。有人反对吗？确实如此。它已经被讨论了很长时间。我知道有些人从设计的角度来看是反对的，但是，现在看来大多数客户端团队都赞成。
是的。有人反对吗？好的，所以我想，所以我们，好吧，这意味着我们将1123与上海一起包括在内，以及4844和自毁以及小的SSD更改，以及人们之前提到的其他两个潜在的权衡，即4788，这些将被cfid，但暂时不包括在内。这对大家有意义吗？好的。所以我们也可以将1153移到包含的列表中，Daniel，我看到你举手了。

Danno Ferrin

是的，所以我支持将EOF从Cancun中移除。这将给我们更多的时间来解决一些核心的深度问题，对吗？我们仍在研究关于Geth可观察性是否应该包含的问题，以及关于create应该如何处理的问题，以及其他一些问题，将其从Cancun中移除可以缓解很多时间压力。
这样我们就可以专注于把它做好，而不是准备好在第三季度发布。尽管这很让人难受，但我认为这是一个正确的决定。

Tim Beiko

好的。Ansgar？

Ansgar

是的，我总体上赞同这种观点。我只想说，因为我认为为长期路线图设定一些大致的期望总是有帮助的。我个人更希望我们至少在事后能够以EOF为重点进行分叉，并希望在Cancun之后相对较快地进行，而不是试图将其与其他内容合并。
我知道，并且希望在Cancun之后9个月或更长时间再进行分叉。
这似乎是因为如果我们一直试图将其与其他重要内容合并，我认为它只会一直推迟，因为它太大了，基本上无法在分叉中占据第二位。所以我认为在某个时候我们只需要说，好吧，它会自行分叉，因为到时候大多数限制都将准备好，这将是一个快速的分叉。

Tim Beiko

是的。所以，我认为这样考虑是有意义的，我不想让我们今天就强烈承诺某件事，因为我们甚至还没有Cancun的实现。但是，是的，似乎EOF和垂直树是接下来两个潜在的重要内容，EOF可能更小且进展更快，这几乎就像我们对合并和提款所做的那样，你有一个包含4844的大型分叉，然后是一个包含EOF的小型分叉。所以，是的，我们肯定可以讨论这个问题。
我认为，就像我们对Cancun有一个清晰的蓝图一样，这可能是需要做出的最高级别的决策，这样我们就可以让团队并行工作。Lucas？是的，要清楚的是，我并不是说EOF很小。我是说，尽管提款并非微不足道，但如果你有合并和提款，合并比提款大得多，而且感觉我们与484和EOF有类似的情况，4844更大。显然，实际上与EOF的组合不太可能，是的，EOF也很大，也许可以是一个较小的重要内容，基本上是下一个分叉。是的。Greg，哦，Greg，你静音了。

Greg

我想重申，我们承诺在某个时候将EOF纳入其中。基本功能与我在2016年提出的EIP 615相同。所以我们已经讨论了七年了。是时候了。我认为我必须要做一些我想在EVM上做七年的工作，但在它加入之前我无法做。

Tim Beiko

是的，我的意思是，我认为所有客户端团队都非常支持EOF，但EOF太大了，无法与Cancun一起包含。我认为我们能做出的最强烈的承诺是将其作为下一个分叉的主要内容。但即使是这样，我们今天也可能无法百分之百地同意。聊天中也有一些相关的评论。是的，好的，所以我认为我们已经涵盖了几乎所有提议的EIP，也许可以简单地回顾一下，我们最终达成的共识。所以4844显然是Cancun的一部分，包括在内。6780。这是一个自毁移除EIP。我们也同意包含这个，在一个月左右的时间内，当我们发布影响分析时再对其进行审查。同时，我们也可以看看set code EIP，即6913，然后我们同意包含6475，即SSZ可选类型。
仍然需要对它进行一些更改。Etan将在未来几天内完成这些更改，我们将更新4844以反映这些更改。最后，我们同意将1153也包含在内。所以这将是Cancun的当前范围。我们已经，好吧，2735，BLS已经是cfid，它仍然存在。Liz 4788。
我们也对其进行了CFI，然后我们从cfid中删除了所有EOF EIP，这基本上是，哦，是的，我们也应该对签名方案进行CFI。6493。但我们还没有完全同意。这对大家有意义吗？好的。
好的。是的，所以在周一的会议上，我们可以在周一的会议上更多地讨论6493 EIP。然后两周后，我们可以再次在这里提出它。

EIP-4844 blob re-orgs & newPayload(context) 50.50

好了，议程上还有两件事。首先是，也与4844相关，关于blob重组和新的payloads规范的对话。我知道Peter和Danny，我们上周在CL会议上讨论过这个问题。我不知道你们俩是否有任何更新，或者，是的，我没有更新。

Danny

我知道Peter想花更多的时间思考这个问题，我也知道可能其他没有过多考虑这个问题的人也想花一些时间思考这个问题。所以我们可以现在讨论，也可以在会议之前讨论。如果我们走这条路线，这将是对引擎API的重大更改。所以我们需要尽快解决这个问题，而不是以后。

Tim Beiko

Peter，你有什么想法吗？你取消了静音，但我们听不到你说话。至少我听不到。哦，不，我们听不到。

Peter

所以本质上我想说的是，我正在研究4844，但不是这个特定部分，所以我真的没有任何更新。

Tim Beiko

好的。我们会看到。我们也可以在discord上继续讨论这个问题，因为它会出现的，但我们应该意识到这一点。是的，基本上，我们需要就这个设计达成一致。

4844 devnet-5 更新 59.19

Tim Beiko

然后，我们议程上的最后一件事，是DevNet 5。本周在这方面有很多工作。我不知道是否有人想快速更新一下，分享一下目前的情况。

Barnabas Busa

当然，我可以做到。基本上，DevNet 5，我们上周五开始进行了driver on测试，然后在昨天进行了实际启动。主要的utc。我们正在使用1000个验证器运行它。我们有三个工作的CL客户端，lighthouse和Prism，以及四个左右的EL客户端。另一个是mine JS，以及everyone的分支和geth的分支。
目前我们有工作的block scout，相关的工具正在上线，我们还没有工作的BL扫描器，但希望它能在本周末上线。很好。我们目前不做任何fuzzing，但我对此持开放态度。而且，可能的时间表是，我不知道，一两周，也许更长，但我希望看到更多的客户端加入。你们是否还在运行dead net force？如果没有任何异议，我们希望在本周末关闭它。

Tim Beiko

似乎我们可以，是的。继续关闭它。是的，谢谢分享更新。还有其他人有想法吗？问题？

Barnabas Busa

我还在聊天中链接了如果你想参与所需的规范。

Tim Beiko

很好，谢谢你。好吧，我想就是这样了。今天还有其他人想聊些什么吗？好的，如果没有，那么我想，是的，下次会议，确定SSZ内容，是的，如果还有其他想讨论的小型EIP，这可能是开始考虑它们的最后机会。
是的，所以请将它们添加到Eth Magician thread中，这样我们就可以，是的，这样我们就可以跟踪它们。好的，谢谢大家。我们很快再和大家聊天。
谢谢你。谢谢你。谢谢你。

出席者

Tim Beiko
Danny Ryan
Pooja Ranjan
Mikhail Kalinin
Marius
Wesley
Barnabas
Saulius
Danno
Lightclient
Pari
Ethan
Mario
Tomasz
Oleg
Kasey
Marek
Crypdough
Fabio Di
Terence
Andrew
Roman
Marcin
Pop
Guilaume
Protolambda
Carlbeek
Mike
Gajinder
Stefan
Hsiao-Wei
Josh
Phil Ngo
Alexey
Holger Drewes
Dankrad
Guillaume
Proto
Holder Drewes
Stokes
Peter Szilagyi
Sean
Micah Zoltu
Jiri Peinlich
Marius Van Der Wijden
Potuz
Evan Van Ness
Moody
Tynes
Alex Beregszaszi
Marek Moraczyński
Justin Florentine
Ben Edgington
Lion Dapplion
Mrabino1
Barnabas Busa
Łukasz Rozmej
Péter Szilágyi
Danno Ferrin
Andrew Ashikhmin
Hdrewes
Crypdough.eth
Ameziane Hamlat
Liam Horne
Georgios Konstantopoulos
Mehdi Aouadi
Bob Summerwill
Jesse Pollak
Stefan Bratanov
Sara Reynolds
Caspar Schwarz-Schilling
Ahmad Bitar
Marcin Sobczak
Kasey Kirkham
Sean Anderson
Saulius Grigaitis
Ruben
George Kadianakis
Dankrad Feist
Andrei Maiboroda
Gcolvin
Ansgar Dietrichs
Jared Wasinger
Diego López León
Daniel Celeda
Trent
Mario Vega
Kamil Chodoła
Ziogaschr
Kevaundray
Antonio Sanso
Oleg Jakushkin
Leo
Nishant Das
Pote
Sam
Tomasz K. Stanczak
Matt Nelson
Gary Schulte
Rory Arredondo

下次会议

2023年5月11日，14:00-15:30 UTC

原文链接： github.com/ethereum/pm/b...

登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

翻译
学分: 0
分类: 以太坊
标签: EIP-4844 Cancun升级 selfdestruct SSZ EVM Devnet

本文参与登链社区写作激励计划，好文好收益，欢迎正在阅读的你也加入。

执行层会议 60

执行层会议 #60

会议日期/时间：2023 年 4 月 27 日，14:00-15:30 UTC

会议时长：1 小时 30 分钟

GitHub 议程

会议视频

主持人：Tim Bieko

笔记：Alen (Santhosh)

介绍

EIP-4844 blob re-orgs & newPayload(context) 50.50

4844 devnet-5 更新 59.19

出席者

下次会议

0 条评论

文章目录