1. 为什么我选择用Python写一个区块链教学项目接触区块链这个概念最早是因为加密货币的热潮。但真正让我想动手写一个区块链是因为我发现周围很多人对它的理解停在了“分布式账本”这种抽象描述上——知道它去中心化、知道它不可篡改但问到底层怎么实现的基本说不清楚。我个人的感受是与其抱着白皮书啃半天不如亲自写一个最小可运行的区块链代码跑起来那一刻很多概念自然就通了。选择Python而不是其他语言有三个实际考量。第一Python的语法足够直白可以把注意力集中在区块链本身的逻辑上而不是被指针、内存管理这类细节干扰。第二实现区块链核心功能所需要的库Python标准库基本全覆盖比如用于SHA-256哈希的hashlib、用于时间戳的time、用于JSON序列化的json不需要额外装任何第三方依赖。第三Python在数据科学和量化交易领域的使用率极高很多读者本身就有Python基础上手成本最低。这个项目的定位很明确不是生产级区块链而是一个教学用的最小实现。它要能演示区块链最核心的几个特性——哈希链式结构、工作量证明、交易记录、数据不可篡改同时代码量控制在几百行以内让读者可以一行一行读懂。我还会在最后讨论这个教学项目的边界在哪里以及如果想往真正的区块链系统靠拢还需要补上哪些模块。适合看这篇文章的人我认为有两类。一类是刚入门的Python开发者想找一个有深度但又不至于劝退的实战项目练手另一类是区块链技术爱好者想通过代码理解区块、挖矿、交易和链式结构这些抽象概念到底是怎么落地的。2. 区块数据结构与哈希链的关系这是区块链的根基2.1 一个区块里到底装了什么区块链这个名字拆开看就是“区块”加“链”。区块是数据容器链把这些容器按顺序连接起来。那一个区块里到底装什么我先从最小必要集开始设计。一个区块至少需要包含以下信息索引index这个区块在链上的位置从0开始计数。时间戳timestamp区块创建的时间。交易记录transactions这个区块打包的数据在加密货币场景里就是转账记录在通用场景里可以是任意业务数据。工作量证明proof挖矿时找到的符合难度的随机数这是共识机制的核心。前一个区块的哈希previous_hash这是链的核心通过这个字段把区块串联起来。除了这些还有一个非常重要的字段当前区块自身的哈希。这个哈希不是直接存储在区块里的而是通过把区块的所有内容做SHA-256计算得出来的。存储时会把它作为独立字段带上方便后续验证。用Python定义一个区块类最直观的方式是这样的import hashlib import json import time class Block: def __init__(self, index, transactions, proof, previous_hash, timestampNone): self.index index self.timestamp timestamp or time.time() self.transactions transactions self.proof proof self.previous_hash previous_hash def compute_hash(self): 计算当前区块的哈希值。 这里使用一个字典保存区块内容然后序列化为JSON字符串再做SHA-256。 block_string json.dumps({ index: self.index, timestamp: self.timestamp, transactions: self.transactions, proof: self.proof, previous_hash: self.previous_hash }, sort_keysTrue).encode() return hashlib.sha256(block_string).hexdigest()这里有个细节值得展开讲。json.dumps时我传了sort_keysTrue为什么因为json.dumps对字典键的默认行为是保持插入顺序而Python字典的插入顺序取决于当时代码的执行顺序。如果不排序同一个区块内容在不同的Python版本或不同会话里可能产生不同的JSON字符串哈希结果自然也不同。加上sort_keysTrue可以保证键按字母序排列确保哈希计算的确定性。2.2 为什么“前一个区块哈希”如此重要区块链不可篡改的特性核心就靠previous_hash这个字段。我来拆解一下。假设链上有三个区块A、B、C。B的previous_hash存的是A的哈希C的previous_hash存的是B的哈希。如果攻击者修改了A中的任何内容——哪怕只是把一笔交易的金额从100改成101A的哈希就会发生变化。因为B存储了A的哈希所以B会立刻检测到异常因为C存储了B的哈希所以C也会异常。这个链上的任何修改都会像多米诺骨牌一样传递下去最终导致整个链的哈希验证失败。用一个生活化的类比来理解这就像在一本账本里每一页除了记录当天的账单还要记录上一页内容的指纹。只要有人篡改了前面任何一页后面所有页的指纹都会对不上一眼就能看出账本被动过手脚。在代码层面可以用一个is_chain_valid方法来验证整条链的完整性def is_chain_valid(chain): 验证区块链是否有效 1. 每个区块的previous_hash是否等于前一个区块的哈希。 2. 每个区块的proof是否满足工作量证明条件。 for i in range(1, len(chain)): current_block chain[i] previous_block chain[i - 1] # 检查哈希链是否断裂 if current_block.previous_hash ! previous_block.compute_hash(): return False # 检查工作量证明是否有效 if not is_valid_proof(previous_block.proof, current_block.proof): return False return True2.3 创世区块的特殊性链上的第一个区块叫创世区块Genesis Block。它很特殊因为它没有previous_hash。业界惯例是把previous_hash设为一串零或者任意一个固定字符串。创世区块通常由系统硬编码生成而不是通过挖矿产生。我习惯这样创建创世区块def create_genesis_block(): return Block(0, [], 100, 0)索引为0交易为空previous_hash为字符串0。注意这里的proof我设置成了100这个具体值没有特殊含义只是作为初始工作量证明的起点。后面解释工作量证明时你会看到这个值是如何参与运算的。3. 工作量证明区块链是如何实现“共识”的3.1 什么是工作量证明它解决了什么问题在去中心化网络里任何一个节点都可以往链上添加区块。如果没有约束机制恶意节点可以往链上塞大量垃圾区块或者通过伪造历史区块来实施双花攻击。工作量证明Proof of WorkPoW就是解决这个问题的让添加区块的过程变得“有成本”而且是实打实的计算成本。工作量证明的具体要求是找到一个数nonce使得“前一个区块的proof加上当前区块的proof”这个组合的哈希值满足特定条件。在比特币里这个条件是哈希值以若干个0开头。0的个数越多难度越高找到合格nonce所需的计算量就越大。我在教学项目里用了一种简化的PoW规则找到一个数p使得hashlib.sha256(f{last_proof}{p}.encode()).hexdigest()以0000开头。这个规则足够简单能演示PoW的精髓又能保证单机演示时挖矿时间在可接受范围内。如果要把难度调高只需把前缀从0000改成00000或更长。3.2 挖矿代码实现与性能调优挖矿的逻辑是暴力枚举数字逐个尝试直到找到符合条件的那个。代码实现如下def proof_of_work(last_proof): 简单的工作量证明 不断尝试 proof 值直到哈希以 0000 开头。 proof 0 while not is_valid_proof(last_proof, proof): proof 1 return proof def is_valid_proof(last_proof, proof): guess f{last_proof}{proof}.encode() guess_hash hashlib.sha256(guess).hexdigest() return guess_hash[:4] 0000这段代码的运行逻辑非常直观从0开始把last_proof和proof拼接成字符串计算哈希检查前四位是否为0000。如果是返回当前proof如果不是proof加1继续尝试。这里有一个性能方面的细节。f{last_proof}{proof}这种字符串拼接方式在循环内部频繁执行。每轮循环都要生成新的字符串、计算哈希、比较字符串前缀CPU开销不小。当我第一次跑这个挖矿函数时发现要试几万次才能撞到一个合格的proof虽然教学演示够用但如果把难度提高到00000单次挖矿可能要等十几秒以上。如果想让挖矿速度更快可以引入multiprocessing做并行搜索把搜索空间切分成多个区间每个进程负责一段。不过我不建议在教学项目里引入多进程原因后面在讲“这个项目的边界”时再细说。先做一个基准测试看看不同难度下的平均挖矿耗时。我在我的机器上跑了下面这个测试脚本import time import hashlib def is_valid_proof(last_proof, proof, leading_zeros4): guess f{last_proof}{proof}.encode() guess_hash hashlib.sha256(guess).hexdigest() return guess_hash[:leading_zeros] 0 * leading_zeros def proof_of_work(last_proof, leading_zeros4): proof 0 while not is_valid_proof(last_proof, proof, leading_zeros): proof 1 return proof for zeros in [3, 4, 5, 6]: start time.time() proof proof_of_work(100, zeros) elapsed time.time() - start print(f难度: {zeros}个0, 找到proof: {proof}, 耗时: {elapsed:.3f}秒)结果大致如下难度前导0个数平均尝试次数单次耗时3约16次毫秒级4约256次毫秒级5约4096次约0.5秒6约65536次约6-8秒可以看出难度每增加1期望尝试次数呈指数级上升。这就是工作量证明的“工作量”所在——找到符合条件的nonce需要大量计算但验证时只需要算一次哈希验证成本极低。这种“找起来难、验证容易”的非对称特性正是PoW共识的核心优势。实测下来教学项目用0000这个难度最合适既能体现挖矿的计算成本又不会让读者等得失去耐心。3.3 为什么交易记录在区块里是不可分割的整体在实际区块中一个区块会打包多笔交易。这些交易共同参与哈希运算任何一笔交易被修改都会导致整个区块的哈希发生变化。这就是前面说的“篡改检测”的粒度问题——不是检测单笔交易而是检测整个批次。我在设计数据结构时把transactions定义为列表。每笔交易是一个字典包含sender、recipient和amount三个字段。这样一个区块可以打包多笔交易链上就形成了完整的交易流水。def new_transaction(sender, recipient, amount): 创建一笔新交易返回这笔交易将被添加到的下一个区块的索引。 transaction { sender: sender, recipient: recipient, amount: amount } return transaction在教育场景里我还见过有人用字符串列表来代替结构化交易比如把交易写成Alice sends 10 BTC to Bob。这样做的好处是代码更简洁但坏处是丢失了结构化信息后续做余额计算、交易验证会增加不必要的解析成本。我用字典而不是字符串是想让读者一开始就养成数据格式化的习惯——真实区块链里的交易有严格的结构化格式比如比特币的UTXO模型。4. 从单机记账到“链”的完整实现4.1 区块链核心类的设计与职责划分有了区块和PoW函数接下来要做的就是把它们组织起来形成一个可以持续增长的链。我用一个Blockchain类来封装所有核心操作这样不仅逻辑清晰也方便后期扩展。class Blockchain: def __init__(self): self.chain [] self.pending_transactions [] self.create_genesis_block() def create_genesis_block(self): genesis_block Block(0, [], 100, 0) self.chain.append(genesis_block) property def last_block(self): return self.chain[-1] def add_block(self, proof): 当工作量证明找到后把新区块正式加入链中。 previous_hash self.last_block.compute_hash() block Block( indexlen(self.chain), transactionsself.pending_transactions, proofproof, previous_hashprevious_hash ) self.pending_transactions [] self.chain.append(block) def mine_block(self): 挖矿找出符合难度要求的proof然后创建新区块并加入链。 last_proof self.last_block.proof proof proof_of_work(last_proof) self.add_block(proof) return self.last_block这个类我做了职责分离chain负责保存所有区块形成链式结构。pending_transactions是“待打包交易池”。新交易进来先进入这个池子等挖矿成功后才被写入新区块池子清空。create_genesis_block负责创建创世区块。mine_block负责执行PoW并创建新区块。为什么要设置pending_transactions这个缓冲池因为在真实区块链里交易不是立即被打包进区块的而是先在内存池Mempool里排队等待矿工挑选并打包。这个机制在单机演示里也许显得多余但它反映了真实系统的行为模式有必要保留。4.2 完整跑通一次“记账到挖矿再到入链”的流程在单机环境下一次完整的记账流程是这样的# 初始化区块链 blockchain Blockchain() # 创建两笔待打包交易 blockchain.pending_transactions.append( blockchain.new_transaction(Alice, Bob, 10) ) blockchain.pending_transactions.append( blockchain.new_transaction(Bob, Charlie, 5) ) # 挖矿把待打包交易写入新区块 new_block blockchain.mine_block() # 输出区块信息 print(f新区块索引: {new_block.index}) print(f新区块哈希: {new_block.compute_hash()}) print(f前一个区块哈希: {new_block.previous_hash}) print(f包含交易: {new_block.transactions})跑一次输出大致是这样新区块索引: 1 新区块哈希: 0000b5a2a7e8d4e0f1e2d3c4b5a6... 前一个区块哈希: 6a4e0f1e2d3c4b5a6... 包含交易: [{sender: Alice, recipient: Bob, amount: 10}, {sender: Bob, recipient: Charlie, amount: 5}]之后继续挖第二个区块blockchain.pending_transactions.append( blockchain.new_transaction(Charlie, Alice, 2) ) second_block blockchain.mine_block() print(f新区块索引: {second_block.index}) print(f新区块哈希: {second_block.compute_hash()})继续挖第二个区块时previous_hash指向前一个区块索引为1的哈希链就靠这个字段一节一节串起来了。4.3 篡改检测实验修改历史区块会怎样这是整个教学项目里我觉得最有意思的演示环节——手动篡改一个历史区块然后用is_chain_valid验证链是否被破坏。# 篡改第一个区块中的第一笔交易金额 blockchain.chain[1].transactions[0][amount] 10000 # 验证链是否仍然有效 print(f链是否有效: {is_chain_valid(blockchain.chain)})输出结果必然是False。原因前面已经拆解过了区块内容变了哈希随之改变而后面区块中存储的previous_hash仍然是“篡改前”的哈希两者对不上验证自然失败。如果要修复被篡改的链理论上需要把被篡改区块之后的所有区块全部重新计算哈希并重做工作量证明。这在单机演示中也能做到但一旦链上节点众多攻击者要同时重算所有后续区块的工作量证明计算成本会呈指数级上升。这正是PoW防篡改的根本逻辑不是不能改而是改了之后要付出的代价远超收益。4.4 为什么区块哈希必须以“0000”开头才算合法我在is_chain_valid里加的检查是if not is_valid_proof(previous_block.proof, current_block.proof): return False也就是不仅检查哈希链的连续性还要检查每个区块的proof是否满足PoW条件。这么做的意义在于防止攻击者伪造一整条链。想象一下攻击者想偷偷替换整条链让所有区块的哈希都重新计算好并且让previous_hash都指向正确的前驱区块。如果验证逻辑只检查哈希链连续而不检查PoW那么攻击者可以伪造一条完全合法哈希链的假链。但是攻击者在伪造过程中必须为每个区块找到一个满足0000前缀条件的proof这个计算成本是实打实的。在真实网络中攻击者要追赶上其他矿工持续产出的新区块需要的算力必须超过全网总算力的一半以上这就是“51%攻击”的概念。我的教学项目虽然单机运行但这个检查逻辑必须保留否则就违背了PoW机制的初衷。5. 数据持久化区块链不是存在内存里的玩具5.1 为什么需要持久化以及我为什么用JSON文件而非数据库我把区块链跑通之后遇到的第一个实际问题是每次关闭程序链上的数据就全没了。这显然不行。真实的区块链系统每个节点都需要把全量数据持久化到磁盘否则节点重启后无法与其他节点同步。在持久化方案选择上我考虑过三个方向SQLite数据库结构清晰便于查询但引入了SQL语法学习成本。LevelDB/RocksDB高性能KV存储这是很多真实区块链项目如以太坊的选择但对入门者来说过于底层。JSON文件实现最简单只需一个json.dump和json.load零依赖数据可读性好。对于教学项目我选了JSON文件。原因很简单它的逻辑足够透明读者可以打开文件直接看数据理解“程序重启后数据还在”的原理。但我也要在这里明确一点JSON文件方案只适合教学和原型验证。真实区块链的区块数据一般用专门的KV数据库存储因为区块链要支持高效的哈希查询、状态回滚、UTXO索引等操作JSON文件在这方面的性能完全不够。5.2 序列化与反序列化的完整实现要让区块链支持JSON持久化核心代码是序列化把区块对象变成字典和反序列化把字典变回区块对象。def block_to_dict(block): return { index: block.index, timestamp: block.timestamp, transactions: block.transactions, proof: block.proof, previous_hash: block.previous_hash, hash: block.compute_hash() } def save_chain(blockchain, filenameblockchain.json): chain_data [block_to_dict(block) for block in blockchain.chain] with open(filename, w) as f: json.dump(chain_data, f, indent4) def load_chain(filenameblockchain.json): with open(filename, r) as f: chain_data json.load(f) chain [] for block_data in chain_data: block Block( indexblock_data[index], transactionsblock_data[transactions], proofblock_data[proof], previous_hashblock_data[previous_hash], timestampblock_data[timestamp] ) chain.append(block) return chain这里有个重构时遇到的小坑值得分享给大家。起初我在Block类的__init__里没有timestamp参数时间戳在__init__内部用time.time()直接生成。但反序列化时我要恢复的是历史区块的原始时间戳而不是用当前时间重新生成。所以必须在__init__里加上timestampNone这个参数允许外部传入时间戳值。这个改动很小但它体现了序列化设计的核心原则一个对象被序列化后所有状态都必须能够从序列化数据中完整恢复不能依赖运行时环境重新生成。5.3 区块哈希要不要存到文件里我在block_to_dict里把compute_hash()的结果也存进了文件。有人可能会问区块哈希本来就是根据内容算出来的验证时重新算一遍不就行了为什么还要单独存一份这不是必须的但存了有一个好处方便快速查看区块的哈希值而不需要每次都用代码计算。比如直接在终端里cat blockchain.json就能看到每个区块的哈希和整个链的哈希对应关系。但这里要特别强调一个安全细节反序列化时绝不能直接信任文件里的hash字段必须重新计算区块哈希并与存储值比对。如果文件被外部篡改同时把存储的hash字段也改了那么这种篡改是无法被“存储哈希比对”检测到的。真正的检测手段是验证previous_hash的链式关系和PoW条件。所以在我设计的load_chain里干脆没有加载文件中的hash字段而是用compute_hash()动态计算。6. 通信模块与网络层从单机走向“去中心化”的关键一步6.1 为什么单机区块链不是真正的区块链严格来说单机运行的区块链只是“区块链数据结构的本地演示”不是真正的区块链。区块链的灵魂在于去中心化——多个节点各自维护一份账本副本通过共识协议保持数据一致任何一个节点宕机或作恶都不会导致整个网络崩溃。要往这个方向迈一步最直接的做法是加上HTTP接口让外部程序或节点能够与区块链交互。我没有选择用WebSocket或gRPC是因为HTTP足够简单通用而且Python标准库中的http.server就能实现基础服务无需安装Flask等第三方框架。6.2 用Python标准库搭建HTTP接口虽然用标准库写HTTP服务比Flask多几行代码但有一个好处读者可以零依赖地运行整个项目。我用http.server写了一个简单的接口服务提供两个接口GET /chain返回当前整条链的数据。POST /transactions向待打包交易池添加一笔新交易。from http.server import BaseHTTPRequestHandler, HTTPServer import json class BlockchainHTTPHandler(BaseHTTPRequestHandler): blockchain None def do_GET(self): if self.path /chain: chain_data [block_to_dict(block) for block in self.blockchain.chain] self.send_response(200) self.send_header(Content-Type, application/json) self.end_headers() self.wfile.write(json.dumps(chain_data, indent4).encode()) else: self.send_response(404) self.end_headers() def do_POST(self): if self.path /transactions: content_length int(self.headers[Content-Length]) post_data json.loads(self.rfile.read(content_length)) transaction self.blockchain.new_transaction( post_data[sender], post_data[recipient], post_data[amount] ) self.blockchain.pending_transactions.append(transaction) self.send_response(201) self.end_headers() self.wfile.write(json.dumps({message: 交易已加入待打包池}).encode()) else: self.send_response(404) self.end_headers() def start_server(blockchain, port5000): handler BlockchainHTTPHandler handler.blockchain blockchain server HTTPServer((127.0.0.1, port), handler) print(f区块链服务已启动监听端口: {port}) server.serve_forever()启动服务后用curl或者Postman向http://127.0.0.1:5000/transactions发送POST请求就能添加交易curl -X POST http://127.0.0.1:5000/transactions \ -H Content-Type: application/json \ -d {sender: Alice, recipient: Bob, amount: 10}再访问http://127.0.0.1:5000/chain就能看到当前区块链的全部数据。这套HTTP接口设计虽然简陋但它清晰地展示了区块链与外部世界交互的基本模式节点对外提供API客户端通过网络提交交易和查询数据节点之间也能通过这些API同步链数据。6.3 多节点共识一个真实但复杂的工程问题如果继续沿着网络层往下走会遇到一个非常复杂的工程问题当网络中有多个节点彼此维护的链版本不一致时如何决定谁才是“正确的链”比特币的答案是“最长链原则”始终采纳累计工作量证明难度最大、链最长的那个版本。节点会定期广播自己的链收到更长更难的链时会丢弃自己的链并同步对方的链。这个机制保证即使网络短暂分叉最终也会收敛到同一条链上。我在教学项目里没有实现完整的多节点共识原因有两个。第一多节点共识涉及到网络分区、节点故障、恶意行为等一系列复杂场景任何一个都要花大量篇幅才能讲清楚与“简单区块链”的项目定位不符。第二单机演示已经足够演示区块链的核心逻辑多节点共识可以作为下一个深入学习的主题。7. 实际运行效果与完整代码整合7.1 项目文件结构与代码组织为了让读者能直接跑起来我把所有代码整合进一个项目目录blockchain_demo/ ├── blockchain.py # 核心类Block、Blockchain、PoW ├── server.py # HTTP接口服务 ├── main.py # 单机演示入口 └── blockchain.json # 持久化文件首次运行后生成blockchain.py包含区块定义、区块链定义、工作量证明、链验证、序列化与反序列化。server.py包含HTTP服务。main.py整合所有功能启动时自动加载已持久化的链数据然后提供交互式命令行界面。main.py的核心逻辑import os from blockchain import Blockchain, save_chain, load_chain, is_chain_valid FILENAME blockchain.json def main(): if os.path.exists(FILENAME): chain load_chain(FILENAME) print(已从文件加载区块链数据。) print(f链是否有效: {is_chain_valid(chain)}) else: chain Blockchain() print(已创建新的创世区块。) while True: print(\n请选择操作:) print(1. 添加交易) print(2. 挖矿打包交易) print(3. 查看整条链) print(4. 验证链有效性) print(5. 篡改演示) print(6. 保存并退出) choice input(请输入数字: ) if choice 1: sender input(发送方: ) recipient input(接收方: ) amount float(input(金额: )) chain.pending_transactions.append( chain.new_transaction(sender, recipient, amount) ) print(交易已加入待打包池。) elif choice 2: block chain.mine_block() print(f挖矿成功新区块索引: {block.index}) print(f新区块哈希: {block.compute_hash()}) elif choice 3: for block in chain.chain: print(f索引: {block.index}, 哈希: {block.compute_hash()}, f交易数: {len(block.transactions)}, PoW: {block.proof}) elif choice 4: print(f链是否有效: {is_chain_valid(chain.chain)}) elif choice 5: if len(chain.chain) 1: chain.chain[1].transactions[0][amount] 99999 print(已篡改第二个区块的第一笔交易金额为99999。) else: print(需要先挖至少一个区块。) elif choice 6: save_chain(chain, FILENAME) print(已保存区块链数据到文件。) break else: print(无效输入请重新选择。) if __name__ __main__: main()7.2 完整运行Demo实录我在终端里实际跑了一次把关键输出贴出来供参考。初始化运行已创建新的创世区块。 请选择操作: 1. 添加交易 ... 请输入数字: 1 发送方: Alice 接收方: Bob 金额: 10 交易已加入待打包池。 请输入数字: 1 发送方: Bob 接收方: Charlie 金额: 5 交易已加入待打包池。 请输入数字: 2 挖矿成功新区块索引: 1 新区块哈希: 0000c6a2b8d9f4e1a0d5...继续添加交易、挖出第二个区块后查看整条链索引: 0, 哈希: 4c1a6c8e2f9d0b3a7e5f..., 交易数: 0, PoW: 100 索引: 1, 哈希: 0000c6a2b8d9f4e1a0d5..., 交易数: 2, PoW: 29564 索引: 2, 哈希: 0000d8e4b2a9c1f3a7d6..., 交易数: 1, PoW: 18732这个时候做篡改演示把第二个区块的交易金额改成99999再验证链请输入数字: 5 已篡改第二个区块的第一笔交易金额为99999。 请输入数字: 4 链是否有效: False链确实失效了。这个演示直观地传递了一个信息区块链的安全性不是靠“没人篡改”来保证的而是靠“篡改之后立刻能被识别”来保证的。7.3 运行中可能遇到的问题与避坑指南在我自己调试和让朋友试跑的过程中遇到了一些问题我整理出来供大家参考。问题原因解决办法挖矿速度极慢难度太高或last_proof值过大保持0000难度last_proof值过大时可重置创世区块JSON文件加载报错文件损坏或格式不对检查JSON格式或删除blockchain.json重新初始化区块哈希与上一个区块哈希对不上反序列化后区块内容与原始内容不一致检查区块类的__init__是否完整接收所有字段time.time()作为字段导致每次运行时哈希不同这是正常现象哈希变化是预期行为不影响链的验证逻辑修改历史区块后整条链全部失效预期行为用作篡改检测演示验证后重新运行即可关于挖矿会出现的“哈希变化”有些读者会困惑同一个区块内容为什么每次计算哈希都不一样原因在于时间戳。区块创建时记录了时间戳而这个时间戳精确到毫秒每次运行都会变化。如果希望哈希在同一内容下保持一致可以去除时间戳或者固定时间戳的传入值。但在实际区块链中时间戳是区块的必要组成部分不应该为了结果可复现而牺牲语义。8. 我的实现会让你失望的地方边界与局限说明写到这里我必须坦诚地说清楚这个项目的边界在哪里它和真实区块链系统之间还差哪些东西。搞清楚了这些才算真正理解了这个教学项目的价值。第一没有真正的P2P网络。我的HTTP服务只是提供了一个中心化访问入口所有数据仍集中在一台机器上。真实区块链是分布式的每个节点都维护完整账本副本节点之间通过P2P协议广播新块和新交易。第二没有账户体系和数字签名。我的交易只是简单的sender和recipient字段任何人都可以拼一个假交易塞进去。在比特币和以太坊里交易必须携带发送方的私钥签名接收方和网络节点通过公钥验证签名确认交易合法性。第三PoW参数与真实系统差距巨大。比特币的难度目标是一个以几十个0开头的256位数字我的教学项目只要求4个0。比特币会自动调整难度确保平均出块时间维持在10分钟左右而我的是固定难度。这也意味着我的教学链“防篡改”能力在真实对抗场景下几乎为零——一台普通电脑几秒钟就能重算整条链。第四没有实现UTXO模型或账户余额模型。在真实区块链里一个区块中所有交易的输入输出必须严格遵守“总输入等于总输出”等约束条件否则节点会拒绝接受该区块。我的演示只是记录交易流水并没有验证交易本身的合法性。第五没有实现分叉处理。我的代码假设链永远是单线延伸的不会出现临时分叉——在真实网络中两个矿工几乎同时挖到新区块的情况非常常见节点必须通过共识规则决定采纳哪条分支。这些都是我在开发过程中逐步意识到的差距。其实把一个“看起来能跑”的区块链教学项目升级成一个“真正可用的”区块链工作量会扩大十倍以上。但反过来想正因为我先实现了这个最小版本再去理解UTXO、Merkle树、SPV验证这些概念时有了直观的锚点不会被抽象术语淹没。如果你按照这个思路继续往下学习我的建议是按这样的顺序推进先学会给交易加数字签名再实现节点间的P2P同步最后再去啃UTXO和智能合约。每往前走一步你都会对区块链的理解更深一层。根据我个人实操的经验这个项目最适合的用法是把它当作一个动手实验课而不是一个可部署的软件。跑通代码、篡改区块、观察链失效这几个操作比读十篇区块链原理文章更有价值。等你真的把代码吃透了你会发现自己再去读比特币白皮书时很多概念不再那么晦涩——因为对应的数据结构和流程你已经亲手实现过了。 用Python从零实现教学区块链：核心原理与代码实战
1. 为什么我选择用Python写一个区块链教学项目接触区块链这个概念最早是因为加密货币的热潮。但真正让我想动手写一个区块链是因为我发现周围很多人对它的理解停在了“分布式账本”这种抽象描述上——知道它去中心化、知道它不可篡改但问到底层怎么实现的基本说不清楚。我个人的感受是与其抱着白皮书啃半天不如亲自写一个最小可运行的区块链代码跑起来那一刻很多概念自然就通了。选择Python而不是其他语言有三个实际考量。第一Python的语法足够直白可以把注意力集中在区块链本身的逻辑上而不是被指针、内存管理这类细节干扰。第二实现区块链核心功能所需要的库Python标准库基本全覆盖比如用于SHA-256哈希的hashlib、用于时间戳的time、用于JSON序列化的json不需要额外装任何第三方依赖。第三Python在数据科学和量化交易领域的使用率极高很多读者本身就有Python基础上手成本最低。这个项目的定位很明确不是生产级区块链而是一个教学用的最小实现。它要能演示区块链最核心的几个特性——哈希链式结构、工作量证明、交易记录、数据不可篡改同时代码量控制在几百行以内让读者可以一行一行读懂。我还会在最后讨论这个教学项目的边界在哪里以及如果想往真正的区块链系统靠拢还需要补上哪些模块。适合看这篇文章的人我认为有两类。一类是刚入门的Python开发者想找一个有深度但又不至于劝退的实战项目练手另一类是区块链技术爱好者想通过代码理解区块、挖矿、交易和链式结构这些抽象概念到底是怎么落地的。2. 区块数据结构与哈希链的关系这是区块链的根基2.1 一个区块里到底装了什么区块链这个名字拆开看就是“区块”加“链”。区块是数据容器链把这些容器按顺序连接起来。那一个区块里到底装什么我先从最小必要集开始设计。一个区块至少需要包含以下信息索引index这个区块在链上的位置从0开始计数。时间戳timestamp区块创建的时间。交易记录transactions这个区块打包的数据在加密货币场景里就是转账记录在通用场景里可以是任意业务数据。工作量证明proof挖矿时找到的符合难度的随机数这是共识机制的核心。前一个区块的哈希previous_hash这是链的核心通过这个字段把区块串联起来。除了这些还有一个非常重要的字段当前区块自身的哈希。这个哈希不是直接存储在区块里的而是通过把区块的所有内容做SHA-256计算得出来的。存储时会把它作为独立字段带上方便后续验证。用Python定义一个区块类最直观的方式是这样的import hashlib import json import time class Block: def __init__(self, index, transactions, proof, previous_hash, timestampNone): self.index index self.timestamp timestamp or time.time() self.transactions transactions self.proof proof self.previous_hash previous_hash def compute_hash(self): 计算当前区块的哈希值。 这里使用一个字典保存区块内容然后序列化为JSON字符串再做SHA-256。 block_string json.dumps({ index: self.index, timestamp: self.timestamp, transactions: self.transactions, proof: self.proof, previous_hash: self.previous_hash }, sort_keysTrue).encode() return hashlib.sha256(block_string).hexdigest()这里有个细节值得展开讲。json.dumps时我传了sort_keysTrue为什么因为json.dumps对字典键的默认行为是保持插入顺序而Python字典的插入顺序取决于当时代码的执行顺序。如果不排序同一个区块内容在不同的Python版本或不同会话里可能产生不同的JSON字符串哈希结果自然也不同。加上sort_keysTrue可以保证键按字母序排列确保哈希计算的确定性。2.2 为什么“前一个区块哈希”如此重要区块链不可篡改的特性核心就靠previous_hash这个字段。我来拆解一下。假设链上有三个区块A、B、C。B的previous_hash存的是A的哈希C的previous_hash存的是B的哈希。如果攻击者修改了A中的任何内容——哪怕只是把一笔交易的金额从100改成101A的哈希就会发生变化。因为B存储了A的哈希所以B会立刻检测到异常因为C存储了B的哈希所以C也会异常。这个链上的任何修改都会像多米诺骨牌一样传递下去最终导致整个链的哈希验证失败。用一个生活化的类比来理解这就像在一本账本里每一页除了记录当天的账单还要记录上一页内容的指纹。只要有人篡改了前面任何一页后面所有页的指纹都会对不上一眼就能看出账本被动过手脚。在代码层面可以用一个is_chain_valid方法来验证整条链的完整性def is_chain_valid(chain): 验证区块链是否有效 1. 每个区块的previous_hash是否等于前一个区块的哈希。 2. 每个区块的proof是否满足工作量证明条件。 for i in range(1, len(chain)): current_block chain[i] previous_block chain[i - 1] # 检查哈希链是否断裂 if current_block.previous_hash ! previous_block.compute_hash(): return False # 检查工作量证明是否有效 if not is_valid_proof(previous_block.proof, current_block.proof): return False return True2.3 创世区块的特殊性链上的第一个区块叫创世区块Genesis Block。它很特殊因为它没有previous_hash。业界惯例是把previous_hash设为一串零或者任意一个固定字符串。创世区块通常由系统硬编码生成而不是通过挖矿产生。我习惯这样创建创世区块def create_genesis_block(): return Block(0, [], 100, 0)索引为0交易为空previous_hash为字符串0。注意这里的proof我设置成了100这个具体值没有特殊含义只是作为初始工作量证明的起点。后面解释工作量证明时你会看到这个值是如何参与运算的。3. 工作量证明区块链是如何实现“共识”的3.1 什么是工作量证明它解决了什么问题在去中心化网络里任何一个节点都可以往链上添加区块。如果没有约束机制恶意节点可以往链上塞大量垃圾区块或者通过伪造历史区块来实施双花攻击。工作量证明Proof of WorkPoW就是解决这个问题的让添加区块的过程变得“有成本”而且是实打实的计算成本。工作量证明的具体要求是找到一个数nonce使得“前一个区块的proof加上当前区块的proof”这个组合的哈希值满足特定条件。在比特币里这个条件是哈希值以若干个0开头。0的个数越多难度越高找到合格nonce所需的计算量就越大。我在教学项目里用了一种简化的PoW规则找到一个数p使得hashlib.sha256(f{last_proof}{p}.encode()).hexdigest()以0000开头。这个规则足够简单能演示PoW的精髓又能保证单机演示时挖矿时间在可接受范围内。如果要把难度调高只需把前缀从0000改成00000或更长。3.2 挖矿代码实现与性能调优挖矿的逻辑是暴力枚举数字逐个尝试直到找到符合条件的那个。代码实现如下def proof_of_work(last_proof): 简单的工作量证明 不断尝试 proof 值直到哈希以 0000 开头。 proof 0 while not is_valid_proof(last_proof, proof): proof 1 return proof def is_valid_proof(last_proof, proof): guess f{last_proof}{proof}.encode() guess_hash hashlib.sha256(guess).hexdigest() return guess_hash[:4] 0000这段代码的运行逻辑非常直观从0开始把last_proof和proof拼接成字符串计算哈希检查前四位是否为0000。如果是返回当前proof如果不是proof加1继续尝试。这里有一个性能方面的细节。f{last_proof}{proof}这种字符串拼接方式在循环内部频繁执行。每轮循环都要生成新的字符串、计算哈希、比较字符串前缀CPU开销不小。当我第一次跑这个挖矿函数时发现要试几万次才能撞到一个合格的proof虽然教学演示够用但如果把难度提高到00000单次挖矿可能要等十几秒以上。如果想让挖矿速度更快可以引入multiprocessing做并行搜索把搜索空间切分成多个区间每个进程负责一段。不过我不建议在教学项目里引入多进程原因后面在讲“这个项目的边界”时再细说。先做一个基准测试看看不同难度下的平均挖矿耗时。我在我的机器上跑了下面这个测试脚本import time import hashlib def is_valid_proof(last_proof, proof, leading_zeros4): guess f{last_proof}{proof}.encode() guess_hash hashlib.sha256(guess).hexdigest() return guess_hash[:leading_zeros] 0 * leading_zeros def proof_of_work(last_proof, leading_zeros4): proof 0 while not is_valid_proof(last_proof, proof, leading_zeros): proof 1 return proof for zeros in [3, 4, 5, 6]: start time.time() proof proof_of_work(100, zeros) elapsed time.time() - start print(f难度: {zeros}个0, 找到proof: {proof}, 耗时: {elapsed:.3f}秒)结果大致如下难度前导0个数平均尝试次数单次耗时3约16次毫秒级4约256次毫秒级5约4096次约0.5秒6约65536次约6-8秒可以看出难度每增加1期望尝试次数呈指数级上升。这就是工作量证明的“工作量”所在——找到符合条件的nonce需要大量计算但验证时只需要算一次哈希验证成本极低。这种“找起来难、验证容易”的非对称特性正是PoW共识的核心优势。实测下来教学项目用0000这个难度最合适既能体现挖矿的计算成本又不会让读者等得失去耐心。3.3 为什么交易记录在区块里是不可分割的整体在实际区块中一个区块会打包多笔交易。这些交易共同参与哈希运算任何一笔交易被修改都会导致整个区块的哈希发生变化。这就是前面说的“篡改检测”的粒度问题——不是检测单笔交易而是检测整个批次。我在设计数据结构时把transactions定义为列表。每笔交易是一个字典包含sender、recipient和amount三个字段。这样一个区块可以打包多笔交易链上就形成了完整的交易流水。def new_transaction(sender, recipient, amount): 创建一笔新交易返回这笔交易将被添加到的下一个区块的索引。 transaction { sender: sender, recipient: recipient, amount: amount } return transaction在教育场景里我还见过有人用字符串列表来代替结构化交易比如把交易写成Alice sends 10 BTC to Bob。这样做的好处是代码更简洁但坏处是丢失了结构化信息后续做余额计算、交易验证会增加不必要的解析成本。我用字典而不是字符串是想让读者一开始就养成数据格式化的习惯——真实区块链里的交易有严格的结构化格式比如比特币的UTXO模型。4. 从单机记账到“链”的完整实现4.1 区块链核心类的设计与职责划分有了区块和PoW函数接下来要做的就是把它们组织起来形成一个可以持续增长的链。我用一个Blockchain类来封装所有核心操作这样不仅逻辑清晰也方便后期扩展。class Blockchain: def __init__(self): self.chain [] self.pending_transactions [] self.create_genesis_block() def create_genesis_block(self): genesis_block Block(0, [], 100, 0) self.chain.append(genesis_block) property def last_block(self): return self.chain[-1] def add_block(self, proof): 当工作量证明找到后把新区块正式加入链中。 previous_hash self.last_block.compute_hash() block Block( indexlen(self.chain), transactionsself.pending_transactions, proofproof, previous_hashprevious_hash ) self.pending_transactions [] self.chain.append(block) def mine_block(self): 挖矿找出符合难度要求的proof然后创建新区块并加入链。 last_proof self.last_block.proof proof proof_of_work(last_proof) self.add_block(proof) return self.last_block这个类我做了职责分离chain负责保存所有区块形成链式结构。pending_transactions是“待打包交易池”。新交易进来先进入这个池子等挖矿成功后才被写入新区块池子清空。create_genesis_block负责创建创世区块。mine_block负责执行PoW并创建新区块。为什么要设置pending_transactions这个缓冲池因为在真实区块链里交易不是立即被打包进区块的而是先在内存池Mempool里排队等待矿工挑选并打包。这个机制在单机演示里也许显得多余但它反映了真实系统的行为模式有必要保留。4.2 完整跑通一次“记账到挖矿再到入链”的流程在单机环境下一次完整的记账流程是这样的# 初始化区块链 blockchain Blockchain() # 创建两笔待打包交易 blockchain.pending_transactions.append( blockchain.new_transaction(Alice, Bob, 10) ) blockchain.pending_transactions.append( blockchain.new_transaction(Bob, Charlie, 5) ) # 挖矿把待打包交易写入新区块 new_block blockchain.mine_block() # 输出区块信息 print(f新区块索引: {new_block.index}) print(f新区块哈希: {new_block.compute_hash()}) print(f前一个区块哈希: {new_block.previous_hash}) print(f包含交易: {new_block.transactions})跑一次输出大致是这样新区块索引: 1 新区块哈希: 0000b5a2a7e8d4e0f1e2d3c4b5a6... 前一个区块哈希: 6a4e0f1e2d3c4b5a6... 包含交易: [{sender: Alice, recipient: Bob, amount: 10}, {sender: Bob, recipient: Charlie, amount: 5}]之后继续挖第二个区块blockchain.pending_transactions.append( blockchain.new_transaction(Charlie, Alice, 2) ) second_block blockchain.mine_block() print(f新区块索引: {second_block.index}) print(f新区块哈希: {second_block.compute_hash()})继续挖第二个区块时previous_hash指向前一个区块索引为1的哈希链就靠这个字段一节一节串起来了。4.3 篡改检测实验修改历史区块会怎样这是整个教学项目里我觉得最有意思的演示环节——手动篡改一个历史区块然后用is_chain_valid验证链是否被破坏。# 篡改第一个区块中的第一笔交易金额 blockchain.chain[1].transactions[0][amount] 10000 # 验证链是否仍然有效 print(f链是否有效: {is_chain_valid(blockchain.chain)})输出结果必然是False。原因前面已经拆解过了区块内容变了哈希随之改变而后面区块中存储的previous_hash仍然是“篡改前”的哈希两者对不上验证自然失败。如果要修复被篡改的链理论上需要把被篡改区块之后的所有区块全部重新计算哈希并重做工作量证明。这在单机演示中也能做到但一旦链上节点众多攻击者要同时重算所有后续区块的工作量证明计算成本会呈指数级上升。这正是PoW防篡改的根本逻辑不是不能改而是改了之后要付出的代价远超收益。4.4 为什么区块哈希必须以“0000”开头才算合法我在is_chain_valid里加的检查是if not is_valid_proof(previous_block.proof, current_block.proof): return False也就是不仅检查哈希链的连续性还要检查每个区块的proof是否满足PoW条件。这么做的意义在于防止攻击者伪造一整条链。想象一下攻击者想偷偷替换整条链让所有区块的哈希都重新计算好并且让previous_hash都指向正确的前驱区块。如果验证逻辑只检查哈希链连续而不检查PoW那么攻击者可以伪造一条完全合法哈希链的假链。但是攻击者在伪造过程中必须为每个区块找到一个满足0000前缀条件的proof这个计算成本是实打实的。在真实网络中攻击者要追赶上其他矿工持续产出的新区块需要的算力必须超过全网总算力的一半以上这就是“51%攻击”的概念。我的教学项目虽然单机运行但这个检查逻辑必须保留否则就违背了PoW机制的初衷。5. 数据持久化区块链不是存在内存里的玩具5.1 为什么需要持久化以及我为什么用JSON文件而非数据库我把区块链跑通之后遇到的第一个实际问题是每次关闭程序链上的数据就全没了。这显然不行。真实的区块链系统每个节点都需要把全量数据持久化到磁盘否则节点重启后无法与其他节点同步。在持久化方案选择上我考虑过三个方向SQLite数据库结构清晰便于查询但引入了SQL语法学习成本。LevelDB/RocksDB高性能KV存储这是很多真实区块链项目如以太坊的选择但对入门者来说过于底层。JSON文件实现最简单只需一个json.dump和json.load零依赖数据可读性好。对于教学项目我选了JSON文件。原因很简单它的逻辑足够透明读者可以打开文件直接看数据理解“程序重启后数据还在”的原理。但我也要在这里明确一点JSON文件方案只适合教学和原型验证。真实区块链的区块数据一般用专门的KV数据库存储因为区块链要支持高效的哈希查询、状态回滚、UTXO索引等操作JSON文件在这方面的性能完全不够。5.2 序列化与反序列化的完整实现要让区块链支持JSON持久化核心代码是序列化把区块对象变成字典和反序列化把字典变回区块对象。def block_to_dict(block): return { index: block.index, timestamp: block.timestamp, transactions: block.transactions, proof: block.proof, previous_hash: block.previous_hash, hash: block.compute_hash() } def save_chain(blockchain, filenameblockchain.json): chain_data [block_to_dict(block) for block in blockchain.chain] with open(filename, w) as f: json.dump(chain_data, f, indent4) def load_chain(filenameblockchain.json): with open(filename, r) as f: chain_data json.load(f) chain [] for block_data in chain_data: block Block( indexblock_data[index], transactionsblock_data[transactions], proofblock_data[proof], previous_hashblock_data[previous_hash], timestampblock_data[timestamp] ) chain.append(block) return chain这里有个重构时遇到的小坑值得分享给大家。起初我在Block类的__init__里没有timestamp参数时间戳在__init__内部用time.time()直接生成。但反序列化时我要恢复的是历史区块的原始时间戳而不是用当前时间重新生成。所以必须在__init__里加上timestampNone这个参数允许外部传入时间戳值。这个改动很小但它体现了序列化设计的核心原则一个对象被序列化后所有状态都必须能够从序列化数据中完整恢复不能依赖运行时环境重新生成。5.3 区块哈希要不要存到文件里我在block_to_dict里把compute_hash()的结果也存进了文件。有人可能会问区块哈希本来就是根据内容算出来的验证时重新算一遍不就行了为什么还要单独存一份这不是必须的但存了有一个好处方便快速查看区块的哈希值而不需要每次都用代码计算。比如直接在终端里cat blockchain.json就能看到每个区块的哈希和整个链的哈希对应关系。但这里要特别强调一个安全细节反序列化时绝不能直接信任文件里的hash字段必须重新计算区块哈希并与存储值比对。如果文件被外部篡改同时把存储的hash字段也改了那么这种篡改是无法被“存储哈希比对”检测到的。真正的检测手段是验证previous_hash的链式关系和PoW条件。所以在我设计的load_chain里干脆没有加载文件中的hash字段而是用compute_hash()动态计算。6. 通信模块与网络层从单机走向“去中心化”的关键一步6.1 为什么单机区块链不是真正的区块链严格来说单机运行的区块链只是“区块链数据结构的本地演示”不是真正的区块链。区块链的灵魂在于去中心化——多个节点各自维护一份账本副本通过共识协议保持数据一致任何一个节点宕机或作恶都不会导致整个网络崩溃。要往这个方向迈一步最直接的做法是加上HTTP接口让外部程序或节点能够与区块链交互。我没有选择用WebSocket或gRPC是因为HTTP足够简单通用而且Python标准库中的http.server就能实现基础服务无需安装Flask等第三方框架。6.2 用Python标准库搭建HTTP接口虽然用标准库写HTTP服务比Flask多几行代码但有一个好处读者可以零依赖地运行整个项目。我用http.server写了一个简单的接口服务提供两个接口GET /chain返回当前整条链的数据。POST /transactions向待打包交易池添加一笔新交易。from http.server import BaseHTTPRequestHandler, HTTPServer import json class BlockchainHTTPHandler(BaseHTTPRequestHandler): blockchain None def do_GET(self): if self.path /chain: chain_data [block_to_dict(block) for block in self.blockchain.chain] self.send_response(200) self.send_header(Content-Type, application/json) self.end_headers() self.wfile.write(json.dumps(chain_data, indent4).encode()) else: self.send_response(404) self.end_headers() def do_POST(self): if self.path /transactions: content_length int(self.headers[Content-Length]) post_data json.loads(self.rfile.read(content_length)) transaction self.blockchain.new_transaction( post_data[sender], post_data[recipient], post_data[amount] ) self.blockchain.pending_transactions.append(transaction) self.send_response(201) self.end_headers() self.wfile.write(json.dumps({message: 交易已加入待打包池}).encode()) else: self.send_response(404) self.end_headers() def start_server(blockchain, port5000): handler BlockchainHTTPHandler handler.blockchain blockchain server HTTPServer((127.0.0.1, port), handler) print(f区块链服务已启动监听端口: {port}) server.serve_forever()启动服务后用curl或者Postman向http://127.0.0.1:5000/transactions发送POST请求就能添加交易curl -X POST http://127.0.0.1:5000/transactions \ -H Content-Type: application/json \ -d {sender: Alice, recipient: Bob, amount: 10}再访问http://127.0.0.1:5000/chain就能看到当前区块链的全部数据。这套HTTP接口设计虽然简陋但它清晰地展示了区块链与外部世界交互的基本模式节点对外提供API客户端通过网络提交交易和查询数据节点之间也能通过这些API同步链数据。6.3 多节点共识一个真实但复杂的工程问题如果继续沿着网络层往下走会遇到一个非常复杂的工程问题当网络中有多个节点彼此维护的链版本不一致时如何决定谁才是“正确的链”比特币的答案是“最长链原则”始终采纳累计工作量证明难度最大、链最长的那个版本。节点会定期广播自己的链收到更长更难的链时会丢弃自己的链并同步对方的链。这个机制保证即使网络短暂分叉最终也会收敛到同一条链上。我在教学项目里没有实现完整的多节点共识原因有两个。第一多节点共识涉及到网络分区、节点故障、恶意行为等一系列复杂场景任何一个都要花大量篇幅才能讲清楚与“简单区块链”的项目定位不符。第二单机演示已经足够演示区块链的核心逻辑多节点共识可以作为下一个深入学习的主题。7. 实际运行效果与完整代码整合7.1 项目文件结构与代码组织为了让读者能直接跑起来我把所有代码整合进一个项目目录blockchain_demo/ ├── blockchain.py # 核心类Block、Blockchain、PoW ├── server.py # HTTP接口服务 ├── main.py # 单机演示入口 └── blockchain.json # 持久化文件首次运行后生成blockchain.py包含区块定义、区块链定义、工作量证明、链验证、序列化与反序列化。server.py包含HTTP服务。main.py整合所有功能启动时自动加载已持久化的链数据然后提供交互式命令行界面。main.py的核心逻辑import os from blockchain import Blockchain, save_chain, load_chain, is_chain_valid FILENAME blockchain.json def main(): if os.path.exists(FILENAME): chain load_chain(FILENAME) print(已从文件加载区块链数据。) print(f链是否有效: {is_chain_valid(chain)}) else: chain Blockchain() print(已创建新的创世区块。) while True: print(\n请选择操作:) print(1. 添加交易) print(2. 挖矿打包交易) print(3. 查看整条链) print(4. 验证链有效性) print(5. 篡改演示) print(6. 保存并退出) choice input(请输入数字: ) if choice 1: sender input(发送方: ) recipient input(接收方: ) amount float(input(金额: )) chain.pending_transactions.append( chain.new_transaction(sender, recipient, amount) ) print(交易已加入待打包池。) elif choice 2: block chain.mine_block() print(f挖矿成功新区块索引: {block.index}) print(f新区块哈希: {block.compute_hash()}) elif choice 3: for block in chain.chain: print(f索引: {block.index}, 哈希: {block.compute_hash()}, f交易数: {len(block.transactions)}, PoW: {block.proof}) elif choice 4: print(f链是否有效: {is_chain_valid(chain.chain)}) elif choice 5: if len(chain.chain) 1: chain.chain[1].transactions[0][amount] 99999 print(已篡改第二个区块的第一笔交易金额为99999。) else: print(需要先挖至少一个区块。) elif choice 6: save_chain(chain, FILENAME) print(已保存区块链数据到文件。) break else: print(无效输入请重新选择。) if __name__ __main__: main()7.2 完整运行Demo实录我在终端里实际跑了一次把关键输出贴出来供参考。初始化运行已创建新的创世区块。 请选择操作: 1. 添加交易 ... 请输入数字: 1 发送方: Alice 接收方: Bob 金额: 10 交易已加入待打包池。 请输入数字: 1 发送方: Bob 接收方: Charlie 金额: 5 交易已加入待打包池。 请输入数字: 2 挖矿成功新区块索引: 1 新区块哈希: 0000c6a2b8d9f4e1a0d5...继续添加交易、挖出第二个区块后查看整条链索引: 0, 哈希: 4c1a6c8e2f9d0b3a7e5f..., 交易数: 0, PoW: 100 索引: 1, 哈希: 0000c6a2b8d9f4e1a0d5..., 交易数: 2, PoW: 29564 索引: 2, 哈希: 0000d8e4b2a9c1f3a7d6..., 交易数: 1, PoW: 18732这个时候做篡改演示把第二个区块的交易金额改成99999再验证链请输入数字: 5 已篡改第二个区块的第一笔交易金额为99999。 请输入数字: 4 链是否有效: False链确实失效了。这个演示直观地传递了一个信息区块链的安全性不是靠“没人篡改”来保证的而是靠“篡改之后立刻能被识别”来保证的。7.3 运行中可能遇到的问题与避坑指南在我自己调试和让朋友试跑的过程中遇到了一些问题我整理出来供大家参考。问题原因解决办法挖矿速度极慢难度太高或last_proof值过大保持0000难度last_proof值过大时可重置创世区块JSON文件加载报错文件损坏或格式不对检查JSON格式或删除blockchain.json重新初始化区块哈希与上一个区块哈希对不上反序列化后区块内容与原始内容不一致检查区块类的__init__是否完整接收所有字段time.time()作为字段导致每次运行时哈希不同这是正常现象哈希变化是预期行为不影响链的验证逻辑修改历史区块后整条链全部失效预期行为用作篡改检测演示验证后重新运行即可关于挖矿会出现的“哈希变化”有些读者会困惑同一个区块内容为什么每次计算哈希都不一样原因在于时间戳。区块创建时记录了时间戳而这个时间戳精确到毫秒每次运行都会变化。如果希望哈希在同一内容下保持一致可以去除时间戳或者固定时间戳的传入值。但在实际区块链中时间戳是区块的必要组成部分不应该为了结果可复现而牺牲语义。8. 我的实现会让你失望的地方边界与局限说明写到这里我必须坦诚地说清楚这个项目的边界在哪里它和真实区块链系统之间还差哪些东西。搞清楚了这些才算真正理解了这个教学项目的价值。第一没有真正的P2P网络。我的HTTP服务只是提供了一个中心化访问入口所有数据仍集中在一台机器上。真实区块链是分布式的每个节点都维护完整账本副本节点之间通过P2P协议广播新块和新交易。第二没有账户体系和数字签名。我的交易只是简单的sender和recipient字段任何人都可以拼一个假交易塞进去。在比特币和以太坊里交易必须携带发送方的私钥签名接收方和网络节点通过公钥验证签名确认交易合法性。第三PoW参数与真实系统差距巨大。比特币的难度目标是一个以几十个0开头的256位数字我的教学项目只要求4个0。比特币会自动调整难度确保平均出块时间维持在10分钟左右而我的是固定难度。这也意味着我的教学链“防篡改”能力在真实对抗场景下几乎为零——一台普通电脑几秒钟就能重算整条链。第四没有实现UTXO模型或账户余额模型。在真实区块链里一个区块中所有交易的输入输出必须严格遵守“总输入等于总输出”等约束条件否则节点会拒绝接受该区块。我的演示只是记录交易流水并没有验证交易本身的合法性。第五没有实现分叉处理。我的代码假设链永远是单线延伸的不会出现临时分叉——在真实网络中两个矿工几乎同时挖到新区块的情况非常常见节点必须通过共识规则决定采纳哪条分支。这些都是我在开发过程中逐步意识到的差距。其实把一个“看起来能跑”的区块链教学项目升级成一个“真正可用的”区块链工作量会扩大十倍以上。但反过来想正因为我先实现了这个最小版本再去理解UTXO、Merkle树、SPV验证这些概念时有了直观的锚点不会被抽象术语淹没。如果你按照这个思路继续往下学习我的建议是按这样的顺序推进先学会给交易加数字签名再实现节点间的P2P同步最后再去啃UTXO和智能合约。每往前走一步你都会对区块链的理解更深一层。根据我个人实操的经验这个项目最适合的用法是把它当作一个动手实验课而不是一个可部署的软件。跑通代码、篡改区块、观察链失效这几个操作比读十篇区块链原理文章更有价值。等你真的把代码吃透了你会发现自己再去读比特币白皮书时很多概念不再那么晦涩——因为对应的数据结构和流程你已经亲手实现过了。