如何在區(qū)塊鏈系統(tǒng)中設(shè)計(jì)一個(gè)標(biāo)準(zhǔn)共識(shí)接口
掃描二維碼
隨時(shí)隨地手機(jī)看文章
區(qū)塊鏈系統(tǒng)共識(shí):去中心化的共識(shí)
本質(zhì)上,區(qū)塊鏈系統(tǒng)是一個(gè)分布式系統(tǒng),但是與普遍的分布式系統(tǒng)不同。普遍的分布式系統(tǒng),其意義在于:面對(duì)增長(zhǎng)的業(yè)務(wù)量,用多臺(tái)機(jī)器承載垂直拆分或水平拆分后的業(yè)務(wù)場(chǎng)景,增大系統(tǒng)容量;根據(jù)業(yè)務(wù)的關(guān)鍵程度,消除單點(diǎn)故障,加強(qiáng)系統(tǒng)可用性。當(dāng)一個(gè)區(qū)塊鏈系統(tǒng)承擔(dān)的業(yè)務(wù)場(chǎng)景復(fù)雜如普遍的分布式系統(tǒng)時(shí),當(dāng)然也需要做如上的考慮。但是區(qū)塊鏈系統(tǒng)之所以應(yīng)當(dāng)被人重視,是因?yàn)樗軌蚪鉀Q存在作惡節(jié)點(diǎn)情況下的數(shù)據(jù)一致性的問(wèn)題,也就是拜占庭將軍問(wèn)題。
區(qū)塊鏈?zhǔn)澜缰?,不存在所謂的中心化服務(wù)器,其是由所有愛(ài)好者、受益者或其他相關(guān)人共同構(gòu)成的P2P網(wǎng)絡(luò),網(wǎng)絡(luò)中的任何一個(gè)節(jié)點(diǎn)都是不可直接信任的,它們中的任何一個(gè)都有作惡可能,這是普遍的分布式系統(tǒng)并不會(huì)考慮的問(wèn)題。這一點(diǎn),與拜占庭將軍問(wèn)題的假設(shè)一致:沒(méi)有中心化的領(lǐng)導(dǎo)機(jī)構(gòu),這些將軍需要對(duì)某個(gè)城市發(fā)起攻擊時(shí),所有將軍需要對(duì)任何將軍提出的攻擊時(shí)間達(dá)成共識(shí)。那么問(wèn)題來(lái)了,如果將軍們自己決定的攻擊時(shí)間不一致,甚至于有將軍已經(jīng)成為叛徒,那么將軍們?nèi)绾芜_(dá)成共識(shí)呢?
同理,在區(qū)塊鏈系統(tǒng)這個(gè)P2P網(wǎng)絡(luò)中,所有的節(jié)點(diǎn)如何針對(duì)某一筆交易達(dá)成共識(shí)呢(也就是基于這一筆交易對(duì)節(jié)點(diǎn)各自的數(shù)據(jù)庫(kù)做出修改)?
在1982年的論文The Byzantine Generals Problem中,Leslie Lamport證明,當(dāng)將軍們中的叛徒不超過(guò)1/3時(shí),存在有效的算法,無(wú)論叛徒們?nèi)绾握垓v,忠誠(chéng)的將軍們總能達(dá)成一致的結(jié)果。而如果叛徒過(guò)多,就無(wú)法保證一定能達(dá)到一致。
那么我們直接假設(shè)區(qū)塊鏈P2P網(wǎng)絡(luò)中,作惡節(jié)點(diǎn)數(shù)量不超過(guò)1/3,否則認(rèn)為區(qū)塊鏈系統(tǒng)構(gòu)建失敗。如此,接下來(lái)最難解決的問(wèn)題就是,在一個(gè)作惡節(jié)點(diǎn)不超過(guò)1/3的區(qū)塊鏈系統(tǒng)中,要選擇誰(shuí)的數(shù)據(jù)作為達(dá)成最終共識(shí)的數(shù)據(jù)?
換一個(gè)角度:如果一個(gè)節(jié)點(diǎn)希望自己提供的數(shù)據(jù)能夠在區(qū)塊鏈系統(tǒng)中達(dá)成共識(shí),他需要做什么?他需要提供一個(gè)Proof。一個(gè)證明。去說(shuō)服區(qū)塊鏈系統(tǒng)接受他所提供的數(shù)據(jù)。
據(jù)此,我們開(kāi)始討論如何在區(qū)塊鏈系統(tǒng)中設(shè)計(jì)一個(gè)標(biāo)準(zhǔn)共識(shí)接口。
標(biāo)準(zhǔn)共識(shí)接口設(shè)計(jì)
區(qū)塊鏈達(dá)成共識(shí)的流程:
1.節(jié)點(diǎn)A準(zhǔn)備了一個(gè)區(qū)塊,廣播給P2P網(wǎng)絡(luò);
2.P2P網(wǎng)絡(luò)的其他節(jié)點(diǎn)收到區(qū)塊以后,經(jīng)過(guò)一系列驗(yàn)證,決定是否將該區(qū)塊放在本地的最長(zhǎng)鏈上;
3.當(dāng)區(qū)塊鏈系統(tǒng)中的大多數(shù)節(jié)點(diǎn)(如超過(guò)2/3)本地某個(gè)區(qū)塊高度對(duì)應(yīng)的區(qū)塊哈希值都一致的話,我們就可以認(rèn)為區(qū)塊鏈針對(duì)這個(gè)高度的區(qū)塊達(dá)成了一致。
如果需要一個(gè)服務(wù)來(lái)幫助節(jié)點(diǎn)A及區(qū)塊鏈其他節(jié)點(diǎn)完成整個(gè)共識(shí)過(guò)程,那么所提供的服務(wù)應(yīng)該大體上有兩種:
1.面對(duì)一無(wú)所知的A,需要在A詢問(wèn)的時(shí)候,告知其(在區(qū)塊鏈?zhǔn)澜缰?,A使用一個(gè)公鑰唯一確定身份)當(dāng)前能不能嘗試產(chǎn)生區(qū)塊,以及如何設(shè)法使其產(chǎn)生的區(qū)塊讓其他節(jié)點(diǎn)接受;
2.除了A以外的其他節(jié)點(diǎn),面對(duì)從網(wǎng)絡(luò)上收到的一個(gè)A廣播出來(lái)的區(qū)塊,通過(guò)一個(gè)開(kāi)源的所有節(jié)點(diǎn)實(shí)現(xiàn)代碼都一致的服務(wù)來(lái)驗(yàn)證該區(qū)塊是否合法。
如果某節(jié)點(diǎn)通過(guò)對(duì)這個(gè)區(qū)塊的驗(yàn)證,得知該區(qū)塊合法,則稱該節(jié)點(diǎn)對(duì)A產(chǎn)生的這個(gè)區(qū)塊達(dá)成了共識(shí)。因?yàn)樗泄?jié)點(diǎn)的驗(yàn)證服務(wù)都是同樣的邏輯,區(qū)塊鏈網(wǎng)絡(luò)中所有節(jié)點(diǎn)對(duì)該區(qū)塊的合法性都會(huì)具有一樣的態(tài)度,終究,這一個(gè)區(qū)塊鏈P2P網(wǎng)絡(luò)中(在沒(méi)有更長(zhǎng)的鏈出現(xiàn)的情況下)對(duì)這個(gè)區(qū)塊被添加到最長(zhǎng)鏈這個(gè)事件達(dá)成最終一致性也是可以預(yù)見(jiàn)的。
aelf共識(shí)通用接口標(biāo)準(zhǔn)
現(xiàn)在開(kāi)始,我們基于“標(biāo)準(zhǔn)共識(shí)接口設(shè)計(jì)”中統(tǒng)計(jì)出來(lái)的兩類服務(wù),進(jìn)行aelf共識(shí)通用接口的設(shè)計(jì)。
首先需要明確,這兩類和共識(shí)相關(guān)的服務(wù)(請(qǐng)求區(qū)塊生產(chǎn)相關(guān)的指示、驗(yàn)證新區(qū)塊)都是只讀的接口,其調(diào)用本身無(wú)需修改區(qū)塊鏈網(wǎng)絡(luò)的賬本信息。
其次,這些接口實(shí)際上會(huì)被aelf主鏈代碼調(diào)用,因此其設(shè)計(jì)需要遵循aelf主鏈代碼中關(guān)于生產(chǎn)區(qū)塊和驗(yàn)證區(qū)塊的邏輯(當(dāng)然,即便在主鏈代碼中,這些接口也幾乎一一對(duì)應(yīng)地出現(xiàn)在共識(shí)的服務(wù)Consensus Service中)。
我們分別討論兩種接口:
請(qǐng)求共識(shí)命令
繼續(xù)前面的例子,還是節(jié)點(diǎn)A,這是一個(gè)已經(jīng)同步到當(dāng)前aelf最長(zhǎng)鏈的節(jié)點(diǎn)。當(dāng)前時(shí)間是2020年1月1日下午13:59:56。A,作為一個(gè)誠(chéng)實(shí)的節(jié)點(diǎn)(沒(méi)有修改本地主鏈代碼),剛剛同步了一個(gè)區(qū)塊(也就是接受到網(wǎng)絡(luò)上其他節(jié)點(diǎn)的區(qū)塊,驗(yàn)證成功,修改了本地的區(qū)塊鏈賬本信息),本地的Best Chain(維護(hù)本地區(qū)塊鏈的一個(gè)數(shù)據(jù)結(jié)構(gòu))得到更新后,Event Bus上裝載了一個(gè)事件。這個(gè)事件的作用之一,就是提醒節(jié)點(diǎn)A去問(wèn)一下共識(shí)服務(wù)(通過(guò)相關(guān)事件訂閱和處理機(jī)制),接下來(lái)他能做點(diǎn)什么。在進(jìn)行詢問(wèn)時(shí),A把自己的公鑰傳給了共識(shí)服務(wù)。
共識(shí)服務(wù)的核心邏輯作為一個(gè)智能合約而存在,因?yàn)橹挥腥绱瞬拍鼙WC其代碼對(duì)于區(qū)塊鏈?zhǔn)澜缰忻恳粋€(gè)節(jié)點(diǎn)都是一致的(不一致意味著這個(gè)節(jié)點(diǎn)試圖作惡或者硬分叉)。經(jīng)過(guò)長(zhǎng)達(dá)幾毫秒的復(fù)雜計(jì)算(也許是簡(jiǎn)單計(jì)算),共識(shí)的智能合約反饋給節(jié)點(diǎn)A一個(gè)信息。這個(gè)信息的生成就因共識(shí)機(jī)制的選取而異,但是無(wú)論什么共識(shí),都應(yīng)該具備以下結(jié)構(gòu):
· A什么時(shí)間可以產(chǎn)生區(qū)塊?
· 如果A可以產(chǎn)生區(qū)塊,那么A應(yīng)該用什么方式進(jìn)行下一步的請(qǐng)求:即在當(dāng)前共識(shí)下,A能產(chǎn)生什么區(qū)塊。在此稱這一信息為額外提示。
如果A不能產(chǎn)生區(qū)塊怎么辦?區(qū)塊鏈?zhǔn)澜缰欣碚撋厦總€(gè)人其實(shí)都有可能產(chǎn)生區(qū)塊,但是由于共識(shí)機(jī)制的設(shè)計(jì)不同(比如PoS共識(shí)),有些區(qū)塊鏈并不希望大多數(shù)節(jié)點(diǎn)有生產(chǎn)區(qū)塊的權(quán)利。這種情況下,只需要將返回給A的時(shí)間設(shè)置到一百年后就可以(可能有些夸張,但是幾個(gè)月后總沒(méi)問(wèn)題)。只要節(jié)點(diǎn)A能夠堅(jiān)持掛機(jī),并且區(qū)塊鏈沒(méi)有產(chǎn)生任何一個(gè)新的區(qū)塊(任何有效的新的區(qū)塊的同步都會(huì)使節(jié)點(diǎn)A重新獲得一個(gè)出塊時(shí)間)。
不難想象基于這個(gè)接口實(shí)現(xiàn)PoW有多么容易。只要時(shí)間設(shè)置為“立刻”,額外提示為空即可。
在aelf主鏈中,共識(shí)服務(wù)得知共識(shí)反饋的時(shí)間信息后,會(huì)立刻更新共識(shí)調(diào)度器(如果此前共識(shí)調(diào)度器非空,則干掉之前未竟的調(diào)度信息,用新的時(shí)間點(diǎn)來(lái)填充,也就是說(shuō)共識(shí)調(diào)度器里面只能有一個(gè)未執(zhí)行的共識(shí)任務(wù),且共識(shí)調(diào)度器是單例的對(duì)象)。
接下來(lái)就是漫長(zhǎng)的倒計(jì)時(shí)。
我們回到節(jié)點(diǎn)A這個(gè)例子。假設(shè)A在請(qǐng)求共識(shí)命令后,得到了一個(gè)時(shí)間:2020年1月1日下午14:00:00,也就是4秒鐘以后。額外提示:NextRound(這是AEDPoS共識(shí)的一個(gè)提示,意味著A將終結(jié)本輪的出塊流程,并更新下一輪的所有代理出塊節(jié)點(diǎn)的出塊順序)。這就意味著調(diào)度器會(huì)立刻更新為4秒后執(zhí)行一個(gè)生產(chǎn)區(qū)塊的事件。這4秒中做什么?如果可以同步到其他節(jié)點(diǎn)發(fā)過(guò)來(lái)的區(qū)塊,而這些區(qū)塊可以通過(guò)驗(yàn)證,那就使用Best Chain更新這一事件的處理器,不斷地問(wèn)共識(shí)服務(wù)請(qǐng)求共識(shí)命令(這一個(gè)操作在代碼中稱為TriggerConsensus),相應(yīng)的,共識(shí)調(diào)度器就會(huì)不斷地重置:3.5秒,3秒,2.5秒,2秒,……
終于,時(shí)間來(lái)到了14:00:00。節(jié)點(diǎn)A在共識(shí)調(diào)度器的支配下開(kāi)始準(zhǔn)備生產(chǎn)區(qū)塊。此時(shí),按照我們之前的設(shè)計(jì),除了已經(jīng)發(fā)揮了作用的出塊時(shí)間,關(guān)于如何生產(chǎn)區(qū)塊,它唯一知道的信息只有之前共識(shí)服務(wù)給他的額外提示。
這時(shí),在aelf中,節(jié)點(diǎn)A把額外提示信息傳遞給共識(shí)服務(wù)。在打包交易之余,還會(huì)調(diào)用另外兩個(gè)服務(wù):
· 獲得共識(shí)區(qū)塊頭信息
· 獲得共識(shí)系統(tǒng)交易
請(qǐng)求共識(shí)命令的接口有一個(gè)作用是設(shè)法讓生產(chǎn)出來(lái)的區(qū)塊通過(guò)驗(yàn)證。在aelf中,在區(qū)塊的一系列驗(yàn)證步驟中,有兩個(gè)和共識(shí)相關(guān)的驗(yàn)證:執(zhí)行前,驗(yàn)證區(qū)塊頭;執(zhí)行后,對(duì)共識(shí)合約狀態(tài)的修改信息是否和區(qū)塊頭中的信息的一致性進(jìn)行驗(yàn)證。
簡(jiǎn)單做個(gè)類比,一個(gè).NET程序員去參加DNT線下沙龍,他拿出參加沙龍的邀請(qǐng)短信給沙龍主辦方進(jìn)行查驗(yàn),這個(gè)短信類似于區(qū)塊頭,也就是說(shuō)如果他拿不出邀請(qǐng)短信,那主辦方不會(huì)讓他參加。接下來(lái),主辦方還會(huì)要求.NET程序員報(bào)出手機(jī)號(hào),然后在參會(huì)人員的花名冊(cè)中尋找該手機(jī)號(hào),這就類似于在區(qū)塊鏈節(jié)點(diǎn)執(zhí)行完共識(shí)交易后的驗(yàn)證。只有這一步也驗(yàn)證通過(guò),.NET程序員才能順利參加此次沙龍。
綜上所述,針對(duì)“請(qǐng)求共識(shí)命令”這一類服務(wù),我們需要三個(gè)接口。用Protobuf直接描述如下:
service ConsensusContract {
rpc GetConsensusCommand (google.protobuf.BytesValue)
returns (ConsensusCommand) {
opTIon (aelf.is_view) = true;
}
rpc GetConsensusExtraData (google.protobuf.BytesValue)
returns (google.protobuf.BytesValue) {
opTIon (aelf.is_view) = true;
}
rpc GenerateConsensusTransacTIons (google.protobuf.BytesValue)
returns (TransacTIonList) {
option (aelf.is_view) = true;
}
}
message ConsensusCommand {
int32 limit_milliseconds_of_mining_block = 2;
// Time limit of mining next block.
bytes hint = 3;
// Context of Hint is diverse according to the consensus protocol we choose, so we use bytes.
google.protobuf.Timestamp arranged_mining_time = 4;
google.protobuf.Timestamp mining_due_time = 5;
}
message TransactionList {
repeated aelf.Transaction transactions = 1;
}
出于對(duì)鏈的安全和穩(wěn)定性考慮,在ConsensusCommand中,除了下次出塊時(shí)間(arranged_mining_time)和額外提示(hint),還包括了出塊時(shí)間限制(limit_milliseconds_of_mining_block)和最晚廣播時(shí)間(mining_due_time)。后面兩個(gè)信息都是給區(qū)塊生產(chǎn)服務(wù)作為參考的,用來(lái)實(shí)現(xiàn)如果超過(guò)了某個(gè)時(shí)間限制,生產(chǎn)出來(lái)的區(qū)塊就無(wú)需廣播(或者即便廣播別的節(jié)點(diǎn)也不能通過(guò)驗(yàn)證,當(dāng)然這個(gè)驗(yàn)證是在下面要討論的接口類型的具體實(shí)現(xiàn)中保證的);多生產(chǎn)出一個(gè)塊也比擾亂區(qū)塊生產(chǎn)秩序要好。
區(qū)塊驗(yàn)證
如果說(shuō)請(qǐng)求共識(shí)命令還值得細(xì)致討論的話,區(qū)塊驗(yàn)證相關(guān)的接口就泛善可陳了。因?yàn)閰^(qū)塊驗(yàn)證邏輯本質(zhì)上是完全因共識(shí)而異的。
接口本身并無(wú)新意,一個(gè)是在共識(shí)交易執(zhí)行前驗(yàn)證區(qū)塊頭,一個(gè)是共識(shí)交易執(zhí)行后驗(yàn)證共識(shí)修改的狀態(tài)是否和區(qū)塊頭中承諾的信息一致。而兩個(gè)驗(yàn)證接口的入?yún)⒍际嵌M(jìn)制數(shù)組,意味著該接口接受任何數(shù)據(jù),只需要共識(shí)的實(shí)現(xiàn)者在驗(yàn)證的具體實(shí)現(xiàn)中自行反序列化即可。