SunlightDB区块链共识机制与SunlightCoin预告

由于P2P网络存在的网络延迟问题，各个节点所观察到的事务先后顺序不可能完全一致。因此区块链系统需要设计一种机制对在差不多时间内发生的事务的先后顺序进行共识。这种对一个时间窗口内的事务的先后顺序达成共识的算法被称为“共识机制”。

大部分区块链商业应用并不需要网络代币，常见的代币类型的共识算法并不适合商业应用。如以下几种：

工作量证明机制(Proof of Work, POW)
就是大家熟悉的挖矿，通过与或运算，计算出一个满足规则的随机数，即获得本次记账权，发出本轮需要记录的数据，全网其它节点验证后一起存储；
优点：完全去中心化，节点自由进出；
缺点：目前Bitcoin已经吸引全球大部分的算力，其它再用Pow共识机制的区块链应用很难获得相同的算力来保障自身的安全；挖矿造成大量的资源浪费；共识达成的周期较长，不适合商业应用。

股权证明机制(Proof of Stake, POS)

POW的一种升级共识机制；根据每个节点所占代币的比例和时间；等比例的降低挖矿难度，从而加快找随机数的速度。
优点：在一定程度上缩短了共识达成的时间，对节点性能要求低，达成共识时间短（网络环境好的话可实现毫秒级）
缺点：还是需要挖矿，本质上没有解决商业应用的痛点。

授权股权证明机制(DPOS)

类似于董事会投票，持币者投出一定数量的节点，代理他们进行验证和记账。
优点：大幅缩小参与验证和记账节点的数量，可以达到秒级的共识验证；减少记账节点规模，属于弱中心化，效率提高。

缺点：整个共识机制还是依赖于代币，很多商业应用是不需要代币存在的。牺牲了去中心化的概念，不适合公有链。

基于 SunlightDB 可以选择以下几种非代币类共识算法。

Paxos 算法
Paxos被用于分布式系统中典型的例子就是Zookeeper，他是第一个被证明的共识算法，其原理基于两阶段提交并扩展。
Paxos算法中将节点分为三种类型：proposer：提出一个提案，等待大家批准为结案。往往是客户端担任该角色acceptor：负责对提案进行投票。往往是服务端担任该角色learner：被告知结案结果，并与之统一，不参与投票过程。可能为客户端或服务端基本过程包括proposer 提出提案，先争取大多数 acceptor 的支持，超过一半支持时，则发送结案结果给所有人进行确认。

一个潜在的问题是 proposer 在此过程中出现故障，可以通过超时机制来解决。极为凑巧的情况下，每次新的一轮提案的proposer 都恰好故障，系统则永远无法达成一致（概率很小）。Paxos 能保证在超过50%的正常节点存在时，系统能达成共识。

Raft 算法
Raft算法是对Paxos算法的一种简单实现。

它包括三种角色：leader、candiate和 follower，其基本过程为：Leader 选举：每个 candidate 随机经过一定时间都会提出选举方案，最近阶段中得票最多者被选为 leader同步log：leader 会找到系统中 log 最新的记录，并强制所有的 follower 来刷新到这个记录，这里的log指的是各种事件的发生记录。

Pool 验证池
基于传统的分布式一致性技术，加上数据验证机制。
优点：不需要代币也可以工作，在成熟的分布式一致性算法基础上，实现秒级共识验证。
缺点：去中心化程度不如Bictoin；更适合多方参与的多中心商业模式。

SunlightDB 插件数据服务

从根本上说，SunlightDB不仅仅是一套区块链数据库系统，更确切的说它是一个多功能数据服务平台，除了最基本的数据功能之外，基于丰富的插件它也提供了很多额外的功能服务，同时SunlightDB插件服务是可以不断扩展的。区块链的共识机制属于应用层问题，分布式数据库一致性算法应该处于区块链共识模型的下面一层。
因此采用哪一种共识机制与用户的业务类型有关，SunlightDB 采用插件的方式满足用户不同业务特性的需要。

对于那些需要或者说可以，使用网络代币的区块链应用......

2017年12月12日，SunlightCoin 不见不散！