StarkEx 不只是一種可擴展性引擎,也可以作爲自主託管型方案。

原文標題:《引介 | StarkEx 作爲自主託管型方案》
撰文:Tom Brand 與 Uri Kolodny
翻譯:阿劍

StarkEx 是一種可擴展性引擎,同時支持用戶自主託管資金;這纔剛剛登陸以太坊主網。StarkEx 實現了 STARK 證明系統的零知識(Zero-Knowledge Proof,ZKP)版本。實現自主託管功能的道路崎嶇難行:託管方案會更簡單、更便宜,而且(最重要的是)更容易理解 —— 大家已經習慣託管型的軟件系統很多年了。

「自主託管系統」,或者叫 「非託管型系統」,其實運用得相當廣泛。只要是用戶能預設自己可以(一鍵)完全控制自己資金的系統,都可以這麼稱呼:免許可型區塊鏈一開始就是被當成託管型系統的替代方案而提出的,想到這一點,你會覺得現狀很魔幻。我們知道建立一個完全自主託管的系統的難度,也知道在這個圈子裏搞創新有很多維度。我們還覺得,隨着時間推移,大家會發現遷移到一個更加自主託管的系統中總是有用的。本文會詳細說明我們做出的選擇,以及我們爲 StarkEx (在這個維度上)設定的方向。

首先,有必要定義一下 「自主託管(self-custodial)」是什麼意思。在我們看來,僅當一個系統滿足下列屬性時,它才能被叫做 「自主託管型系統」:

  1. 沒有用戶的明確簽名,資金就不能轉移;
  2. 在簽名的時候,用戶可(通過錢包的用戶體驗設計)獲得所有的信息;
  3. 資金隨時可退出;
  4. 代碼升級機制即使被濫用也不能破壞上述機制。

本文將致力於解釋:(1)爲什麼說證明系統最適合於支持自主託管型方案;(2) StarkEx 智能合約的審計狀況;(3)我們所用的智能合約升級機制;(4)錢包支持 (STARK 簽名方案及整合方法);(5)數據可用性(從我們第一個版本所用的數據可用性委員會方案,到完全免信任的鏈下數據可用性方案)。

自主託管性作爲一個神聖的理想,可追溯到區塊鏈最初的願景,一句話:「沒拿着私鑰的,就不算你的幣(not your keys, not your coins)」。早些時候,因爲 Layer-1 的吞吐量侷限,自主託管這個理想往往讓位於可擴展性(以及流動性)。這種讓步的結果就是中心化的交易所:交易所託管着交易者的密碼學資產,交易者得到的好處是流動性(還有相當大的對手方風險)。但今天,ZKP 系統背後的科學和工程技術都變得更成熟了,尤其是 STARK,我們已經完全迎來了奇點 —— 再也沒必要去作這種讓步了。

ZKP 系統的歷史既美麗又複雜。重點是,ZKP 系統能以免信任的模式,爲公鏈提供可擴展性和隱私性。而自主託管型解決方案恰好需要免信任的基礎設施。換句話說,如果需要信任某個實體,即使沒讓 「自主託管」 變成一句空話,也會大大削弱其意義。

ZKP 系統有兩個部分:提供 「計算完整性(CI)」 的基礎層,以及在此之上保證零知識的概率層。要實現可擴展性的時候,我們實際上只需要 CI 層。CI 層可幫助參與協議的一方(即證明者)爲任意計算(或者說狀態轉換)在鏈下生成一個證明,而任意數量的另一方(驗證者)可在鏈上以非常小的計算開銷驗證這個證明。

理論上來說,信任假設當然是越少越好。具體而言,對 STARK 來說:

  • 不需要對驗證者作任何信任假設,既不需要實時的信任關係,也不需要預處理的信任關係,因爲 STARK 不需要受信任的初始化設置(trusted setup)。說得極端一些,即使由一個惡意團體使用惡意的硬件來充當證明者,計算不同則證據一定不同,錯誤的計算所生成的證明無法通過檢驗。
  • 驗證者在鏈上運行,需要保證資源是足夠的。

