中文版|EOS.IO技術白皮書第二版

本譯文由荊凱在 Harvey老狼、譚智勇、宋承根@OracleChain 及 梓岑 所譯第一版EO 技術白皮書基礎之上修訂增改而成。特此致謝。

譯者： Harvey老狼，譚智勇， 宋承根@OracleChain， 梓岑，荊凱

March 16, 2018

摘要：http://EOS.IO軟體引入了新的區塊鏈架構，旨在實現去中心化應用的縱向和橫向擴展。這是通過創建一個類似操作系統的架構來實現的，可以在上面構建應用。該軟體提供了帳戶，身份驗證，資料庫，非同步通信以及跨越多個CPU內核或集群的程序調度。該技術的最終形式是一個區塊鏈架構，在治理區塊鏈的場景下，可以最終擴展，足以支持每秒數百萬筆交易，消除用戶費用，實現去中心化應用的輕鬆快速地部署和維護。

請注意: 本文中提到的加密通證指的是使用http://EOS.IO軟體所構建的區塊鏈上的加密通證，並不是在EOS 通證發行相關的ETH區塊鏈上的ERC-20兼容通證。

Copyright ? 2018 block.one

無需授權，出於非商業目的和教育用途（即，除了收費或商業目的)，任何人都可以使用、複製或者分發本白皮書中的任意材料，需要註明原文出處和適用的版權聲明。

1.背景

區塊鏈技術源於2008年推出的比特幣，自那時以來，企業家和開發人員一直在努力使該技術通用化，以便在單個區塊鏈平台上支持更廣泛的應用。

雖然一些通用區塊鏈平台還在努力實現第一個能正常運行的區塊鏈應用，針對特定場景的區塊鏈應用諸如BitShares去中心化交易所（2014）和Steem社交媒體平台（2016）已經成為日活躍用戶上萬的成功應用。這兩個應用成功的把性能提高到每秒數千筆交易，延遲降低到1.5秒，降低交易費用，並實現了與當前中心化伺服器的方案相似的用戶體驗。

由於現有的區塊鏈平台使用費用高昂，計算性能有限，阻礙了區塊鏈的廣泛應用。

2.區塊鏈應用的要求

為了得到廣泛使用，區塊鏈上的應用程序要求區塊鏈平台足夠靈活，能夠滿足如下要求：

2.1 支持百萬級別的用戶

想要同Ebay，Uber，AirBnB和Facebook這些企業競爭，需要能夠處理數千萬日活躍用戶的區塊鏈技術。 在某些情況下，除非用戶數足夠龐大，否則應用程序可能無法正常運作，因此，能夠應對大量用戶的平台至關重要。

2.2 使用免費

應用開發人員需要具備靈活性，能夠為用戶提供免費服務; 用戶不必為了使用平台或從平台的服務中受益而付費。用戶可以免費使用的區塊鏈平台，自然會得到更多人的青睞。有了足夠的用戶規模，開發者和企業可以創建對應的盈利模式。

2.3 輕鬆升級和故障修復

基於區塊鏈構建應用程序的企業，需要區塊鏈平台具備靈活性，可以為其應用添加新特性來增強完善。區塊鏈平台必須對軟體和智能合約的升級提供支持。

所有的非小型的軟體都可能會有缺陷，即使是用了最嚴格的形式驗證也是如此。當bug不可避免出現時，區塊鏈平台必須足夠健壯，能夠修復這些bug。

2.4 延遲低

及時的反饋是良好用戶體驗的基礎。延遲時間如果超過了幾秒鐘，會大大影響用戶體驗，嚴重降低基於區塊鏈的應用相對於現有的非區塊鏈應用的競爭力。區塊鏈平台應當支持低延遲的交易。

2.5 串列性能

有些應用程序由於必須順序執行命令，從而無法用並行演算法進行實現。諸如交易所之類的應用經常需要足夠的串列操作處理性能，以應對大量的交易。因此，區塊鏈需要提供強大的串列性能支持。

2.6 並行性能

大型應用程序需要在多個CPU和計算機之間分配工作負載。

3.共識演算法(BFT-DPOS)

http://EOS.IO軟體採用了目前為止唯一能夠符合上述性能要求的去中心化共識演算法 -- 委託權益證明Delegated Proof of Stake (DPOS).。根據這一演算法，在使用http://EOS.IO軟體構建的區塊鏈上持有通證的人，可以通過一個持續進行的投票系統來選擇區塊生產者。任何人都可以選擇參加區塊生產，只要能夠說服通證持有人為其投票，就會有機會參與區塊生產。

http://EOS.IO軟體可以讓區塊每0.5秒生成一個。任何時刻，只有一個生產者被授權產生區塊。如果在計劃的某個時間內沒有成功出塊，則跳過該塊。如果有一個或更多的區塊被跳過，則在區塊鏈上會有0.5s或者更久的空白。

使用http://EOS.IO軟體，區塊的產生是以126個區塊(每個出塊者六個區塊，乘以21個出塊者)為一個周期。在每個出塊周期開始時，會根據通證持有人所投票數選出21個區塊生產者。被選中的區塊生產者的順序會根據15個及以上的區塊生產者的同意，制定出塊順序的安排。

