區塊鏈100講：EOS 白皮書中文版

時間 2019-11-21

原文原文鏈接

摘要：EOS.IO軟件引入一種新的區塊鏈架構設計，使得去中心化的應用能夠橫向和縱向擴展。經過構建一個仿操做系統的方式來實現，在它之上能夠構建應用程序。該軟件提供賬戶、身份驗證、數據庫、異步通訊和跨越數百個CPU內核或集羣的應用程序調度。此區塊鏈架構能夠擴展至每秒處理百萬級交易，免去用戶的手續費，而且能夠快速簡易地部署去中心化應用。git

PS:本白皮書中提到的加密代幣指的是基於EOS.IO軟件上運行區塊鏈上的加密代幣。並非指在以太坊區塊鏈上分發的ERC-20 EOS代幣。github

1 免責聲明

本EOS.IO技術白皮書草案僅供參考。block.one不保證其準確性或本白皮書中得出結論的正確性,本白皮書「按原樣」提供。不得以任何形式明示，暗示，法定或其餘方式表示和保證，包括但不限於：算法

（i）適銷性，適用於特定用途、適用性、使用、標題或不侵權;數據庫

（ii）本白皮書的內容沒有錯誤;設計模式

（iii）這些內容不會侵犯第三方的權利。安全

對於因使用、引用或依賴此白皮書或此處包含的任何內容而引發的任何形式的損害，即便已被告知存在此類損害的可能性，本公司及其附屬公司概不負責。在任何狀況下，一方或其附屬公司將不會對任何人或實體的任何損害、損失、責任、成本或費用負責，不管是直接的仍是間接的、後果性的、補償性的、附帶的、實際的、懲戒性的、懲罰性的或特殊的使用、引用或依賴本白皮書或此處包含的任何內容，包括但不限於業務，收入，利潤，數據，使用，商譽或其餘無形損失的任何損失。性能優化

2 背景

在 2008 年誕生的比特幣引入了區塊鏈技術,自從那以後企業家和開發者就不斷地嘗試推廣這一技術，以便在單一的區塊鏈平臺上支持更爲普遍的應用程序。網絡

一些區塊鏈平臺在努力支持去中心化應用，特定應用相關的區塊鏈有BitShares去中心化交易所(2014)和Steem社交媒體平臺 (2016), 他們經過提高性能達到每秒處理上千交易、將延遲下降到1.5秒、消除手續費和提供堪比存在的中心化服務的用戶體驗, 目前天天已經有成千上萬的活躍用戶在使用。架構

現有區塊鏈平臺受高昂的交易手續費和有限的計算能力約束，阻礙了區塊鏈技術的大面積應用。併發

3 區塊鏈應用的要求

爲了贏得普遍的應用，構建在區塊鏈之上的應用須要一個知足如下要求的平臺：

支持百萬級別用戶

像 Ebay、Uber、AirBnB 和 Facebook 這樣企業，須要區塊鏈技術能支持每日數以千萬的活躍用戶。在某些狀況下，只有用戶羣體達到一個足夠的數量後應用纔有價值,所以一個能夠處理海量用戶的平臺是相當重要的。

無償使用

應用開發者須要讓用戶無償使用服務的靈活性;用戶爲了使用使用平臺或受益於服務無需必定要付費。一個能夠免費供用戶使用的區塊鏈平臺或許將得到更爲普遍的使用。開發者和企業能夠制訂有效的貨幣化策略。

容易升級和修復bug

基於區塊鏈構建的企業級應用,須要能靈活地爲應用增長新特性。全部軟件都會受到bug的影響，即使是通過了最嚴格意義上的驗證。這個平臺必須具備足夠的魯棒性以便應對不可避免出現的bug。

低延時

一個好的用戶體驗須要具備低延時性,在數秒內就能收到可靠的反饋。高延時會阻礙用戶，而且會讓構建在區塊鏈上的應用比已有的非區塊鏈應用缺少競爭力。

串行性能

一些應用由於順序依賴關係的執行步驟而不能使用併發算法。好比交易所就須要足夠的時序性能來處理很高的交易量，所以平臺必須具備高串行性能。

併發性能

大型可擴展應用須要將計算工做分配到多個 CPU 和計算機之上。

4 共識算法DPOS

EOS.IO軟件使用惟一能知足區塊鏈應用性能需求的去中心化共識算法，委託股權證實(DPOS)。在這種算法下，持有EOS.IO軟件區塊鏈令牌的人能夠經過持續運行的投票系統選擇區塊生產者，任何人均可以選擇參與區塊生產，並有機會生產與總票數成正比的區塊。對於私有鏈，管理者可使用令牌來添加和刪除IT成員。

