比特币的区块数据里包含了比特币链上的核心信息，包括比特币如何交易，区块扩容等问题。比特币从诞生到现在，每10分钟诞生一个区块，访问 https://blockchain.info/ 查看最近的区块信息，可以看到当前的区块大小已经接近或超过中本聪设置的1MB容量。
区块链数据结构
一个完整的区块结构主要由以下几部分构成：
| 数据项 | 字节 | 字段 | 说明 |
|---|---|---|---|
| Magic NO | 4 | 魔数 | 常数0xD9B4BEF9 |
| Blocksize | 4 | 区块大小 | 用字节表示的该字段之后的区块大小 |
| Blockheader | 80 | 区块头 | 组成区块头的几个字段 |
| Transaction counter | 1-9 | 交易计数器 | 该区块包含的交易数量，包含coinbase交易 |
| Transactions | 不定 | 交易 | 记录在区块里的交易信息，使用原生的交易信息格式，并且交易在数据流中的位置必须与Merkle树的叶子节点顺序一致 |
区块信息解析
我们从 https://webbtc.com 选择一个区块哈希值为000000000003ba27aa200b1cecaad478d2b00432346c3f1f3986da1afd33e506的早期区块进行分析。
可以看到该区块中包含了三笔交易信息，下面对区块信息字段进行解析。
区块头分析
前80个字节是区块头。
{
"hash": "000000000003ba27aa200b1cecaad478d2b00432346c3f1f3986da1afd33e506",
"ver": 1,
"prev_block": "000000000002d01c1fccc21636b607dfd930d31d01c3a62104612a1719011250",
"mrkl_root": "f3e94742aca4b5ef85488dc37c06c3282295ffec960994b2c0d5ac2a25a95766",
"time": 1293623863,
"bits": 453281356,
"nonce": 274148111
}| 字节 | 字段 | 说明 |
|---|---|---|
| 4 | 版本 | 区块版本号，表示本区块遵守的验证规则 |
| 32 | 父区块头哈希值 | 前一区块的哈希值，使用SHA256(SHA256(父区块头))计算 |
| 32 | Merkle根 | 该区块中交易的Merkle树根的哈希值，同样采用SHA256(SHA256())计算 |
| 4 | 时间戳 | 该区块产生的近似时间，精确到秒的UNIX时间戳，必须严格大于前11个区块时间的中值，同时全节点也会拒绝那些超出自己2个小时时间戳的区块 |
| 4 | 难度目标 | 该区块工作量证明算法的难度目标，已经使用特定算法编码 |
| 4 | Nonce | 为了找到满足难度目标所设定的随机数，为了解决32位随机数在算力飞升的情况下不够用的问题，规定时间戳和coinbase交易信息均可更改，以此扩展nonce的位数 |
说明：
- 版本、父区块头哈希值和Merkle根采用的是小端格式编码，即低有效位放在前面。
- 时间戳表示的是自1970年1月1日0时0分0秒以来的秒数
Coinbase交易信息分析
一个区块第一个交易规定为coinbase交易，即由挖矿产生的比特币奖励，可以看到目前挖出每个区块的奖励是12.5个比特币，下一次减半会发生在2020年。除了挖矿奖励，“矿工”的激励还有新增账本记账的手续费，在未来比特币总量不增加之后，后者会成为矿工的主要收入。
{
"hash": "8c14f0db3df150123e6f3dbbf30f8b955a8249b62ac1d1ff16284aefa3d06d87",
"ver": 1,
"vin_sz": 1,
"vout_sz": 1,
"lock_time": 0,
"size": 135,
"in": [{
"prev_out": {
"hash": "0000000000000000000000000000000000000000000000000000000000000000",
"n": 4294967295
},
"coinbase": "044c86041b020602"
}],
"out": [{
"value": "50.00000000",
"scriptPubKey": "041b0e8c2567c12536aa13357b79a073dc4444acb83c4ec7a0e2f99dd7457516c5817242da796924ca4e99947d087fedf9ce467cb9f7c6287078f801df276fdf84 OP_CHECKSIG",
"next_in": {
"hash": "f3e6066078e815bb24db0dfbff814f738943bddaaa76f8beba360cfe2882480a",
"n": 12
}
}],
"nid": "70ab531a68f973f7d20b8260cb5e7fecba3699c48715b8b44539ff9776d0b88e"
}| 字节 | 字段 | 描述 |
|---|---|---|
| 4 | 版本 | 这笔交易参照的规则 |
| 1-9 | 输入计数器 | 包含的交易输入数量 |
| 32 | 交易哈希 | 不引用任何一个交易，值全部为0 |
| 4 | 交易输出索引 | 固定为0xFFFFFFFF |
| 1-9 | Coinbase数据长度 | coinbase数据长度 |
| 不定 | Coinbase数据 | 在V2版本的区块中，除了需要以区块高度开始外，其它数据可以任意填写，用于extra nonce和挖矿标签 |
| 4 | 顺序号 | 值全部为1，0xFFFFFFFF |
| 1-9 | 输出计数器 | 包含的交易输出数量 |
| 8 | 总量 | 用聪表示的比特币值 |
| 1-9 | 锁定脚本大小 | 用字节表示的后面的锁定脚本长度 |
| 不定 | 锁定脚本 | 一个定义了支付输出所需条件的脚本 |
| 4 | 锁定时间 | 一个区块号或UNIX时间戳 |
交易信息记录
下面来看下普通的交易记录。
{
"hash": "fff2525b8931402dd09222c50775608f75787bd2b87e56995a7bdd30f79702c4",
"ver": 1,
"vin_sz": 1,
"vout_sz": 2,
"lock_time": 0,
"size": 259,
"in": [{
"prev_out": {
"hash": "87a157f3fd88ac7907c05fc55e271dc4acdc5605d187d646604ca8c0e9382e03",
"n": 0
},
"scriptSig": "3046022100c352d3dd993a981beba4a63ad15c209275ca9470abfcd57da93b58e4eb5dce82022100840792bc1f456062819f15d33ee7055cf7b5ee1af1ebcc6028d9cdb1c3af774801 04f46db5e9d61a9dc27b8d64ad23e7383a4e6ca164593c2527c038c0857eb67ee8e825dca65046b82c9331586c82e0fd1f633f25f87c161bc6f8a630121df2b3d3"
}],
"out": [{
"value": "5.56000000",
"scriptPubKey": "OP_DUP OP_HASH160 c398efa9c392ba6013c5e04ee729755ef7f58b32 OP_EQUALVERIFY OP_CHECKSIG",
"address": "1JqDybm2nWTENrHvMyafbSXXtTk5Uv5QAn",
"next_in": {
"hash": "5aa8e36f9423ee5fcf17c1d0d45d6988b8a5773eae8ad25d945bf34352040009",
"n": 6
}
},
{
"value": "44.44000000",
"scriptPubKey": "OP_DUP OP_HASH160 948c765a6914d43f2a7ac177da2c2f6b52de3d7c OP_EQUALVERIFY OP_CHECKSIG",
"address": "1EYTGtG4LnFfiMvjJdsU7GMGCQvsRSjYhx",
"next_in": {
"hash": "220ebc64e21abece964927322cba69180ed853bb187fbc6923bac7d010b9d87a",
"n": 0
}
}
],
"nid": "fc7704fdd7ec5e69163e51b827fea2133990a26defee2b475408b3c16fd9a968"
}扩容问题如何解决
在比特币诞生初期，中本聪为了比特币系统的安全和稳定，防止比特币系统被攻击而把区块大小设置为1M。在当时比特币用户量少，比特币交易是不存在拥堵问题的。
随着比特币网络的发展，单个区块存储的交易信息越来越多，1MB区块仅能容纳2000条左右交易，
交易量大时需要排队等待区块写入确认，交易网络拥堵问题越来越严重，为此也出现了解决容量问题的几个方案。
1.区块扩容
解决区块过小问题，最直接的办法就是扩容。区块体积中位数在2015年里得到了翻番，从1月份的292KB快速增长至12月份的749KB。2015 年12月比特币香港扩容会议由Pieter Wuille提出了隔离见证(Segregated Witness)之后，扩容问题甚至已经简化为仅升级至2MB。
为什么不把区块设置的更大一些，比如30MB？区块存储的是交易信息，若提高区块体积限制至30MB，最大的问题不是CPU计算能力瓶颈，而是块的传播与存储。30MB的块可能会导致全网孤块率和空块率大幅上升，一年产出1.5TB的区块链数据也超出大部分节点机器的硬盘容量。基于这1.5TB的数据，区块链浏览器、钱包服务商等则可能膨胀10倍达到15TB，对于目前来说已经远超普通机器/数据库的磁盘容量。除了扩容，还有另外的解决方案就是隔离见证和闪电网络。
2.隔离见证和闪电网络
隔离见证(SegWit)是把交易的签名数据从交易数据中剥离出来，用于解决延展性攻击。比特币交易主要是由两部分数据组成。其中一部分为交易数据，它负责记录比特币的来源和去处。而另外一部分则是见证数据，这部分数据由一些加密数据组成，用于证明这些交易请求是真实可信的。中本聪在设计比特币的时候直接把这两部分信息都放在了区块内，所以一个区块就承载不了更多的交易信息。如果隔离了“见证数据”，那么区块链只记录交易数据，那么一个区块可承载更多的交易。
闪电网络（Lightning Network）方案是在比特币网络上再外加一个「 闪电网络（Lightning Network）」，把原有比特币链上金额较少的交易，转移到这个闪电网络来处理，完成后再记录到原链上。这是一种链外交易（Off-chain transaction），目的是解决加快交易速度，以太坊（Ethereum）也有类似的方案叫Raiden Network。
用搭乘公共汽车的来假设，试想像比特币的区块是一辆公共汽车，每隔十分钟，固定时间发车，当要乘车的人超过公共汽车容量，不能上车的人就要等待下一班。我们的目的就是让更多的人可以乘车，即承载更多的交易。
比特币区块链本身是可以根据交易费率来优先完成交易的，如果你想快速完成转账等功能，可以设置较高的手续费。这就类似公共汽车让出更高价格买票的人先上车，不愿付高车票的人就要一直等下去，直到坐车的人变少。隔离见证就是我们在公共汽车后面加挂一个货车（SegWit车箱），所有乘车的人都要把背包和行李放到这个货车上面，因为少了随身物品，每个人占的空间变少了，公共汽车就可以多载一些人，乘载量就变多了。闪电网络可以理解为在公交车路线旁边再架一条铁路，让挤不上公共汽车的人直接去坐火车，解决掉太多人要搭乘车（交易），而汽车太小的问题。隔离见证和闪电网络在技术上有可行性，但是同样有许多质疑。依赖于隔离见证的闪电网络等二层网络并不能被认为是比特币的扩容方案，因为闪电网络的交易并不等价于比特币的点对点的链上交易，大部分比特币交易的场景并不适用于闪电网络。假设闪电网络部署成功，也会存在大型支付中心的问题，这违背了比特币做为点对点支付系统的初衷。
- blocks：比特币区块头数据表
- transactions：比特币交易头数据表
- tx_inputs：比特币交易输入数据表
- tx_output：比特币交易输出数据表
