選擇代碼庫

目前有以太網協議的8個實現：

• 去http://github.com/ethereum/go-ethereum
• C ++ http://github.com/ethereum/cpp-ethereum
• Python http://github.com/ethereum/pyethereum
• Javascript http://github.com/ethereum/ethereumjs-lib
• Java https://github.com/ethereum/ethereumj
• Haskell https://github.com/jamshidh/ethereumH
• Rust（Parity） https://github.com/ethcore/parity
• Ruby https://github.com/janx/ruby-ethereum

這些實現的區別在于：

• 許可證（GPL，LGPL，MIT，Apache）
• 性能
• 功能完備
• 模塊化
• 易于修改
• 易于集成到其他系統中

對于企業用例，性能可能非常重要。 在對以太坊客戶進行基準測試方面做了一些努力，請參閱：

https://github.com/ethereum/wiki/wiki/Benchmarks

但是，對所有可能具有高性能的客戶端（C ++，Go，Haskell，Java，Parity）的一套全面的基準測試將是一項非常有用的任務。 關于許可，Go是LGPL許可的，C ++是GPL許可的，但是有一種努力（結果仍然不確定）將其重新許可給Apache，Java是麻省理工學院，而Parity是GPL。

配置文件

Ethereum節點必須支持的配置文件有一個非正式標準，它描述了網絡參數。 目標是允許節點輕松連接到測試網絡，專用網絡，并從長遠來看，指定具有不同屬性的替代網絡，包括一致性算法，P2P網絡協議，初始狀態和協議規則。 這里描述了標準：

https://github.com/ethereum/wiki/wiki/Ethereum-Chain-Spec-Format

企業以太坊版應尊重標準的超集，以便以正確的配置設置啟動的節點將充當以太坊公共鏈節點（但有更多API和其他功能對企業用途有用），但節點以不同的方式啟動設置將使用PBFT參與給定的聯盟鏈網絡，或者使用不同虛擬機的測試網絡，或者比公共鏈更早地結合新的可擴展性功能的網絡等。

共識

目前，以太坊客戶支持工作共識的證明。 需要以這樣一種方式模塊化共識算法，即可以使用股權證明（Casper）以及私有鏈特定共識算法，可能的初始目標是PBFT和DPOS（基本上是一輪）羅賓一致算法）。 第一步是準確確定共識算法“類”的“接口”應該是什么樣子。

界面的可能草圖如下：

• submitTransaction(tx) ：向參與節點提交事務。 節點將嘗試將其包含在塊中，或者對其進行投票，或者在一致性算法中執行等效操作。
• sendMessage(msg, node_id) ：向另一個節點發送消息。
• broadcastMessage(msg) ：廣播消息。
• getMostRecent(conf_level) ：獲取滿足給定確認級別的最新塊。 在工作證明或DPOS中， conf_level將表示確認的數量，因此它將返回鏈中的第n個最后一個塊; 在PBFT確認是二進制（即最終確認是即時的）所以它總是返回最近確認的塊。

請注意，公共鏈共識還需要激勵模型，即。 獎勵表現良好并可能懲罰表現不佳的參與者的共識參與者的方法。 我們通過提供兩個選項來抽象：

在處理塊中的每個事務之后自動調用的函數finalize ，它對狀態進行修改并可以使用塊作為輸入。

在處理塊中的每個事務之前自動調用的函數initialize ，這會對狀態進行修改并可以使用塊作為輸入。

請注意， finalize或initialize可能只是調用一些標準契約，并將塊頭作為數據; 以太坊公共連鎖計劃長期采用這種方法。 在財團鏈中，沒有必要使用這些功能來激勵; 但是，它們可能對其他目的有用（例如，自動運行預定的操作）。 因此，由于這些操作的效用并不與共識激勵嚴格相關，因此不應將它們視為共識界面的一部分; 相反，它們應被視為交易處理規則。

在私有鏈環境中，有幾種最常用的共識算法：

• 權限證明 - 基本上，一個具有一個特定私鑰的客戶端構成所有塊
• PBFT （或其他一些傳統的拜占庭容錯共識算法）
• DPOS （或其他一些基于鏈的有限驗證器一致性算法）
• Casper （以太坊的候選人證明 ），帶有固定的驗證器集

