引介| StarkEx 作為自主託管型方案，Part-1：引言

動因

StarkEx 是一種自主託管式可擴展性引擎。我們已經介紹過了自主託管式系統的各個方面，其中可升級性也是一個方面。本文將要介紹我們為StarkEx 構建的可升級性機制，這是確保StarkEx 維持自主託管性的關鍵。

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

StarkEx 應用合約簡介

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

升級機制和保護自主託管

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

1.邏輯合約升級：

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

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

2.驗證者合約升級：

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

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

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

安全性風險及其解決方案

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

1.資金被鎖定：

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

2.資金被盜：

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

3.驗證者可靠性漏洞：

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

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

（文內有許多超鏈接，可點擊左下”閱讀原文“ 從EthFans 網站上獲取）

原文鏈接:

https://medium.com/starkware/contract-upgradability-d3a4451877c

作者: StarkWare

翻譯&校對:

閔敏 &阿劍