<commit_before>---
layout:     post
title:      "区块链简介二"
subtitle:   ""
date:       2018-01-22 09:00:00
author:     "xuguangjin"
header-img: "img/post-bg-02.jpg"
---

## 共识算法
>君子和而不同，小人同而不和

共识机制的源头可以用两个传统问题来区别，一类是“类两军问题”，一个是我们之前讨论过的“拜占庭将军问题”。两者的本质区别在于，拜占庭里存在作恶问题，而两军问题是单纯的共识问题
- 类两军问题：古代有两个相距很远的军队要传递信息，蓝军派遣一个信使去跟红军说：有本事把意大利炮拿过来！红军收到后回复蓝军说：收到指令。蓝军要给出确认答复：知道你收到指令了！红军继续给出答复：知道你知道我知道指令了！
- 拜占庭将军问题：略

PoW作为比特币里最经典的设计，过去已经描述，本次暂且不表。下面我们只介绍两个共识算法，PoS（Proof of Stake）和Paxos。

#### Paxos
Paxos 问题是指分布式的系统中存在故障（fault），但不存在恶意（corrupt）节点场景（即可能消息丢失或重复，但无错误消息）下的共识达成（Consensus）问题。因为最早是 Leslie Lamport 用 Paxon 岛的故事模型来进行描述而命名。Paxos 被广泛应用在ZooKeeper 等系统中Lamport 因此获得了 2013 年度图灵奖。

故事背景是古希腊 Paxon 岛上的多个法官在一个大厅内对一个议案进行表决，如何达成统一的结果。他们之间通过服务人员来传递纸条，但法官可能离开或进入大厅，服务人员可能偷懒去睡觉。简单的描述，问题就是
* 我们要通过民主方式做决议
* 提议的人可能故障不干活，投票的人也可能出故障不干活
* 如何在存在故障的情况下，只要51%的人在干活，就能做出最终决议

**两阶段的提交**
- ** 准备阶段**：提案者发送自己计划提交的提案的编号到多个接受者，试探是否可以锁定多数接受者的支持。接受者时刻保留收到过提案的最大编号和接受的最大提案。如果收到的提案号比目前保留的最大提案号还大，则返回自己已接受的提案值（如果还未接受过任何提案，则为空）给提案者，更新当前最大提案号，并说明不再接受小于最大提案号的提案。
- **提交阶段**：提案者如果收到大多数的回复（表示大部分人听到它的请求），则可准备发出带有刚才提案号的接受消息。如果收到的回复中不带有新的提案，说明锁定成功，则使用自己的提案内容；如果返回中有提案内容，则替换提案值为返回中编号最大的提案值。如果没收到足够多的回复，则需要再次发出请求。接受者收到接受消息后，如果发现提案号不小于已接受的最大提案号，则接受该提案，并更新接受的最大提案。
- 一旦多数接受了共同的提案值，则形成决议，成为最终确认的提案。

#### PoS
权益证明（Proof of Stake，简称PoS）由Quantum Mechanic 2011年在比特币论坛讲座上首先提出，后经Peercoin（点点币）和NXT（未来币）以不同思路实现。
**PoS的主要理念是节点记账权的获得难度与节点持有的权益成反比**，相比PoW，其在一定程度上减少了数学运算带来的资源消耗，性能也得到了相应的提升，但依然是基于哈希运算，竞争获取记账权的方式，可监管性弱。该共识机制的容错性和PoW相同。它是PoW的一种升级，根据每个节点所占代币的比例和时间，等比例地降低挖矿难度，从而加快找到随机数的速度。

PoS的优点：在一定程度上缩短了共识达成的时间；不再需要大量消耗能源去挖矿。
PoS的缺点：还是需要挖矿，本质上没有解决商业应用的痛点

#### 小结
直接说结论，第二代区块链无论如何改进，都无法逃脱PoW的根基带来的宿命。PoW带来的资源浪费是致命且不可或缺的，没有资源浪费就没有稳定性，存在资源浪费就会带来效率问题（需要长时间等待达成共识，且存在海量重复运算或无效运算）。