StarkEx 是一種爲交易所設計的可擴展性引擎,但 STARK 也可以用於爲其它應用提供可擴展性。使用的時候,應用的部分邏輯要在鏈下實現,而需要與鏈上實體(智能合約、賬戶,等等)交互的邏輯則要作爲應用智能合約(ASC)在鏈上實現。

StarkEx 的一個用戶是我們的合作伙伴,DeversiFi,一個自主託管型交易所。DeversiFi 會使用 StarkEx 來擴展交易操作(包括交易也包括轉賬)的吞吐量。ASC 保證了沒有用戶的簽名資金就無法轉移(簽名是通過對 STARK 證據的驗證來驗明的)。StarkEx 要求用戶存儲資金到 ASC 中,這就使該 ASC 容易成爲黑客的目標。這份 ASC 代碼已經經過審計和高強度的測試,以保證其正確性和安全性。此外,我們還計劃繼續使用其它工具,比如形式化驗證,來保證代碼的正確性和安全性。

審計並不能保證一個系統是安全的,因爲合約的掌控賬戶(admin)可以給合約做一系列升級,讓自主託管變成一個空架子。智能合約的升級(或者換句話說叫遷移)讓開發者可以修復 bug 並擴展功能。下一篇博客,我們就要講講我們是如何設計智能合約升級機制,來保證 StarkEx 能永遠保證其自主託管性。

對了,還要提醒一句:大家一般用來形容 「自主託管型方案」 的形容詞是 「非託管型(non-suctodial)」,我們不喜歡這個詞,因爲它是否定形式的,似乎暗示了託管型系統(比如中心化交易所)纔是基準,纔是值得借鑑的。但託管型解決方案是與公鏈的精神相悖的。強制託管方回到自己原有的角色,是比特幣和以太坊的精神所在,這就是爲什麼我們更喜歡 「自主託管」 這個詞。

合約可升級

動因

我們已經介紹過了自主託管式系統的各個方面,其中可升級性也是一個方面。下面介紹我們爲 StarkEx 構建的可升級性機制,這是確保 StarkEx 維持自主託管性的關鍵。

需要升級智能合約代碼的情況有兩種:增加新功能和修復安全性漏洞。難點在於如何在不損害系統自託管性的前提下引入升級。如果 StarkEx 邏輯被惡意更換,應用運營者就有可能掌控所有用戶資產。StarkEx 通過一個新型可升級性機制來保護用戶資產。簡單來說,這個機制利用了時間鎖和三類臨時性智能合約(詳見下文)。

StarkEx 應用合約簡介

引介 | StarkEx 作爲自主託管型方案,Part-2:合約可升級性

引介 | StarkEx 作爲自主託管型方案,Part-2:合約可升級性

StarkEx 應用智能合約(ASC)採用了代理模式(由 openZepplin 率先引入),因此包含多個子組件。代理合約內存儲着所有數據和資金,並(通過一個指針)指向一個定義了功能的地址(也就是邏輯合約 Logic Contract)。通過代理合約,我們在代理合約環境內運行委託調用(delegate call)來調用邏輯合約。因此,StarkEx ASC 邏輯是由邏輯合約定義的;整個系統通過部署新的合約和更新代理合約中的指針來升級(邏輯)。驗證者(Verifier)合約和數據可用性委員會(Data Availability Committee,DAC)合約的地址均由邏輯合約而非代理合約引用(如果你想要複習關於 StarkEx 組件的簡介,請點擊此處)。

升級機制和保護自主託管

在第一階段,我們爲邏輯合約、驗證者合約和數據可用性委員會合約都單獨設置了升級機制。所有升級操作都只能由經過許可的地址執行。

