區塊鏈的投票演算法實現
① 區塊鏈有幾種共識演算法
Ripple Consensus(瑞波共識演算法)
使一組節點能夠基於特殊節點列表達成共識。初始特殊節點列表就像一個俱樂部,要接納一個新成員,必須由51%的該俱樂部會員投票通過。共識遵循這核心成員的51%權力,外部人員則沒有影響力。由於該俱樂部由「中心化」開始,它將一直是「中心化的」,而如果它開始腐化,股東們什麼也做不了。
5、PBFT:Practical Byzantine Fault Tolerance(實用拜占庭容錯演算法)
PBFT是一種狀態機副本復制演算法,即服務作為狀態機進行建模,狀態機在分布式系統的不同節點進行副本復制。每個狀態機的副本都保存了服務的狀態,同時也實現了服務的操作。將所有的副本組成的集合使用大寫字母R表示,使用0到|R|-1的整數表示每一個副本。為了描述方便,假設|R|=3f+1,這里f是有可能失效的副本的最大個數。盡管可以存在多於3f+1個副本,但是額外的副本除了降低性能之外不能提高可靠性。
PBFT演算法主要特點如下:客戶端向主節點發送請求調用服務操作;主節點通過廣播將請求發送給其他副本;所有副本都執行請求並將結果發回客戶端;客戶端需要等待f+1個不同副本節點發回相同的結果,作為整個操作的最終結果。
② 莫斯科市採用以太坊區塊鏈技術進行投票的目的
第一個真正的里程碑應該是一場地方選舉,而最終目標則是全國性選舉。
在西方國家民眾對政府機關的信任度正以驚人的速度下滑之際,普京領導下的俄羅斯政府正採取措施試圖加強民眾對其系統的信任。
俄羅斯的民主制度已經歷史悠久,但是蘇聯解體遺留的腐敗餘毒以及之後葉利欽執政時代遭到西方世界的掠奪仍是一個大問題。
俄羅斯推出這一系統恰逢「美國特別檢察官穆勒以干涉2016年美國總統大選的理由對13個俄羅斯人和3個俄羅斯實體機構正式提起訴訟,引起全球轟動」的時候。對於反民主勢力而言,這一事件令穆勒看起來更像可利用的傻瓜。
在華盛頓的大佬們仍不滿和抱怨這個自己不喜歡的選舉結果的時候,俄羅斯正展開行動,確保約瑟夫·斯大林最經常被人引用的格言之一——「投票的人決定不了什麼,計票的人決定了一切」不適用於俄羅斯。
③ 區塊鏈技術的應用實例有哪些
區塊鏈技術在投票方面的應用
快上在全國范圍率先將區塊鏈技術應用到投票領域,有效解決投票數據信任問題,為活動方提供最真實有效的數據,保障真實投票用戶權益,同時讓區塊鏈技術「親民化」,讓普通大眾在生活服務領域,快速感知、享受區塊鏈技術帶來的便利。
區塊鏈技術在數字資產登記方面的應用
金主數字資產服務平台率先使用區塊鏈技術,該技術是一種全球通用的分布式賬本技術,具有可追溯、不可篡改、不可偽造的特性。平台的數字資產均來自規范的數字資產發行方,資產價值通過公開市場來決定,避免導致價值高估或低估。
區塊鏈技術在金融行業的應用
螞蟻金服自主可控的金融級商用區塊鏈平台已經在多個社會和商業應用場景實現多機構多國全球部署,螞蟻區塊鏈平台交易支持秒級確認,共識機制使用高效的並行共識演算法,保障了區塊鏈平台的高性能,螞蟻區塊鏈已經有了多個生產級落地應用,將領先的技術運用到民生、商業、金融等各個領域。
④ 區塊鏈 --- 共識演算法
PoW演算法是一種防止分布式服務資源被濫用、拒絕服務攻擊的機制。它要求節點進行適量消耗時間和資源的復雜運算,並且其運算結果能被其他節點快速驗算,以耗用時間、能源做擔保,以確保服務與資源被真正的需求所使用。
PoW演算法中最基本的技術原理是使用哈希演算法。假設求哈希值Hash(r),若原始數據為r(raw),則運算結果為R(Result)。
R = Hash(r)
哈希函數Hash()的特性是,對於任意輸入值r,得出結果R,並且無法從R反推回r。當輸入的原始數據r變動1比特時,其結果R值完全改變。在比特幣的PoW演算法中,引入演算法難度d和隨機值n,得到以下公式:
Rd = Hash(r+n)
該公式要求在填入隨機值n的情況下,計算結果Rd的前d位元組必須為0。由於哈希函數結果的未知性,每個礦工都要做大量運算之後,才能得出正確結果,而算出結果廣播給全網之後,其他節點只需要進行一次哈希運算即可校驗。PoW演算法就是採用這種方式讓計算消耗資源,而校驗僅需一次。
PoS演算法要求節點驗證者必須質押一定的資金才有挖礦打包資格,並且區域鏈系統在選定打包節點時使用隨機的方式,當節點質押的資金越多時,其被選定打包區塊的概率越大。
POS模式下,每個幣每天產生1幣齡,比如你持有100個幣,總共持有了30天,那麼,此時你的幣齡就為3000。這個時候,如果你驗證了一個POS區塊,你的幣齡就會被清空為0,同時從區塊中獲得相對應的數字貨幣利息。
節點通過PoS演算法出塊的過程如下:普通的節點要成為出塊節點,首先要進行資產的質押,當輪到自己出塊時,打包區塊,然後向全網廣播,其他驗證節點將會校驗區塊的合法性。
DPoS演算法和PoS演算法相似,也採用股份和權益質押。
但不同的是,DPoS演算法採用委託質押的方式,類似於用全民選舉代表的方式選出N個超級節點記賬出塊。
選民把自己的選票投給某個節點,如果某個節點當選記賬節點,那麼該記賬節點往往在獲取出塊獎勵後,可以採用任意方式來回報自己的選民。
這N個記賬節點將輪流出塊,並且節點之間相互監督,如果其作惡,那麼會被扣除質押金。
通過信任少量的誠信節點,可以去除區塊簽名過程中不必要的步驟,提高了交易的速度。
拜占庭問題:
拜占庭是古代東羅馬帝國的首都,為了防禦在每塊封地都駐扎一支由單個將軍帶領的軍隊,將軍之間只能靠信差傳遞消息。在戰爭時,所有將軍必須達成共識,決定是否共同開戰。
但是,在軍隊內可能有叛徒,這些人將影響將軍們達成共識。拜占庭將軍問題是指在已知有將軍是叛徒的情況下,剩餘的將軍如何達成一致決策的問題。
BFT:
BFT即拜占庭容錯,拜占庭容錯技術是一類分布式計算領域的容錯技術。拜占庭假設是對現實世界的模型化,由於硬體錯誤、網路擁塞或中斷以及遭到惡意攻擊等原因,計算機和網路可能出現不可預料的行為。拜占庭容錯技術被設計用來處理這些異常行為,並滿足所要解決的問題的規范要求。
拜占庭容錯系統 :
發生故障的節點被稱為 拜占庭節點 ,而正常的節點即為 非拜占庭節點 。
假設分布式系統擁有n台節點,並假設整個系統拜占庭節點不超過m台(n ≥ 3m + 1),拜占庭容錯系統需要滿足如下兩個條件:
另外,拜占庭容錯系統需要達成如下兩個指標:
PBFT即實用拜占庭容錯演算法,解決了原始拜占庭容錯演算法效率不高的問題,演算法的時間復雜度是O(n^2),使得在實際系統應用中可以解決拜占庭容錯問題
PBFT是一種狀態機副本復制演算法,所有的副本在一個視圖(view)輪換的過程中操作,主節點通過視圖編號以及節點數集合來確定,即:主節點 p = v mod |R|。v:視圖編號,|R|節點個數,p:主節點編號。
PBFT演算法的共識過程如下:客戶端(Client)發起消息請求(request),並廣播轉發至每一個副本節點(Replica),由其中一個主節點(Leader)發起提案消息pre-prepare,並廣播。其他節點獲取原始消息,在校驗完成後發送prepare消息。每個節點收到2f+1個prepare消息,即認為已經准備完畢,並發送commit消息。當節點收到2f+1個commit消息,客戶端收到f+1個相同的reply消息時,說明客戶端發起的請求已經達成全網共識。
具體流程如下 :
客戶端c向主節點p發送<REQUEST, o, t, c>請求。o: 請求的具體操作,t: 請求時客戶端追加的時間戳,c:客戶端標識。REQUEST: 包含消息內容m,以及消息摘要d(m)。客戶端對請求進行簽名。
主節點收到客戶端的請求,需要進行以下交驗:
a. 客戶端請求消息簽名是否正確。
非法請求丟棄。正確請求,分配一個編號n,編號n主要用於對客戶端的請求進行排序。然後廣播一條<<PRE-PREPARE, v, n, d>, m>消息給其他副本節點。v:視圖編號,d客戶端消息摘要,m消息內容。<PRE-PREPARE, v, n, d>進行主節點簽名。n是要在某一個范圍區間內的[h, H],具體原因參見 垃圾回收 章節。
副本節點i收到主節點的PRE-PREPARE消息,需要進行以下交驗:
a. 主節點PRE-PREPARE消息簽名是否正確。
b. 當前副本節點是否已經收到了一條在同一v下並且編號也是n,但是簽名不同的PRE-PREPARE信息。
c. d與m的摘要是否一致。
d. n是否在區間[h, H]內。
非法請求丟棄。正確請求,副本節點i向其他節點包括主節點發送一條<PREPARE, v, n, d, i>消息, v, n, d, m與上述PRE-PREPARE消息內容相同,i是當前副本節點編號。<PREPARE, v, n, d, i>進行副本節點i的簽名。記錄PRE-PREPARE和PREPARE消息到log中,用於View Change過程中恢復未完成的請求操作。
主節點和副本節點收到PREPARE消息,需要進行以下交驗:
a. 副本節點PREPARE消息簽名是否正確。
b. 當前副本節點是否已經收到了同一視圖v下的n。
c. n是否在區間[h, H]內。
d. d是否和當前已收到PRE-PPREPARE中的d相同
非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的PREPARE消息,則向其他節點包括主節點發送一條<COMMIT, v, n, d, i>消息,v, n, d, i與上述PREPARE消息內容相同。<COMMIT, v, n, d, i>進行副本節點i的簽名。記錄COMMIT消息到日誌中,用於View Change過程中恢復未完成的請求操作。記錄其他副本節點發送的PREPARE消息到log中。
主節點和副本節點收到COMMIT消息,需要進行以下交驗:
a. 副本節點COMMIT消息簽名是否正確。
b. 當前副本節點是否已經收到了同一視圖v下的n。
c. d與m的摘要是否一致。
d. n是否在區間[h, H]內。
非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的COMMIT消息,說明當前網路中的大部分節點已經達成共識,運行客戶端的請求操作o,並返回<REPLY, v, t, c, i, r>給客戶端,r:是請求操作結果,客戶端如果收到f+1個相同的REPLY消息,說明客戶端發起的請求已經達成全網共識,否則客戶端需要判斷是否重新發送請求給主節點。記錄其他副本節點發送的COMMIT消息到log中。
如果主節點作惡,它可能會給不同的請求編上相同的序號,或者不去分配序號,或者讓相鄰的序號不連續。備份節點應當有職責來主動檢查這些序號的合法性。
如果主節點掉線或者作惡不廣播客戶端的請求,客戶端設置超時機制,超時的話,向所有副本節點廣播請求消息。副本節點檢測出主節點作惡或者下線,發起View Change協議。
View Change協議 :
副本節點向其他節點廣播<VIEW-CHANGE, v+1, n, C , P , i>消息。n是最新的stable checkpoint的編號, C 是 2f+1驗證過的CheckPoint消息集合, P 是當前副本節點未完成的請求的PRE-PREPARE和PREPARE消息集合。
當主節點p = v + 1 mod |R|收到 2f 個有效的VIEW-CHANGE消息後,向其他節點廣播<NEW-VIEW, v+1, V , O >消息。 V 是有效的VIEW-CHANGE消息集合。 O 是主節點重新發起的未經完成的PRE-PREPARE消息集合。PRE-PREPARE消息集合的選取規則:
副本節點收到主節點的NEW-VIEW消息,驗證有效性,有效的話,進入v+1狀態,並且開始 O 中的PRE-PREPARE消息處理流程。
在上述演算法流程中,為了確保在View Change的過程中,能夠恢復先前的請求,每一個副本節點都記錄一些消息到本地的log中,當執行請求後副本節點需要把之前該請求的記錄消息清除掉。
最簡單的做法是在Reply消息後,再執行一次當前狀態的共識同步,這樣做的成本比較高,因此可以在執行完多條請求K(例如:100條)後執行一次狀態同步。這個狀態同步消息就是CheckPoint消息。
副本節點i發送<CheckPoint, n, d, i>給其他節點,n是當前節點所保留的最後一個視圖請求編號,d是對當前狀態的一個摘要,該CheckPoint消息記錄到log中。如果副本節點i收到了2f+1個驗證過的CheckPoint消息,則清除先前日誌中的消息,並以n作為當前一個stable checkpoint。
這是理想情況,實際上當副本節點i向其他節點發出CheckPoint消息後,其他節點還沒有完成K條請求,所以不會立即對i的請求作出響應,它還會按照自己的節奏,向前行進,但此時發出的CheckPoint並未形成stable。
為了防止i的處理請求過快,設置一個上文提到的 高低水位區間[h, H] 來解決這個問題。低水位h等於上一個stable checkpoint的編號,高水位H = h + L,其中L是我們指定的數值,等於checkpoint周期處理請求數K的整數倍,可以設置為L = 2K。當副本節點i處理請求超過高水位H時,此時就會停止腳步,等待stable checkpoint發生變化,再繼續前進。
在區塊鏈場景中,一般適合於對強一致性有要求的私有鏈和聯盟鏈場景。例如,在IBM主導的區塊鏈超級賬本項目中,PBFT是一個可選的共識協議。在Hyperledger的Fabric項目中,共識模塊被設計成可插拔的模塊,支持像PBFT、Raft等共識演算法。
Raft基於領導者驅動的共識模型,其中將選舉一位傑出的領導者(Leader),而該Leader將完全負責管理集群,Leader負責管理Raft集群的所有節點之間的復制日誌。
下圖中,將在啟動過程中選擇集群的Leader(S1),並為來自客戶端的所有命令/請求提供服務。 Raft集群中的所有節點都維護一個分布式日誌(復制日誌)以存儲和提交由客戶端發出的命令(日誌條目)。 Leader接受來自客戶端的日誌條目,並在Raft集群中的所有關注者(S2,S3,S4,S5)之間復制它們。
在Raft集群中,需要滿足最少數量的節點才能提供預期的級別共識保證, 這也稱為法定人數。 在Raft集群中執行操作所需的最少投票數為 (N / 2 +1) ,其中N是組中成員總數,即 投票至少超過一半 ,這也就是為什麼集群節點通常為奇數的原因。 因此,在上面的示例中,我們至少需要3個節點才能具有共識保證。
如果法定仲裁節點由於任何原因不可用,也就是投票沒有超過半數,則此次協商沒有達成一致,並且無法提交新日誌。
數據存儲:Tidb/TiKV
日誌:阿里巴巴的 DLedger
服務發現:Consul& etcd
集群調度:HashiCorp Nomad
只能容納故障節點(CFT),不容納作惡節點
順序投票,只能串列apply,因此高並發場景下性能差
Raft通過解決圍繞Leader選舉的三個主要子問題,管理分布式日誌和演算法的安全性功能來解決分布式共識問題。
當我們啟動一個新的Raft集群或某個領導者不可用時,將通過集群中所有成員節點之間協商來選舉一個新的領導者。 因此,在給定的實例中,Raft集群的節點可以處於以下任何狀態: 追隨者(Follower),候選人(Candidate)或領導者(Leader)。
系統剛開始啟動的時候,所有節點都是follower,在一段時間內如果它們沒有收到Leader的心跳信號,follower就會轉化為Candidate;
如果某個Candidate節點收到大多數節點的票,則這個Candidate就可以轉化為Leader,其餘的Candidate節點都會回到Follower狀態;
一旦一個Leader發現系統中存在一個Leader節點比自己擁有更高的任期(Term),它就會轉換為Follower。
Raft使用基於心跳的RPC機制來檢測何時開始新的選舉。 在正常期間, Leader 會定期向所有可用的 Follower 發送心跳消息(實際中可能把日誌和心跳一起發過去)。 因此,其他節點以 Follower 狀態啟動,只要它從當前 Leader 那裡收到周期性的心跳,就一直保持在 Follower 狀態。
當 Follower 達到其超時時間時,它將通過以下方式啟動選舉程序:
根據 Candidate 從集群中其他節點收到的響應,可以得出選舉的三個結果。
共識演算法的實現一般是基於復制狀態機(Replicated state machines),何為 復制狀態機 :
簡單來說: 相同的初識狀態 + 相同的輸入 = 相同的結束狀態 。不同節點要以相同且確定性的函數來處理輸入,而不要引入一下不確定的值,比如本地時間等。使用replicated log是一個很不錯的注意,log具有持久化、保序的特點,是大多數分布式系統的基石。
有了Leader之後,客戶端所有並發的請求可以在Leader這邊形成一個有序的日誌(狀態)序列,以此來表示這些請求的先後處理順序。Leader然後將自己的日誌序列發送Follower,保持整個系統的全局一致性。注意並不是強一致性,而是 最終一致性 。
日誌由有序編號(log index)的日誌條目組成。每個日誌條目包含它被創建時的任期號(term),和日誌中包含的數據組成,日誌包含的數據可以為任何類型,從簡單類型到區塊鏈的區塊。每個日誌條目可以用[ term, index, data]序列對表示,其中term表示任期, index表示索引號,data表示日誌數據。
Leader 嘗試在集群中的大多數節點上執行復制命令。 如果復製成功,則將命令提交給集群,並將響應發送回客戶端。類似兩階段提交(2PC),不過與2PC的區別在於,leader只需要超過一半節點同意(處於工作狀態)即可。
leader 、 follower 都可能crash,那麼 follower 維護的日誌與 leader 相比可能出現以下情況
當出現了leader與follower不一致的情況,leader強制follower復制自己的log, Leader會從後往前試 ,每次AppendEntries失敗後嘗試前一個日誌條目(遞減nextIndex值), 直到成功找到每個Follower的日誌一致位置點(基於上述的兩條保證),然後向後逐條覆蓋Followers在該位置之後的條目 。所以丟失的或者多出來的條目可能會持續多個任期。
要求候選人的日誌至少與其他節點一樣最新。如果不是,則跟隨者節點將不投票給候選者。
意味著每個提交的條目都必須存在於這些伺服器中的至少一個中。如果候選人的日誌至少與該多數日誌中的其他日誌一樣最新,則它將保存所有已提交的條目,避免了日誌回滾事件的發生。
即任一任期內最多一個leader被選出。這一點非常重要,在一個復制集中任何時刻只能有一個leader。系統中同時有多餘一個leader,被稱之為腦裂(brain split),這是非常嚴重的問題,會導致數據的覆蓋丟失。在raft中,兩點保證了這個屬性:
因此, 某一任期內一定只有一個leader 。
當集群中節點的狀態發生變化(集群配置發生變化)時,系統容易受到系統故障。 因此,為防止這種情況,Raft使用了一種稱為兩階段的方法來更改集群成員身份。 因此,在這種方法中,集群在實現新的成員身份配置之前首先更改為中間狀態(稱為聯合共識)。 聯合共識使系統即使在配置之間進行轉換時也可用於響應客戶端請求,它的主要目的是提升分布式系統的可用性。
⑤ 現在有哪些投票軟體採用了區塊鏈技術呢
我也用過一部分投票軟體,不過我沒有看軟體用了什麼技術,看樓上的介紹感覺挺不錯的,等下就去了解一下區塊鏈相關的東西。
⑥ 深入了解區塊鏈的共識機制及演算法原理
所謂「共識機制」,是通過特殊節點的投票,在很短的時間內完成對交易的驗證和確認;對一筆交易,如果利益不相乾的若干個節點能夠達成共識,我們就可以認為全網對此也能夠達成共識。再通俗一點來講,如果中國一名微博大V、美國一名虛擬幣玩家、一名非洲留學生和一名歐洲旅行者互不相識,但他們都一致認為你是個好人,那麼基本上就可以斷定你這人還不壞。
要想整個區塊鏈網路節點維持一份相同的數據,同時保證每個參與者的公平性,整個體系的所有參與者必須要有統一的協議,也就是我們這里要將的共識演算法。比特幣所有的節點都遵循統一的協議規范。協議規范(共識演算法)由相關的共識規則組成,這些規則可以分為兩個大的核心:工作量證明與最長鏈機制。所有規則(共識)的最終體現就是比特幣的最長鏈。共識演算法的目的就是保證比特幣不停地在最長鏈條上運轉,從而保證整個記賬系統的一致性和可靠性。
區塊鏈中的用戶進行交易時不需要考慮對方的信用、不需要信任對方,也無需一個可信的中介機構或中央機構,只需要依據區塊鏈協議即可實現交易。這種不需要可信第三方中介就可以順利交易的前提是區塊鏈的共識機制,即在互不了解、信任的市場環境中,參與交易的各節點出於對自身利益考慮,沒有任何違規作弊的動機、行為,因此各節點會主動自覺遵守預先設定的規則,來判斷每一筆交易的真實性和可靠性,並將檢驗通過的記錄寫入到區塊鏈中。各節點的利益各不相同,邏輯上將它們沒有合謀欺騙作弊的動機產生,而當網路中有的節點擁有公共信譽時,這一點尤為明顯。區塊鏈技術運用基於數學原理的共識演算法,在節點之間建立「信任」網路,利用技術手段從而實現一種創新式的信用網路。
目前區款連行業內主流的共識演算法機制包含:工作量證明機制、權益證明機制、股份授權證明機制和Pool驗證池這四大類。
工作量證明機制即對於工作量的證明,是生成要加入到區塊鏈中的一筆新的交易信息(即新區塊)時必須滿足的要求。在基於工作量證明機制構建的區塊鏈網路中,節點通過計算隨機哈希散列的數值解爭奪記賬權,求得正確的數值解以生成區塊的能力是節點算力的具體表現。工作量證明機制具有完全去中心化的優點,在以工作量證明機制為共識的區塊鏈中,節點可以自由進出。大家所熟知的比特幣網路就應用工作量證明機制來生產新的貨幣。然而,由於工作量證明機制在比特幣網路中的應用已經吸引了全球計算機大部分的算力,其他想嘗試使用該機制的區塊鏈應用很難獲得同樣規模的算力來維持自身的安全。同時,基於工作量證明機制的挖礦行為還造成了大量的資源浪費,達成共識所需要的周期也較長,因此該機制並不適合商業應用。
2012年,化名Sunny King的網友推出了Peercoin,該加密電子貨幣採用工作量證明機制發行新幣,採用權益證明機制維護網路安全,這是權益證明機制在加密電子貨幣中的首次應用。與要求證明人執行一定量的計算工作不同,權益證明要求證明人提供一定數量加密貨幣的所有權即可。權益證明機制的運作方式是,當創造一個新區塊時,礦工需要創建一個「幣權」交易,交易會按照預先設定的比例把一些幣發送給礦工本身。權益證明機制根據每個節點擁有代幣的比例和時間,依據演算法等比例地降低節點的挖礦難度,從而加快了尋找隨機數的速度。這種共識機制可以縮短達成共識所需的時間,但本質上仍然需要網路中的節點進行挖礦運算。因此,PoS機制並沒有從根本上解決PoW機制難以應用於商業領域的問題。
股份授權證明機制是一種新的保障網路安全的共識機制。它在嘗試解決傳統的PoW機制和PoS機制問題的同時,還能通過實施科技式的民主抵消中心化所帶來的負面效應。
股份授權證明機制與董事會投票類似,該機制擁有一個內置的實時股權人投票系統,就像系統隨時都在召開一個永不散場的股東大會,所有股東都在這里投票決定公司決策。基於DPoS機制建立的區塊鏈的去中心化依賴於一定數量的代表,而非全體用戶。在這樣的區塊鏈中,全體節點投票選舉出一定數量的節點代表,由他們來代理全體節點確認區塊、維持系統有序運行。同時,區塊鏈中的全體節點具有隨時罷免和任命代表的權力。如果必要,全體節點可以通過投票讓現任節點代表失去代表資格,重新選舉新的代表,實現實時的民主。
股份授權證明機制可以大大縮小參與驗證和記賬節點的數量,從而達到秒級的共識驗證。然而,該共識機制仍然不能完美解決區塊鏈在商業中的應用問題,因為該共識機制無法擺脫對於代幣的依賴,而在很多商業應用中並不需要代幣的存在。
Pool驗證池基於傳統的分布式一致性技術建立,並輔之以數據驗證機制,是目前區塊鏈中廣泛使用的一種共識機制。
Pool驗證池不需要依賴代幣就可以工作,在成熟的分布式一致性演算法(Pasox、Raft)基礎之上,可以實現秒級共識驗證,更適合有多方參與的多中心商業模式。不過,Pool驗證池也存在一些不足,例如該共識機制能夠實現的分布式程度不如PoW機制等
這里主要講解區塊鏈工作量證明機制的一些演算法原理以及比特幣網路是如何證明自己的工作量的,希望大家能夠對共識演算法有一個基本的認識。
工作量證明系統的主要特徵是客戶端要做一定難度的工作來得到一個結果,驗證方則很容易通過結果來檢查客戶端是不是做了相應的工作。這種方案的一個核心特徵是不對稱性:工作對於請求方是適中中的,對於驗證方是易於驗證的。它與驗證碼不同,驗證碼是易於被人類解決而不是易於被計算機解決。
下圖所示的為工作量證明流程。
舉個例子,給個一個基本的字元創「hello,world!」,我們給出的工作量要求是,可以在這個字元創後面添加一個叫做nonce(隨機數)的整數值,對變更後(添加nonce)的字元創進行SHA-256運算,如果得到的結果(一十六進制的形式表示)以「0000」開頭的,則驗證通過。為了達到這個工作量證明的目標,需要不停地遞增nonce值,對得到的字元創進行SHA-256哈希運算。按照這個規則,需要經過4251次運算,才能找到前導為4個0的哈希散列。
通過這個示例我們對工作量證明機制有了一個初步的理解。有人或許認為如果工作量證明只是這樣一個過程,那是不是只要記住nonce為4521使計算能通過驗證就行了,當然不是了,這只是一個例子。
下面我們將輸入簡單的變更為」Hello,World!+整數值」,整數值取1~1000,也就是說將輸入變成一個1~1000的數組:Hello,World!1;Hello,World!2;...;Hello,World!1000。然後對數組中的每一個輸入依次進行上面的工作量證明—找到前導為4個0的哈希散列。
由於哈希值偽隨機的特性,根據概率論的相關知識容易計算出,預計要進行2的16次方次數的嘗試,才能得到前導為4個0的哈希散列。而統計一下剛剛進行的1000次計算的實際結果會發現,進行計算的平均次數為66958次,十分接近2的16次方(65536)。在這個例子中,數學期望的計算次數實際就是要求的「工作量」,重復進行多次的工作量證明會是一個符合統計學規律的概率事件。
統計輸入的字元創與得到對應目標結果實際使用的計算次數如下:
對於比特幣網路中的任何節點,如果想生成一個新的區塊加入到區塊鏈中,則必須解決出比特幣網路出的這道謎題。這道題的關鍵要素是工作量證明函數、區塊及難度值。工作量證明函數是這道題的計算方法,區塊是這道題的輸入數據,難度值決定了解這道題的所需要的計算量。
比特幣網路中使用的工作量證明函數正是上文提及的SHA-256。區塊其實就是在工作量證明環節產生的。曠工通過不停地構造區塊數據,檢驗每次計算出的結果是否滿足要求的工作量,從而判斷該區塊是不是符合網路難度。區塊頭即比特幣工作量證明函數的輸入數據。
難度值是礦工們挖掘的重要參考指標,它決定了曠工需要經過多少次哈希運算才能產生一個合法的區塊。比特幣網路大約每10分鍾生成一個區塊,如果在不同的全網算力條件下,新區塊的產生基本都保持這個速度,難度值必須根據全網算力的變化進行調整。總的原則即為無論挖礦能力如何,使得網路始終保持10分鍾產生一個新區塊。
難度值的調整是在每個完整節點中獨立自動發生的。每隔2016個區塊,所有節點都會按照統一的格式自動調整難度值,這個公式是由最新產生的2016個區塊的花費時長與期望時長(按每10分鍾產生一個取款,則期望時長為20160分鍾)比較得出來的,根據實際時長一期望時長的比值進行調整。也就是說,如果區塊產生的速度比10分鍾快,則增加難度值;反正,則降低難度值。用公式來表達如下:
新難度值=舊難度值*(20160分鍾/過去2016個區塊花費時長)。
工作量證明需要有一個目標值。比特幣工作量證明的目標值(Target)的計算公式如下:
目標值=最大目標值/難度值,其中最大目標值為一個恆定值
目標值的大小與難度值成反比,比特幣工作量證明的達成就是礦中計算出來的區塊哈希值必須小於目標值。
我們也可以將比特幣工作量的過程簡單的理解成,通過不停變更區塊頭(即嘗試不同nonce值)並將其作為輸入,進行SHA-256哈希運算,找出一個有特定格式哈希值的過程(即要求有一定數量的前導0),而要求的前導0個數越多,難度越大。
可以把比特幣將這道工作量證明謎題的步驟大致歸納如下:
該過程可以用下圖表示:
比特幣的工作量證明,就是我們俗稱「挖礦」所做的主要工作。理解工作量證明機制,將為我們進一步理解比特幣區塊鏈的共識機制奠定基礎。
⑦ 區塊鏈系統開發-區塊鏈交易系統開發-的核心技術有哪些
區塊鏈技術是當今新興的一項技術,但這么說也不太妥當,因為十年前比特幣的出現這項技術也隨之誕生,但說其是當下很火熱的技術是沒問題的。區塊鏈技術經過10年來的不斷更新,終於在近兩年都有了相關的應用落地,且進入了區塊鏈3.0時代,未來的3-5年,相信會有更多的領域需要區塊鏈系統來支撐。下面區塊鏈系統開發路普達(loopodo)小編就帶大家來看一下,區塊鏈系統開發的幾大核心技術。
一、哈希演算法
哈希演算法是區塊鏈系統開發中用的最多的一種演算法,哈希函數(Hash Function),也稱為散列函數或雜湊函數,哈希函數可將任意長度的資料經由Hash演算法轉換為一組固定長度的代碼,原理是基於一種密碼學上的單向哈希函數,這種函數很容易被驗證,但是卻很難破解。通常業界使用y =h (x)的方式進行表示,該哈希函數實現對x進行運算計算出一個哈希值y。
二、非對稱加密演算法
非對稱加密演算法是一種密鑰的保密方法,非對稱加密演算法需要兩個密鑰:公開密鑰(publickey)和私有密鑰(privatekey)。公開密鑰與私有密鑰是一對,如果用公開密鑰對數據進行加密,只有用對應的私有密鑰才能解密。因為加密和解密使用的是兩個不同的密鑰,所以這種演算法叫作非對稱加密演算法
三、共識機制
所謂「共識機制」,是通過特殊節點的投票,在很短的時間內完成對交易的驗證和確認;對一筆交易,如果利益不相乾的若干個節點能夠達成共識,我們就可以認為全網對此也能夠達成共識。
現今區塊鏈的共識機制可分為四大類:工作量證明機制(PoW)、權益證明機制(PoS)、股份授權證明機制(DPoS)和Pool驗證池。
四、智能合約
智能合約就是傳統合約的數字化網路化版本。它們是區塊鏈上運行的計算機程序,可以滿足在源代碼中寫入的條件時自行執行。智能合約一旦編寫好就可以被用戶信賴,合約條款就不會被改變,因此合約是不可更改的,並且任何人也不能修改。
開發發人員會為智能合約編寫代碼,這樣就是用於交易和兩方乃至多方之間的任何交換行為。代碼里會包含一些觸發合約自動執行的條件。一旦完成編寫,智能合約就會自動被上傳到網路上。數據上傳到所有設備上以後,用戶就可以與執行程序代碼的結果達成協議。
五、分布式存儲
分布式存儲是通過網路使用企業中的每台機器上的磁碟空間,並將這些分散的存儲資源構成一個虛擬的存儲設備,數據分散的存儲在企業的各個角落。海量的數據按照結構化程度來分,可以大致分為結構化數據,非結構化數據,半結構化數據。
路普達網路科技專注區塊鏈系統開發,以太坊開發,區塊鏈交易系統開發、虛擬幣平台開發,幣幣交易系統開發、數字貨幣錢包系統開發