以太坊《私有链和联盟链的机会与挑战》报告
以太坊平臺評估 私有鏈和聯盟鏈的機會與挑戰
作者:Vitalik Buterin?
翻譯:萬向區塊鏈實驗室/ChinaLedger 聯盟?
排版/校對:區塊鏈鉛筆(ChainB.com)
(注:本文屬于學習資料,請勿用于商業用途。轉載請注明作者與出處。)
以太坊平臺的構想最早是在 2013 年 11 月提出來的,當時的目標是創建一個 更通用的區塊鏈平臺——通過工作量證明機制(或最終轉換成權益證明機制)實 現了公共經濟共識的概念,并將其與狀態豐富的圖靈完備虛擬機的抽象能力結合 起來,從而讓應用程序開發者更容易地創建區塊鏈上的應用程序,并能受益于區 塊鏈的去中心化和安全的特性,特別是避免了為每一個新的應用程序創建一個新 區塊鏈的麻煩。
而之前曾經出現過的區塊鏈協議可以視為是單一功能的工具,就如口袋中的 計算器,即使在好一點的情況下也就像瑞士軍刀這樣的多功能工具而已;以太坊 則是區塊鏈中的“智能手機”:它是一個通用的平臺,你可以在上面搭建自己需 要實現的功能,就如搭建一個“APP”一樣,以太坊的用戶將會即時接觸到它能 提供的好處,而不需下載任何新的軟件。
雖然這個項目原本是作為“Mastercoin 功能升級提議”的一部分提出來的 (目的是為金融合約提供支持),后來項目的關注點擴展到了更廣泛的應用領域, 包括金融合約,下注,數字代幣(資產)發行,去中心化文件存儲激勵機制,投 票,“去中心化自治組織”等。以太坊平臺開發的資金是通過在 2014 年 8 月的 一場眾籌活動籌集回來的。自從那時起,平臺上已經出現了超過 100 個應用程序, 范圍包括金融清算和結算,到保險,數字資產發行,甚至是非金融領域的應用(包 括投票和物聯網)。
基礎設計
有的區塊鏈都有一個“歷史”的概念——所有之前的交易、轉賬及其發生順 序的集合,以及“狀態”——決定某個給定交易是否有效以及在交易處理后狀態 將會如何改變的“當前相關的”數據。區塊鏈協議同時有一個“狀態轉換規則” 的概念:基于之前的狀態,以及一個給定的交易,(i)這個交易是有效的嗎? 還有,(ii)在交易發生后,狀態會是什么?
我們可以用比特幣 1 給出一個例子。在比特幣中,狀態是賬戶余額的集合(如 地址 39BaMQCphFXyYAvcoGpeKtnptLJ9v6cdFY 有 522.11790015 個比特幣,地址 375zAYokrLtBVv6bY47bf2YdJH1EYsgyNR 有 375 個比特幣......)。狀態轉換功能取得發送者的地址、目標地址以及一個值,然后詢問:(i)這個交易已經由發 送者用密碼學的方式正確簽名了嗎?還有(ii)發送者的賬戶里面有足夠的比特 幣用于本次的發送嗎?如果其中一個問題的答案是否定的,那么交易就是無效的, 并且不能被包含到一個區塊里面。如果一個區塊包含了當前狀態下的一個無效交 易,那么這個區塊就會被網絡忽略掉 2。如果兩個問題的答案都是正確的,那么 交易的價值就會從發送者的余額中抽離出來,并添加到接收者的余額中。
在以太坊中,相關的設計會更復雜一些。狀態可以被視為是所有賬戶的集合, 而每一個賬戶要不就是“外部擁有的賬戶”(EOA,externally owned account) 或一個合約(contract)。如果賬戶屬于 EOA,則狀態會簡單地存儲這個賬戶的 以太幣余額(以太坊的內部加密代幣,其功能,類似比特幣或 XRP)以及一系列 用于防止重復支付攻擊的序列號。如果賬戶是一個合約,則狀態會存儲合約的代 碼,以及合約的存儲空間——一種鍵值數據庫(key-value database)。
在以太坊中一個交易會指定(跟其他的一些所需信息一起,這會在后面會提 到)一個目標地址、用于交易的以太幣數量,以及一個理論上能存儲任何信息的 “數據”域(另外,還有一個發送人的地址,不過這在簽名里已經指定了,因此 這里沒有專門說明)。如果一個交易是對 EOA 或一個尚未存在的賬戶發出的,則 它除了簡單地作為發送以太幣的手段外,并沒有其用途。如果一個交易被發送到 一個合約里,則會執行合約的代碼。這個代碼有能力實現:
? 讀取交易數據。
? 讀取交易中被發送的以太幣余額。
? 讀取或寫入合約自己的存儲空間。
? 讀取環境變量(如時間戳,區塊難度,前一個區塊的哈希值) ? 向另一個合約發送一個“內部交易”。
本質上說,你可以將合約視為是存儲在以太坊的狀態里的一類“虛擬對象”, 它可以包含自己內部的永久存儲空間,并有能力像外部用戶一個擁有對其他合約 的操作權限和關系。內部交易是由合約創建的一種交易;就如普通的“外部”交 易一樣,它也包含了一個明確的發送者、目標地址、以太幣數量以及信息數據,如果一個內部交易被發送到一個合約,則合約的代碼就會運行起來;在合約執行 結束后,合約的代碼將有能力返回 0 或更多字節數的數據,可以讓內部交易用于 “詢問”其他合約去獲取特定的信息。一個交易(transaction)可以創建一個 新的合約——通過將合約的代碼放置在交易的數據中(目標地址不進行設置), 或通過 CREATE 這個操作代碼(opcode)從合約的內部實現這個功能。
簡單地說,在以太坊的公有鏈上,合約機制是以如下的形式被使用的:
? 作為一個追蹤用戶發行資產(issuer-backed assets)的數據庫;
? 作為一個可控制其他資產的“智能合約”(下面會詳細介紹這個概念), 并將根據特定的條件將這些資產發送到特定的參與方;這通常會進一步分解 成幾個子類別,包括(i)金融合約(如差價合約,二元期權,衍生品), (ii)擔保交易(實施“無需信任的數字資產原子化互換”),(iii)多 方協議,如拍賣,保險合約,鼓勵披露特定信息的經濟游戲等;
? 作為一個基于區塊鏈的域名系統的注冊記錄管理;
? 作為一個代表用戶或機構的賬戶,不過擁有復雜的訪問權限控制,如多 重簽名;
? 作為“軟件庫”,讓代碼可以寫入、發布到區塊鏈上,并由其他的人使 用;
“智能合約”的概念通常被簡單地定義為“一個直接控制數字資產的電腦程 序”3,這是特別重要的。合約有它們自己的地址,因此可以像用戶一樣作為數 字資產的持有者了如果一個合約真的“擁有”數字資產,這意味著(i)只有合 約自己的執行過程能夠向另一方發送資產,還有(ii)每一個參與方在區塊鏈上 可以看到并檢驗這個資產真的在程序的控制下。
例如,你可以在無需信任的情況下實現資產 A 與資產 B 的交易——通過資產 A 的擁有者將資產發送到一個程序里,這個程序的代碼定義了“如果我在 24 小 時內收到資產 B,則我會將資產 A 發送到發送人的地址里,并將資產 B 發給我的 創建者,否則我將會把資產 A 發送回我的創建者”。資產 B 的擁有者可以看到該 合約確實控制了資產 A,而且知道一旦他們將資產 B 發送到合約的賬戶,合約將會進行一個公平、正確的交易。合約并沒有“擁有者”(owner)這個概念;當 資產 A 的原始擁有者把該資產發送到合約里,則他們就無法通過操縱這個合約把 資產拿回來,而是只能等待交易成功完成并接收所交換到的資產 B,或者 24 小 時后,若交易還是沒有成功,則他們會自動地拿回資產 A。
以太坊區塊鏈在較高的層級上有點像比特幣的區塊鏈。最主要的也是最重的 ——區塊鏈由一系列的區塊所組成,每一個區塊包含指向前一個區塊的指針,以 及一個經過排序的交易列表。區塊是由工作量證明所維護的,“最長的鏈”(由 整體難度決定)定義了一系列經過確認的交易及其執行的順序。
為了到達以太坊區塊鏈上的“當前狀態”,節點可以從“初始狀態”開始(這 是一個內嵌在每一個以太坊客戶端里的、所有人都認可的初始狀態),并處理每 一筆交易,并按順序執行由交易處理和代碼執行過程所帶來的余額/序列號/代碼 /存儲的變化。比特幣里面也有同樣的過程;雖然以太坊對交易執行過程“狀態 變化”模型的重視是獨特的(在比特幣中,交易通常被視為花費來自歷史上前一 個交易的“輸出項”,而不是狀態里的某個對象)。但以太坊、比特幣和瑞波、 狗狗幣等協議里,代碼在這部分工作中的運行模式大體上是一樣的。
以太坊使用了內存需求較高的哈希函數,uncle 激勵機制,難度調整算法, gas 限制調整算法等,這些都是以太坊的一些值得注意的不同之處,不過這些都 是優化工作,可以說在以太坊的本質中并不是處于中心的地位。
以太坊中另一個值得注意的特性(比特幣中沒有的)是 Merkle 樹的深度使 用,讓“輕客戶端”可以只下載和校驗區塊的頭信息,同時也能在有需要的時候決定并安全地對區塊鏈狀態的任何特定部分進行校驗。而在比特幣中,一個區塊 頭只儲存包含交易的 Merkle 樹的根哈希值(root hash),在以太坊中每一個區 塊投包含了一個“狀態根”(state root),實質上是包括了整個當前狀態(賬 戶余額,序列號,代碼和儲存)的密碼學哈希樹的根哈希值。
因此,輕客戶端通常可以只下載區塊頭(每 17 秒約 500 字節),如果輕客 戶端需要了解狀態中的某個特定數值(如“賬戶 0x124b6f72 中的余額是多少?” 或“賬戶存儲空間中鍵值為 178233 的記錄對應什么數據?”),它就可以請求網 絡中的任何“完全節點”提供一個“分支”——這是(Merkle)樹結構中的數據 區塊構成的一系列哈希值,指定了直到樹根部的特定信息,而輕客戶端可以自己 驗證該分支的完整性。如果該分支是正確的,它就接納這個答案。“輕客戶端” 模式對那些使用智能手機和物聯網/嵌入式設備的以太坊用戶是很有用的,對那 些電腦性能較低、網絡帶寬較差的用戶也是很有用的。
以太坊的私有鏈和公有鏈
需要注意到,雖然以太坊原來是以公有鏈的形式存在的,但以太坊的狀態轉 換規則(即協議中處理交易、執行合約代碼等的部分)可以從以太坊的公有鏈共識算法(如工作量證明)中抽離出來,因此完全可以創建運行以太坊代碼的私有 鏈(在一個節點上運行,這個節點由一個公司控制)或聯盟鏈(由一系列預先指 定的節點運行)。4 以太坊技術自身因此可謂是與具體的應用場景不相關的—— 無論是用于公有鏈、聯盟鏈或私有鏈的模式,因此我們的目標是讓以太坊的多種 實例的互操作性實現最大化——如可以將為以太坊公有鏈書寫的合約和應用程 序導入到以太坊的私有鏈中,反過來也一樣。
現在,在私有鏈的應用場景中已經有幾個版本的以太坊在進行開發了,如 Hydrachain。私有鏈版本的以太坊實施方案在理論上會一些可擴展性方面的提升, 但若這些特性要應用到公有鏈版本的以太坊上,還是需要完成不少的工作。
金融領域中的應用
雖然以太坊是一個高度通用化的平臺,其用途理論上是很廣泛的,但以太坊 上的主要應用項目還是具有某些金融特性。這些應用項目可以進一步分解成“純 金融性的”,即只進行有價金融資產管理、創建金融合約、擔保交易等;另一種 是“半金融性”的,將一些本身并非金融應用的服務與金融、支付用例結合起來。
后一個類別的例子由很多,從“去中心化的 Uber”平臺,到專注于機構服 務的貿易融資項目(如在 2016 年 1 月贏得上海區塊鏈黑客馬拉松大獎的 CargoChain),這些項目都利用了以太坊區塊鏈的數字資產管理和智能合約功能 及其在金融應用領域之外的功能,將以太坊用作一個航運記錄跟蹤、聲譽和評價 信息,以及為簽訂的法律合約提供存在性證明的數據庫。
在“純金融性應用”的方面,我們可以看到:
? 基于區塊鏈的金融合約和衍生品處理平臺(如Clearmatics);
? 在區塊鏈上實施的其他金融工具(如UBS的“智能債券”平臺);
? 從黃金(如DigixGlobal)到以法幣計價的“結算幣”這類對現實世界 資產進行數字化的應用,為金融交易和簡單的主流支付服務;
? 使用區塊鏈實現差價合約(CFD),用智能合約執行,并用無對手風險的 加密貨幣進行抵押品管理和結算工作,以創建映射現實世界資產的“鏡像資產”,在那些有足夠流動性和套利空間的市場中提供對底層資產的相同回報 率。
? 基于區塊鏈或基于智能合約的抵押品管理。
有一類非金融領域的區塊鏈應用所提供的服務本來在金融平臺上就是很有用的(無論是否基于區塊鏈技術);或許最佳的例子就是身份驗證系統。
為你的應用評估以太坊私有鏈或公有鏈的適用性
評估以太坊在這些應用上的適用性涉及兩個主要的步驟。第一步是去決定區 塊鏈是否真的適合做這個事情。區塊鏈的基本技術優勢包括可靠性,安全性,可 審計性以及去中心化,這些都是人們了解得比較多的,不過人們考慮得比較少的 則是這些特性能在什么場所發揮作用。主流的支付系統需要依靠聯盟數據庫或公 共數據庫去實現密碼學意義上的可審計性及去中心化嗎?證券交易呢?航運或 航空票務市場呢?或文件存儲、計算呢?商家的積分計劃呢?在非金融應用那邊, 若要對不同的現實世界資產或數字資產(如域名)的所有權進行追蹤呢?電子郵 件和社交網絡應用呢?
這樣,我們就面臨一個選擇了——公有鏈和私有鏈哪種更合適?可以這么說, 以太坊的優勢在公有鏈或聯盟鏈上是有所不同的。在公有鏈上,除了能夠實現程 序化的擔保交易和金融合約外,以太坊能提供的一個好處是協同性,正如一位以 太坊應用程序開發者最近描述過的那樣。以太坊中的合約可以滿足不同的功能, 而每一種建造在以太坊之上的應用程序在理論上可以利用其它應用程序提供的 功能。
例如,如果你希望用區塊鏈去管理公司股份的所有權,那么從安全性和可校 驗的記錄管理角度來看,這個工具確實是很有用的,但另一個好處是讓股權眾籌 變得更簡單了:公司可以將股份轉移到一個智能合約中,任何人若將 Y 個單位的 加密貨幣 Z 發送到該合約,該合約就會自動往他的賬戶中返回 X 個單位的股份, 而合約中的這些錢若要提取出來,必須經過 5 個董事中的 3 個人的授權。如果公 司所在地有相應的監管要求,需要進行某種形式的 KYC(了解你的客戶)認證或 對投資者的身份進行限制,只要有人在以太坊上設計了一個基于區塊鏈的 KYC和認證平臺,前面提到過的這個股權眾籌平臺以及其他的股權眾籌平臺(也可以 是廣義的金融應用項目)可以立刻與該身份認證系統進行互動,并往合約中添加 相應的限制,要求只有經過授權的個人才能達成有效的股權購買行為。
具體來說,我們可以認為協同性是以太坊和所謂的“雙層”區塊鏈智能合約 系統(如現在已經停止了的 Codius 項目)的主要差別,后者將區塊鏈當成是一 個純粹用于追蹤資產所有權的層(甚至是更“傻瓜化”的純數據層),并要求每 一個應用程序通過多重簽名“公證人”或讓用戶獨自處理區塊鏈并“解讀”其結 果的方式單獨去處理智能合約;協同性的設計目標是讓應用程序就智能合約執行 結果正確性的來源達成共識(每一個人都同意這個來源是安全的),因此在協議 的層面引入這種機制將鼓勵其作為共識算法的一部分從而實現公共利益,是有經 濟意義的。
在私有鏈中,論點就有所不同了。私有鏈通常是用作為特定產業創建結算平 臺的工具,通過構建一個實質上是唯一的、共同的數據庫,讓機構之間的交易處 理效率趕上機構內的交易處理效率。私有鏈的理想“用戶”實質上是一個在一定 程度上已經去中心化的產業,這產業里面沒有一個公司擁有超過略高于兩位數的 市場份額,不幸的是,這種去中心化的狀態在當前的技術水平下明顯降低了效率: 如果一個公司的客戶希望與其他公司的另一個客戶進行某種互動(如發送付款, 執行交易等),就需要一個繁瑣和笨重的機構間對賬和結算過程,這通常帶來了 明顯的費用以及延遲。使用區塊鏈的話,當前的“半去中心化”的產業“政治架 構”照樣可以保存下來——并不需要說服所有的參與方進行合并或成為某個超級 公司的客戶,更不需要說服那些有反壟斷政策的監管者同意這種合并。同時,通 過技術上的簡單變革,得到了大規模的網絡效應和高度的互操作性的好處。
另一個潛在的好處是通過“分離關注點”的做法提高金融產業的效率:銀行 并不需要親自對每一種類別的金融應用進行創新,而是可以將這個任務交給更靈 活的金融企業,這些企業正在往類似軟件提供商這種角色的方向發展,它們可以 幫助用戶在區塊鏈上發送經過密碼學簽名的交易、執行交易、以及達成涉及有對 應背書資產的代幣相關的合約,而不需自己對實際的資產進行托管(因此降低了它們自身的監管負擔),而銀行還是會保留它們的核心業務——接收存款,以及 發放貸款。
在私有鏈的場景中,協同性就顯得沒那么重要了,因為每一個私有鏈更有可 能被設計成專門針對某種特定應用。不過,還是有可能實現某種程度上的“私有 鏈間互動”或“公有鏈與私有鏈互動”這樣的協同模式。現在已經有一些針對跨 鏈資產交易這種特定用例的嘗試了,包括 TierNolan 的跨鏈互換協議,以及 Interledger 最近發布的一些成果;然而,以太坊的策略更具雄心壯志,尋求創 造更通用的“搭橋”機制,讓從一個區塊鏈讀取另一個區塊鏈的內容成為可能(例 如,BTCrelay 是比特幣和以太坊之間的橋),長期的目標將會是整合一個通用 的異步編程語言,讓應用程序可以跨越多個區塊鏈開展。若這是一個有較高需求 的特性,則計劃中的以太坊 2.0 的很多技術可以重點去達成這些目標;若這個功 能被認為重要性不高,則以太坊的功能就會受限在智能合約和未來的可證明性上, 至于“傻瓜區塊鏈”和“智能區塊鏈”之間的取舍及其效率與復雜性的平衡,這 是要由用戶去決定的。
當一個公司決定區塊鏈是可行的策略時,它就需要選擇具體的平臺。以太坊 的好處是可編程性,靈活性,協同性,模塊性,以及容易使用的哲學思想——畢 竟,我們現在和未來五年內都不太可能完全分析清楚開發者們到底需要什么樣的 特性。如果公司的法務研究工作決定某類特定的應用需要 KYC(了解你的客戶) 認證、登記限制或其他規則,那么身份認證可以作為一個獨立的層進行搭建,并 可以書寫直接接入這個系統的合約。在一個股份可以被私下進行交易的公司里, 你希望股份登記在區塊鏈上,而且希望增加一個限制,即只有經過 51%的現有股 東同意才能增加新的股東,這樣你還是可以在不改變基礎層或系統的其他部分就 可以實現這個目的。
即使是對如支付這樣簡單點的應用來說,剛開始時在以太坊之上搭建這種應 用,可以快速地在基礎的資產層上整合更高級的應用功能,如金融合約,抵押品 管理,無需信任的原子化互換等,這樣將來需要這些功能就可以輕易地添加上去。 以太坊未來的版本將會繼續這種“未來兼容性”,甚至將其擴展到連密碼學的層 面——用戶甚至可以選擇用于保護其賬號的密碼學算法。例如,如果你對量子計算機(譯者注:具有強大運算性能,對一些加密方法帶來威脅)感到擔憂,而且 想快速地升級到 Lamport 簽名機制,就可以如愿以償,無需等待整個區塊鏈的協 議的進化。
自然而然地,有些人認為“如果能用一種簡單的工具去完成一項任務,就不 要用復雜的工具了”,隨之而來的還有認為以太坊的通用性或其實施的特定方式 帶來了特定的效率問題。前一種論點需要就具體的項目進行具體的分析,并與以 太坊的特性進行對比;后面的論點將會在接下來的以太坊路線圖中進行詳細討論。
以太坊開發路線圖概要
以太坊項目當前預期的里程碑目標將會在下面的章節展開討論:
? Metropolis:Mist瀏覽器的發布,預計在2016年的夏天或秋天;
? Serenity (“以太坊 1.5”):發布區塊鏈的 PoS 股權證明(Casper)版本, 同時包含以太坊改善提議(EIPs)101 和 105。這計劃在 2017 年早期實現。 ? WebAssembly 發布 (“以太坊 1.75”):更快的虛擬機。預計在 2017 年 到來。
? 以太坊2.0(尚未命名):初步可擴展性提升的版本。預期在2017年晚 期實現。
? 以太坊3.0(尚未命名):“沒有限制的”可擴展性版本,預計在2018 年晚期實現。
這些名字在接下來的章節中將會被大量使用。
安全性
(以太坊)作為一個在大范圍內復制、共享賬本的圖靈完備狀態機,能讓世 界上任何能購買 0.3 美分價值以太幣的人上傳代碼,然后網絡中的每一個參與者 都必須在自己本地的機器上運行這段代碼,這確實是會帶來一些明顯的與安全性 相關的憂慮。畢竟,其他的一些平臺也提供類似的功能,這包括了 Flash 和JavaScript——它們經常碰到“堆與緩沖區溢出攻擊”,沙盒逃逸攻擊以及大量的其他漏洞,讓攻擊者可以做任何事情,甚至包括控制你的整臺計算機。除此之 外,還會有拒絕服務攻擊(D.D.O.S.)——強迫虛擬機去執行無限循環的代碼。
為解決這些挑戰,以太坊項目引入了不少的策略。首先,以太坊的虛擬機的 架構是高度簡化和受限的,之所以要從頭搭建一個全新的虛擬機而不是用如 Java 這樣現有的虛擬機,是為了實現虛擬機的高度安全性。與訪問系統資源、 直接讀取內存或與文件系統互動的操作代碼(Op Codes)在 EVM 以太坊虛擬機的 設計規格中是不存在的;與此相反,唯一存在的“系統”或“環境”操作代碼是 與以太坊“狀態”里定義的架構進行互動的:虛擬機內存,堆棧,存儲空間,代 碼以及區塊鏈環境信息(如時間戳)。
以太坊虛擬機的大多數實施方案是解釋型的,不過有一個由 JIT 編譯的虛擬 機已經被開發出來了。以太坊虛擬機(以及以太坊協議的其他部分)已經有 6 個實施版本了,也經歷了超過50000個單元測試,以確保完美的兼容性和確定性 的執行結果。7 Go語言、C++和Python語言的實施版本在我們的安全審計機構 Deja Vu 的幫助下,已經進行了深度的安全性審計。在以太坊發布后的幾個月時 間里,發現過幾個需要修復的安全性漏洞,不過這種事發生的頻率已經大幅度降 低了:在本文行文前的兩個月,以太坊網絡一直在正常運行,而沒有發現任何明 顯的安全性漏洞。
無限循環攻擊的解決方案是最復雜的。總體上說,任何圖靈完備的編程語言 在理論上都是會碰到“停機問題”的,即不可能預先確定給定程序在給定的輸入 值下進行運行是否會出現停機問題。其中一個例子就是考拉茲猜想(Collatz Conjecture)。假設有如下的程序:
該猜想認為,如果你使用任何輸入值去運行這個程序,這個程序最終會停止, 不過我們并不能證明這一點;若在找到一個反面例子的情況下我們就可以證明“并不是這樣的”,但現在人們已經嘗試過 1 萬億以上的輸入值了,也沒能找到 這樣的一個反面例子。因此,這帶來了一個憂慮——攻擊者可以創建一個合約, 里面包含一些混淆的無限循環代碼,然后往這個合約里面發送一筆交易,從而將 系統拖垮。
以太坊解決這個問題的概念是汽油(Gas):交易的發送者定義他們授權代 碼運行所需的最大計算步數,然后為此支付相應比例的以太幣。在實際中,不同 的操作過程需要耗費不同的 Gas 數量,這些耗費的標準不僅是基于執行每一種操 作過程所需的運算時間,還包括如全節點儲存以及內存耗費等考量因素,所以 Gas 并不只是一個用于統計運算步數的標準,不過我們初步就理解成“Gas=計算 步數”吧,這對理解 Gas 的用途基本上足夠了。
若在執行交易的過程中“Gas”被耗盡了,如超出了其允許的最大計算步數所需的預算,則交易的執行會被回滾,但交易還是正確的(只是不再有效了),發送者照樣要付相應的費用;因此,交易的發送者必須在下面兩種策略之間進行取舍:設置一個更高的 Gas 限額,這可能會支付更高的交易費;或設置一個較低的 Gas 限額,這樣可能會創建出一個會被回滾的交易,就需要以一個更高的限額重新發送一遍了。信息(譯者注:可用于合約間互動的一個特性)本身也可以設置 Gas 的限額,因此可能讓一個合約與其他合約進行互動,而無需擔心其他合約會無節制地消耗自己的合約里的 Gas“預算”。這個機制已經被密碼學學者 Andrew Miller 及其他人審查過了,其結論是這個機制確實能實現逃過停機問題的目的,并以經濟學的方式分配運算能力,不過在某些邊緣案例中激勵機制可能不是一個 最優解 9。
第三個安全性問題在較高的層面展現出來:若我看到某人提供的一個智能合 約,上面寫著它是一個二元期權合約,需要收取 10 美元的費用,而且若 3 月 30 日的金價超過 1100 美元時則會向你支付 20 美元——我如何知道這是真的呢?如 果這是一個合約,用于管理整個市場內的二元期權合約,讓用戶可以出價、投標、 完成交易,我如何知道這個合約沒有能讓作者拿著所有的錢跑路的后門呢?一個 更好的問題是,假設這個合約的作者編程水平有限,他們如何知道自己寫出的程 序代碼沒有漏洞,讓大家永遠都沒法將錢從合約中拿走呢?
上述的兩個問題——程序員作惡和程序員出錯——是獨立的問題,而解決問 題也有所不同,但兩者之間還是有共同點的。以太坊里面臨的挑戰對應兩類解決 方案,分別是低科技的和高科技的解決方案。高科技解決方案在理論上能提供更 好的希望,不過會帶來整合的難度,以及更依賴于復雜的工具。而針對作惡問題 的低科技解決方案有兩個層面。第一,在以太坊里,我們明確以下兩者的區別, 即應用程序的核心(純粹由智能合約的集合構成)以及界面(HTML 和 Javascript 代碼通過讀取區塊鏈及發送交易的方式與核心通訊)。
這是一個為擔保交易 Dapp 應用而設的簡單、美觀的用戶界面。不過你怎么 知道點擊“移除”按鈕時并不是將你的全部錢發送給開發者呢?
我們的目標是讓核心變得可信,若要實現這點,核心就必須盡量精簡,并且 經過深入的審計和審查;而用戶界面可能包括大量的代碼,可以無需這么信任; 我們的一個中期的設計目標是讓以太坊用戶界面去保護用戶,以免他們受到來自 作惡的交易界面的損害,如通過強制性的彈出一個“你是否想將帶有這些數據的 一個交易發送到這個合約里?”對話框(或其他形式的通知方法)。我們希望會 呈現出一些專業事務所的市場空間,就如今天律師事務所創建標準化法律合約那 樣,這些專業事務所會為不同的用例創建標準化的合約,并讓這些合約接受來自 第三方審計人員的深入檢查。
審計和標準化可以減少代碼錯誤帶來的損害,不過在錯誤的特例里,已經有 人進行了數十年的研究,引入了一種強類型要求的編程語言,專門用于避免錯誤; 這類語言讓你可以更豐富地指定每一種數據的含義,并自動防止數據被以明顯錯 誤的方式組合起來(如時間戳加上了一個貨幣價值,或由區塊哈希值分割的地址)。
更高級的解決方案集合依賴于名為形式化驗證(Formal Verification)的 技術。簡單地說,形式化驗證就是使用計算機程序自動地在數學的層面上證明關 于其他計算機程序的語句。其中一個簡單的例子就是證明一個排序算法的正確性: 給定一段代碼,它以一個數組作為輸入項,并提供一個數組作為輸出項,你可以 插入一個“定理”,如for x ε I: x ε O; j > i => O[j] >= Oi。形式 化驗證者將會處理這個代碼,構造出肯定或否定這個定理的數學證明,或放棄處 理(在考拉茲猜想的例子里有可能會這樣)。Aesthetic Integration 公司的 Imandra 產品甚至可以自動找出錯誤定理的反面例子。
現在,以太坊的高級編程語言 Solidity(編譯到以太坊的 bytecode)的主 導開發者 Christian Reitwiessner 正在將形式化證明引擎 Why3 整合到 Solidity 里面,讓用戶可以在 Solidity 程序里面插入與某種數學論點有關的證據,并在 編譯的時候進行驗證;還有一個項目在將 lmandra 整合到以太坊虛擬機的代碼里。
通過 why3 引擎實現 Solidity 的形式化證明
形式化證明是一項強大的技術;不過,它無法解決這樣的一個問題:有一些 事情,可能連我們自己都不知道應該要去證明。人類對公平和正確性的定義往往 是非常復雜的,而由此帶來的復雜影響往往是難以檢測的。市場的訂單本(譯者 注:Order Book,即撮合交易引擎常見的買賣單系統)通常需要有一些基礎的正 確性規則(你要不就以所出的價格得到你需要的東西,要不系統就把錢返還給你), 順序的不變性(為了防止 front-running,即所謂的提前交易或搶單),確保每 一個買家和賣家都能與最佳的對手單匹配上,以及其他等等;不幸的是,我們并 不能簡單地將所有的情況都列舉出來,也無法確保我們沒有任何遺漏的事項。現 在看來,對我們來說選擇什么東西進行驗證會是繼續是一項藝術(難題),不過 形式化證明技術肯定會降低攻擊者們進行攻擊的自由度,讓對代碼進行審計的人 員降低負擔。
關鍵建議
金融機構應該考慮使用以太坊的公有鏈或私有鏈版本,或者使用一個基于 EVM(以太坊虛擬機引擎)的系統,畢竟這個虛擬機是以完美的確定性和安全性 的出發點去設計和測試的,這些兩個目標對分布式賬本的用例是很有用的。(譯 者注:基于 EVM 的系統,并不一定指以太坊,而是指 EVM 這個虛擬機引擎的設計 能夠即使是與其他的系統結合起來,例如非區塊鏈技術的系統,也能發揮強大的 功能)。具體來說,除了 EVM 之外,當前并沒有其他主流的虛擬機引擎包含了 Gas 計數器這個概念,而這個機制對以下的目標是必須的:(i)避免無限循環攻 擊,(ii)避免在某些邊緣案例里的具備不確定性的行為。在一個私有鏈的實例里 面,并不一定要用以太幣去支付 Gas(或者其他密碼學代幣);你可以直接給用 戶分配“Gas 資源“,有點像亞馬遜云服務器給客服分配“CPU 時間”一樣,你 也可以簡單地要求所有的交易都包含一個給定的最大限制(如每個交易的 gas 上限是 100 萬),(譯者注:這樣即使有人發動無限循環攻擊,他也只能最多執 行 100 萬 Gas 允許執行的計算步數,無法導致系統長期的死循環)。
不過,除了虛擬機的安全性外我們還有其他需要考慮的事情:在以太坊平臺 上,用戶若要與一個智能合約進行互動,必須確定他們面對的程序是以他們想象 中的執行方式去運行(譯者注:例如,一個旨在進行遺產分配的智能合約,用戶 必須確定當自己的財產劃撥進這個智能合約后,這個智能合約在日后真的會自動 地按照設定的規則去分配遺產)。區塊鏈是一個提供了密碼學擔保的平臺,具有 一定的便利性,畢竟代碼是存儲在區塊鏈上的,所有與合約相關的參與者都能查 看此代碼,用戶也能確定代碼真的會被執行,不過若要確保不存在任何形式的作 惡行為和意外的漏洞,這依然具有挑戰性(可參考 Underhanded Contest,這是 一個所謂的“卑鄙 C 程序大賽”,專門編寫一些“說是一套,做是另一套”的程 序,里面的一些例子具有相當的代表性)。我們推薦用戶去探索形式化驗證技術, 在他們與代碼互動的過程中進行自動化的驗證,在金融行業的用例里面,涉及的 經濟利益較大,這樣的技術可能是很有用的。
效率
效率問題是人們對以太坊平臺的主要憂慮之一。具體來說,一些人認為以太 坊平臺太通用了,因此可能會成為“什么都能做,但什么都不精通”的例子。由 比特股團隊(BitShares team)及其他人提出來的一類觀點就是虛擬機內執行的 代碼必然會比原生的代碼慢,相比之下,那種支持很多“預編譯”操作代碼的平 臺顯然會更高效。Gideon Greenspan(MultiChain 平臺所屬公司的 CEO)也提出 了與并發性有關的論點,不過平行化和計算效率是不同的概念,所以將會在下文 與可擴展性相關的段落敘述這個問題。第三個擔憂是以太坊區塊鏈里進行的一些 操作指令,特別是 Merkle 哈希過程,帶來了不必要的緩慢,因此可以將它移除 以實現更高的效率(而且,在私有鏈的場合,可能不太需要這個了)。
EVM 以太坊虛擬機
或許可以說,虛擬機的問題是目前最復雜的。區塊鏈最早的腳本語言——比 特幣腳本,是一個模仿 Forth 語言搭建的基于堆棧的編程語言,它的基礎算法帶 有無大小限制的整數,字符串操作,以及一系列的高級密碼學原語。其執行引擎 的效率還是比較低的,顯然不適合在腳本的層面創建任何形式的復雜應用。不過, 因為 UTXO 模型固有的“無狀態”的特性,在比特幣之上搭建高級應用一直是不 太可能的,因此在比特幣之上的腳本執行效率一直沒有受到太多的關注(這個情 況在最近出現了變化:在一篇近期的博客文章里面,比特幣的核心開發團隊反對 區塊大小從 1MB 擴展到 2 MB,認為這樣的話一個體積最大的交易可能需要十分 鐘才能校驗完畢)。
以太坊原來的編程語言有意做得像比特幣腳本那樣,除了帶有一個狀態豐富 的執行環境,而不是比特幣腳本那種無狀態的。對 256 位整數的限制被添加進去 了(比特幣腳本里還是禁止了這個限制),是為了防止整數乘法成為一種拒絕服 務攻擊的載體。它也曾經考慮過加入基于整數大小的動態 Gas 消耗機制,不過基 于效率的考慮最終還是剔除了。256 位被視為一個最佳的尺寸上限,因為它執行 和計算起來還是相對較快的,而且也具有足夠的資源去處理橢圓曲線加密算法(使用 256 位數)和哈希(大多數主流的哈希算法會提供一個 256 位的輸出值)。 它里面帶有專為哈希和橢圓曲線操作的操作代碼(opcodes)。
那時候的用意是為了支持簡單的金融腳本、if-then 條件語句以及其他的應 用程序,這些場景里 256 位的虛擬機可能會存在一定的效率問題,但相對于在交 易中校驗橢圓曲線簽名涉及的耗費,這些效率問題還是可以忽略不計的(這有點 像比特幣的腳本)。在大多數的案例中,以下的描述是成立的:對一個簽名進行 校驗需要處理超過一千個模塊化的乘法運算操作,而運行實際的虛擬機代碼只需 要簡單地處理一些條件語句及變量的變化。因此,那種認為“只”校驗簽名和運 行“完整”的程序之間存在巨大成本差別的看法,在很大程度上是錯誤的:不管 虛擬機的性能如何,時間瓶頸在于密碼學校驗,而不是在于處理一些 if-then 條件語句。
足夠的極限
不過,在一些場景中還是存在非常明顯的整體開銷的。第一個是在涉及較多 的狀態改變的操作過程中。當前,每一個狀態的改變是以對 Merkle 樹進行修改 的形式實現的,這會觸發 5-20 次反序列化操作,哈希和重新序列號操作,以及 數據庫的更新。就如之前描述的那樣,Merkle 樹若從輕客戶端的友好性來說是 協議的重要組成部分,若要在跨鏈運作中處理“收據”的話就更為重要了;不過, Merkle 樹相關操作對效率的影響還是非常明顯的——基準測試顯示,在某些合 約中,Merkle 樹的更新會耗費很多的時間,若要驗證簽名的話花費的時間就更 多了。
若要緩和這個影響,有兩個途徑。第一個解決方案是比特股團隊推薦的,即 完全去除 Merkle 樹,簡單地在 leveldb 數據庫里存儲狀態。這對狀態更新的效 率大約會提升 5-20 倍左右,不過這是會對輕客戶端的友好性帶來影響的。對很 多私有鏈的應用來說, 這或許是一個合適的做法。第二個方法,也是以太坊團 隊最可能在 1.1 版本的 Serenity 釋出時跟進的辦法,是一個折中的策略:目前 Merkle 樹里允許 32 字節的鍵值對(key/value pairs),在將來會允許無限制大小的值,讓應用程序開發者可以在一個地方存儲數據架構并對其進行頻繁更新, 這樣就能夠減少實際上更新 Merkle 樹的次數。10
在以太坊虛擬機內使用高級的數學和密碼學算法可能是第二個弱點。目前, 在以太坊虛擬機內進行開發的可選方案有環簽名,zk-SNARKs 零知識證明協議, RSA 式公鑰加密算法,奇異值分解(singular value decomposition),甚至是 一些對內存需求較高的哈希函數,如 scrypt。若要引入這些功能,以太坊虛擬 機的性能在實際使用中可能較低:
? 用原生Python語言進行的橢圓曲線簽名校驗需要0.017秒;在Python 版本的以太坊虛擬機中需要 0.57 秒
? 用原生Python語言進行的五把鑰匙的環簽名校驗需要0.119秒;在 Python 版本的以太坊虛擬機里需要 3.68 秒
? g用Python實施對內存需求較高的scrypt哈希函數的運算,會小于一 秒;在 Python 版本的以太坊虛擬機里這個操作的過程實在是太長了,甚至 需要分解到 118 個區塊里才能執行這些交易。
這些情況是由兩個方面的原因所導致的。第一,現有的虛擬機方案已經經歷 了幾十年的開發,有不少優化的 JIT(just-in-time,即時技術)方案,而以太 坊只有相對簡單的 JIT 方案。若要讓以太坊趕上現有的虛擬機的性能,可能需要 幾年的時間。其次,256 位整數的需求讓虛擬機的速度大幅度降低,畢竟其底層 的機器使用的是 64 位的架構,而這些算法的大部分代碼只處理那些小于 64 位的 整數,并不需要在每一個加法和乘法運算中使用整個 256 位的運算器及由此帶來 的整體開銷。
在短期內,我們的解決方案一直是“預先編譯的合約”。本質上說,如果應 用過程中對某種特定的密碼學功能有較高的需求(如 SHA3,SHA256,橢圓曲線 簽名校驗等),我們就給每一種功能分配一個地址(當前我們用較低的地址,如 1,2,3 等),并增加一個協議上的規則,即進入這個地址的一個交易(或內部 交易)消耗低額 Gas(有相應的標準),并輸出一個與輸入值相應的結果。這個 功能并不是整合在以太坊虛擬機里;相反,它是以原生代碼的形式整合到每一個以太坊的客戶端,讓其運行成本更低及擁有原生代碼的速度。這實質上是一個“急 救繃帶式的修復方案”,專門為特定的用例解決需求。不過,它顯然不是最優的: 這意味著對某類智能合約來說——那些帶有稀奇古怪的、對運算資源需求較多的 密碼學算法的智能合約,其“無需許可的創新”可能就會受限于這個設計,它們 無法像普通的智能合約那樣享受任意的靈活性——普通的合約可以在不對協議 層面進行更改的情況下書寫任意的新功能。
WebAssembly ——“EVM 2.0”
基于這個原因,我們的一個研究者 Martin Becze,正在探索用 WebAssembly 作為實現更快的虛擬機的途徑,以提供一個長期的可行解決方案。這個項目有兩 個步驟。第一步是書寫一個 JIT 編譯器,目標是將 EVM 的代碼編譯成 WebAssembly 的代碼,這樣能實現更快的 EVM 實施方案。第二步是使用 WebAssembly 去創建一 個“以太坊虛擬機 2.0”,其對 WebAssembly 增加的功能只有一個,就是一個代 碼翻譯器,可用于(i)插入 gas 計數操作,和(ii)禁止如下的一些操作代碼 (opcode)——那些被認為不太明確的、沒有確定性的、或訪問以太坊虛擬機本 來就不應該訪問的信息的。(如線程,浮點運算)。
基于幾種原因,WebAssembly 被視為是一個理想的方案,這與 WebAssembly 和以太坊共享著相似的設計目標是有關聯的。
? WebAssembly致力于為小型的應用程序提供非常小的代碼體積。一些更 傳統的技術方案(如由 C++生成的字節碼)及其默認的工具往往會生成很大 的代碼尺寸——即使是那些微小的應用程序。 (舉例:參考這個開發者生成 一個小型的Linux 可執行文件的嘗試) 。這對今天的大體積硬盤來說或許不 是個問題,但對一個區塊鏈環境來說,可能會包含由幾百萬的用戶上傳的代 碼,這就帶來了一定的負擔了。
? WebAssembly的設計目標是運行來自不明身份的人提供的未經信任的代 碼。
? WebAssembly已經有多個JIT的實施方案,也有讓它們都具備兼容性的 目標。
? WebAssembly若要用在我們所需的應用場所,其主要的不足之處會是缺 乏 gas 計數的機制,和潛在的非確定性問題,而代碼翻譯器就是解決這些問 題的。在理想中,用戶可以使用(與 WebAssembly 編程所需的)相同的高級 編程語言和開發工具去書寫代碼,而代碼將會在區塊鏈上執行——以一種跟 WebAssembly 環境里一樣的方式去執行,只是代碼翻譯器層將會跟蹤計算步 數,并禁止非確定性的操作。初步的測試表明,gas 的計數在總體上只增加 了 5%. 從初步的測試來看,WebAssembly 自身在不同的場合會有媲美于原生 C++代碼的 25-90%效率——可以說對我們的需求而言,基本上足夠拉近解釋 型語言與原生執行語言之間的差距了。
WebAssembly 的實施目前尚處于初始的階段;已經有一個將 WebAssembly 代 碼轉換成增加 gas 計數的概念驗證模型在運行了,不過若要推出最終產品的話還 需要較多的工作。生下來的工作包括測試 WebAssembly 的多個實施方案,或許會 增加一個 Python 的實施方案以增加其完整性,并將其整合到客戶端里;如果 WebAssembly 計劃繼續下去的話,將有可能被添加到 Serenity 版本與可擴展的 以太坊 2.0 版本(后面的章節會提到)之間的一個版本里,如在 2017 年期間的 某個時間。同時,整體上說,這些以太坊協議的改善方案將有可能先會應用到私 有鏈上,因為在公有鏈上修改錯誤是更難的,這是一個安全性上的考量因素。
需要注意的是,這些解決方案旨在解決初步的效率問題。那些反對無限制的 狀態變更運算、可并行性的主要技術論點是很重要的;雖然在低吞吐量的情況下, 運算到底是在一臺或多臺計算機上進行的問題并不是特別重要,但在高吞吐量的 情況下,就如我們將會看到的那樣,并行化是解決可擴展性的關鍵——甚至比效 率更重要。
關鍵建議
以太坊虛擬機的效率在目前要比其他主流的虛擬機都低。這主要是因為在早 期作出的“靈活性高于性能”的設計目標。對很多簡單的應用來說,這并不是一 個問題,畢竟相對于校驗密碼學簽名的整體運算開銷來說,處理一些加法、乘法和 if-then 條件語句的整體運算開銷可以忽略不計。不過,目前還是不適合將一 些很復雜的運算(如定制化的密碼學)直接整合到以太坊虛擬機里面。
在中期,以太坊的更新版本將有可能使用以下兩種手段的組合:代碼的預先 處理過程,以及將 WebAssembly 作為創建更快的以太坊虛擬機的方案——其代碼 執行效率可以接近原生的代碼。
在此之前,Serenity 的版本釋出將會允許幾種額外的、專用的密碼學操作 (以原生代碼的速度運行),我們推薦那些想使用對運算資源需求較高算法的開 發者先使用以太坊的私有鏈去擴展以太坊的“預先編譯合約”的機制,在原生代 碼的層面通過預先編譯的合約直接加入這些高級的操作——如果他們實在不想 再等了。那些正在使用私有鏈,想獲得更高度的可擴展性的用戶,則可以考慮(i) 立刻整合一些 Serenty 版本計劃中的修改方案,以及(ii)若不考慮輕客戶端的 友好性的話,可以直接移除 Merkle 樹。
可擴展性
可擴展性是每一種區塊鏈技術都在面臨的根本性挑戰。若用傳統的眼光去看, 去中心化協議一種備受稱贊,原因是它們擁有更高的可擴展性,讓用戶和公司以 低成本、高效的方式分發文件,也能讓應用程序去管理數百萬用戶之間的通訊, 因此對非技術性的用戶來說,他們對區塊鏈的印象可能是,這種“點對點貨幣” (現在是“點對點智能合約”)應該有同樣的好處。
然而,事實并不是這樣。區塊鏈的去中心化應用有著自身的獨特特性——它 的數據并不是以“在不同的參與方之間分割、存儲數據”,而是“復制”的:網 絡中的每一個節點處理每一個交易,并維護著整個狀態(譯者注:可以理解為總 賬本)。這帶來的結果是,區塊鏈得到了去中心化技術的一些好處——特別是在 容錯和中立性方面,以及讓每一個用戶都能親自校驗區塊鏈上的每一個交易而得 到的極強的可校驗性。但是,這也讓它的可擴展性相對于傳統系統來說更低了。 實際上,不管區塊鏈有多少個節點,它的交易處理性能始終無法超過單一的節點。 還有,與 BitTorrent 這樣的網絡不同的是,BitTorrent 的網絡性能會隨著節點的加入而提升,而區塊鏈的性能永遠不可能高于每一個節點的性能,還有,隨著 節點的增加及其帶來的節點間通訊延遲,其性能可能還會更低。
公有鏈上面臨的麻煩會更多。公有鏈上的每一個節點都必須處理整個網絡的 交易(這還意味著它讓每一個人都能加入的設計目標,實質上意味著很多人就是 用消費級的筆記本電腦加入網絡的),而且我們也不可能期望每一個節點都會將 100%的 CPU 運算資源貢獻出來。這是有幾個原因的。各個節點的 CPU 一直在同時 運行其他應用程序,也不是總是在線的。其次,除了設備的限制外,公有鏈還需 要面對經濟激勵上的限制:如果維護節點的成本顯著高于節點的總成本,那么網 絡就傾向于走向中心化,即兩個節點基于經濟因素的考量,可能會互相信任并最 終只運行一個節點 11。還有,節點可以簡單地停止校驗網絡上的校驗,并直接享 受別人提供的校驗服務——這是一個明顯的“公地悲劇”,若很多礦工同時嘗試 這樣的做法,就可能會帶來很大的系統性風險。中心化和不參與校驗的均勢是必 須防止的失敗模式,而且必須考慮到安全性上的誤差,畢竟當一個系統進入一個 不利的均勢,就很難改變規則或強制推倒重來了。
基于這些原因,雖然 C++版本的以太坊節點理論上的交易處理性能是超過 1000 交易/秒,但以太坊網絡的區塊 gas 限制帶來了一個軟性的上限——10 個交 易/秒(假設這是簡單的交易,那些復雜的交易更接近 1-5 個交易/秒,而當前在 網絡中實測的結果是接近 6.8 交易/秒)。比特幣若單從 CPU 限制的考慮能實現 4000 交易/秒的性能,但現在實際上有一個 7 個交易/秒的上限(還只是對小型 交易而言),實測中約等于 3 個交易/秒 12。私有鏈并沒有這些方面的憂慮,因 為它們可以要求每一個節點配置高性能的計算機和網絡條件,并在現實世界中確 保參與者在運行一個真實的節點;因此,基于比特幣和以太坊的私有鏈可以輕松 實現 1000 個交易/秒。因此,在短期內,對很多企業用戶來說,私有鏈可能是最 適合的、最實際的選項——若他們要將區塊鏈用于主流的用例并達到足夠可擴展 性的話,不過在大規模使用的場景中可能還是不夠的:DTCC 現在每天處理 1 億 次操作(約等于每秒 1200 次),而上海證券交易所的交易系統訂單處理峰值可 超過 8 萬筆/秒,至于那些區塊鏈推廣者們認為前途廣泛的小微交易應用,需要 的交易性能就更高了。
解決方案
為解決可擴展性面臨的挑戰,我們在探索兩個類別的解決方案:sharding (分片)和 state channels(狀態通道)。Sharding 技術與數據庫分片的技術 相似,狀態的不同部分會由不同的節點去存儲,交易會被引導到不同的節點—— 取決于這些節點負責哪個分片,因此這些分片可以被同時處理;而狀態通道是比 特幣模式的“閃電網絡”的一個廣義方案,它尋求將大部分的交易在參與方之間 直接進行,而不在區塊鏈上進行,最終只使用區塊鏈作為最終的爭議仲裁手段。 (現實問題:Dominic William 的 dfinity/pebble 提議使用了這類分片技術嗎?)
在前一個方案中,私有鏈和公有鏈的分片用例有著不同的考慮因素。在私有 鏈分片的例子里,目標是中規中矩的:讓以太坊最大程度地并行化。每一個節點 始終要處理每一筆交易,唯一不同的地方是當運算進行并行化了,網絡的可擴展 性可以通過增加每一個節點的 CPU 的核心數據及內存去擴展。
在公有鏈的案例中,目標就更有雄心壯志了:創造一個區塊鏈協議,其網絡 的完全節點(譯者注:完全節點即存儲完整的總賬本的節點)數量即使為 0,也 能生存下去——即創造一個網絡,其中的每一個節點只處理所有交易的一小部分, 并用“輕客戶端”技術去訪問區塊鏈的其他部分,同時保留了安全性。在這種模 式下,交易不僅在不同的 CPU 核心上處理,而且會在不同的計算機上處理,就如 公有鏈加密貨幣經濟學的分析 13 那樣,并不需要相信每一個節點。以太坊 2.0 和 3.0 的長期計劃,是將協議改造成一個可運行 VISA 支付網絡級別的區塊鏈,甚 至是其幾個級別之上的性能——這還不需要特別的機器,只是由運行在商品級的 筆記本電腦所構成的網絡上。14
為解決這個問題,我們的整體方案是從實施一個并行化計劃出發(通過以太 坊改善提議 EIP105,這是在 Serenity 版本里安排的),這會提供私有鏈方案所 需的可擴展性特性,以及公有鏈上的中規中矩的改進,在此之后的以太坊 2.0 版本里將會包含一個密碼學與經濟學相關設計的計劃,以通過分片技術為公有鏈 增加安全可靠的可擴展性。EIP105 及一些為 Sernity 版本而設的特性已經被整 合到一個 Python 語言的概念驗證中;2016 年的末期可能會推出測試鏈,2016年的早期可能會有一個實測的網絡,當然了時間上的推遲是有可能的,我們的指 導思想是只在產品就緒的時候發布,并不會沖著計劃表發布。在這份路線圖的前 半部分,主要的挑戰是開發工作,不過在日后的階段會涉及與經濟激勵以及點對 點網絡架構相關的研究任務。
私有鏈里的并行化
總體上說,如果計算任務可以被完全的并行化,私有鏈的可擴展性就會是無 限的:你總是可以往每一個節點里添加更多的 CPU 核心數量。若事實不是這樣, 則最大的理論速率就受限于安達爾定理(Amdahl’s law):你能給系統進行提速 的極限取決于那些不能進行并行化的部分的倒數。如果你可以進行 99%的并行化, 那么你就可以提速到 100 倍,但如果你只能實現 95%的并行化,那么你就只能提 速到 20 倍(譯者注:在本例中,若有 99%的并行化,則有 1%是不能并行化的, 那么 1%的倒數即 100,所以得出可提速的極限是 100 倍,95%的例子同理)。我 們可以給一個更精確的描述:假設 CPU 時鐘的速度是固定的,處理一批交易所需 的理論最小時間跟交易執行的依賴關系圖里最長鏈條的長度是成比例的;即最長 鏈條里面的交易在理論上會有相互的影響,因此必須按順序執行。
多重簽名合約(multisig-Oracle)的智能合約執行模式的最大功能或許是 ——每一個合約都有自己的一系列“公證人”,單獨地就該合約的執行結果進行 投票,而不考慮其他合約的事務。彼此之間沒有協同工作,這就意味著沒有彼此 間的依賴性,因此尋找將底層的資產管理層或數據層進行并行化的方案就變得相 對簡單了 15。以太坊里的循環與協同的模式帶來了這樣的挑戰:理論上,并不存 在這樣的一個限制,去明確“狀態”中哪些數據是可以被合約執行過程所依賴的, 因此將計算任務按照序列的方式去運行可能就是我們的現實方案了。16
因此,若我們想通過 sharding 技術實現可擴展性,我們就需要對以太坊的 執行模型作出一些妥協,讓其能進行并行化,來自傳統并行計算理論的經驗就很 有用了。我們不再將整個狀態構造為單一的機器,而是將其作為分布式存儲機, 在里面交易被限制為只處理狀態的一部分,這樣它們就可以進行并行處理了。若 要實現分片間的通訊功能,我們需要添加消息傳遞機制;這里面最主要的挑戰就是要確保它具有確定性。我們正采用的一個手段,它可以被用于公有鏈和私有鏈 的場景中,那就是一個“收條”的范式:交易的執行過程可以改變局部分片的狀 態,不過它同時會生成“收條”,被存儲于一種共享的存儲空間里面,以后可以 通過其他分片的交易執行過程被審閱(但不能被修改)。
若要觀察一下這種技術如何在現實中應用,可以在較高的層次上分析一種數 字代幣例子。用戶 A 持有 500 單元的 X 代幣;這個信息是存儲在分片 M 里面的。 用戶 B 持有 100 單元的代幣 X;這個信息是存儲在分片 N 里面的。假設用戶 A 想 從分片 M 中發送 100 單元的代幣 X 到分片 N 里。在一個同步的模式里,所有的分 片是被全部節點存儲的,這實現起來會很簡單;就如以太坊代碼的一個例子—— 這個例子經常在幻燈片和我們開發者的 T 恤背后可以看到,代碼會很像這樣:
在一個異步的模式中,我們就需要將這些過程分成幾個階段:
1、 在分片 M 里,把 A 的余額減少 100,并生成一個收條,稱“B 應該接 收到 100 單元的 X 代幣。這個收條的 ID 號是 17265715249。“
2、 在分片 N 里會以一個交易的形式引入該收條被創建的證據(在私有 鏈的例子會是指向共享存儲模塊的一個指針,而在公有鏈的例子里則會是 Merkle 的證據)。這個合約會對以下細節進行校驗:(i)該證據是正確的,而 且(ii)未曾消費過具有相同 ID 號的收條。這個合約給 B 的余額增加了 100, 并在存儲區里標記上該收條及其 ID 號已經被消耗的事實。
3、 在更高級的應用中,若分片 M 在運行一個智能合約,它要在付款完 成后執行一些操作,這樣分片 N 中的記錄就能用作一個收據,提供給分片 M 并證 明付款已經完成,這樣分片 M 就可以繼續它要進行的操作。
若被消耗過的收條記錄不斷增加,其解決方案可以是給收條設置一個超時參 數(例如幾個星期),并將那些太舊的被消耗收條列表清除掉。
收條的模式是很方便的,因為它對應了兩種開發者們很熟悉的編程概念:異 步編程和 UTXOs(比特幣里面的“未花費的交易輸出”的概念)。在比特幣里面, 交易運行的方式是消耗一堆由之前的交易創造出來的 UXTOs,然后生成一個或多 個新的 UTXOs,這些新生成的 UTXOs 也能被將來的交易所消耗掉。每一個 UTXO 可以視為是一種“幣”:它有一個面額,有一個持有者,而一個有效交易的兩個 主要規則是:(i)該交易必須包含它消耗的每一個 UTXO 的持有者的簽名,而且 (ii)UTXOs 被消耗的總面額必須大于或等于該交易產生的 UTXO 面額的總量。
雖然 UTXO 的模式在某種程度上是很笨拙的,它需要復雜的錢包代碼去決定用戶 消耗 UTXO 的順序,以優化交易費,并讓那些沒有仔細實施該技術的錢包暴露到 拒絕服務攻擊之中,不過它在某種程度上也提高了對用戶的隱私保護水平(因為 用戶的資金并不能立刻與其他人的資金聯系起來),也提供了一定程度的可并行 性,也讓在其內擴展一些密碼學技術成為可能(這會在“隱私保護”的章節進行 討論)。收條是由交易執行過程所產生的對象,可以被將來交易的執行所“消耗”, 這與 UTXOs 有相似之處;因此,它可以被理解成用圖靈完備智能合約實現的廣義、 概況化的 UTXOs 模式。
收條模式與異步編程的聯系是挺明顯的。若分片 M 里的函數 A 用異步的方式 調用分片 N 里的函數 B,這可以通過如下的方式實現:用代碼執行函數 A,并生 成一個收條(內含提供給函數 B 的參數),之后執行函數 B 的交易可以消耗這個 收條。若需要一個回調函數,則當調用函數 B 的時候,函數 A 可以在狀態中留下 一個對象,并聲明它在等待來自函數 B 的回復,這個對象遲些就會被由函數 B 生成的收條所消耗,并得到一個回復。
需要注意的是,在私有鏈的場景中,一旦交易被處理后,收條就可以即時在 所有的分片中進行處理,這個過程會持續下去,直到收條生成和執行的完全鏈條 被執行完成。由于收條的異步特性,這個過程還是可以被高度的并行化的:在每 一個分片中的交易可以并行處理,進入每一個分片的收條也可以并行處理,如此 類推;因此,只要在一個分片內沒有太多的交易在同時進行,并且收條-回調的 鏈條的長度有一定的控制,那么就能完全解決并行化的問題。
從私有鏈到公有鏈
在公有鏈的場景中,我們會面對兩個額外的問題。第一,在不同的分片內處 理交易執行的節點是在地理上被分割的,在不同的計算機上運行;這就導致了處 理收條的工作并不是即時的,一個復雜的異步合約執行可能需要超過一分鐘才能 執行完畢。其次,這些計算機并沒有相互信任的關系。因此,一個在分片 M 內處 理交易的節點并不能簡單地通知分片 N 內處理交易的節點并聲稱“我已經創建了一個收條了”;而是要證明給它們看。幸好,Merkle 證明可以是一個理想的解 決方案。
在以太坊 2.0 的公有鏈中,設計目標是構造一個系統,其中的狀態集合是分 布在在網絡中的不同節點上的,每一個節點只持有狀態的一小部分“分片”。所 有的節點都會跟蹤一個“header鏈”,里面包含了狀態的Merkle樹根的哈希值。 因此,可以很輕松地整合一個收條方案:當分片 M 創造了一個收條后,一個 Merkle 分支(如一系列用于證明該收條存在的哈希值鏈條)可以作為一個進入分片 N 的交易進行傳遞,然后若需要一個回調,則可以創建另一個收條,并返回另一個 Merkle 分支。
下一個問題是決定由誰去校驗每一個分片。當然了,分片技術的目的就是要 舍棄“每個人處理一切事情”的范式,并在很多節點間分割校驗的責任。原生的 工作量證明機制若要安全實現這個技術會比較困難:比特幣整合的工作量證明機 制是完全匿名的(連假名機制都沒有)17 共識機制,若某個分片只由總算力中的 一小部分去維持其安全性,那么攻擊者可以調用他們的算力專門去攻擊這個分片, 這樣就有機會用不到 1%的全網算力去攻擊整個區塊鏈。
其實,這個狀況在以下的一些解決方案中會發生變化:股權證明機制,如 puzzle towers 這樣的改進版工作量證明機制,以及在私有鏈里使用的拜占庭容 錯共識算法 18:在共識處理過程的參與者們會有某種身份,即使是類似地址的密碼學化名身份,因此我們可以通過隨機采樣方案解決“定向攻擊”的問題,即從 整個驗證節點池里面隨機選擇某些節點的集合去處理任意給定的交易集合,這樣 攻擊者就幾乎無法定向攻擊任何特定的交易或特定的分片。還有,惡意和瀆職行 為是很容易被打擊和管制的;就如 Vlad Zamfir 所說的那樣,“若股權證明機制 里某個節點挖出了一個無效的區塊,其后果就如同挖礦工廠被燒掉一樣”。19
因此,公有鏈的場景中,整體的思路是首先將交易收集到一個各自獨立的“交 易組”里面,然后讓每一個交易組選擇一個隨機的驗證節點去進行驗證。“header chain”自身不再校驗全部的”交易組”,而只是校驗某種校驗憑證——這個憑 證會隨著交易組提供,它包含來自特定集合的、具有足夠數量的大多數驗證節點 的簽名。
將分片技術應用到區塊鏈應用中
現在還有兩個問題。第一,狀態應該怎么進行分片?在公有鏈的場景中,這 可以進一步分解成“應用程序間的分片”,目標是將狀態以某種形式進行分片, 從而讓多個在大多數情況下獨立的應用程序以并行的方式處理;還有“應用程序 內的分片”,即應用程序被分割到多個分片中。第一個問題或許比較簡單,畢竟 應用程序間的互動往往是低頻率的,因此最簡單的解決方案可以是通過地址空間 進行分片。在私有鏈的場景中,區塊鏈往往只被用于一種應用,因此“應用程序 內的分片”在這種場合會更有優勢。其次,我們如何能設計出高級的編程語言, 去利用區塊鏈的應用程序內分片的潛能,并將其優勢最大限度地呈現給開發者 們?
從分片的角度來看,面臨著如下的挑戰:我們如何創建一個分片方案,同時 可以提供應用程序內和應用程序外的分片功能,而不增加太多的復雜性?當前, 我們解決這個問題的主要提議是 Serenity EIP105 提議,其主要思想如下:首先, 地址空間被拆分為 65536 個分片,只有在同一個分片內才能進行同步的交易執行; 其他的則只能以異步的方式執行。其次,一個具有給定片段的代碼可以以相同的 地址存在在多個分片中,讓程序可以同時在多個分片之間存在。合約或許可以采用在傳統的并行計算場景里常見的分區技術(如 SQL 查詢),去決定如何存儲它 們的數據:通過某些特定鑰匙的特性屬性進行分區,隨機向分區里分配新的對象, 或許一些更智能的負載均衡算法等。在 Solidity 里面,可行的方案可以是定義 一個 shardedMap數據結構,在編譯的時候定義一個將鑰匙映射到分片 ID 的方案。 我們預期高級語言的開發者探索以下技術的組合:SQL 風格的分片方案,異步編 程概念——如回調和 promises,以及其他的技術,從而讓開發者更容易定制一 個可擴展的區塊鏈環境。
對特定的區塊鏈應用來說,最簡單的分片方式是存在證明(使用區塊鏈去展 示特定的數據片段在特定的時間存在)。這種用例并不需要擔心雙重支付的問題, 而且已經被 Factom(公證通)和其他項目以一種可擴展的方式在使用。“不存 在證明”,即證明一個“存在證明信息”還沒有被發布到區塊鏈上(如證書撤回), 就稍微要難一點了,因為你無法簡單地使用 Factom 方案里的“只發布 Merkle 樹根”的手段去解決它,不過還是可以最大限度地并行化的。20
在數字資產的用例中可能會更難處理,但還是能通過異步編程實現的,就如 上面提到過的那樣;其中唯一的效率問題是付款發出和收款人能實際使用之間存 在輕微的時間差。雙方(或多方)智能合約跟數字資產并沒有明顯的差別,也面 臨著同類的限制。諸如金融領域的身份驗證這類應用程序可能會涉及數字資產轉 賬系統和身份管理系統之間的互操作過程;在這里異步處理并不是太大的問題。 原子化交易實施方案將需要處理一些特殊的案例,即雙方嘗試同時參與一筆交易; 鎖定機制和由合約生成退款交易的機制或許是處理這個問題最顯然的策略了。那 些基于區塊鏈技術并實時處理訂單薄系統的市場看上去是最難處理的;比特股開 發團隊最近得出結論,若不引入多個市場及隨之而來的套利空間,是無法應用此 技術的。至于類似高頻批量競價機制市場這樣的非即時市場或許可以使用并行排 序算法。(若這是真的話,這對來自 Overstock 的 T0/Medici 及同類項目有什么 影響?)
狀態通道
States channels(狀態通道)是這樣的一種策略,它保留底層的區塊鏈協 議運作的模式,但改變協議的具體用法,以解決可擴展性的挑戰:它將區塊鏈作 為處理任何形式交易的主要處理層,而是作為一個結算層——只處理一系列互動 所產生的最終交易,并只在出現爭議的時候執行復雜的運算操作。
為了更細致地了解這個概念,我們先來考慮一下狀態通道用在支付系統的例 子。假設 A 有 100 個幣,想以較高的頻率支付給 B。這樣,A 開始將 100 個幣發 送到智能合約里面,當 A 想執行其對 B 的第一筆付款時(例如 0.1 個幣),他創 建一個有數字簽名的“憑證”(這并不是一個有效的區塊鏈交易),該“憑證” 上聲明(99.9,0.1,0),在這里面,99.9 表示他本人希望得到合約里的多少 幣,0.1 表示 B 應該得到多少個幣,而 0 是一個序列號。而 B 接著進行會簽 (counter-sign)。若 A 希望再支付 0.2 個幣,他就簽發一個新的憑證,聲明(99.7, 0.3,1),同理 B 又進行會簽。現在若 B 想向 A 返還 0.05 個幣,她就應該簽發 一個憑證,聲明(99.75,0.25,2),然后 A 進行會簽。
在這個過程中,每一個參與方都可以往這個合約中發送一個交易,從而關閉 這個通道,并開始一個結算的過程。這會啟動一個時間區間,在這期間 A 或 B 可以提交憑證,具有最大序列號的憑證將會被處理。如果 A 故意提交一個更早序 列號的憑證,則 B 可以自己提交具有最大序序列號的憑證。這樣,區塊鏈就可以 被視為某種“密碼學法庭”:作為一種成本較高的仲裁手段,它是一種用于提供 安全性的最后手段,因此也降低了造假和欺詐的動機,當然了,如果這個過程運 行得很好,那么區塊鏈只會偶爾被用來做最終結算。
這種簡單的支付通道機制帶來了兩種歸納結論。首先,如果你想支持任何人 之間的大規模支付活動,而不只是A與B之間的話,你也不想為每一個人創造“N 的平方”這么多數量的通道,那么你就可以“組合”通道:如果有一個 A 與 B, B 與 C,C 與 D 之間的通道,那么你就可以將 A 到 D 之間的轉賬變成 3 條通道的 更新過程,每條通道更新一次。21
其次,可以加入智能合約。如果 A 和 B 想達成一個金融合約,這個合約根 據某個公式進行轉賬,這樣他們可以都簽發一個憑證(H(C),k),在這里 H (C)是一段代碼的哈希值,而 K 是最近的序列號;這實質上是告訴狀態結算合 約“評估進行了哈希運算的 C 的代碼,并讓結果告訴你應該向 A 和 B 各發多少錢”。 舉例來說,C 可以是差價合約這類金融合約;如果狀態通道控制著多種資產,它 可以是一大類不同類別交易里的一種,如有杠桿的交易抵押品管理協議,期權等。
當到了從通道中取出資產的時候,A 和 B 可以運行 C,由此都知道他們各自 應該得到多少錢,區塊鏈就不需要評估這個合約了;若 C 給 A 發送了 75 個幣, 給 B 發了 25 個幣,為了方便起見,他們可以都簽發一個新的憑證(75,25,k+1), 若任意一方拒絕執行,則另一方可以簡單地提交(H(C),k)以及 C,并讓區塊鏈 進行運算以及引出同樣的結果。
狀態通道并不是一個完美的解決方案;具體來說,還不清楚它能怎么適用于 大規模的多用戶應用場景,它也沒有給原來的區塊鏈在可擴展性上帶來多少改善 (從存儲更大狀態體積的角度去考慮)——它只增加了實際上的交易吞吐量。不 過,它也有不少的好處,除了作為一種可擴展性解決方案外,它也是一個隱私保護方案,因為區塊鏈在這個過程中看不到中間的支付或合約信息,除了最終的結 算和爭議解決過程;它也是一個解決延時問題的方案,因為兩方之間的通道更新 幾乎是即時的——比任何區塊鏈上的解決方案都快(無論是公有鏈還是私有鏈), 甚至可能比中心化的解決方案都快——因為 A 與 B 之間的通道更新無需中心化服 務器也能實現。22
狀態通道理論上不需要修改以太坊的協議也能實施,如 Raiden 這樣的團隊 已經在將狀態通道網絡整合到以太坊上了;Jeff Coleman 和其他人正在研究往 以太坊上整合狀態通道的最佳方法。因此,這可能是在短期內最安全的可擴展性 解決方案了(以及隱私保護方案,在下面的章節會提及)。
關鍵建議
在短期內,關心可擴展性的機構有兩個選項:(i)不管是在公有鏈還是私 有鏈上,探索將大部分的應用程序邏輯放到狀態通道里面的做法,還有(ii)在 一個以太坊私有鏈版本里實施 EIP 105 計劃,并使用異步編程及分片機制去實現 并行化。在使用這個方法之前,用戶應該先決定他們的應用程序是否能在當前的 單線程以太坊實例中運行;性能需求低于 2000 交易/秒的應用程序并不需要并行 化的特性,現在就能在以太坊的私有鏈上實施了。若不采用狀態通道的話,公有 鏈當前的可擴展性并不適用于大部分的金融應用程序,畢竟以太坊的公有鏈只能 安全地支持 10-20 交易/秒。
隱私保護
以太坊及區塊鏈應用程序面臨的另一個主要挑戰是隱私保護問題。這個問題 很簡單:多個節點驗證和審計系統中的所有交易,保證了記錄的真實性,但也帶 來了隱私保護上的問題。在一些案例中,很多區塊鏈用戶對這點理解不夠深入: 很多公司剛開始關注區塊鏈,是因為他們聽說區塊鏈是一項極佳的信息安全技術, 不過要經歷一段時間后他們才能理解區塊鏈提供的是信息的真實性,而非隱私性, 而他們概念中的“信息安全”指的是隱私保護。
首先,最重要的是要明白私有鏈并不是一個隱私性的解決方案(除非區塊鏈 只有一個節點,這樣......它是否還能叫區塊鏈就有一定的爭議了)。一個具備 N 個節點的區塊鏈的容錯性可以達到 N/3 甚至更高,取決于你選擇的網絡模型,若 從可驗真性的角度看有 N/2 的容錯性,但從隱私保護的角度看,即使是少量的失 誤也可能導致很嚴重的后果。原因很簡單:任何擁有該數據的節點可以發布該數 據。如果你對信息安全的主要考慮是隱私保護,而且你沒興趣了解高級的密碼學 或最起碼的密碼學與經濟學相關設計,如狀態通道,那么你可能適合用一個中心 化的服務器而非區塊鏈去實現。
區塊鏈隱私保護相關的解決方案通常有兩種:低科技的解決方案,即簡單地 依賴密碼學哈希運算、簽名和密碼學與經濟學相關設計去減少信息暴露及區塊鏈 上信息間關聯性被解開的可能性。高科技的解決方案,即使用高級的密碼學技術, 去提供非常強大、在數學上可證明的隱私保護特性,讓區塊鏈可以公開地處理交 易和合約,但混淆其內容,這樣外人無法進行解密。兩種策略都有各自的局限: 低科技的方案更容易實施,但其隱私保護程度是“統計學意義上”的。而高科技 的方案更強大,但開發起來會更困難,而且可能要依賴于一些并沒經過仔細測試 的安全性假設。
了解相關的目標
在開始為公有鏈或私有鏈研發一個基于密碼學的隱私保護方案前,必須先了 解具體的需求。在公有鏈的共同目標就是盡量隱藏信息。理論上“黑盒”區塊鏈 是一個理想方案,即使用密碼學技術去混淆整個狀態及狀態變換的規則,因此用 戶可以發送加密的交易并讀取與他們相關的信息,但不能解密其他信息。實際上 能實現這項方案的密碼學混淆技術理論上是存在的,但當前效率非常低,幾乎是 不實用的。最近發表的一篇論文里預計“(若要用上這項技術)在同樣的 CPU 上執行一個 2 位的乘數需要 1.3*108 年”。不過,有一些稍微弱一點的密碼學可 以提供更實際的隱私保護方案,可以為特定的數據或元數據提供完全的隱私性保 證。這些機制會在接下來的章節介紹。
在私有鏈,或公有鏈里的很多類型的金融應用案例中,需求是更具體的:在 特定的案例中,監管方需要得到相關的信息。同時,金融機構里面也有了解客戶 個人信息的需求,最起碼是要確定該客戶的個人信息包含特定的屬性(如確定他 們的用戶不是美國公民或居民,這種要求對銀行和金融初創企業來說是很常見的, 因為這可以降低監管風險及合規成本)。其他需求可能還會基于數額,如向相關 的金融監管機構匯報超過 10000 美元的大額交易是一個常見的要求。
處理這些要求的“基礎案例”可以是簡單地在區塊鏈上發布與每一個用戶賬 戶相關的身份信息,讓應用程序在于賬戶互動前先檢查這些信息。不過,這顯然 是透露得太多了;DTCC 最近發布的一篇文章提醒,“與身份相關的信息并不適 合存儲在一個去中心化的賬本里,除非該項技術走向成熟并證明它能抵御攻擊”。 因此,這帶來了一個挑戰——是否有一種方法既能滿足監管者與其他信息上的需 求,又能在同時避免透露過多的信息?
低科技的解決方案
在低科技的范圍里,過去 10 年間有不少令人矚目的解決方案被設計出來了, 這可以用于提高公有鏈支付系統的隱私保護中(還有更通用的資產轉讓)用戶案 例。最簡單的策略是為每一個操作設置一個一次性的賬號,這樣單個用戶的活動 無法彼此聯系在一起,然后引入一種所謂“避免合并付款”的機制,極大地降低 用戶活動的可關聯性。23
CoinJoin 是一種更高級的策略,它創建了一種區塊鏈上的協議,N 個參與方 在區塊鏈上合并和重新分割他們的資產,這樣外人在查閱區塊鏈數據時無法得知 輸入項與輸出項之間的對應關系。
對智能合約用例來說(更準確地說是雙方或多方金融合約),就如前面可擴 展性章節里討論過的那樣,狀態通道是目前最佳的低科技的隱私保護方案:除非 發生紛爭,或合約的一方失蹤,其他人無需知道任何合約的細節,甚至無需知道 該合約存在過。
若特定的機構需要了解賬戶被誰擁有,有幾個方法可以滿足其需求。最簡單 方法或許是要求每個賬戶得到特定的 “KYC 授權機構”的授權;這個授權機構 就能得知每個賬戶后的現實身份,也能通過避免合并付款交易鏈和 CoinJoin 實 例去跟跟蹤資金的流動,而其他人就看到具有“半匿名”特性的交易輸出鏈條。 識別信息可以通過 Merkle 樹發布在區塊鏈上:KYC 授權機構可以簽發 Merkle 樹 的根值,若某個用戶希望向一個應用程序證明特定的信息(如姓名,年齡,ID 號碼,公民身份狀態),那么他們可以向程序提供 Merkle 樹的分支信息,而無 需透露其他的信息。
實施這種方案面臨的最大挑戰是法律上的,而不是技術上的;就如前面章節 提到過的那樣,金融應用案例通常需要執行它們自己的 KYC 政策,而不能簡單地 依賴第三方提供的服務。不過,這種挑戰可能與特定的案例是高度相關的,而很 多應用案例中,可能直接就可以成為軟件提供商,從而避免了這些方面的憂慮, 并將資產的托管權交給那些需要執行復雜驗證工作的一系列機構去進行。
高科技的解決方案
從高科技的角度看,有三種最佳的技術可以用于以太坊平臺上,這就是環簽 名,ZK-SNARKs 零知識證明以及秘鑰共享技術。
環簽名技術是一種特殊類型的密碼學簽名,它能夠證明簽名者擁有一個對應 特定集合公鑰的私鑰,而不會暴露出簽名者的身份(該私鑰對應哪個公鑰)。另 外,還有一個更高級的版本,即可鏈接的環簽名,它有一個額外的特性:如果你 用同樣的私鑰簽名兩次,這個事實就能被檢測到——但不會暴露出其它的信息。 總體上說,環簽名技術可以用于證明簽名者屬于某個集合里面的成員之一:例如, 某種特定服務的授權用戶構成了一個集合,一個人可以用這項技術證明自己屬于 這個集合里面的一員,但不需要暴露出自己的身份。可鏈接的環簽名技術在區塊 鏈場景中可能是最有用的,因為可鏈接的特性增加了抵抗雙重支付的關鍵能力: 在保留完整的隱私性的前提下,單個參與者不能進行雙重支付——如果他們這樣 做了,就會被查出來。
這項技術的一個天然的應用,就是為區塊鏈資產管理而設的簡化隱私保護計劃。例如,開發者可以整合一個簡化版的 CoinJoin 方案,在這個方案中,用戶只需要往智能合約里發送一個單元的某種資產,在滿足以下兩種情況時可以將這些資產提取到另一個賬號中——提供一個可鏈接的環簽名,以證明(i)他們是其中一個存款者,而且(ii)他們之前沒有提供過一個簽名,也沒有進行過提款。 24
這項技術若用于現有的身份管理平臺之上,就是作為一個安全的、帶有隱私 保護機制的身份唯一性(一一對應)認證方案。例如,若監管者允許金融平臺在 無需校驗身份信息的情況下開放小額賬戶(如 200 美元以下)的存款和轉賬權限,但對超出這個數額的賬號會要求提供身份驗證信息。在現在,電話號碼通常可以 作為一種身份唯一性認證手段,不過它的缺點是(i)它不能保護隱私,而且(ii) 電話號碼與身份之間并不是一一對應的。有一個潛在的解決方案(假設存在某種 密碼學數字身份管理方案 25)就是讓用戶使用可鏈接的環簽名去證明(i)他們 是一名授權用戶,而且(ii)他們還沒有開設一個賬戶,這樣的話他們就被允許 開設一個帶有 199 美元限額的賬號。用戶只有在提供更多身份信息的情況下才能 將賬戶升級到更高的限額。隱私性的特性并不需要是絕對的;具體來說會根據限 額的不同設定相應的界限,低于該界限時只需提供少量的信息,而高于該界限時 需要提供更多的信息,而可鏈接的環簽名技術可以用于保護涉及更高等級信息的 隱私權。
加法同態加密是可鏈接環簽名技術的天然搭檔。加法同態加密技術背后的概 念如下:你可以為原始值進行加密,若你將 x 和 y 這兩個值加密生成 e(x)和 e(y), 第三方可以在不需要知道 x、y 的值或任何隱私信息的情況下,計算出 e(x+y)的 值。這個技術與密碼學概念“范圍證明”(Range Proofs)結合起來,被 Greg Maxwell 和其他人擴展成為機密交易(confidential transactions)方案,這 個方案能對區塊鏈上的所有的交易值和賬戶余額進行加密,用戶只能看到自己賬 戶的余額以及進入自己賬戶的交易相關值,同時能夠保證賬目的正確性(如交易 結果是零和的,一個人的收入必然對應另一個人的支出,任何人不能憑空創造出 新的貨幣,最重要的是任何賬戶的余額都不會是負數);令人驚訝的是,從數學 的角度看,最后一個要求給開發類似方案的工作帶來了很多困難。26
這樣的一個機密保護方案在理論上可以與狀態通道技術一起,創造一個具有 高度隱私保護性能的智能合約平臺:用戶可以進入 State Channels,其互動過 程不會被其他用戶看到,最終就一個新的集合的余額達成共識,與此同時舊的余 額和新的余額是被完全加密的,而公眾能夠校驗的結論是(i)余額的改變是零 和的結果,而且(ii)所有的新余額必須是非負數的。可鏈接的環簽名技術可以 用于保護身份,加法同態加密技術和范圍證明技術可以保護余額的機密性,而 State Channels 可以在帶來該信息改變的互動過程中保護其安全性和隱私性。若有某些中心化的參與方提出監管方面的需求,這個特性可以整合到用戶允許使 用的智能合約集合里面。27
ZK-SNARKs 是一個非常強大的密碼學原語,其定義如下:ZKSNARKs 是一個密 碼學的證明,里面有一個私有的輸入項 I,這個輸入項只為證明者所知,另有一 些公開的程序P,以及公開的值O,可得P(I)=O,而不需要透露出輸入項I的值。 要了解這個原語可實現的功能,可以參考一下身份驗證這種特定的場景。通過 ZK-SNARKs,你可以提供諸如“這個密碼學鑰匙的持有者擁有一個由 X 機構發放 的數字 ID 證書,至少有 19 歲,是 Y 國的公民,并有一個駕照”這種信息的密碼 學證明,而不需要透露出有關你身份的信息。28
ZK-SNARKs 可用于資產轉讓業務場景的隱私保護方案中,實質上是隱藏了交 易之間的關聯,也能為智能合約創造更好的隱私保護性能。一個叫 Hawk 的項目 引入了一種“私有合約”的概念,它的可校驗性并不依賴于某些個人或機構,而 需要一個參與方確保其隱私性,在這種模式中的“管理者”的任務是負責更新加 密后的智能合約的狀態,并證明這些更新是有效的。這個管理者會看到所有的數 據,不過即使這個管理者失職,其他的參與者也可以繼續進行互動(這個過程可 能會導致隱私信息的泄露,但這只針對該特定互動過程而言)。管理者這個角色 可以簡單地由互動過程中的其中一個參與方擔任,或者可以是一個中心化的機構; 在受監管的金融產業場景里,最理想的情況是由中心化機構擔任管理者這個角色, 畢竟這種場景里的開發者本來就需要了解系統中發生的各種情況。29
另一個獨立的問題是:如果 KYC(了解你的顧客)信息必須針對每一個賬戶 進行獨立的保存,誰來保存它呢?若要保證隱私性的話,單靠私有鏈或許無法實 現這個目標,這其中的原因已經在這章的開頭講述過了。不過,另一種密碼學技 術可以為你帶來更多的進展,這就是秘鑰共享技術。總體上說,秘鑰共享的概念 跟訪問數據所用的多重簽名技術有類似之處。一份數據可以在 N 個參與方之間進 行共享,而其中的 M 個參與方可以共同恢復該數據,不過若 M-1 個參與方就無法 看到任何有用的信息,只能看到加密后的隨機信息(M 和 N 的值可以進行任意設 置,如 2/3,6/12,9/9 等)。理論上說,開發者可以將這項技術與 ZK-SNARKs 技術結合起來,實現類似 David Chaum 的加密信息提案的金融隱私信息保護方案:總體上說要求全面保護隱私信息及實現匿名性,不過要求他們將于交易相關的細 節信息(發送者和接受者,數值等)在 N 個主鑰匙持有者之間進行秘密共享。 ZK-SNARKs 可用于確保數據是有效的,若不包含這樣的有效元數據或證據的交易 就無法被接納到區塊鏈中。
ZK-SNARKs 是一項很強大的技術,不過可能會在安全性上有一些未經證明的 問題,可能還有效率方面的擔憂:當前,在一臺普通的計算機上創建一個這樣的 密碼學證明大約需要超過 90 秒的時間。因此,對很多應用程序來說,一些隱私 保護性能稍弱但更高效的密碼學技術或許會更好用,如環簽名和加法同態加密技 術。
以太坊團隊在整合這些方案的過程中有兩個角色。首先,這些技術已經有不 少可以建造在以太坊上了;類似 Raiden 這樣的項目在以太坊上搭建 State Channels 網絡的嘗試已有數月的時間,而可鏈接的環簽名方案也已經被搭建(以 一個早期的測試版本的形式)。我們有意與密碼學專家和其他開發者一起,將上 述的一些方案整合到以太坊里面,盡量達到最大程度的可用性。其次,虛擬機的 效率已經成為了整合這些技術的主要瓶頸,這會成為本項目未來發展的一個重要 焦點。因此,在以太坊的公有鏈上若要最大程度地將這些技術整合進去并進行實 踐,其時間表與 Serenty 版本的釋出以及(可能發生的)WebAssembly 技術推進 會有緊密的關聯。當然了,私有鏈可以通過提前整合這些特性的方式獲得這些得 益,也可以通過簡單地添加一些預先編譯合約的形式去實現。
關鍵的建議
在可擴展性的問題上,區塊鏈有不少的解決方案,但隱私性的問題就不是這 樣了。我們已經作出私有鏈無法徹底解決這類問題的結論了;因為私有鏈雖然在 可校驗性上具有 33%或 50%的容錯程度,但在關于隱私性的問題上,它可能不如 一臺中心化的服務器;在中心化的方案上,你或許只能入侵一臺服務器;但在區 塊鏈上,節點非常多,若任何一臺節點的信息被泄露,都會揭示出所有的信息。
看來,私有鏈并不是一個解決隱私保護問題的合理方案,在此之外,有一些 針對特定應用場景的技術,讓你可以為特定的用例創建高度的隱私性,這些用例具體會包括數字資產轉移,身份校驗,多方智能合約以及數據存儲。這些解決方 案需要使用高級的密碼學技術,如環簽名,加法同態加密,零知識證明以及秘鑰 共享技術。隱私保護方案可以進行高度的定制,如只有在特定的情況下才能向特 定的參與方展示特定的信息(交易相關的參與方,金融機構,監管者等)。這樣 的系統若能得到深入的應用,就有可能在高度地保護用戶隱私權的同時滿足監管 者及其他信息索取方的需求。
以太坊項目的路線圖有計劃整合這些技術,并讓開發者們在以太坊上建立帶 有隱私保護特性的應用程序變得更簡單。在 State Channels 的例子中,已經有 不少項目在整合這項技術了。不過,私有鏈上的以太坊用戶可以通過自己的實踐, 根據自己的進度選擇整合上述列表中的任意技術,并以預先編譯的合約 (Precompiled Contracts)形式去實施。
純凈性
或許在討論這些技術能如何用于以太坊時,最關鍵的一點是:以太坊的主要 理念是創建一個具有高度通用性的、高度“開發者友好”特性的平臺。與 Monero 這種平臺不一樣的是,Monero 嘗試將“可鏈接的環簽名”作為底層代幣管理方 案的必須部分,而以太坊將自身看做是一個計算平臺,對在其之上搭建的應用并 沒有特定的要求。因此,以太坊并沒有計劃實現一個“匿名的代幣”,也沒有計 劃走向另一個極端——即不會在協議的層面整合一個現實世界的身份管理系統, 這一點對公有鏈、私有鏈版本的協議來說都是一樣的。
以太坊的主導理念是將技術建立在不同的層面。“第一層”是以太坊的平臺 自身,包括以太坊的虛擬機(Ethereum Virtual Machine),執行環境以及區塊 鏈共識算法。在這之上,開發者們可以將這些隱私保護方案搭建作為“第二層”。 在現在,以太坊的協議或許并不是完全“純凈”的:在協議的層面之上,包含了 具有余額和序列號的賬戶的概念,這個部分被 secp256k1 數字簽名算法保護著, 作為交易執行的“入口”。不過,我們計劃通過 Serenity EIP 101 改善方案計 劃去改變這個現狀,將這些特性剝離出來:所有交易都會被校驗——只要它們的 格式是正確的,而所有的交易看起來都會來自“入口”賬戶 0xffffffff......用戶的賬戶將會成為一種“傳遞合約”——即以太坊上的一個智能合約,可以從 入口接收到信息,并僅在該信息包含合法的密碼學簽名以及序列號時將其傳遞出 去。
這個方案的所帶來的影響,是以太坊當前帶有序列號的賬戶模式并不會再擁 有系統的特權了;相反的是,任何涉及到 UTXOs、可鏈接的環簽名(linkable ring signatures)、機密交易(confidential transactions)或者其他技術的賬戶 管理方案可以被整合到這個平臺上,感覺上就像是“原生”的賬戶管理方案一樣 ——與現時所用的賬號和序列號構成的賬戶管理方案并沒有太大的區別。雖然 EVM(以太坊虛擬機)還沒有升級到 WebAssembly 技術(或其他類似的替代技術, 如果我們最終要采用那些方案的話),但里面還是有加入一些特定的密碼學操作 指令的空間,這樣就可以避免虛擬機的整體資源耗費,并以合理的效率去處理這 些指令,但這些操作指令還是被高度封裝過的,我們的最終目標是讓所有的功能 都在 WebAssembly 的代碼里面執行。到那個時候,以太坊的私有鏈或公有鏈的實 踐案例或許會帶有一套復雜的第二層工具,讓用戶可以創建由密碼學保護的賬號, 管理他們的身份,選擇性的向特定的參與方展示或證明自己身份相關的信息,或 執行其他類似的操作。這樣,平臺的底層結構就會得到極大地簡化,效率也會上 一個臺階,而且開發者們依然會擁有高度的自主權,這樣他們就能在平臺的底層 之上搭建滿足不同產業和應用要求的工具。
結論
以太坊提供了一個具備高度通用性的平臺,讓用戶可以為各種類型的用例創 建應用程序,從而省去了自己搭建區塊鏈所用的時間和耗費。這個平臺的愿景是 要搭建一個“世界計算機”:它要創建一個系統,對用戶來說,這個系統看起來 就像是一臺計算機一樣,同時擁有了區塊鏈技術所帶來的安全性、可審計性和去 中心化的好處。這個項目的路線圖還包括了一些將來的計劃,旨在解決一些區塊 鏈技術存在的問題,如可擴展性、隱私保護等,從而為多種應用場景提供極致的 友好體驗,并最大程度上保留和完善當前的“對開發者友好的用戶體驗”。
在一些場景里面,以太坊或許是不適用的,這些場景包括:(i)在一些能 通過搭建專用平臺而受益的場景中,在這些場景里,搭建專用的平臺能夠針對某 些特殊的目標進行優化,其提升的可擴展性及效率明顯超過了進行專門定制化操 作所需的額外成本,或(ii)區塊鏈完全不適用的場所。在以下場景中,以太坊 是有意義的:(i)在需要一個具有長期、高度可審計性需求的平臺中,以及在 需要快速加入新功能的平臺中——甚至在沒有區塊鏈節點運作者的協作時也能 增加新的功能,(ii)在需要創建一個大型的應用程序協作生態時,或(iii) 在用戶需要使用自動化執行、可編程的“智能合約”的場景中。
至于在以太坊的公有鏈、私有鏈還是聯盟鏈的選擇中,最終是取決于開發者 和應用場景的需求。目前,那些沒有得到機構支持的開發者大部分選擇了公有鏈, 因為它的準入門檻很低,而且不需要請求別人去采用他們的應用程序。那些早就 有幾百萬用戶的金融機構并沒有這方面的憂慮,因此這些機構應該將這些選項都 考慮進來。在短期內的“安全”的策略就是先嘗試一下具備 5-25 個節點(每個 機構運營一個或多個)的聯盟鏈,這是因為——(i)聯盟鏈在短期內具有可擴展 性的優勢,(ii)一個“受控”的系統所帶來的低風險性有利于說服法律部門和監 管者,而且(iii)他們也能在公有鏈前使用上如 EIP101 和 105(這兩個都是以 太坊改善提議的編號)的特性;在長期來說,私有鏈、聯盟鏈和公有鏈的選擇會 取決于特定的應用場景,特別是要考慮在性能和互操作性能之間的取舍。
對那些重視隱私性的用戶來說,私有鏈并不是一種靈丹妙藥;在協議的層面 上,任何多節點的區塊鏈的隱私性都可能不如一個單服務器的解決方案。因此, 我們應該進一步探索 State Channels 狀態通道,ZK-SNARKs 零知識證明,環簽 名等密碼學方案,因為它們能夠使用區塊鏈去存儲金融數據并進行相關的計算, 同時保留為用戶提供高度的(但并不是絕對性的)隱私保護。以太坊的路線圖已 經有相關的計劃,力求為這類隱私保護技術提供最友好的支持,將其整合到以太 坊的協議之上。
英文版pdf下載地址：Ethereum-Platform-Review-Opportunities-and-Challenges-for-Private-and-Consortium-Blockchains.pdf
中文版pdf下載地址：以太坊平臺評估 私有鏈和聯盟鏈的機會與挑戰.pdf
視頻地址：以太坊平臺評估 私有鏈和聯盟鏈的機會與挑戰
總結
以上是生活随笔為你收集整理的以太坊《私有链和联盟链的机会与挑战》报告的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Lending Club贷款数据分析
- 下一篇： JES-java emil server