邏輯合約升級

  • 升級:各個邏輯合約版本的地址均存儲在代理合約內。新版本在激活之前,先要鎖定一段時間,即,我們所說的升級激活延遲:upgrade_activation_delay (設爲 28 日)。upgrade_activation_delay 比 StarkEx Escape Hatch (逃生艙口)的寬限期長得多。在特定時間點,所有版本中只有一個是激活的,不過授權管理員可以在未鎖定的版本之間即時切換。
  • 自主託管:在新版本解鎖之前,系統預留了足夠長的時間讓用戶進行審查。如果有用戶認爲新版本不可接受,可以選擇退出 StarkEx ,並向其他用戶發出示警。由於 upgrade_activation_delay 比寬限期久得多,用戶有充足的時間取出資金。

另外兩個合約均提供驗證服務:一個被用來驗證 STARK 證明(驗證者合約),另一個被用來驗證數據可用性(DAC 合約)。這兩個合約本質上是相似的,因此均由邏輯合約執行,並且採用相同的方式升級。

驗證者合約升級

  • 機制:邏輯合約內保存了驗證者合約的列表。只有在被所有驗證者接受的情況下,一個證明纔會被視爲有效。新的驗證者可以立即添加到合約內。但是,在 upgrade_activation_delay 期間,刪除驗證者需要等待一段時間。
  • 自主託管:驗證者的任務是接受有效證明,拒絕無效證明。出於安全性考慮,添加驗證者的操作是即時的(無延遲)—— 請注意,是即時添加而非替換。由於證明必須被所有驗證者接受(才能被視爲有效),即時添加驗證者只會變得更安全而不是更不安全,因爲無效證明還是不能被接受。時間鎖可以保證已經部署的驗證者不會被立即刪除,讓社區有充足的時間審查新添加的合約。

DAC 合約升級:與驗證者合約在模式和原理上都相同

爲了更好地理解這些驗證合約的累積性,請把它們想象成篩子:驗證者合約就像是網眼很密的篩子,僅允許有效語句通過。StarkEx 沒有使用新篩子替換舊篩子,而是要求語句既要通過之前的篩子,又要通過新部署的篩子。新的篩子不會讓無效的語句通過驗證,只能 進一步限制 被視爲有效的語句集合。大多數比特幣協議升級(軟分叉)也是如此:一旦軟分叉執行,之前被視爲無效的區塊依然是無效的,之前有效的區塊也可能會變成無效的。

安全性風險及其解決方案

正如我們在上文所述,升級智能合約的主要原因之一是檢測出了安全性風險。安全性風險可以分爲以下三類:

資金被鎖定

  • 風險:用戶存入智能合約的資金可能會因爲漏洞而鎖定(例如,Parity 多重簽名合約漏洞)。
  • 解決方案:添加一個新的邏輯合約版本來修復該漏洞。

資金被盜

  • 風險:惡意用戶可能會利用合約中的漏洞來濫用 API ,盜走合約中的資金。StarkEx 應用運營者需要具備及時修復這類漏洞的能力,因爲拖得越久損失越大。
  • 解決方案:一超過時間鎖限定的期限,就能立即切換到另一個邏輯合約版本。具體來說,系統中會有一個預先加載好且僅允許取款的極簡版本。極簡版本可以有效地關閉所有合約功能,僅允許用戶取款。

驗證者可靠性漏洞

這類漏洞可能會導致資金被鎖定和被盜的情況,值得單獨拿出來討論,因爲 StarkEx 是基於零知識證明的系統。

  • 風險:這類漏洞會導致驗證者合約接受無效狀態轉換的證明,進而導致用戶餘額被篡改,尤其會導致資金被盜。
  • 解決方案:立即(不設時間鎖)添加一個新的驗證者合約即可解決可靠性漏洞,因爲每一次狀態轉換必須被所有已部署的驗證者接受:通過部署新的驗證者合約來拒絕無效轉換,就足以讓系統將無效狀態轉換拒之門外了。

錢包支持