PBFT和DPOS（純粹作為一種共識算法，不包括某類令牌持有者對代表投票的能力）各有各的優缺點。 特別：

• 假設至少67％的節點在線且誠實，PBFT在部分同步網絡模型下具有各種屬性（安全性，活躍性等）的學術上強大的形式證明
• PBFT即時終結 - 一旦確認交易一次，就不可能恢復。 DPOS共識的概率很像工作證明（事實上，稍微差一點，因為攻擊者可以看到他們是否有能力提前恢復短程叉），因此雖然“事實上終結”的概念是可能的，它需要幾分鐘才能到達
• DPOS可以支持無限數量的節點，而PBFT在大約30個節點之上變得非常低效，因為每個節點必須在每一輪中向每個其他節點發送消息并從其接收消息。 DPOS這樣做是因為每一輪只包含一個隨機選擇的驗證器
• DPOS在概念上更易于理解和實現，并且直觀地了解它為什么會聚
• 在同步網絡模型中，DPOS可以承受高達49％的拜占庭故障，高于PBFT的33％; 此外，如果DPOS由節點脫機而不是試圖攻擊網絡，DPOS可以承受更多的故障

Casper旨在作為一種加密經濟算法，任何人都可以通過存錢來成為驗證者。 但是，只需指定固定的驗證器集，就可以將其重新用于許可的上下文。 一旦Casper在主要的以太坊客戶端實施，這種方法值得探索。

在需要特定安全屬性的某些情況下，可能需要提供權威證明，并且以太坊的技術更多地用于提供確定性和可驗證的執行和審計屬性，而不是傳統意義上的分散。 因此，實現所有這三個并使每個用戶可以選擇使用哪個給定應用程序是有意義的。

注意 ：有一種常見的誤解，即不同的算法具有廣泛不同的事務處理能力，例如。 DPOS可以處理100 tx /秒，而PBFT可以處理1000 tx / sec等。而在未來的分片區塊鏈的情況下，這可能是真的，在區塊鏈的上下文中，每個節點處理每個事務，但事實并非如此; 無論使用何種一致性算法，處理每個事務都需要相同數量的計算工作量，盡管可能存在小差異，因為某些算法需要在短程分叉的情況下重新計算事務，有些算法可以更安全地允許事務處理鏈中性能的差異通常幾乎完全是由于協議和實現的差異，而不是共識算法（公共鏈容量往往低得多的重要例外）他們的額外經濟限制，更小的節點大小和集中化問題）。

抽象化

在以太坊協議開發中，主要的重要哲學之一是抽象概念：協議本身應盡可能簡單，并盡可能在合同代碼中實現，而不是通過硬協議規則實現。 抽象目標包括：

• 帳戶安全（請參閱https://github.com/ethereum/EIPs/issues/86 ）
• 事務狀態轉換函數（即處理事務的規則）
• 以太（即將醚變為ERC 20令牌 ，就像其他人一樣）
• 日志/事件

抽象的目的如下：

• 降低攻擊面并降低核心代碼的復雜性
• 能夠更輕松地將公共鏈協議硬件化為不同的協議規則，因為它可以通過交換合同代碼來完成
• 能夠更輕松地在測試網絡或私有實現上交換不同的規則集
• 能夠在每個應用程序或每個用戶級別上切換不同的規則（例如，一些用戶希望他們的帳戶由ECDSA保護，一些用戶更喜歡Lamport用于量子證明，而在某些私人鏈條用例中，行業或國家標準要求使用特定形式的密碼術; EIP 86的目標是支持所有這些）

EES可能希望提前實現其中一些抽象功能。

P2P網絡

以太坊目前的P2P網絡是Kademlia架構，詳情如下：

• https://github.com/ethereum/wiki/wiki/%C3%90%CE%9EVp2p-Wire-Protocol
• https://github.com/ethereum/go-ethereum/wiki/Peer-to-Peer

