eos最新技術白皮書

本文由【區(qū)塊鏈研習社】優(yōu)質(zhì)內(nèi)容計劃支持,更多關于區(qū)塊鏈的深度好文,請點擊區(qū)塊鏈研習社傳送門

太專業(yè)的技術貼,大家留言交流。

智博區(qū)塊鏈私教團


本白皮書中內(nèi)容無需授權,任何人都可以復制或分發(fā)用于非商業(yè)或教育用途,只需注明原始來源和應用版權聲明即可,但不可用于收費或者商業(yè)用途。

免責聲明: 本 EOS.IO 技術白皮書 2.0 版本僅作信息提供之用。block.one 不保證白皮書中內(nèi)容或結論的準確性,僅供參考。block.one 不會作出、并且明確否認所有明示的或隱含的、法定的或其他形式的聲明和保證條款,包括但不限于:(i)適銷性、針對特定用途的適用性、適宜性、用途、所有權和非侵權的保證;(ii)本白皮書中的內(nèi)容不存在錯誤的保證;(iii)本白皮書內(nèi)容不會侵害第三方權利的保證。block.one 及其分公司不承擔因對本白皮書及本聲明中所含內(nèi)容的使用、參考或信任而造成的任何損失,即便已告誡過可能造成的損害。任何個人或實體由于對本白皮書及本聲明所包含內(nèi)容的使用、參考、或信任而造成的各種形式的任何損害、損失、負債、成本或花費,不論是直接的、間接的、作為結果的、賠償?shù)摹⑴及l(fā)的、實際的、懲戒的、懲罰的,或是特殊性的,包括但不限于任何業(yè)務、收入、利潤、數(shù)據(jù)、效用、商譽或其他無形損失,block.one 或其分公司在任何情況下均不為此承擔責任。

背景

伴隨著比特幣的誕生,區(qū)塊鏈技術在 2008 年問世,從那之后,企業(yè)家和開發(fā)者不斷地試圖將區(qū)塊鏈技術通用化,以期在單一區(qū)塊鏈平臺上實現(xiàn)對去中心化應用更廣泛的支持。

在眾多爭相實現(xiàn)支持可實用的去中心化應用的區(qū)塊鏈平臺當中,一些針對特定應用場景的區(qū)塊鏈脫穎而出并被廣泛使用,吸引了成千上萬的用戶。例如去中心化交易所 BitShares(2014)和社交媒體平臺 Steem(2016)。類似的項目之所以能被眾多用戶接納,是因為他們不僅提高了性能使得每秒可處理的交易量達到數(shù)千次,還將確認時間縮短至 1.5s 并且消除了交易費用,同時他們還能提供可與現(xiàn)有的中心化服務相媲美的用戶體驗。

然而更多現(xiàn)有的區(qū)塊鏈平臺(的使用)則需要高昂的交易費用,并且計算能力也有限,這些都是阻礙區(qū)塊鏈技術被更廣泛地接受與使用的因素。

對區(qū)塊鏈應用的要求

要實現(xiàn)更廣泛的應用,區(qū)塊鏈上的應用程序需要一個足夠靈活的平臺,該平臺要滿足以下需求:

支持百萬級用戶

與 Ebay、Uber、AirBnB 和 Facebook 這樣的企業(yè)競爭,區(qū)塊鏈技術要能處理百萬級的日活躍用戶。 在某些場景中,除非用戶量達到一個極其龐大的數(shù)量級,否則應用并無用武之地。因此,一個可以支持相當龐大的用戶量的平臺是至關重要的。

免費使用

應用開發(fā)者需要足夠的靈活性來為用戶提供免費的服務,用戶不應該因為使用平臺或從平臺上的服務中獲益而支付費用。可免費使用的區(qū)塊鏈平臺會更受歡迎,開發(fā)者和商家也可以從中創(chuàng)造更多有效的盈利策略。

易于升級和 Bug 修復

基于商用區(qū)塊鏈之上的應用需要有一定的靈活性來支持新特性的增加,因此平臺本身必須支持軟件和智能合約的升級。

軟件只要達到一定規(guī)模,就必定會出現(xiàn) bug,即便是通過了再嚴格的驗證也不例外。因此平臺必須足夠魯棒(Robust)并支持修復不可避免的 bug。

低延時

好的用戶體驗要求在數(shù)秒內(nèi)就能收到可靠的反饋。高延時不僅會讓用戶心煩,還會導致建立在區(qū)塊鏈之上的應用競爭力不如現(xiàn)有的中心化應用。因此,平臺需要支持低延時交易。

時序性能

由于執(zhí)行步驟的順序依賴關系,一些應用不能使用并發(fā)算法來實現(xiàn)。例如,交易所就需要足夠的時序性能來處理高交易量。因此,平臺需要具備高時序性能。

并發(fā)性能

大規(guī)模的應用需要將工作量分配到多臺 CPU 和計算機之上,因此,平臺需要內(nèi)建對并發(fā)的支持。

共識算法(BFT-DPOS)