上面介紹過了自主託管式系統的各個方面,其中就包括錢包。下面將要介紹我們是如何與不同的錢包提供商合作,來確保 StarkEx 保持自主託管型系統的本色。

自主託管型系統的一大重要特徵是,每次交互都需要用戶簽名。我們的首要原則是 「不只要簽名,還要驗證它。」—— 這是套用的區塊鏈行業的老話:「不要相信它,去驗證它。」 換言之,要是用戶不能驗證,自主託管型系統只是徒有其名而已。用戶要能夠驗證他們的錢包和自主託管型應用之間所進行的交互的參數。例如,如果一名用戶向鏈上合約提供了簽名,ta 的錢包顯示的應該是經過良好解析的可讀消息,而非一團高深莫測的數據。在用戶需要簽署鏈下交易的時候,二層應用也應遵循同樣的原則。

爲了恪守 「不只要簽名,還要驗證它」 這一原則,我們正在與多個錢包提供商合作,將我們的協議直接整合進他們的產品內。這一整合對零知識證明系統來說尤爲重要。爲了高效地驗證簽名,零知識證明二層系統所使用的曲線通常不同於標準的以太坊曲線,使用的哈希函數也不同。一種簡單的方法是在瀏覽器中實現錢包。我們傾向於不這麼做,主要有兩點原因:首先,StarkEx 的目標是讓用戶可以直接通過錢包在專業的交易平臺中交易,無需再將資金轉移到其他地方;第二,構建一個安全的錢包並非易事(路印最近被曝出的高危前端漏洞就是一個很好的例子)。

下文列出了截至 2020 年 5 月支持 StarkEx 的錢包。

Ledger :完全整合

Ledger 是完全整合 StarkEx 的。無論是鏈上合約調用還是鏈下訂單提交,每一次交互都將由 Ledger 解析,然後向用戶顯示。用戶要先確認過後才能在 Ledger 中籤名。用戶將能驗證每一次交互的參數。此外,Ledger 將在其原生以太坊應用中支持 StarkEx (用戶甚至不需要通過 Ledger Live 安裝特定的應用)。

爲了整合 StarkEx ,我們必須將 STARK 專用曲線添加到 Ledger 的固件中 ,並在 Ledger 的應用中執行 StarkWare 的哈希函數(Pedersen 哈希函數)。通過 StarkWare 和 Ledger 的緊密結合,Ledger 成了首個應用於二層的硬件錢包。

WalletConnect:完全整合

WalletConnect 是完全整合 StarkEx 的。WalletConnect 是一個開放式協議,(通過二維碼)將桌面應用連接到使用端到端加密技術的移動錢包。我們與 Pedro Gomes 一起實現了 StarkEx 交互,創建了 StarkEx WalletConnect Provider 。DeversiFi 是首個構建在 StarkEx 上的自主託管型交易所,也將 WalletConnect 整合進了它的應用中。移動錢包 Argent 目前正在整合 StarkEx WalletConnect Provider ,很快就會支持用戶在 DeversiFi 上進行自主託管型交易。

MetaMask:混合解決方案

目前,我們爲 MetaMask 用戶提供混合解決方案。所有鏈上交易都將由 MetaMask 處理,所有鏈下交易都將由瀏覽器內置錢包(第一種就是 DeversiFi 的錢包)處理。這一解決方案與如今絕大多數二層方案相同,而且可以讓我們立即支持 MetaMask 龐大的基礎用戶。這一方案目前還做不到上面幾個方案那樣完美:用戶既不能驗證鏈上合約調用,也不能驗證他們的鏈下交易。一旦 MetaMask 部署好 Snaps 插件系統,這一問題就能得到解決。我們將繼續作爲 Snaps 上的 Design Partner (設計夥伴)與 MetaMask 團隊密切協作(參見我們在 Devcon 5 上的聯合演示),讓 StarkEx 像我們所描述的最優方法那樣爲 MetaMask 用戶提供服務。

