写作动机与背景
最近看到月之暗面（即开发 Kimi 大模型的公司）的招聘要求，其中一条为：
能够说出任意软件的任意操作的全链路过程并根据需要无限细化。
我用这条要求自省了一下，发现自己虽一直在学习和研究各类 DeFi 协议，但对承载这些协议的底层公链技术细节，了解得并不全面。比如，若没有深入掌握以太坊的交易（transaction）细节、出块机制等，要开发一款以太坊生态的 DEX 套利程序，几乎是无法实现的。
网上随手一搜，能找到大量以太坊学习资料，但我在学习时发现，这些资料大多呈现 “两极分化”：一类是从高抽象层面做概览式讲解，只点到核心概念，缺乏深入拆解；另一类则默认读者已有充足背景知识，直接切入源码细节，对新人不够友好。
这让我萌生了撰写此专栏的想法：一方面，记录自己的学习过程，方便后续查阅；另一方面，希望在理论与实践间找到平衡 —— 既从抽象层面讲透设计思想及来龙去脉，又深入 go-ethereum 源码，拆解设计如何落地为具体的代码实现。
我期望的目标是：读者在阅读完这个专栏后，能够深入理解以太坊的所有核心设计原理与实现细节。假设有一天以太坊的代码突然消失了，我们也能够从零开始重新设计并构建出一套完整的以太坊系统——至少在理论层面上知道如何实现。
目标读者定位
专栏主要面向以下两类读者：
最适合的读者：计算机相关专业的读者。在已有知识（如数据结构、操作系统、网络等）的辅助下，可以毫无障碍地跟进专栏内容。
也能读的读者：已经在使用 Web3 应用（如钱包转账）的人，想了解底层机制和原理。专栏内容尽可能自包含，大部分情况下都能跟上节奏。只有涉及到过于基础的专业知识时，可能需要跳出去自己补一下。不过 AI 时代这也不再是难事，在 AI 工具的帮助下，几分钟之内便能快速了解一个概念。
无论你的背景如何，只要愿意学习，都能跟上这个专栏的节奏。
关于编程语言
研究以太坊系统具体的实现时，专栏分析的对象是以太坊官方使用 Go 语言开发的客户端（go-ethereum）。代码会有详细注解，遇到不熟悉的语法也可以用 AI 工具快速了解。因此即使没有 Go 语言基础，也能理解代码逻辑和设计思路。
专栏框架
渐进式讲解
以太坊是一套复杂系统，包含大量精心设计的数据结构、算法与协议。高效的学习方法在于先理解 “设计背后的原因”，再结合设计逻辑去看具体实现。
为帮助读者更好地掌握以太坊的设计思路与实现原理，对于多数核心概念，我们将采用以下结构讲解：
- 明确问题：先界定需要解决的核心需求或待处理的关键问题；
- 分析局限：解释常规解决方案为何无法满足以太坊的特殊需求；
- 拆解设计：介绍以太坊的设计是如何针对性解决上述问题的；
- 落地实现：深入 go-ethereum 源码，拆解设计思路具体实现；
- 未来演进：探讨当前设计存在的不足，及社区提出的改进提案与发展方向。
以讲解以太坊状态存储系统为例，我们将按照以下步骤展开：
- 以太坊需要记录 address → 余额的映射
- Hash table 虽然可以实现 key-value 存储，但无法满足可验证性需求
- 引入 Merkle Trie 结构，结合前缀树和 Merkle Tree 的优势，实现可验证的状态存储
- 分析 go-ethereum 中如何通过 Trie 结构实现账户状态的存储和查询
- 探讨 Trie 的性能瓶颈，以及 Verkle Tree 提案如何改进
通过这种方式，读者不仅知道"代码是这样写的"，更理解"为什么这样设计"，以及"未来会如何演进"。
DAG 知识构建
可以对以太坊的知识体系按层级拆解：底层核心概念相对独立，上层复杂概念则由底层概念组合衍生而成。为降低学习时的理解负担，专栏采用有向无环图（DAG） 式的知识组织逻辑，从底层基础概念开始，逐步向上搭建完整知识框架。其核心思路可概括为：
- 自底向上，逐层构建：底层技术模块（如 RLP 编码、加密算法、Trie 数据结构等）具备独立功能，是搭建上层组件的‘基础砖块’；上层组件（如交易 Transaction、以太坊虚拟机 EVM）则是对底层技术模块的整合与应用。
- 避免循环依赖：每个概念在讲解时，其依赖的前置知识已在之前的文章中讲清楚。学习某个概念时，不会被突然冒出的新概念打断思路，也不需要跳出去补充其他知识。
- 心智负担最小化：这种组织方式符合系统构建的自然过程。就像盖房子，先准备砖块、水泥等材料，再用这些材料搭建墙体、屋顶，最后建成完整建筑。
以下是专栏知识体系的层级结构示意：
graph TD ETH[以太坊系统] --> Consensus[共识机制] ETH --> Client[客户端] Client --> TX[Transaction 交易] Client --> EVM[EVM 虚拟机] TX --> RLP[RLP 编码] TX --> State[状态管理] TX --> Crypto[加密算法] EVM --> State EVM --> Crypto EVM --> Opcode[操作码] State --> Trie[Merkle Patricia Trie] State --> DB[键值存储] Trie --> Merkle[Merkle Tree] Trie --> Patricia[Patricia Trie 前缀树] Crypto --> Hash[哈希函数 Keccak-256] Crypto --> Signature[数字签名 ECDSA] Crypto --> Curve[椭圆曲线 secp256k1]
专栏文章将按照自底向上的顺序撰写，先讲解 RLP、加密算法、Trie 等基础组件，再逐步展开 Transaction、EVM 等核心概念，最后深入客户端和共识机制。
专栏规划
本专栏将按照 DAG 知识地图的层次结构，从底层往上逐步展开：
- 基础组件层：RLP 编码、加密算法（哈希、签名、椭圆曲线）、Merkle Patricia Trie 等
- 核心概念层：交易（Transaction）、以太坊虚拟机（EVM）、状态管理机制等
- 系统层：客户端架构、共识机制、P2P 网络协议等
以太坊是一套复杂的系统，包含大量精心设计的组件与机制 —— 仅其 Go 语言版本的实现代码就超过 30 万行。要完整剖析整套系统并非易事，需要较长的讲解周期。
本专栏将以不定期更新的形式持续撰写，直至把以太坊系统的设计逻辑与实现细节讲解透彻。如有兴趣，欢迎订阅关注 👀。此外，文章规划可能会根据实际情况调整，以便更清晰地呈现内容。
版本说明
以太坊是一个快速发展的项目，代码库持续迭代更新。为了避免不同版本之间的代码差异导致读者困惑，本专栏所有代码示例和分析均基于以下特定版本：
- 代码仓库：ethereum/go-ethereum
- 版本号：
v1.16.7 - Commit Hash：
b9f3a3d964ed3d31e710ec7dd66da9181477ecb2 - 对应 Fork：Fusaka
锁定版本可以确保文章中的代码示例、函数签名、实现逻辑与描述保持一致。读者如果在本地阅读源码，建议 checkout 到上述 commit，以获得最佳阅读体验。
👏欢迎通过各种方式交流反馈，共同探讨以太坊的设计与实现。
-- EOF --