EOS.IO 軟件采用授權委托證明(DPOS)的算法,在目前已知的去中心化共識算法中,只有該算法經(jīng)證明可以滿足區(qū)塊鏈上應用程序的性能要求。根據(jù)這種算法, EOS 區(qū)塊鏈上所有代幣持有者可以都通過一個持續(xù)的投票系統(tǒng)選擇區(qū)塊生產(chǎn)者。想?yún)⑴c區(qū)塊生產(chǎn),只要能說服代幣持有人給自己投票,最終(得票最高的那些節(jié)點)被選為區(qū)塊生產(chǎn)者。

EOS.IO 軟件能夠精確地每 0.5 秒產(chǎn)生一個區(qū)塊,并且在任一時間僅有一個生產(chǎn)者獲權生產(chǎn)區(qū)塊。如果在預定時間內(nèi)沒有區(qū)塊生成,則跳過該塊。相應的,當跳過一個或多個塊時,區(qū)塊鏈中會存在一個大于等于 0.5 秒的時間間隔。

使用 EOS.IO 軟件,每一輪產(chǎn)生 126 個區(qū)塊(共 21 個區(qū)塊生產(chǎn)者,每一輪都有一個特定的生產(chǎn)者負責產(chǎn)生 6 個塊,即一輪的時間為 63 秒)。在每輪開始時,根據(jù)代幣持有者的投票選出 21 個不同的區(qū)塊生產(chǎn)者。獲選的生產(chǎn)者的生產(chǎn)順序由 15 個或更多生產(chǎn)者一致同意決定。

如果一個生產(chǎn)者錯過了一個塊,并且在過去 24 小時均未產(chǎn)生任何塊,則會被從生產(chǎn)者的名單中剔除,直至他通知區(qū)塊鏈表明他打算再次開始生產(chǎn)區(qū)塊。這種方式可以排除不可靠的生產(chǎn)者來最小化錯過的區(qū)塊數(shù)量,從而確保網(wǎng)絡的順暢運行。

正常情況下, DPOS 區(qū)塊鏈不會產(chǎn)生任何分叉,因為生產(chǎn)者生產(chǎn)區(qū)塊的方式是合作而非競爭。如果出現(xiàn)分叉,那么共識的處理方式是自動切換到最長的鏈上。其工作原理是,一個區(qū)塊鏈的分叉上新區(qū)塊的添加速度與在這個分叉上達成共識的生產(chǎn)者的多寡直接相關。換言之,生產(chǎn)者數(shù)量多的分叉,其增長速度要比生產(chǎn)者較少的分叉的增長速度更快,這是因為生產(chǎn)者數(shù)量多的分叉錯過的區(qū)塊數(shù)往往會更少。

此外,任何區(qū)塊生產(chǎn)者都不應該在同一時刻在兩個分叉上競爭出塊。如果有塊生產(chǎn)者被發(fā)現(xiàn)這么做,可能會被投票出局。這種雙重生產(chǎn)會留下密碼學證據(jù),因此識別并自動清除這類區(qū)塊生產(chǎn)者是可行的。

添加了拜占庭容錯機制的 DPOS 算法需要所有生產(chǎn)者簽名所有區(qū)塊,但禁止同一個生產(chǎn)者簽名兩個時間戳或高度相同的區(qū)塊。一個區(qū)塊一旦被 15 個生產(chǎn)者簽名,那么這個區(qū)塊就可以被視為不可逆了。 任何生產(chǎn)者一旦簽名兩個相同時間戳或相同區(qū)塊高度的區(qū)塊,這種不誠信行為就會留下密碼學證據(jù)。在這一模型下,不可逆的共識將在 1 秒內(nèi)達成。

交易確認

典型的基于 DPOS 共識算法的區(qū)塊鏈中,區(qū)塊生產(chǎn)者會有 100% 的參與度。一筆交易在廣播后的平均 0.25 秒之后,就可以 99.9% 確定這筆交易不可逆了。

而 EOS.IO 軟件除了 DPOS 共識算法,還引入了了異步拜占庭容錯(aBFT),可讓交易的更快達到不可逆轉狀態(tài),可在 1 秒內(nèi) 100% 確定交易達到了不可逆狀態(tài)。

交易作為權益證明(TaPoS)

EOS.IO軟件要求每一筆交易必須包括最近的一個區(qū)塊頭的部分哈希值。這個哈希值有兩個目的:

1.防止一個交易在另一個未包含該交易的分叉上被重新廣播。

2.通知整個網(wǎng)絡,某個特定用戶和他的權益存在于某個特定的分叉上。

如此一來,偽造假冒鏈將變得非常困難,因為偽造者無法將合法鏈中的交易遷移到假冒鏈上。

賬戶系統(tǒng)

EOS.IO 軟件規(guī)定所有的賬戶都由一個唯一名稱來標識,名稱的最大長度為 12 個字符。該名稱由帳戶的創(chuàng)建者指定。帳戶創(chuàng)建者必須使用 EOS 代幣預留 RAM 用來存儲新帳戶,直至新帳戶質(zhì)押自己的代幣來預留自己的 RAM。

