diff --git a/.starrydeserts_image/Layered-Architecture.png b/.starrydeserts_image/Layered-Architecture.png new file mode 100644 index 0000000..8a6c7b0 Binary files /dev/null and b/.starrydeserts_image/Layered-Architecture.png differ diff --git a/CHENFANGC.md b/CHENFANGC.md index 92872d3..90ea742 100644 --- a/CHENFANGC.md +++ b/CHENFANGC.md @@ -165,4 +165,19 @@ EOA 可以发起交易，交易类型包括： 共识层客户端 共识层客户端是实现以太坊共识协议的软件。不同的客户端可能在性能、编程语言和功能上有所差异，但它们都遵循相同的协议规范，以确保网络的互操作性。 +### 2025.02.11 + +### Development 开发 + +包括计算机、数学、密码学、算法、编程、网络、分布式系统和区块链、安全、终端、shell 脚本和版本控制…… +（学不完，看不懂 T.T……今天工作量大，没有看视频啊） + +### 2025.02.12 + +### 以太坊和形式化验证 + +- 协议验证、智能合约验证 + +安全和活跃的保证是以太坊去中心化基础设施的核心。形式化验证在验证以下各项的正确性方面起着关键作用 + diff --git a/HeliosLz.md b/HeliosLz.md index 9ba209a..bea409e 100644 --- a/HeliosLz.md +++ b/HeliosLz.md @@ -313,5 +313,195 @@ ECC 是一种 非对称加密算法，基于椭圆曲线数学，提供与 RSA * 权益证明改进 * 状态和历史到期 +### 2025.02.11 + +Week 1 | Protocol Intro + +**以太坊的起源与设计理念** + +* 以太坊的设计受到 UNIX 操作系统 和 自由软件运动（FOSS） 的启发。UNIX 的 模块化设计 和 Bell Labs 的开放协作环境影响了以太坊的开发方式。以太坊的目标是通过自由、开放和透明的软件赋能用户和开发者，确保 去中心化 和 信任无须信任。 +* 自由软件运动 的思想对于以太坊及所有加密货币至关重要。以太坊的开发遵循 FOSS 原则，以确保软件的开放性和用户的自由，进一步保障以太坊的安全性、去中心化性和信任性。 +* 密码学革命 是以太坊发展的基础。现代加密技术，尤其是 非对称加密，为 数字隐私 和 安全通信 打下了基础，影响了加密货币的发展。 +* 早期的 Cypherpunk 运动也为以太坊的去中心化理念奠定了基础，他们主张建立一个基于 无信任、无边界 技术的数字世界。 + +**以太坊的协议设计与发展** + +以太坊的设计从 比特币 和早期区块链技术中汲取灵感，最终形成了 通用区块链计算平台。最初的 白皮书 和 黄皮书 定义了以太坊的技术规范，随着时间的推移，这些设计通过 EIP（以太坊改进提案） 进行了不断的更新和改进。 + +以太坊的设计原则包括： +* 简单性：保持设计和实现的简洁。 +* 普适性：适用于各种应用场景。 +* 模块化：分解为多个可独立发展的模块。 +* 非歧视性：保障每个人都能平等参与。 +* 敏捷性：快速适应新变化。 + +**以太坊的网络架构** + +* 以太坊网络由两个主要的层级构成：执行层（Execution Layer） 和 共识层（Consensus Layer）。执行层负责处理交易和管理状态（例如账户和智能合约数据），而共识层通过 权益证明（PoS） 确保网络的安全性和容错性。 + +**以太坊的客户端与实施** + +* 以太坊有多种客户端实现，允许开发者使用不同的编程语言来实现 执行层（EL） 或 共识层（CL）。这些客户端组成了以太坊的 节点（Node），每个节点都参与以太坊网络的运作。 +* 以太坊采用 客户端多样性 的策略，不依赖于单一的官方实现，确保即使某个客户端出现问题，网络的其余部分仍然能够正常运行。 + +**以太坊的研发与协调** + +* 以太坊的开发是开放的、公开的，全球有 20多个开发团队 在共同推动以太坊的前进。不同的开发人员在不同领域内发展专业知识，并通过模块化的设计进行协作。 +* 核心开发者会议（ACD） 定期讨论共识层和执行层的进展，确保以太坊的研发进程得到协调并向前推进。以太坊的改进提案（EIP）通过 社区讨论 来推动技术创新。 + +**以太坊的测试与验证** + +* 由于以太坊协议的不断发展和多样化的客户端实现，测试成为确保网络安全的重要环节。测试工具包括 状态转换测试、模糊测试 和 RPC 测试 等，确保网络升级和新功能的稳定性。 + +### 2025.02.12 + +**学习小组第二周 | 执行层（Execution Layer）** + +预读材料： + +节点和客户端 + +1. 节点（Node） + +在以太坊网络中，节点是任何参与网络的计算机系统，负责验证交易、维护区块链状态并传播信息。节点根据其角色和功能，可以分为几种类型： + +1.1 全节点（Full Node） + +全节点是最重要的节点类型，它存储并验证整个区块链的历史数据。全节点会下载并验证所有的区块和交易，确保每个区块都符合以太坊协议的规则。全节点负责： + +* 存储整个区块链数据（包括所有交易、区块头等）。 +* 验证每个新块是否符合共识规则。 +* 参与网络中的共识过程，帮助确保链的安全性。 +* 执行和验证每个交易（执行层部分）。 + +全节点有助于去中心化，因为它们不依赖于第三方进行数据验证。 + +1.2 轻节点（Light Node） + +轻节点不保存完整的区块链数据，而是只存储与当前活动相关的数据。这使得轻节点在资源消耗上比全节点低。轻节点通过与全节点连接来获取区块头和必要的数据。它们的主要特点是： + +* 只保存区块头，不存储完整的交易和状态数据。 +* 依赖全节点提供交易的验证结果。 +* 适用于需要低资源消耗的场景，例如手机钱包和轻量级应用。 + +轻节点的工作效率较高，但需要与其他全节点交互来验证交易和区块。 + +1.3 归档节点（Archive Node） + +归档节点是全节点的一种特殊类型，它不仅存储整个区块链的数据，还存储每个区块和交易的所有历史状态。归档节点的作用是提供历史数据查询的功能，特别适用于需要审计或历史数据的情况。归档节点的特点是： + +* 存储所有区块和交易的完整历史。 +* 提供完整的状态数据，可以查询历史时刻的状态。 +* 存储所有的帐户余额、智能合约数据等详细信息。 + +归档节点一般用于开发、分析和区块链数据分析场景，不常见于普通的以太坊网络使用。 + +2. 客户端（Client） + +客户端是与以太坊网络交互的软件，负责与其他节点进行通信，并执行相关任务，如发送交易、验证区块、同步状态等。每个客户端实现了以太坊协议的不同部分，具体有多个实现版本。客户端主要负责： + +* 与其他节点建立连接。 +* 获取、验证和处理区块和交易。 +* 与执行层、共识层以及网络层交互。 + +2.1 不同类型的客户端 + +以太坊有多个客户端实现，每个客户端都遵循相同的协议标准（以太坊协议），但是其内部实现可能有所不同。常见的以太坊客户端包括： + +* Geth（Go-Ethereum）：这是最广泛使用的客户端之一，采用 Go 编程语言编写。Geth 提供了完整的以太坊节点功能，包括全节点、轻节点和矿工功能。它支持以太坊的主网、测试网和私人链。 +* Besu：这是一个由 Hyperledger 项目支持的以太坊客户端，采用 Java 编写。Besu 主要面向企业和企业级解决方案，支持以太坊 1.x 和 2.x。 +* Nethermind：另一个以太坊客户端实现，采用 C# 编写，注重性能和对 .NET 环境的支持。 +* OpenEthereum（以前的 Parity）：这个客户端采用 Rust 编写，旨在提供高性能和轻量级的以太坊实现。它通常用于高效的交易处理和运行。 +* Lighthouse、Prysm、Nimbus：这些客户端是以太坊 2.0 的实现（即信标链客户端），它们实现了以太坊的共识层，用于支持以太坊的 PoS（权益证明）机制。 + +2.2 客户端的功能 + +客户端根据其类型和功能，承担着不同的职责： + +* 执行层（EL）客户端：处理交易的执行和状态更新。它通过虚拟机（EVM）执行每个交易，并更新状态树（state trie）。Geth、Besu 和 OpenEthereum 都是典型的执行层客户端。 +* 共识层（CL）客户端：与 PoS（权益证明）机制相关，负责维护和验证信标链（Beacon Chain）的状态。共识层客户端如 Prysm、Lighthouse 和 Nimbus 是以太坊 2.0 的组成部分。 +* P2P 网络层客户端：负责与其他节点进行通信，传播区块和交易。通过开发 P2P 协议，节点能够有效地传播信息并同步状态。 + +2.3 客户端交互 + +客户端通过以下方式与以太坊网络和其他节点进行交互： + +* JSON-RPC：客户端通过 JSON-RPC 接口与网络中的其他节点交互。这些接口包括发送交易、查询区块、获取节点信息等常见操作。 +* Gossip协议：节点通过 gossip 协议传播交易和区块。每当一个节点接收到新的区块或交易时，它会将其传递给其他连接的节点，确保网络中的每个节点都能同步。 +* Snap Sync：这种同步机制允许节点快速同步整个链的状态，它通过下载和应用块和状态的增量更新来实现高效的同步。 + + +以太坊：机制（基于这些幻灯片的讲座也可以在 YouTube 上观看：《以太坊执行层概述 - Dan Boneh》） + +1. 执行层概述 + +现实生活类比：银行的交易系统 + +想象你在一个银行账户中进行资金转账。这就类似于以太坊中的交易和状态更新。当你发起转账时： + +* 银行系统需要验证你的账户余额是否足够（类似于以太坊检查交易是否合法）。 +* 然后，它会执行转账操作，将资金从一个账户转移到另一个账户（类似于以太坊执行交易并更新状态树）。 +* 最后，银行系统更新你的账户余额，并将这次交易记录保存下来（类似于以太坊更新区块链的状态）。 + +2. 区块验证 + +现实生活类比：交易验证和审核 + +假设你去银行办理转账，银行会进行一系列的检查： + +* 交易验证：检查你是否有足够的余额，转账金额是否合理，接收人的账户是否有效等。 +* 状态更新：银行会根据验证结果，更新你的账户余额，并在系统中保存这次交易。 + +在以太坊中，每个区块都包含一组交易，执行层会逐一验证这些交易是否合法（如检查签名、余额、时间戳等）。如果某个交易不合法，整个区块会被拒绝。 + +3. EVM：以太坊虚拟机 + +现实生活类比：计算机处理器 + +以太坊虚拟机（EVM）类似于银行后台的计算机系统。每笔交易就像一条指令，EVM 就是执行这些指令的计算机处理器。每一条指令（如“转账”或“调用智能合约”）都会消耗一定的计算资源（类似于银行系统消耗资源处理转账）。EVM 会逐步执行这些指令，并更新状态。 + +4. Gas 机制 + +现实生活类比：交易手续费 + +当你去银行办理转账，银行通常会收取一定的手续费。这个手续费的多少取决于你转账的金额和银行的费用政策。以太坊中的 Gas 费用类似于这个手续费，它是执行交易和合约的代价。 + +* 比如，当你转账时，银行会检查你支付的手续费是否足够覆盖银行的成本，确保它能够处理你的请求。同样，以太坊会检查你支付的 Gas 是否足够覆盖执行交易的成本。 + +5. EIP-1559 费率机制 + +现实生活类比：动态收费系统 + +假设你在不同的时段去银行，银行可能会根据拥挤程度调整手续费：比如在高峰时段，手续费可能会增加；在低谷时段，手续费可能会降低。这类似于以太坊的 EIP-1559 机制，它通过动态调整“基础费用”（base fee），使得交易费用在网络负载较高时增加，负载较低时减少，从而确保交易的可预测性。 + +6. 状态转换函数（State Transition Function） + +现实生活类比：银行账单 + +当你进行交易时，银行系统会根据你的转账记录更新你的账单状态。这个过程就像以太坊中的状态转换函数。每一笔交易都改变了账户的状态（余额），并更新到系统中。状态转换函数确保每个账户的余额和状态正确。 + +7. 节点类型 + +现实生活类比：银行不同的服务 + +* 全节点（Full Node）：就像银行的总账户系统，保存了所有的交易记录和账户信息，任何人都可以查询到所有的账单和历史交易。 +* 轻节点（Light Node）：类似于银行的客户应用，你不需要保存所有的历史账单，只需要知道你自己的账户余额和最近的交易。 +* 归档节点（Archive Node）：相当于银行的历史档案系统，专门用来存储所有的历史交易记录，可以查询过去很久以前的转账和交易信息。 + +8. P2P 协议：节点之间如何沟通 + +现实生活类比：银行之间的消息传递 + +当你在一个银行账户进行转账时，可能需要通过不同的银行进行资金转移。这就像以太坊的 P2P 协议，银行之间需要互相传递消息，确认转账的详细信息。在以太坊网络中，节点之间也通过 P2P 协议进行数据交换，确保每个节点都能得到最新的区块信息和交易。 + +9. Snap Sync + +现实生活类比：银行的实时更新 + +当你登录银行账户时，银行会迅速同步你最新的账户信息。这就像以太坊的 Snap Sync，它能确保节点快速同步最新的区块链状态，以便他们可以更快地验证和执行交易。 + +* 阶段 1：类似于银行下载最新的账户和交易数据。 +* 阶段 2：类似于银行确保所有账户信息和交易记录没有被篡改或遗漏。 + diff --git a/JeasonZhang.md b/JeasonZhang.md index 48892e5..32f9025 100644 --- a/JeasonZhang.md +++ b/JeasonZhang.md @@ -441,6 +441,271 @@ ### 2025.02.11 -内容 +##### **EPF WIKI WEEK5** + +#### **I. 核心学习目标** + +**主题**: 以太坊研究生态与路线图演进 +**目标**: 掌握以太坊六大发展阶段（Merge/Surge/Scourge/Verge/Purge/Splurge）的技术规划及当前研究热点。 + +------ + +#### **II. 以太坊路线图解析** + +##### **1. 六大发展阶段** + +| 阶段 | 核心目标 | 关键技术 | +| ----------- | ---------------- | ------------------------------------------------------------ | +| **Merge** | PoS共识完善 | 单槽最终性（SSF）、秘密领导者选举（SLE）、提款机制优化 | +| **Surge** | 扩容与数据可用性 | EIP-4844（Blob交易）、数据可用性采样（DAS）、ZK Rollup互操作性 | +| **Scourge** | MEV治理与抗审查 | ePBS（Enshrined PBS）、MEV销毁、质押上限机制 | +| **Verge** | 状态验证效率提升 | Verkle树、SNARK化（信标链状态转换、EVM验证） | +| **Purge** | 协议简化 | EIP-4444（历史数据修剪）、状态过期机制 | +| **Splurge** | 用户体验优化 | 账户抽象（ERC-4337）、EIP-1559最终形态、深度密码学整合 | + +------ + +#### **III. 当前研究热点** + +##### **1. 密码学前沿** + +- **KZG多项式承诺**：用于Blob数据验证（[KZG仪式](https://scroll.io/blog/kzg)） +- **Verkle树结构**：替代Merkle Patricia Trie，提升状态证明效率（[Vitalik解析](https://vitalik.eth.limo/general/2021/06/18/verkle.html)） + +##### **2. 扩容技术** + +- **数据可用性采样（DAS）**：通过随机抽样验证数据可用性 +- **跨Rollup互操作**：标准化跨链消息协议 + +##### **3. 抗MEV机制** + +- **包含列表（Inclusion Lists）**：防止交易审查 +- **MEV-Burn**：通过协议内拍卖销毁MEV收益 + +------ + +#### **IV. 关键升级进展** + +##### **1. 近期里程碑** + +- **Dencun升级**：EIP-4844实施，降低Layer2成本 +- **Pectra升级**：Verkle树预编译合约部署 + +##### **2. 开发者工具** + +- **Helios轻客户端**：Rust实现的快速同步客户端（[构建指南](https://a16zcrypto.com/posts/article/building-helios-ethereum-light-client/)） +- **EVM对象格式（EOF）**：优化合约代码存储结构 + +------ + +#### **V. 学习资源推荐** + +##### **必读材料** + +- [以太坊终极形态](https://vitalik.eth.limo/general/2021/12/06/endgame.html)（Vitalik长文） +- [Blob空间经济学](https://domothy.com/blobspace/)（Domothy分析） +- [以太坊数据结构演进](https://arxiv.org/pdf/2108.05513.pdf)（学术论文） + +##### **实践指南** + +- [EthRoadmap.com](https://ethroadmap.com/)：交互式路线图可视化 +- [执行票据提案](https://ethresear.ch/t/execution-tickets/17944)：参与协议改进讨论 + +------ + +#### **VI. 技术术语对照** + +| 英文术语 | 中文解释 | +| -------------------------- | ----------------------- | +| Single Slot Finality | 单槽最终性 | +| Data Availability Sampling | 数据可用性采样 | +| Enshrined PBS | 协议内提议者-构建者分离 | +| Verkle Proofs | Verkle树证明 | +| MEV Burn | MEV销毁机制 | + +------ + +通过本课程的系统学习，开发者可全面把握以太坊技术演进的宏观框架，深入参与核心协议研究。建议结合[Ethresear.ch论坛](https://ethresear.ch/)跟踪最新提案，通过节点工作坊实践客户端运维。 + +### 2025.02.12 + +##### **EPF WIKI Node Workshop** + +#### **I. 核心学习目标** + +**主题**: 以太坊客户端实践操作 +**目标**: 掌握执行层（EL）与共识层（CL）客户端的部署、配置及运维技能。 + +------ + +#### **II. 环境准备** + +##### **1. 系统要求** + +- **推荐系统**: Debian 12（支持Ubuntu/macOS，建议使用虚拟机统一环境） + +- **硬件配置**: 测试网节点无需高性能硬件（2核CPU/4GB RAM/50GB存储） + +- 基础工具安装: + + ```bash + sudo apt update && sudo apt install -y curl git gpg docker.io build-essential + ``` + +##### **2. 前置知识** + +- **客户端架构**: 复习[节点架构文档](https://ethereum.org/en/developers/docs/nodes-and-clients/node-architecture/) +- **Linux基础**: 掌握[基础命令行操作](https://ubuntu.com/tutorials/command-line-for-beginners) + +------ + +#### **III. 客户端部署流程** + +##### **1. 客户端选择与获取** + +- **推荐组合**: Geth（EL） + Lighthouse（CL） + +- 二进制验证（以Geth为例）: + + ```bash + # 下载签名文件 + curl -O https://geth.ethereum.org/geth-linux-amd64-1.13.0-6c74b4e6.sig + # 验证签名 + gpg --verify geth-linux-amd64-1.13.0-6c74b4e6.sig + ``` + +##### **2. Docker快速部署** + +```bash +# 启动Geth测试网节点 +docker run -d -p 8545:8545 -v /data/geth:/root/.ethereum \ + ethereum/client-go --goerli --http --http.addr 0.0.0.0 + +# 启动Lighthouse共识客户端 +docker run -d -p 9000:9000 -p 9001:9001 -v /data/lighthouse:/root/.lighthouse \ + sigp/lighthouse lighthouse beacon --network holesky +``` + +##### **3. 测试网配置** + +- Holesky测试网: + + ```bash + geth --holesky --syncmode snap --http + lighthouse beacon --network holesky + ``` + +- Ephemery自定义创世块: + + ```bash + geth init --datadir ./ephemery ephemery-genesis.json + ``` + +------ + +#### **IV. 节点运维实践** + +##### **1. RPC接口使用** + +- 基础访问: + + ```bash + curl -X POST -H "Content-Type: application/json" \ + --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \ + http://localhost:8545 + ``` + +- 控制台交互: + + ```bash + geth attach http://localhost:8545 + > eth.syncing + ``` + +##### **2. 验证者管理** + +- 质押存款: + + ```bash + lighthouse account validator deposit \ + --network holesky \ + --keystore ./validator_keys \ + --deposit-value 32 + ``` + +##### **3. 系统服务配置** + +- systemd服务文件示例（Geth）: + + ```ini + [Unit] + Description=Geth Execution Client + After=network.target + + [Service] + ExecStart=/usr/bin/geth --http --syncmode snap --cache 2048 + Restart=always + User=geth + + [Install] + WantedBy=multi-user.target + ``` + +------ + +#### **V. 进阶实践建议** + +##### **1. 节点监控** + +- Prometheus+Grafana方案: + + ```bash + # 安装Prometheus + docker run -d -p 9090:9090 -v /prometheus-data:/prometheus prom/prometheus + # 配置Grafana仪表盘（参考Coincashew指南） + ``` + +##### **2. 网络诊断** + +- P2P网络分析: + + ```bash + # 使用devp2p工具检查节点连接 + devp2p discv5 nodes -bootnodes enr://... + ``` + +##### **3. 客户端切换实验** + +- 执行层切换 + + （Geth → Erigon）: + + ```bash + erigon --chain holesky --datadir ./erigon-data --http + ``` + +- 共识层切换 + + （Lighthouse → Nimbus）: + + ```bash + nimbus_beacon_node --network=holesky --web3-url=http://localhost:8545 + ``` + +------ + +#### **VI. 关键资源推荐** + +- **节点维护指南**: [EthStaker Holesky指南](https://github.com/eth-educators/ethstaker-guides) +- **验证者监控**: [Grafana仪表板配置](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet/part-i-installation/monitoring-your-validator-with-grafana-and-prometheus) +- **故障排查**: [合并后节点FAQ](https://notes.ethereum.org/@launchpad/node-faq-merge) + +------ + +通过本工作坊的系统实践，开发者将具备独立部署和维护以太坊全节点的能力，为参与网络验证或协议开发奠定基础。建议从测试网开始，逐步过渡到主网节点运维。 + +### 2025.02.13 + +##### **EPF WIKI WEEK6** diff --git a/KieSun.md b/KieSun.md index 3fe1657..1537bb7 100644 --- a/KieSun.md +++ b/KieSun.md @@ -297,4 +297,52 @@ EIP-7702 和 EIP-3074 共同构成了以太坊账户抽象路线图的重要组 这个提案代表了以太坊在账户抽象方向上的重要一步，将为整个生态系统带来深远的影响。[1] ``` +### 2025.02.12 + +``` +# 以太坊共识层架构总结 + +## 核心主题 +本文主要介绍了以太坊共识层(CL)的架构设计、共识机制和工作原理。 + +## 关键要点 + +### 1. 共识协议架构 +- 以太坊采用双重共识协议组合：LMD GHOST 和 Casper FFG，合称为 Gasper [1] +- LMD GHOST 主要提供活性(liveness)，确保链的持续运行 +- Casper FFG 提供安全性(safety)，通过定期确认来保护链 [4] + +### 2. 分叉选择机制 +- 使用分叉选择规则来帮助网络达成一致的线性历史 [1][2] +- 主要通过选择"头区块"(head block)来隐式选择一个分支 +- 所有被选择的区块必须符合协议规则且其所有祖先区块也必须有效 [2] + +### 3. 系统架构组件 +主要包含两个核心组件 [6]: +- Beacon 节点：负责协调权益证明共识，与其他节点通信 +- 验证者：需要质押32 ETH，负责在PoS系统中提议区块 + +### 4. 状态转换机制 +- 每个节点通过应用状态转换函数来更新状态 [7] +- Beacon链是基于时隙(slot)驱动的，包含以下转换： + - 每时隙转换 + - 每区块转换 + - 每纪元转换 [8] + +### 5. 系统特性 +- 在网络条件良好时同时提供安全性和活性 +- 在网络分区等问题发生时优先保证活性 +- 执行层(EL)和共识层(CL)并行运行，通过Engine-API进行通信 [6] + +## 技术亮点 +- 采用模块化设计，将共识层和执行层分离 +- 通过双重共识协议互补，在实践中取得良好效果 +- 清晰的状态转换机制确保网络一致性 [7][8] + +## 实际应用 +- 以太坊主网是生产环境的实例，管理真实的ETH +- 提供测试网络供开发者和验证者测试新功能 +- 支持多客户端实现，提高系统的多样性和稳定性 [6] +``` + diff --git a/Lvista.md b/Lvista.md index 86dd0d3..646be04 100644 --- a/Lvista.md +++ b/Lvista.md @@ -239,6 +239,92 @@ happened about Tx. ### 2025.02.11 +**An Example contract: NameSystem** + +A name system on Eth: [uniswap -> addr] +> is a simplified ENS, like DNS + +Need to support three operations: +- `Name.new`(OwnerAddr, Name): intent to register +- `Name.update`(Name, newVal, newOwner) +- `Name.lookup`(Name) + +``` solidity +contract nameSys{ + struct nameEntry{ + address owner; + bytes32 value; + } + mapping(bytes32=> nameEntry) data; + + function nameNew(bytes32 name){ + //registration fee is 100 Wei + if(data[name]==0 && msg.value >=100){ + data[name].owner = msg.sender + emit Register(msg.sender, name) + } + } + + function nameUpdate(bytes32 name, + bytes32 newValue, + address newOwner) { + // check if message is from domain owner, + // and update cost of 10 Wei is paid + if (data[name].owner == msg.sender && msg.value >= 10) { + data[name].value = newValue; // record new value + data[name].owner = newOwner; // record new owner + } + } + + function nameLookup(bytes32 name) { + return data[name]; + } +} + +``` +1. ⚠️ Here the `nameNew`func is unsafe, Anyone can use this function to peek into the database or steal certain names and resell them. +2. The `nameLookup` is used by contracts, humans do not need this.(use etherscan.io) + +**EVM mechanics: execution environment** + +- The EVM is **Ethereum’s execution engine**, ensuring that smart contracts run **securely, in a decentralized, and deterministic manner**, making it the backbone of DeFi, NFTs, and DApps. +- EVM is compiled to bytecode + +| Function | Description | +|----------|------------| +| Running Smart Contracts | Interprets and executes Solidity, Vyper-based contracts | +| Decentralized Computing | Executes on all Ethereum nodes, ensuring consistency | +| Transaction Processing | Verifies transactions, updates balances and contract states | +| Maintaining Blockchain State | Manages contract storage, account data, and logs | +| Gas Fee Management | Prevents excessive computation, incentivizes validators | +| Security & Isolation | Runs contracts in a safe environment to prevent exploits | + +**Gas** + +- Every instruction costs gas. +- Different instruction costs different gas.(See https://www.evm.codes/) + > eg. SLOAD, SSTORE VS MLOAD, MSTORE, the former operate on blockchain(like disk), and the latter operate for single Tx(like RAM) +- Tx fees (gas) prevents submitting Tx that runs for many steps. +- During high load: block proposer chooses Tx from mempool +that maximize its income. +- Reducing on chain storage is advocated + ![](https://files.catbox.moe/pcntjb.png) + +**Gas prices spike during congestion** + +**Congestion** can result in an increase in gas prices, which can bring +more income for those block proposer. + +![](https://files.catbox.moe/k63zc7.png) + +**EIP1559: How to figure out this congestion issue?** + +> EIP1559, since8/2021, goal: +> - users incentivized to bid their true utility for posting Tx, +> - block proposer incentivized to not create fake Tx, and +> - disincentivize off chain agreements. + +a solution: [ Transaction Fee Mechanism Design, by T. Roughgarden, 2021 ] ### 2025.02.12 diff --git a/PubYuCHe.md b/PubYuCHe.md index 995ba66..828b29b 100644 --- a/PubYuCHe.md +++ b/PubYuCHe.md @@ -45,6 +45,51 @@ EPF #1 week - 如果發生以下情況，則可能發生錯誤 - 存在無效交易，則整個區塊無效，狀態不會更新 -### 2025.02.08 +### 2025.02.11 + +區塊建立函數 + +1. 參數部分 +- 環境 (Environment)： 這部分提供了區塊生成過程所必需的基本背景信息，例如當前時間、區塊鏈中的位置（區塊編號）、前一個區塊的資訊以及區塊費用的基準值。這些數據對確保區塊的正確生成和區塊鏈的連續性非常重要。 +- 交易池 (Tx pool)： 這是一個臨時儲存待執行交易的集合。系統會根據交易的價值（例如支付的手續費）來排序，確保高價值交易能夠優先被執行，從而最大化收益。 +- 狀態資料庫 (StateDB)： 此資料庫保存著所有與賬戶、合約狀態等相關的信息，任何交易執行後都可能對這些狀態做出改變，故需在區塊生成後更新。 +2. 返回結果 +- 區塊 (Block)： 生成的新區塊，包含了一系列已執行的交易及相關區塊資訊。 +- 更新後的狀態資料庫 (Updated StateDB)： 反映了所有交易執行後的最新狀態，這是整個區塊鏈運行過程中的核心數據。 +- 錯誤 (Error)： 在區塊生成或交易執行過程中可能出現錯誤，這一部分用來返回和記錄相關錯誤信息。 +步驟詳解 +步驟 1：追蹤 gas 使用量並存儲交易 +- 在這一階段，系統不斷從交易池中選取交易，並將它們加入到待生成的區塊中，同時監控累積的 gas 消耗。當達到預定的 gas 限制時，就不再添加新的交易，確保區塊不會因為交易數量過多而超出計算或存儲的限制。 +這裡提到的「gas」是 Ethereum 用來衡量計算工作量的單位，每個區塊都有一個最大 gas 限制（例如 3000 萬），以防止過多計算影響網絡穩定性。 +步驟 2：從交易池中取得並執行最佳交易 +- 使用 Pop() 方法從排序好的交易池中取出最有價值的交易。這裡的「最佳」交易通常是指那些支付較高手續費的交易，因為礦工（或驗證者）傾向於優先處理這些交易以獲取更多收益。 +交易通過 Ethereum 的虛擬機（VM）進行執行，執行結果會更新狀態資料庫，並將成功執行的交易記錄到區塊中。 +如果在執行過程中某筆交易被發現無效（例如簽名錯誤或執行失敗），系統會記錄錯誤，但仍會繼續處理後續交易，直到沒有足夠的 gas 或交易池被清空。 +步驟 3：使用 Finalize 函數組裝區塊 +- 最後，Finalize 函數會根據已執行的交易列表以及區塊相關的資訊（如區塊頭資料）生成一個完整且可驗證的區塊。這個區塊會被添加到區塊鏈上，成為區塊鏈歷史的一部分。 + + +狀態轉移函數 + +newPayload 函數： + +起點與檢查： 此函數是從共識層（CL）觸發的，代表一個新的區塊提案進入流程。執行層（EL）在這個階段會檢查區塊的完整性，例如確認區塊數據的正確性與一致性。 +流程延伸： 當初步檢查通過後，流程深入到 insertBlockWithoutSetHead，正式啟動區塊的鏈上添加操作。 +insertBlockWithoutSetHead 函數： + +執行與驗證： 這個函數負責將區塊中的交易執行，並對區塊內容進行各項驗證。驗證通過後，將區塊及其交易狀態寫入資料庫。 +區別與後續： 與 insertChain 函數不同，此處不會立即更新正則鏈狀態，而是需要後續額外的 SetCanonical 操作來最終確定區塊在正則鏈中的地位。這種分步驟的設計有助於更細緻地控制區塊的驗證與最終確認過程。 +insertChain 函數及其子流程： + +verifyHeaders： 在正式執行區塊之前，首先必須對區塊頭進行嚴格檢查。這包括： +EIP-1559 屬性： 確保區塊頭中的 gas 限制符合網絡規範。 +其他檢查項目： 如 gas 限制、實際使用的 gas、區塊生成時間等，確保整體數據正確無誤。 +驗證通過後，區塊才被認為是有效的，可進入下一步執行。 +Process 函數： +參數與執行環境： 該函數需要區塊數據、狀態資料庫以及虛擬機配置。這些參數共同確保區塊在執行過程中能夠正確地影響狀態。 +狀態轉移機制： Geth 使用 state_processor 來完成狀態轉移。這個過程將每筆交易依次執行，更新狀態資料庫，並計算出新的狀態。 +後續更新： 當所有交易都處理完畢後，系統會更新其他關鍵指標，最終把區塊的最終狀態寫入區塊鏈，確保區塊成為鏈上歷史的一部分。 + +### 2025.02.12 diff --git a/README.md b/README.md index 0bf8964..91a71a5 100644 --- a/README.md +++ b/README.md @@ -101,92 +101,92 @@ Telegram：https://t.me/ETHPandaOrg/5427 | Name | 2.06 | 2.07 | 2.08 | 2.09 | 2.10 | 2.11 | 2.12 | 2.13 | 2.14 | 2.15 | 2.16 | 2.17 | 2.18 | 2.19 | 2.20 | 2.21 | 2.22 | 2.23 | 2.24 | 2.25 | 2.26 | 2.27 | 2.28 | 3.01 | 3.02 | | ------------- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | -| brucexu-eth | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | -| PayFv | ⭕️ | ✅ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | | | | -| chloezhu010 | ✅ | ✅ | ⭕️ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | | | | +| brucexu-eth | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | +| PayFv | ⭕️ | ✅ | ✅ | ⭕️ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | +| chloezhu010 | ✅ | ✅ | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | coratann | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| luffythink | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| Henry | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | | -| d0d0d9 | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| henryleo | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| zhouCode | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| mrmign | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| ghx1104 | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| Coooder-Crypto | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| rayjun | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | +| luffythink | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | +| Henry | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | +| d0d0d9 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | +| henryleo | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | +| zhouCode | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | +| mrmign | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | +| ghx1104 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | +| Coooder-Crypto | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | +| rayjun | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | CJC824 | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | | William-02-02 | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| hotoo | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | +| hotoo | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | | JoscelynFarr | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| cherry-yl-sh | ✅ | ⭕️ | ⭕️ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | | -| HeliosLz | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| lllapland | ✅ | ✅ | ⭕️ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | +| cherry-yl-sh | ✅ | ⭕️ | ⭕️ | ✅ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | +| HeliosLz | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | +| lllapland | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | passer-byzhang | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| StillFantastic | ⭕️ | ✅ | ⭕️ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | | +| StillFantastic | ⭕️ | ✅ | ⭕️ | ✅ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | | debugzhao | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | -| StarryDeserts | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| KieSun | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| k66 | ✅ | ✅ | ⭕️ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | +| StarryDeserts | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | +| KieSun | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | | +| k66 | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | DVDguzhou | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | armada2013 | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| realgu | ✅ | ✅ | ⭕️ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | | -| Eizz0 | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | | -| kernel1983 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | -| JC13043DB | ✅ | ⭕️ | ⭕️ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | +| realgu | ✅ | ✅ | ⭕️ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | +| Eizz0 | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | +| kernel1983 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | +| JC13043DB | ✅ | ⭕️ | ⭕️ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | | GuoyangLiu24 | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| cooper | ⭕️ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | +| cooper | ⭕️ | ✅ | ✅ | ✅ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | | | chyyynh | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| frankmint2024 | ✅ | ⭕️ | ✅ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | | -| Amberrrrrr | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | | -| yahsinhuangtw | ✅ | ✅ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | | | | +| frankmint2024 | ✅ | ⭕️ | ✅ | ⭕️ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | +| Amberrrrrr | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | +| yahsinhuangtw | ✅ | ✅ | ✅ | ⭕️ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | | | 0xKarl98 | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| marvelshan | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | +| marvelshan | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | rogers3333 | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | deporter | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| LouisTsai-Csie | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| kidneyweakx | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | +| LouisTsai-Csie | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | +| kidneyweakx | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | keroro520 | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| huangyan0914 | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | | +| huangyan0914 | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | | 0xNezha | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | Garyamour | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | | huahuahua1223 | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| dethan3 | ✅ | ✅ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | | | | +| dethan3 | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | Azleal | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| jjeejj | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| buctor41 | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | | -| zhwindy | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| rectinajh | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | +| jjeejj | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | +| buctor41 | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | +| zhwindy | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | +| rectinajh | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | letsgoexplore | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| Lvista | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | +| Lvista | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | lanpan999 | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| liuxulife | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | | -| CHENFANGC | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| ppatrick007 | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| zt2 | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | +| liuxulife | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | +| CHENFANGC | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | +| ppatrick007 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | +| zt2 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | yiwen4 | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | affe | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| dundun930326 | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | +| dundun930326 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | Echocipher | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | -| poyucheese | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| amandakelake | ✅ | ✅ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | | | | +| poyucheese | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | +| amandakelake | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | ALiangNe | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| tienshaoku | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | | -| tannerang | ✅ | ⭕️ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | | | | -| dixia | ✅ | ✅ | ✅ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | | | | -| dajuguan | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | | +| tienshaoku | ✅ | ✅ | ✅ | ⭕️ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | +| tannerang | ✅ | ⭕️ | ✅ | ⭕️ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | +| dixia | ✅ | ✅ | ✅ | ⭕️ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | +| dajuguan | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | | timfaner | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | -| JeasonZhang | ✅ | ⭕️ | ⭕️ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | +| JeasonZhang | ✅ | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | LikKee | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| phoebe-dot | ✅ | ✅ | ✅ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | | -| PubYuCHe | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | | +| phoebe-dot | ✅ | ✅ | ✅ | ✅ | ⭕️ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | | +| PubYuCHe | ✅ | ✅ | ⭕️ | ⭕️ | ⭕️ | ✅ | | | | | | | | | | | | | | | | | | | | | evanwu | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | lknxt1995 | ✅ | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | -| nooma42 | ✅ | ⭕️ | ⭕️ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | | +| nooma42 | ✅ | ⭕️ | ⭕️ | ✅ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | | eddy8 | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | -| yenchihliao | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| DasNarrenschiff | ✅ | ⭕️ | ⭕️ | ✅ | ⭕️ | | | | | | | | | | | | | | | | | | | | | -| awsomecty | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | -| devbards | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | +| yenchihliao | ⭕️ | ⭕️ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | +| DasNarrenschiff | ✅ | ⭕️ | ⭕️ | ✅ | ⭕️ | ⭕️ | | | | | | | | | | | | | | | | | | | | +| awsomecty | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | +| devbards | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | | | | | | | | | | StellaWang5209 | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | | pillowtalk-Qy | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | | yoona333 | ⭕️ | ⭕️ | ❌ | | | | | | | | | | | | | | | | | | | | | | | @@ -577,6 +577,67 @@ Telegram：https://t.me/ETHPandaOrg/5427 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/StarryDeserts.md b/StarryDeserts.md index 0c71dc2..46f2069 100644 --- a/StarryDeserts.md +++ b/StarryDeserts.md @@ -355,6 +355,181 @@ timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) +### 2025.02.11 + +#### 以太坊执行层规范（第3天） + +------ + +##### **交易执行与EVM机制** + +- **执行阶段**： + + 1. **检查点状态（$$\sigma_0$$）**： + $$\sigma_0 \equiv \sigma \quad \text{except:} \quad + \begin{cases} + \sigma_0[\text{Sender}]_{\text{balance}} = \sigma[\text{Sender}]_{\text{balance}} - \text{upfrontCost} \\ + \sigma_0[\text{Sender}]_{\text{nonce}} = \sigma[\text{Sender}]_{\text{nonce}} + 1 + \end{cases}$$ + +- **EVM状态机**： + - **寄存器定义**： + $$\mu \equiv (\mu_{\text{gasAvailable}}, \mu_{\text{programCounter}}, \mu_{\text{memoryContents}}, \mu_{\text{activeWordsInMemory}}, \mu_{\text{stackContents}})$$ + +------ + +##### **合约创建流程** + +1. **地址生成**： + $$\text{地址} = \text{KEC}(\text{RLP}([\text{Sender}_{\text{address}}, \text{Sender}_{\text{nonce}} - 1]))[-20:]$$ + +2. **账户初始化**： + $$\sigma^*[\text{newAccount}] \equiv (\text{Nonce}=1, \text{Balance}=T_{\text{value}}, \text{Storage}=\text{TRIE}(\emptyset), \text{CodeHash}=\text{KEC}(()))$$ + +------ + +##### **Gas计算模型** + +- **内存扩展成本**： + $$\text{MemoryExpansionCost} = 3 \times \Delta_{\text{expansion}} + \left\lfloor \frac{\Delta_{\text{expansion}}^2}{512} \right\rfloor$$ + - $$\Delta_{\text{expansion}}$$：新增内存块数 + +------ + +##### **R代码：基础费用模拟** + +```R +calculate_base_fee_per_gas <- function( + parent_gas_limit, parent_gas_used, parent_base_fee_per_gas, + max_change_denom = 8, elasticity_multiplier = 2 +) { + parent_gas_target <- parent_gas_limit %/% elasticity_multiplier + if (parent_gas_used == parent_gas_target) { + parent_base_fee_per_gas + } else if (parent_gas_used > parent_gas_target) { + gas_used_delta <- parent_gas_used - parent_gas_target + base_fee_per_gas_delta <- max( + (parent_base_fee_per_gas * gas_used_delta %/% parent_gas_target) %/% max_change_denom, + 1 + ) + parent_base_fee_per_gas + base_fee_per_gas_delta + } else { + gas_used_delta <- parent_gas_target - parent_gas_used + base_fee_per_gas_delta <- (parent_base_fee_per_gas * gas_used_delta %/% parent_gas_target) %/% max_change_denom + parent_base_fee_per_gas - base_fee_per_gas_delta + } +} +``` + + + +### 2025.02.12 + +#### 以太坊执行层架构（第1天） + +------ + +##### **客户端架构概览** + +###### 核心职责 + +1. **区块链数据验证与存储** + - 维护本地区块链副本 + - 通过默克尔树验证数据完整性 +2. **网络通信** + - 使用DevP2P协议进行点对点通信 + - 交易池（mempool）管理 +3. **共识层协作** + - 实现Engine API接口 + - 响应`forkChoiceUpdated`和`newPayload`调用 + +##### 分层架构 + +Layered-Architecture + +------ + +##### **EVM设计原理** + +###### 虚拟机核心特征 + +- **硬件无关性** + 通过`EVM字节码`实现跨平台一致性，类似JVM设计理念 +- **沙盒环境** + 每个交易在隔离环境中执行，保证状态变更原子性 + +###### 三明治复杂性模型 + +1. **外层（简单）** + - Solidity/Yul等高级语言 + - JSON-RPC接口 +2. **中间层（复杂）** + - 编译器（Solidity→EVM字节码） + - Gas计量系统 +3. **内层（简单）** + - EVM指令集（约140个操作码） + +------ + +##### **状态管理机制** + +###### 全局状态组成 + +| 组件 | 存储内容 | 数据结构 | +| -------- | ----------------------- | --------------- | +| 账户状态 | 余额/Nonce/合约代码哈希 | Merkle-Patricia | +| 合约存储 | 智能合约变量数据 | Merkle-Patricia | +| 交易收据 | 交易执行日志 | Bloom Filter | + +###### 状态转换公式 +$$\sigma_{t+1} \equiv \Upsilon(\sigma_t, T)$$ + +- $$\sigma_t$$: 当前状态 +- $$T$$: 交易集合 +- $$\Upsilon$$: 状态转换函数 + +------ + +##### **交易生命周期** + +###### 处理流程 + +1. **接收** + 通过JSON-RPC接口接收签名交易 +2. **验证** + - 签名有效性 + - Nonce连续性 + - Gas预算充足 +3. **传播** + 通过DevP2P协议广播至全网节点 +4. **打包** + 被矿工/验证者选入候选区块 +5. **执行** + 在EVM中触发状态转换 + +###### Gas计算模型 +$$\text{总Gas成本} = \text{固有成本} + \sum(\text{操作码Gas} \times \text{执行次数})$$ + +------ + +##### **网络层（DevP2P）** + +###### 关键协议 + +| 协议 | 功能 | 传输内容 | +| ------ | ------------ | ------------- | +| eth/66 | 区块同步 | 区块头/体数据 | +| eth/67 | 交易传播 | 原始交易数据 | +| les/4 | 轻客户端支持 | 状态证明 | + +###### 节点发现机制 + +1. 使用Kademlia DHT协议 +2. 通过ENR记录存储节点元数据 +3. 维护动态路由表（Bucket结构） + + + diff --git a/amandakelake.md b/amandakelake.md index 24773b0..2039c16 100644 --- a/amandakelake.md +++ b/amandakelake.md @@ -207,4 +207,51 @@ PoS 提供了一种不同于 PoW 的安全保证： - [ ] 分片深入 +### 2025.02.11 +[week4](https://epf.wiki/#/eps/week4?id=pre-reading) + +如何确保智能合约在复杂网络环境中的可靠性？ + +EVM测试方法论 +- 字节码级模拟测试：通过EVM模拟器对合约字节码进行逐指令调试 +- Gas消耗追踪矩阵：建立不同操作码的Gas消耗基准值（如：SSTORE=20000 Gas） +- 状态树差异对比：记录每个交易前后的存储树哈希变化 + +```js +// 示例：网络层与合约层的集成测试用例 +describe("跨层事务测试", () => { + it("应正确处理网络延迟下的合约调用", async () => { + // 模拟300ms网络延迟 + network.setLatency(300); + const txReceipt = await contract.execute(); + expect(txReceipt.status).to.equal(1); + }); +}); +``` + +如何在开发环境中构建真实攻击场景？ +```shell +ganache-cli \ + --fork https://mainnet.infura.io/v3/YOUR_PROJECT_ID@15890350 \ + --networkId 5777 \ + --gasLimit 12000000 \ + --allowUnlimitedContractSize + +``` +- 主网分叉测试：捕获真实链上攻击模式 +- 内存泄漏压力测试：持续运行72小时观察内存占用曲线 + +如何构建抗DDoS的测试网络架构？ +1. 节点负载均衡策略 + - 于交易Gas的优先级队列 + - 动态调整的P2P连接池（最大连接数 = √(节点总数)*10） +2. 容错测试矩阵 +```python +# 网络故障注入测试示例 +for fault_type in ['packet_loss', 'latency_spike', 'partition']: + with NetworkFault(fault_type, duration=60): + assert consensus_algorithm.recovery_time < 15 + +``` + diff --git a/awsomecty.md b/awsomecty.md index c88601d..e79cbe7 100644 --- a/awsomecty.md +++ b/awsomecty.md @@ -100,5 +100,30 @@ Core development: 分别是EF Testing、EF DevOps、EF Ipsilon、EF JavaScript来负责 ### 2025.02.11 +1. 合并（The Merge） +目标：从挖矿（工作量证明）转向质押（权益证明），让网络更环保、更安全。 +已完成： +启动了信标链，为合并做准备。 +成功完成了合并，停止了挖矿，转向了质押。 +允许质押者提取他们的以太币。 +未来研究： +单槽最终性（SSF）：让交易更快确认（从12分钟缩短到12秒），提升用户体验。 +量子安全签名：研究新的加密技术，防止未来可能出现的量子计算机攻击。 +2. 激增（The Surge） +目标：通过“卷叠”（rollups）和“数据分片”（data sharding）提升以太坊的交易处理能力。 +已完成： +实现了“Proto-danksharding”，降低了交易成本。 +未来研究： +Danksharding：进一步扩展rollups，让以太坊能处理更多交易。 +数据可用性采样（DAS）：一种高效验证数据完整性的方法，减轻节点的负担。 +3. 净化（The Scourge） +目标：减少审查（censorship）风险，优化矿工提取价值（MEV）的分配，防止中心化。 +已完成： +MEV-Boost：将MEV部分分配给质押者。 +未来研究： +ePBS（增强型区块提议者和构建者分离）：防止交易被审查，保护小质押者的利益。 +MEV-Burn（MEV燃烧）：将MEV的一部分销毁，让所有以太币持有者受益。 +ET（执行票证）：通过市场机制选择区块构建者，防止中心化。 +IL（包含列表）：确保某些交易必须被包含，防止区块构建者随意审查。 diff --git a/brucexu-eth.md b/brucexu-eth.md index a882632..d8f955a 100644 --- a/brucexu-eth.md +++ b/brucexu-eth.md @@ -190,10 +190,42 @@ Light clients are nodes that do not contain entire blockchain data. Instead, the 选择要验证的 tx 的相关 hash 即可，因为上层的 hash 节点都是计算生成的。 -TODO https://epf.wiki/#/eps/week1 - TODO 跑一下代码 https://github.com/dajuguan/lab/blob/main/eth/randao.py +# 2025.02.12 + +## https://epf.wiki/#/eps/week1 + +![image](https://github.com/user-attachments/assets/3635c3a4-c051-4557-a8cb-0621a5b84467) + +The Merge 的过程，其实是构建了一个平行的 Beacon Chain 一直在运行和检测，之后把 execution layer 接过来。 + +As hinted above, the main high level components of Ethereum are execution and consensus layer. These are 2 networks which are connected and dependent on each other. Execution layer provides the execution engine, handles user transaction and all state (address, contract data) while consensus implements the proof-of-stake mechanism ensuring security and fault tolerance. + +The traditional development cycle for new features or changes is Idea - Research - Development - Testing - Adoption. However, problems might arise at any moment of this cycle resulting in iterating again from the beginning. + +The coordination mainly happens via regular calls which are scheduled in the PM repo. + +The ideas and proposed changes from the community are coordinated using EIP process. Additionally, there are a few discussion forums. The biggest one discussing core upgrades is https://ethresear.ch. Another forum which is connected to the EIP process and serves for discussion about specific proposals is Ethereum Magicians. Lots of important discussion is also happening on the R&D Discord server (ping us in EPFsg discord to get an invite) and in client team groups. There are also offsites or workshops where many core developers meet in person to speed up the process face to face. + +通过 https://github.com/ethereum/pm 学习到的社区协调和管理经验： + +1. 通过创建 issues + tag 来放议题、会议链接等信息，例如 https://github.com/ethereum/pm/issues/1253 包括全部的会议，不仅仅是 ACDE ACDC +2. 提供了一个 Google Calendar 来快速添加，但是目前不知道是自动还是人工维护的 +3. 欢迎大家通过评论的方式，添加议题等 +4. 写清楚了议题如何添加、谁能参加、谁主持等 +5. ECH 提供了字幕稿，然后下面有个大表单，可以看到每次会议的录屏、notes、讨论等等 + +对 LXDAO 的启发： + +- 可以考虑将会议集中在这里管理，避免在论坛占用大家的注意力 +- 提供会议的速记和内容稿，作为社区周报的内容，而非比较制式的，重点在于引导大家讨论 + +TODO https://notes.ethereum.org/@mikeneuder/rcr2vmsvftv + +TODO https://epf.wiki/#/eps/week2 + + diff --git a/chloezhu010.md b/chloezhu010.md index 91acd06..93c495d 100644 --- a/chloezhu010.md +++ b/chloezhu010.md @@ -157,6 +157,63 @@ timezone: Europe/Berlin - Light clients and stateless: reduce the resource required for running nodes - RESTful api: eg. Besu - Improved json-rpc: add support for batch request, better error handling etc. +### 2025.02.11 +- Blockchain level protocol + - reference link: https://epf.wiki/#/wiki/protocol/design-rationale + - Accounts over UTXOs + - UTXO (unspent tx output) + - Account + - What's the pros/ cons of account vs UTXO? Why Ethereum chooses account-based model? + - Merkle patricia trie + - a modified MPT + - deterministic and cryptographically verifiable + - Verkle tree + - vector commitments allow for much smaller proofs (aka witness) + - RLP (recursive length prefix) + - SSZ (simple serialize) + - Hunt for finality: Casper FFG + LMD GHOST + - Discv5: the discovery protocol + - a kademlia based DHT to store ENR records + - ENR (ethereum node record) contain routing info to establish connections between peers +### 2025.02.12 +- Pros Cons of Account vs UTXO + - Account: How it works in high level + - the blockchain maintains a global state composed of accounts + - each account has a balance (in smart contract, storage and code) + - tx directly modify the state of these accounts + - UTXO: How it works in high level + - the blockchain tracks unspent tx outputs + - a UTXO represents a chunk of crypto that has been created as an output of a tx, but has not yet been spent + - tx consume existing UTXO and create new ones + - Comparison + + | | Account-based | UTXO-based | + | -------- | ------- | ------- | + | state representation | global state of accounts & balances | set of unspent tx outputs | + | tx logic | directly modify account balance | consume UTXOs and create new ones | + | complexity | easier for dev, esp. for smart contractss | more complex for devs, esp. for advanced logic | + | parallelizability | limited, as txs modifying the same account must be processed sequentially | high, as independent UTXOs can be processed in parallel | +- Why MPT then Verkle tree + - MPT + - a data structure, that combines merkle tree (provide cryptographic proofs to verify the data integrity) and patricia trie (a compressed trie that stores key-value pairs) + - Verkle tree + - more advanced data structure to address the issue of MPT + - vector commitment + merkle tree, it uses vector commitment (eg. polynomial commitments) to create smaller & more efficient proofs + - Comparison + + | | MPT | Verkle tree | + | -------- | ------- | ------- | + | proof size | large (scale with tree depth) | small (constant or logarithmic) | + | efficiency | less efficient for deep trees | more efficient for deep trees | + | stateless clients | inefficient due to large proof | efficient due to compact proof | + | scalability | limited by proof size & depth | better scalability for large states | + | cryptographic basis | merkle proof (hash-based) | vector commitment (eg. polynomial) | +- What's RLP? What's its purpose? +- What's SSZ? What's its purpose? + - What's union? + - What's ephemeral header? +- What's discv5? +- diff --git a/cooper.md b/cooper.md index 9f9fbca..a3e1181 100644 --- a/cooper.md +++ b/cooper.md @@ -289,7 +289,10 @@ EVM 字节码是程序的字节序列（8 位）的表示。字节码中的每 ### 2025.02.12 > 周三 -笔记内容 +#### 学习总结 +参考：https://epf.wiki/#/wiki/EL/evm + +细致的了解了EVM的执行流程，以及EVM的执行引擎。 ### 2025.02.13 > 周四 diff --git a/d0d0d9.md b/d0d0d9.md index 5487f91..fd76fe9 100644 --- a/d0d0d9.md +++ b/d0d0d9.md @@ -104,6 +104,11 @@ continue running on consumer-grade hardware without missing out MEV exposed ### 2025.02.10 +#### Gasper +https://medium.com/@jamaltheatlantean/what-is-gasper-20f6697d3dc6 + +Gasper结合了**Casper FFG（Friendly Finality Gadget）和LMD-GHOST（Latest Message Driven - Greediest Heaviest Observed SubTree） + #### Committee ▪ Validators within the network will be randomly shuffled under different committees. ▪ Each validator will make one attestation per epoch. The exact slot the validator is @@ -128,12 +133,42 @@ A checkpoint is a block in the first slot of an epoch. If there is no such bloc #### FFG Vote When casting an LMD GHOST vote, a validator also votes for the checkpoint in its current epoch, called the target. This vote is called a Casper FFG vote, and also includes a prior checkpoint, called the source. In the diagram, a validator in Epoch 1 voted for a source checkpoint of the genesis block, and a target checkpoint of the block at Slot 64. In Epoch 2, the same validator voted for the same checkpoints. Only validators assigned to a slot cast an LMD GHOST vote for that slot. However, all validators cast FFG votes for each epoch checkpoint. +Casper FFG 主要负责区块链的最终确定性（finality），确保一旦一个区块被认为是最终的，它就不会被更改。这通过在每个周期（称为epoch）结束时执行检查点来实现。 + #### Attestations An attestation contains both an LMD GHOST vote and an FFG vote. Optimally, all validators submit one attestation per epoch. An attestation has 32 slot chances for inclusion on-chain. This means a validator may have two attestations included on-chain in a single epoch. Validators are rewarded the most when their attestation is included on-chain at their assigned slot; later inclusion is a decaying reward. To give validators time to prepare, they are assigned to committees one epoch in advance. Proposers are only assigned to slots once the epoch starts. Nonetheless, secret leader election research aims to mitigate attacks or bribing of proposers -#### Gasper -https://medium.com/@jamaltheatlantean/what-is-gasper-20f6697d3dc6 +### 2025.02.11 + +[共识介绍视频](https://www.youtube.com/watch?v=5gfNUVmX3Es) + + +### 2025.02.12 + +#### Research and Roadmap + +[Ethereum Roadmap](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week5.pdf) + +##### Scourge +(very) brief overview of MEV +ePBS / Inclusion Lists / MEV Burn +Max EB, Stake capping + +##### Verge +Verkle Trees +SNARKify everything + +##### Purge +【EIP-4444](https://eips.ethereum.org/EIPS/eip-4444) +Protocol simplifications + +##### Splurge +[EIP-1559 endgame](https://ethresear.ch/t/multidimensional-eip-1559/11651) +Account Abstraction +Deep cryptography + + diff --git a/dethan3.md b/dethan3.md index 86be65a..e9419da 100644 --- a/dethan3.md +++ b/dethan3.md @@ -39,4 +39,13 @@ Week3 主要讲述了以太坊的共识层，需要了解 POS 的原理。 ### 2025.02.10 第五章讲了以太坊的路线图，当然这是2024年的路线图。今年应该要讲新的路线图，最好赶快报名今年的课程。 2月12日开始 + +### 2025.02.11 +以太坊的目标是成为一个世界计算机吗？ +以太坊又3个部分组成：EVM, Blockchain, Network + +以太坊提供了一种无需信任的信任 + +自由加密运动是以太坊和所有加密货币活动的基础 + \ No newline at end of file diff --git a/devbards.md b/devbards.md index 0deeaf3..67973a8 100644 --- a/devbards.md +++ b/devbards.md @@ -46,6 +46,13 @@ Week 5's content is much more complex than I expected. It seems like I need to f I realized that my fundamental knowledge of cryptocurrencies is too limited, and jumping straight into BFT feels like taking on a boss fight way beyond my level—everything just seems vague and confusing. So, I’ve decided to borrow some introductory books on cryptocurrencies to build a stronger foundation. Additionally, I noticed that writing notes in English might not be as helpful for the Chinese-speaking community. Therefore, once I have a more complete understanding, the recording style would change somehow. ### 2025.02.11 +From the reading on the history of cryptocurrencies, blockchain techniques, and consensus mechanisms: + +Bitcoin uses a reward mechanism to incentivize miners to become nodes in its P2P network. However, this raises the question—once the total supply of Bitcoin reaches its limit and no more Bitcoin can be "mined," how will the network continue to operate? The alternative mechanism I found is that transaction fees will sustain network operations, which in turn creates the necessity for higher fees. This has led to the development of off-chain solutions like the Lightning Network. + +Ethereum, on the other hand, is gradually replacing PoW with a PoS mechanism, where participants stake ETH to take part in consensus and earn rewards. To enhance security, the slashing mechanism punishes malicious actors. Unlike Bitcoin, Ethereum does not have a fixed supply limit, but by implementing Base Fee burning, it introduces a deflationary aspect to ETH. + +Understanding these concepts gives me a deeper appreciation of the motivations behind founding this study group—it’s truly fascinating! ### 2025.02.12 diff --git a/dixia.md b/dixia.md index 580fa86..ce13618 100644 --- a/dixia.md +++ b/dixia.md @@ -24,10 +24,10 @@ Node and EL. But is this a physical scope separation? Need to learn more. EOA controlled by key pair. Contract controlled by code. -Every smart contract's persistent storage is just an array of 32bytes. the root is a MPT hash. Does balance take up space of storage? +Every smart contract's persistent storage is just an array of 32 bytes. The root is a MPT hash. Does balance take up space of storage? Nope -Message are just tx from contract without signature. but then how does other contracts know the message is from the initial contract? -And how does EVM or consensus verify the message(virt tx)? +Messages are just tx from contract without signature but then how do other contracts know the message is from the initial contract? +And how does EVM verify the message (virtual tx)? https://cs251.stanford.edu/lectures/lecture7.pdf [0] @@ -37,32 +37,32 @@ Block Data Structure: world state root has MPT hash of all accounts on Ethereum. It takes 16tb to run an archive node rn. -EVM still use stack (max: 1024) to execute code but with JUMP instruction code. +EVM still uses stack (max: 1024) to execute code but with JUMP instruction code. -Burn ether preventing off-chain fee refund agreement to proposers that I did not thought before. A proposer could create/encourage fake txs to farm more ether reward if eth not burn and refund gas fee off-chain. The fee they paid would be less than eth reward to block proposer which it is the case given there are eth inflation for block proposers. But why would proposer are incentivized to do this? they could just collect reward from block building with the trouble of creating fake txs unless the block reward is proportional to the txs they included? +Burn ether preventing off-chain fee refund agreement to proposers (I did not think before). A proposer could create/encourage fake txs to farm more ether reward if eth not burned and refund gas fee off-chain. The fee they paid would be less than eth reward to block proposer which is the case given there is ether inflation for block proposers. But why would proposers be incentivized to do this? They could just collect reward from block building without the trouble of creating fake txs unless the block reward is proportional to the txs they included? -In bitcoin's world, miner has fixed cost for mining the block but they do get fee reward as well. So this could apply to Bitcoin as well +In bitcoin's world, miners have fixed cost for mining the block but they do get fee reward as well. So this could apply to Bitcoin as well. ### 2025.02.08 -#### Why would proposer engage into off-chain fee refund agreement +#### Why would proposers engage in off-chain fee refund agreement -It is not due to the block reward as it is not proportional to the txs they included. But for the following reason: +It is not due to the block reward as it is not proportional to the txs they included. But for the following reasons: -1. Proposer could fake up transactions to create a impression/illusion of higher activity on the chain. Given if they could get the gas fee back the cost of artificially creating txs is very low (transaction fee + effort to inflate txs). But that would require you control majority of the validator nodes or can reliably predict the next block proposer. The former could be the case actually right now? given there are 2-3 block builder building most of the blocks.(builder == proposer?) +1. Proposers could fake transactions to create an impression/illusion of higher activity on the chain. Given if they could get the gas fee back, the cost of artificially creating txs is very low (transaction fee + effort to inflate txs). But that would require you control majority of the validator nodes or can reliably predict the next block proposer. The former could be the case actually right now? Given there are 2-3 block builders building most of the blocks (builder == proposer?) -2. To bid up the gas fee so other users have to pay more to get their txs included. This could require the same condition as above. As you intentionally pay a higher gas fee but can recover most of it back. It would be in the interest of proposer to do so. This would apply to Bitcoin as well. If majority of mining pool has an agreement. Could very well be the case for other chains. +2. To bid up the gas fee so other users have to pay more to get their txs included. This could require the same condition as above. As you intentionally pay a higher gas fee but can recover most of it back. It would be in the interest of proposers to do so. This would apply to Bitcoin as well. If majority of mining pools have an agreement. Could very well be the case for other chains. #### -gas fee right felt like a spam preventing mechanism rather than a fee market which pricing different resources. +Gas fee before EIP-1559 feels like a spam preventing mechanism rather than a fee market which prices different resources. -encrypted mempool: total gas case has to be unencrypted. Cosmos has encrypted mempool. general idea is no complete solution available yet +Encrypted mempool: total gas case has to be unencrypted. Cosmos has encrypted mempool. General idea no one have seen a complete solution available yet. ### 2025.02.10 -A epoch has 32 slots. +An epoch has 32 slots. -A validator will be randomly selected to be a proposer for a slot. so the validator is the proposer. +A validator will be randomly selected to be a proposer for a slot. So the validator is the proposer. 1 slot has 3 phases and a block: @@ -83,13 +83,29 @@ why have a slot instead of a block? proposer can reorder txs in a slot. so I guess other validators has no way to verify the order of txs in a block when they attest to it. I guess this is why validators only follow the fork-choice rule -given the deadline for attesetion is 4 seconds, so that give you some idea on how much MEV it can take place on the time dimension. +given the deadline for attesetion is 4 seconds, so that give you some idea on how much bot could MEV using the time advantage. #### spam txs -actually once is a validator is chosen to be a proposer, it can know therefore it can start to spam txs. +actually once is a validator is chosen to be a proposer, it can know therefore it could time the opportunity to spam txs. https://www.paradigm.xyz/2023/04/mev-boost-ethereum-consensus https://epf.wiki/#/eps/week3 - + + +### 2025.02.11 + +a commmitte is of 128 validators. +a validator run a beacon node + +still not sure why a committe concept is needed after watch all these video + +PoW consensus use economic (hash power) to reach consensus which looks a lot simpler. Through it does give entity who has most computing power an advantage so it is more close to "real" economy where PoS could at certain time depeg from real economy power. As long as stakeholder/token holder has a little real world economy power(pay for server and bandwdith). (eth will have price but it is less impact by commodity price such as electricity + ) it is easier to develop as independent set of stakerholders on its own economy compare to Bitcoin i.e. if someone is very good at investing/trading, he or she could acquire ether at lower price. But you alway need to pay for a market price for electricity. PoW resets the game each time but does make bitcoin's opeartion more close to "real world" + +### 2025.02.12 + +fork choice rule == LMD GHOST + + \ No newline at end of file diff --git a/dundun930326.md b/dundun930326.md index 3654ce2..70b39d3 100644 --- a/dundun930326.md +++ b/dundun930326.md @@ -122,9 +122,128 @@ Root ├── 64 (d) → 6F67 (og) → "bark" ``` +### 2025.02.11 +TODO : responsibility、p2p、snap +今天看了執行層的詳細架構，但覺得有點太難了，所以用GPT幫我生重點。 +以下是針對原文中第 2、3、4、5 部分的詳細解釋： +--- + +## 1. 區塊結構與區塊處理流程 + +**區塊結構** +- 每個區塊作為區塊鏈中的基本單位，包含區塊頭、交易列表以及其他相關元數據。 +- **區塊頭：** 記錄了父區塊的哈希值、時間戳、難度指標、狀態樹根、交易樹根等關鍵參數。這些資訊不僅保證了區塊內容的不可篡改性，也成為驗證區塊合法性的依據。 + +**區塊處理流程** +- **交易收集與排序：** 節點從網絡中收集各筆交易，並根據一定的排序規則（例如手續費優先等）進行整理，形成待打包的交易池。 +- **區塊生成：** 節點根據共識規則，選取合適的交易打包成區塊，同時計算與該區塊相關的狀態轉換。 +- **區塊驗證：** 新生成的區塊會經過嚴格的驗證程序，包括檢查區塊頭資訊、每筆交易的合法性以及狀態轉換的正確性。 +- **鏈接與確認：** 驗證通過後，新區塊被其他節點認可並與之前的區塊鏈進行鏈接，從而形成完整且連續的區塊鏈。 + +--- + +## 2. 狀態轉換函數 + +**概念說明** +- 狀態轉換函數定義了從當前區塊狀態到下一個區塊狀態的轉變規則。每筆交易在執行時，都會根據該函數更新賬戶狀態、智能合約存儲以及其他鏈上數據。 + +**細節內容** +- **交易執行：** 每筆交易可能涉及調用智能合約、轉賬或合約部署等操作，其執行結果將改變系統內部狀態。 +- **錯誤處理：** 當交易執行過程中遇到錯誤（如資金不足或非法操作）時，系統會根據預設規則進行回滾或標記錯誤，確保不會影響其他交易的正確執行。 +- **數據一致性：** 嚴格定義的狀態轉換邏輯確保所有節點在處理相同交易時，能夠得出一致的狀態更新結果，從而維持整個網絡的一致性。 + +--- + +## 3. Ethereum 虛擬機（EVM）運作機制 + +**EVM 基本架構** +- **指令集與計算模型：** Ethereum 虛擬機（EVM）是一個基於堆疊運算的虛擬機，內置完整的指令集，用以執行智能合約的邏輯。 +- **Gas 機制：** 為防止無限循環和濫用資源，EVM 在執行每條指令時都需消耗一定的 gas，且由交易發起者提前支付。這不僅保護了網絡資源，同時也激勵開發者優化合約代碼。 + +**執行流程** +- **智能合約執行：** 當合約被調用時，EVM 根據合約代碼逐條執行指令，同時根據設定的 gas 限制進行資源控制。 +- **存儲與運算：** 在合約執行過程中，EVM 負責讀取、寫入及計算相關數據，並維護一個內部存儲空間來管理合約狀態。 +- **結果與回執：** 執行結束後，EVM 生成交易回執，其中記錄了執行結果、剩餘 gas 以及在執行過程中產生的事件或錯誤信息。 + +--- + +## 4. 交易驗證與處理流程 + +**交易結構** +- 每筆交易包含發起方、接收方、轉賬金額、gas 限制與價格以及數據負載（通常用於智能合約的調用）等信息。 +- 交易中必須包含數字簽名，以證明發起者的身份和交易的合法性。 + +**驗證步驟** +- **格式檢查：** 首先檢查交易數據結構是否符合規範要求。 +- **簽名驗證：** 通過公鑰密碼學方法驗證數字簽名，確保交易來自合法的發起者。 +- **Gas 檢查：** 驗證交易所設定的 gas 限制是否合理，並確認發起者賬戶中有足夠餘額支付所需費用，以防濫用網絡資源。 +- **狀態轉換檢查：** 在執行交易前後，對比系統狀態變化是否符合預期，從而防止任何非法或不當的狀態更新。 + +--- + +### 2025.02.12 +### RPC 遠端程序呼叫 +在以太坊及其他區塊鏈中，RPC（Remote Procedure Call，遠端程序呼叫）是一種協定，允許應用程式與區塊鏈節點進行互動。透過RPC，開發者可以查詢區塊鏈資料、發送交易，以及與智能合約互動。 + +以太坊實現了JSON-RPC規範，這是一種無狀態、輕量級的遠端程序呼叫協定，使用JSON作為資料格式。以太坊客戶端通常支援多種傳輸協定，包括HTTP、WebSocket和IPC，這使得開發者能夠以多種方式與以太坊網路互動。 + +在區塊鏈生態系統中，RPC是去中心化應用程式（DApps）與區塊鏈網路溝通的關鍵橋樑。開發者可以使用RPC介面查詢區塊資訊、發送交易請求，或與智能合約進行互動。例如，當使用者在DApp中發起交易時，應用程式會透過RPC將交易資訊傳送至區塊鏈節點，節點再將交易廣播至整個網路。 +總而言之，RPC在以太坊和其他區塊鏈中扮演著關鍵角色，提供了應用程式與區塊鏈網路之間的溝通管道，支持各種區塊鏈操作的實現。 + +### responsibility、p2p、snap +--- + +### 1. Responsibility（責任／職責分工） + +在以太坊架構中，「responsibility」主要描述各系統組件或層級在協議中各自承擔的明確角色與任務。例如： + +- **層級職責分離** + 自從以太坊完成合併（The Merge）之後，整個系統被劃分為兩大層級： + - **執行層（Execution Layer）**：負責處理交易、執行智能合約以及維護帳戶狀態。 + - **共識層（Consensus Layer）**：負責區塊排序、驗證以及確保全網達成共識。 + 這種分工確保各層均有其明確「責任」，有助於系統模組化、易於維護和未來獨立升級。 + +- **節點責任** + 每個以太坊節點在網路中均承擔著驗證交易與區塊、維護最新網路狀態以及通過 P2P 網絡傳播數據的責任，從而確保網絡的安全性與去中心化運作。 + +總體而言，「responsibility」體現了以太坊中「各司其職」的設計理念，是確保系統穩定運作與安全的重要基石。 + +--- + +### 2. P2P（點對點網絡） + +「P2P」是「peer-to-peer」的縮寫，代表以太坊中節點間進行直接通信的去中心化網路架構，主要特點包括： + +- **無中心化伺服器** + 以太坊網絡中的節點直接互相連接，無需依賴單一中心伺服器。透過分散式網絡協議（如 devp2p），各節點可以互相傳送交易、區塊及狀態資訊，這增強了網絡的抗審查能力與容錯性。 + +- **節點發現與數據傳輸** + 節點能自動發現其他節點並建立安全加密的通信鏈路，確保數據（例如交易與區塊資訊）能夠迅速且可靠地在整個網絡中廣播與傳播。 + +- **網絡健壯性** + 去中心化的 P2P 結構能有效防止單點故障和集中式攻擊，即使部分節點下線，整個網絡依然可以穩定運作並維持共識。 + +--- + +### 3. Snap（快照同步機制） + +在以太坊中，「snap」通常指的是**snap sync**（快照同步）機制，這是一種用來加速新節點同步的技術手段： + +- **狀態快照機制** + 由於以太坊的歷史數據量龐大，若從創世區塊開始逐筆重放交易來構建最新狀態，所需時間和資源極高。snap sync 機制允許新節點直接從其他已同步的節點下載一份包含當前狀態（如帳戶餘額、智能合約存儲等）的快照，從而跳過重放所有歷史交易的步驟。 + +- **快速驗證與更新** + 節點下載快照後，會進行必要的驗證以確保資料正確無誤。隨後，新節點只需處理快照之後的新區塊，迅速趕上最新狀態，從而大幅縮短同步時間。 + +- **提升網絡擴展性** + snap sync 使得新節點能夠更快接入網絡，降低了同步過程中的計算與存儲負擔，這對於應對網絡規模不斷增長具有重要意義。 + +總結來看，「snap」在以太坊中代表利用狀態快照進行快速同步的一種高效機制，使新節點無需從頭重放全部歷史交易即可快速獲得最新狀態，從而促進了網絡的高效擴展與穩定運作。 + +--- diff --git a/ghx1104.md b/ghx1104.md index e0c64c0..bc75e59 100644 --- a/ghx1104.md +++ b/ghx1104.md @@ -423,5 +423,71 @@ Splurge 包含一些额外的改进，进一步提升以太坊的功能： • EIP-1559 Endgame：优化 EIP-1559 的燃烧机制，以提高费用市场的稳定性。 • Account Abstraction（AA）：允许智能合约账户拥有更强大的功能，例如灵活的支付方式、多重签名等，减少对外部钱包的依赖。 • Deep Cryptography：进一步增强密码学能力，为未来的扩展性提供保障。 - + + +### 2025.02.11 + +#### week5 + +* 实践：如何在以太坊网络上运行节点 + +1. 运行节点简介 +运行以太坊节点是参与以太坊网络的基础，分为 执行层（EL） 和 共识层（CL）。要成功运行完整节点，需要同时配置这两层客户端。 + +2. 选择客户端和环境 +选择合适的客户端对提高节点稳定性至关重要。常见的 EL 客户端有 Geth 和 Erigon，CL 客户端有 Prysm 和 Lighthouse。确保操作系统支持并行运行这两个客户端。 + +3. 获取和验证客户端 +从官方网站或 GitHub 下载客户端，验证二进制文件的完整性以防篡改。 + +4. 客户端配置 +配置执行层与共识层客户端，确保它们之间正确通信（通过 RPC）。 + +5. 在 Holesky 测试网运行 +使用 Holesky 测试网来验证客户端的设置，确保没有问题后再迁移到主网。 + +6. 运行自定义 Genesis +通过使用自定义 Genesis 文件创建临时（Ephemeral）以太坊网络，进行实验或测试。 + +7. 切换客户端 +如需更换客户端（例如从 Prysm 切换到 Lighthouse），只需停止当前客户端并配置新的客户端。 + +8. 使用客户端与 RPC 交互 +通过 HTTP、WebSocket 或 IPC 接口与节点交互，进行交易查询或钱包管理。 + +9. 添加验证者 +质押 ETH 成为验证者并加入共识层，配置验证者密钥并启动验证。 + +10. 系统监控和服务 +使用 systemd 配置客户端自动启动，结合 Prometheus 和 Grafana 进行节点监控。 + + +### 2025.02.12 + +#### week6 + + +1. Hsiao-Wei Wang on Consensus Specs + +Hsiao-Wei Wang 是一位在以太坊共识协议方面具有深厚经验的研究者，主要关注以太坊的共识层（Consensus Layer）。他在演讲中可能会讨论 以太坊共识规范（Consensus Specs），这涉及到如何确保网络参与者在没有中央权威的情况下达成一致，以及如何保持网络的安全性和稳定性。 + +共识规范主要包括： + • 权益证明（PoS）：以太坊从工作量证明（PoW）转向 PoS 后，如何确保验证者的选举和网络的持续一致性。 + • 信标链（Beacon Chain）：用于协调共识层的机制，它通过区块链上的验证者来确保网络状态的同步。 + • 区块生成和验证：如何验证交易和生成新区块，并在分布式网络中保持一致。 + +在此话题中，Hsiao-Wei Wang 可能还会讨论 共识算法的改进、安全性分析 和 网络扩展性 等问题。 + +2. Sam Wilson on EELS + +Sam Wilson 可能会讨论 EELS（Ethereum Execution Layer Security），这是一个专注于提高以太坊执行层（Execution Layer）安全性的议题。执行层处理以太坊网络中的所有交易、智能合约和计算，因此其安全性至关重要。 + +EELS 可能涉及的内容包括： + • 智能合约的安全性：确保合约执行不被恶意攻击利用。 + • 交易处理和验证：确保交易的有效性和可靠性，避免恶意交易影响整个网络。 + • 数据存储和状态管理：确保以太坊节点在处理大量数据时，仍能保持高效且安全的操作。 + • 攻击防范机制：例如防止重放攻击、闪电贷攻击等。 + +Sam Wilson 可能会讨论如何加强执行层安全性，以确保以太坊网络能够处理更多的交易负载，同时保护用户和验证者免受潜在的攻击。 + diff --git a/henryleo.md b/henryleo.md index 5272b44..6582d23 100644 --- a/henryleo.md +++ b/henryleo.md @@ -167,12 +167,19 @@ BitTorrent 旨在解决依赖中心化服务器下载大文件导致的网络堵 以太坊坚持去中心化来实现无需许可、可信中立和抗审查，这并不意味着要求绝对的透明和排斥商业或其他组织，合约或者协议可以有不透明的部分，但规则和退出机制必须透明（个人理解）。要求和排斥是控制，以太坊不要控制，要**通过技术**构筑“无限花园”，这一点承接密码朋克的核心信念之一：“that the power of technology often creates new political realities.”。 - -#### Refs +###### Refs - [A Prehistory of the Ethereum Protocol | vitalik.eth.limo](https://vitalik.eth.limo/general/2017/09/14/prehistory.html) - [Inevitable Ethereum - World Computer](https://inevitableeth.com/home/ethereum/world-computer) - [密码朋克 | 以太坊协议的史前史](https://epf.wiki/#/wiki/protocol/prehistory?id=cypherpunks-write-code) +### 2025.02.11 + +#### 以太坊的组成 + +以太坊通过三个Part 组件致力于实现通用计算平台： +- EVM Ethereum Virtual Machine 以太坊虚拟机 +- Ethereum Blockchain 以太坊区块链 +- Ethereum Network 以太坊网络 diff --git a/jjeejj.md b/jjeejj.md index 99de35a..42f8f69 100644 --- a/jjeejj.md +++ b/jjeejj.md @@ -95,4 +95,19 @@ timezone: Pacific/Auckland # 新西兰标准时间 (UTC+12) 2. JSON-RPC 1. 远景是所有的客户端提供相同的 api, 用户可以运行他们选择的任意客户端，并于所有工具完美集成 +### 2025.02.11 + +1. Week3: 共识层 CL 是以太坊的一个核心组件，核心任务使用 Pos (Proof of Stake) 来确保网络中的安全性、一致性、去中心化 + 1. 负责共识算法：验证者选择、区块提议、区块验证、最终性 + 2. 确保每个交易只只能包含在一个区块终 + 3. 奖惩机制 + 4. 网络同步 + 5. 主要的参与者是验证者 + +### 2025.02.12 + +1. Week4: 主要讲测试和安全方面 + 1. 存在很多工具，都没有用过啊，感觉有点头大 + + diff --git a/k66.md b/k66.md index efd1309..139ebc3 100644 --- a/k66.md +++ b/k66.md @@ -120,4 +120,25 @@ Week3 + Satoshi solves Byzantine General's Problem + POW and heaviest chain algorithm mean any node 最終會converge to same current state as any other +### 2025.02.11 + +總費時: 約30分鐘 + +Week3 ++ 承續前一日，week3影片，但我不太懂，想說之後回頭再看一遍。 + +Week4 ++ 講安全及測試 ++ EVM testing: EEST(Ethereum/Execution Spec Test) + - test Filling: 皆為json files + - Pre-State 停在此 + - Environment + - Transaction(s) + - Post-State + +以下為明天: ++ 共識層的測試: ethereum/consensus-specs ++ Cross-Layer(Interop) Testing: `Hive`, `Devnet`, `Shadow-Forks`, `Testnets` ++ 安全: 淺在的issues, bugs + diff --git a/kernel1983.md b/kernel1983.md index cd991a3..52b8413 100644 --- a/kernel1983.md +++ b/kernel1983.md @@ -112,4 +112,18 @@ N年前研究 POW 的同时，我也瞎写过 POS https://github.com/kernel1983/ 摸鱼为主。 +### 2025.02.12 + +今天随机阅读了其它同学的学习笔记，一些提到 Verkle 树能解决状态爆炸问题。应该有一些计算机基础的人，都会否定这个想法。 + +首先，有一些语言上的艺术，在误导大家学习：压缩是什么？一般无损压缩需要能够解压还原。如果我有1G数据，我通过一些方法可以验证数据，比如默克尔树，那么我生成的是证明，默克尔根并没有起到压缩的作用，因为它无法解压成原始数据。所以说 Verkle 树能把不断增加的全局状态压缩到一个很小的数据，仅仅用于验证。 + +EVM 在执行中必须访问全局状态，如果是默克尔根或者 Verkle 树，则根本无法用于运行 EVM。我们还是需要全局状态，保存不断变大的全局状态，去支持 EVM 的运行。 + +我在研究区块链分片的时候，一开始就非常轻松的完成了对于交易的分片。对于全局状态的分片，一直没有很好的方案。但是在去年，我们意识到，全局状态爆炸，本来就是需要被抑制的，不断增长的全局状态会影响节点运行的去中心化（除非有完美的分片方案，但是这非常不切实际）。抑制全局状态，意味着我们无需全局状态的分片，这两者达到了空前的统一。 + +同时，我们也认识到，区块链中必须要有稀缺性资源，我们可以认为的定义 coin 的总量，故意制造稀缺，但是更需要定义这些 coin 与什么资源相关。在比特币中，coin 用于支付交易手续费。这里有一个悖论，成功的区块链代币将不断上涨，不断上涨的代币将抑制链上繁荣，区块链不再繁荣则会导致区块链的失败。我们称为 BTC 悖论（这不是说 BTC 会失败，而是采用 BTC 类似代币模型，用代币支付链手续费的其它区块链，会受到这一悖论魔咒的困扰，包括 ETH）。这个悖论简单说，区块链的繁荣将导致失败。 + +改进方法：在我们 Zentra 中，会利用全局状态的稀缺性，设计代币。这样的设计将鼓励链上繁荣，币价上涨不会抑制链上活跃度。 + diff --git a/kidneyweakx.md b/kidneyweakx.md index d466075..88c14cd 100644 --- a/kidneyweakx.md +++ b/kidneyweakx.md @@ -64,4 +64,7 @@ gas 算式挺複雜的，看了一陣子 # 2025.02.10 今天看的東西不多，大概搞懂坎昆升級後 Blob 的計算公式，總感覺現在這機制弄的有點複雜和雜亂 +# 2025.02.11 +EL Client 今天看的相對比較熟，之前玩過 quorum 和 besu 設計挺像的 + \ No newline at end of file diff --git a/lllapland.md b/lllapland.md index faa291a..071b676 100644 --- a/lllapland.md +++ b/lllapland.md @@ -27,24 +27,14 @@ https://epf.wiki/#/eps/week1 - **FOSS (Free & Open Source Software)**: Software that respects users' freedom and community - **GNU**: Foundation for open-source software, influencing Ethereum's development principles. GNU stands for "GNU's Not Unix" - Cryptography - - **Key Usage** - - Symmetric: Same key for encryption & decryption - - Asymmetric: Uses a public/private key pair - - **Security** - - Symmetric: Less secure if the key is exposed - - Asymmetric: More secure; only the private key must be kept secret - - **Speed** - - Symmetric: Faster (simpler computation) - - Asymmetric: Slower (complex mathematical operations) - - **Key Distribution** - - Symmetric: Requires secure key exchange - - Asymmetric: Public key can be shared openly - - **Common Algorithms** - - Symmetric: AES, DES, RC4 - - Asymmetric: RSA, ECC, Diffie-Hellman - - **Use Cases** - - Symmetric: Encrypting files, database security - - Asymmetric: Digital signatures, 🌟 **blockchain**, secure communication (TLS, PGP) + | **Characteristic** | **Symmetric Encryption** | **Asymmetric Encryption** | + |-------------------|-------------------------|--------------------------| + | **Key Usage** | same key for encryption & decryption | public/private key pair | + | **Security** | less secure if key is exposed | more secure; only private key must be kept secret | + | **Speed** | faster (simpler computation) | slower (complex mathematical operations) | + | **Key Distribution** | requires secure key exchange | public key can be shared openly | + | **Common Algorithms** | AES, DES, RC4 | RSA, ECC, Diffie-Hellman | + | **Use Cases** | encrypting files, database security | digital signatures, 🌟 **blockchain**, secure communication (TLS, PGP) | #### Implementations and Development @@ -211,9 +201,65 @@ https://epf.wiki/#/eps/week3 | **Communication Complexity** | **O(n²)** -> multiple rounds of message exchanges, where each node broadcasts messages to all other nodes 🌟| **O(n)** | ----- -TBC +### 2025.02.11 +https://epf.wiki/#/eps/week3 + +- PoS + - in-protocol signal allow for **penalties**, not just rewards (compared to PoW) + - scenarios: + - double signing + - going offline + - equivocation -> voting for multiple **competing blocks** at the same height [💡](https://youtu.be/5gfNUVmX3Es?si=z7ba-EZ48kbH4I5V) + - how? + - **slashing**: cutting validator's stake for malicious behavior (up to 32 ETH) + - **inactivity leak**: gradual stake reduction for being offline to maintain network liveness + - benefits: + - reduce attack surface + - less resource intensive +- Bribe attacks -> attackers influence validator behavior through **economic incentives** + - examples: + - paying validators to vote for specific blocks + - bribing validators to stay offline + - mitigations: + - slashing penalties make bribe acceptance **more costly than potential gains** + - withdrawal delays increase the cost of malicious behavior +- GHOST vs. Casper + - ethereum 2.0's consensus mechanism uses a modified version of **GHOST** combined with **Casper FFG** (Finality Gadget) + +| Mechanism | Purpose | Consensus Type | Key Features | +|-----------|---------|---------------|--------------| +| **GHOST** | **fork-choice rule** to determine the canonical chain | **PoW & PoS** | • usually considers the **entire tree of blocks** (special case: LMD-GHOST looks at validators' **latest messages**)
• chooses the **heaviest** subtree
• prevents short-chain attacks | +| **Casper FFG** | **finality gadget** for PoS consensus | **PoS** | • checkpoint-based finalization
• uses validator voting
• provides economic finality through slashing | + + + +### 2025.02.12 +https://epf.wiki/#/eps/week3 + +- Attestation: statement or proof of a certain fact + - Ethereum's PoS consensus [tutorial](https://youtu.be/5gfNUVmX3Es?si=_fkMJ6mn3LQGAE4V&t=83) + - epoch -> **a time unit** used to **organize validator duties** and **finalize** blocks efficiently + - **1 epoch = 32 slots** (Each slot is **12 seconds**) + - **1 slot** = opportunity to **propose a block** + - How to? + 1. **a validator is selected** to propose a block in **each slot** + 2. **other validators attest** using **BLS signatures** (aggregating hundreds of signatures into a single signature) + - validators are assigned to different **committees** + - each committee is responsible for validating **specific shards** + 3. **attestations are aggregated** and included in the next block + 4. **epoch ends after 32 slots** (~6.4 min) + 5. **If 2/3 validators agree, finalization occurs** + - EAS: Ethereum Attestation Service 🔥 [tutorial](https://youtu.be/DMGj5GNll0k?si=LFfMfwQp7LqfNyCV&t=967) + - [usage cases / ideas](https://docs.attest.org/docs/category/example-use-cases) + - identity + - statements + - etc. + + + + + diff --git a/marvelshan.md b/marvelshan.md index 1768ef2..bc01a63 100644 --- a/marvelshan.md +++ b/marvelshan.md @@ -469,5 +469,196 @@ EELS 則是構建在執行層上的規範，可以用於運行測試，驗證新 ### 2025.02.11 +![image](https://github.com/user-attachments/assets/ba2ff0d7-5834-4ac0-ad24-56cd87ee22bf) + +### 1. 執行層的角色與架構 +執行層的主要職責包括： +- 執行交易（Transaction Execution） +- 驗證區塊鏈數據並存儲本地副本 +- 透過 Gossip 協議與其他執行層客戶端通訊 +- 維護交易池（Transaction Pool） +- 滿足共識層（Consensus Layer）需求，以驅動整體運作 + +執行層架構的核心組件： +- **執行引擎（Execution Engine）：** 負責驅動執行層，並受共識層驅動。 +- **DevP2P（Networking Layer）：** 透過引導節點（Boot Nodes）初始化，以進入以太坊網絡。 +- **Engine API：** 例如 `fork choice updated` 方法，可透過訂閱特定同步模式來從其他節點下載區塊。 + +--- + +### 2. 以太坊虛擬機（EVM） +- EVM 為以太坊提供虛擬化的 CPU，確保不同硬體架構（如 x86、ARM、RISC-V）下的執行結果一致。 +- EVM 的作用類似於 JVM（Java 虛擬機），讓所有以太坊客戶端能夠對計算結果達成共識。 +- **三明治複雜性模型（Sandwich Complexity Model）：** + - 外層應保持簡單，所有複雜性集中於中間層。 + - 以太坊的最外層是 EVM 代碼，高層為 Solidity，透過編譯器轉譯為 EVM 字節碼。 + +--- + +### 3. 以太坊的狀態（State） +- **以太坊是狀態機（State Machine）：** 透過交易在不同狀態間轉換。 +- 與比特幣不同，以太坊維護**全域狀態**（Global State），而比特幣只維護 UTXO（未花費交易輸出）。 +- **狀態的組成部分：** + - 以太坊地址、餘額 + - 智能合約的代碼與數據 + - 當前網絡狀態（State & Network State） + +--- + +### 4. 交易（Transactions） +- 交易會觸發**狀態轉換（State Transition）**，透過 EVM 進行處理。 +- 交易在 EVM 內部執行後，如果合法，就會改變以太坊的全域狀態。 + +--- + +### 5. DevP2P（點對點網絡通信） +- **作用：** 執行層客戶端透過 DevP2P 傳播交易與區塊。 +- 交易先存入**記憶池（Mempool）**，再透過 P2P 傳遞給其他客戶端。 +- 每個接收交易的節點都會驗證交易的有效性，並再次廣播至網絡。 + +--- + +### 6. JSON-RPC API（執行層對外接口） +- **用途：** + - 透過 JSON-RPC API 與執行層互動，例如查詢以太坊狀態或發送交易。 + - 錢包（如 MetaMask）或 DApp 透過 JSON-RPC API 與以太坊網絡通訊。 +- **交易流程：** + 1. 使用錢包簽署交易 + 2. 交易經執行層驗證 + 3. 廣播交易至整個網絡 + +--- + +### 7. Engine API（共識層與執行層的接口） +- **作用：** 連接共識層與執行層，提供兩類主要端點： + - **New Payload（V1/V2/V3）：** 負責區塊驗證與插入 + - **Fork Choice Updated（V1/V2/V3）：** 負責狀態同步與區塊建構 + +--- + +### 8. 同步（Sync） +- **以太坊的交易處理依賴於全球狀態，而非單一節點的本地狀態。** +- 執行層透過**LMD-GHOST 算法**決定最佳分叉選擇，並透過 Engine API 傳遞至執行層。 +- **同步方式：** + 1. 下載遠端節點的區塊 + 2. 驗證區塊，並在 EVM 中執行 + +--- + +### 9. 執行層架構組件 +- **Engine（執行引擎）：** 負責執行 Engine API，並連接至共識層。 +- **認證機制：** Engine API 透過 JSON-RPC（HTTP）提供服務，並透過 JWT（JSON Web Token）驗證請求來源。 +- **安全性：** + - Engine API **僅供共識層訪問**，不對外開放。 + - JWT 只用於驗證來源，**不加密**傳輸流量。 + +--- + +### 10. 負責交易驗證的例行程序（Routines） +- **Payload 驗證** + - 透過區塊頭（Block Header）與執行環境規則驗證區塊內容。 +- **合併後（The Merge）的變化** + - 以前，執行層負責共識、排序區塊、處理區塊重組。 + - 現在，這些任務交由**共識層**，執行層主要負責**狀態轉換（State Transition）。** + +--- + +### 11. 共識層與執行層的交互 +- **共識層如何與執行層互動？** + - 共識層在**Deneb 信標鏈規範**（Beacon Chain Specs）中定義**執行負載（Execution Payload）**。 + - 負載透過 `execution_engine` 函數傳遞到執行層。 + - **驗證流程：** + 1. **高級檢查**（如父區塊哈希、時間戳驗證）。 + 2. **基礎檢查**（輕量級驗證）。 + 3. **傳輸至執行層進行區塊驗證**。 + 4. **通知負載函數（notify payload）**：將執行負載傳遞給執行引擎。 + 5. **執行引擎執行狀態轉換，並返回成功或失敗結果**。 + +--- + +### 12. 狀態轉換函數（State Transition Function, STF） +- **區塊級狀態轉換函數（Block Level STF）** + - 是執行層的核心功能，負責區塊驗證與插入。 + - 雖然在 Geth 具體實作，但不同客戶端的 STF 概念相同。 + - 在 EELS Python 規範客戶端中，STF 才明確被提及，其他客戶端則將 STF 功能拆分至不同架構組件中。 + +參考： + +[以太坊的節點](https://ithelp.ithome.com.tw/m/articles/10289488) + +### 2025.02.12 + +#### Besu +- **私密交易**：僅限於部署或調用智能合約，無法進行 Ether 轉帳。 +- **私密智能合約**：只有指定的參與方節點可以讀取和寫入合約內容。 +- **應用場景**：適用於聯盟鏈中，特定企業之間的隱私保護需求，例如投票系統。 + +- 基本知識 + - **Ethereum 智能合約**：智能合約是可編程的區塊鏈協議，用於執行合約條款。 + - **Ballot 智能合約**：一個投票合約範例，包含投票權分配、投票、查看結果等功能。 + - **Besu 私密智能合約**：與一般智能合約的區別在於，只有參與方節點可以操作合約。 + +- Besu 私密交易參數設定 + - **PrivateFrom**：發起方的公鑰。 + - **PrivateFor**：參與方的公鑰列表。 + - **Payload**：智能合約的操作數據，編碼為 16 進位字串。 + - **GasLimit**：交易所需的 Gas 上限。 + - **Nonce**：交易序號，確保交易唯一性。 + +- 發佈私密智能合約 + - **步驟**： + 1. **定義候選人名單**：例如 `["Alice", "Bob", "Kevin"]`。 + 2. **型態轉換**：將候選人名單轉換為智能合約所需的 `[32]byte` 格式。 + 3. **參數打包**：使用 ABI 打包合約的建構函數參數。 + 4. **產生 Payload**：將合約的 Bytecode 與打包後的參數結合。 + 5. **產生 Private Raw Transaction**：使用 `NewContractCreation` 創建交易。 + 6. **發佈合約**：透過 `eea_sendRawTransaction` 發佈合約，並取得合約地址。 + +- 寫入私密智能合約 + - **賦予投票權**： + - 使用 `giveRightToVote` 函數，賦予特定帳戶投票權。 + - 打包參數並產生 Payload，發送私密交易。 + - **投票**： + - 使用 `vote` 函數，進行投票。 + - 打包參數並產生 Payload，發送私密交易。 + +- 讀取私密智能合約 + - **查看投票結果**： + - 使用 `winnerName` 函數，查看當前最高票的候選人。 + - 透過 `priv_call` RPC 方法讀取合約數據。 +--- +#### Reth + +1. **Reth 使用 MDBX 作為主要的資料庫** + - MDBX（Lightning Memory-Mapped Database Extended）是一個高效能、低開銷的鍵值存儲系統，專門設計來處理高並發讀寫操作。 + - Reth 透過一層 **抽象（abstraction）**，讓底層存儲層具有靈活性，未來若要更換 MDBX，變更的成本可以降到最低。 + +2. **Codecs（編碼/解碼）** + - Reth 透過 **Compact Trait** 來進行數據壓縮，比如： + - 壓縮 **無符號整數（unsigned integers）** 的前導 0 + - 優化存儲 **區塊頭（headers）、訪問列表（access-lists）** 等數據 + +3. **DB Abstractions（資料庫抽象層）** + - **Database Trait** + - 提供 **唯讀** 或 **讀寫** 交易的基本 API，讓 Reth 操作底層數據時不需要直接依賴 MDBX，而是透過這一層抽象來與資料庫交互。 + + - **Cursor（游標）** + - 用於 **遍歷資料庫**，提高查詢和計算效率。 + - **特點**： + - 適用於 **Merkle Root 計算**，因為連續存取數據比隨機讀取快得多。 + - 在寫入大量數據時，**先排序再寫入** 會大幅提升性能，游標可以幫助我們更有效地管理這個過程。 + +**Reth執行擴展（ExEx）：** + +Reth引入了執行擴展（Execution Extensions，簡稱ExEx），這是一個框架，用於構建高性能和複雜的鏈下基礎設施作為執行後掛鉤。可用於實現Rollup、索引器、MEV機器人等，與現有方法相比，代碼量減少了10倍以上。這使得開發人員能夠以標準化的方式構建可重用的ExEx，類似於Cosmos SDK模組或Substrate Pallets的工作方式。 + +參考： + +[如何透過 Private Transaction 操作 Hyperledger Besu 私密智能合約](https://medium.com/bsos-taiwan/how-to-use-besu-private-smart-contract-51e33c5b6d62) + +[Paradigm：介紹 Reth 執行擴充（ExEx），建構高效能的鏈下基礎設施](https://web3caff.com/zh_tc/archives/103079) + +### 2025.02.13 + diff --git a/mrmign.md b/mrmign.md index 841386a..eb6af8a 100644 --- a/mrmign.md +++ b/mrmign.md @@ -142,6 +142,53 @@ Learn [Inevitable Ethereum - World Computer](https://inevitableeth.com/home/ethe - ### 2025.02.11 +- 《Absolute Essentials of Ethereum》Ch2 **Execution Layer** + - **Ether & Transaction Fees** + - Gwei is used to denominate transaction fees. + - **gas cost** and **gas fees**. In Ethereum, computational cycles are calculated in a unit call gas. A gas unit is not a currency unit. Gas cost relates only to how many computational cycles are needed. + - *Every computational instruction(an Opcode) in a transaction has an associated gas cost.* + - The Gas Limit included in a transaction is the maximum amount of gas that a user is willing to pay for. + - Gas fees have two forms. + - **base fee**, refers to the algorithmically dynamic cost of gwei in the Ethereum network + - **priority fee**, get transaction accepted faster + - Transaction fees = gas cost * (base fee + priority fee) + - The above is pre-2021 situtaion(London Upgrade/EIP-1559) + - The base fee is burnt and removed from circulation. + - The priority fee is paied to the users called validators. + - **Transaction Structure** + | Field | comment | + |---|---| + | From | sending address | + | To | receiving address | + | Digital Signature | a signature produced using the private key of the sender | + | Nonce | show how many transactions an account has made | + | Value | the ETH to be transfered | + | Input Data | Input data(message call) ; Initialise(contract creation) | + | Gas Limit | limit on gas | + | Max Priority Fee | maximum priority fee you will pay | + | Max Fee | maximum overall fee you will pay | + - **Ethereum Virtual Machine(EVM)** + - the most important field is the **Input Data**, because it contains the function we want to call and the arguments we want to pass. + - it follows Application Binary Interface(ABI) format. + - functions are identified in the ABI specification by the reference MethodID. + - `transfer(address to, uint256 value)` + - MethodID: `0xa9059cbb` + - ByteCode: `0xa9059cbb00000000000000000000009f11260cb6427c20a019780d99d3a2d7ffe9a25300000000000000000000000000000000000000000000000000002c8650c0` + - The EVM interprets and executes the Input Data field using the following: + - **Virtual Read-Only Memory(ROM)**: Reads the code of an involved contract account + - a temporary state for processing the transactions: + - **Program Counter**: The program counter tracks what instructions from the contract code need to be processed next + - **The Stack**: The EVM uses a stack-based model for executing code + - **EVM Memory**: Temporary memory used within the machine state to track changes + - **Gas counter**: Tracks the gas used. Reverts if no more gas is available and undoes the proposed state changes. + - **Storage**: changes are recorded permanently to reflect the new world state that emerges from the temporary machine state. + - **ERC-20** + - The ERC-20 token standard creates fungible tokens. + - **ERC-721** + - ERC-721 is designed to create Non-Fungible Tokens(NFT). *ERC-721 tokens are unique.* + - usually an NFT smart contract builds a collection of items that are a similar type, but with unique differences. + - **Decentralised Application(dApps)** + - In an Ethereum context, a dApp refers to the smart contract plus the non-blockchain technologies it combines with to aid the user experience. ### 2025.02.12 diff --git a/phoebe-dot.md b/phoebe-dot.md index 4ea9c48..17b03a2 100644 --- a/phoebe-dot.md +++ b/phoebe-dot.md @@ -63,7 +63,7 @@ Note ### 2025.02.12 -Note +向AI 老师请教了一下关于ZK技术的底层逻辑，好难理解啊，是怎么把中文组成这样让人看不懂的句子的 😎 慢慢理解吧 大脑吸收需要时间 ### 2025.02.13 diff --git a/poyucheese.md b/poyucheese.md index 5234d41..ec5804c 100644 --- a/poyucheese.md +++ b/poyucheese.md @@ -55,4 +55,20 @@ timezone: Asia/Shanghai 今天沒時間看新的東西，簡單複習消化 week 2 的內容，看其他人的筆記也能收穫很多不同觀點的看法。 +### 2025.02.11 + +#### [SGweek3](https://epf.wiki/#/eps/week3) + +今天看了 week 3 的內容，是關於以太坊的共識，包含爲什麼需要共識機制——因為要做到去中心化，此類共識機制如何解決拜占庭問題（確保惡意節點難以攻擊）： + +- **PoW (Bitcoin)** 使創建區塊難度提升，攻擊成本大 +- **PoW + GHOST (Ethereum1.0)** 以太坊的出塊時間比 bitcoin 短，所以容易出現分叉 (新創建的區塊來不及被廣播)，使用 GHOST 協議和獎勵接受沒成為最長鏈的叔塊，也保護礦工的權益 +- **PoS + Casper FFG + LMD GHOST (Ethereum2.0)** + - **Casper FFG (Friendly Finality Gadget)** + + >採用投票機制，驗證者透過 質押 ETH 來表決哪個區塊應該成為最終區塊。惡意驗證者若投票錯誤，將面臨懲罰。 + - **LMD GHOST (Latest Message Driven Greediest Heaviest Observed Subtree)** + + >透過權重最大（最多驗證者投票的）的子樹來決定主鏈，確保惡意節點無法輕易影響共識。 + diff --git a/ppatrick007.md b/ppatrick007.md index 247b9d7..9e4d31c 100644 --- a/ppatrick007.md +++ b/ppatrick007.md @@ -188,4 +188,19 @@ Hi, 我是国内一名理科研究生，会一些编程语言，平时科研主 - **深度加密（Deep Cryptography）**：研究更高效的加密方法，以提高隐私性和安全性。 +### 2025.02.11 + +### 主题：共识层与执行层规范（Consensus and Execution Spec） + +#### 主要内容 +今天学习的重点是深入了解 **共识层（Consensus Layer）** 和 **执行层（Execution Layer）** 的规范。 + +#### 共识层规范（Consensus Specs） +- **Hsiao-Wei Wang 的讲座**：介绍了以太坊 **共识规范（Consensus Spec）**，包括其架构、工作原理以及如何在不同的客户端实现。 +- **Pyspec**：通过 Python 编写的以太坊共识规范实现，适用于验证共识规则。ß + +#### 执行层规范（Execution Layer Specs） +- **Sam Wilson 的讲座**：讨论了 **执行层规范（EELS）**，重点是执行引擎与智能合约执行过程的规范定义。 +- 通过演示，Sam 展示了如何通过修改执行层规范来添加新的 **EVM 操作码（Opcode）**。 + diff --git a/rayjun.md b/rayjun.md index e914730..55126c6 100644 --- a/rayjun.md +++ b/rayjun.md @@ -209,5 +209,28 @@ EVM 中有一些关键的组件： - 应用：Celo - 在以太坊协议中，节点和验证者是共识系统的参与者，slot 和 epoch 控制共识时间，Block 和 Attestations 是共识系统中的核心要素，达成共识需要依赖这些数据 - +### 2025.02.12 +- 以太坊从 PoW 转成 PoS 的核心原因：能耗高且扩展性有限 + - 以太坊当前的共识协议：LMD GHOST + Casper FFG = Gasper + - PoW 和 PoS 本身不是共识协议，而是一线共识协议的机制，主要作用是用来抵抗 Sybil 攻击，让参与网络有一定的成本 + - PoW 和 PoS 都是通过分叉选择来选择链的方向： + - PoW：依据完成的总计算量 + - PoS：依据特定链的总质押价值 +- The Merge 在升级的时候使用的是 TTD 而不是区块高度， TTD 其实就是每个区块难度的累加，之所以不使用区块高度，是为了方式有人恶意加速或者减缓 The Merge 升级的进度 +- 以太坊的共识层称之为 Beacon Chain，它负责监督提出和证明新区块的验证者，确保网络的完整性和安全性。 + - Validator 的限制 + - 当前需要质押 32 个 ETH 才能成为 Validator + - Block Proposer 的选择过程依赖 RANDAO 和 VDF 来保证随机性 + - Validator 会被分成多个委员会，负责区块提议和证明 + - 如果 Validator 作恶，那么他们的资金就会面临处罚 + - slot 和 epoch：每个 slot 12 秒，一个 epoch 为 32 个 slot，每个 slot 都需要指定一名 validator 来提议区块，而验证委员会者证明该区块的有效性 + - Block Proposer 由 RANDAO 选出，选择的过程中，会加权计算 Validator 的余额 + - Validator 可以同时成为 Block Proposer 和 Committees 成员，这种情况很少，概率为 1/32 + - Validator 和 Attestations：Blocker Proposer 时被伪随机（因为缺乏真正的随机院）选择来构建区块的验证者，大多数情况下，验证者时对区块进行投票的 asstester，这些投票记录在信标链中 + - Committees：委员会至少由 128 名验证者组成，在一个 epoch 中，每个 slot 都会分配至少一个 Committees，也就是说在一个 epoch 中，validator 只会存在一个 Committees 中，所以这里也就说明了为什么一个 Validator 在一个 slot 中 同时为 Block Proposer 和 Committees 成员的概率很小 + - Committees 中 Validator 的数量至少要有 128 个 + - 如果网络的 Validator 少于 8192 个，那么就会有一些 slot 的委员会人数不足，如果 Validator 的数量超过 8192 ，那么每个 slot 都至少有两个完整的委员会 + - 如果委员会的规则不足 128，整个网络的 validator 人数少于 4096 时，网络的安全性就会很低 + - Blob 中的数据实际存储在共识层，执行层只存储 blob 的 KZG commitments + diff --git a/realgu.md b/realgu.md index b13ca2f..8336313 100644 --- a/realgu.md +++ b/realgu.md @@ -30,4 +30,32 @@ timezone: Asia/Shanghai - why don't we just have a hash of all transactions concatenated? why do we run a lot more hashes by building a merkle tree? The Merkle tree is useful because it allows users to verify a specific transaction without downloading an entire blockchain—which can be hundreds of gigabytes in size. For example, say that you wanted to verify that transaction TD is included in the block in the diagram above. If you have the root hash (HABCDEFGH), you can query the network about HD. It might return HC, HAB, and HEFGH. The Merkle tree allows you to verify that everything is accounted for with three hashes: given HAB, HC, HEFGH, and the root HABCDEFGH, HD (the only missing hash) has to be present in the data. Additionally, the structure is helpful because the process is very fast. It seems as if hashing thousands of transactions would be time-consuming, but modern computers can do it in milliseconds. Because it is easy for computers to do, it makes sense to use the technique to verify large amounts of data, like the data contained in a blockchain. Merkle roots, trees, and block hashes are what create the unalterable chain of transactions and blocks. - merkle-patricia trie [checkthis](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) +### 2025.02.10 +- 1e = 1 billion gwei +- 一笔交易大概需要21000 gas unit，每个block 的 gas limit 目前大概 30m gas unit，base fee是 gwei / gas unit +- 晕了 EL Spec 很难读下去，暂时跳过吧 + +### 2024.02.11 +State Trasition Function: +``` +func stf(parent types.Block, block types.Block, state state.StateDB) (state.StateDB, error) { //1 + if err := core.VerifyHeaders(parent, block); err != nil { //2 + // header error detected + return nil, err + } + for _, tx := range block.Transactions() { //3 + res, err := vm.Run(block.header(), tx, state) + if err != nil { + // transaction invalid, block is invalid + return nil, err + } + state = res + } + return state, nil +} +``` +问题: what exactly does a 'state' contains? what are the tries? + + + diff --git a/rectinajh.md b/rectinajh.md index fdf3080..a4136bd 100644 --- a/rectinajh.md +++ b/rectinajh.md @@ -37,4 +37,7 @@ https://epf.wiki/#/wiki/protocol/history 今天学习执行层数据规范最初被指定是根据黄皮书来设计的 https://epf.wiki/#/wiki/EL/el-specs +### 2025.02.12 +今天学习执行层客户端的架构设计 +https://epf.wiki/#/wiki/EL/el-architecture diff --git a/tannerang.md b/tannerang.md index 7bd7ae5..97cb886 100644 --- a/tannerang.md +++ b/tannerang.md @@ -39,6 +39,9 @@ EIP-1559 - 新建立的合約地址會是 `address = keccak256(rlp.encode([sender_address, sender_nonce]))[12:]` - 新合約 Nonce 等於 1，Balance 等於 pre-existingValue + msg.value​​ `σ∗[newAccount]≡(Nonce=1,Balance=preexistingValue+Tvalue​​,Storage=TRIE(∅)​,CodeHash=KEC(())​))` +### 2025.02.11 + +把 Week2 影片看完，筆記明日補上 diff --git a/tienshaoku.md b/tienshaoku.md index bbd1e60..085e0c9 100644 --- a/tienshaoku.md +++ b/tienshaoku.md @@ -99,6 +99,8 @@ user ---(User API)>>> execution engine ---(Engine API)>>> beacon node ---(Beacon ### 2025.02.09 +### 2025.02.10 + #### Execution Layer Spec - The Execution Layer focuses exclusively on executing the state transition function (STF). This role addresses two primary questions: diff --git a/yahsinhuangtw.md b/yahsinhuangtw.md index dc13bd3..32f017e 100644 --- a/yahsinhuangtw.md +++ b/yahsinhuangtw.md @@ -50,4 +50,16 @@ https://youtu.be/UihMqcj-cqc?si=MqL3ac9Xg30LPJmE 這裡要強調的重點是，merkle tree 在以太坊驗證資料上持續扮演重要角色。以太坊技術底層中到處都有使用到 merkle tree，主要用途是在以太坊的驗證資料方面。你要驗證有龐大的 40 gb 的 state 資料的某一塊小小的資料時，你不需要全部 40 gb 都撈出來驗證，只要一小塊 tree 的某些節點資料拿出來就可以驗證。 +### 2025.02.12 + +今日晚上殘酷學習時間，拜讀了 Nic Lin 林老師今天發表的新文章「Ethereum Pectra 硬分叉介紹」https://medium.com/taipei-ethereum-meetup/ethereum-pectra-eips-introduction-1f90f4ea25d5 + +Screenshot 2025-02-12 at 9 12 55 PM + +中間段落提到，EIP-7251: Increase the MAX_EFFECTIVE_BALANCE 這段，提及 EIP-7251 之後，質押下限（MIN_ACTIVATION_BALANCE）仍然是 32 ETH，但上限（MAX_EFFECTIVE_BALANCE）大幅調高為 2048 ETH。這裡意思是之後就可以質押 32~2048 ETH 這麼大一個範圍。 + +Screenshot 2025-02-12 at 9 12 16 PM + +還有一段提到 EIP-7702 這個改進，最關鍵的改動是，之後 EOA 可以搖身一變成合約。老師文中舉例，如果你填一個 Safe 合約地址，那你的 EOA 就會變身成為 Safe 合約。 + diff --git a/yenchihliao.md b/yenchihliao.md index 51d87af..8ea24fe 100644 --- a/yenchihliao.md +++ b/yenchihliao.md @@ -97,4 +97,18 @@ Picked up/strengthened some key concepts - p2p protocol broadcast tx to square root of peers - snap sync protocol: contrast to full sync +### 2025.02.11 +Finished week3 + +Picked up/strengthened some key concepts +- Each "slot" has a block unless a validator failed/missed to propose +- Every blocks have a bunch of "attestation" +- Attestations of a block are included into the next block +- Every 32 slots forms a "Epoch" (for mainnet) +- Slashes and rewards are evaluated at the end of every epoch +- The full validator set is randomly shuffled and distributed to one of slots in a epoch +- Each validator only verifies once in a epoch +- Justification: 2/3 of validators attested +- Finialize: Justifying a justified block + diff --git a/zhouCode.md b/zhouCode.md index 932c4ba..660a2fd 100644 --- a/zhouCode.md +++ b/zhouCode.md @@ -538,4 +538,85 @@ func build(env Environment, pool txpool.Pool, state state.StateDB) (types.Block, - 由于能源需求低，发行较少的以太币就可以激励大家参与 - 与工作量证明相比，对不当行为的经济处罚让 51% 攻击的代价变得更高。 - 如果 51% 攻击是为了攻破加密经济的防御，那么社区可以求助于诚实链的社交恢复。 + +### 2025.02.11 + +#### Study Group 2024 week4 学习 + +#### 以太坊测试与安全 + +##### 测试的核心 + +- **预状态（Pre-state）**：测试前的区块链状态（合约代码、存储、余额等）。 +- **环境（Environment）**：区块参数（时间戳、燃料限制、基础费用、分叉激活时间）。 +- **交易（Transactions）**：触发特定EVM操作的输入数据。 +- **后状态（Post-state）**：测试后预期的区块链状态（存储变更、状态根等）。 +- **测试生成（Test Filling）**：通过工具（如Go Ethereum的`evm`模块）将测试定义转换为可执行的测试夹具（Fixture）。 + +##### **测试工具与框架** + +- **执行规范测试库（Ethereum Execution Spec Tests）**： + - 使用Python编写，支持复杂参数化测试（如不同分叉规则）。 + - 依赖Go Ethereum生成测试夹具，未来计划通过[EELS](https://github.com/ethereum/execution-specs)实现独立验证。 +- **Hive框架**： + - 用于跨层端到端测试，模拟共识层与执行层的交互（如Engine API调用）。 + - 支持并行测试多客户端（如Geth、Nethermind）的兼容性。 + +##### **共识层测试** + +- **共识规范测试（Consensus Spec Tests）**： + - 将规范与测试代码合并，覆盖信标链状态转换、分片逻辑等。 + - 生成多种格式的测试夹具（如区块有效性、质押操作）。 + +##### **安全漏洞与披露** + +- **潜在风险**： + - 客户端错误验证有效/无效区块可能导致网络分叉。 + - 不同层（执行层/共识层）的客户端兼容性问题。 +- **漏洞披露流程**： + - 发现漏洞后通过[以太坊漏洞赏金计划](https://bounty.ethereum.org/)提交，最高可获得25万美元奖励。 + - 公开披露需在修复后进行（参考[历史案例库](https://github.com/ethereum/eth-sec)）。 + +### 2025.02.12 + +#### Study Group 2024 week5 学习 + +#### **合并（The Merge）** + +- 以太坊从工作量证明（PoW）转向权益证明（PoS）的重要性，信标链（Beacon Chain）的启动与合并后的经济安全性提升。 +- 最终性（Finality）概念的引入（12.6分钟完成区块最终确认）。 +- 签名聚合（Signature Aggregation）和秘密领导者选举（Whisk协议）的研究进展。 + +#### **激增（The Surge）** + +- **数据可用性采样（DAS）**: 通过多项式承诺（如KZG）实现高效数据验证，支持Rollup扩展。 +- **EIP-4844（Proto-Danksharding）**: 引入“Blob”存储结构，降低Rollup数据成本，已上线主网。 +- **Rollup分类**: 乐观Rollup与零知识Rollup的对比，强调数据可用性对挑战机制的重要性。 + +#### **The Scourge** + +- **提议者-构建者分离（PBS）**: 减少验证者中心化风险，通过MEV-Boost临时方案过渡到协议内实现。 +- **最大有效余额（Max EB）**: 从32 ETH提升至2048 ETH，优化验证者效率。 +- **流动性质押（Liquid Staking）**: 探索降低罚没风险的新机制（如质押上限）。 + +#### **验证（The Verge）** + +- **Verkle树**: 取代Merkle树，实现更高效的轻客户端验证和状态证明，支持无状态验证。 +- **ZK化（ZK-SNARKs）**: 未来将共识层和执行层交易验证集成零知识证明，提升可扩展性。 + +#### **清洗（The Purge）** + +- **历史过期（EIP-4444）**: 节点不再存储超过1年的历史数据，依赖Portal Network等去中心化存储方案。 +- **状态简化**: 移除旧版协议支持（如RLP序列化），向SSZ过渡。 + +#### **挥霍（The Splurge）** + +- **账户抽象（ERC-4337）**: 支持智能合约钱包，实现社交恢复、批量交易等高级功能。 +- **EVM优化（EOF）**: 提升EVM兼容性，支持模块化升级。 +- **加密创新**: 全同态加密（FHE）、一次性签名（One-Shot Signatures）等前沿研究。 + +#### 其他关键讨论 + +- **量子抗性**: 长期规划中替换BLS签名，采用抗量子算法（如STARKs）。 +- **路线图复杂性**: 未来可能面临协议僵化（Ossification）风险，需平衡创新与稳定性。 diff --git a/zhwindy.md b/zhwindy.md index c84f409..6d75867 100644 --- a/zhwindy.md +++ b/zhwindy.md @@ -50,20 +50,28 @@ timezone: Asia/Shanghai ### 2025.02.10 今天深入学习第二部分 以太坊虚拟机EVM的内容: -* 预编译合约 -* 以太坊状态机: state machine -* 虚拟机范式: virtual machine paradigm +* 以太坊状态机(state machine) +* 虚拟机范式(virtual machine paradigm) * EVM 和 EVM bytecode -* 栈(Stack) 和 程序计数器(program counter) +* 程序计数器(program counter) * Gas +* 栈(Stack) * 内存(Memory) * Storage * Wrapping up * EVM upgrades * EVM实现: Go(Geth), Rust(revm), Python(py-evm), C++(EVMONE) +* 预编译合约 ### 2025.02.11 +今天继续学习第二部分以太坊虚拟机的细节: +* 数据结构MPT: Merkle Patricia Trie +* Transaction剖析 +* JSON-RPC API +* 数据序列化RLP +* 区块构建 + ### 2025.02.12 ### 2025.02.13 diff --git a/zt2.md b/zt2.md index f80fb03..226fdfb 100644 --- a/zt2.md +++ b/zt2.md @@ -203,4 +203,83 @@ CA 具有两个附加属性： - 代码 - 存储 +### 2025.02.11 + +#### 执行层（Execution Layer） + + +##### 执行层的定义 + + +以太坊执行层是最初由黄皮书引入的，实现了以太坊作为全球计算机的状态转换（State Transition Function 或 STF），通俗来说，它具备两个核心角色： + + +- 决定某个区块是否能够上链 +- 决定该区块上链后，整个以太坊全球计算机的状态如何发生变化 + +为了支持核心角色，它也要负责一些具体的工作如： + + +- 验证区块链数据并进行本地副本保存 +- 实现稳定的客户端通信协议 +- 维护交易池 +- 满足共识层的要求 + +##### 执行层具体架构 + + +经过合并升级，以太坊网络中的执行层功能已发生结构性调整。此前，该层级肩负着区块链共识管理、区块序列验证及链重组处理等核心职责。而当前架构下，这些核心功能已全面移交至共识层运作，执行层因此实现了职能精简化转型。在现有体系中，执行层可被抽象理解为专门执行状态转换功能的核心模块。 + +![image](https://res.craft.do/user/full/ca875b0a-92a3-940e-21e3-a9ace35d9a4b/doc/EFD8C5C2-91E3-4D88-9218-08555760530E/9EB98687-5A5F-4D89-886E-B8984A0377BB_2/DscRQ5xcQAo0c0IyjH3jnNeZ2QMyGiB7En0mywTiQHAz/Image.png) + +从这张图中可以看到，执行层通过左下角的协议实现与其他执行层完成通信，在通信建立后接受其他执行层客户端发来的交易与区块，并同步维护本地状态（State）同时将新交易通过引擎 API 向共识层传递，接收共识层处理结果后交给 EVM 虚拟机执行具体交易逻辑，并完成状态转换后同步到本地状态（State）中，交给网络层协议完成状态对其他客户端的同步，最终利用 JSON-RPC 接口向 WEB3 钱包提供服务。 + + +- Engine API：共识层与执行层之间唯一的沟通桥梁。 + +关键概念：`execution_engine` + +###### execution_engine + + +`execution_engine` 负责执行层与共识层之间的沟通，同时承担了大量的复杂工作，简要描述如下： + + +1. 共识层获得区块后，对区块进行一系列高层级验证，该类验证比较轻量级，如验证父哈希的准确性、时间戳的准确性等等 +2. 共识层简单验证通过后，将具体区块细节传递给执行层，执行层进行精确验证，如区块头精确性验证、交易状态验证等 +3. 执行层完成核心验证后，最终交给执行引擎进行交易，并实现状态转换，通知共识层状态转换结果。 + +（注意，区块中的单个交易执行失败，整个区块都会被打回重来） + +### 2025.02.12 + +#### Bridge + +无论是智能合约还是以太坊，其根本是建立在一个个的节点（node）之上，依靠节点上 EVM 虚拟机的计算能力实现上层业务逻辑的构造。 + +其缺陷在于，无论智能合约逻辑有如何复杂，但它永远只能够在以太坊钩织的数据里漫游而无法接触到以太坊网络以外的数据，因为 EVM 限制其获取以太坊网络以外的数据，如互联网数据。 + +脱离了外部世界的以太坊合约是不完整的，而“桥”则是一个构建起外部世界与以太坊世界数据流通的通道。 + +运行了 bridge 的服务，可以通过主动向以太坊链上的合约 push 外部世界的数据，从而完成外部数据上链的工作，这样，以太坊网络中，就存在了外部世界的数据，这通常维护在某个智能合约中。 + +![image](https://github.com/user-attachments/assets/2075b70e-4bb8-40b8-a0c3-7ee7ae4ba66f) + +同样，如果某个服务能够将两个链的数据进行互通，则也可以视作一种桥：Blockchain Bridges + +![image](https://github.com/user-attachments/assets/2ed7c94c-3782-4d36-b15b-17a3b0f538d3) + +这里就引入了另一个概念，预言机（Oracle）：区块链预言机是位于以太坊与外部世界之间的实体，负责在两者之间传递信息。 + +预言机一般包括： + +- Oracle 智能合约部分：存在于以太坊中的代码，处理请求并协调内部与外部客户端之间的交互。 +- Oracle 外部接口（节点）：与以太坊进行通信的计算机和服务器。节点是能够进行极其快速且低成本计算的中心化实体。它们还连接到外部数据源，并可以将这些数据发布到链上。 + +![image](https://github.com/user-attachments/assets/ea77b6ba-dfc6-4fa8-8d3b-4cc25fcfd002) + +预言机解决方案：[Chainlink](https://chain.link/): + +image +