EOS.IO軟件能夠精確到每3秒鐘受權一個生產者產生一個區塊。若是一個區塊在規定時間以內產生,則這一區塊將被跳過。當一個或多個區塊被跳過期，在區塊鏈中會有6秒或6秒以上的間隔。

在EOS.IO軟件中，區塊經過21名生產者輪流產生。在每一輪的開始時，21個區塊生產者被選出。獲票最高的前20個自動成爲生產者，最後一個生產者根據得票比例必定機率選出(猿哥注: 看了EOS相關源碼, 目前生產者候選數量是30,投票數前20的直接入選, 最後一個根據投票數量從剩餘的10箇中選出, 選出機率近似於其在剩餘候選者中的票數比例)。選中的生產者經過從區塊鏈取到的時間做爲僞隨機數來打亂其順序。打亂順序是爲確保這些生產者與其餘生產者保持持續的鏈接。

若是生產者錯過了一個塊而且在最近24小時內沒有產生任何塊，則這個出塊者將被從候選者列表中刪除,直到它被通知要開始再次生產區塊。經過經過最小化區塊丟失(因不可靠的節點不做爲致使丟失)數量保證了網絡的順利運行。

在通常狀況下，一個DPOS區塊鏈不會經歷任何的分叉，由於區塊生產者是經過合做而非競爭的方式來生產區塊。即使真的出現了分叉，共識也將自動的切換到最長的鏈上。之因此會這樣運做，是由於區塊添加到一個區塊鏈分叉的速率與公用同一共識的區塊生產者比例是相關的。換句話說，具備更多生產者的區塊鏈分叉會比擁有較少生產的那一個條增加的速度更快。並且，沒有一個生產者會同時在兩個分叉上同時生產區塊。若是一個區塊生產者被抓到作這樣的事兒，那麼這個生產者將極可能被投票投出。這些雙重生產行爲對應密碼學憑證能夠用來自動的刪除這些濫用者。

交易確認

一般DPOS區塊鏈100%會有區塊生產者參與。一個交易從廣播開始後平均1.5 秒就能夠99.9%被認爲是確認了。

在一些特殊狀況下例外，軟件出現bug，網絡擁塞，或一個惡意的區塊生產者製造了兩個或更多的分叉。爲了確保一個交易絕對是不可逆的，一個節點能夠選擇等待21個區塊生產者中的15個給出確認。基於一般的EOS.IO軟件配置，在通常狀況下這須要平均45秒的時間。默認狀況下，全部的節點將認爲當21個生產者中有15個給出確認後這一區塊就是不可逆的了，而且無論長度如何都不會切換到沒有這一區塊的分叉。

在分叉開始的9秒內，一個節點就能夠警告用戶他們很可能正處於分叉中。在連續丟失2個區塊後，有95%的機率能夠確認一個節點處於分叉中。在連續丟失3個區塊後就有99%的機率確認。能夠經過節點丟失、近期參與比率和其餘參數來構建魯棒性預測模型，從而快速的警告操做者出現了問題。

對於這種警告的反應徹底取決於商業交易的性質，但最簡單的作法就是等待15/21的確認直到警告消失。

交易股權證實TaPoS

EOS.IO軟件須要每個交易包含最近一個區塊頭的哈希值。這個哈希值有兩個目的：防止不包含區塊引用的交易在分叉時重放發生；和通知網絡對應的用戶和他們的股份當前在某個具體的分叉上。隨着時間的推移，全部的用戶直接確認區塊鏈，在這一鏈條上難以僞造假的鏈條，由於假的鏈條根本沒法從合法鏈條上遷移交易。

5 帳戶

EOS.IO軟件容許全部的賬戶使用一個惟一可讀的名稱來索引，長度在2到32個字符之間。這個名稱由賬戶建立者本身選擇。全部的賬戶必須在建立時用極少的賬戶餘額來注資，從而覆蓋存儲賬戶信息的成本。賬戶名稱也支持命名空間，好比@domain這個賬戶的擁有者是惟一能夠建立@user.domain賬戶的人。

在一個去中心化的場景中，應用開發者將會爲新用戶註冊成本買單。傳統商業已經在經過以廣告、免費服務等方式獲取用戶, 獲取用戶也是須要付出成本的。比起來，資助一個新的區塊鏈賬戶的花費簡直微不足道。值得慶幸的是，對一個已經在另外一個應用註冊過的用戶並不須要再建立新的賬戶。

消息及處理

每一個賬戶能夠發送結構化的消息給其餘的賬戶，而且能夠定義腳原本處理他們接收到的消息。EOS.IO軟件給每一個賬戶提供了只有本身的消息處理腳本能訪問的私有數據庫。消息處理腳本一樣能夠給其餘賬戶發送消息。消息和自動化的消息處理的結合決定了EOS.IO如何定義智能合約的。