在去中心化的背景下,應用程序開發(fā)人員在新用戶注冊時,會象征性地支付賬戶創(chuàng)建費用。傳統(tǒng)企業(yè)為獲取客戶,已經(jīng)以廣告、免費服務等形式為每個用戶花費了大量資金。相比之下,創(chuàng)建新的區(qū)塊鏈賬戶所需的資金成本微不足道。不過好在如果用戶在注冊另一個應用程序時已經(jīng)創(chuàng)建了帳戶,那就沒有必要再次創(chuàng)建了。

操作(Actions)和處理程序

每個帳戶可以發(fā)送結構化的操作(Actions)到其他帳戶,并且可以定義程序代碼來處理收到后的操作。EOS.IO軟件為每個帳戶提供自己的私有數(shù)據(jù)庫,只能由該賬戶的操作處理程序(Action Handler)訪問。操作處理程序還可以發(fā)送操作到其他賬戶。操作和自動化的操作處理程序的結合合是EOS.IO定義智能合約的方式。

為支持并發(fā)執(zhí)行操作,每個賬戶可以在其數(shù)據(jù)庫內(nèi)定義任意多個作用域。區(qū)塊生產(chǎn)者通過這種方式安排事務,使得事務執(zhí)行時對作用域的內(nèi)存訪問沒有沖突,因此事務可以并發(fā)執(zhí)行。

基于角色的權限管理

權限管理包括確認某項操作是否被正確授權。最簡單的權限管理是檢查交易是否具有所需的簽名,這也意味著所需的簽名是已知的。一般而言,授權涉及個人或群體,并且往往是分類的。EOS.IO 軟件提供了一個聲明式權限管理系統(tǒng),可以對帳戶進行細粒度、高級別的控制,以確定誰在何時可以做什么。

身份驗證和權限管理必須標準化,并與應用程序的業(yè)務邏輯分開,這是至關重要的。這樣使得開發(fā)工具能夠以通用方式管理權限,并為優(yōu)化性能提供巨大空間。

每個帳戶都可以通過其他帳戶和私鑰的組合來控制。這就創(chuàng)建了一個分層的權限結構,真實反映了現(xiàn)實中權限的組織方式,并使得多用戶的賬戶控制比以往更容易。多用戶控制對提升安全性的作用是最大的。如果使用得當,會極大降低黑客攻擊而造成的盜竊風險。

EOS.IO 軟件允許帳戶定義什么樣的賬戶和密鑰的組合可以把特定的操作發(fā)送到另一個賬戶。例如,可以使用一個密鑰訪問用戶的社交媒體帳戶,另一個密鑰用于訪問交易所。甚至可以授權其他帳戶來代表本賬戶進行操作,而無需為其他賬戶分配密鑰。

命名的權限級別

帳戶通過使用 EOS.IO 軟件,可以定義命名的權限的級別,每個權限級別可以從更高級別的命名權限中派生。每個命名權限級別定義一個權限。權限是一個多簽名的閾值檢查,由其他帳戶的密鑰和/或命名權限級別組成。例如,可以為一個帳戶的某個操作設置"朋友"權限級別,該帳戶的朋友對該操作具有相同等級的控制權限。

另一個例子是 Steem 區(qū)域鏈,它具有三個硬編碼的命名的權限級別:owner, active和posting。posting 權限只能執(zhí)行諸如投票和發(fā)布等社交操作,而 active 權限可以執(zhí)行除更改所有者的所有操作。owner 權限應該被冷存儲起來,它可以執(zhí)行一切操作。EOS.IO 推廣了這一理念,允許每個賬戶所有者自定義權限級別以及操作的分組。

權限映射

EOS.IO 軟件允許每個帳戶定義從合約/操作或其他賬戶的合約到其自己的命名的權限級別之間的映射。例如,賬戶持有人可將其社交媒體應用程序映射到賬戶所有者的"朋友"權限組。通過此映射,該賬戶的任何朋友都可以作為賬戶所有者在社交媒體發(fā)布信息。盡管這些朋友可以作為帳戶所有者發(fā)布信息,但他們?nèi)匀粫褂米约旱拿荑€來簽名。這就意味著,哪些朋友以何種方式使用了該帳戶,始終是可以確定的。

權限評估

當從賬戶 @alice 發(fā)送類型為" Action " 的操作到 @bob 時,EOS.IO 軟件將首先檢查 @alice 是否為 @bob.groupa.subgroup.Action 定義了權限映射。如果沒有發(fā)現(xiàn)任何結果,那么將會檢查 @bob.groupa.subgroup,然后檢查 @bob.groupa,最后檢查 @bob。如果沒有找到進一步的匹配,則假定映射的命名權限組是 @alice.active。

一旦確定了映射的命名權限,則使用多簽名閾值來驗證簽名,并獲取命名權限相關聯(lián)的權限。如果失敗,那么它會遍歷父類權限,最后遍歷 owner 的權限,即@alice.owner。

默認權限組

EOS.IO 軟件給所有賬戶指定了兩個默認權限組。一個是"owner"權限組,可以執(zhí)行任何操作。還有一個“active”權限組,除了更改“owner” 權限組之外,可以執(zhí)行所有操作。所有其他權限組均由“active”組派生。

并發(fā)評估權限

