追梦人物❤️包子 博主
一直走在追梦的路上。

0x00:专栏开篇

2026-01-2020 阅读0 评论

写作动机与背景

最近看到月之暗面(即开发 Kimi 大模型的公司)的招聘要求,其中一条为:

能够说出任意软件的任意操作的全链路过程并根据需要无限细化。

我用这条要求自省了一下,发现自己虽一直在学习和研究各类 DeFi 协议,但对承载这些协议的底层公链技术细节,了解得并不全面。比如,若没有深入掌握以太坊的交易(transaction)细节、出块机制等,要开发一款以太坊生态的 DEX 套利程序,几乎是无法实现的。

网上随手一搜,能找到大量以太坊学习资料,但我在学习时发现,这些资料大多呈现 “两极分化”:一类是从高抽象层面做概览式讲解,只点到核心概念,缺乏深入拆解;另一类则默认读者已有充足背景知识,直接切入源码细节,对新人不够友好。

这让我萌生了撰写此专栏的想法:一方面,记录自己的学习过程,方便后续查阅;另一方面,希望在理论与实践间找到平衡 —— 既从抽象层面讲透设计思想及来龙去脉,又深入 go-ethereum 源码,拆解设计如何落地为具体的代码实现。

我期望的目标是:读者在阅读完这个专栏后,能够深入理解以太坊的所有核心设计原理与实现细节。假设有一天以太坊的代码突然消失了,我们也能够从零开始重新设计并构建出一套完整的以太坊系统——至少在理论层面上知道如何实现。

目标读者定位

专栏主要面向以下两类读者:

最适合的读者:计算机相关专业的读者。在已有知识(如数据结构、操作系统、网络等)的辅助下,可以毫无障碍地跟进专栏内容。

也能读的读者:已经在使用 Web3 应用(如钱包转账)的人,想了解底层机制和原理。专栏内容尽可能自包含,大部分情况下都能跟上节奏。只有涉及到过于基础的专业知识时,可能需要跳出去自己补一下。不过 AI 时代这也不再是难事,在 AI 工具的帮助下,几分钟之内便能快速了解一个概念。

无论你的背景如何,只要愿意学习,都能跟上这个专栏的节奏。

关于编程语言

研究以太坊系统具体的实现时,专栏分析的对象是以太坊官方使用 Go 语言开发的客户端(go-ethereum)。代码会有详细注解,遇到不熟悉的语法也可以用 AI 工具快速了解。因此即使没有 Go 语言基础,也能理解代码逻辑和设计思路。

专栏框架

渐进式讲解

以太坊是一套复杂系统,包含大量精心设计的数据结构、算法与协议。高效的学习方法在于先理解 “设计背后的原因”,再结合设计逻辑去看具体实现。

为帮助读者更好地掌握以太坊的设计思路与实现原理,对于多数核心概念,我们将采用以下结构讲解:

  1. 明确问题:先界定需要解决的核心需求或待处理的关键问题;
  2. 分析局限:解释常规解决方案为何无法满足以太坊的特殊需求;
  3. 拆解设计:介绍以太坊的设计是如何针对性解决上述问题的;
  4. 落地实现:深入 go-ethereum 源码,拆解设计思路具体实现;
  5. 未来演进:探讨当前设计存在的不足,及社区提出的改进提案与发展方向。

以讲解以太坊状态存储系统为例,我们将按照以下步骤展开:

  1. 以太坊需要记录 address → 余额的映射
  2. Hash table 虽然可以实现 key-value 存储,但无法满足可验证性需求
  3. 引入 Merkle Trie 结构,结合前缀树和 Merkle Tree 的优势,实现可验证的状态存储
  4. 分析 go-ethereum 中如何通过 Trie 结构实现账户状态的存储和查询
  5. 探讨 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 Hashb9f3a3d964ed3d31e710ec7dd66da9181477ecb2
  • 对应 Fork:Fusaka

锁定版本可以确保文章中的代码示例、函数签名、实现逻辑与描述保持一致。读者如果在本地阅读源码,建议 checkout 到上述 commit,以获得最佳阅读体验。

👏欢迎通过各种方式交流反馈,共同探讨以太坊的设计与实现。

-- EOF --

0 评论
登录后回复