第3讲:BTC-数据结构

本节《03-BTC-数据结构》主要讲比特币区块链里用到的几种核心数据结构,包括交易结构、区块结构以及 Merkle 树等,并说明这些结构如何保证不可篡改性和可验证性。

课程整体脉络

这一讲在前一节"密码学原理"的基础上,从"数据长什么样"入手,解释比特币系统里信息是如何被组织和关联的,即:一笔交易如何记录、多个交易如何组成区块、区块之间如何串起来形成区块链。 课程目标是让学生理解:只靠这些数据结构和哈希函数,就能在开放网络中做到"谁也改不了账本、谁都能验证"。

交易数据结构

课程重点先讲"交易"(transaction)的内部结构,一般包含输入列表、输出列表、金额、锁定脚本、解锁脚本等字段。 老师会强调:每个"输入"必须指向一条已有交易的某个"输出"(UTXO),也就是"花谁给你的钱",而"输出"则记录"把钱给谁",这样把每次转账都串成一条可追溯的记录链。

  • 例子:A 之前收到过一笔 10 BTC 的输出,现在想给 B 转 3 BTC,就会构造一笔新交易:输入引用那笔 10 BTC 的输出,输出分成两个:一个 3 BTC 给 B,一个 7 BTC 找零给 A 自己。
  • 通过这种"必须一次性花掉一个输出再找零"的结构,可以防止重复花同一笔钱,并简化验证逻辑:节点只要检查引用的输出是否还"未花费"(UTXO 集合里存在)即可。

区块头与区块体

接着课程讲"区块"的结构:区块大致分为"区块头(header)"和"区块体(body)"。 区块体里是本区块打包的所有交易;区块头包含版本号、前一个区块的哈希、Merkle 根哈希、时间戳、难度目标和随机数 nonce 等字段,是工作量证明和链式连接的关键。

  • 例子:区块头中的"前一个区块哈希"好比一本账本中"上一页的指纹",任何人改动前一区块哪怕一笔交易,都会导致前一区块哈希变化,从而使当前区块头哈希也失效,形成"牵一发而动全身"的防篡改效果。
  • 学生只要获取一条最长合法链的"区块头序列",就能快速验证整条链的工作量和链接关系,而不必一开始就下载全部交易细节。

Merkle 树与 Merkle 根

老师会重点讲解 Merkle 树:它是一棵二叉哈希树,叶子结点是每笔交易的哈希,上层结点是左右孩子哈希拼接后再哈希,一直往上合并,最终得到一个 Merkle 根存进区块头。 这样可以用一个固定长度的哈希值来"代表"区块中所有交易数据,同时支持高效的包含性证明。

  • 例子:如果钱包想证明"交易 X 确实包含在某区块里",节点只需给它从该交易所在叶子到根路径上相邻兄弟结点的哈希列表,钱包自己逐层拼接哈希就能算出根值,若与区块头里的 Merkle 根一致,就证明该交易已被该区块收录。
  • Merkle 树还能局部检测篡改:如果某笔交易被改掉,对应叶子哈希变了,其路径上的所有中间哈希都会变,最终导致 Merkle 根不一致,从而立刻发现问题。

链式结构与不可篡改性

最后课程把这些结构串起来:交易通过引用旧输出、区块通过前块哈希链接、交易集合通过 Merkle 树压缩,整体形成一条"每一环都依赖前一环"的哈希链。 在这种结构下,想要篡改一笔早期交易,就等于要重新计算那笔交易所在区块的 Merkle 根和区块头哈希,并连同之后所有区块一起重做工作量证明,代价极高。

验证每个区块头的哈希满足难度,区块间前后哈希一致,再抽查交易和 Merkle 路径,就可以对整条链的有效性有高置信度,而不需要信任任何单一机构。

  • 这一讲的核心结论是:比特币并不靠"机构背书"来保证账本可信,而是靠这些精心设计的数据结构加哈希函数,把"想作弊就得付出巨大算力成本"写死在系统规则里。
相关推荐
白狐_7981 小时前
【项目实战】我用一个 HTML 文件写了一个“CET-6 单词斩”
前端·算法·html
夕水1 小时前
React Server Components 中的严重安全漏洞
前端
sg_knight1 小时前
SSE 技术实现前后端实时数据同步
java·前端·spring boot·spring·web·sse·数据同步
苹果电脑的鑫鑫1 小时前
el-select下拉菜单如何可以手输入内容
前端·vue.js·elementui
脾气有点小暴2 小时前
ES6(ECMAScript 2015)基本语法全解析
前端·javascript
前端fighter2 小时前
全栈项目:闲置二手交易系统(二)
前端·vue.js·node.js
sztian682 小时前
JavaScript---BOM对象、JS执行机制、location对象
开发语言·前端·javascript
潘小安2 小时前
【译】别再想着 Figma 了,AI 才是新的设计工具
前端·ai编程·weui