權限評估過程是"只讀"的,并且,對權限的更新交易直到被打包進區(qū)塊后才會生效。這意味著一切交易的所有密鑰和權限評估都可以并發(fā)執(zhí)行。此外,這還說明快速權限驗證是可行的,而且不需要啟動昂貴的應用程序邏輯(并且在驗證失敗時會回滾應用邏輯)。最后,這意味著交易權限可以在接收到待處理的交易時進行評估,而在待處理的交易被處理時無需重新評估。

從整體來看,權限驗證占交易驗證中所需計算的很大一部分。讓權限驗證過程只讀,并且可并發(fā)執(zhí)行,可以顯著提升性能。

當我們重放區(qū)塊鏈的歷史,試圖從操作日志重新生成確定性狀態(tài)時,不需要再次評估權限。交易包含在一個已知的不可逆的區(qū)塊中這一客觀事實,足以讓其跳過權限評估的不周步驟。這極大減少了重放不斷增長的區(qū)塊鏈時消耗的計算量。

帶強制延遲的操作

時間是關乎安全的關鍵因素。通常情況下,只有在私鑰被盜竊者使用了之后,私鑰的所有者才能知道它被盜了。當人們的應用軟件需要在連網(wǎng)的計算機上保存密鑰以供日常使用時,基于時間的安全性就顯得更為重要了。EOS.IO 軟件使得開發(fā)者可以指定某些操作 (Actions) 在記錄到一個區(qū)塊后必須至少等待一小段時間后才被應用。在此期間,操作可以取消。

當一個操作廣播后,用戶可以通過電子郵件或短信來接收其通知。如果他們沒有給這個操作授權,那就可以使用賬戶恢復流程來恢復賬戶并撤銷操作。

上述所需的操作確認延遲取決于操作的敏感程度。支付咖啡錢時可以沒有任何延遲,在幾秒鐘內(nèi)就達到不可逆,而購房時可能就需要 72 小時的結算期。轉讓整個帳戶到新的控制權可能需要長達30天的時間。確切的延遲時間是由應用開發(fā)者和用戶共同決定的。

密鑰被盜后的恢復

EOS.IO 軟件為用戶提供了一種在密鑰被盜后恢復帳戶控制權的方法。帳戶所有者 (owner) 可以通過過去 30 天內(nèi)處于活躍狀態(tài)的任何 owner 密鑰,以及來自其指定的帳戶恢復合作伙伴的批準來重置其帳戶的 owner 密鑰。沒有帳戶所有者的幫助,帳戶恢復合作伙伴無法單獨重置帳戶的控制權。

黑客嘗試完成恢復流程是沒有意義的,因為他們已經(jīng)"控制"了帳戶。此外,如果他們?nèi)f一真要走這個流程,恢復伙伴也會要求身份識別和多重認證(電話和電子郵件)。這會讓黑客的身份受到懷疑,或讓他在該流程中一無所獲。

該流程與簡單的多重簽名協(xié)議很不一樣。多重簽名交易中,另一方會成為每筆交易的參與者。相比之下,在恢復流程中,合作伙伴只是參與了恢復流程,無權干預日常交易。這大大降低了所有相關人員的操作成本和法律責任。

應用的確定性并行執(zhí)行

區(qū)塊鏈共識取決于確定性 (可重復) 行為,這意味著所有并行執(zhí)行必須避免使用互斥鎖或者其他鎖原語。如果沒有鎖,那么必須要有方法來保證可能被并行執(zhí)行的交易不會產(chǎn)生非確定性結果。

EOS.IO 軟件在 2018 年 6 月的發(fā)行版將會是單線程的,但是它會包含將來多線程、并行執(zhí)行所需的數(shù)據(jù)結構。

在基于 EOS.IO 軟件的區(qū)塊鏈中,一旦啟用并行操作,區(qū)塊生產(chǎn)者的工作就是將操作 (Action) 投遞到獨立的分片 (shard) 中,以便可以進行并行評估。區(qū)塊生產(chǎn)者的產(chǎn)出是將被確定性地執(zhí)行的計劃表,但是生成計劃表的過程不需要是確定性的。這意味著區(qū)塊生產(chǎn)者可以利用并行算法來調(diào)度交易。

部分的并行執(zhí)行是說,當一個腳本生成一個新的操作時,它可能不會被立即投遞,而是被安排在下一個循環(huán)中投遞。無法立即分配的原因是接收者可能正在活躍地修改自己在其他分片中的狀態(tài)。

最小化通信延遲

延遲時間是指一個帳戶向另一個帳戶發(fā)送操作并接收響應所需的時間。我們的目標是使兩個賬戶能夠在一個區(qū)塊內(nèi)來回交換操作,而不必為每次操作都等待 0.5 秒。為了實現(xiàn)這一點,EOS.IO 軟件將每個區(qū)塊分成多個循環(huán) (Cycle),每個循環(huán)又被分成多個分片,每個分片包含一組交易。每筆交易都包含一組要投遞的操作。這個結構可以被可視化為一棵樹,其中不同層交替地按順序及并行地處理。

區(qū)塊 區(qū)域 循環(huán) (順序) 分片 (并行) 交易 (順序) 操作 (順序) 接收者和被通知賬戶 (并行)