如果出塊者錯過了一個塊，並且在最近24小時內沒有產生任何塊，則這個出塊者將被剔除在考慮範圍之外，直到他們通知區塊鏈可以重新開始產生區塊。這確保了網路的順利運行，把被證明為不可靠的區塊生產者排除在出塊排程之外，通過這一方式使得錯過區塊的數量最小化。

在正常情況下，DPOS塊鏈不會經歷任何分叉，因為區塊生產者並非競爭關係，他們合作產生區塊。如果有區塊分叉，共識將自動切換到最長鏈。這一方式之所以有效，是因為區塊鏈分叉上增加區塊的速度，與具有相同共識的區塊生產者的比例直接相關。換句話說，具有更多生產者的區塊鏈長度將比具有較少生產者的區塊鏈增長速度更快，因為，有更多生產者的區塊鏈分叉上，丟塊更少。

此外，沒有塊生產者可以同時在兩個區塊鏈分叉上生產塊。如果一個塊生產者發現這麼做了，就可能被投票出局。這類雙重生產的密碼學證據，也可能會被用來自動移除作惡者。

在傳統的DPOS演算法上增加了拜占庭容錯演算法(Byzantin Fault Tolerance) ，所有的出塊者都要對所有區塊簽名，以此來確保在同一時間戳或者同一區塊高度上，沒有區塊生產者能夠同時在兩個區塊上簽名。一個區塊有了15個區塊生產者的簽名，該區塊就被認為是不可逆的。任一拜占庭區塊生產者如果想在同一時間戳或者同一區塊高度的兩個區塊上簽名，就不得不留下密碼學證據。在這一模式下，一秒之內就可以達成不可逆的共識。

3.1 交易確認

使用DPOS演算法的區塊鏈，一般出塊者都是100%參與的。一筆交易在廣播後平均0.25秒，就可以認為具有99.9%的確定性了。

http://EOS.IO 在DPOS之外，還增加了非同步拜占庭容錯(aBFT, asynchronous Byzantine Fault Tolerance ), 來實現更快的不可逆性。aBFT演算法使得在1秒內就可以對不可逆性得到100%的確認。

3.2 作為權益證明的事務(TaPoS)

http://EOS.IO軟體要求每個交易都要將最近區塊的區塊頭哈希的一部分包括在其中。 這一哈希有兩個目的：

1.防止在區塊鏈分叉上的交易重放，這些交易並不包含參考區塊;

隨著時間的推移所有用戶都能直接對區塊鏈進行確認，這使得偽造鏈難以作偽，因為偽造的鏈無法從合法的鏈上轉移交易。

4.賬戶

http://EOS.IO軟體允許使用唯一的可讀的名稱來實現對帳戶的引用，名稱最長為12個字元。該名稱由帳戶的創建者選擇。賬戶創建者必須留出RAM空間用於存儲新的賬戶，直至新建的賬戶抵押了通證以獲得自己的RAM空間。

在去中心化的情境下，應用程序開發人員將為創建帳戶支付名義成本來註冊新的用戶。通常企業已經以廣告和免費服務等形式，為所獲取的每個用戶花費了大量資金。相比之下，創建新的區塊鏈帳戶所需的資金成本是微不足道的。並且幸運的是，沒有必要為已經由另一個應用程序註冊的用戶創建帳戶。

4.1 動作(Action)及處理器

每個帳戶可以將結構化的Action發送到其他帳戶，並且可以定義Action被接受後的處理腳本。http://EOS.IO軟體為每個帳戶提供其自己獨有的資料庫，只能由自己的action處理程序訪問。Action處理腳本還可以向其他帳戶發送Action。Action和自動的action處理程序的組合正是http://EOS.IO定義智能合約的方式。

為了支持並行執行，每個賬戶都可以在其資料庫中定義任意數量的範圍(scope)。區塊生產者會對事務進行排程，不會在訪問scope的內存時出現衝突，因此事務可以進行並行執行。

4.2 基於角色的許可權管理

許可權管理主要涉及對某一特定Action是否得到正確授權進行確定。許可權管理的最簡單形式是檢查事務是否具有所需的簽名，但這意味著已經知曉了所需的簽名。通常，授權是與個人或由個人組成的團隊綁定在一起的，並且通常會進行劃分。http://EOS.IO軟體提供了一個斷言式的許可權管理系統，可以讓帳戶就何人在何時能夠做何事上，進行細粒度和高級別的控制。

至關重要的是，身份認證和許可權管理被標準化實現，並與應用程序的業務邏輯分離。這使得開發某種工具以通用方式管理許可權成為可能，並為性能優化提供了巨大的空間。

每個帳戶都可以通過其他帳戶和私鑰的任何加權組合來控制。這種機制創建了一個能夠真實反映許可權在現實中的組織情況的層次化許可權結構，並使得多用戶對賬戶的控制比以往任何時候都更容易。多用戶控制是提升安全性的最重要因素，如果能正確地使用，可以極大地消除黑客盜竊的風險。

http://EOS.IO軟體允許帳戶可以定義何種密鑰和/或賬戶3的組合，可以向另一賬戶發送特定類型的Action。例如，可以為用戶的社交媒體帳號提供一個密鑰，並提供另一密鑰用於訪問交易所。甚至用戶可以給予其他帳戶許可讓其代表自己的帳戶行事，而無需向其他帳戶分配密鑰。

4.2.1 命名許可權級別