基於角色的權限管理

權限管理涉及斷定一條消息是否被正確的受權。權限管理最簡單的形式就是檢查一個交易包含必須的簽名，但這意味着必須的簽名是已知的。通常狀況下，權威必然是獨立的個體或者個體組成的羣體，而且是被劃分開的。EOS.IO軟件提供了聲明式的權限管理系統，經過管理誰能夠在什麼時間作什麼來給用戶細力度和高維度的控制。

受權和權限管理被標準化和脫離應用的商業邏輯是不可取的。這使得管理權限的工具得以被開發，既知足常規的需求又爲性能優化提供了重要的可能性。

每個賬戶能夠被任何權重組合的其餘賬戶和私鑰管控。這建立了分層級的權利結構，這反映了現實中的權限分配方式，而且讓多用戶共同管理資產變得從未如此簡單。多用戶控制是安全最大的貢獻者，而且，當用戶使用得當，它能夠極大的消除因被黑而致使被盜竊的風險。

EOS.IO軟件容許賬戶能夠定義與其餘賬戶密鑰的「and」和「or」的組合，而且把這個組合以將特定類型的消息發送到另外一個賬戶。例如，能夠爲用戶的社交媒體賬號提供一個密鑰，給交易所提供一個密鑰。甚至用戶能夠給予其餘賬戶許可以讓其表明本身的賬戶行事，而無需向其餘賬戶分配密鑰。

命名的權限級別

在EOS.IO軟件中，賬戶能夠定義命名的權限級別，每個是由更高級別的命名權限派生而來。每個命名的權限級別定義了一個權威；一個權威是多重簽名閾值校驗，它包含密鑰和／或其餘賬戶的命名權限級別。打個比方，一個賬戶的「朋友」權限級別能夠被設置爲由該賬戶的任何一個朋友無差異的控制。

另外一個例子是Steem區塊鏈，它包含三個硬編碼的命名權限級別：擁有者、活躍和發帖。發帖權限就只能進行如投票和發帖的社交活動，而活躍權限能夠作除了變動擁有以外的全部的事情。擁有者權限的意思是冷存儲而且有能力作任何事。EOS.IO經過容許每一個賬戶持有者定義本身的權限層次結構以及動做的分組來實現相似的管理理念。

命名的消息處理羣組

EOS.IO軟件容許每一個賬戶將他們本身的消息組織到一個命名和嵌套的羣組中。這個命名的消息處理羣組能夠在其餘賬戶配置他們權限級別時被引用。

最高級別的消息處理羣組是賬戶名稱，最低級別的是一個賬戶接收到的單獨的消息類型。這些羣組能夠被這樣的方式引用： @accountname.groupa.subgroupb.MessageType.

在這樣的模型之下，交易所合約能夠經過將掛單的建立和取消分組，從而與充值提現分離開。交易所合約的這樣分組對用戶而言帶來了方便。

權限映射

EOS.IO軟件容許每一個賬戶定義從任意賬戶的一個命名的消息處理羣組與本身的命名的權限級別之間創建映射。舉個例子，一個賬戶全部者能夠將本身社交媒體應用與本身的「朋友」權限羣組創建映射。有了這個映射，任何朋友能夠以這一賬戶的身份在這一賬戶的社交媒體上發帖。儘管他們將以賬戶全部者的身份發帖，他們仍然使用本身的密鑰來簽名消息。這意味着老是能夠辨識出是哪個朋友在以何種方式使用賬戶。

評估權限

當@alice以"Action"類型發送一條消息給@bob時，EOS.IO軟件首先會檢查@alice是否爲@bob.groupa.subgroup.Action定義過權限映射。若是什麼都沒有找到，緊接着檢查@bob.groupa.subgroup映射，而後是@bob.groupa，最後@bob將被檢查。若是都沒有找到，那麼假定映射爲命名的權限羣組@alice.active。

一旦一個映射被識別，則經過閾值多簽名流程驗證簽名權威，而且關聯權威與命名的權限。若是失敗了，則躍遷至父權限，直至擁有者權限，@alice.owner。

默認權限組

該技術還容許全部賬戶都有一個能夠作全部事情的"擁有者"權限組，和一個除了更改全部者組以外能夠執行全部操做的「活躍」權限組。全部其餘權限組均派生自「活躍」權限組。

權限並行評估

權限評估過程是「只讀」的，而且經過交易對權限的變動在一個區塊結束以前不會起做用。這意味着對全部的交易對應的密鑰和權限評估能夠被並行執行。此外，這意味着一個快速的權限驗證是可行的，它無需啓動會引發回滾需求的高成本的應用邏輯。最後，這意味着交易權限能夠被評估即使接收到等待的交易，而且以後無需再從新評估。

