# Fund in the Shell: a transplant approach to upgradable Enzyme portfolios
###### tags: `enzyme medium 閱讀筆記`
## 基礎介紹
Enzyme 基金現在可以通過允許經理選擇加入最新版本的流程進行完全升級，同時為投資者提供選擇退出的窗口。技術方法是將基金的“靈魂”（所有權、資產持有量和股份）移植到新的外殼（發行配置）中。
自 2019 年底以來，Avantgarde Finance 的核心開發團隊一直在開發Enzyme協議的第二個主要版本
2020 年年中，團隊正在推動自 2019 年第一季度 Melon 最初推出以來的第一個主要版本的第三季度發布。該協議有望實現重大改進，例如單一交易基金設置、貸款集成、全面節省氣體，以及抽象和可擴展的費用、政策和 DeFi 適配器。然而，隨著目標日期的臨近，團隊一直受到用戶體驗問題的困擾：資金無法升級。

## 不可升級的資金是用戶體驗的噩夢
一般來說，當Enzyme協議有新版本發佈時，基金經理可能希望轉移到該版本以利用新功能、改進和持續維護的基礎設施（例如，價格反饋和官方 Avantgarde Finance UI） .
以前，這樣的基金經理需要在新版本上創建一個新基金，然後以某種方式與他們的投資者溝通，從舊基金中贖回股票並投資於新基金。這會造成用戶體驗的噩夢

### 以允許用戶代理的方式升級酶資金非常複雜
由於三個因素，為 Enzyme 找到合適的可升級範式非常複雜：
- 代碼庫的複雜性
- 合同耦合
- 希望允許用戶有選擇地升級

Enzyme Protocol 擁有龐大的合約領域（目前已部署 32 個合約），其中包括會計和參與的核心邏輯、處理費用、政策和 DeFi 操作的擴展功能，以及定價和轉換資產價值的基礎設施。
此外，這些合約是緊密耦合的；該協議是硬編碼的，包含有關特定費用、特定價格饋送、特定類型的擴展功能等的知識。（這個發布週期的一個重點是解耦和抽像這些合約）。
獨立地，這些因素都不一定會導致難以升級的範式。例如，如果代碼複雜性（甚至緊密耦合）是唯一的問題，Enzyme委員會仍然可以升級整個協議並強制所有用戶使用所有合約的相同版本。事實上，這是升級 DeFi 協議的普遍接受的範式。
> 但是，讓用戶代理機構決定是否接受任何提議的升級非常重要。

從“code is law”的角度來看，當用戶決定開始使用協議時，他們同意該協議的運行規則。雖然可以說同意代理合同的規則構成這樣的協議，但這給了治理結構全權委託。此外，如果資產託管、股票購買或贖回、資產估值等方式發生變化，某些投資組合經理可能會產生實際或法律後果。
由於我們需要考慮兩個用戶組：投資組合經理（投資產品）和投資者（這些投資產品），這種對可選升級的渴望變得更加困難。
這三個因素的融合使傳統的升級方法令人生畏和危險。多個用戶組將需要參與升級在不同發布週期中創建的不同類型的合約，從而產生無限的版本構造，這些版本需要以某種方式進行測試，以保證每個構造中所有合約的交叉兼容性。

### 尋找Enzyme基金的“靈魂”
酶基金的“靈魂”、本質是什麼？從最重要到最不重要的大致順序：
- 資產持有量
- 分享
- 所有權和訪問權
- 授權（基金可以做什麼和不允許做什麼）
- 費用
- 會計和估值邏輯
- 策略
- 其他配置

我們還需要考慮這些組件中的哪些足夠抽象，以免我們為Enzyme協議的未來版本束縛於特定的架構結構。例如，持久化策略（授權）和費用將要求每個後續版本不僅對策略和費用是什麼有相同的理解，而且還要保持存儲中每個實例所代表內容的一致性（例如，使用 PerformanceFee 和特定設置）。
最終，我們決定基金的靈魂是它的資產持有量和股份，以及基本的訪問控制結構。

### 通過移植遷移升級資金
在傳統的數據庫驅動系統中，“遷移”通常是指使用模式之間的映射來讀取遺留數據庫並寫入後續數據庫。
正如人們經常指出的那樣，區塊鏈不是數據庫（也不應該被用作數據庫），實際上每次升級時將整個存儲佈局複製和寫入新合約會很麻煩且成本高昂。
移植整個合約是一種更實用的方法。

簡圖概念化Enzyme協議中不同的壽命、依賴性和控制途徑

上圖是基於migration的可升級過程確定的架構模式。該圖並且不是 100% 準確的，但它可以說明以下幾個關鍵點。請注意，例如，組框的顏色代表不同類別的生命週期：紫色框代表在所有版本中繼續存在的永久合約，藍色框代表可以在版本之間回收的架構，綠色框代表發布- 特定的架構。

#### VaultProxy 和 VaultLib
我們決定通過為每個基金部署一個代理合約來實現常用的代理升級模式（遵循 EIP-1822 和 EIP-1967），該VaultProxy代理合約指向VaultLib特定於當前版本的共享邏輯合約。然後VaultProxy通過將其指向VaultLib下一個版本來升級它。
跨版本持續存在，因此VaultProxy提供了一個規範的基金地址來存放資產。同時，這個靈魂的剩餘元素的基本存儲佈局（所有權和股份的 ERC20 佈局）在VaultLibBaseCore作為每個基礎的合同中定義VaultLib。後續版本可以通過擴展先前版本的基礎來添加到此核心存儲佈局。例如，第一個版本添加了用於跟踪基金持有的資產的存儲模式和事件。

#### Dispatcher
有一個不可升級的合同Dispatcher，稱為 位於所有版本之上。它的主要職責是部署新VaultProxy實例，了解每個VaultProxy實例當前處於哪個版本，並促進VaultProxy實例遷移到當前版本。
Dispatcher表面上是將實例移植到新版本的外科醫生，VaultProxy並且只接受來自最新版本的命令。就這個總體基礎架構而言，Enzyme委員會只需要Dispatcher與當前版本保持同步即可。

移植本身非常簡單：Dispatcher只需更新以下兩個存儲變量VaultProxy：
- 下一個VaultLib
- 下一個accessor（對允許更改VaultProxy狀態的帳戶的抽象引用）
版本之間的這種抽象切換允許版本架構幾乎無限地發展，Dispatcher與版本的操作方式完全無關。

新版本唯一必要的架構組件是一個廣泛定義的頂級合約，用於與 `Dispatcher` 和新的 `VaultLib` 交互

為了授權用戶代理是否升級到最新版本，Dispatcher遵循信號執行路徑：
經理表示他們將升級到最新版本
經理必須等待時間鎖到期（目前為 48 小時）
經理執行升級，完成移動
這條途徑為管理者和投資者提供了升級的機構。基金經理通過主動發出信號並執行升級來選擇加入，並且投資者有一個可以選擇退出的窗口。