如何判断区块链项目真伪

区块链技术被包装得过于神秘，以至于经常有人跑来问我区块链是个什么东西、这个区块链项目靠不靠谱。为了省点口水，我简明扼要的敲几行字。为了说清楚这个问题，我们首先得了解区块链技术「是什么」。

CAP定理

一个区块链项目首先得是个分布式系统。

对于分布式系统，有一个「CAP定理」指出：一个分布式系统不可能同时保证「一致性」，「可用性」，「分区容忍性」三个特性同时成立，设计中往往需要弱化某个特性。

Consistency（一致性）：每次读取要么获得最近写入的数据，要么获得一个错误

Availability（可用性）：每次读取获得一个非错误响应，但不保证数据是最新的

Partition Tolerance（分区容忍性）：即使节点间因网络延迟或丢包产生数据丢失，整个系统依然能正常运行

常见的分布式系统设计

弱化一致性

对结果一致性不敏感的应用，可以允许在新版本上线后过一段时间才更新成功，期间不保证一致性。例如网站静态页面内容、实时性较弱的查询类数据库等，CouchDB、Cassandra 等为此设计。

弱化可用性

对结果一致性很敏感的应用，例如银行取款机，当系统故障时候会拒绝服务。MongoDB、Redis 等为此设计。

弱化分区容忍性

现实中，网络分区出现概率减小，但较难避免。某些关系型数据库、ZooKeeper 即为此设计。

区块链技术属于「弱化一致性」分类。很多时候人们发现实际上对一致性的要求并没有那么强，可以适当放宽一致性要求，降低系统实现的难度。例如在一定约束下实现所谓最终一致性（Eventual Consistency），即总会存在一个时刻（而不是立刻），系统达到一致的状态。

为了保障最终一致性，就会用到所谓的共识算法。

共识算法的演化

Paxos 与Raft

Paxos共识算法在1990年由Leslie Lamport提出，解决的是分布式系统中「消息有丢失或重复，但无错误消息」时，如何达成共识的问题（Paxos问题）。Raft是Paxos算法的一种简化实现。

Byzantine Fault Tolerant 算法

Byzantine Fault Tolerant算法在1999年由Castro和 Liskov提出，解决的是「可能有恶意节点和错误消息」时，如何达成共识的问题（拜占庭问题）。该算法只需要系统中有三分之二的节点是正常工作的，就可以保证一致性。

区块链技术的Proof of Work算法

同样是为了解决拜占庭问题，Proof of Work算法一边放宽了对最终一致性确认的需求，约定好大家都确认并沿着已知最长的链进行拓宽；另一边通过经济手段（需要达到系统总算力的二分之一以上）来惩罚恶意破坏者。

后来的各种 PoX 系列算法，也都是沿着这个思路进行改进。

明辨真假

了解清楚了区块链技术的原理和目的之后，我们就不难总结出辨别区块链项目真假的标准：

是否真的有必要做成分布式系统

有很多业务，吞吐量极小，甚至于单台机器就能搞定；同时也没有去中心化的需求，压根做不成分布式系统，或者实际上就是一个中心化的系统，跟区块链技术毫不沾边。

业务场景是否对实时一致性不敏感

有些业务对实时一致性非常敏感，比方说网游，一个副本里的不同玩家之间，数据是需要实时一致的。这种情况下，我们会选择牺牲CAP定理中的其他要素，跟区块链也沾不上边。

数据和实物间的一一对应关系靠什么保证

金融系统中，可以利用区块链技术进行数字化货币的更高效的结算，但与此同时，纸币的防伪技术也是不能少的。

很多所谓的「物联网区块链」项目，压根没有类似的「纸币防伪技术」，把标签一撕再一贴，就完成造假了。

区块链技术的防作弊机制，只能防范数据交换环节的篡改，不能监督任何「单点黑盒操作」