什麼是 ERC-4626 代幣標準？

雖然目前已有幾個主流的代幣標準，去中心化金融（DeFi）領域在代幣化金庫（tokenized vaults）方面仍存在一個反覆出現的重大問題。這正是最新標準 ERC-4626 誕生的原因。

本文將說明什麼是金庫（vault）、開發者在將其代幣化時面臨的問題，以及 ERC-4626 如何解決 DeFi 開發中的這項問題。接著我們會深入探討這個新標準帶來的變化，並示範如何在你的智能合約中實作。

什麼是金庫（vault）？

金庫是一種多簽方案或智能合約，可用來儲存與管理加密貨幣等資產。每個金庫都會有其產生的代幣，作為一種收益形式。這些產生出來的代幣之後可以兌換回原本鎖在金庫中的代幣。

舉例來說，當你在自動做市商（AMM）Sushiswap 上質押 Sushi 時，你會獲得 xSushi 作為獎勵。同樣地，當你在 DeFi 借貸協議 Compound 上為 USDC 穩定幣進行流動性挖礦時，你也會獲得 cUSDC。

cUSDC 和 xSushi 都是生息代幣（yield-bearing tokens），可以兌換回原本的代幣（在此例中即 USDC 或 SUSHI）。只要金庫或資金池中鎖定的代幣持續增加，生息代幣的價值就會持續增加。

金庫被認為比錢包更好、更安全，這也是許多 DeFi 協議選擇將資金存入金庫的原因。使用金庫的知名 DeFi 協議包括 Sushiswap、Aave、Balancer 和 Compound 等。

代幣化金庫存在什麼問題？

開發者在處理生息代幣時面臨的問題，在於如何整合不同協議的代幣。

舉例來說，若你想開發一個 DeFi 應用，需要整合每個協議的代幣，你就得逐一研究每種代幣、了解其收益累積的模型，並將其調整納入你的程式碼庫。

如果你想整合 Maker DAO 的 vDAI、Curve 上的 stETH 等等，你就需要理解它們各自智能合約的特殊之處，並建立客製化方案，才能成功將每一種代幣整合進你的 DeFi 應用中。

除了整合不同生息代幣的過程可能既耗費心力又耗時之外，這也因為潛在錯誤而增加了智能合約的風險。

開發者需要花更多時間檢查轉接器（adapter）中潛在的漏洞，在某些情況下，甚至可能需要外包給智能合約審計人員，而這可能相當昂貴。在攻擊者不斷破壞許多協議與 DeFi 應用完整性的當下，這一點變得更加重要。

ERC-4626 標準是由誰制定的？

2021 年底，Fei Protocol 的創辦人 Joey Santoro 注意到開發者整合各自獨立的生息代幣有多麼困難，於是他帶領另外四位 Ethereum 開發者組成的團隊，提交了 Ethereum Comment Proposal 4626（ERC-4626）。

經過多輪審查與討論後，Ethereum 終於在 2022 年 5 月批准了這個標準。

ERC-4626 對金庫帶來哪些好處？

ERC-4626 的主要好處在於，它將代幣化金庫標準化，使協議整合變得更容易、更不容易出錯。

由於現在有一個可以整合的共通標準，開發者不再需要為每個協議個別建立轉接器。簡而言之，這加快了開發速度；可組合性（composability）達到了極致。

同樣地，這也降低了成本，因為開發者不再需要請審計人員協助檢查轉接器與介面。最重要的是，ERC-4626 提升了處理生息代幣的應用與收益聚合器（yield aggregator）之間的安全性。

ERC-4626 標準帶來哪些變化？

有了新的 ERC-4626 代幣標準，開發者現在有了一套標準，可用來開發涉及生息代幣的 DeFi 應用。

簡而言之，ERC-4626 標準實作了以下特性：

• 為想要整合它的開發者提供最佳化的金庫介面
• 以份額（shares）作為存款的兌換憑證，份額代表對金庫底層代幣的部分所有權
• 為開發生息合約的開發者提供一致的標準
• 經過實戰考驗的金庫代幣安全性