在一個循環(huán)內(nèi)生成的交易可以在任意后續(xù)的循環(huán)或區(qū)塊中被投遞。區(qū)塊生產(chǎn)者會持續(xù)給區(qū)塊增加循環(huán),直到超過最大運行時間,或者沒有新生成的交易要投遞。

對一個區(qū)塊使用靜態(tài)分析來驗證給定循環(huán)內(nèi)沒有兩個分片包含修改同一帳戶的交易,這種方式是可行的。只要這一點是確定的,那么一個區(qū)塊就可以通過并行運行所有的分片的方式進行處理。

只讀的操作處理程序

有些帳戶可能可以用"通過/未通過”的方式來處理操作,而不必修改其內(nèi)部狀態(tài)。如果是這種情況,只要對于特定的賬戶只有只讀的操作處理程序被包含在某一循環(huán)內(nèi)的一個或多個分片中,那么這些處理程序可以被并行執(zhí)行。

多帳戶的原子交易

有時候我們希望保證操作投遞給多個賬戶并被接收是原子的。在這種情況下,兩個操作會被放置在同一筆交易里,這兩個帳戶還會被分配到相同的分片里并按順序處理操作。

區(qū)塊鏈狀態(tài)的部分評估

區(qū)塊鏈擴容技術要求組件是模塊化的。任何人都不應該處理所有事情,特別是在他們只需要使用一小部分鏈上數(shù)據(jù)的情況下。

交易所應用的開發(fā)者會運行全節(jié)點以便給用戶顯示交易狀態(tài)。這個交易所應用不需要其他社交媒體應用相關的狀態(tài)。EOS.IO 軟件允許任意全節(jié)點選擇要運行的任意應用的子集。如果你的應用不依賴于其他合約的狀態(tài),那么你可以安全地忽略投遞給其他應用的操作。

自主最優(yōu)調(diào)度

EOS.IO 軟件不能強迫區(qū)塊生產(chǎn)者投遞任何操作給任何其他帳戶。每個區(qū)塊生產(chǎn)者都需要對處理交易所需的計算復雜度和時間做出主觀測量。無論是用戶生成的還是智能合約自動生成的交易,這一點都適用。

在一個基于 EOS.IO 軟件的區(qū)塊鏈里,在網(wǎng)絡層面上,所有交易會根據(jù)執(zhí)行的 WASM 指令數(shù)來計算帶寬成本。但是使用 EOS.IO 軟件的每個區(qū)塊生產(chǎn)者都可能會使用自己的算法和標準來計算資源的使用情況。當區(qū)塊生產(chǎn)者判定某個交易或賬戶會消耗過多的計算能力時,在生產(chǎn)自己的區(qū)塊時他們會直接拒絕這個交易;但是如果其他區(qū)塊生產(chǎn)者都認為這個交易有效,他們還是會處理該交易。

一般而言,只要有 1 個區(qū)塊生產(chǎn)者認為某個交易有效且在資源使用限制內(nèi),那么其他所有區(qū)塊生產(chǎn)者也會接受這個交易;但是這個交易可能需要多達 1 分鐘才能找到生產(chǎn)者。

在某些情況下,生產(chǎn)者創(chuàng)建的區(qū)塊可能包含可接受范圍之外的數(shù)量級的交易。遇到這種情況,下一個區(qū)塊生產(chǎn)者可以選擇拒絕該區(qū)塊,這個僵局將會被第三個生產(chǎn)者打破。這和過大區(qū)塊導致網(wǎng)絡傳播延遲沒什么區(qū)別。EOS.IO 社區(qū)會注意到這種濫用模式,并最終移除惡意生產(chǎn)者的投票。

這種對計算成本的主觀評估使得區(qū)塊鏈不必精確和確定地測量交易需要運行多長時間。有了這個設計就沒必要精確地計算指令數(shù),這可以在不違反共識的情況下顯著增加優(yōu)化性能的機會。

延遲交易

EOS.IO 軟件支持延遲交易,這是一種被調(diào)度到將來執(zhí)行的交易。這使得計算能夠被分配到不同的分片中,并且能夠創(chuàng)建持續(xù)調(diào)度執(zhí)行連續(xù)交易并長時間運行的進程。

上下文無關的操作

上下文無關的操作是指包含僅依賴交易數(shù)據(jù),而不依賴區(qū)塊鏈狀態(tài)的計算。比如說,簽名驗證這種計算,只需要交易數(shù)據(jù)和簽名以確定簽署交易公鑰。在區(qū)塊鏈必須執(zhí)行的單個計算中,這是最昂貴的一種,然而由于這種計算是上下文無關的,所以它可以被并行執(zhí)行。

上下文無關的操作和用戶的其他操作類似,只是它們無需訪問區(qū)塊鏈狀態(tài)來執(zhí)行驗證。這不僅使得 EOS.IO 軟件能夠并行地處理所有上下文無關的操作,比如簽名驗證;更重要的是,還可以實現(xiàn)通用簽名驗證。