本节内容引用
[《区块链技术指南》](https://yeasy.gitbooks.io/blockchain_guide/content/distribute_system/paxos.html)，
[《区块链数字货币的9种共识机制比较》](https://zhuanlan.zhihu.com/p/32585236) 作者：刘杨，来源：知乎，著作权归作者所有。

## 零知识证明
> 知之为知之，不知为不知，是知也

之前我们也提到过merkle tree，也算是一种零知识证明，用途是不拿到所有区块的情况下证明某一个区块的有效性。在以太坊中，区块的组合方式进行了更为优化的处理，在更大的程度上降低了客户端对区块的需求。
<commit_msg>Update 2018-01-22-blockchain2.markdown<commit_after>---
layout:     post
title:      "区块链简介二"
subtitle:   ""
date:       2018-01-22 09:00:00
author:     "xuguangjin"
header-img: "img/post-bg-02.jpg"
---

## 共识算法
>君子和而不同，小人同而不和

共识机制的源头可以用两个传统问题来区别，一类是“类两军问题”，一个是我们之前讨论过的“拜占庭将军问题”。两者的本质区别在于，拜占庭里存在作恶问题，而两军问题是单纯的共识问题
- 类两军问题：古代有两个相距很远的军队要传递信息，蓝军派遣一个信使去跟红军说：有本事把意大利炮拿过来！红军收到后回复蓝军说：收到指令。蓝军要给出确认答复：知道你收到指令了！红军继续给出答复：知道你知道我知道指令了！
- 拜占庭将军问题：略

PoW作为比特币里最经典的设计，过去已经描述，本次暂且不表。下面我们只介绍两个共识算法，PoS（Proof of Stake）和Paxos。

#### Paxos
Paxos 问题是指分布式的系统中存在故障（fault），但不存在恶意（corrupt）节点场景（即可能消息丢失或重复，但无错误消息）下的共识达成（Consensus）问题。因为最早是 Leslie Lamport 用 Paxon 岛的故事模型来进行描述而命名。Paxos 被广泛应用在ZooKeeper 等系统中Lamport 因此获得了 2013 年度图灵奖。

故事背景是古希腊 Paxon 岛上的多个法官在一个大厅内对一个议案进行表决，如何达成统一的结果。他们之间通过服务人员来传递纸条，但法官可能离开或进入大厅，服务人员可能偷懒去睡觉。简单的描述，问题就是
* 我们要通过民主方式做决议
* 提议的人可能故障不干活，投票的人也可能出故障不干活
* 如何在存在故障的情况下，只要51%的人在干活，就能做出最终决议

**两阶段的提交**
- **准备阶段**：提案者发送自己计划提交的提案的编号到多个接受者，试探是否可以锁定多数接受者的支持。接受者时刻保留收到过提案的最大编号和接受的最大提案。如果收到的提案号比目前保留的最大提案号还大，则返回自己已接受的提案值（如果还未接受过任何提案，则为空）给提案者，更新当前最大提案号，并说明不再接受小于最大提案号的提案。
- **提交阶段**：提案者如果收到大多数的回复（表示大部分人听到它的请求），则可准备发出带有刚才提案号的接受消息。如果收到的回复中不带有新的提案，说明锁定成功，则使用自己的提案内容；如果返回中有提案内容，则替换提案值为返回中编号最大的提案值。如果没收到足够多的回复，则需要再次发出请求。接受者收到接受消息后，如果发现提案号不小于已接受的最大提案号，则接受该提案，并更新接受的最大提案。
- 一旦多数接受了共同的提案值，则形成决议，成为最终确认的提案。

#### PoS
权益证明（Proof of Stake，简称PoS）由Quantum Mechanic 2011年在比特币论坛讲座上首先提出，后经Peercoin（点点币）和NXT（未来币）以不同思路实现。
**PoS的主要理念是节点记账权的获得难度与节点持有的权益成反比**，相比PoW，其在一定程度上减少了数学运算带来的资源消耗，性能也得到了相应的提升，但依然是基于哈希运算，竞争获取记账权的方式，可监管性弱。该共识机制的容错性和PoW相同。它是PoW的一种升级，根据每个节点所占代币的比例和时间，等比例地降低挖矿难度，从而加快找到随机数的速度。

PoS的优点：在一定程度上缩短了共识达成的时间；不再需要大量消耗能源去挖矿。
PoS的缺点：还是需要挖矿，本质上没有解决商业应用的痛点

#### 小结
直接说结论，第二代区块链无论如何改进，都无法逃脱PoW的根基带来的宿命。PoW带来的资源浪费是致命且不可或缺的，没有资源浪费就没有稳定性，存在资源浪费就会带来效率问题（需要长时间等待达成共识，且存在海量重复运算或无效运算）。

本节内容引用
[《区块链技术指南》](https://yeasy.gitbooks.io/blockchain_guide/content/distribute_system/paxos.html)，

[《区块链数字货币的9种共识机制比较》](https://zhuanlan.zhihu.com/p/32585236) 作者：刘杨，来源：知乎，著作权归作者所有。

## 零知识证明
> 知之为知之，不知为不知，是知也

之前我们也提到过merkle tree，也算是一种零知识证明，用途是不拿到所有区块的情况下证明某一个区块的有效性。在以太坊中，区块的组合方式进行了更为优化的处理，在更大的程度上降低了客户端对区块的需求。

{'fraction_non_alphanumeric': 0.1143274142544393, 'fraction_numerical': 0.01921673558744831, 'mean_word_length': 12.798657718120806, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 7, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2962480', 'n_tokens_mistral': 3653, 'n_tokens_neox': 4375, 'n_words': 127}