從各方面考慮，權限驗證佔據了驗證交易計算量的很大比例。讓其只讀和廣泛的併發處理將會使得性能有一個質的飛躍。

當從消息日誌中從新生成肯定性狀態時再也不須要重複的權限驗證。事實是一個交易若是被包含近了一個被認爲不存在問題的區塊時它就有足夠的理由跳過這步這將極大減小由於區塊鏈增加拉去過去記錄時的計算量。

能夠強制延時的消息

時間是安全的關鍵組成部分。在大多數狀況下，一個私鑰在沒有被使用前都無從知曉它是否被偷竊。當人們有須要密鑰的應用在天天聯網使用的電腦上運行時，基於時間的安全會更爲重要。EOS.IO軟件讓應用開發者能夠指明消息必須在被加到一個區塊以前等待最小的時間間隙。在此期間，這些消息能夠被取消。

用戶能夠在消息廣播出去後經過郵件或者文字消息的形式收到通知。若是他們沒有受權，那麼他們可使用賬戶恢復流程來恢復賬戶並撤回消息。

延時長短視操做敏感性而定。爲一杯咖啡付款能夠沒有任何延時，幾秒以內就不可逆了，而購買一個房子也許須要72小時的結算期。轉移整個賬戶到一個新的控制可能須要長達30天。具體的延時選擇由開發者和用戶本身來作選擇。

恢復被盜竊的密鑰

EOS.IO軟件提供給用戶一種找回本身失竊密鑰控制權的方式。一個賬戶的全部者可使用過去30天任何活躍的擁有者密鑰與事先指定的合做者賬戶給出的批准來重置本身賬戶的密鑰。賬戶的恢復合做者在沒有全部人幫助的狀況下沒法重置賬戶的控制權。

黑客嘗試進行恢復流程是無心義的，由於他們已經「控制」了賬戶。此外，就算他們真的進行這一流程，恢復合做者也會詢問身份證實和多因素認證 (手機和郵件)。這會讓黑客脫做出讓步或者無功而返。

這一流程與簡單的多重簽名有很大差別。在多重簽名中，另外一個公司要參與全部轉帳的執行，但在恢復流程中，它卻只在恢復時才起做用對天天的轉帳無從干預。這大大的下降了參與者的成本和法律責任。

6 應用程序的肯定性並行執行

區塊鏈共識取決於肯定性 (可重現的) 的行爲。這意味着全部的並行計算必須是不能互斥或者具備其餘鎖特性的。沒有了鎖就必須有一些方式能夠確保全部的賬戶只能夠讀取和寫入他們本身的私有數據庫。這也意味着每一個賬戶處理消息是順序的，而併發只能在賬戶層面進行。

使用EOS.IO軟件，區塊生成器的工做是將消息傳遞到獨立的線程中，以便它們能夠並行地評估。每一個賬戶的狀態由且只由發送給它的消息決定。進度表由區塊生產者輸出而且會被肯定性的執行，可是生成進度表的過程卻不必定是肯定性的。這意味着區塊生產者可使用併發算法來調度交易。

並行執行的一方面意味着當一個腳本生成了一個新的消息，它不會當即被髮送，而被安排在下一個輪訓中發送。不能立馬發出的緣由是接受者可能在另外一個線程中活躍的變動本身的狀態。

最小化通訊延遲

延遲是一個賬戶從發出一條消息給另外一個賬戶，直到收到迴應的這段時間。咱們的目標是在一個單獨的區塊中包含兩個賬戶交換消息的來去信息，而不用在每條消息間等待 3 秒鐘。爲了作到這一點，EOS.IO 軟件將每一個區塊劃分爲循環。每一個循環劃分爲線程，每一個線程包含了交易的一個列表。每個交易包含了待發送的消息集合。這個結構能夠被可視化爲一個樹，其中交互層彼此並行，各自被順序的執行。

區塊

循環 (順序) 線程 (並行) 交易 (順序) 消息 (順序) 接受者和被通知賬戶 (並行)

在一個循環中生成的交易能夠在後續的任何一個循環或者區塊中被髮送。區塊生產者會持續不斷的向區塊中添加循環直到最大的牆上時間到了或者沒有更多的新交易要發送。

能夠對一個區塊使用靜態分析來驗證同一個循環內不存在兩個線程包含同一賬戶下對交易的變動。只要保持不變一個區塊就能夠並行的運行全部的線程。

只讀消息的處理

