| timezone |
|---|
Asia/Shanghai |
请在上边的 timezone 添加你的当地时区，这会有助于你的打卡状态的自动化更新，如果没有添加，默认为北京时间 UTC+8 时区 时区请参考以下列表，请移除 # 以后的内容
timezone: Pacific/Honolulu # 夏威夷-阿留申标准时间 (UTC-10)
timezone: America/Anchorage # 阿拉斯加标准时间 (UTC-9)
timezone: America/Los_Angeles # 太平洋标准时间 (UTC-8)
timezone: America/Denver # 山地标准时间 (UTC-7)
timezone: America/Chicago # 中部标准时间 (UTC-6)
timezone: America/New_York # 东部标准时间 (UTC-5)
timezone: America/Halifax # 大西洋标准时间 (UTC-4)
timezone: America/St_Johns # 纽芬兰标准时间 (UTC-3:30)
timezone: America/Sao_Paulo # 巴西利亚时间 (UTC-3)
timezone: Atlantic/Azores # 亚速尔群岛时间 (UTC-1)
timezone: Europe/London # 格林威治标准时间 (UTC+0)
timezone: Europe/Berlin # 中欧标准时间 (UTC+1)
timezone: Europe/Helsinki # 东欧标准时间 (UTC+2)
timezone: Europe/Moscow # 莫斯科标准时间 (UTC+3)
timezone: Asia/Dubai # 海湾标准时间 (UTC+4)
timezone: Asia/Kolkata # 印度标准时间 (UTC+5:30)
timezone: Asia/Dhaka # 孟加拉国标准时间 (UTC+6)
timezone: Asia/Bangkok # 中南半岛时间 (UTC+7)
timezone: Asia/Shanghai # 中国标准时间 (UTC+8)
timezone: Asia/Tokyo # 日本标准时间 (UTC+9)
timezone: Australia/Sydney # 澳大利亚东部标准时间 (UTC+10)
timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12)
-
自我介绍
Web3 从业近三年，全栈工程师。
-
你认为你会完成本次残酷学习吗？
会！
今天阅读了 el-specs。其中设计到了大量的数学公式，所以结合 AI 帮助阅读。
大致整理了一个大纲：
让我为您总结这份关于以太坊执行层(EL)规范的文档:
# 主要主题
1. 执行层状态转换函数(STF)
2. 区块头验证
3. 交易执行流程
4. Gas定价和经济模型
5. Blob Gas机制
# 核心要点
## 状态转换功能
- 执行层专注于执行状态转换函数(STF),主要解决两个问题:
- 区块是否可以添加到区块链末尾
- 状态如何变化 [1]
## 区块验证流程
- 包括区块头验证、Gas使用验证、父区块验证等多个步骤
- 验证过程确保每个区块符合以太坊协议规则 [3]
## 交易执行机制
- 交易执行分为多个阶段:
- 初始化检查点状态
- 交易规范化和子状态初始化
- 主执行阶段
- 临时状态、预终态和最终状态的处理 [19][20]
## Gas经济模型
- 采用EIP-1559定义的动态基础费用机制
- 包含目标Gas限制、基础费用调整等机制
- 旨在提高网络效率和费用可预测性 [5][7]
## Blob Gas创新
- 引入了新的Blob交易类型
- 使用动态定价机制调节Blob Gas价格
- 设定了目标Blob Gas(~400KB)和最大限制(~800KB) [12][13]
# 技术亮点
1. 采用自然数作为区块参数,简化了计算和验证流程 [7]
2. 引入了访问列表(Access List)机制优化状态访问成本 [14]
3. 实现了可预测的基础费用调整机制 [5]
4. 集成了Blob交易支持,增强了Layer 2扩展性 [12]
# 重要更新
- 更新了状态转换函数的实现
- 优化了Gas计算模型
- 增加了Blob交易支持
- 改进了区块验证机制 [1][3][12]
这份规范文档详细定义了以太坊执行层的核心机制,为客户端实现提供了明确的技术指导。
对于其中 Blob 的内容需要学习下，明天整理一波内容。
今天主要学习 Blob 交易。
## 什么是 Blob 交易？
Blob 交易(blob-carrying transactions)是在 EIP-4844 中引入的一种全新的以太坊交易类型。这种交易可以携带大量的数据（blob），但这些数据不能被 EVM（以太坊虚拟机）直接访问 [4]。
## 主要特点
1. **数据存储方式**：
- Blob 数据会被临时存储在信标节点(beacon node)中一段时间
- 这些数据不会永久保存在以太坊的历史记录中
- 数据会在一定时间后被自动删除 [1]
2. **主要用途**：
- 主要面向 Layer 2 扩容解决方案，特别是 Rollup
- Rollup 的排序器(sequencer)可以使用 blob 交易来提交批量交易数据
- 显著降低 L2 解决方案的成本 [2]
## 技术影响
1. **性能提升**：
- 引入了新的数据结构来处理大量数据
- 通过将数据从主链中分离出来，提高了网络效率
- 被称为"原型分片"(Proto-danksharding)的重要组成部分 [3]
2. **成本优化**：
- 显著降低了 Layer 2 解决方案的数据存储成本
- 为未来的完整分片技术铺平道路
- 提供了更经济的数据可用性解决方案 [2]
## 实际应用
1. **Layer 2 优化**：
- Rollup 可以使用 blob 交易来提交更多的交易数据
- 降低了最终用户的交易成本
- 提高了整体的交易吞吐量 [1]
2. **未来发展**：
- 作为完整分片(Full Danksharding)的过渡方案
- 为以太坊的可扩展性提供了重要基础
- 有助于实现更高效的数据处理机制 [3], [4]
## 局限性
1. **数据访问**：
- Blob 数据不能被智能合约直接访问
- 主要用于数据可用性而非计算
- 数据存储时间有限 [4]
2. **使用场景**：
- 主要针对特定用例（如 Rollups）
- 不是所有应用都能直接受益
- 需要专门的集成支持 [2], [3]
昨天关于 Blob 的内容还看到一篇不错的文章 What is EIP-4844? Proto-Danksharding and Blob Transactions Explained 。
今天主要阅读 el-architecture 中的内容。了解到原来以太坊有两种主要的交易池，Blob 的交易顺序和传统的不大一样，会基于以下顺序排列：
- 交易的 gas 价格
- blob 的大小
- 交易进入池的时间
今天的内容主要感兴趣的在于 EVM 这块，明天再阅读下相关的内容。
# 客户端架构总结
## 1. 概述
以太坊的客户端架构不仅仅是执行交易的基础层，它还承担了多个关键职责，包括验证区块链数据、存储本地副本、通过点对点协议进行网络通信、维护交易池，以及满足共识层的要求。这些功能确保了以太坊网络的稳健性和完整性。[1]
## 2. 关键概念
### 2.1 虚拟化中央处理单元 (CPU)
以太坊围绕一个虚拟化的中央处理单元（EVM）构建，确保无论在何种硬件上执行，结果都是一致的。EVM 作为以太坊程序的虚拟执行引擎，促进了所有以太坊客户端之间的共识。[2]
### 2.2 状态机
以太坊作为一个通用计算系统，运作如同状态机，能够根据输入在不同状态之间转换。与比特币不同，以太坊维护一个全局状态，包含地址、余额、合约代码和数据。[2]
## 3. 交易流程
交易在执行层客户端的内存池中初步存储，然后通过点对点通信传播。每个接收者在广播交易之前会确认其有效性。与执行层的通信通过标准化的 JSON-RPC API 进行，这使得外部查询以太坊状态或发送交易成为可能。[3]
## 4. 架构组件
### 4.1 引擎 API
执行层客户端通过 Engine API 与共识层连接，提供两个主要的端点：**新负载**和**分叉选择更新**，分别用于有效负载的验证和插入，以及状态同步和区块构建。[3][4]
### 4.2 状态转换
状态转换是通过交易触发的，该过程在 EVM 中进行。如果交易被视为合法，则会导致以太坊网络的状态变化。[2][5]
## 5. 数据存储
以太坊客户端需要将区块链和状态数据存储在磁盘中，以验证新块、检查历史记录并为网络中的其他节点提供服务。客户端通常会维护多个数据库以处理不同类型的数据，例如历史数据库和当前状态的 trie 结构数据库。[18]
## 6. 交易池
以太坊有两种主要的交易池：
1. **传统池**：由 Geth 管理，使用价格排序的堆或优先队列来组织交易。
2. **Blob 池**：采用不同的机制进行操作，具有独特的优先级堆用于交易驱逐。[18]
## 7. 共识引擎
执行层有自己的共识引擎（ethone），与其副本的信标链协作，功能约为共识层的全功能共识引擎的一半。[9]
## 8. 结论
以太坊的客户端架构通过多层次的设计和虚拟化技术，确保了其在不同硬件上的一致性和可靠性，同时通过复杂的交易处理和状态管理机制，维持了网络的稳定性和安全性。
---
今天通过 AI 快速把剩余的内容了解了一遍，总体来说没什么感兴趣的点，加上大量的公式就更没兴趣了，准备阅读下 布拉格升级 文档里的内容。
今天复习了下 EIP4337 的内容，顺带了解了下目前账户抽象的使用情况，了解下来发现目前这块推进的也并不是很多，业内并不是很看好这个前景。顺带学习了这次布拉格升级中的 EIP7702。
是的，我需要纠正之前的回答。EIP-7702 确实是与账户抽象（Account Abstraction）相关的重要提案。让我重新详细说明：
### EIP-7702 概述
EIP-7702 是以太坊网络中关于账户抽象的重要改进提案，计划在未来的 Pectra 硬分叉（预计2025年）中实施。这个提案旨在让智能合约账户能够像外部拥有账户(EOA)一样发起和执行交易，从而实现真正的账户抽象。[2]
### 核心目标
1. **移除 EOA 依赖**
- 计划逐步取代传统的外部拥有账户
- 将所有账户转换为智能合约账户
- 提供更灵活的账户管理机制 [4]
2. **改进交易处理**
- 允许智能合约账户直接发起交易
- 无需依赖外部账户触发
- 简化用户交互流程 [1]
### 主要优势
1. **增强安全性**
- 支持更复杂的验证逻辑
- 可以实现多重签名
- 提供更灵活的访问控制 [3]
2. **改善用户体验**
- 简化交易流程
- 降低使用门槛
- 支持更多创新功能 [1]
3. **开发灵活性**
- 允许开发者自定义账户行为
- 支持复杂的交易逻辑
- 便于集成新功能 [4]
### 与 EIP-3074 的关系
EIP-7702 和 EIP-3074 共同构成了以太坊账户抽象路线图的重要组成部分。这两个提案相互补充，共同推动以太坊网络向更灵活、更用户友好的方向发展。[3]
### 未来展望
1. **生态系统影响**
- 预计将推动智能账户的广泛采用
- 促进新型应用场景的出现
- 改变用户与区块链交互的方式 [2]
2. **技术革新**
- 为 DApp 开发提供新可能
- 简化智能合约开发
- 提升整体用户体验 [4]
这个提案代表了以太坊在账户抽象方向上的重要一步，将为整个生态系统带来深远的影响。[1]