使用http://EOS.IO軟體，帳戶可以定義命名許可權級別，每個許可權級別可以從更高級別的命名許可權派生。每個命名許可權級別定義一項授權；這一授權是密鑰和(/或)其他賬戶的命名許可權級別所組成的多簽名檢查的閾值。例如，帳戶的「朋友」許可權級別可以設置為帳戶中的某項Action能被該賬戶的任何朋友的帳戶平等地控制。

另一個例子是Steem區塊鏈，其具有三個硬編碼命名的許可權級別：owner，active和posting。Posting許可權只能執行諸如投票和發布等社交行為，而active許可權除了更改所有者之外，可以做其他任何事情。owner許可權用作冷存儲，它能夠做所有事情。http://EOS.IO對這一概念進行了通用化，允許每個帳戶持有者定義自己的許可權層次結構以及動作的分組。

4.2.2 許可權映射

http://EOS.IO軟體允許每個帳戶定義在合約/動作或任何其他帳戶的合約，以及賬戶自己的命名許可權級別之間進行映射。例如，賬戶持有人可以將賬戶持有人的社交媒體應用程序映射到帳戶持有者的「朋友」許可權組。通過此映射，帳戶的任何朋友都可以和帳戶持有者一樣，在帳戶的社交媒體上發布內容。即使他們會作為帳戶持有者來發帖，他們仍然使用自己的密鑰來為Action簽名。這意味著總是可以辨別出來哪些朋友以何種方式使用了其帳戶。

4.2.3 許可權評估

當從@Alice向@bob發送類型為「Action」的動作(Action)時，http://EOS.IO軟體將首先檢查@alice是否為@bob.groupa.subgroup.Action定義了許可權映射。如果沒有找到任何結果，那麼將會檢查@bob.groupa.subgroup，然後是@bob.groupa，最後是@bob的映射。如果此時仍然沒有找到匹配的結果，那麼假定的映射將是命名許可權組@alice.active。

一旦識別出許可權映射，則啟動多簽名閾值校驗過程對簽名授權進行校驗，把該授權與命名許可權相關聯。如果失敗，那麼它會遍歷父許可權，最終遍歷到其所有者的許可權，@alice.owner。

4.2.3.1 Default Permission Groups 默認許可權組

http://EOS.IO 的技術還允許所有帳戶都有一個可以做所有事情的「owner」許可權組，和一個除了更改所有者組之外可以執行所有操作的「active」許可權組。所有其他許可權組均派生自「active」許可權組。

4.2.3.2 並行許可權評估

許可權評估是個「只讀」的過程，通過事務對許可權進行的修改，在一個區塊結束時才會生效。首先，這意味著所有事務的所有密鑰和許可權評估可以並行執行。其次，這種機制意味著可以快速驗證許可權，而不需要啟動可能會回滾的代價高昂的應用程序邏輯。最後，這意味著當接收到掛起的事務時， 可以執行事務許可權驗證；而在取消掛起、事務生效時，無需重新執行驗證。

考慮到所有因素，許可權驗證佔據了交易驗證中很大比例的計算量。使之成為只讀和並行的過程，可以顯著提高性能。

在對區塊鏈重放，以便從Action的日誌中重新生成確定性的狀態時，並不需要再次評估許可權。事務被包含在一個已知的狀態良好的區塊中這一事實，使其可以跳過評估的步驟。這極大地減少了在對日益增長的區塊鏈重放時的計算工作量。

4.3 強制延遲的動作(Actions)

時間是安全的關鍵組成部分。在大多數情況下，在私鑰被使用前不可能知道其是否已經被盜用。基於時間的安全機制在人們使用一些特殊的應用程序時更為關鍵，這些應用程序需要在連網的電腦上保存密鑰，便於人們日常使用。http://EOS.IO軟體允許應用程序的開發者指定某些Action在包含在區塊後、實際應用之前，必須等待的最短時間段。在此期間，這些動作可以被取消。

當這類Action被廣播時，用戶可以通過電子郵件或簡訊收到相應通知。如果他們未曾授權，那麼他們可以登錄其帳戶來還原帳戶數據並撤回Action。

所需的延遲取決於操作的重要程度。支付一杯咖啡可以在幾秒鐘內確認，不需延遲，而買房子可能需要72小時清算周期。將整個帳戶轉移到新的控制者手上可能最多需要30天。具體延遲的選擇取決於應用程序開發者和用戶。

4.4 密鑰被盜後的恢復

http://EOS.IO軟體為用戶提供了一種在密鑰被盜時恢復其帳戶控制權的方法。 帳戶所有者可以使用在過去30天內活動的所有者(owner)許可權的密鑰，以及賬戶所有者所指派的帳戶恢複合作夥伴的許可，來重置其帳戶上的所有者密鑰。不經過帳戶所有者的配合，帳戶恢複合作夥伴無法重置其帳戶的控制權。

對於攻擊帳戶的黑客而言，由於其已經「控制」該帳戶，因此嘗試執行恢復過程沒有任何收穫。此外，如果他們的確進行恢復的過程，那麼恢複合作夥伴可能需要身份認證和多因素認證（如電話和電子郵件）。這或者會暴露黑客的身份，或者黑客在恢復過程中毫無所得。

這個過程與簡單的多重簽名機制有極大的不同。通過多重簽名的交易，有一個對象會執行並參與每一筆交易。然而，通過恢復過程，恢復過程的合作夥伴僅參與了恢復的過程，並沒有權力參與日常的交易。這極大降低了相關參與者的成本和法律責任。

