主页

索引

模块索引

搜索页面

常用

比特币网络系统中并没有特殊创新的技术，它有机的组合了如下领域的已有成果:

* 密码学
* 博弈论
* 记账技术
* 分布式系统
* 控制论

挖矿

备注

挖矿即不断接入新的Block延续Block Chain的过程

挖矿为整个系统的运转提供原动力，是比特币的发动机，没有挖矿就没有比特币。挖矿有三个重要功能:

1.发行新的货币（总量达到之前）
2.维系货币的支付功能
3.通过算力保障系统安全
金矿消耗资源将黄金注入流通经济，
比特币通过“挖矿”完成相同的事情，只不过消耗的是CPU时间与电力。
当然，比特币的挖矿意义远大于此。

Block Hash算法

区块头部信息结构:

1. Version(4字节):
    版本号，用于跟踪软件/协议的更新

2. hashPrevBlock(32字节):
    上一个block hash值，引用区块链中父区块的哈希值

3. hashMerkleRoot(32字节):
    Merkle根，上一个block产生之后至新block生成此时间内，交易数据打包形成的Hash
    即: 该区块中交易的merkle树根的哈希值

4. TimeUnix(4字节):
    时间戳，该区块产生的近似时间（精确到秒的Unix时间戳）

5. Bits(4字节):
    难度目标值，即该区块工作量证明算法的难度目标

6. Nonce(4字节):
    随机数，用于工作量证明算法的计数器(PoW 问题的答案)

区块结构:

1. 区块大小(4字节):
  用字节表示的该字段之后的区块大小

2. 区块头(80字节):
  组成区块头的几个字段

3. 交易计数器(1-9的可变整数)
  交易的数量

4. 交易(大小是可变的)
  记录在区块里的交易信息

创业区块:

创世区块的哈希值为：
0000000000 19d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

概念

比特币账户:

采用了非对称的加密算法，用户自己保留私钥，对他发出的交易进行签名确认，并公开公钥。
比特币的账户地址其实就是用户公钥经过一系列 hash及编码运算后生成的 160 位（20 字节）的字符串:
    hash算法: HASH160，或先进行 SHA256，然后进行 RIPEMD160

交易:

交易是完成比特币功能的核心概念，一条交易将可能包括如下信息：
1. 付款人地址：合法的地址，公钥经过 SHA256 和 RIPEMD160 两次 hash，得到 160 位 hash 串
2. 付款人对交易的签字确认：确保交易内容不被篡改
3. 付款人资金的来源交易 ID：从哪个交易的输出作为本次交易的输入
4. 交易的金额：多少钱，跟输入的差额为交易的服务费
5. 收款人地址：合法的地址
6. 收款人的公钥：收款人的公钥
7. 时间戳：交易何时能生效

网络中节点收到交易信息后，将进行如下检查：
1. 交易是否已经处理过
2. 交易是否合法。包括地址是否合法、发起交易者是输入地址的合法拥有者、是否是 UTXO
3. 交易的输入之和是否大于输出之和
检查都通过，则将交易标记为合法的未确认交易，并在网络内进行广播

脚本

备注

脚本（Script） 是保障交易完成（主要用于检验交易是否合法）的核心机制，当所依附的交易发生时被触发。通过脚本机制而非写死交易过程，比特币网络实现了一定的可扩展性。比特币脚本语言是一种非图灵完备的语言，类似 Forth 语言。

一般每个交易都会包括两个脚本:

输出脚本（scriptPubKey）
认领脚本（scriptSig）

输出脚本目前支持两种类型:

* P2PKH：Pay-To-Public-Key-Hash:
    允许用户将比特币发送到一个或多个典型的比特币地址上（证明拥有该公钥），
    前导字节一般为 0x00；
* P2SH：Pay-To-Script-Hash
    支付者创建一个输出脚本，里边包含另一个脚本（认领脚本）的哈希，
    一般用于需要多人签名的场景，前导字节一般为 0x05；

以 P2PKH 为例，输出脚本的格式为:

scriptPubKey:
    OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

其中:
    1. OP_DUP 是复制栈顶元素；
    2. OP_HASH160 是计算 hash 值；
    3. OP_EQUALVERIFY 判断栈顶两元素是否相等；
    4. OP_CHECKSIG 判断签名是否合法。
        这条指令实际上保证了只有 pubKey 的拥有者才能合法引用这个输出。

另外一个交易如果要花费这个输出，在引用这个输出的时候，需要提供认领脚本格式为:

scriptSig:
    <sig> <pubKey>
其中:
    <sig> 是拿 pubKey 对应的私钥对交易（全部交易的输出、输入和脚本）hash 值进行签名
    pubKey 的 hash 值需要等于 pubKeyHash。

进行交易验证时，会按照先 scriptSig 后 scriptPubKey 的顺序进行依次入栈处理，即完整指令为:

<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

备注