專用鏈可能希望使用相同的網絡代碼（但在配置文件中設置了不同的網絡ID），或者使用其他類型的網絡; 最可能的替代方案是每個節點直接連接到每個其他節點的設計（非常可行，并且在具有少于20個節點的網絡中可能是最佳的）。 此外，還可以選擇定制在網絡或更低級別進行的連接（例如，所有節點是否應位于同一子網中？如果它們在物理上彼此靠近，那么光纖連接是否最佳？）; 許多細節很大程度上超出了EES代碼庫的范圍，但代碼庫應該確保它在許多常見的預期配置下運行良好。

隱私保護協議

有關可用方法的更詳細說明，請參閱https://blog.ethereum.org/2016/01/15/privacy-on-the-blockchain/ 。

蜜蜂

目前，以太坊代碼庫支持一組基本API，用于查詢區塊鏈，查詢合同狀態，過濾日志，發送交易等。進行更復雜查詢的主要方式（例如，在特定令牌中返回特定帳戶的余額）在區塊鏈上發布，在區塊鏈訂單簿上返回要約的要價等，是通過“虛擬交易”的概念。 本質上，這個想法是客戶端可以假裝在本地執行一個事務，這會調用一個返回值的契約函數。 然后API將（可能同步）返回值。

但是，可能需要更多高級API，特別是在不僅需要訪問當前狀態而且還需要訪問先前狀態，獲取有關事務的信息以及更高級的區塊鏈分析形式的用例時; 此外，API還有與API格式兼容的空間，用戶已經熟悉并期望這些API格式。

可能非常有用的特定API類是能夠對區塊鏈進行SQL和類似查詢。 這方面有一些現有項目，請參閱：

• https://www.reddit.com/r/ethereum/comments/4gcsn2/introducing_etherquery_perform_sql_queries/
• https://github.com/jamshidh/ethereum-data-sql

然而，在使這些系統最有效并且廣泛適用于許多用例方面仍有許多工作要做。

用戶界面

以太坊中的用戶界面屬于廣泛類別，包括：

• Mist瀏覽器，以及用HTML / Javascript編寫的應用程序，可以在Mist內部或通過用戶的常規瀏覽器使用
• 阻止探索者如etherchain ， etherscan和ether.camp 。 請注意，與許多其他區塊鏈的類似工具不同，后者主要關注貨幣余額和交易，以太坊區塊探險家往往非常先進和一般，提供合同狀態，功能，內部交易等的觀點; 例如，這是一個ether.camp的DAO視圖：
• geth命令行界面（與web3 Javascript API相同）。

提高效率

驗證以太坊中的塊的過程目前包含以下特別是計算密集型操作：

• 驗證交易簽名
• 運行由事務執行觸發的EVM實例
• 更新Merkle樹，包括計算新的中間散列
• 更新數據庫

已經進行了一些基準測試，表明單個以太坊節點每秒能夠進行大約1000-2000次交易，并且在給定當前軟件的情況下，小型聯盟網絡每秒能夠進行幾百次交易。 這些限制是由于（1）帶寬限制和（2）計算限制的組合而產生的。

在單筆交易中，我們可以期待：

• 1個橢圓曲線簽名驗證（或更確切地說，公鑰恢復）
• 3-10狀態更新（最少3個，對應于發件人以太扣除，收件人以太增加和礦工以太付費;狀態變更合同調用將有更多），對應于Merkle樹的3-10更新，需要~15-100輪次序列化，散列等
• 對底層數據庫進行相應的~15-100更新
• 在合同調用中，至少有一輪VM執行，但可能更多。 對最近的以太坊交易進行的一項非正式調查顯示，在天然氣消費交易中，天然氣消耗量中位數為~50,000氣體，平均為~100,000。

虛擬機優化和預編譯合同

以太坊虛擬機是一種獨特的架構，針對以下屬性進行了優化：