5.應用程序的確定性並行執行

區塊鏈共識取決於確定性（可重現）行為。這意味著所有並行執行都能在不使用互斥體或其他鎖的原語的情況下正常運行。沒有鎖，必須有方法來確保可能需要進行並行操作的事務，不會產生非確定性的結果。

2018年6月份發布的http://EOS.IO軟體版本會是單線程運行的，但是包含了未來需要進行多線程和並行執行所用到的數據結構。

基於http://EOS.IO軟體構建的區塊鏈，一旦並行執行的功能開啟，區塊生產者的工作是將Action傳遞到單獨的碎片(shard)中，以便它們可以並行地評估。每個帳戶的狀態只取決於傳遞給它的消息。區塊生產者的輸出會產生排程表，並且將被確定性地執行，但是生成排程的過程不必是確定性的。這意味著區塊生產者可以利用並行演算法來對事務進行排程。

並行執行的部分還意味著當腳本生成新的Action時，它不會立即發送，而是在下一個周期中發送它。無法立即發送的原因是因為接收方可能會在另一個碎片(shard)中主動修改自己的狀態。

5.1 通信延遲優化

延遲時間是一個帳戶將動作(Action)發送到另一個帳戶並收到響應所需的時間。http://EOS.IO軟體的目標是使兩個帳戶能夠在單個區塊內來回交換Action，而不必在每個Action之間等待0.5秒。為了實現這一點，http://EOS.IO軟體將每個區塊分為周期（cycle）。每個周期分為多個碎片（shard），每個碎片(shard)包含一組事務列表。每個事務包含一組要傳遞的動作(Action)。該結構可以被可視化為樹，其中各層依據其特性被順序處理或者並行處理。

Block 區塊 Region 區 Cycles (sequential) 周期(順序) Shards (parallel) 碎片(並行) Transactions (sequential) 事務(順序) Actions (sequential) 動作(順序) Receiver and Notified Accounts (parallel) 接收者和通知的賬戶(並行)

在一個周期中生成的事務可以在任何後續的周期或區塊中傳送。區塊生產者不斷地向一個區塊中添加cycle，直至達到了最大的時鐘時間，或者沒有新生成的需要傳送的事務為止。

可以使用區塊的靜態分析來驗證在給定周期(cycle)內是否存在兩個碎片(shards)包含了修改同一個帳戶的事務。只要這種靜態分析機制一直起作用，就可以通過並行運行所有線程來處理區塊。

5.2 只讀Action處理器

部分賬戶可能會處理一些只需要決定通過與否的動作(Action)，而不會改變自己內在狀態。這種情形下，只需要在一個特殊的周期內的一個或多個碎片(shards)中只有某一特定賬號的只讀Action處理器被包含在其中，這些處理器就能並行進行。

5.3 多賬戶的原子事務

有時，我們希望確保 Action 可以被多個帳戶以原子化地方式傳遞和接收。在這種情況下，兩個Action會被放置在同一筆事務中，兩個帳戶將被指派相同的碎片(shard)，Actions會按順序執行。

5.4 對區塊鏈狀態的部分評估

大規模區塊鏈技術組件應該是模塊化的。不需要每個人都運行所有東西，特別是如果他們只需要使用應用的一小部分時，更是這樣。

出於將交易狀態顯示給用戶的目的，交易所應用程序的開發者將維護一個完整的節點。這款交易應用不需要其他社交媒體應用的相關狀態。http://EOS.IO系統允許任何完整節點可以選擇性地運行任意的應用子集。如果你的應用程序不需要依賴其他程序的狀態， 那麼傳遞給其他應用的Action將被安全地忽略。

5.5 對任務排程的主觀優化

http://EOS.IO系統不能強制阻止區塊生產者向其他帳戶發送的任何Action。每個區塊的生成者對處理一筆事務的計算複雜度和時間都有自己的主觀度量，無論這一事務是由用戶生成的還是由智能合約自動生成的。

在使用http://EOS.IO軟體來構建而啟動的一條區塊鏈中，在網路層上所有交易的帶寬成本，都會基於所執行的wasm命令的數量來計費。但是，使用該軟體的每個單獨的區塊生產者會使用它們自己的演算法和測量方式來計算資源的使用情況。當一個區塊生產者發現一筆事務或帳戶已經消耗了大量的計算能力時，他們會在生成自己的塊時拒絕該交易；但是，如果其他區塊生產者認為該事務有效，他們仍然會處理。

一般來說，只要有一個區塊生產者認為一筆事務是有效的，並且所消耗的資源是在限制範圍內的，那麼其他所有的區塊生產者也會接受，但可能要花費多達1分鐘才能使該筆事務傳播到這一區塊生產者處。

在某些情況下，區塊生產者可以創建一個區塊，其中包括在可接受範圍之外的事務。在這種情況下，下一個區塊生產者可能會選擇拒絕這個區塊，而這一僵局將會被第三個區塊生產者終結。這與一個大區塊導致網路傳播延遲所引發的情況沒有什麼不同。社區會注意到這種濫用權力的模式，並最終撤銷對該惡意區塊生產者的投票。

對計算成本的主觀評估，可以讓區塊鏈不必去精確地度量運行某些任務所需要的時長。有了這個設計，就不需要精確地對指令計數，這將極大地增加優化的可能，而不會打破共識。

