简介

EIP（Ethereum Improvement Proposal）是以太坊改进提案
任何人都能提交的标准化文档
驱动以太坊从创世区块到今天的唯一正式机制
ERC只是EIP的应用层子集
所有硬分叉升级Layer2变革账户抽象都源于EIP 好的，下面是不含任何表情、按 EIP 状态与类型分类整理的中文笔记版，适合课堂笔记、复习或写作使用。

EIP 状态

EIP（Ethereum Improvement Proposal，以太坊改进提案）在提出、讨论和落地过程中，会经历以下生命周期状态

Idea（想法阶段）

  • 处于预草案阶段，仅是初步构想
  • 不会被记录在官方 EIP 仓库中
  • 通常在论坛、Issue 或社区中进行非正式讨论

Draft（草案阶段）

  • 正式进入 EIP 生命周期的第一个阶段
  • 按 EIP 模板规范化后，由 EIP Editor 合并进仓库
  • 处于持续开发和修改中

Review（评审阶段）

  • 作者认为提案已较为成熟
  • 主动请求社区或同行进行技术评审
  • 重点关注规范完整性、可行性与兼容性

Last Call（最终审查阶段）

  • 进入最终审查窗口，通常为 14 天
  • 由 EIP Editor 指定并设置 last-call-deadline
  • 若发现需要进行规范性修改，将退回 Review 状态

Final（最终状态）

  • 成为正式标准
  • 进入终态，不再进行实质性修改
  • 仅允许修正勘误或补充非规范性说明

Stagnant（停滞状态）

  • Draft 或 Review 状态下，连续 6 个月无实质进展
  • 会被标记为停滞
  • 作者或 Editor 可重新激活并移回 Draft

Withdrawn（撤回）

  • 作者主动撤回提案
  • 该状态具有终结性
  • EIP 编号不可再次使用，重新提出需新编号

Living（持续更新）

  • 特殊状态，不进入 Final
  • 允许持续演进和更新
  • 典型代表为 EIP-1（EIP 流程规范）

EIP 类型

EIP 根据内容性质与影响范围分为以下几类

Core（核心协议类）

  • 需要共识分叉（硬分叉或软分叉）
  • 或与核心客户端和协议密切相关
  • 示例：EIP-5、EIP-211、EIP-225

Networking（网络层）

  • 涉及 devp2p、轻节点协议
  • 以及 Whisper、Swarm 等网络协议规范
  • 示例：EIP-8

Interface（接口规范）

  • 客户端 API、RPC、ABI 等接口层标准
  • 包含方法命名、调用规范等
  • 通常先在 interfaces 仓库中讨论
  • 示例：EIP-6

ERC（应用层标准）

  • 应用与合约级标准

  • 是开发者最常接触的一类

  • 示例：

    • ERC-20（EIP-20，代币标准）
    • ERC-721（NFT）
    • EIP-137（ENS）
    • EIP-681（URI Scheme）
    • EIP-4337（账户抽象）

Meta（流程与治理类）

  • 描述以太坊相关流程、规范和治理机制
  • 不直接修改以太坊协议代码
  • 通常需要社区共识
  • 属于 Process EIP
  • 示例：EIP-1

Informational（信息说明类）

  • 用于说明设计思想、背景或提供指导
  • 不提出新功能或强制性规范
  • 不一定代表社区共识
  • 实现者可以自由选择是否遵循

标识含义

文章进度说明

  • ✅ 已完稿 - 文章已完成并发布
  • 📝 待撰写 - 文章正在规划或撰写中

共识层变更标记

  • 🟥 共识变化 - 需要硬分叉或修改共识规则的EIP
  • 🟦 无共识变化 - 仅影响执行层的EIP（如大多数预编译和接口标准）

Core

ERC

Networking

Interface