有些賬戶能夠在傳遞/失敗的基礎上處理消息而不修改內部狀態。若是是這樣的話，那麼這些處理程序能夠並行執行，只要只有一個特定的賬戶的只讀消息處理程序包含在一個或多個線程在一個特定的週期。

多賬戶的原子化交易

有時咱們須要確保消息自動的被多個帳戶傳遞和接收。在這種狀況下，消息會被放在同一個交易內，帳戶會被分配到同一個線程，而且消息被順序的添加。這種狀況對性能是不理想的，當用戶使用涉及到「帳單」時，他們將在交易內以帳戶惟一索引被列入其中。

基於性能和成本緣由最好減小涉及兩個或多個重度賬戶的原子性操做。

區塊鏈狀態的部分評估

擴展區塊鏈技術使得組件化成爲必要。每一個人不該該執行全部的事務，尤爲是當其只須要運行應用的一個小的子集。

一個交易所應用開發者運行一個完整節點位的是爲其用戶展示全部的狀態。這個交易所應用沒有與社交網絡創建關聯的必要性。 EOS.IO軟件容許任何的完整節點選擇應用的任何子集來執行。傳遞給其餘應用的消息能夠被安全的忽略掉，由於應用程序的狀態徹底由傳遞給它的消息派生。

這與其餘賬戶的溝通有一些重要的影響。最重要的是，不能假定其餘賬戶的狀態能夠在同一臺機器上訪問。這也意味着，雖然很容易啓用「鎖」來容許一個賬戶同步調用另外一個賬戶，若是其餘賬戶不駐留在內存中，這種設計模式就會出現問題。

全部帳戶賬戶間的狀態通訊必須經過包含在區塊鏈中的消息進行。

自主最優調度

EOS.IO軟件並不能爲區塊生產生者爲任何其餘賬戶送達的任何信息負責。每一個區塊生產者要對計算的發雜讀和處理一個消息的時間本身進行主觀上的預測。這同時適用於用戶生成的和腳本自動生成的交易。

在運行EOS.IO區塊鏈的網絡層面，EOS.IO系統處理的每一筆交易都有固定的計算帶寬成本，無論它是耗時0.01ms仍是10 ms。可是，每一個單獨的區塊生成者會使用它們本身的算法和度量來衡量資源使用。當一個區塊生產者判定一個交易或者賬戶消耗了不相稱的大量的計算資源時，他們能夠在生成本身的區塊時拒絕該交易；可是，若是其餘區塊生產者認爲交易是有效的，他就仍須要處理該交易。

通常而言，只要一個區塊生產者認爲交易在資源使用限度內是有效的，那麼其餘區塊生產者就也要接受，但可能交易傳遞給生產者就要花費1分鐘。

在某些狀況下，生產者能夠建立包含可接受範圍以外的數量級的塊。在這種狀況下，下一個區塊生產者可能會選擇拒絕區塊和束縛將被第三個生產者打破。這和由於區塊過大致使的網絡延時沒什麼打不一樣。社區會注意到模式的異常並最終會將票從流氓生產者哪裏刪掉。

這種對計算成本的主觀評估將區塊鏈從必須精確和肯定的預測一些東西要花多長時間來運行這一問題中解放出來。有了這一設計就不須要精確的數指令，將極大的增長優化的可能性又沒必要打破共識。

7 Token模型與資源使用

PS:本白皮書中提到的加密代幣指的是基於EOS.IO軟件上運行區塊鏈上的加密代幣。並非指在以太坊區塊鏈上分發的ERC-20 EOS代幣。

全部區塊鏈都是資源受限的，要防止濫用。在EOS.IO軟件中，應用程序使用三類資源:

帶寬和日誌存儲(磁盤)；
計算與計算儲備(中央處理器)；
狀態存儲(內存)。

帶寬和計算有兩部分，瞬時使用和長期使用。區塊鏈將維護全部消息的日誌，完整節點會下載和存儲這些日誌。經過日誌信息，能夠重現全部應用程序的狀態。

可計算債務是一個必須經過消息日誌從新構建狀態的計算結果。若是可計算債務增加變得臃腫則有必要經過快照方式記錄區塊鏈狀態，並丟棄區塊鏈歷史。若是可計算債務增加過快，則它須要花費6個月時間來重放等值與1年的交易。這很不可取，所以，可計算債務須要被細心的管理。

區塊鏈狀態存儲是經過訪問應用邏輯獲取的信息。它包括諸如掛單和帳戶餘額等信息。若是狀態從未被應用讀取則它不會被存儲。好比，博客發佈的內容和評論如未被應用邏輯讀取則他們就不該該存儲在區塊鏈狀態中。同時，發佈的內容／評論的存在、投票的數量和其餘屬性要做爲區塊鏈狀態的部分被存儲下來。