鏈下數據可用性

動因

StarkEx 是一種自主託管式可擴展性引擎。這已經是我們的《StarkEx 作爲自主託管型方案》系列的第四篇也是最後一篇文章了。本文將要介紹 StarkEx 這個自主託管型系統的最後一部分內容:數據可用性方案的部署以及它將如何引領我們走向更加免信任的未來。

我們先來回顧一下知識點。在 StarkEx 中,交易是批量處理的,然後在鏈下驗證,並生成一個 STARK 證明。我們將這一過程稱爲有效狀態轉換。這個證明會和系統新狀態的承諾一起被髮送到區塊鏈上,然後由區塊鏈驗證證明並存儲承諾。批量交易的數據存儲在鏈下或鏈上皆可。如果選擇鏈上數據可用性,交易就會被記錄成調用數據(calldata)。如果選擇鏈下數據可用性,交易就會被記錄在鏈下。鏈下數據可用性更具可擴展性:無論 StarkEx 上有多少活動,消耗的區塊鏈資源都是固定的。

首個部署完成的 StarkEx —— 用於支持 DeversiFi 去中心化交易所 —— 將選擇鏈下數據可用性。DeversiFi 之所以做出這樣的選擇,一方面是因爲可擴展性優勢,另一方面是因爲這會爲其用戶提供更好的隱私性,可以幫助用戶隱藏其交易策略。因此,想要訪問自己賬戶餘額的用戶可以從 StarkEx 運營者處獲得:應用運營者(Application Operator)和證明運營者(Proof Operator)(在首個部署完成的 StarkEx 項目中,這兩個角色分別由 DeversiFi 和 StarkWare 擔任)。要驗證自己的賬戶在某個時刻的狀態時,用戶可以根據自己賬戶在相關默克爾樹上的默克爾路徑完成驗證。關於用戶對運營者的信任,需要注意的一點是:用戶不需要基於對運營者的信任來相信系統狀態是有效的,因爲狀態轉換的有效性是由 STARK 證據來保證的。用戶只需相信運營者會實現數據可用性即可。

數據有效性委員會(DAC)

爲了讓用戶完全不需要信任 StarkEx 運營者,我們已經組建了數據有效性委員會(DAC)。DAC 成員的職責是保存鏈下數據的副本,並在緊急情況下將這些副本放回公共域。緊急情況指的是 StarkEx 運營者不響應用戶提款要求的情況。在緊急情況下,應用智能合約(ASC)將不再接受新的狀態更新,而是隻允許能夠提供最新狀態的默克爾證明的用戶直接取款。

DAC 成員的職責

在正常情況下

  • 接收每一次狀態轉換,計算新的狀態,簽署新狀態的承諾
  • 爲鏈下數據保存私密且安全的副本

只有當簽署對應的狀態承諾的 DAC 成員達到一定數量之後,ASC 纔會接受 STARK 證明。

在緊急情況下

將它們保存的數據副本公開。在這種情況下,用戶可以訪問通往他們賬戶的默克爾證明,使用這條證明直接從 ASC 那裏取回他們的資金,完全不需要信任運營者。

通往未來之路

我們認爲,將對 DAC 的信任最小化是非常重要的。

首先,我們打算將 DAC 存儲的數據加密,以此確保 DAC 成員不再掌握任何有關 StarkEx 用戶的數據。加密可以確保委員會成員不會透露敏感信息,從而減少他們的責任,也可以免去用戶對他們的信任。因此,加密可以讓 StarkWare 大幅增加委員會的人數,從而減少在緊急情況下對個體成員履行職責的依賴。

之後,我們將實現一個完全免信任的方案,可以讓相關方完全不需要信任 DAC 。這個方案需要投入非常有限的資源:或者將他們的數據放到鏈上,或者監控鏈下數據的進程(需要投入的資源遠少於運營者)。我們將會發布新的文章來詳細闡述這些概念。

來源鏈接:medium.com