• 小攻擊面，假設其中運行的所有代碼都是不可信的
• 小代碼大小（例如，默認gcc為C ++代碼創建的4kb“樣板”在單個用戶的硬盤驅動器上是可接受的，但當代碼需要位于區塊鏈時完全不可接受; EVM代碼通常低于100字節）
• 完全確定性（請注意，由于使用天然氣進行計量，即使超時也是確定性的;嘗試使用現有虛擬機的大多數其他智能合約框架完全無法實現此目的）
• 啟動新VM實例并關閉實例非常快，因為我們希望每個事務創建和銷毀1-10個EVM實例。 請注意，大多數這些實例可能運行少于100個計算步驟; 因此，“輕量級”至關重要。
• 降低復雜性 - 在用戶打算在合同代碼中實現替代機制的情況下（例如，multisig，環簽名，鏈上令牌），“特權”協議內機制僅用于復制工作并進入而抽象將允許您使用替代機制來替換默認機制。
• 有多個完全兼容的實現（在https://github.com/ethereum/tests上有大約50000個測試用例，其中8個以太坊客戶端中的所有8個VM實現都通過了）

重要提示 ：“氣體”和“以太”不是一回事。 氣體是一種機制，允許EVM內部的計算被確定性地計量，即。 合同以確定性地限制對某些固定數量的計算步驟的調用。 以太是支付交易費用的一種方式，預計交易費用與燃氣消耗量成正比。 以太幣的比特幣模擬是BTC，比特幣模擬的氣體是事務在一個塊中占用的字節數; 在以太坊中，單獨測量字節是不夠的，因為你還需要測量計算，因此需要測量氣體的概念。 在私人鏈上，你不需要用乙醚來支付天然氣; 您可以提出備用規則集，例如，簡單地要求每個事務的最大氣體限制為100萬。

請注意，原始EVM 不是為高性能計算而設計的。 當創建EVM 1.0規范時，關于區塊鏈腳本內部可以完成的工作的大多數想法都在50行代碼之下，包括“if ... then”邏輯和基本算法，并且在這種環境中可以做出強有力的案例EVM執行中即使100倍的低效率也不會對總事務處理時間產生顯著影響，因為大量的事務處理負載以驗證橢圓曲線簽名的形式出現（需要循環通過橢圓曲線添加超過1000次，其中每次添加本身包含許多256位操作）。

然而，最近我們已經意識到在EVM中存在對高性能計算的非常大的需求，特別是為了實現更復雜的密碼術（例如，環簽名，部分同態加密，其他種類的橢圓曲線，燈管簽名）; 因此，我們意識到我們目前在EVM方面的工作還不夠。 我們目前有兩種方法可以同時解決這個問題：

• 基于WebAssembly的可能的新虛擬機（請參閱https://github.com/ethereum/evm2.0-design ）
• EVM改進
• 預編譯合同

WebAssembly計劃是開發一個“轉換編譯器”，它采用WebAssembly代碼并將其轉換為WebAssembly代碼，在每個分支點跟蹤其自身的“氣體消耗”，并在剩余氣體低于零時自動停止。 選擇WebAssembly是因為設計要求在許多情況下類似于以太坊，例如。 用戶將在他們的瀏覽器中運行不受信任的WebAssembly代碼，代碼大小也需要很小，因為代碼是實時下載的，并且已經存在多個實現以及它們之間的兼容性目標。 但是，WebAssembly缺乏氣體計數的概念，并且轉換編譯器將修復該問題，同時允許使用未修改的WebAssembly實現來執行實際操作。 它還將禁止浮點數和潛在的非確定性的其他來源。 請注意，無法保證WebAsssembly將成為主要的公共鏈VM，但進一步開發它并使其成為私人鏈使用的候選者可能是有意義的。

領先的EVM改進建議是添加一組256個64位寄存器，以及專門用于處理這些寄存器的操作碼。 這允許以接近本機速度處理僅需要64位精度的操作。 如果實施此提議，則可以通過在升級的EVM和WASM之間進行雙向編譯來將其與WebAssembly路由合并，從而使WASM成為此升級的EVM的實現之一。

“預編譯合同”是在本機代碼中實現的操作，可以通過在預先指定的地址調用合同來訪問。 目前的預編譯包括：

• 橢圓曲線簽名公鑰哈希恢復（地址0x000....0001 ）
• SHA256（地址0x000....0002 ）
• RIPEMD160（地址0x000....0002 ）

在許多行業用例中，目標是將現有的庫集成到財務計算（例如OpenGamma ）或不同形式的密碼術以符合行業或國家標準，或加速復雜的業務邏輯（例如訂單簿）這需要以非常高的速度運行。 這樣做的應用程序可能希望指定自己的預編譯。 我們建議私有鏈預編譯采用0x000....000400到0x000....0fffff （即1024到1048575）范圍內的地址，以避免與可能的未來公共鏈功能發生沖突。

