区块链技术被包装得过于神秘,以至于经常有人跑来问我区块链是个什么东西。为了省点口水,我简明扼要的敲几行字。
区块链首先得是一个分布式系统。
分布式系统有个「CAP定理」指出,一个分布式系统不可能同时保证「一致性」,「可用性」,「分区容忍性」三个特性同时成立,设计中往往需要弱化对某个特性的保证。
Consistency(一致性):每次读取要么获得最近写入的数据,要么获得一个错误
Availability(可用性):每次读取获得一个非错误响应,但不保证数据是最新的
Partition Tolerance(分区容忍性):即使节点间因网络延迟或丢包产生数据丢失,整个系统依然能正常运行
几种常见的应用场景:
弱化一致性
对结果一致性不敏感的应用,可以允许在新版本上线后过一段时间才更新成功,期间不保证一致性。例如网站静态页面内容、实时性较弱的查询类数据库等,CouchDB、Cassandra 等为此设计。
弱化可用性
对结果一致性很敏感的应用,例如银行取款机,当系统故障时候会拒绝服务。MongoDB、Redis 等为此设计。
弱化分区容忍性
现实中,网络分区出现概率减小,但较难避免。某些关系型数据库、ZooKeeper 即为此设计。
区块链技术属于上述三种场景的「弱化一致性」分类。
很多时候人们发现实际上对一致性的要求并没有那么强,可以适当放宽一致性要求,降低系统实现的难度。例如在一定约束下实现所谓最终一致性(Eventual Consistency),即总会存在一个时刻(而不是立刻),系统达到一致的状态。
为了保障最终一致性,就会用到所谓的共识算法。
各种共识算法
Paxos 与Raft
Paxos共识算法由Leslie Lamport于1990年提出,解决的是分布式系统中「消息有丢失或重复,但无错误消息」时,如何达成共识的问题(Paxos问题)。Raft是Paxos算法的一种简化实现。
Byzantine Fault Tolerant 算法
Byzantine Fault Tolerant算法由Castro和 Liskov在1999年提出,解决的是「可能有恶意节点和错误消息」时,如何达成共识的问题(拜占庭问题)。该算法只需要系统中有三分之二的节点是正常工作的,就可以保证一致性。
区块链技术的Proof of Work算法
同样是为了解决拜占庭问题,Proof of Work算法一边放宽了对最终一致性确认的需求,约定好大家都确认并沿着已知最长的链进行拓宽;另一边通过经济手段惩罚恶意破坏者(需要达到系统总算力的二分之一以上)。
后来的各种 PoX 系列算法,也都是沿着这个思路进行改进。
了解清楚了区块链技术在计算机学中的位置之后,我们再来看,怎么分辨一个区块链项目是真是假:
是否真的有必要做成分布式系统
有很多业务,吞吐量极小,一个集群甚至单台机器就搞定了;同时也没有去中心化的需求,压根做不成分布式系统,更无从和区块链技术沾边。
业务场景是否对实时一致性不敏感
有些业务对实时一致性非常敏感,比方说网游,一个副本里的不同玩家之间,数据是需要实时一致的。这种情况下,我们会选择牺牲CAP定理中的其他要素,跟区块链也沾不上边。
数据和实物间的一一对应关系靠什么保证
金融系统中,可以利用区块链技术进行数字化货币的更高效的结算,但与此同时,纸币的防伪技术也是不能少的。
很多所谓「物联网区块链」项目,压根没有相对应的「纸币防伪技术」,把标签一撕再一贴,就完成造假了。
Proof of Work机制是否冗余
很多实物,其制造过程本身就已经是Proof of Work了
防作弊只能防范数据交换环节的篡改,不能监督任何单点黑盒操作
领取专属 10元无门槛券
私享最新 技术干货