通過支持上下文無關的操作,Sharding,Raiden,Plasma,State Channels 等擴容技術變得更加可并行和實用。這項技術的開發(fā)可以實現(xiàn)高效的區(qū)塊鏈間通信和潛在的無限可擴展性。

治理(Governance)

治理是指人們在社區(qū)中的一系列管理流程,借此人們可以:

就那些軟件算法無法完全捕獲的集體行動的主觀問題達成共識

執(zhí)行他們做好的決定

通過章程修正案來修改治理規(guī)則

基于 EOS.IO 程序的區(qū)塊鏈實現(xiàn)的治理過程,可以有效指導區(qū)塊生產(chǎn)者的現(xiàn)有影響。先前的區(qū)塊鏈由于缺少明確的治理過程,而依賴于臨時的、不正式的治理過程,常引起爭議,最終導致結果不可預測。

基于 EOS.IO 程序的區(qū)塊鏈所認可的是權利來源于將那些權利委托給區(qū)塊生產(chǎn)者的代幣持有者。區(qū)塊生產(chǎn)者被賦予了受限且經(jīng)過驗證的權限,他們可以利用這些權限,完成賬戶凍結,更新有缺陷的程序,或者提議對基本協(xié)議的硬分叉更改。

區(qū)塊生產(chǎn)者選舉是集成于 EOS.IO 程序之中的。在對區(qū)塊鏈做任何更改之前,這些改動都必須經(jīng)過這些區(qū)塊生產(chǎn)者的批準。如果塊生產(chǎn)者拒絕執(zhí)行代幣持有者所希望的改變,那么塊生產(chǎn)者可能會被投票出局。如果區(qū)塊生產(chǎn)者在未經(jīng)代幣持有者允許的情況下做了更改,那么所有的其他非生產(chǎn)性全節(jié)點驗證器(交易所等)則能夠拒絕掉這些更改。

凍結賬戶

有時,智能合約的行為會發(fā)生異常或者變得不可預測,不再按預期執(zhí)行;或有時,應用程序或賬戶會發(fā)現(xiàn)某個行為會導致其過度消耗資源,當這些問題不可避免地發(fā)生時,區(qū)塊生產(chǎn)者有權去糾正這些問題。

區(qū)塊鏈上的所有區(qū)塊生產(chǎn)者都有權去確定哪些交易會被包含進塊中,這使得他們有能力凍結賬戶。只要 EOS.IO 軟件中 21 個活躍生產(chǎn)者中的 15 個投票達成一致,即可授權凍結賬戶。如果生產(chǎn)者濫用該權力,那么他們則會被投票出局,被凍結的賬戶也將得以解凍。

更改賬戶代碼

當所有其他辦法都失效且有一個"無法停止的程序"以不可預知的方式在運行時,使用 EOS.IO 軟件允許區(qū)塊生產(chǎn)者在不使用硬分叉的情況下替換這些賬戶的代碼。這種替換代碼的的請求類似于凍結賬戶的過程,需要至少 15 個區(qū)塊生產(chǎn)者投票通過。

章程(Constitution)

EOS.IO 程序允許區(qū)塊鏈建立點對點的服務條款,或是在簽署該協(xié)議的用戶之間綁定合約,我們稱之為"章程"。該章程規(guī)定,用戶之間不能完全由代碼來規(guī)定執(zhí)行的義務,而是應該通過建立管轄權和法律法規(guī)以及其他相互接受的規(guī)則來幫助解決出現(xiàn)的爭議。網(wǎng)絡上每筆交易的廣播都必須包含章程的哈希來作為簽名的一部分,從而明確地將簽署人綁定到合約中。

該章程還規(guī)定應考慮源代碼協(xié)議的可讀性。該功能用于明確區(qū)分漏洞和功能,同時引導社區(qū)界定哪些修復是合適的,哪些是不合適的。

升級協(xié)議和章程

協(xié)議的正規(guī)源代碼以及章程規(guī)定,協(xié)議可以進行更新。EOS.IO 程序規(guī)定更新過程如下:

區(qū)塊生產(chǎn)者提議對章程作出修改,并獲取到 15/21 的認可。

區(qū)塊生產(chǎn)者在連續(xù)的 30 天保持并擁有對新章程的 15/21 的認可。

所有用戶都必須表明接受新章程,并以此作為對未來交易處理的條件。

區(qū)塊生產(chǎn)者根據(jù)章程所發(fā)生的變化對源代碼進行修改,并使用新章程的哈希將其提交至區(qū)塊鏈。

區(qū)塊生產(chǎn)者在連續(xù)的 30 天保持并擁有對新代碼的 15/21 的認可。

對代碼所做的更改在 7 天后生效,當源代碼得到正式批準后,給予所有非生產(chǎn)完整節(jié)點 1 周的時間進行升級。

所有未升級到新代碼的節(jié)點會自動關閉。

默認情況下,針對 EOS.IO 程序所做的配置,以及通過更新區(qū)塊鏈來添加新功能的過程需要 2 到 3 個月的時間,而針對不需要對章程做更改的非關鍵性漏洞的修復更新可能需要 1 到 2 個月的時間。

緊急變更