拒絕服務攻擊和安全性

2016年9月和10月，針對各種以太坊實施和以太坊協議進行了一系列拒絕服務攻擊。 其中很大一部分利用了Go實現中的“二次內存消耗”漏洞，其中客戶端在每次調用時都低效地復制了潛在的大量緩存狀態，從而導致處理速度非常慢或由于客戶端耗盡內存。 此外，由于讀取狀態的操作碼（例如EXTCODECOPY，BALANCE，CALL）定價不正確，并且因為SUICIDE操作碼中的設計缺陷提供了一種非常便宜地膨脹狀態的方法，因此出現了大量攻擊。空賬號。 這些問題在10月17日的硬盤中得到了解決。

截至撰寫本文時，主要的剩余拒絕服務問題是客戶端進行O（log（n））數據庫讀取以讀取狀態條目，以及當狀態太大而無法容納到內存中時（由于以前的攻擊不再可能，狀態大大增加之后的情況）這使得處理狀態讀取操作碼變慢。

有兩種方法可以解決此問題。 一種是實現一個緩存，允許在O（1）數據庫讀取中讀取狀態條目（可能是在最佳實現中讀取的單個數據庫）; 這解決了問題，但仍然留下了事務處理能力的下限。 單個SSD讀取需要100微秒 ; 因此，leveldb讀取可能需要200-400微秒，創建每秒約2500次讀取的上限，或每秒約500次事務。 離線節點能夠同步的要求進一步降低了這一點。 由于需要更新狀態樹（添加O（log（n））開銷），寫入時間可長達10倍??，但這可以在后臺進程中完成。 因此，將狀態存儲在SSD中使得難以有效地處理超過~100tx / sec。

另一種方法是實施措施，以確保國家的總規模保持足夠小，以適應記憶。 在公共鏈中，這需要為賬戶收取“租金”（見這里 ， 這里 ， 這里和這里的建議）; 在聯盟鏈中，這只需要一個良好的垃圾收集策略，并在需要時為驗證器節點添加更多RAM。

Merkle樹

Merkle樹（有時也稱為“Merkle Patricia樹”，“Patricia trie”，“Merkle Patricia trie”或“trie”）是以太坊協議的重要組成部分，特別是在公共鏈中提供了大量價值。 樹的功能（詳見此處 ， 此處和此處有更詳細的說明）是提供一個加密認證的數據結構，存儲整個狀態（即賬戶余額，合同存儲，隨機數等）; 每個32字節的根哈希映射唯一（假設SHA3的加密安全性）映射到特定狀態，其大小可能是千兆字節。

這允許以下好處：

• 安全快速同步 ：加入網絡的新客戶端無需處理從創世塊到當前時刻的每個事務，以便下載狀態。 相反，他們可以簡單地下載塊頭，驗證工作證明（或可能證明PBFT參與者的賭注或簽名），找到最近的最終塊，并從該塊中包含的根哈希下載整個當前狀態并進行身份驗證它通過檢查trie中的每個哈希匹配。
• 輕客戶端支持 ：客戶端沒有足夠的計算能力，存儲或帶寬來下載和處理甚至整個當前狀態可能只是跟蹤塊頭并使用一致性算法來驗證塊頭，然后下載并驗證“分支”當客戶需要得到一些特定的狀態數據時，Merkle樹就到了。
• 獨立的光可驗證性 ：塊創建者可以提出一個“證據”，包括一個塊以及在該塊期間訪問或修改的狀態數據部分，即使沒有任何其他數據的任何客戶端也可以用來驗證創建了塊并正確執行了事務。

雖然在撰寫本文時還沒有人提出過這樣的產品，但可以想象一個運行其業務邏輯單節點私有鏈的集中式服務，它使用Merkle樹的獨立光可驗證功能來為其用戶提供服務。具有很強的可審計性和真實性保證。 例如，交換機可以承諾提供允許任何用戶在任何時間下載與其賬戶數據相對應的Merkle分支的API，并且還在每次操作之后發布其內部狀態的根散列。 如果用戶看到他們的余額意外減少并且想要確保沒有瀆職行為，他們可以使用二進制搜索算法來確定他們的余額減少了哪個操作，然后下載該操作的執行證明并驗證這項行動是合法的。 因此，Merkle樹在許多財團和私人連鎖應用以及公共鏈中都有益處。