引入脚本机制带来了灵活性，但也引入了更多的安全风险。比特币脚本支持的指令集十分简单，基于栈的处理方式，并且非图灵完备，此外还添加了额外的一些限制（大小限制等）

设计理念

如何避免作恶

备注

基于经济博弈原理。在一个开放的网络中，无法通过技术手段保证每个人都是合作的。但可以通过经济博弈来让合作者得到利益，让非合作者遭受损失和风险。

博弈论早已被广泛应用到众多领域:

一个经典的例子是两个人来分一个蛋糕，如果都想拿到较大的一块，在没有第三方的前提下，该怎么指定规则才公平？
最简单的一个方案是负责切蛋糕的人后选。

推广到 N 个人:

比特币网络需要所有试图参与者（矿工）都首先要付出挖矿的代价，进行算力消耗，
    越想拿到新区块的决定权，意味着抵押的算力越多。
一旦失败，这些算力都会被没收掉，成为沉没成本。
当网络中存在众多参与者时，个体试图拿到新区块决定权要付出的算力成本是巨大的，
    意味着进行一次作恶付出的代价已经超过可能带来的好处。

负反馈调节

比特币网络在设计上，很好的体现了负反馈的控制论基本原理:

比特币网络中矿工越多，系统就越稳定，比特币价值就越高，但挖到矿的概率会降低。
反之，网络中矿工减少，会让系统更容易导致被攻击，比特币价值越低，但挖到矿的概率会提高。

因此:
    比特币的价格理论上应该稳定在一个合适的值（网络稳定性也会稳定在相应的值），
    这个价格乘以挖到矿的概率，恰好达到矿工的收益预期。

共识机制

备注

传统的共识问题是考虑在一个相对封闭的体系中，存在好节点、坏节点，然后如何达成一致。对于比特币网络来说，因为它是开放的，网络质量也是完全无法保证的，导致问题更加复杂，难以依靠传统的一致性算法来实现。

比特币网络对共识进行了一系列的放宽，同时对参与共识进行了一系列的限制:

1. 不实现最终共识，理论上现有达成的任何结果都可能被推翻
    只是被推翻的可能性随着时间而指数级的下降，要付出的代价迅速上升
2. 达成共识的时间比较长，而且是按照块来进行阶段性的确认（快照），提高网络可用性
3. 通过进行 PoW 限制合法提案的个数，提高网络的稳定性

闪电网络

比特币的交易网络最为人诟病的一点便是交易性能:

全网每秒 7 笔的交易速度，远低于传统的金融交易系统；
同时，等待 6 个块的可信确认导致约 1 个小时的最终确认时间。

闪电网络的主要思路十分简单:

将大量交易放到比特币区块链之外进行。
该设计最早是 2015 年 2 月在论文《The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments》中提出

比特币的区块链机制自身提供了很好的可信保障，但是很慢；
另一方面考虑，对于大量的小额交易来说，是否真实需要这么高的可信性？

闪电网络通过智能合约来完善链下的交易渠道。

核心的概念主要有两个:

RSMC（Recoverable Sequence Maturity Contract）
HTLC（Hashed Timelock Contract）
前者解决了链下交易的确认问题，后者解决了支付通道的问题

RSMC

  • Recoverable Sequence Maturity Contract，中文可以翻译为“可撤销的顺序成熟度合同”

这个词很绕，其实主要原理很简单，就是类似准备金机制:

我们先假定交易双方之间存在一个“微支付通道”（资金池）。
双方都预存一部分资金到“微支付通道”里，之后每次交易，就对交易后的资金分配方案共同进行确认，同时签字作废旧的版本。
当需要提现时，将最终交易结果写到区块链网络中，被最终确认。可以看到，只有在提现时候才需要通过区块链。

另外，即使双方都确认了某次提现，首先提出提现一方的资金到账时间要晚于对方，这就鼓励大家尽量都在链外完成交易。

HTLC

  • 微支付通道是通过 Hashed Timelock Contract 来实现的，中文意思是“哈希的带时钟的合约”。

这个其实就是限时转账。理解起来其实也很简单:

通过智能合约，双方约定转账方先冻结一笔钱，并提供一个哈希值，
在一定时间内有人能提出一个字符串，使得它哈希后的值跟已知值匹配（实际上意味着转账方授权了接收方来提现）则这笔钱转给接收方

推广一步，甲想转账给丙，丙先发给甲一个哈希值。
甲可以先跟乙签订一个合同，如果你在一定时间内能告诉我一个暗语，我就给你多少钱。
乙于是跑去跟丙签订一个合同，如果你告诉我那个暗语，我就给你多少钱。
丙于是告诉乙暗语，拿到乙的钱，乙又从甲拿到钱。
最终达到结果是甲转账给丙。
这样甲和丙之间似乎构成了一条完整的虚拟的“支付通道”。

主页

索引

模块索引

搜索页面