ERC-4626 如何運作：函式與事件

ERC-4626 是 ERC-20 標準的擴充，並與其相容。因此，大多數適用於 ERC-20 代幣合約中常見的變數、事件與函式，在 ERC-4626 金庫標準中仍然適用。

該金庫標準引入了「份額（shares）」的概念，作為從整個資金池中取得部分所有權的方式。這些「份額」指的就是生息代幣。

現在讓我們開始用 ERC-4626 進行開發。

雖然你也可以使用 Cairo、Viper 等語言，但我們會用 Solidity 來撰寫這個合約。

1. 將 OpenZepellin 擴充套件匯入你的 IDE

打開你的 IDE 之後——我們建議使用 Remix——先告訴編譯器你要用哪個版本的 Solidity 撰寫合約。

在此我們宣告使用 0.8 版本。接著，你需要匯入 ERC-20 和 ERC-4626 這兩個 OpenZeppelin 擴充套件。

接下來，讓我們建立一個合約並為它命名。

2. 建立你的合約

為你的合約命名，並進一步明確表示它同時基於 ERC-20 代幣與 ERC-4626。

Contract, testingVaults is ERC20, IERC4626 { your entire code here}

3. 實作標準

建立合約後，關於這個標準中的方法、函式與事件，有一些重要的變化你應該了解。因此，讓我們來檢視 ERC-4626 中的一些方法與事件：

Deposit（存款）

當使用者將任何資金存入金庫時，deposit 函式會觸發智能合約，鑄造相對應數量的份額給存款人。作為一個事件，每當有存款發生時，智能合約都必須觸發此事件。

透過這個函式，我們指示合約將一些代幣存入金庫，並將份額的所有權交給呼叫者。你可以用同樣的方式撰寫提款函式。

Withdrawal（提款）

withdrawal 函式協助擁有者銷毀份額以換取資產。當有資金從金庫提出時，必須觸發 withdrawal 事件。

此事件中的 address indexed _from 代表核准將代幣存入金庫的使用者，而能夠提出已存入代幣的人則是 address indexed _to。

Asset 與 totalAsset

金庫代幣的地址應在 asset 函式中使用。智能合約中底層資產的總數量則應宣告在 totalAssets 之下。

convertToShares 與 convertToAssets

在 ERC-4626 標準下，有兩個轉換函式：convertToShares 與 convertToAssets。

當你需要將資產轉換為份額時，convertToShares 是應該呼叫的正確函式，因為它會回傳可釋出的份額數量，而非資產數量。

反之，convertToAssets 則是反向運作，將份額轉換為資產。

Mint（鑄造）

當有存款發生時，會為接收者呼叫 mint 函式。maxMint 是金庫中可為使用者或接收者鑄造的份額總量。身為開發者，你應該自行設定這個值。

Redeem（贖回）

redeem 函式會從擁有者——msg.sender——銷毀部分份額，並將資產發送給接收者。如果因某些原因無法贖回這些份額，就必須回退（revert）redeem。

maxRedeem 是金庫中擁有者可贖回的份額數量。

Preview（預覽）

在使用 preview 系列方法時，開發者必須留意，這些方法回傳的數值不會完全精確，但會相當接近。你不應將它們當作預言機（oracle）來依賴。

你可以搭配 mint、withdraw、redeem 和 deposit 等其他方法一起使用 preview。

就是這樣。你已經成功踏上 ERC-4626 的開發之旅！

總結——ERC-4626 的未來

隨著 ERC-4626 的出現，DeFi 領域正迎來一股新的浪潮。

由於過去沒有標準，DeFi 聚合器一直覺得整合多種生息代幣相當費力。但現在，ERC-4626 讓透過一次 API 呼叫就能取得生息代幣的詳細資訊成為可能。

透過這套經過實戰考驗的標準，開發者需要額外費心提升含生息代幣的 DeFi 應用安全性的問題，在很大程度上已獲得解決。

在接下來幾年，各種 DeFi 協議之間的可組合性與互通性將會持續提升。這個標準甚至有可能成為在 DeFi 生態系中打造並推出全新產品的基石。