区块链概览

最后更新：2026 年 9 月 12 日

本节涵盖内容

本仓库提供 Kubernetes 和 EKS 培训资料。之所以包含区块链，是因为对 Kubernetes 运维人员来说，区块链节点是一种非典型工作负载。

大多数 Kubernetes 工作负载属于两类之一：无状态，因此可以随时终止并重启；或有状态，但可以交由托管服务（RDS、ElastiCache）运行。区块链节点两者都不是。

常见假设	区块链节点的实际情况
“Pod 随时都可以替换”	重建数百 GB 至数 TB 的本地状态可能需要数天
“横向扩容会提高吞吐量”	增加副本可以扩展 RPC 读取能力和可用性，但不会自动提高底层链的写入/共识能力
“健康检查通过就能提供服务”	同步落后的节点可能通过健康检查，却返回错误数据
“滚动更新可以实现零停机部署”	协议激活前，可以对兼容分叉的版本进行金丝雀发布/滚动发布；协议期限与分叉后的回滚兼容性是不同的约束
“从备份恢复数据”	链上状态可以通过重放恢复，但密钥丢失就无法挽回

这些差异会影响实际运维决策。本节旨在介绍这些问题。

#	文档	回答的问题
1	区块链基础知识	什么是共识、Merkle 树、P2P 和最终性？这些设计为何会带来相应的运维特征？
2	在 EKS 上运行区块链节点	如何实际管理 StatefulSet、存储、P2P、同步和升级？
3	Amazon Managed Blockchain	托管服务能接管哪些工作、无法处理什么？AWS 账本服务的变化意味着什么？
4	金融服务视角	联盟治理、隐私、监管和与现有基础设施集成方面有哪些实际问题？

文档 1 是文档 2–4 的前置内容。如果你已熟悉区块链，可以从文档 2 开始；但要理解文档 2，仍需阅读文档 1 中“运维特征的来源”部分。

本节有两类不确定性，并分别处理。

① 快速演进的协议规范：使用已公布的激活日期，而不要假设升级周期固定。硬件、质押和 blob 处理方式都可能变化；以下数据是带日期的参考信息，并非保证仍适用的当前要求。

② 非一手资料中的数据：节点硬件要求等数值通常来自社区或厂商估算，而非官方规范。此类数值会注明来源性质并以范围表示。

未经官方文档确认的内容会放在 Needs verification 提示块中。制定生产设计前，应直接查阅协议官方文档和客户端发布说明中的当前值。