投研早报丨Vitalik 为什么着急提出账户抽象新方案 EIP-7702？/ Polygon 首席执行官：为什么说没有必要构建 L3？/ Vitalik 新作：多维 Gas 定价
投研早报丨Vitalik 为什么着急提出账户抽象新方案 EIP-7702？/ Polygon 首席执行官：为什么说没有必要构建 L3？/ Vitalik 新作：多维 Gas 定价
ChainFeeds Newsletter 每日精选 Web3 深度投研「简报」+ AI 驱动的热点新闻榜单，帮你做出聪明决策
📢 ChainBuzz 热点新闻 ｜2024.5.11
🔥 Layer3：将于今年初夏推出协议治理与实用代币 L3，51% 用于社区分配
🔥 Eigen 基金会：EIGEN 质押空投认领已开放，8.25% 将用于未来空投
🔥 LayerZero 发布「Protocol RFP」提案，作为 TGE 分配第一步
🔥 彭博社：主流加密交易平台上月交易量出现 7 个月以来首次下降
🔥 数据：ENA 代币申领数量突破 3 亿枚，已超空投总量的 40%
🔥 Ethena 发布路线图：今年将重塑并推动 DeFi、CeFi 与 TradFi 的融合
👨💻 ChainFeeds 投研简报 ｜2024.5.10
1️⃣ 研究｜Vitalik 为什么着急提出账户抽象新方案 EIP-7702？
2️⃣ 以太坊｜以太坊核心开发者最新会议摘要：EIP-7702 纳入疑虑、坊执行层序列化方法转换
3️⃣ 研究｜Vitalik 新作速读：多维 Gas 定价
4️⃣ 观点｜Polygon 首席执行官：为什么说没有必要构建 L3？
5️⃣ 研究｜共享证明、证明聚合和证明者市场：如何改变 ZK 证明格局？
6️⃣ 研究｜下一代区块链：并行执行
7️⃣ 研究｜解读 Vitalik 最新提案 EIP-7702：将彻底改变 Web3 应用程序交互方式？
8️⃣ 研究｜可验证计算：如何使用加密扩展信任？
每日精选的加密信息由 ChainFeeds 团队与 AI 共同编写，我们已将内部的信息流工具优化并开放给所有读者及 Web3 行业者使用，测试链接 👇
🌞 Web3 行研早报来自：Web3 行业必读深度资讯「简报」平台｜chainfeeds.xyz
🤖️ Web3 热点榜单来自：AI 驱动的 Web3 热点新闻自动聚合工具｜chainbuzz.xyz
1️⃣ Vitalik 为什么着急提出账户抽象新方案 EIP-7702？
导读：同样都是账户抽象提案，ERC-4337、EIP-3074 和 EIP-7702 的差别在哪里？ERC-4337 是账户抽象的应用层标准，EIP-3074 是直接修改 EVM 的协议层标准，而 EIP-7702 有点介于两者之间，为 EOA 临时赋予了智能合约。
0xNatalie: ERC-4337 由 Vitalik 提出，是应用层标准，主要目标是让智能合约账户具有 EOA 主动发起交易的特性。它通过引入一个名为 EntryPoint 的智能合约，使得智能合约可以表现得像是用户的账户，也就意味着用户操作类似账户的智能合约来管理他们的资产和交易。主要特点包括无需硬分叉、与现有 EOA 系统兼容、实现账户抽象及让智能合约账户具有 EOA 主动发起交易的特性。
EIP-3074 由以太坊研究员 SamWilsn、Go Ethereum 开发者 Matt Garnett 等人提出，且 Vitalik 未参与此提案的起草，这是一种允许 EOA 将其权限委托给智能合约的方法，引入了两个新的操作码：AUTH 和 AUTHCALL，使得智能合约可以代表 EOA 执行操作，比如批量处理交易、赞助 gas 费用。这对于以太坊的虚拟机是一个较大的变动。但其存在一个安全隐患，委托机制可能导致安全问题，因为如果授权给恶意合约，可能会导致资金被盗。
Vitalik 是 EIP-7702 的第一作者，于 5 月 7 日刚发布了此提案。作为 EIP-3074 的替代方案，EIP-7702 引入一种允许 EOA 在交易过程中临时采用智能合约功能的机制。通过这种方法，EOA 可以在单一交易执行期间将 EOA 转换成智能合约钱包，而在交易结束后恢复到普通状态。并且因为 EIP-7702 已经提供了临时改变 EOA 代码的框架，所以在 EIP-7702 的基础上实施 EIP-5003（允许 EOA 永久转变为智能合约账户）变得相对简单，通过设置不在交易结束后清除代码，可以实现 EOA 到智能合约的永久转变。主要特点包括在交易过程中，EOA 的智能合约代码临时被赋予执行特定操作的能力。且其具有高度兼容性。此外，与 EIP-3074 相比，EIP-7702 虽然也是协议层标准，但它在交易中临时应用智能合约代码，不需要永久改变以太坊虚拟机。（ 来源 ）
2️⃣ 以太坊核心开发者最新会议摘要：EIP-7702 纳入疑虑、坊执行层序列化方法转换
导读：在最新的 ACDE 电话会议上，开发者们就 Pectra Devnet 0 的准备工作、EIP 3074 的实施更新以及将执行层的序列化方法从 MPT 转换为 SSZ 的紧迫性进行了讨论。其中，对 EIP-7702 的讨论引起了与会者的广泛关注，该提案被视为取代 EIP-3074 的潜在方案。中文版本由 BlockBeasts 编译发布。
Christine Kim: 以太坊基金会开发者运营工程师 Barnabas Busa 表示，他的团队正在测试第一个 Pectra 开发者专注的测试网络的客户端配置，并将在 5 月 13 日星期一之前努力确保 Pectra Devnet 0 的稳定配置。根据 Pectra Devnet 0 的准备情况追踪器，Geth、Nethermind 和 EthereumJS 客户端团队已完全实现了 Pectra 代码规范。在 CL 客户端方面，Grandine 的开发者 Saulius Grigaitis 表示，所有 EIP 都已经实现，但当与 EL 客户端一起运行时，他的团队遇到了一些错误。来自 Lighthouse 团队的代表表示，他们即将为 Pectra Devnet 0 准备好一个完整的实现，并指出引擎 API 中的规范需要更新。Teku 的开发者 Mikhail Kalinin 表示，他正在努力将这些更新添加到引擎 API 规范中。
尽管开发者们同意将 EIP-3074 保留在 Pectra Devnet 0 的规范中，但已经讨论了一种替代性 EIP 来取代它，即 EIP-7702。根据 Lightclient 的说法，所有参与者都同意完全本地账户抽象化距离在以太坊上实现还需要几年的时间。然而，对于这是否意味着优先考虑对外部拥有账户（EOAs）功能的变更，或者将 EOAs 迁移到智能合约钱包上，存在分歧。以太坊联合创始人 Vitalik Buterin 提出了一个新的 EIP，即 EIP-7702，该 EIP 将使以太坊支持一种新的交易类型，以支持 EOAs 在单个交易期间像智能合约钱包一样运行。Lightclient 表示，来自 EIP-3074 分组会议的参与者普遍对 EIP-7702 持积极态度。然而，他后来补充说，关于 EIP-7702 仍有重要细节需要解决。例如，有关如何撤销 EIP-7702 交易以及如何缩放这类交易的 gas 成本的详细信息仍不清楚。如果 EIP-7702 被接受并纳入 Pectra 升级，那么就会考虑用它替代 EIP-3074，因为其实现了与 EIP-3074 类似的结果，但却不会在以太坊上创建新的操作码，并且提高了对新 EOA 行为进行静态分析的便利性。（ 来源 ）
3️⃣ Vitalik 新作速读：多维 Gas 定价
导读：以太坊联创 Vitalik Buterin 表示通过 EIP-4844，现在实际上已经在以太坊上实现了多维 Gas，并撰文探讨了这种方法的优点，以及进一步进行增强的前景。中文版本由 Foresight News 编译。
Vitalik Buterin: 为什么不降低 calldata 的 Gas 成本以使 Rollup 更便宜呢？我们之前这样做过，现在也可以再次这样做。但这里的答案是：区块的最大大小是 30,000,000/16=1,875,000 非零字节，而网络勉强能或者几乎不能处理这样大小的区块了。再将成本降低 4 倍会使最大值提高到 7.5 MB，这将给安全性带来巨大风险。这个问题最终通过在每个区块中引入一个独立的、对 Rollup 友好的数据空间（称 blob）来解决。结果是，Rollup 的成本降低了 100 倍，Rollup 上的交易量增加了 3 倍以上，而理论上的最大区块大小仅略有增加：从约 1.9 MB 增加到约 2.6 MB。
在不久的将来，无状态客户端（stateless clients）的存储证明也会出现类似的问题。目前的计划是通过将以太坊的 State tree 设计从 Merkle Patricia trees 转变为 Verkle trees 来支持无状态客户端。然而，Verkle trees 不具备抗量子性，并且对于较新的 STARK 证明系统来说并不是最优选择。因此，许多人有兴趣通过二进制 Merkle trees 和 STARKs 来支持无状态客户端，但其关键弱点在于生成证明的时间很长。我们处理此类情况的 default 方法是重新定价：提高存储读取的成本，以减少每个区块的最大值到更安全的水平。但是，我们已经这样做了很多次，如果再次这样做，会使太多应用变得太昂贵。一个更好的方法是多维 Gas：分别对存储访问进行限制和收费，将平均使用量保持在每个区块 1,000 次存储访问，但设置每个区块的上限进行设置，例如 2000 次。
另一个值得考虑的资源是状态大小的增长：即增加以太坊状态大小的操作，这些操作之后需要全节点来保存。状态大小增长的独特之处在于，限制它的理由完全来自于长期持续的使用，而不是峰值。因此，为增加状态大小的操作添加一个单独的 Gas 维度可能是有价值的，但目标不同：我们可以设定一个浮动价格来针对特定的平均使用量，但完全不设置每个区块的限制。这展示了多维 Gas 的一个强大属性：它让我们能够分别针对每个资源，询问（i）理想平均使用量是多少？（ii）每个区块的安全最大使用量是多少？与基于每个区块的最大值来设定 Gas 价格，并让平均使用量跟随其后不同，我们有 2n 自由度来设定 2n 参数，根据对网络安全的考虑来调整每一个参数。
我能想到的最简单的「完整的多维定价解决方案」是：我们将子调用 Gas 限制视为成比例的。也就是说，假设有 𝑘 种不同的执行类型，并且每个交易设置了多维限制 𝐿1...𝐿𝑘 。假设在当前执行点，剩余 Gas 为 𝑔1...𝑔𝑘 。假设调用 CALL 操作码，并使用子调用 Gas 限制 𝑆 。让 𝑠1=𝑆 ，然后 𝑠2=𝑠1/𝑔1∗𝑔2 ， 𝑠3=𝑠1/𝑔1∗𝑔3 ，以此类推。也就是说，我们将第一种类型的 Gas（实际上是 VM 执行）视为一种特殊的「账户单位」，然后分配其他类型的 Gas，以便子调用在每种类型的 Gas 中都获得相同百分比的可用 Gas。这种方法有点难看（ugly），最大限度地保证了向后兼容性。如果我们想在不牺牲向后兼容性的情况下，使该方案在不同类型的 Gas 之间更加「中立」，我们可以简单地将子调用的 Gas 限制参数表示为当前 context 中剩余 Gas 的一部分（例如，[1...63]/64）。
然而，无论在哪种情况下，都值得强调的是，一旦开始引入多维执行 Gas，固有的复杂性（ugliness）就会增加，这似乎很难避免。因此，我们的任务是做出一个复杂的权衡：我们是否接受在 EVM 层面上的某种程度的复杂性（ugliness）增加，以安全地解锁显著的 L1 可扩展性增益，如果是的话，哪种具体提案对协议经济和应用程序开发者最有效？很有可能，我上面提到的两个方案都不是最好的，但仍有空间提出更优雅、更好的方案。（ 来源 ）
4️⃣ 【英文长推】Polygon 首席执行官：为什么说没有必要构建 L3？
导读：Polygon 首席执行官 Marc Boiron 认为构建 L3 是一个糟糕的想法及营销噱头，并撰文概述了他的理由。
Marc Boiron: 1）在 L2 上，你可以像在 L3 上一样定制一切。 2）你可以在 L2 上使用原生的 Gas 代币，就像在 L3 上一样。 3）你可以在 L2、L3 甚至 L1 之间实现无缝互操作，而无需使用 L3。 4）只要连接到 AggLayer 的其他链可以从交易所上线，你就可以直接从任何交易所进入 L2，这提供了更灵活的选择，使得不需要为了受益于其上的 L3 而将一个 L2 上线到每个交易所。 5）你可以在多个 L2 甚至 L3 上分摊 L2 交易成本。 6）作为 L2，你可以享有主权，同时享有以上所有好处，而 L3 则受 L2 决定对 L3 施加的任何限制。 7）L2 允许您频繁且快速地返回以太坊，而 L3 则不然。
为什么会有人试图让 L3 建立在 L2 上？L2 的开发者这样做是为了增加对其 L2 上区块空间的需求，并锁定 L3 的网络效应。他们通过 L3 这样做，是因为他们缺乏开发跨 L2 安全互操作性的零知识技术。在某些情况下，他们可能会认为自己可以创造足够的网络效应，最终建立起自己的验证程序集，以足够的经济安全性取代以太坊。【原文为英文】（ 来源 ）
5️⃣ 【英文】共享证明、证明聚合和证明者市场：如何改变 ZK 证明格局？
导读：模块化通常被理解为由四个 Layer 组成：DA、共识、执行和结算。而共享证明可能会作为新 Layer 被集成到模块化中。它是否会弥补高效和可扩展验证的缺失部分？
Facundo: 共享排序器为跨域交易提供了高吞吐量。然而，它们实际上并不证明任何东西。未来，它们可能会与共享 Prover 网络整合，将这一任务委托出去。Prover 网络提供了一种解决方案：一个统一的市场，各种 ZK 应用可以将证明生成外包给专业提供商，从而提高成本和时间效率。共享证明器可以填补需要 ZK 证明支持但又缺乏内部 zkVM 或电路开发资源的应用的空白。在与证明者网络连接的各种 Rollup 网络的事务生命周期如下：Rollup 提交证明请求、匹配机制选择证明者、证明者满足请求、为提高效率，可选择对证明进行聚合、证明者将最终证明提交给 L1 进行验证。
证明聚合协议市场格局：1）Nebra：让 ZK 应用程序捆绑多个证明以获得更便宜的验证，他们声称在测试网上支持约 10 个证明 / 秒。他们的证明器目前是集中式的，但目标是以后实现去中心化。目前他们有一个类似于现有 L2 逃生舱的强制包含机制。如果证明者审查或延迟证明，ZK 应用程序可以绕过证明者，在 L1 上执行证明结算。 2）Aligned Layer：由 EigenLayer AVS 保护的 ZK 验证层。Restakers 通过证明聚合和单一以太坊提交为用户提供软终结性。默认的 DA 是 EigenDA，但也可以选择 Celestia 或 Avail 等其他 DA 层。 3）AggLayer：用于安全跨链交互的中立基础设施。它旨在将独立的链网络统一在一座桥下，在不损害主权的情况下促进互操作性。该系统的建立是为了聚合所有连接链上的证明，然后提交一个唯一的证明，该证明包含提交的每个独立证明的 Merkle tree。此外，Agglayer 还在 Rollup 之间连接了一个共享跨链桥，简化了 L1 和 L2 之间的资产流动。
虽然证明者市场的去中心化是一个悬而未决的问题，但目前正在探索一些方法：1）证明竞赛： 最快的证明者获胜，提高效率，但浪费计算量（成本转嫁给用户）；2）证明挖矿： 与 PoW 挖矿类似，SNARK ASIC 的硬件加速有望降低成本。【原文为英文】（ 来源 ）
6️⃣ 下一代区块链：并行执行
导读：区块链技术的迭代发展中，并行执行正成为提升交易效率、降低成本和增强用户体验的关键革新。本文概述了什么是并行执行，并对并行执行的市场格局进行了分析解读。中文版本由 DefiLlama 24 编译发布。
pt1mfv: 市场格局：1）Solana 虚拟机（SVM）：Solana 是第一个围绕并行执行设计的区块链网络。Sealevel 是 Solana 网络的并行智能合约运行时环境，采用多线程架构，这意味着它可以在验证器核心的容量范围内同时处理多个交易。Solana 并行执行的关键是在启用交易时，网络会为该交易分配一系列要执行的指令，具体是访问哪些账户和状态以及进行哪些更改。Solana 还利用 Cloudbreak，其自定义的 accountsDB，用于存储和管理状态数据，以支持交易的并发读写。 2）Sei Network：Sei 正在过渡到一个乐观的并行模型，这意味着所有交易将在提交到网络时并行处理（执行阶段），然后在验证阶段检查与先前交易的冲突信息。如果发现两个或更多的冲突交易，即尝试访问相同网络状态的交易，Sei 会识别这一冲突点，然后根据冲突的性质，要么并行要么顺序地重新运行交易。为了存储和维护交易数据，Sei 还将引入 SeiDB，这是一个定制数据库，旨在通过优化并行执行来改进 v1 版本的不足之处。最后，Sei 最近还宣布推出了其 Parallel Stack，这是一个开源框架，用于使 Layer 2 扩展解决方案（例如 rollups）能够利用并行执行并从中受益。 3）Monad：类似于 Sei v2，Monad 将采用乐观执行模型。重要的是要注意，在与以太坊保持同步的同时，Monad 会以线性顺序对区块中的交易进行排序，并顺序更新每个交易。为了比当前以太坊客户端提供的状态更有效地维护和访问区块链数据，Monad 创建了自己的定制 MonadDB，这是为区块链本地构建的。 4）Aptos：利用 Block-STM，这是一种软件事务内存（STM）并发控制机制的修改实现。Block-STM 是一个多线程并行执行引擎，它允许乐观并行执行。交易在区块内被预排序和策略性地排序，这对于有效解决冲突和重新执行交易至关重要。Aptos 的研究发现，使用 Block-STM 的并行化理论上可以支持高达 160,000 TPS。 5）Sui：采用了自定义的 Move 实现，该实现从原始的 Diem 设计中改变了存储模型和资产权限。与 Solana 类似，Sui 实施了确定性并行执行，要求交易提前声明它们需要访问的账户。 6）Movement Labs：作为 Move 开发者的 AWS 类执行即服务平台，Movement 将并行化作为核心设计特性。MoveVM 是一个模块化的执行环境，它允许区块链网络根据需要扩展和调整其交易处理能力，以支持日益增长的交易量，增强其并行处理和执行交易的能力。Movement 还将推出 M2，这是一个将与 EVM 和 Move 客户端互操作的 ZK-rollup。M2 将继承 Block-STM 并行化引擎，并有望因此实现数万 TPS。（ 来源 ）
7️⃣ 【英文】解读 Vitalik 最新提案 EIP-7702：将彻底改变 Web3 应用程序交互方式？
导读：Vitalik Buterin 最新提出了 EIP-7702 提案。Polygon 开发者关系工程师 Jarrod Watts 撰文对 EIP-7702 的有关工作原理及其提到的其他三个提案 EIP-4337、EIP-3074 及 EIP-5003 相关进行了介绍。
Jarrod Watts: EIP-4337：于 2023 年 3 月在主网上线，允许用像账户一样编写智能合约，以便它们可以验证和执行交易，这改进了许多用户体验（UX）。但问题是 EOA 仍然是迄今为止使用最广泛的账户类型。而由于 Web3 应用缺乏对连接智能合约账户的原生支持，如今大多数人仍通过 MetaMask 等插件钱包使用 EOA。
EIP-3074：这个提案其实是在 EIP-4337 之前提出的，但是它尚未合并到主网。EIP-3074 目标是赋予 EOA 更多权力，允许他们将其 EOA 的控制权委托给智能合约。该提案添加了两个新的操作码：AUTH 及 AUTHCALL。这实现了与 EIP-4337 许多相同的用例，而无需每个用户部署新的智能合约。但其也存在争议，「如果有人制定恶意合约并且用户委托给他们怎么办？」解决这个问题的方法是钱包服务提供商甚至不允许用户对任何合约进行授权，他们可能会保留一份用户可以委托授权的智能合约白名单列表，并且此列表之外的任何合约都不会显示给用户。
EIP-5003：添加了另一个操作码「AUTHUSURP」，它将代码部署在 EIP-3074 授权地址。其和 EIP-3074 的主要区别是 EIP-3074 是对智能合约的临时委托，而 EIP-5003 是从 EOA 永久迁移并从 EOA 转换至智能合约账户。但这两个方案存在的问题是与通过 EIP-4337 的当前账户抽象方案不太兼容；
EIP-7702：提出了一种同时接受 contract_code 和签名字段的新交易类型，在开始执行交易时，它将签名者账户的合约代码设置为 contract_code。在交易结束时，它会将代码重新设置为空。EIP-7702 并没有引入新的操作码，而是定义了要调用的函数此外，该提案与为 EIP-4337 构建的所有账户抽象工作高度兼容。【原文为英文】（ 来源 ）
8️⃣ 【英文】可验证计算：如何使用加密扩展信任？
导读：可验证计算通过证明某些最终状态是对某些程序的一组输入的结果，来提供数学上有保证的完整性。Archetype 合伙人 Dmitriy Berenzon 撰文概述了可验证计算的历史和用例，并对可验证计算项目的框架进行了评估。
Dmitriy Berenzon: 用例：1）隐私保护：Verifiable compute 技术利用零知识证明确保隐私，包括花费密钥、未花费的交易笔记和防止双重花费、价值守恒以及 Merkle 树的有效性。然而，主流采用这些解决方案时常面临监管要求难以符合的问题。因此，新项目利用可验证计算提供保障，例如用户可生成证明，证明未与 OFAC 名单上的任何人互动，且隐私属性可根据需要调整，揭示地址连接但保持价值和金额隐藏；
2）状态和计算压缩：例如 ZKRU 和协处理器，ZKRU 通过维护分区的持久状态，定期发布并在结算层最终确定，从而提高区块链的执行吞吐量。而协处理器允许区块链应用使用链外计算，同时访问底层链的全部状态，而不会给应用本身增加任何信任假设。使用此属性的另一个用例是链上游戏。用户可以在本地模拟游戏，提供游戏结束状态的证明，然后对其进行无信任验证，而不是验证链上游戏的单个操作；
3）数据完整性：可验证计算可用于证明来自链上或链下来源的某些数据及对该数据的任何额外计算都是准确的，没有被篡改过。这样就有了一类可定义为可验证的算子，可用于多种应用中，如去中心化交易所的价格馈送，以及在链上获取任意 Web2 数据和身份。可验证计算还可通过在电路中执行价格更新和签名验证，并在链上发布包含签名更新的证明，从而在一般情况下用于扩展计算器。它还可用于构建可验证数据库，通过证明数据注入和检索的正确性来确保数据来源；
4）机器学习（zkML）：可用于将机器学习模型的执行委托给服务提供商，并获得证明确保模型输出的正确性，例如公共模型 / 私人输入、私人模型 / 公共输入等；
5）证明生成与聚合：某些可验证计算系统的功能之一是递归，即通过使用一个证明的输出作为另一个证明的输入来生成「证明的证明」。这可以通过聚合不同来源的证明并递归证明到一个单一证明中来降低验证成本，从而分摊所有参与方的成本。【原文为英文】（ 来源 ）