區塊生產者對外發布她們可用的帶寬，計算能力和狀態。EOS.IO 容許賬戶按比例消耗一個3天對賭合約中的可用資源。舉個例子，若是一個基於EOS.IO的區塊鏈啓動了，一個賬戶持有全部token發行總量的1%，那麼賬號就具備使用1%狀態存儲空間的能力。

使用EOS.IO軟件，帶寬和計算能力將被分配到部分儲備基礎中，由於它們是短暫的(未使用的容量不能存儲下來供未來使用)。EOS.IO軟件將使用相似於Steem的算法來限制帶寬使用速率。

客觀和主觀度量

如前所述，檢測計算使用的性能和優化的影響很大；所以，全部資源的使用限制，最終都是主觀的，執行依靠我的的算法和區塊生產者進行估計。也就是說，有一些事情是微不足道的客觀衡量。發送的消息數和存儲在內部數據庫中的數據大小是便宜的客觀衡量。的EOS.IO軟件讓區塊生產者採用相同的算法應對客觀的量，但能夠在主觀量上選擇採用更嚴格的主觀測量算法。

接收方付費

傳統上來講，企業爲辦公場地、計算力和其餘爲了運行企業而須要的成本買單。客戶從企業購買具體的產品，產品銷售產生的利潤來蓋過企業運做的成本。相似的，沒有哪一個網站要求來訪者爲蓋過運做成本而支付。所以，去中心化應用也不該該強制用戶由於使用了區塊鏈而直接爲區塊鏈支付。

EOS.IO軟件不要求用戶直接向區塊鏈支付，所以不限制或阻止企業肯定其產品的貨幣化策略。

委託能力

若是一個區塊鏈是使用EOS.IO軟件開發的，而其令牌是由一個持票人持有，他可能不須要當即消耗所有或部分可用帶寬，這樣的持有者能夠選擇將未消耗的帶寬給予或租給他人；使用EOS.IO軟件的區塊生成者將識別這樣的受權並直接分配相應帶寬。

分離交易成本與Token價值

EOS.IO軟件的一個主要優勢是應用程序可使用的帶寬徹底獨立於token價格。若是應用程序全部者持有相應數量的令牌，那麼應用程序能夠在固定的狀態和帶寬持續運行。開發人員和用戶不會受到token市場價格波動的影響。EOS.IO軟件區塊生成者可以獨立於token價格而天然地增長帶寬、計算資源和每一個令牌的可用性。

EOS.IO軟件會獎勵區塊區塊生成者必定數量的token。token的價格將會影響區塊生成者可以購買的帶寬、存儲和計算資源；在這個模型下,隨着token價格的升高, 網絡性能也會天然提升。

狀態存儲成本

因爲帶寬和計算資源能夠被委託，所以應用程序的狀態存儲須要應用程序開發者持有必定token直到狀態被刪除。若是狀態永遠不會被刪除那麼對應的token實質上不是流通中token了。

每個用戶賬戶須要一個肯定數量的存儲；所以每個賬戶必須保持一個最小的餘額。隨着網絡存儲能力的不斷提高，最低餘額的要求將會降低。

塊獎勵

每次生成一個塊時，EOS.IO軟件都會獎勵該區塊生產者新的token。所建立的token數量由全部區塊生成者所公佈的指望報酬的中位數決定。EOS.IO軟件可能會配置區塊生成者所得獎勵上限，以便讓token的增加率不超過5%。(猿哥注:目前2018-04-07最新規則是獎勵1%的token給節點,另外4%留做其它用途)。

社區效益應用

除了加入基於EOS.IO軟件的區塊生成者團隊，用戶還能夠選擇3個社區福利應用，也稱爲智能合約。這三個應用將接收至多一個按照配置百分比對應的token年供應量減去每一年提供給區塊生產者的token量。這些智能合約將按照每一個應用接收到的token持有者的票的比例對應的token。這些應用或者智能合約能夠被token持有者選出的新的應用或智能合約所替代。

8 治理

治理是人們在主觀問題上達成共識的過程，而這沒法徹底用軟件算法來捕獲。EOS.IO軟件實現了一個治理過程，有效地影響現有的區塊生產者。若是沒有定義好的治理流程，以前區塊鏈依賴臨時的、非正式和經常充滿爭議的方式治理，將直接致使不可預知的結果。

在EOS.IO軟件中，治理權是經過令牌持有者委託給區塊生產者。區塊生產者被授予有限的檢查權威來凍結賬戶，升級有缺陷的應用程序，對底層協議提出硬分叉的改進建議。