5.6 延遲交易

http://EOS.IO 軟體支持延遲事務，事務可以安排在未來執行。這可以讓計算轉移到不同的碎片(shard)和/或創建長期運行的持續的流程，可以為持續的事務排程。

5.7 上下文無關的Action

上下文無關的動作(Action)涉及到這樣的計算: 只依賴事務的數據，而不依賴區塊鏈的狀態。例如，簽名驗證的計算，只需要事務數據和簽名來確定簽署該事務的公鑰。這是區塊鏈上必須執行的最昂貴的計算之一，但是因為這一計算是上下文無關的，所以可以並行執行。

上下文無關 Action 就像其他的用戶Action一樣，只是它們無法訪問區塊鏈狀態來執行驗證。這不僅能使 http://EOS.IO 可以並行處理所有上下文無關的動作(Copntext Free Actions)，例如簽名驗證，更重要的是，這為通用的簽名驗證提供了支持。

在支持上下文無關動作(Context Free Actions)的情況下，可伸縮性技術如Sharding、Raiden、Plasma、State Channels等，變得更加可並行化，實用性更強。這一發展可以實現高效的跨區塊鏈通信和潛在的無限可擴展性。

6.通證模型和資源使用

請注意: 在本篇白皮書中，所指的加密通證是使用http://EOS.IO軟體所構建區塊鏈中的加密通證。 並不是在 EOS 通證發行過程中所用的基於以太坊的ERC-20兼容通證.

所有的區塊鏈都是資源受限的，需要系統防止其濫用。在使用 http://EOS.IO 軟體的區塊鏈中，應用程序會消耗三大類資源:

1. 帶寬和日誌存儲 (磁碟);
2. 計算和計算積壓 (CPU);
3. 狀態存儲 (RAM).

瞬時使用和長期使用的這兩類組件都會消耗帶寬和計算。區塊鏈系統將維護所有Action的日誌，這些日誌將會被所有的完整節點下載和存儲。通過日誌，可以重構所有應用程序的狀態。

計算債務( computational debt)是指通過對 Action 的日誌重新生成狀態的計算消耗。如果計算債務的增長太大，就有必要對區塊鏈的當前狀態進行快照，並拋棄區塊鏈的歷史狀態。如果計算債務增長過快，區塊鏈將會耗用6個月的時間來重放1年的交易。因此，對計算債務進行謹慎管理是至關重要的。

區塊鏈存儲的狀態指那些可從應用程序邏輯訪問的信息。它包括諸如訂單和帳戶餘額等信息。如果應用程序不讀取該狀態，則不應該存儲它。例如，博客文章的內容和注釋不被應用程序邏輯讀取，因此它們不應該存儲在區塊鏈的狀態中。與此同時，博文或評論是否存在這一狀態信息、投票數和其他屬性將作為區塊鏈狀態的一部分被存儲起來。

區塊生成者可以公布它們可用的帶寬、計算資源和狀態的容量。http://EOS.IO系統根據賬戶在期限為三天的抵押合約中所抵押的通證數量，允許每個帳戶可以消耗一定比例的可用容量。例如，假設一個基於http://EOS.IO系統的區塊鏈應用啟動，如果一個帳戶持有該區塊鏈提供的總通證的1%，那麼這個帳戶就有可能利用該區塊鏈1%的狀態存儲容量。

使用http://EOS.IO系統的區塊鏈上，帶寬和計算能力的分配是基於部分儲備機制的，因為它們是短暫的(未使用的容量不能存儲下來為將來使用)。EOS. IO系統將使用類似於Steem的演算法來限制帶寬使用速率。

6.1 客觀和主觀度量

正如前面所討論的，可度量計算的使用對性能和優化有很大的影響；因此，所有資源的使用限制最終都是主觀的，並且根據各自的演算法和估計來執行。通常由區塊生產者創建自定義的插件來實現。

除此之外，有些無足輕重的東西，可以進行客觀度量。所傳遞動作(Actions)的數量和存儲在內部資料庫中的數據大小，這些都很容易進行客觀測量。http://EOS.IO軟體允許區塊生產者在這些客觀的度量上應用相同的演算法，但是也可以在主觀度量上選擇更嚴格的主觀演算法。

6.2 接收方支付

歷來是由企業為辦公空間、計算電力以及運營業務所需的其他費用買單。客戶從企業購買特定產品，而這些產品的銷售收入將用於支付企業的運營成本。同樣，沒有任何網站要求訪問者為維護伺服器而支付小額費用。因此，去中心化應用程序不應該強迫它的客戶為使用區塊鏈而向區塊鏈支付直接費用。

使用http://EOS.IO軟體的區塊鏈不要求用戶直接向區塊鏈支付使用費用，因此不限制或阻止企業制定其產品的貨幣化策略。

雖然接收方可以付費，http://EOS.IO 軟體允許發送方為帶寬，計算和存儲付費。這樣的話，應用開發者可以選擇最適合他們應用程序的方式。在很多情況下，對於不想要自己實現定量配給系統(rationing system)的開發者而言，發送方付費這一方式顯著降低了複雜性。應用開發者可以將帶寬和計算能力代理給他們的用戶，然後採用「發送方付費」的模式來使用應用。從終端用戶的角度來看仍然是免費的，但是從區塊鏈的視角看，這是屬於發送方付費的模式。

