1 CAP在公式设计中的展现
- CAP定理：任何一个分布式系统中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得
- 一致性：在分布式系统中所有的数据备份，是否在同一时间是同样的值
- 可用性：在集群中一部分节点故障以后，集群整体是否还能响应读写请求
- 分区容错性：系统不能在时限内达成一致，就发生了分区。所以，对时限的要求就是分区容错性
- CAP定理对区块链共识设计的作用
- 区块链作为系统设计，也是属于分布式系统
- 单机设计共识没有分区容错性的体现，所以单机设计共识很大程度上会有问题
- 由于一定要保证分区容错性，所以只能在C和A二选一就有了两类共识
- 类BFT：一致性，每个时间节点是finality的
- POX：可用性，每个时间节点都是possibility的
- 有没有保证CA的情况
- 假如你设计了一个单机共识，又觉得特别好
- 主备同步了解一下
- 当没有故障时，系统正常处理请求并且返回一致的结果。出现故障后，首先把所有请求切换到正常机器，故障机器下线。接着人工恢复故障机器上的数据，保证数据一致性。最后机器正常上线，恢复系统容量。
- 带来的就是中心节点来run整个事情
2 链式和拜占庭式设计的优劣
- 链式设计的优点：因为没有保证一致性，只要最终一致
- 可以很去中心化：POW
- 可以很低功耗：POS
- 可以很有创造性：POX
- BFT类设计的有点：
- 保证了一致性，所以适合商业场景
- finality用来保障不分叉，提高商业场景的稳定性
- 链式与BFT式的缺点
- 链式：缺少finality，所以经常会有分叉，需要解决分叉问题
- BFT式：因为保障一致性，所以会有相互的通信，节点数量高了会有通信风暴
3 POW、POS和POX在设计中的侧重点
- POW：如何设计一个新的抗ASIC的POW
- POS：如何设计一个合理的队列方式
- POX：如何保障这个X factor是可以证明以及被别人证明的
4 如何工程化设计融合型共识
- 链式共识：融合设计需要一定的finality加入
- 类BFT共识：融合设计需要一定的成本加入