如果軟件出現(xiàn)了會對用戶產(chǎn)生影響的漏洞或是安全問題,急需作出修復,則區(qū)塊生產(chǎn)者可能會因此加快此過程。但是需要加速升級的方式,來引入新功能或者修復無害漏洞可能會與章程的規(guī)定相違背。

腳本和虛擬機

EOS.IO 軟件將會是賬戶間傳遞可信消息(稱之為"操作")的最重要的平臺。腳本語言和虛擬機屬于具體實現(xiàn),與 EOS.IO 的技術設計幾乎是相互獨立的。任何確定性的語言或者虛擬機,只要性能足夠好,并支持沙盒運行機制,都可以和 EOS.IO 的 API 整合起來。

范式定義的操作(Actions)

任何賬戶間的操作都滿足一定的范式,該范式也是區(qū)塊鏈共識狀態(tài)的組成部分。這一范式支持二進制格式和 JSON 格式間的無縫轉換。

范式定義的數(shù)據(jù)庫

數(shù)據(jù)庫狀態(tài)也由類似的范式定義。這一范式使得所有應用儲存的數(shù)據(jù)都遵循特定的格式,既能轉換為可讀性很強的 JSON 格式,又能以高效的二進制格式存儲與操作。

通用多索引數(shù)據(jù)庫 API

開發(fā)智能合約需要一個事先定義好的數(shù)據(jù)庫來追蹤、存儲和查詢數(shù)據(jù)。開發(fā)者們普遍需要支持數(shù)據(jù)排序或多字段索引的數(shù)據(jù)庫,來保證數(shù)據(jù)的一致性。

將認證從從應用中抽離

為了最大化并行運算能力和最小化算力債(計算應用狀態(tài)需要在交易日志中從頭運算),EOS.IO 軟件將驗證邏輯分成了三部分:

驗證一個操作在內(nèi)部是一致的。

驗證所有的前置條件是有效的。

修改應用狀態(tài)。

驗證操作的內(nèi)部一致性是只讀操作,且不需要區(qū)塊鏈狀態(tài)信息。這意味著這一操作可以最大程度地并行進行。驗證前置條件的有效性(比如必要的余額)也是只讀操作,因此也可以利用并行機制。只有修改應用狀態(tài)這一步需要寫操作,并且對每個應用必須嚴格按照順序執(zhí)行。

認證是用來驗證操作是否可以被執(zhí)行的一個只讀過程。而(操作涉及的)真正的業(yè)務則是應用程序來完成的。當一個操作發(fā)生的時候,這兩部分工作都需要實時計算。好消息是,一旦(包含該操作的)交易被打包進了區(qū)塊鏈,認證操作也就不再需要重復進行了。

跨鏈通信

EOS.IO 的設計能促進跨鏈通信,實現(xiàn)方式是簡化生成操作存在證明和順序證明。這些證明和圍繞操作傳遞設計的應用架構一起,使得跨鏈通信的細節(jié)和驗證工作對應用開發(fā)者不可見,開發(fā)者看到的只是更高層次的抽象。

用于輕客戶端驗證的默克爾證明

如果客戶端不需要處理全部交易的話,和其他區(qū)塊鏈的結合將變得非常容易。畢竟類似交易所這樣的客戶端,它只關心資產(chǎn)的轉入和轉出。理想情況下,交易所的鏈可以用轉賬交易的輕量默克爾證明(來完成交易所業(yè)務),而不是完全信任某個區(qū)塊生產(chǎn)者。每條鏈的區(qū)塊生產(chǎn)者都希望和其他鏈同步的開銷盡可能地小。

輕量客戶端驗證(LCV)的目標是生成相對輕量的存在證明,這些證明可以被任何關心一個輕量的數(shù)據(jù)集的客戶端用來驗證。在上述例子中,LCV 的目的就是為了用來證明某筆交易已經(jīng)被包含進某一特定區(qū)塊,而這一區(qū)塊已經(jīng)被某條特定的鏈所收錄。

比特幣支持交易驗證的功能,這一功能基于一個假設,那就是所有的節(jié)點都可以訪問到全部的區(qū)塊頭歷史數(shù)據(jù)(區(qū)塊頭數(shù)據(jù)每年增加 4MB)。在每秒 10 筆交易的吞吐下,一個驗證用到的存儲空間約為 512 個字節(jié)。對于 10 分鐘一個區(qū)塊的比特幣來說,這是可行的。但對于擁有 0.5 秒的出塊速度的 EOS.IO 軟件來說,這個機制顯然不夠輕量。

任何有不可逆區(qū)塊頭數(shù)據(jù)的用戶在交易被區(qū)塊記錄后,都可以使用 EOS.IO 提供的輕量證明。輕量證明的哈希連接(hash-linked)結構表明,最多只要 1024 個字節(jié),即可驗證任何一筆交易的存在與否。

考慮到區(qū)塊鏈中的區(qū)塊的 id 和區(qū)塊頭都是可信的且不可逆的,因此證明某個區(qū)塊被包含在某個區(qū)塊鏈中也是可行的。這類證明最多只需 ceil(log2(N)) 次摘要計算即可完成,其中 N 為區(qū)塊鏈中的區(qū)塊個數(shù)。就 SHA256 這種摘要算法來說,你只需要 864 個字節(jié)就可以在一個有著 1 億個區(qū)塊的鏈上驗證某個區(qū)塊的存在。

