简介本资源是一份面向计算机专业学生与区块链初学者的系统性入门讲义聚焦区块链核心技术原理与工程实现基础。内容覆盖密码学基石SHA-256哈希函数的抗碰撞性、隐藏性与谜题友好性、数字签名机制非对称加密在身份认证中的应用、核心数据结构哈希指针链表与Merkle树的构造逻辑及验证原理以及区块链协议关键问题如双花攻击成因与去中心化解决方案。全文以北京大学肖臻老师《区块链技术与应用》公开课第一节至第四节讲义为蓝本结构清晰、推导严谨含大量图示化说明与典型场景分析。资源为单文件Word文档.doc共1个文件大小134KB轻量易读适合作为课堂笔记补充或自学提纲。目前已有80人学习下载读者可直接获取完整知识框架、关键公式解释、Merkle证明流程、区块头字段解析及比特币脚本验证逻辑等高价值内容。1. 这不是密码学课件而是一份能跑通比特币核心逻辑的「可执行知识图谱」从哈希指针到UTXO验证5个模块全链路闭环你手头这份《区块链技术与应用.doc》表面看是北大肖臻老师公开课的讲义整理但实际它是一份极少见的、以工程实现为隐性主线的知识文档——所有概念都锚定在比特币真实协议行为上SHA256怎么用、Merkle proof怎么构造、coinbase transaction怎么序列化、UTXO集合如何被全节点实时维护。它不教你怎么写智能合约而是告诉你当一个交易广播进来时节点到底执行了哪7步校验为什么轻节点无法独立验证双花为什么“挖矿找nonce”这个等式成立的前提是哈希函数必须满足puzzle friendly性质这些不是理论推演而是比特币 Core 源码里AcceptToMemoryPool()和CheckBlock()函数的真实逻辑切片。适合两类人一是刚学完数据结构和密码学基础、正卡在“知道概念但不会写验证逻辑”的开发者二是想跳过冗长白皮书、直接用最小可行代码复现区块链关键机制的课程设计者。它不替代源码但能让你在打开main.cpp前就清楚每一行if (hash target)背后站着什么数学约束和系统权衡。2. 密码学原语不是装饰品SHA256 与 ECDSA 的工程级调用实操2.1 SHA256 的三重角色完整性校验、工作量证明、Merkle 根生成在比特币中SHA256 不是单一用途函数而是承担三种不可替代的职责区块头哈希SHA256(SHA256(block_header))—— 双重哈希防止长度扩展攻击输出256位固定值作为区块唯一IDMerkle 根计算对交易列表两两哈希SHA256(SHA256(tx1) SHA256(tx2))逐层向上归并最终根哈希存入区块头工作量证明目标H(block_header) ≤ target中的H即双重SHA256target是动态调整的256位整数以十六进制表示前导零越多难度越高。提示不要用 Pythonhashlib.sha256().digest()直接拼接——比特币要求小端序little-endian字节序处理。例如区块头原始字节流需先按小端序解析version,prev_block_hash,merkle_root等字段再整体哈希。常见翻车点Python 默认大端序C/Rust 的uint32_t字段需显式htole32()转换。下面这段 Python 代码严格复现比特币区块头哈希逻辑含小端序处理import hashlib import struct def bitcoin_block_header_hash(version, prev_hash, merkle_root, timestamp, bits, nonce): # 所有字段转为小端序字节注意prev_hash 和 merkle_root 是32字节需反转字节序 header_bytes b header_bytes struct.pack(I, version) # version: 小端32位整数 header_bytes bytes.fromhex(prev_hash)[::-1] # prev_hash: 32字节反转字节序 header_bytes bytes.fromhex(merkle_root)[::-1] # merkle_root: 同上 header_bytes struct.pack(I, timestamp) # timestamp header_bytes struct.pack(I, bits) # bits (target compact format) header_bytes struct.pack(I, nonce) # nonce # 双重SHA256先哈希一次再哈希结果 hash1 hashlib.sha256(header_bytes).digest() hash2 hashlib.sha256(hash1).digest() # 返回小端序显示的哈希值即比特币钱包/区块浏览器显示格式 return hash2[::-1].hex() # 示例测试创世区块头哈希已知值000000000019d6689c085ae1658de89f946b8b4a2e7e344e4b129e7e5515e55b genesis_hash bitcoin_block_header_hash( version1, prev_hash0000000000000000000000000000000000000000000000000000000000000000, merkle_root4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b, timestamp1231006505, bits0x1d00ffff, nonce2083236893 ) print(Genesis block hash (little-endian display):, genesis_hash)参数说明与逻辑struct.pack(I, x)中表示小端序I表示无符号32位整数prev_hash和merkle_root输入是十六进制字符串如abc...需先bytes.fromhex()转为字节再[::-1]反转字节序——这是比特币网络传输和存储的标准双重哈希SHA256(SHA256(x))是硬编码规则不可省略输出hash2[::-1].hex()是为了匹配比特币区块浏览器显示格式人类可读的小端序十六进制。2.2 ECDSA 签名与验证为什么比特币用 secp256k1 而非 RSA比特币使用椭圆曲线数字签名算法ECDSA在secp256k1曲线上实现交易签名而非更常见的 RSA。根本原因在于相同安全强度下secp256k1 的私钥仅需256位而 RSA 需要3072位以上这对区块链的存储和带宽至关重要。一个比特币地址本质是公钥的哈希RIPEMD160(SHA256(pubkey))而签名过程是对交易摘要z SHA256(transaction)计算用私钥d和随机数k生成签名(r, s)验证时用公钥Q d*GG为基点检查r ≡ x_coord(k⁻¹(z r*d)*G) mod n是否成立。以下 Python 代码使用ecdsa库完成标准流程注意生产环境请用secp256k1C 绑定库提升性能import ecdsa import hashlib import binascii # 1. 生成密钥对secp256k1 曲线 sk ecdsa.SigningKey.generate(curveecdsa.SECP256k1) vk sk.get_verifying_key() # 2. 构造交易摘要 z简化直接哈希字符串 transaction A-B(5BTC);fee0.001 z hashlib.sha256(transaction.encode()).digest() z_int int.from_bytes(z, big) % ecdsa.SECP256k1.order # 取模防止越界 # 3. 签名返回 (r,s) 元组 signature sk.sign_digest(z, sigencodeecdsa.util.sigencode_string) # 4. 验证 try: vk.verify_digest(signature, z, sigdecodeecdsa.util.sigdecode_string) print(✅ Signature valid) except ecdsa.BadSignatureError: print(❌ Signature invalid) # 5. 导出公钥用于生成地址 pubkey_bytes vk.to_string() # 65字节未压缩公钥 address_hash hashlib.new(ripemd160, hashlib.sha256(pubkey_bytes).digest()).hexdigest() print(Bitcoin address (P2PKH):, 1 address_hash[:34]) # 简化版地址生成关键参数与边界ecdsa.SECP256k1.order是曲线阶数n ≈ 2^256z_int必须对n取模否则签名无效sigencode_string表示 ASN.1 编码的 DER 格式比特币标准不可用sigencode_der以外的编码公钥vk.to_string()默认输出65字节未压缩格式以04开头压缩格式33字节02/03开头需调用vk.to_string(encodingcompressed)地址生成必须经SHA256 → RIPEMD160两层哈希且最终 Base58Check 编码需添加版本字节主网为0x00和校验和前4字节SHA256(SHA256(versionhash))——此处为简化演示省略。2.3 避坑哈希与签名中的5个致命细节现象 → 原因 → 解决全是血泪经验现象用hashlib.sha256(data).hexdigest()计算区块头哈希结果与 Bitcoin Core 不一致。原因hexdigest()返回大端序字符串而比特币要求小端序显示即字节流反转后显示。更隐蔽的是data若含整数字段如versionPython 默认大端序打包而比特币协议规定小端序。解决所有整数字段用struct.pack(I, x)打包哈希结果用hash[::-1].hex()反转字节序显示。现象ECDSA 签名验证失败vk.verify_digest()抛BadSignatureError。原因交易摘要z未对曲线阶数n取模或z长度超过256位导致高位截断。解决z_int int.from_bytes(z, big) % ecdsa.SECP256k1.order强制取模。现象Merkle root 计算错误两笔交易tx1, tx2的根哈希与bitcoin-cli getblock hash 2返回值不符。原因Merkle tree 要求交易列表必须按原始广播顺序排列且单个交易时需自身哈希两次SHA256(SHA256(tx))作为叶节点偶数个叶节点正常配对奇数个则最后一个叶节点重复一次。解决实现 Merkle tree 时先对每笔交易做双重哈希得叶节点再递归配对hash_pair SHA256(SHA256(left) SHA256(right))奇数长度时right left。现象轻节点验证 Merkle proof 时本地计算的路径哈希与根哈希不匹配。原因proof 路径中兄弟节点的哈希值顺序错误左兄弟在前还是右兄弟在前或未按路径方向从叶到根正确拼接SHA256(SHA256(sibling) current)或SHA256(SHA256(current) sibling)。解决比特币规定若当前节点是左子节点则拼接sibling current若是右子节点则current sibling。路径数组需明确标注每个兄弟节点的左右方位。现象用secp256k1库生成的私钥导入 Bitcoin Core 钱包失败。原因Bitcoin Core 要求 WIFWallet Import Format编码即0x80 privkey_bytes checksum的 Base58Check 编码而非裸私钥。解决WIF 编码需计算校验和checksum SHA256(SHA256(0x80 privkey))[:4]再 Base58 编码整个字节流。3. 区块链数据结构落地从 Hash Pointer 到 Merkle Tree 的内存实现3.1 Hash Pointer 的工程定义不只是“指向”而是“绑定校验”在传统链表中next指针是一个内存地址如0x7fff5fbff6a0修改节点数据不影响指针值。而在区块链中“Hash Pointer” 是一个结构体struct HashPointer { uint256 hash; // 前一区块全部数据的双重SHA256哈希值 uint32_t size; // 前一区块数据长度可选用于快速定位 };它的核心价值不是寻址而是完整性绑定当你读取当前区块时必须用其hash字段去重新计算前一区块的哈希若不匹配则整条链自该点断裂。这意味着不可篡改性修改任一历史区块数据 → 其哈希改变 → 后续所有区块的hash字段失效轻量验证全节点只需保存最新区块头80字节即可通过逐层哈希回溯验证任意历史区块无需存储全部数据防环依赖Hash Pointer 无法构成环形链表因为计算H(A)需要A的完整数据而A又依赖H(B)B依赖H(A)形成死锁。下面用 Python 实现一个最小可行的区块链类重点展示 Hash Pointer 如何驱动验证import hashlib import time import json class Block: def __init__(self, index, previous_hash, data, timestampNone, nonce0): self.index index self.previous_hash previous_hash # Hash Pointer 的核心字段 self.data data self.timestamp timestamp or time.time() self.nonce nonce self.hash self.calculate_hash() def calculate_hash(self): # 区块哈希 SHA256(索引 前哈希 数据 时间戳 随机数) block_string f{self.index}{self.previous_hash}{self.data}{self.timestamp}{self.nonce} return hashlib.sha256(block_string.encode()).hexdigest() class Blockchain: def __init__(self): self.chain [self.create_genesis_block()] def create_genesis_block(self): return Block(0, 0, Genesis Block, 1231006505, 2083236893) def get_latest_block(self): return self.chain[-1] def add_block(self, data): new_block Block( indexlen(self.chain), previous_hashself.get_latest_block().hash, # 关键Hash Pointer 赋值 datadata ) self.chain.append(new_block) def is_chain_valid(self): # 从创世块开始逐块验证 Hash Pointer for i in range(1, len(self.chain)): current_block self.chain[i] previous_block self.chain[i-1] # 1. 当前区块的 previous_hash 是否等于前一区块的实际哈希 if current_block.previous_hash ! previous_block.hash: print(f❌ Invalid Hash Pointer at block {i}: expected {previous_block.hash}, got {current_block.previous_hash}) return False # 2. 当前区块自身哈希是否被篡改 if current_block.hash ! current_block.calculate_hash(): print(f❌ Invalid self-hash at block {i}) return False return True # 使用示例 my_chain Blockchain() my_chain.add_block(Transaction 1: A-B(5)) my_chain.add_block(Transaction 2: B-C(3)) print(Is chain valid?, my_chain.is_chain_valid()) # ✅ True # 模拟篡改修改第二块数据 my_chain.chain[1].data CORRUPTED DATA print(After tampering:, my_chain.is_chain_valid()) # ❌ False检测到 Hash Pointer 断裂逻辑说明add_block()中previous_hashself.get_latest_block().hash是 Hash Pointer 的赋值动作它将新块与前一块密码学绑定is_chain_valid()的核心是双重校验current.previous_hash previous.hashPointer 完整性 current.hash recalc_hash()自身完整性篡改后is_chain_valid()立即返回False且精准定位到block 1的previous_hash不匹配——这正是区块链“自验证”能力的体现。3.2 Merkle Tree为什么不用普通二叉树Merkle Tree 与普通二叉搜索树BST有本质区别特性普通 BSTMerkle Tree节点内容存储键值对如keytxid, valuetx存储哈希值叶节点交易哈希内部节点子节点哈希拼接哈希排序要求键必须有序左根右无序叶节点按交易广播顺序排列不排序比特币用 sorted Merkle tree 仅用于 SPV 证明不存在核心目的快速查找特定键快速证明某交易存在于区块中Merkle Proof且证明大小仅为O(log N)Merkle Proof 的构造逻辑给定一笔交易tx找到其在树中的叶节点位置收集从该叶到根路径上所有兄弟节点的哈希值组成 proof 数组。验证者用tx哈希和 proof 数组按路径方向逐层计算最终得到根哈希与区块头中merkle_root比较。以下 Python 实现一个支持 Merkle Proof 生成与验证的树import hashlib def double_sha256(data): return hashlib.sha256(hashlib.sha256(data).digest()).digest() def build_merkle_tree(tx_list): 构建 Merkle tree返回 (root_hash, proof_path) if not tx_list: return b\x00 * 32, [] # 叶节点每笔交易做双重哈希 nodes [double_sha256(tx.encode()) for tx in tx_list] # 逐层归并 while len(nodes) 1: if len(nodes) % 2 1: nodes.append(nodes[-1]) # 奇数个时复制最后一个 new_nodes [] for i in range(0, len(nodes), 2): combined nodes[i] nodes[i1] new_nodes.append(double_sha256(combined)) nodes new_nodes return nodes[0], [] # 简化暂不返回 proof见下方函数 def get_merkle_proof(tx_list, target_tx): 为 target_tx 生成 Merkle proof路径上的兄弟哈希列表 if target_tx not in tx_list: return None # 构建叶节点哈希列表 leaves [double_sha256(tx.encode()) for tx in tx_list] idx tx_list.index(target_tx) proof [] level leaves[:] while len(level) 1: if len(level) % 2 1: level.append(level[-1]) next_level [] for i in range(0, len(level), 2): left level[i] right level[i1] if i1 len(level) else level[i] # 如果 target 在左子树兄弟是 right反之兄弟是 left if idx % 2 0: # idx 是偶数 → 当前节点是左子节点 if i1 len(level): proof.append((right, right.hex())) # else: 叶节点唯一无兄弟但比特币要求复制故总有兄弟 else: # idx 是奇数 → 当前节点是右子节点 proof.append((left, left.hex())) # 计算父节点哈希 combined left right next_level.append(double_sha256(combined)) level next_level idx // 2 # 上升一层索引折半 return proof def verify_merkle_proof(target_tx_hash, proof, root_hash): 验证 Merkle proof current_hash target_tx_hash for side, sibling_hash in proof: sibling_bytes bytes.fromhex(sibling_hash) if side left: combined sibling_bytes current_hash else: # right combined current_hash sibling_bytes current_hash double_sha256(combined) return current_hash root_hash # 示例 txs [A-B(5), B-C(3), C-D(1)] root, _ build_merkle_tree(txs) proof get_merkle_proof(txs, B-C(3)) tx_hash double_sha256(B-C(3).encode()) is_valid verify_merkle_proof(tx_hash, proof, root) print(Merkle proof valid?, is_valid) # ✅ True参数与陷阱说明double_sha256()是比特币硬性规定不可省略get_merkle_proof()中idx % 2 0判断左右子节点决定兄弟哈希取哪一侧verify_merkle_proof()必须严格按 proof 中的side字段拼接顺序left时sibling currentright时current sibling当交易数为1时proof 为空列表验证直接current_hash root_hash。3.3 避坑数据结构实现中的4个反直觉陷阱现象 → 原因 → 解决全是调试到凌晨三点的教训现象自己实现的 Merkle root 与bitcoin-cli getblock hash 2返回的merkleroot不一致。原因比特币区块中交易列表的第一个交易永远是 coinbase transaction铸币交易且其输入脚本包含额外随机数extraNonce导致哈希不同。你的tx_list若未包含 coinbaseroot 必然错误。解决构造 Merkle tree 时tx_list[0]必须是 coinbase transaction 的完整序列化字节含scriptSig中的 extraNonce。现象Hash Pointer 验证通过但区块仍被 Bitcoin Core 拒绝。原因Hash Pointer 仅保证链式结构但比特币还要求区块头version,timestamp,bits等字段符合共识规则如timestamp median_time_pastbits在允许范围。解决完整验证需调用CheckBlockHeader()逻辑包括时间戳检查、难度目标检查、签名检查等不能只验哈希。现象Merkle proof 验证失败current_hash与root_hash差一个字节。原因哈希值比较时用了字符串但double_sha256()返回字节对象root_hash可能是十六进制字符串如abc...而current_hash是字节。解决统一用字节比较current_hash bytes.fromhex(root_hash)或current_hash.hex() root_hash。现象轻节点用 Merkle proof 验证交易存在但全节点说该交易已被双花。原因Merkle proof 只证明交易曾被包含在某个区块中不证明该区块在最长有效链上。若发生分叉该区块可能被回滚。解决轻节点必须等待足够多的确认数如6个区块确保该区块已稳固在主链上——这需要同步区块头链并验证工作量。4. 协议层实战双花攻击模拟与 UTXO 集合的内存管理4.1 双花攻击的本质不是“技术漏洞”而是“状态同步延迟”双花Double Spending不是密码学被破解而是分布式系统中状态最终一致性的必然代价。攻击者利用网络延迟在两个不同节点同时广播同一笔 UTXO 的两笔消费交易交易 A 发送给节点 XX 将其加入内存池并开始挖矿交易 B 发送给节点 YY 同样将其加入内存池若 X 和 Y 分别在相近时间挖出新区块且区块都包含各自交易则形成分叉最终只有最长链上的交易被确认另一笔交易作废。因此防御双花的核心不是阻止广播而是让诚实节点快速达成对交易顺序的共识。比特币通过工作量证明PoW实现挖矿难度使新区块平均10分钟产生大幅降低分叉概率节点总是选择累计工作量最大的链最长链规则用户等待6个确认约1小时此时逆转概率低于10^-9。下面用 Python 模拟双花场景重点展示 UTXO 集合如何被更新from collections import defaultdict class UTXOSet: def __init__(self): # {txid_vout: {amount: float, scriptPubKey: str}} self.utxo {} def add_utxo(self, txid, vout, amount, scriptPubKey): self.utxo[f{txid}_{vout}] { amount: amount, scriptPubKey: scriptPubKey } def spend_utxo(self, txid, vout): key f{txid}_{vout} if key not in self.utxo: raise ValueError(fUTXO {key} not found) del self.utxo[key] def get_balance(self, address): # 简化假设 scriptPubKey 包含地址实际需解析脚本 return sum(v[amount] for k, v in self.utxo.items() if address in v[scriptPubKey]) class Transaction: def __init__(self, txid, inputs, outputs): self.txid txid self.inputs inputs # [{txid: ..., vout: 0}] self.outputs outputs # [{value: 5.0, scriptPubKey: OP_DUP ...}] def is_valid(self, utxo_set): # 1. 检查所有输入 UTXO 是否存在且未花费 total_input 0 for inp in self.inputs: key f{inp[txid]}_{inp[vout]} if key not in utxo_set.utxo: return False, fInput {key} not in UTXO set total_input utxo_set.utxo[key][amount] # 2. 检查输出总额 ≤ 输入总额含手续费 total_output sum(out[value] for out in self.outputs) if total_output total_input: return False, Output exceeds input return True, Valid # 初始化 UTXO创世区块铸币 utxo UTXOSet() utxo.add_utxo(genesis, 0, 50.0, OP_DUP OP_HASH160 ...) # 攻击者 Alice 的双花交易 tx_a Transaction( txidtx_a_123, inputs[{txid: genesis, vout: 0}], outputs[{value: 5.0, scriptPubKey: Alice_address}, {value: 45.0, scriptPubKey: Alice_change}] ) tx_b Transaction( txidtx_b_456, inputs[{txid: genesis, vout: 0}], outputs[{value: 10.0, scriptPubKey: Bob_address}, {value: 40.0, scriptPubKey: Alice_change}] ) # 模拟节点 X 接收 tx_a if tx_a.is_valid(utxo)[0]: print(✅ Node X accepts tx_a) # 更新 UTXO删除输入添加输出 for inp in tx_a.inputs: utxo.spend_utxo(inp[txid], inp[vout]) for i, out in enumerate(tx_a.outputs): utxo.add_utxo(tx_a.txid, i, out[value], out[scriptPubKey]) # 模拟节点 Y 接收 tx_b此时 utxo 已被 tx_a 修改 if tx_b.is_valid(utxo)[0]: print(❌ Node Y should reject tx_b: UTXO already spent) else: print(✅ Node Y correctly rejects tx_b (double spend detected))逻辑说明UTXOSet是全节点内存中的核心数据结构实时反映“哪些钱还没花”spend_utxo()删除输入对应的 UTXOadd_utxo()添加输出对应的 UTXOis_valid()第一步即检查输入是否仍在 UTXO 集合中——这是防双花的第一道也是最后一道防线模拟中tx_b因genesis_0已被tx_a消耗验证失败节点 Y 拒绝。4.2 UTXO 集合的持久化与快照为什么 Bitcoin Core 启动要扫描整个区块链Bitcoin Core 启动时若没有现成的 UTXO 数据库chainstate/目录会执行reindex遍历从创世块到最新块的所有交易重建 UTXO 集合。这是因为UTXO 集合是派生状态非原始数据区块链只存储交易UTXO 是交易执行后的结果为加速启动Bitcoin Core 维护一个 LevelDB 数据库chainstate/键为c txid_vout值为 UTXO 序列化数据。以下 Python 伪代码展示 UTXO 快照的生成逻辑简化版import plyvel def build_utxo_snapshot(blockchain_db_path, snapshot_path): 从区块链数据库生成 UTXO 快照LevelDB 格式 # 打开区块链数据库实际为 blocks/ 目录下的 .dat 文件此处简化 # 1. 初始化空 UTXO 字典 utxo_snapshot {} # 2. 遍历所有区块伪代码 for block in blockchain_iterator(): for tx in block.transactions: # 处理 coinbase添加新 UTXO铸币 if tx.is_coinbase(): for i, out in enumerate(tx.outputs): key fc{tx.txid}_{i} # c 表示 coinbase utxo_snapshot[key] serialize_utxo(out) # 处理普通交易删除输入添加输出 else: for inp in tx.inputs: key_in fu{inp.txid}_{inp.vout} # u 表示普通 UTXO if key_in in utxo_snapshot: del utxo_snapshot[key_in] for i, out in enumerate(tx.outputs): key_out fu{tx.txid}_{i} utxo_snapshot[key_out] serialize_utxo(out) # 3. 写入 LevelDB db plyvel.DB(snapshot_path, create_if_missingTrue) with db.write_batch() as wb: for key, value in utxo_snapshot.items(): wb.put(key.encode(), value) db.close() print(f✅ UTXO snapshot saved to {snapshot_path}) def serialize_utxo(output): 序列化 UTXO简化仅金额和脚本 return f{output.value}:{output.scriptPubKey}.encode()关键参数LevelDB 键前缀c表示 coinbase UTXOu表示普通 UTXO便于快速扫描serialize_utxo()必须包含所有必要字段金额、脚本、高度用于 pruned node、是否为 coinbase实际 Bitcoin Core 使用更紧凑的序列化CTxOutCompressor并存储在chainstate/的Cf00000000000000000000000000000000000000000000000000000000000000文件中。4.3 避坑UTXO 与协议验证的3个高危误区现象 → 原因 → 解决全是线上事故复盘现象节点同步完成后getbalance返回 0但listunspent显示有 UTXO。原因getbalance默认只返回“成熟”的 coinbase UTXO需100个确认而listunspent显示所有未花费输出。新挖出的币未达成熟期本文还有配套的精品资源点击获取