然而，Merkle樹也帶來了效率成本; 因此，在那些不需要它的應用程序中，最佳解決方案可能是簡單地刪除Merkle樹，而是直接將狀態存儲在數據庫中，因此三個狀態更改將對應于三個數據庫操作。 也就是說，重要的是不要過快地跳到這個結論，因為有幾種方法可以優化Merkle樹而不必完全刪除它。 這包括：

• 允許在狀態中存儲無限大小的值，而不僅僅是32字節值（參見EIP 97 ）。 如果合同通常需要同時存儲許多價值（例如，基于區塊鏈的訂單簿存儲購買貨幣，賣出貨幣，價格，數量，賣方），這可以將效率提高2倍。
• 在每次事務之后刪除中間根哈希的存儲，而不是在每個塊之后執行它。 這個（1）允許更多地使用緩存，因此如果塊中的許多事務修改單個帳戶，則只需要對整個塊的該帳戶進行單個Merkle樹更新，（2）允許Merkle樹使用更有效的算法進行更新（例如， 在基準測試中看到具有此優化的Go客戶端需要28.5毫秒而不是45.7來更新，當中間根哈希計算的數量減少40％時），（3）允許使用更可并行化的算法更新Merkle樹，并且（4）可能打開一些啟發式并行事務執行優化的大門。
• 更改序列化算法或trie算法（例如，使其成為二進制trie而不是現在的hexary）
• 軟件級改進

最優策略是追求三條路徑（即，添加一個選項來實例化一個沒有Merkle樹的以太坊鏈，探索協議hardforking選項，以使Merkle樹更有效，并探索代碼的軟件級改進）。

事務并行化

當前以太坊模型的一個常見批評（參見http://www.multichain.com/blog/2015/11/smart-contracts-slow-blockchains/ ）是因為它在交易可以產生的影響中如此開放有，并行驗證交易是困難的。 刪除中間狀態根計算后，可以使用的一種啟發式策略的工作方式如下：

選擇需要處理的下一個k事務t[1] ... t[k] 。 在當前狀態之上處理所有并行線程（如果它讀取已經寫入的數據，則為每個線程提供一個單獨的緩存），并在執行期間跟蹤每個線程讀取的地址集和每個線程的地址集。線程寫道。

設(i, j)是最早的碰撞（按j排序），其中（i） i < j ，（ii） t[j]讀取事務t[i]寫的東西。

應用t[1] ... t[j-1]包含的狀態更新。 回到第1步，從t[j]作為第一個交易。

在一般情況下，這可能會實現大幅加速，但這并不能保證; 此外，依賴于該方案可能會使您的應用程序容易受到拒絕服務攻擊，其中攻擊者發送大量故意無法并行的事務以防止任何并行執行發生 - 在最壞的情況下，性能將不會更好比單線程的情況。 上面詳述的Merkle樹變化將主要允許Merkle樹計算的并行化，并且橢圓曲線簽名驗證在現有客戶端中預先計算并且可以已經并行化，但這是目前我們可以做到的。

Ethereum 2.0和3.0的長期路線圖是實現“分片”的概念，其中狀態被分解為多個部分，每個部分由一部分節點存儲，并且影響狀態的不同部分的事務被處理由不同的節點并行。 本路線圖的一部分是允許事務靜態聲明一個地址范圍，在這個地址范圍內，它們可以進行同步操作，因此在不保持整個狀態的情況下處理這些事務實際上是可行的。 超出規定地址范圍的呼叫將返回OUT_OF_RANGE錯誤，類似于有效的OUT_OF_GAS錯誤。