6.3 授權能力

在一條使用http://EOS.IO系統開發的區塊鏈上，通證的持有人可能不需要立即消耗可用帶寬的全部或部分資源，他們可以選擇將未消耗的帶寬委託或租賃給他人；在這一區塊鏈上運行http://EOS.IO 軟體的區塊生產者將識別這一授權並分配相應的帶寬。

6.4 將交易成本與通證價值區分開

http://EOS.IO軟體的主要優點之一是，應用程序可用的帶寬數完全獨立於通證的價格之外。如果應用程序所有者持有相應數量的通證，那麼應用程序可以在固定的狀態下，使用固定的帶寬資源持續運行。開發人員和用戶不會受到通證的市場價格波動的影響，因此不會依賴於喂價。換句話說，使用http://EOS.IO程序運行的區塊鏈，可以讓區塊生產者能夠自然地增加每單位通證可用的帶寬、計算資源和存儲資源，這與通證的價值無關。

使用http://EOS.IO軟體的區塊鏈，區塊生產者每次產生區塊，都會得到一定的通證獎勵。通證的值將影響一個區塊生成者能夠有錢購買的帶寬、存儲和計算量；這個模型自然會利用通證價值的上漲來提高網路性能。

6.5 狀態存儲成本

帶寬和計算可以可以代理給他人，但是應用程序狀態的存儲需要開發者持有通證，直至狀態刪除為止。如果程序的狀態永不刪除，那麼實際上這部分通證就退出了流通。

6.6 出塊獎勵

在使用http://EOS.IO軟體構建的區塊鏈上，每生成一個區塊，出塊者都會得到一些新的通證作為獎勵。在這一狀況下，新創建的通證數量是由所有區塊生產者公布的期望報酬的中位數而決定的。可以配置http://EOS.IO軟體，限制區塊生成者所得獎勵上限，使得通證供應的年總增長率不超過5%。

6.7 工作提案系統

在基於http://EOS.IO 軟體的區塊鏈上，通證持有人除了選舉區塊生產者，還可以選出一些旨在造福社區的工作提案。獲勝的提案能夠得到通證獎勵，所配置的每年通證的膨脹率減去已支付給區塊生成者的部分，就是這部分獎勵的最大值。這些提案將按照所得到的選票比例來獲得通證的分配，上限是他們進行工作所要求的通證數量。所選出的提案可以由通證持有人新選出的提案所替代。

實現工作提案的系統合約，可能不會在2018年6月份首網啟動時就緒，但是資金機制會上線。區塊生產者開始獲得獎勵時，就會開始為提案系統累積基金。由於工作提案系統會以WASM實現，所以日後可以無需分叉就能夠將其加上。

7.治理

治理是社區之中成員的如下過程：

1. 有些事實無法通過軟體代碼來收集，而人們通過搜集這些事實，就主觀問題達成共識;
2. 執行他們達成的決策;
3. 通過憲法修正案，來變更治理規則。

基於http://EOS.IO 軟體的區塊鏈實現的治理過程，有效地引導了區塊生產者的現有作用。以前的區塊鏈缺乏定義好的治理過程，依賴於臨時、非正式和經常存在爭議的治理過程，從而導致不可預知的結果。

基於 http://EOS.IO 軟體的區塊鏈認為，權力來自於通證持有人，他們將權力代理給區塊生產者。區塊生產者被賦予了有限和經審查的授權，可以凍結賬戶，更新有缺陷的應用，並提出對基礎協議進行硬分叉的變更。

http://EOS.IO 軟體內嵌了區塊生產者的選舉機制。在對區塊鏈進行任何更改之前，這些區塊生產者必須批准它。如果區塊生產者拒絕按通證持有人的期望做出變更，那麼可以投票將其替換。如果未經通證持有者的允許區塊生產者就擅作更改，那麼所有其他非出塊的全節點驗證者(交易所等)將拒絕該更改。

7.1 凍結賬戶

有時，智能合約會發生異常或不可預知的狀況，無法按預期執行；有時，應用程序或帳戶可能會利用漏洞，使其消耗不合理的巨量資源。當此類問題不可避免地發生時，區塊生產者應當有權力糾正。

所有區塊鏈上的區塊生產者都有權選擇將哪些事務包含在區塊之中，這給予了他們凍結賬戶的能力。使用 http://EOS.IO 軟體的區塊鏈將這一權力正式化了，對一個賬戶凍結的決策會提交給21個節點進行投票，如果得到15個節點及以上的通過，則會凍結賬戶。如果出塊者濫用權力，他們可以被投票換掉，而凍結的賬號也會解凍。

7.2 更改賬戶代碼

當其他一切都失敗了，而「無法停止的應用程序」以一種不可預知的方式運行時，使用 http://EOS.IO 軟體的區塊鏈，允許區塊生產者在不需要硬分叉整個區塊鏈的情況下就能替換掉帳戶的代碼。與凍結帳戶的過程類似，替換賬戶的代碼需要得到被選中出塊節點中17 / 21個節點的投票同意。

7.3 憲法

http://EOS.IO 軟體使得區塊鏈可以在簽名用戶之間建立P2P的服務協議或約束性合約，即所謂「憲法」。憲法內容定義了無法通過代碼來強制履行的用戶義務；通過確立司法權和適用法律以及其他公認的規則，促進爭議的解決。每一筆在網路中廣播的事務，其簽名信息中必須包含憲法的哈希值，因此明確的將簽名者綁定至合約。

