区块链技术与数字货币

1.起源

➢中本聪(Satoshi Nakamoto), 2008

➢比特币:一种点对点的电子现金系统

2.分布式账本技术原理

1.两个核心技术：

➢以链式区块组织账本数据实现账本数据的不可篡改

➢分布式的可信记账机制

2.共识机制：由谁记账

➢目的：

⚫ 解决记账权

➢ 场景：

➢ 开放系统，动态增减，海量节点

➢解决方案

⚫ 工作量证明（proof of work）：高强度哈希计算 (SHA256)进行算力竞争解决记账权，达成共识。

3.共识协议模型：

• 节点海量、动态增减

• 存在恶意节点

• PBFT算法要求节点集相对稳定，数量有限，不适用

• 工作量证明PoW共识

▫ 划定固定时间段（10分钟）

▫ 相同或相似输入数据（组装的区块）

▫ 算力竞争选出获胜节点，其它节点验证结果后不再发送消息

▫ 最长链原则，从短期共识扩展到长期共识

3.区块链宏观结构

➢区块链

⚫ 基于哈希值进行链接

➢特点

⚫ 区块链中数据无法篡改或删除

⚫ 区块链越长可信度越高

4.区块链微观结构

1.区块组成

➢每个区块包括区块头和交易数据两个部分

⚫ 区块头由当前区块的元数据和前一区块的Hash值构成

⚫ Merkle树用于对交易数据列表进行快速寻址

2.区块的结构

区块头的结构

3.区块头代码

class CBlockHeader {} //这是一个“类”，或数据机构，内含下面这些字段：
] int32_t nVersion //所采用Bitcoin协议的版本号
] uint256 hashPrevBlock //上一个块的（块头）Hash值。
] uint256 hashMerkleRoot //所记载交易记录的TxID，
                         //即其Hash值所构成Merkle树的根
] uint32_t nTime //本块的发布时间
] uint32_t nBits //为挖矿过程设置的难度，Hash值中须有的前导零的位数。
] uint32_t nNonce //在挖矿过程中使Hash值达到nBits字段所
                  //要求前导零位数的试凑值。

4.区块标识符：区块头哈希值和区块高度

• 区块主标识符是它的加密哈希值，一个通过SHA256算法对区块头进行二次哈希计算而得到的数字指纹。例如 :000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f是第一个比特币区块的区块哈希值。

• 区块哈希值实际上并不包含在区块的数据结构

• 第二种识别区块的方式是通过该区块在区块链中的位置，即“区块高度（block height）”。例如：高度为0的区块就是创世区块。

• 和区块哈希值不同的是，区块高度并不是唯一的标识符，因为有可能出现区块链分叉。

5.Merkle树

• Merkle树是一种哈希二叉树，它是一种用作快速归纳和校验大规模数据完整性的数据结构。这种二叉树包含加密哈希值。

▫ 叶节点是数据块的哈希值。

▫ 非叶节点的哈希值是根据它下面子节点的值哈希计算得到。

• 在比特币网络中，Merkle树被用来归纳一个区块中的所有交易，同时生成整个交易集合的数字指纹，且提供了一种校验区块是否存在某交易的高效途径。

• Merkle树中使用两次SHA256算法计算结点的哈希值。

▫ H~A~ = SHA256(SHA256(交易A)) //两次SHA256是为了提高安全强度

• 当N个数据元素经过加密后插入Merkle树时，你至多计算log2(N)次就能检查出任意某数据元素是否在该树中，这使得该数据结构非常高效。

6.Merkle树的价值：简单支付验证

有了Merkle树，一个节点能够仅下载区块头（80字节/区块），然后通过从一个满节点回溯一条Merkle路径就能认证一笔交易的存在，而不需要存储或者传输区块链中大多数内容。

这种不需要维护一条完整区块链的节点，又被称作简单支付验证（SPV）节点，它不需要下载整个区块而通过Merkle路径去验证交易的存在。

7.比特币区块链中的节点

• 全节点 full client：存储着整个区块链，承但对交易请求进行验证和执行，可以通过挖矿争取发布区块，还承担着应别的节点之请向其发送区块和相关交易信息的义务，同时也承担转发交易请求和区块的义务。

▫ 矿工节点 ▫ 非矿工节点

• 轻节点 light client ：

① 简单支付验证（SPV）节点：只存储区块头，不存储区块块体，仍可以对到来的交易请求进行

验证。

②钱包：一个连接区块链的应用软件(app)，记录与所有者有关的信息：

区块链地址、私钥、账户余额、UTXO等，不存储账本。

8.SPV（钱包）验证过程

• 针对某个支付到自己比特币地址的交易建立布隆过滤器，限制只接收含有目标比特币地址的交易。

• 其他全节点探测到某个交易符合SPV节点设置的布隆过滤器条件时，以 Merkleblock消息的形式发送该区块，Merkleblock消息包含区块头和一条连接目标交易与Merkle根的Merkle路径。

• 交易的存在性验证：SPV节点通过该Merkle路径找到跟该交易相关的区

块，并验证对应区块中是否存在目标交易（Merkle Path Proof）。

• 交易是否双化验证：SPV节点检查这笔交易所在区块之后的区块个数，区块个数越多说明该区块被全网更多节点共识，一般来说，一笔交易所属区块之后的区块个数达到6个时，说明这笔交易是可信的。

5.区块链整体结构

区块头代码

class CBlockHeader {} //这是一个“类”，或数据机构，内含下面这些字段：
] int32_t nVersion //所采用Bitcoin协议的版本号
] uint256 hashPrevBlock //上一个块的（块头）Hash值。
] uint256 hashMerkleRoot //所记载交易记录的TxID，
//即其Hash值所构成Merkle树的根
] uint32_t nTime //本块的发布时间
] uint32_t nBits //为挖矿过程设置的难度，Hash值中须有的前导零的位数。
] uint32_t nNonce //在挖矿过程中使Hash值达到nBits字段所
                  //要求前导零位数的试凑值。

交易的数据结构

class CTransaction {} //一个交易请求或交易记录
] const std::vector<CTxIn> vin //本Tx的输入UTXO序列，即资金来源。
] const std::vector<CTxOut> vout //本Tx的输出UTXO序列，即资金去向。
] const int32_t nVersion // CURRENT_VERSION=2
] const uint32_t nLockTime //锁定时间，时间未到点之前本交易不入块
。
] const uint256 hash //本Tx的Hash值，只存储在内存中，
                     //不作永久存储也不发送。