由於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 不見不散！