EOS.IO軟件的一部分是區塊生產者的選舉。在對區塊鏈沒有作任何變動以前他們必須承認它。若是區塊生產者拒絕token持有者所預期的變動他們就會被投出。若是區塊生產者未經token持有者的受權做出變動，其餘的非生產、完整驗證(交易所等)會拒絕這些變動。

凍結賬戶

有時一個智能合約的行爲處於一種一場或不可預測的狀態而且沒法按照預期執行；另外一些時候一個應用或賬戶也許發現了一個能夠銷燬不可想像數量資源的漏洞。當這些問題不可避免的發生時，區塊生產者有能力來扭轉這一局面。

全部區塊鏈上的區塊生產者都有能力來決定哪些交易被加到區塊中，這給了他們凍結賬戶的能力。EOS.IO軟件凍結一個賬戶時須要17/21活躍區塊生產者的投票比例,才能正式凍結。若是生產者濫用權利他們會被淘汰，而對應凍結的賬戶也會解凍。

更改賬戶代碼

當其餘一切都失敗了，而「不可阻擋的應用程序」以一種不可預知的方式運行時，EOS.IO軟件容許區塊生成者在不須要硬分叉整個區塊鏈的狀況下替換賬戶的代碼。與凍結賬戶的過程相似，此代碼的替換須要17/21的活躍被區塊生產者投票。

憲法

EOS.IO應用使得區塊鏈建立了一個點對點的服務條款協議或者綁定用戶到一個合約，這都須要用戶對其簽名，簡稱「憲法」。憲法的內容定義了僅僅依靠代碼沒法在用戶間履行的義務，同時經過創建管轄權和可選的法律來解決相互間的爭端。每一個在網絡廣播的交易都必須將憲法的哈希值做爲簽名的一部分，從而顯性的將簽名者綁定在合約中。憲法還定義了人類可讀意圖的源代碼協議。這個意圖是用來識別錯誤和功能之間的差別，當錯誤發生時，引導社區對什麼是適當或不當修復。

升級協議和憲法

EOS 軟件使用權威的源代碼定義憲法和協議，同時也定義了憲法及協議的更新方法。對憲法或協議進行變動，需完成如下步驟：

（1）區塊生產者對憲法提出改建意見並得到17/21同意。（2）區塊生產者持續同意達到17/21且連續30天。（3）全部用戶須要使用新的憲法來作簽名。（4）區塊生產經過變動代碼的方式來影響憲法而且提交一個git記錄的哈希值。（5）區塊生產者持續17/21同意連續30天。（6）7天后改成會起影響的代碼，給全部完整節點1周時間在確認源碼後進行升級。（7）全部未升級到最新代碼的節點被自動關掉。

按照EOS.IO的默認配置，添加新特性升級區塊鏈的流程須要2到3個月，而修復通常的bug不須要更改憲法須要1到2個月時間。

緊急變動

區塊生產者能夠推薦軟件的變動當bug是傷害性bug或安全溢出影響用戶使用的。通常來講，這多是對憲法的加速更新，引進新的功能或修復無害的錯誤。

9 腳本和虛擬機

EOS.IO首先會是一個平臺用於協同用戶間認證消息的傳遞。腳本語言和虛擬機的具體實現與EOS.IO技術的設計是分離的。任何語言或者虛擬主機，只要肯定並適合沙盒，帶有足夠的運行效率都可以和EOS.IO軟件API對接。

模式定義的消息

因此用戶間發送的消息都是經過模式定義定義出來的，它是區塊鏈共識狀態的一部分。這個模式容許消息在二進制與JSON格式之間無縫的轉換。

模式定義的數據庫

數據庫狀態也是經過相似的模式來定義。這是爲了確保全部應用存儲的數據是能夠轉化爲人類可讀的JSON但存儲和控制時使用高效的二進制。

分離受權與應用

爲了最大化並行運算，同時將從交易日誌中從新生成應用程序狀態的計算消耗降至最低，EOS.IO軟件將驗證邏輯分爲三個部分:

（1）驗證消息是否內部一致；（2）驗證全部前提條件是否有效；（3）修改應用程序狀態。

驗證消息的內部一致性是隻讀的而且無需訪問區塊鏈狀態。這意味着它能夠以最大併發來執行。驗證前提條件，好比須要的餘額數，是隻讀的所以也能夠受益與並行計算。只有更改應用狀態時須要寫入權限而且必須順序的執行每一個應用。

身份認證是一個驗證消息可被使用的只讀過程。應用程序實際上在發揮做用。同一時間二者都須要被計算，然而一旦消息被包含進區塊它就再也不須要進行消息驗證的操做了。

10 虛擬機獨立架構

EOS.IO軟件的目的是能夠支持多種虛擬機，同時能夠隨着時間推移按需增長新的虛擬機。出於這個緣由，本文不會討論任何特定語言或虛擬機細節，但即使如此，目前也已經有兩種虛擬機正在評估接入EOS.IO軟件。