使用合適的哈希連接(hash-linking)機制生產(chǎn)區(qū)塊以啟用上述證明,幾乎不會帶來什么額外開銷,所以這種方式十分可行。

若要在其他鏈上驗證證明,時間、空間和帶寬上都有很多優(yōu)化空間。追蹤全部的區(qū)塊頭(每年 420MB 遞增)可以將證明維持在比較小的空間占用。僅追蹤最近的區(qū)塊頭會在最小長期存儲和證明大小之間實現(xiàn)平衡。另外也可以采用惰性求值的方式,記錄過去的證明的中間哈希值。新證明只需要包含已知的稀疏樹的連接。具體選取何種方式,取決于默克爾證明引用的帶有交易的外部區(qū)塊的比例。

當互聯(lián)和耦合程度達到一定的復雜度之后,將兩條鏈的數(shù)據(jù)合并將更簡單高效,如此一來也就不再需要默克爾證明了。因為性能的原因,跨鏈證明的頻度當然是越小越好。

跨鏈通信的延遲

當和外部區(qū)塊鏈進行通信的時候,區(qū)塊生產(chǎn)者必須要 100% 確認一筆交易已經(jīng)被不可逆轉地寫入到外部區(qū)塊鏈之后,才可以將其當作合法輸入。EOS.IO 的區(qū)塊鏈加上 DPOS 算法 0.5 秒的出塊速度,結合拜占庭容錯機制,使得等待上述確認的時間大約為 0.5 秒。任何區(qū)塊生產(chǎn)者若違背上述原則,不等待確認即開始下一步操作,例如交易所在未確認的情況下就將資產(chǎn)沖入用戶賬戶,隨后又將資產(chǎn)取消的行為,都將影響區(qū)塊鏈的共識機制。EOS.IO 軟件使用 DPOS 算法結合拜占庭容錯機制快速實現(xiàn)交易的不可逆性。

完整性證明

當外部的區(qū)塊鏈使用默克爾證明的時候,去知曉處理的全部交易全部有效,迥異于去知曉沒有交易被跳過或省略。因為想要證明"最近全部的交易都已經(jīng)被知曉"是不可行的,而證明“交易歷史記錄里沒有被跳過的交易”則很容易。EOS.IO 軟件通過給發(fā)送到每個賬戶的每個操作一個順序編號來實現(xiàn)這一點。用戶可以使用這些順序編號來驗證某個特定賬戶的所有操作都已經(jīng)被處理,并且是嚴格按照順序來處理的。

隔離見證(SegWit)

隔離見證(SegWit)是指一筆交易被打包進不可變更的區(qū)塊鏈之后,這筆交易的簽名就與交易無關了。一旦交易變?yōu)椴豢勺兏鼱顟B(tài),簽名數(shù)據(jù)就可以被舍棄,其他人仍然能獲得區(qū)塊鏈當前狀態(tài)。考慮到簽名數(shù)據(jù)容量占據(jù)了多數(shù)交易的很大部分,隔離見證將能大幅縮減磁盤占用和數(shù)據(jù)同步時間。

隔離見證的概念對用于跨鏈通信的默克爾證明同樣適用。一旦一個證明被接受并被不可逆地記錄進區(qū)塊鏈,那么這個證明用到的 2KB 大小的 sha256 哈希值就可以在不影響區(qū)塊鏈狀態(tài)的前提下被舍棄。值得一提的是,將隔離見證用于跨鏈通信節(jié)省的存儲空間的是常規(guī)簽名場景下的 32 倍。

隔離見證應用的另一個場景則是用于(存儲) Steem 的博客文章。利用隔離見證,存儲在區(qū)塊鏈上的將只是一篇篇博客內(nèi)容的 sha256 哈希值,真正的內(nèi)容則存儲于隔離見證數(shù)據(jù)中。區(qū)塊生產(chǎn)者只需要依靠內(nèi)容的哈希值就可以驗證文章的存在。要從交易日志中恢復區(qū)塊鏈當前狀態(tài),生產(chǎn)者無需存儲全部的內(nèi)容。這樣一來,以下的證明方式變得可行:內(nèi)容只要曾經(jīng)有人看過即可,無需永久儲存。

結束語

EOS.IO 軟件的設計理念來源于已被證實的概念和最佳實踐,代表了區(qū)塊鏈技術的重大進步。作為未來全球范圍區(qū)塊鏈社會的宏偉藍圖的組成部分,EOS.IO 使得去中心化應用(dApp)的開發(fā)、部署和管理變得更加容易。

最后編輯于
?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,786評論 6 534
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 98,656評論 3 419
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,697評論 0 379
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,098評論 1 314
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,855評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 55,254評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,322評論 3 442
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,473評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 49,014評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 40,833評論 3 355
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,016評論 1 371
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,568評論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 44,273評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,680評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,946評論 1 288
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,730評論 3 393
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,006評論 2 374

推薦閱讀更多精彩內(nèi)容