Build A Decentralized Monetary System
去中心化货币系统
if central bank plans to issue digital currency, it's intuitive to refer to the characteristic of cash.
如果央行计划发行数字货币，那么提到现金的特性是很直观的。
- Counterfeit Resistance: Difficult to forge, unalterable.
- Uniqueness: Non-reproducible.
1.抗伪性：难以伪造，不可更改。
2.唯一性：不可重造。
Counterfeit resistance can be effectively addressed through a public-private key system.
可以通过公钥-私钥系统有效解决防伪问题 ：签名 & 验签。
Uniqueness is crucial because digital currency, as a file, can be infinitely copied, and the inability to ensure uniqueness can lead to double-spending attacks, where a single currency is spent multiple times.
唯一性至关重要，因为数字货币 作为一个文件可以无限复制，而无法确保唯一性可能会导致双花攻击，即一种货币被多次花费。
Maintaining the uniqueness of currency, the solution for centralized monetary systems is centralized accounting, which preserves the relationship between currency and holders.
However, this approach has the drawback of requiring confirmation from the central bank system for each transaction.
保持货币的唯一性，集中货币系统的解决方案是集中会计，它保留了货币和持有人之间的关系。--- 央行记录每个货币在谁的名下，可以防范双花攻击。
然而，这种方法的缺点是需要中央银行系统对每笔交易进行确认。
The solution for decentralized monetary systems is blockchain technology.
去中心化货币系统的解决方案是区块链技术。
┌───────────┐ ┌──────────────┐ ┌─────────────┐
│ │ │ │ │ │
┌─────────────┼────┐ ┌┼────▼──────┐ ┌─┼─────▼──────┐ ┌─┼────────────┐
│ create coin │ │ │A┌──►B(5) │ │ B┌───►C(2) │ │ C────►E(7) │
│ ▼ │ │ │ │ │ │ │ │ │ │
│ ─────►A(10)│◄────┤ │ │◄────┤ │ │◄───┤ │ │
│ │ │ └──►C(5) │ │ └───►D(3) │ │ │ │
│ │ │ signed by A│ │ signed by B │ │ │signed by C │
└──────────────────┘ └─────▲──────┘ └──────────────┘ └─┼────────────┘
│ │
│ │
└──────────────────────────────────┘
create coin : 铸币
箭头：往左追溯的这些箭头也是 Hash指针，指向前面的某个交易，
表示币的来源 （之前那堂课说的Hash指针是指向上一个区块的Hash指针）。
注意： 这个例子中，好像每个区块只有一个交易，但实际系统中每个区块可以有很多交易，
这些交易组织成Merkle tree。
Every Bitcoin transaction includes inputs, outputs, and signature.
每笔比特币交易都包括输入、输出和签名。
1. Input section:
- 1.1. Source of the coins: It traces the origin transaction of the coins to confirm the transaction's source, preventing the same currency from being spent multiple times.
1.1. 币源（发款者）：追踪币源交易，确认交易来源，防止同币多次消费。指向交易的Hash指针。
- 1.2. Sender's public key : Being able to cross-verify with the recipient's public key hash from the output part of the transaction where the coin originates ensures that the public key has not been forged.
1.2. 币源（发款者）的公钥 ：确保此公钥没有被伪造的方法是：检查此公钥 和 1.1.币源指向的交易（此发款者在它作为收款者的那笔交易）中的输出部分的公钥哈希。进行哈希值校验。 实践中会把本次交易的输入脚本和那段交易的输出脚本拼接起来执行，无错则成功。
2. Output section:
Output section includes the recipient's public key hash;
Output 部分包括币目的地（收款者的公钥哈希值） 即 收款人的账号地址;
3. Signature:
The sender uses his private key to sign the transaction.
币源（发款者）签发的签名：发款者使用他的私钥针对交易进行签名。
Consensus Protocol
比特币共识协议
每个区块 分成 block header和block body两部分。
block header是一些宏观点的信息, block body 是含有交易列表。
block header | block body
{ | {
version | transaction list
hash of previous block header | }
Merkle root hash |
target |
nonce |
}
取哈希指针的时候是把这个block header的全部域都取哈希，block body是没做这个区块之间的哈希指针的。header里的这个成员Merkle Root Hash就已经能够保证了这个block body的 transaction list是不被篡改的。
刚才我们的讨论呢还有一个简化的假设: 讨论中好像是每个节点都需要验证所有的交易。
实际当中呢系统中的节点分为全节点和轻节点。大多数节点是轻节点。
Full node & Light node。
- Fully validating node
- Light weight node (only save infos of block headers)
轻节点 没有办法独立验证 交易的合法性。比如它没有交易信息，它没法自己验证双花攻击。
轻节点没有参与区块链的构造和维护。 它只是利用了区块链的一些信息做一些查询之类的。
区块链是个去中心化的账本，那既然是个账本，账本的内容得有一个统一的说法。否则的话呢我记的账跟你记的账不一样，那最后按哪个账本来算呢。用我们分布式系统的术语来说，叫做账本的内容要取得分布式的共识
分布式共识呢一个比较简单的例子就是分布式的哈希表，比如系统里有很多台机器共同维护一个全局的哈希表。那么这里呢需要取得共识的内容是什么，比如说有的人在我这台机器上插入一个key: value 对。’Xiao‘这个key对应的value是12345。
那别人在另一台机器上去读的时候，也要能把这个读出来，这叫一个全局的哈希表。
关于这个分布式共识呢，有很多的理论研究，学术界研究了很多年，分布式系统最著名的一个不可能结论就是 FLP impossibility result。这三个字母是三个作者的姓的开头字母，都是分布式系统的专家。他们的结论是什么：在一个异步的系统里，网络传输时延没有上限。
那么即使只有一个成员是有问题的, faulty。那么也不可能取得共识，这个结论是听上去很悲观的。
如果对系统的网络传输是异步的，网络时延没有上限
哪怕系统中有一个成员是faulty的，你也没法达成共识。
还有一个结论比较著名的
叫做CAP 理论。这cap这三个字母呢是指分布式系统的三个性质。三个我们想要的性质：
C 是consistency
A 是availability
P 是partition tolerance
这个CAP theorem是说呀任何一个分布式系统，比如说我们这个分布式哈希表这三个性质当中最多只能满足两个，不可能三个性质都满足，就比如说如果你想要的是consistency和aviability，你就得不到partition tolerance。如果你想有availability和partition tolerance，别人可以用的就要牺牲consistency，就不能保证系统状态一定是一致的。这就是CAP, 分布式共识的一个比较著名的协议Paxos,balabala ...... (因为时间关系，就不讲这些分布式理论了) 这些理论呢跟比特币的实际应用关系是不大的，下面呢我们看一下比特币中的共识协议
In the Bitcoin system, due to the potential presence of malicious nodes, it is necessary to determine which node has the right to write transactions into the blockchain.
Bitcoin employs a voting mechanism based on computational power rather than account numbers to prevent Sybil attacks.
在比特币系统中，由于可能存在恶意节点，因此有必要确定哪个节点有权将交易写入区块链。比特币采用基于计算能力的投票 而不是 帐号的投票机制来防止 女巫攻击 Sybil attacks。 疯狂创建账号，如果使用的投票机制，比如只要产生到51%的节点，就可以一定操纵投票结果。
简单的账号投票机制 是不行的。比特币系统当中用了一个很巧妙的机制来解决这个问题
也是投票，但不是按照账户的数目投票，而是用计算力来投票，每个节点可以在本地组装一个候选区块，把它认为合法的交易放到这个区块里，然后就开始尝试各种nonce值。
大家还记得我们以前讲的那个 computational puzzle 是什么意思吗
其中 block header有个成语是 4byte的 nonce。求出来这个哈希值落在指定范围内，就获得记账权。
所谓的记账权就是往比特币这个去中心化的账本里写入下一个区块的权利
只有找到这个nonce获得记账权的节点，才有权利发布下一个区块，那么其他节点收到这个区块之后呢，要验证一下这个区块的合法性。比如先验证一下这个block header的内容填的对不对，检查一下这个nBits域设置的是不是符合比特币协议中规定的难度要求，然后查一下这个nonce是否使得整个block header的哈希是小于等于这个目标阈值的。就换句话说你发布一个区块，1.验证你是不是真的获得了记账权。 接着看一下 block body里的 交易列表，检查 是否每个交易都合法： 2.合法的签名 3.用的币在之前都没有被花费过。
This computational power-based voting, also known as Proof of Work, involves brute-forcing a system-preset random number nonce, with the node that solves it first gaining the right to write into the block and receiving BTC rewards. The rewards started at 50 btc per block and halved precisely every 210,000 blocks(approximately every four years)
这种基于计算能力的投票，也称为工作量证明 Proof of Work，涉及对系统预设的随机数随机数进行暴力破解，首先解决该随机数的节点获得写入区块的权利(记账权)并获得 BTC 奖励。奖励从每个区块 50 btc 开始，每 210,000 个区块（大约每四年）减半。
这个区块里所有的交易都是合法的，我们应不应该接受它，这里的区块合法指的是：每个交易都是有合法的签名，用的币以前都没有被花过，所以每个交易都是合法的，block header也符合要求，每个域设置都是合法的。但是它是插在中间一个位置，它不插在后面，它插在中间。
比如交易是这样的：插上以后，有两个分支，这里A->B转款，插过来的这个是A->A'自己给自己转款。这明显不合理，双花攻击。但是从这两个区块往前回溯，却是检测不到双花攻击的。虽然最长
Additionally, to prevent forking attacks, it is stipulated that only blocks on the longest valid chain are accepted, and blocks on non-longest valid chains are discarded.
此外，为防止分叉攻击，规定只接受最长有效链上的区块，不最长有效链上的区块被丢弃。
┌───────┐◄──┬───────┐
┌───┤ │ │ │
┌──────┐◄──┬──────┐ ◄───┬──────┐◄───┬──────┐ │ └───────┘ └───────┘
│C->A │ │ │ ◄┐ │ A->B │ │ │◄┘
└──────┘ └──────┘ │ └──────┘ └──────┘◄┐ ┌───────┐
│ └───┼ │
│ └───────┘
└──┬──────┐ orphan block
│A->A' │
└──────┘