WebAssembly

Web Assembly是一種爲了構建高性能的Web應用而新興的Web標準。只須要進行少許的更改Web組建就能夠製做爲肯定性的和沙盒化的。Web Assembly的好處是它有着普遍的產業支持而且它可讓智能合約使用熟知的語言進行開發，好比C或C++。

以太訪開發者已經開始更改Web Assembly來提供合適的沙盒與肯定性在他們的以太訪式Web Assembly (WASM)。這種方式讓EOS.IO很容易地與之適配和對接。

以太訪虛擬機EVM

EVM虛擬機已經衆多智能合約所使用，EVM也能夠在EOS.IO軟件中使用。在基於EOS.IO的區塊鏈上，EVM合約能夠在內部沙箱中運行，只須要少許適配就能夠與其它EOS.IO應用程序交互。

11 跨鏈通訊

EOS.IO軟件被設計爲跨區塊鏈通訊友好的。這是經過生成消息存在證實與消息時序證實變的簡單而實現的。這些證實與應用架構設計相結合，即圍繞消息細節的跨鏈傳輸和有效性驗證時隱藏應用程序開發者的架構設計。

用於輕客戶端的Merkle證實

若是客戶端不須要處理全部的交易會讓多區塊鏈間的整合更爲輕鬆。畢竟，一個交易所只須要關心交易所的入帳和出帳，別無他求。若是交易所鏈條可使用資金的輕量merkle證實，而沒必要非要徹底依賴對它區塊生產者的信任會是一個不錯的主意。至少一個鏈的區塊生產者在與其餘區塊鏈同步時更樂意保持儘量小的開銷。

LCV的目標能產生相對輕量存在性證實，使得任何追蹤相對輕量數據集的人能夠驗證其有效性。在這種狀況下，目的是爲了證實一個特定的交易是包含在一個特定的區塊中，區塊包含在一個特定的區塊鏈的已驗證歷史中。

比特幣支持經過全節點的完整記錄獲取每一年4MB大小的區塊頭信息來驗證交易。每秒10個交易，一個有效的證實須要512個字節。這對於有10分鐘間隔的區塊鏈沒有問題，可是對於3秒間隔區塊鏈就顯得不那麼「輕量」了。

EOS.IO軟件使得任何一我的只要他擁有包含交易所對應區塊以後的隨意一個不可逆的區塊頭，他就能夠進行輕量證實。使用下面展現的哈希鏈結構就可使用少於1024字節的大小來完成任意交易的存在性證實。若是假設校驗節點在過去幾天內全部的區塊頭一直增加(2MB的數據)，那麼驗證這些交易將只須要200字節就夠了。

將生產的區塊與恰當的哈希鏈作關聯使得開銷增幅很小，這意味着沒有理由不使用這種方式來生成區塊。

當須要驗證其餘鏈時，有譬如時間/空間/帶寬的多樣化優化能夠作。追蹤所有區塊頭(420MB/年) 將保持證實體積的輕巧。只追蹤最近的頭能夠提供最小長期存儲和證實大小來得到。另外，一個區塊鏈可使用懶惰的評估方法，即它記住過去證實的中間值哈希。新證實只須要包含指向已知稀疏樹的連接。確切的方法將取決於那些包含對Merkle證實引用的交易所在的外部區塊的比例。

必定密度的聯繫後，將變得更爲高效，一個鏈會包含另外一個鏈整個區塊的歷史和消除證據一塊兒，這樣就不須要通訊即可以驗證了。出於性能緣由，應最小化的跨鏈證實的頻率。

跨鏈通訊的延時

當與外部區塊鏈進行通訊時，區塊生產者必須等待直到100%確信一個交易已經被另外一個區塊鏈確認爲不可逆後纔會接收它成爲一個有效的輸入。使用EOS.IO軟件，憑藉3秒出塊時間及21個區塊生產者的委託權益證實，這大概須要45秒的確認時間。若是區塊鏈生產者不等到不可逆轉就確認，就像一個交易所接受了一筆存款然後又撤銷這筆操做，這會影響區塊鏈共識的有效性。

完備性證實

當使用來自外部區塊鏈的Merkle證實時，在已知全部交易均已驗證和已知沒有交易被跳過或遺忘之間有一個重要的差別。雖然不可能證實全部最近的交易是已知的，但有沒有間隙的交易歷史是能夠被證實的。EOS.IO軟件在每一個用戶的每一個傳遞的消息上分配了一個序列號。一個用於可使用這些序列號來證實全部的消息由某個特定賬戶處理，只須要看它是不是按序執行的。