憲法還定義了源代碼協議的人類可讀的意圖(intent)。在錯誤發生時，這一意圖用於分辨bug和特性的區別，幫助社區確定什麼樣的修復措施才是合理的。

7.4 協議和憲法的升級

http://EOS.IO 軟體定義了如下過程，藉助於此，可以對由源代碼和憲法所定義的協議，進行變更：

1. 區塊生產者提出變更憲法的動議，獲得出塊者中 15/21 的投票通過。
2. 區塊生產者對新憲法的贊成態度，需要維持持續30天。
3. 所有的用戶都需要表示接受新的憲法，作為未來的交易能夠處理的條件。
4. 區塊生產者採納對源代碼的變更以反應憲法的變化，並用新憲法的哈希值將變更提交到區塊鏈上.
5. 區塊生產者對新代碼的贊成態度，需要維持持續30天.
6. 代碼的修改7天之後生效, 源代碼通過後，給非出塊的全節點一周的時間進行更新。
7. 所有未升級代碼的全節點，會自動關閉。

根據http://EOS.IO 軟體的默認配置，更新區塊鏈增加新特性的過程往往耗時2～3個月，而只需要進行非關鍵問題的修復卻不需要修改憲法的更新，需要1到2個月時間。

7.4.1 緊急情況下的變更

如果需要進行軟體變更，以便修復正在損害用戶利益的有害漏洞或安全漏洞，區塊生產者可以加速這一變更過程。通常而言加速新特性更新過程或修復無害的bug，都是違反憲法的行為。

8.腳本 & 虛擬機

http://EOS.IO 軟體首先是一個平台，協調已認證信息(稱為Action，動作)在賬戶間的傳遞。腳本語言和虛擬機的實現細節將獨立於 http://EOS.IO 技術。任何開發語言或虛擬機，只要具有確定性，經過了恰當的沙盒化並具有足夠的性能，，都可以與 http://EOS.IO 軟體的 API集成。

8.1 模式(schema)定義的動作(Action)

在賬戶之間發送的所有動作都是通過模式(schema)來定義的，這是區塊鏈共識狀態的一部分。這一模式(schema)使得 Action 可以在二進位和JSON格式之間無縫轉換。

8.2 模式定義的資料庫

資料庫狀態也是由類似的模式所定義的。這確保了所有應用程序所存儲的所有的數據，都能夠以人類可讀的 JSON 格式解析，又利用了二進位文件的高效性進行操作和存儲。

8.3 通用的多重索引資料庫 API

開發智能合約需要定義好的資料庫模式，用於追蹤，存儲和尋找數據。開發者通常需要按照多個欄位對相同的數據排序或索引，並維持所有索引的一致性。

8.4 驗證與應用程序相分離

為了儘可能優化並行運算，並把從程序日誌中重新生成應用程序狀態時相關的計算債務( computational debt )降至最低，http://EOS.IO 軟體將驗證邏輯分為三個部分:

1. 驗證動作( Action) 的內在一致性;
2. 驗證所有前置條件的有效性; 以及
3. 修改應用程序的狀態

對Action 內部一致性的驗證是只讀的，不需要訪問區塊鏈狀態，這意味著它執行時，可以將並行運算最大化。對前置條件（如所需的賬戶餘額）的驗證也是只讀的，因此也可以受益於並行運算。只有對應用程序狀態的修改才需要寫的許可權，必須對每個程序順序處理。

驗證(Authentication)是一個只讀過程，用於檢驗一個動作(Action)是否可以生效。應用(Application)是實際起作用的過程。這兩種計算都需要實時進行，不過，一旦一筆事務包含在了區塊鏈之中，就不需要再進行驗證操作了。

9.區塊鏈跨鏈通訊

http://EOS.IO 軟體旨在促進區塊鏈間的跨鏈交互，這通過簡化Action存在證明(proof of Action existence)和Action順序證明(proof of Action sequence)的生成過程來實現。這些證明與圍繞Action 傳遞而設計的應用架構結合起來，將跨鏈通訊以及驗證證明的細節對應用的發者隱藏，展現給開發者的是高層次的抽象。

9.1 用於輕客戶端驗證的Merkle證明(LCV)

如果客戶端不需要處理所有的事務(transaction), 那麼，與其他區塊鏈交互將變得非常容易。畢竟，一個交易所只會關注交易所的出賬和入賬信息，而不會關心其它。更理想的情況是，對於交易所自身所維持的鏈來說，如果可以將輕量級的默克爾存款證明應用其中，那麼就不必完全依賴自己的區塊生產者。至少，某個區塊鏈的生產者在同步另一條區塊鏈時，會希望儘可能減小開銷。

LCV的目標是能產生相對輕量級的交易存在證明，其他人只需要追蹤一個相對輕量級的數據集，就可以對此進行驗證。既然如此，目標就是證明一筆特定的事務被一個特定的區塊所包含，並且 某一條特定的區塊鏈的驗證歷史中，已經包含了該區塊了。

比特幣的輕量級驗證方式是，假設所有節點都可以讀取區塊頭數據的完整記錄，區塊頭數據每年增長4MB。 假設每秒產生10筆交易，一個有效的證明需要512 bytes，這對於一個出塊時間為10分鐘的區塊鏈來說是可行的。但對於一個出塊時間為 0.5 秒的區塊鏈來說，這就遠遠談不上「輕量」了。