公共區塊鏈分片是一項復雜的技術挑戰，因為除了涉及數據庫分片的常見問題之外，還存在加密經濟挑戰，因為公共區塊鏈的特定形式的分布式計算具有每個節點不信任任何其他節點的獨特屬性，所以另一個節點簡單地說它處理和驗證了一組給定的交易是不夠的。 但是，就私人和財團鏈而言，不需要走這么遠; 相反，它只需要實現與事務可并行性有關的分片路線圖的一部分（即指定地址范圍的事務），然后通過要求網絡中的每個節點簡單地添加更多CPU核心和更多帶寬來實現可擴展性。

這種分片的一個挑戰是在許多應用中需要進行多次操作，即需要交叉分片，即。具有分散在整個州的效果，使得具有窄地址范圍的單個交易不能覆蓋它。這些案例的解決方案是異步編程語言，允許將操作分成多個階段。例如，從碎片A到碎片B的硬幣轉移將包括以下步驟：

在同時指定目標分片和地址的事務中，在分片A上銷毀X幣; 共識機制生成一份收據，證明此操作已得到確認。

將此收據提交到碎片B中的合同中，然后在碎片B上生成X個新硬幣。然后將記錄保存到碎片B的存儲中，說明收據已被消耗，從而防止它再次用于生成新硬幣。

有關如何完成此操作的詳細信息，請參閱此演示文稿（視頻）。

一個重要的高級任務是實際創建編程語言，以便輕松實現這些類型的異步跨分片操作。請注意，很多這項工作將同時為編程語言奠定基礎，編程語言可編譯為跨多個區塊鏈的應用程序。

智能合約安全

觸及公共和財團鏈智能合同的智能合約編程的一個重要方面是安全性，包括防止良性開發人員錯誤，以及合同作者為了試圖欺騙用戶而包含的惡意攻擊。關于公共以太坊區塊鏈的合同編程錯誤的匯編列表可以在這里找到：

https://blog.ethereum.org/2016/06/19/thinking-smart-contract-security/

安全研究員Andrew Miller的舊論文可以在這里找到：

https://eprint.iacr.org/2015/460.pdf

關于安全合同編程技術的以太坊維基文檔可以在這里找到：

https://github.com/ethereum/wiki/wiki/Safety

第一個鏈接還包括可以對EVM以及以太坊開發環境進行的可能的增量改進，以便最大限度地降低此類攻擊的風險。另外，由于入射DAO在2016年6月一直存在，以便于更安全的合同開發了一些提議的電子信息產品的：EIP 114，116，117，118和119。對于財團鏈開發社區而言，在公共鏈生態系統之前實施以安全為重點的EIP可能并不明智，因為我們不希望通過為聯盟鏈生態系統制定一套安全的合同編程實踐來混淆開發人員，并且公共鏈生態系統（除非絕對不可避免，例如在公共鏈上，游戲理論問題更加不可避免）。

除了低級別的改進之外，還可以構建更高級別的工具，以提高合同編程生態系統的安全性。這些分為兩大類：

新的編程語言（使用Solidity，Serpent，LLL或EVM作為編譯目標）

用于新編程語言或現有編程語言的形式驗證，符號執行或其他靜態分析工具

請注意，必須注意這些工具如何與底層環境集成;例如，純函數式語言經常被引用作為以太坊契約編程挑戰的解決方案，但如果我們看看DAO盜竊的具體情況，我們可以看到它是由于“重新入侵”黑客而產生的，其中一個合同稱為然后調用原始合同的不受信任的合同，即使您嘗試在當前的EVM上實現純函數式語言，您也會遇到這樣的挑戰：如果您需要再次簽訂合同，則很難確定子合同除非實現EVM級操作碼，否則不會進行一些“不純的”狀態改變操作STATIC_CALL。

一般來說，不可能有一種神奇的技術可以解決所有智能合約安全問題; 相反，我們將看到增量方法的組合，包括新語言，更好的分析工具，更好的開發工具，更好的標準和最佳實踐以及對底層EVM的更改。應將更好的標準和最佳實踐集成到開發工具中，以使程序員更容易適應; 區塊鏈技術的很大一部分價值在于減少建立高信任系統的準入門檻，如果以前的入門門檻只能被多年專業開發人員教育的要求所取代，那么該技術的潛力可以說是顯著的降低。

國家頻道