http://EOS.IO 軟體的輕量級證明中，在某筆交易被包含到區塊鏈之後，只需要對任意一個不可逆的區塊頭進行驗證即可。使用下圖中的哈希鏈表架構，可能只需要不到1024個位元組大小的證明，就可以驗證任意一筆交易的存在。

給定區塊鏈上任意一個區塊的區塊id，以及一個不可逆的可信區塊的區塊頭。可以證明某個區塊是包含在區塊鏈上的。這一證明的演算法複雜度是（log2(N)），其中 N 是區塊鏈上的區塊數量。給定 SHA256 加密演算法的類型，只用 864 個位元組，你就能夠證明在一條包含了 1億個區塊的鏈上，一個任意的區塊是否存在。

生成區塊的時候如果使用合適的哈希鏈表來產生這些證明，只會帶來很小的增量開銷，這意味著沒有理由不以這種方式去生成區塊。

對其他鏈上的證明進行驗證時，在時間、空間和帶寬方面都有很大的優化空間。跟蹤所有區塊頭數據(420 MB/年)可以讓證明的尺寸最小。只跟蹤最近的區塊頭，可以在長期存儲文件的最小化和證明尺寸的最小化之間，得到均衡。或者，一個區塊鏈可以採用惰性評估的方式，只記錄過去證明的中間哈希值。新的證明只需要包含指向已知的sparse tree（稀疏樹）結構的鏈接。實際使用的方式，需要根據在merkle 證明中所引用的交易位於外鏈上所佔的比例來決定。

在一條區塊鏈上，可以將另外一條區塊鏈的所有區塊歷史都包含其中，不需要再進行跨鏈的證明。在跨鏈關聯密度達到一定程度之後，這會是更高效的做法。出於性能考慮，理想情況是儘可能降低將跨鏈證明的頻率。

9.2 跨鏈通訊延遲

與外部區塊鏈通訊時，區塊生產者必須等到一筆事務(transaction)經過外部區塊鏈的確認，達到了100%的不可篡改的確定性之後，才能夠接受該筆事務，認可為有效的輸入。在一條基於 http://EOS.IO 軟體的區塊鏈上，藉助於DPOS 0.5秒的出塊速度，並使用了額外的拜占庭容錯的不可篡改性，這一過程大約耗時為0.5秒。如果某個鏈上的區塊生產者不等到交易不可篡改，就像一個交易所接受了一筆存款而後這筆操作又撤銷了的情況一樣，這會影響這條鏈共識的有效性。http://EOS.IO 軟體使用了 DPOS 和 aBFT(非同步拜占庭容錯)演算法，提供快速的不可篡改性。

9.3 完成性證明

使用外部區塊鏈的merkle 證明，知道所有處理過的事務都是有效的，和知道沒有事務被跳過或忽略，這兩者之間有明顯差別。雖然無法證明最近的所有事務都是已知的，但是，要證明在事務的歷史中不存在遺漏，還是可能的。http://EOS.IO 軟體為傳遞給每個賬戶的每個Action都指定了一個序列號，使得這一點成為可能。用戶可以用這些序列號來證明，與某個賬戶相關的所有的 Action 都得到了處理，並且是按順序處理的。

9.4 隔離見證

隔離見證(SegWit) 是指，在不可逆地將一筆事務包含到區塊鏈中之後，事務的簽名不再具有相關性了。一旦事務具有不可篡改性了，簽名數據可以被剪掉，其他所有人都能夠達成當前的狀態。由於在大多數的事務之中籤名數據佔據了很大一部分，SegWit 能夠明顯地降低磁碟使用量，減少同步時間。

同樣的概念可以用在跨鏈通訊的merkle證明中。一旦一筆證明被接受，並不可逆的記錄到區塊鏈之後，想達成正確的區塊鏈狀態，用作證明的sha256 哈希的2kb文件就不再需要了。同樣使用隔離見證，給跨鏈通訊所帶來的節省程度，是給普通簽名帶來節省程度的32倍。

隔離見證的另外一個例子是Steem的文章。在這一模式下，(在區塊鏈中)一篇帖子只包含博客內容的sha256哈希函數值，博客正文會被放在隔離見證數據中。區塊生產者只需要驗證內容是存在的，並且具有給定的哈希值，而不需要在鏈上存儲博文的內容，就能夠從區塊鏈的日誌中恢復到當前的狀態。這樣做可以在不必永久保存博文內容的情況下，就能夠證明所說的內容曾經存在過。

10.結論

http://EOS.IO 軟體是基於已為實踐所證實的概念和最優實踐的經驗來設計的，代表著區塊鏈技術的根本性進步。它是全球性可擴展的區塊鏈社會宏偉藍圖的一部分 ，在其中，可以輕鬆部署和管理去中心化的應用程序。

聲明：

為方便大家閱讀，HelloEOS適度做了不改變願意的修改。

英文原文地址：

https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md

https://github.com/BlockchainTranslator/EOS/blob/master/TechDoc/EOS.IO%20Technical%20White%20Paper.md

HelloEOS官網：www.helloeos.com.cn

HelloEOS資訊站：www.helloeos.one

微信公眾號：hello-EOS

微博：@helloEOS社區

Telegram：helloeos

Twitter：helloEOS?