狀態渠道是區塊鏈技術的流行短期可擴展性，隱私和延遲解決方案。有關州渠道的一些信息可以在這里找到：

• http://www.arcturnus.com/ethereum-lightning-network-and-beyond/
• http://www.jeffcoleman.ca/state-channels/
• http://ethereum.stackexchange.com/questions/342/what-are-payment-channels-can-they-be-implemented-on-ethereum/1648

一些實現包括：

• https://github.com/AnnaIsAWang/LedgerLabsCoops2016
• http://raiden.network

特權賬戶

許多聯盟鏈應用程序要求某些節點（例如，監管機構）具有特殊權限。可能的特權包括：

• 凍結余額的能力
• 能夠停止執行智能合約
• 能夠更改智能合約的代碼
• 能夠查看大多數參與者僅以加密形式看到的明文狀態信息（例如，余額，合同條款）

在某些情況下，這些特權最好在基礎協議之上的層中實現; 例如，在新智能合約的發行受到嚴格限制的鏈中（或者甚至在整個鏈只有一個合約的情況下），可以將這些特征實現到合同本身的代碼中。在隱私保護解決方案的情況下，監管機構能夠查看明文狀態只能在頂層進行，因為隱私保護解決方案本身將通過頂層構建。

在其他情況下，這些特權最好通過更改底層協議來實現。最簡單的方法是引入一些新的操作碼，例如。0xed = SSTORE_EXT（設置外部帳戶的存儲），0xee = WITHDRAW（從另一個帳戶中排除ETH），0xef = SET_CODE（設置另一個帳戶的代碼），并且只給一個地址使用這些操作碼的特權（例如地址254）。這樣一個“特權地址”是未來作為抽象路線圖的一部分可能在以太坊實施的一個特征（在公共鏈中，只有系統級合同，如實施合同創建功能的假設合同，可以訪問這個特權地址，因此不會被任何組織或個人用作“后門”，但在私人和財團鏈中，它可以作為特權機制使用。

改變共識集

一旦財團鏈啟動，事后就不可避免地會有理由改變一致的參與者。 這包括：

• 誘導新成員進入財團
• 取消財團的新成員
• 更改聯盟的一個或多個成員使用的私鑰

處理這個有幾種方法：

• 在配置文件中修復共識集，并使每個共識集更改為硬分叉
• 將共識集存儲在合同中，合同本身會對更新共識集的規則進行編碼
• 使用安全的外部機制來存儲共識集（例如，以太坊公共區塊鏈）

如果需要，共識抽象應該能夠涵蓋所有三種模式。如果（i）共識集存儲在鏈內合同中并且一致性算法不提供即時終結性（例如DPOS），或者（ii）共識集存儲在外部機制中，那么謹慎的做法是在達成共識集更改和更改變為活動時之間存在延遲。卡斯珀目前為公共鏈計劃的股權協議證明的方法是將區塊鏈時間分成12小時的“時期”，并使用在上一個時期開始時定義的驗證集（即一個始終是在過去的12到24小時之間）作為當前區塊的共識。

您可能希望使用外部機制的原因是為頻繁脫機節點提供更高的安全保障。具體而言，特別是如果共識集很小，則存在以下風險：在一段時間內，大多數歷史密鑰將被泄露，并且如果攻擊者獲得這些密鑰，則他們將能夠創建替代鏈并且欺騙長 - 離線節點，這個鏈是合法的。使用外部機制來存儲共識參與者會使這種情況發生得更加困難;雖然這種方法可能并不適合所有應用程序，但在許多情況下，聯盟本身可能足夠大，以至于50％的歷史密鑰折衷是不太可能的。

請注意，精心設計的設置甚至可以通過使用一致性算法來容忍外部機制的短期故障，該算法可以容忍感知共識機制中的小差異; 這也需要限制共識參與者可以改變的速度，并且規則如果機制不可用，則應該使用最新的可用共識集（盡管這是高度理論化的）。

另請參見：本文，其中顯示了拜占庭容錯一致性算法在驗證器轉換期間可以保持安全屬性的一種方法。

https://github.com/ethereum/wiki/wiki/Consortium-Chain-Development

總結

以上是生活随笔為你收集整理的【译】Consortium Chain Development的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。