前言

最近一個叫做 GAS2ETH 的 EIP， 由於有可能收入明年的以太坊升級（Glamsterdam 硬分叉），在 X 上引發許多討論。它是一個相對簡潔的 EIP 提案，卻有改變以太坊網路層、應用層、乃至各種公共財專案的潛能。這篇文章希望可以簡明扼要地介紹這個 EIP，還有分享我個人對於這個 EIP 的想法。

現有的 Gas 與 Gas Price

簡單複習一下：現在的以太坊中， gas（燃料）是用來衡量運算量的單位。它反映了一個節點執行一筆交易中的每一個步驟實際上耗費的資源。

在簽署一筆交易時，發送者必須要設定 gas （或稱作 gasLimit）作為這筆交易會用到的運算量上限，若一筆交易在執行過程耗費 gas 超過這個上限，就會被判定為交易失敗。另外，所有交易被收入區塊時，也會用實際運行交易消耗的 gas 量，乘上 gas price 成為最後總付出的手續費。（gas price 包含了 base fee 與 priority fee，但這裡可以把兩者合併一起看）。

在現有的框架下，gas 的功能相對單純：它代表了一筆交易消耗了多少節點的資源，可以用以判斷一筆交易的複雜度，也決定手續費的多寡。而一筆交易的「手續費」是用戶付給以太坊網路中的 validator 以確保交易被收入的，屬於以太坊網路層協議的規範，跟這筆交易所要驅動的特定智能合約沒有關係。若有用戶需要付 eth 給智能合約，則需要在交易中另外夾帶一筆 eth （或稱為 value、msg.value）。

提案簡介

而這個 Gas 2 ETH 的提案，想要藉由一個新的 opcode，簡單的做一件：讓智能合約可以直接將 gas 轉換回 eth，並加到某個帳戶裡。

具體來說，當合約執行時，它可以使用這個新的 GAS2ETH opcode，從一個獨立的 GAS2ETH budget 中扣除任意數量的 gas，扣除的量乘上當下的 gas price，可以直接變成 eth 並加入指定的地址，無需任何額外交易。

這個額外的 budget 初始化為 tx.gas_limit，但與執行用的 gas 分開計算，因此不會影響合約的正常執行。

另外值得注意的是： GAS2ETH 消耗掉的 gas 將不算在整個 block 的 gas 上限裡，也不會影響 base fee 的變化。

GAS2ETH 跟 msg.value 的差別

以結果來看，把 gas 轉換回 eth，跟現在以太坊交易中夾帶 msg.value 的作用其實差不多，都是某一個地址收到了來自交易發起者的 eth。但實則有兩個關鍵的區分：

一、不需要用到 msg.value

透過 GAS2ETH 當作收費手段，可以直接從一筆交易的「原生手續費」中收取費用，完全融合現有用戶與錢包既有的交易流程。

我們上面的圖中使用 Uniswap 舉例，大家可能覺得區分「手續費」跟付給合約的「msg.value 」很正常，因為若是想要使用 Uniswap 賣出 eth，交易附帶著一些 eth 很合理，這個使用情境也不像真的被合約「收費」。

但如果這個合約換成 Safe 的多簽合約錢包，且 Safe 合約錢包要求每筆交易都要付少量 eth 作為使用費，這樣的情況下若是使用 msg.value，就代表每個用戶呼叫合約時都要附帶 eth，非常麻煩；反之如果有了 GAS2ETH，用戶就不用想這麼多，一樣只要在交易的時候，指定想要付的 gas price，錢包幫忙算的總 gas 會自動包含 Safe 想要收取的 gas。交易執行時，合約再自動使用 GAS2ETH 轉換部分 gas 為使用費即可。

P.S. GAS2ETH 跟 transfer 有另一個執行上的細節差異，就是 GAS2ETH 會直接增加收款者的 eth 餘額，並不是進行一個 call 的呼叫。所以並不用擔心對方是否是合約、或 re-entrancy 等等問題，但這也代表我們有了更簡單的方式強制轉帳給某個帳戶。

二、GAS2ETH 收費可以與節點層同步、隨網路用量變動

這樣的收費方式除了方便以外，也會自動隨著網路使用量（gas price）變化，跟 validator 的手續費同步。這是一個美好的理想狀態：理論上合約層的協議們如果都採用這樣的收益模型，就可以跟以太的節點們共進退：大家都有一樣的經濟誘因，在以太坊的使用量越大時，收益越多。

過去曾經有不同的團隊試圖用這種方式收費：比較有名的是 0x Protocol：他們的 V3 推出時，就包含了一個隨著 gas price 變動的 protocol fee。每當訂單媒合完成的時候，taker 需要支付定值 protocolFeeMultiplier 乘上 gas price 的費用給 0x。

但由於 gas price 是不斷變動的數值，這代表 taker 要在確認訂單的時候，往往要高估現有 gas price，多送一些 eth 在交易中，免得突然 gas price 暴漲導致交易失敗（多付的會由合約退款）。0x 也允許大家用 weth（ERC20 版本的 eth）付款，合約會自動試著從 taker 的錢包裡面轉需要的 weth 到合約裡面。但無論哪一個選項，用戶要嘛要把一些 eth 轉換成 weth 存在錢包裡；要嘛需要每次接單都多丟一些 eth，並承受交易失敗風險。這造成 0x 從 V3 到 V4 都讓使用者怨聲載道，整合 0x 也成為一件麻煩的事情，總是伴隨著非常糟糕的 UX。0x 最終也推出了 RFQ，並且捨棄了 protocol fee。

如果有了 GAS2ETH ，這樣的收費方式有可能會再度成為主流。

對合約生態系的影響

上述兩點簡單敘述了，為什麼 GAS2ETH 好像沒有很特別，但其實作用很大。因為 GAS2ETH 創造了一種更直接、跟以太坊網路更綁定的收益模式，同時確保用戶在體驗方面也可以無痛銜接，這對不同種類的合約都有很大的影響。

對公共財與 DeFi 應用的影響

在目前所有種類的合約中，應該只有金融類型的協議（DeFi 合約）是有可能賺錢的：由於交易帶有金融價值，現有的 DeFi 協議，收益設計大部分都是從用戶真正交易的 token 中抽點稅，例如借貸平台中，賺取借方與貸方的利息差；或是永續合約用 notional value 取 BPS 作為協議收入。除了 DeFi 類型外的協議都很難賺錢。

若是有了 GAS2ETH ，智能合約就可以更單純地收取使用費。這讓一些開發合約錢包、DAO toolkit 的團隊有營收手段，且隨著越多人使用合約，收益也會越高。這能解決現在許多以太坊上面的合約因為是「公共財」而無法創造營收的問題。

DeFi 儘管已經有既有的收益模型，GAS2ETH 也能讓收費模式更多樣化，例如上述 0x 這種媒合交易的協議；GAS2ETH 也適合被用在一些如清算保護的自動化的服務，讓用戶可以支付跟「執行交易」相對應的費用。

對代幣經濟學的影響

目前以太坊上無法有效收費的最直接影響，就是讓代幣經濟學（Tokenomics）成為主流。無論什麼類型的應用，基本上現在都是靠著發代幣在彌補營收短缺，並靠著機制設計確保代幣可以保持其價值，定期幫助團隊變現。

如果有了 GAS2ETH 這種收費模式，所有類型的合約都可以使用這種單純的盈利模型。例如像 USDC 這樣的穩定幣，若是每次轉帳，約有固定其手續費 1% 的 gas 被付給穩定幣商（例如定價 200 gas），這就是一個非常簡易、符合穩定幣的發展目標的收益模型。

我認為這是一個更合理的解法。應用層可能因此出現更多單純來提供服務的合約，他們不必為此搞一套代幣以及 governance 系統。目前已經有代幣的項目，也能因此為持有者們增加額外的收入管道。

對整體合約開發生態系的影響

這樣的收費機制也會變相獎勵「合約優化」：幫用戶節省越多 gas，自然可以跟用戶要越多「小費」。這讓整個網路上的合約開發，不論是 DeFi 協議、還是公共財類型的合約，都會自然地出現很多動機做 gas 優化。這會讓以太坊整體可以執行的交易更多，更有效率地被所有人使用。

其他影響與潛在問題

雖然 GAS2ETH 能為合約層帶來更多正面的彈性，但它也可能會造成一些潛在的影響。這不一定是負面的，但是可能會對各個角色、甚至以太坊手續費市場造成相當多副作用，可以期待未來有更多的研究。

讓交易與 Gas 複雜化

最簡單也最直接的影響，就是我們會破壞一些原本以太坊交易的設計。

像最前面提到的，原本一筆交易的 gas 跟 gas price 都是只跟「網路層」相關的參數，跟一個合約的執行基本上沒有關聯；而 msg.value 則是設計為「交給合約處理」的 eth；有了 GAS2ETH 之後，會讓這兩個原本設計的分層變得模糊：未來交易中的 gas 不再單純代表複雜度，每個帳戶也多了除了原生轉帳以外的強制支付方式。

P.S. 這種「不呼叫合約」的支付方式，也有另外一個 EIP-5920 提議要透過一個 PAY opcode 來完成，看起來 Execution Layer 想要這個功能是勢不可擋。

對手續費與 Block Building 生態系的影響

GAS2ETH 也會對 block building 生態系造成很大的影響：目前以太坊大部分的 proposer 大多都使用 MEV-boost 來增進收益，其中 builder 會跟 searcher 一起合作尋找 MEV 的機會，並向 proposer 競標區塊的排序權，這是現在被稱為 PBS 的機制。Builder 跟 searcher 一起尋找的額外利潤都來自 用戶交易的 MEV。

有了 GAS2ETH 之後，將多了一個 App 以及用戶可以直接付費給 builder 的管道，這使得用戶不再必須透過支付給 proposer 的 priority fee 來影響交易順位，而是可以利用 builder 這個角色，直接支付小費或是 bribe。這可能會影響未來的 order flow 更多往中心化的 builder 角色集中，也可能出現許多與特定 builder 合作的應用。

對 ERC4337 Paymaster 的影響

在 ERC4337 的生態中，支付交易手續費的人都是 bundler，而用戶可以使用不同種類的 paymaster 來幫忙最後「報銷」這筆費用。

如果有現有的 AA 錢包幫用戶出交易手續費，很明顯的可能會讓人開始想辦法坑 paymaster 的錢，偷偷拿來執行一些 GAS2ETH 的合約，並把一些手續費變成 eth 轉給自己。這會讓 paymaster 的日子很難過：如果限制最高 GAS2ETH 可使用 gas 上限的話，可能會影響使用某些正當含有 GAS2ETH 的 App 時的體驗，不限制的話又有可能被薅羊毛，可能要引入其他的機制來篩選要補助的交易。

以上就是幾個比較直接會受到此 EIP 影響的生態系。

結語與個人感想

我認為這個 EIP 真的有非常巨大的潛力，不論是核心想解決的付費 UX，還是對以太坊上公共財專案帶來的影響力，都非常令人期待。

以太坊的更新歷史中，有許多能夠改變底層特性的 EIP，例如 EIP7702、Transient Storage、CREATE2 等等。儘管提出的時候一樣都有一些對既有生態系衝擊的疑慮，最終都大大提升了應用層的方便性、彈性，最終對整體的生態系往往都是加分的。也因此我認為我們可以用更正面的角度來看待這種簡潔且充滿彈性的提案，也非常期待它被納入下次的硬分岔。

以太坊是一個使用者付費的網路沒錯，但是一直以來這些費用都不是付給合約的開發團隊，而是付給以太坊的網路節點。儘管應用端的團隊們因此創造出了代幣經濟學，我卻始終不認為這是好的解法。查理蒙格有句名言： “Show me the incentive and I’ll show you the outcome”。我認為這完美解釋了為什麼目前的應用層往往讓人留下充滿投機的印象，因為這正是目前的獎勵機制能夠創造的唯一一種環境。

有了這個 EIP 之後，我期望看到的是未來應用層團隊的 incentive 本質上的轉變 — 更多人有誘因去為網路整體效能做優化、公共財專案得以延續、應用層凡事都要「為代幣賦能」的習慣也將被打破。

因此最後鼓勵大家如果有興趣，可以去 Forum 多看看大家的討論或表達對它的支持。目前提案的這個階段，可能還有非常多沒有人想過的問題，如果大家想到什麼問題，也可以提出來跟世界各地的以太魔術師們一起討論。

P.S. 順便推薦大家一個好用的網站 — forkcast，可以追蹤每個 hardfork 正在被討論、或是已經納入和拒絕的 EIP。

GAS2ETH 簡介 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

前言

在半年前寫完 Euler 上篇之後，Euler V2 經歷了飛速發展，協議的總鎖倉量有顯著成長，近期更是推出了 EulerSwap：一個可以與 Uniswap V4 相連結的產品，占據了許多討論版面。

在上篇簡介中，我們核心介紹了 EulerV2 身為一個借貸協議的特性，但實際上為了考慮借貸以外的應用，EulerV2 的工程藍圖十分龐大，例如另一個已經準備好卻遲遲沒有發布的合約是關於合成資產，也就是像 Aave 的 GHO 一樣的合成穩定幣。

在這篇文章中，我們將介紹 EulerV2 合約架構，一些設計理念，延伸到他目前已經實作的借貸與 Synth，讀者理解多種產品後，將更容易掌握「通用架構」的定義。最後我會列出它依然存在的限制、以及我對 V3 的一些完全沒有根據的想像。

EulerV2

Euler V2 如同很多團隊，試圖打造一個適用於任何金融協議的基礎架構：他們把這個協議的骨幹稱為 EVC (Ethereum Vault Connector)，並且試圖定義了一些所有金融協議的共通點，其中又以他們如何定義「共用流程」為核心。

下圖中我簡單畫了一個示意圖：最左邊的 EVC 合約定義了一些「流程」，右邊則是一個個 Vault。Euler V2 的根本邏輯，就是使用 EVC 作為框架，操作多個可以互相關連的 Vault。

我們在上文中有簡略提到：我們可以把 Vault 想像成一個個「資產管理單位」：在借貸的情境下，一個 Vault 就代表一個代幣的借貸市場。

目前 Euler 有實作的 Vaults，就只有 EVault 跟 Synth 兩個合約，其中 EVault 就是借貸協議的合約、Synth 顧名思義代表合成資產。它們兩個都符合「EVC Vault」的標準，因此可以透過 EVC 連結在一起。

至於什麼叫做「連結」？除了連結以外，上述的共用流程又是什麼？我們接下來馬上會介紹。這裡只要先理解，當我們又聽說一個 EulerV2 有一個「功能」時，它可能來自 EVC 、也可能是某一個 vault 特別定義的功能。

EVC (Ethereum Vault Connector)

我認為可以用以下兩個核心觀念來理解為何需要 EVC，這將能夠讓我們快速理解為什麼 EVC 會這樣設計：

1. 核心金融產品的共通點是抵押品 (collateral) 與各自不同的 accounting。
2. DeFi 協議應該符合 FREI-PI 的 Pattern。

我們先著重介紹這兩點，介紹完之後會再合併介紹 EVC 最終合成的模樣、以及其他的小功能。

1. DeFi Protocol = Collateral + Custom Accounting

這是 EVC 最核心的設計原則之一：根據 Euler 的邏輯，如果我們看借貸 （lending），永續合約（perp），選擇權（option）等金融協議、甚至拓展到預測市場等等，總是逃脫不了的一個詞就是抵押品（collateral）。

這幾乎也是 EVC 架構唯一對於實作比較 opinionated 的一個部分：它想像每個協議都會需要抵押品，然後以此為基礎去做別的事情，因此 EVC 中的 “connector” 指的一大重點就是希望能夠讓協議們彼此互相作為抵押品。

例如：有兩個協議都符合 EVC 的標準，一個是借貸 (lending)，一個是選擇權 (option) 協議，EVC 的遠大目標就是希望一個在借貸協議中借錢的人，可以使用他在選擇權協議中的 position 作為抵押品，並且盡可能簡化「接受更多抵押品」的擴充流程。

至於要怎麼算這個選擇權抵押品值多少錢、這部分就交給借貸協議去決定。這就是所謂的 custom accounting: 每一個協議要怎麼記帳、結算，跟 EVC 並沒有關係，EVC 只是簡單定義了一些常用的 collateral 與「主要協議」之間關係的流程。

這個如同「主要協議」的角色就是 “Controller”：每一個帳戶會對應到一個 controller，這個 controller 也必須是一個 vault，但它是「權力最大」的一個 vault，而用戶可以透過 EVC 把其他的 vault 當作 collateral 來使用，也有權力負責清算。

2. FREI-PI Pattern

我們前面一直講到的「共用流程」，實際一點來說，就是一個很類似於安全社群常常講的 FREI-PI Pattern 的流程。這個 pattern 一共可以拆分為兩個部分：「帳戶檢查」以及「協議檢查」：

帳戶檢查
簡單的說，這樣的設計核心原則是在每個使用者要對自己的帳戶 (account) 做一個操作時，允許他做任意數量的任何操作，只在最後檢查他的帳戶是否為「合法」：這就包括在過程中短暫的 underwater、或是讓使用者去做一些外部合約互動、例如 swap。

這部分設計的開山始祖是 DYDX，這麼做的目的是為了最簡便地解決 UX、 batching 與外部合約互動的問題。如果我們只讓一個用戶一個交易做一件事，會遇到兩個大問題

1. 需按順序操作且具備預存流動性（upfront liquidity）：
   如果一個用戶需要借錢，他就需要先一筆交易存入抵押品、 再另一筆交易借出錢。就算這兩筆可以被 batch 在一起，用戶也不能「先借出錢」，再加入抵押品。這件事看似正常，但實際上讓一個鏈上常見的 使用情境— 「槓桿」，變得很難做：因為每次要來借錢、都要先準備 100% 的抵押品，使得槓桿玩家必須透過 flashloan 等其它合約的幫助來完成。但如果我們用這個 pattern：直接允許用戶把錢借出來、一口氣 swap 成抵押品的資產，再加上少部分用戶自己提供的抵押品，就能完成一個 leverage 的倉位，我們只在最後檢查最終倉位是否合法即可。
2. 交易手續費與輔助合約：
   上述的做法不但整合上難搞、常常需要其他中繼小合約幫忙，另一個大的缺點就是每個動作都做一次倉位是否和法的檢查的話，這種 batch 的操作就會非常消耗 gas、畢竟這種檢查類型的計算通常是最消耗運算資源的。

因此這種「batch operation」，最後進行一個 “account check” 的 pattern 變得非常受歡迎。

協議檢查
為什麼會從 DYDX 的設計，延伸到這個名字很難唸的 pattern，主要就是安全性的考量：除了對於每個用戶各自帳戶的檢查外，最好再多一個「協議」本身的 global invariant check。

如果沒有這個全域的檢查的話，可能就會有一些類似「把自己搞破產、卻讓協議蒙受更多損失」的攻擊手法。這裡有一篇很棒的文章，可以給各位參考：〈You’re writing the require statement wrong〉。

FREI-PI 一言以蔽之，就是一個「允許任意操作」，最後在進行兩輪檢查：操作者帳戶檢查、以及全域協議檢查，這樣的流程。

EVC 的 Controller — Check 流程

理解了以上兩點原則之後，我們回到 EVC 的幾個重點：

• 所有跟 EVC 互動的合約，都是一個個 vault。
• 每個帳戶可以選擇一個 Vault 作為 controller、另外可以選擇多個其他 vault 做為抵押品 (collateral)。
• Controller 是決定帳戶最終合法性的主要協議：如果一個用戶要借錢，它就會選擇一個 EVault 作為 controller。
• EVC 允許用戶呼叫 controller 並進行任意數量的操作、 EVC 會確保在流程的最後，controller 合約上的 account check （帳戶檢查）跟 vault check （協議檢查）被執行。

我們用一個簡單的例子加上圖示來理解：若 Bob 想透過 Euler 的 EVault 借貸，可以想像成一個如下的初始狀態：

若 Bob 想要用 ETH 為抵押品，借出 USDC，他必須向 EVC 註冊這個帳戶想要使用 USDC EVault 作為 controller（因為 USDC EVault 最終要負責判斷願不願意借出這筆錢），並且用 ETH EVault 作為 collateral。

EVC 掌管所有人的帳戶權限，也負責記錄每個帳戶的 controller, collateral 分別是誰。

接下來就可以進入真正執行交易的流程了：

我們簡單解析一下這個流程圖：首先，第一個操作 (operation 1) 用戶先對 controller 呼叫 borrow，在這個時候 controller vault 就已經先把 USDC 轉給用戶了。接著下面一個步驟 (operation 2) 用戶才把抵押品存到 ETH vault 中。

而最後一段 checkAccountStatus 以及 checkVaultStatus 兩個呼叫，就是前面介紹的 FREI-PI 的兩個檢查，它們會在一系列操作的最後執行。而這兩個檢查其實是 controller 要求的：第一步中，USDC Vault 被呼叫 borrow 後，就透過一個 requireAccountStatusCheck 的方式，回頭告訴 EVC：「要記得最後確保帳戶是合法的。」同理 requireVaultStatusCheck 則是告訴 EVC 要記得呼叫一個 vault-level 的檢查。

這裡可以看出，這樣的設計理念是透過統一介面當作起始點 (EVC)，統一發出對很多不同合約的連續呼叫，但最後又要由「主要負責 accounting」的那個合約負責執行帳戶檢查，因此 Euler 才想出這麼一個複雜的架構。

Execution Context

上述這種把檢查放在最後面的流程，在 Euler 的實作中被稱為 deferred check （延遲檢查），是 EVC 對呼叫時的預設模式，而實作中透過一套 “Context” 來管理。

EVC 會用 transient storage 儲存最近一次對外呼叫的 context，藉此判斷何時要進行所有的檢查，並透過兩個 set 存下所有要檢查的帳戶地址及 vault 的地址，以方便進行所有檢查。

一個 vault 可以要求 EVC 檢查不只一個帳戶；一個 vault 也可以在自己被呼叫時再透過 EVC 去呼叫別的 vault，這時 context 就會紀錄「多個」需要被檢查的 vaults。這樣的情境被稱為 nested execution context，確保每個 vault 都可以最大彈性的去做任何事情，而 EVC 會確保所有該檢查的東西都有檢查到。這部分細節比較複雜，有興趣了解更多的可以看文件連結。

Forgiveness & Control Collateral

除了前述正規的「要求檢查」流程外，一個 vault 也可以用 forgive的方式「取消」這樣的要求：例如在清算的流程當中，如果協議設計上被清算者有可能被清算後，仍然過不了 health check，該 vault 就需在清算過程中呼叫 EVC 的 forgiveAccountStatusCheck，將此檢查從待檢查清單（set）中移除，否則清算交易最終會因為帳戶檢查失敗而失敗。

另一個在清算過程會用到的 function 就是 controlCollateral ：可以簡單想像成，一個讓 controller vault 有能暫時控制一個帳戶的 collateral 的機制：例如在借貸協議的清算中，需將被清算者帳戶內的抵押品轉給清算者。由於這些資產實際存放於 collateral vault 中，controller 需透過呼叫 EVC 的 controlCollateral 來間接操作 collateral vault。 EVC 判斷其權限之後，就會照著 controller 想要的方式，去呼叫 collateral vault。在 collateral vault 看來，可能就是一個簡單的用戶 withdraw 交易而已。

這裡不能看出 EVC 這樣生態系之內的信任關係：controller 是最重要的一個角色，如果你註冊了一個奇怪的 vault 作為 controller，它是有權力鎖住或是拿走你在 collateral vault 中的資產的。反過來說，controller 也要信任底下的 collateral vaults，否則它們可以惡意導致清算失敗。

EVC 其他功能

除了上述的核心 context 管理以外， EVC 提供了許多所有協議都會需要的功能：

SubAccount — 子帳戶

Subaccount 指的是用簡易的方法讓一個地址，能夠控制 256 個相互獨立的「子帳戶」。這讓每個 vault 在實作上，可以直接把每個不同的 account 當作完全不同的個體，不用去管理帳戶轉移和權限等問題，而每個用戶可以用最多 256 個子帳戶，去跟所有 EVC 底下的協議互動。這是 Euler 從 V1 開始便實作的功能，非常的簡潔、不需要用到昂貴的 storage 就輕鬆解決多帳戶的一個方法，我覺得到現在還是有點被大家低估了，非常推薦大家套用這套實作方式。

Operator

除了子帳戶外，用戶也可以為每個子帳戶設定 operator 的地址，可以是 EOA 或是合約，有利於大家開發一些代管、自動化的產品。

這也不是一個特別的功能，但最近很紅的 EulerSwap 便是利用這樣的機制：每一個想要當做市商（market maker）的人，都要設定一個特別合約作爲自己借貸帳戶的代管者，這個合約就會透過 hook 連接 UniswapV4，動態的使用「借貸」來填補流動性、媒合一些 Uniswap 訂單來賺手續費。

Permit + Batching

最後講到 Permit 與 Batching：所有跟 EVC 生態系互動的交易，都可以透過 permit 的方式發出，也就是可以完全 gasless，用戶只要簽名，不一定要消耗寶貴的以太或是自己發送交易。

Batching 簡單講就多筆交易綑綁在一起，不過這裡有一點值得注意：由於 EVC 可能同時有好多的協議，理論上 batching 也可以跟 permit 結合，統一把與 EVC 底下所有協議互動的所有交易，一起打包送上鏈。這能開創一些特別的 usecase，也讓各個 vault 不用自己處理任何自己協議內的 batching，在開發上十分方便。

標準化的 EVC 協議

Euler 會做出這樣的設計，以借貸協議的出發點其實不奇怪：從 Compound 開始，由於要做出可以互為抵押品的 monolithic lending，合約上便使用這種由一個中心化的 “Comptroller”，聯繫不同市場的架構。只是以前一個單位僅是一個 ERC20 (cToken)，而還是由中心的 Comptroller 作為借貸協議的核心骨幹，包含了大部分的商業邏輯等等。

EulerV2 與 EVC 的架構，把這個概念更進一步的抽象，我認為其中最大的重點就是「協議」與「資產」的模糊化。

以往我們在開發協議的時候，通常想最多的都是自己核心的商業邏輯，並把所有可能未來要接受的資產，都視為一個個 ERC20 ，這導致我們高度依賴代幣化：任何協議只要將其資產包裝成 ERC20 代幣，就能輕易被外部使用，形成俗稱的「DeFi Lego」。

當然，ERC20 並不能表達所有的應用場景，也因此許多協議都需要別的協議包裝成不同的標準，才能互相使用。

如果換成使用 EVC 的架構來看待上述的協議關係，則更像是每個協議放棄更多自主性，透過統一的帳戶標準，在核心層整合 EVC 的流程，包裝成 vaults，便於與其他協議連結及互動。在我心裡的想像大概變成這樣：

我們不再是以「中心協議」對「外部資產」的角度在看待要整合的其他合約，取而代之的是較為平行的關係，並且分享了一樣的帳戶標準。

要說這樣比較容易管理嗎？我覺得不一定，其實金融本質上，協議之間相互依存的關係依然存在，並不會因為換了一個合約架構，就突然少了一層疊疊樂的風險。

一個比較明確的差異在於安全性：各協議如同登上同一艘船，因核心流程由 EVC 定義且經過多次審計（audit），其安全性較有保障。此外，採用相同體系或能在清算流動性等環節共享基礎設施，帶來工程實務上的效益。

除此之外，我認為剩下的好處比較多是心理上，或許會覺得這樣更好理解與管理。

更多的 Vaults — EVault & Synth

前面介紹的過程中，已經把 EVault 的功能介紹的差不多了：簡單總結一下，EVault 就是能做到多市場互為抵押品的借貸市場。藉由多個 EVault 同時接受彼此為抵押品，以此提高資金利用率。每個 EVault 所掌管的，便是關於「每種抵押品最多能借多少錢」這類型的設定，當然還有清算流程：用戶必須用合法的抵押品，才能借出 EVault 中的存款。

P.S. 如果想要複習一下這種「多對多」的借貸市場，跟比較單純「isolated lending」的比較，可以看這篇 Morpho 與 Euler 的比較。

Synth (ESynth)

有了基本的 EVault 之後，要在其上做合成資產就變得簡單很多：有興趣看細節的可以看這個 github 連結：裡面加起來應該只要幾百行程式碼，就輕鬆就做出了一個合成資產。

這裡的做法是：ESynth 合約可視為符合 EVC 標準的 ERC20 代幣，它一方面像 escrow vault 一樣擔任簡單的包裝器，使得這個合成資產可以被 EVC 中的其他協議使用；另一方面，它唯一做的事情就是把資產 mint 到 “Synthetic Asset Vaults” 當中。

Synthetic Asset Vault 就是變形的 EVault，EVault 的本質就是借貸市場，Synthetic Vault 跟 EVault 的唯一差別只在於，Synthetic Vault 只有 ESynth 合約可以 deposit 進去，也就是一般人不能 “supply” 到這個市場裡面。

一般人若是想要持有這個合成資產，就要直接從 EVault 中借出該資產：下圖是一個簡單的想像圖：假如我們今天想要創造一個類似 USD 的資產，簡稱為 eulUSD，那一個完整的「借貸市場 + 合成資產市場」組合拳就會如下圖：

有了以下設定之後，用戶便可以用 ETH，跑到 EVault 3 去借出 ESynth。這樣就創造出一個「有抵押物背書」的合成資產了！

不過有個值得注意的點，就是這張圖裡的 EVault 3 由於只有 ESynth 合約可以 supply 進去，因此其他 vaults 理論上也不會開放這個資產當作合法的 collateral，畢竟能夠持有的只有 ESynth 合約而已。一般用戶可能會拿到的只有最右邊的 ESynth ERC20 token。

但反過來，EVault 3 還是可以設定各式各樣的 collateral 都能夠來 mint 這個合成資產。而 ESynth 亦可將資金分配至多個 EVault 中，讓 eulUSD 可以同時服務多個不同的「借貸生態系」。

這裡或多或少可以看出，EVC 不僅適用於 EVault 這類借貸協議（雖然 ESynth 跟 EVault 算是高度相關），更能延伸至任意協議。如果想要拿 EVC 當做基底，來開發其他 DeFi 協議，也能享有前述的一堆內建功能。

EVC 的限制

在整個 EVC 的設計中，我認為一個十分可惜的點，是對於 EVC 帳戶與 Controller 一對一的限制。

這樣的選擇十分的合情合理：大幅降低了整合與合約的複雜度，變相大幅提升安全性。 EVC 作為一個處理權限的中樞，這樣一個帳戶一個 Controller 的規則，能夠確保與之整合的協議，能更好地理解唯一的「控制權」。

我會認為有點可惜，是因為我認為這是 DeFi 衍伸品協議界最待解決的問題。我們舉一個簡單的例子：假設 Bob 今天在一個 EVault 使用 ETH 為抵押品借了一些 DAI，且 EVC 體系內存在另一個永續合約協議 （就稱它為 Euler-Perp吧），如果能讓 Bob 把這些 ETH 抵押品減去 DAI 的欠款後餘額，當作保證金到 Euler Perp 做一些短線交易，資金利用率不就又大幅提升了嗎？

為什麼目前的 EVC 做不到這點，是因為 Bob 在 EVault 可能被清算，因此 EVault 必須作為 Controller 來確保自己有控制權與清算權：這就代表 Bob 的這個帳戶，沒辦法再去做其他危險的事情了（沒辦法再設定 Euler Perp 為 Controller 來玩交易）。

我們前面雖然說到，這些 vaults 雖然能互相成為彼此的 collateral，但這樣的整合僅限於成為彼此抵押品，仍然無法做到「共享控制權」，也就是你一但在某個協議持有可能被清算的倉位，你就不能再用同一筆錢到另一個協議做類似的事情。

這些限制聽起來很合理，（畢竟這樣就有高槓桿的風險）但這也正是許多人嘗試解決的 DeFi 痛點。尤其是一些傳統金融來的人，總是對 “portfolio margin” 這個詞執迷不悟：如果我們可以拿跨協議的 portfolio 來做擔保，那每個協議都能好好的做好一件事情，但又同時允許用戶拿著這個 portfolio 跟其他的協議組合，最大化的增加資金利用率。

我認為未來如果有 portfolio margin 問題的解法，肯定會長得跟 EVC 有點像：一個中心化的流程中樞、共享的清算機制、並且有辦法透過一個共用的流程，讓每個協議簡單定義少少的函示，交由中樞確保操作後所有協議的要求都有被滿足。

Euler 並沒有在 V2 做到這件事情，也導致這樣的設計有時看起來會有點「雞肋」：雖然好像非常的有拓展性，但純粹以功能面來看，它這樣的架構實際上「多做」到的事情並沒有太多。

再加上 codebase 裡的一些小細節（例如 controller set 是一個 set，但最多只能放一個值）當讓我覺得，Euler 很可能是為了做 portfolio margin 為出發點開始設計 V2，只是遇到很多不必要的複雜度，因此才決定把它砍回一個相對基礎的版本。

小結

儘管現在一統大 DeFi 的夢想還沒實現，但是 Euler V2 可以說是已經把這種通用架構做到一個極致，並且離大家夢寐以求的 portfolio margining 只有看似一小步的一大步之遙。

除了設計外，他們的工程方面的實作、安全性測試等等，也是堪比合約開發界楷模：非常推薦有在學習形式驗證 （formal verification）的人去看他們 EVC 或是 vault kit 裡面所寫的 certora 測試。

從第一次看 Euler 到現在，我也經歷了「不懂幹嘛把事情搞那麼複雜」，到「理解它跨協議通用性的厲害」，再到「隱約看到它的未來」這幾個階段。目前的理解也就停留在這裡了，如果未來有更多想法，會再補充。

就讓我們一起期待 Euler 的下一步吧！

Euler V2 介紹 —(下) was originally published in DeFi 燒酒螺 on Medium, where people are continuing the conversation by highlighting and responding to this story.

謝謝 Kevin Lin 幫忙 review

前言

這陣子研究借貸協議比較多，也發佈了兩篇文章分別探討 Euler 跟 Morpho 兩個借貸協議。如果對這兩個協議不了解建議回顧兩篇文章。

• 借貸協議 Morpho 簡介
• Euler V2 介紹 — (上)

這篇文章我想獨立分別出來，特別比較 Euler 跟 Morpho 的差異，我把他們兩家各自視為 Monolithic Lending (Euler) vs Isolated Lending (Morpho) 的典範，但這兩種模式有許多本質上的差異，我認為一定程度上這會體現在更方方面面：他們未來各自會如何 scale、遇到什麼樣的成長瓶頸、以及每一個被稱為「特色」的點隱含的 trade-off，都可以透過直接的比較清楚地呈現出來。

同時附上英文版連結，內容有些微不同，也希望大家可以捧場一下 😆

Monolithic Lending vs Isolated Lending

稍微複習一下兩種協議的基本邏輯：

Monolithic Markets

指的通常是一個多資產的借貸市場，並用有以下特徵：

1. 支援多個抵押品：不同使用者，可以用不同抵押品，到同一個池子中借錢，並且使用相同利率

2. 存入這個市場中的抵押品，同時也允許別的人借出：自己的抵押品也變相是一個市場的流動性，能夠生利息。

我們比較熟悉的 Aave 跟 Compound 都是屬於這種市場。這種市場通常設定比較複雜、也必須牽扯到「管理」層，否則誰來決定這一個池子要接受哪些抵押品。 Euler V2 是第一個做出底層去中心化，讓所有人都可以來部署任意 monolithic market 的協議，也就是可以利用 Euler v2 去發行跟 Aave 一模一樣的市場。

Isolated Markets

Isolated markets 則是相對簡單的設計：這些協議中會有最小單位的市場，每個市場只會有一個 loan asset （借貸資產），以及一種抵押品。不同的 borrower 必須到不同的市場中去進行借款，每個市場的利率也不相同。

Morpho 身為 isolated lending 的代表，還會使用叫做 “Vault” 的合約當作中間層的聚合器（上圖藍色的方塊），這樣聚合器收了存款者的錢後，會再存 (supply) 到不同的市場中，賺取利息，並且幫忙存款者進行合理的風險 / 收益管理。

簡單回顧完兩者定義，我們接著可以從幾個面向來比較這兩種不同架構的借貸協議：借錢者的 UX、資金利用率、特殊角色分工、流動性、以及不同架構隱含的假設與精神。

Borrowing UX

對 Borrower 來說，用 Euler 的用戶 UX 體驗應該是較為舒服的，其中最大的差異來自可以同時用多少不同抵押品來借錢。

在 Morpho 的設定中，每個 collateral + loan 都會是一個獨立的市場，所以要同時 maintain 多個倉位才有辦法一邊用 ETH 借錢，一邊用 BTC 借錢。在 Euler：這兩個倉位可以合而為一，只要管理一個總倉位就好，清算時則由 liquidator 決定要清算你哪一個資產。

但一個有趣的點是，在 Morpho 中，你的每個分離的倉位都理論上會拿到一個更公平的市場利率。例如我就只用 ETH 借 USDC，利率就只有 5%，如果同時想用 eETH 借 USDC，這部分的利率可能 15%，兩個會分開算。

同樣的情境在 Euler 中，可能因為這個 Vault 就是接受 10 種不同的抵押品，所以利率很自然地會是所有資產的「平均」。這將不利於使用相對安全的資產借錢的用戶，因為等於他同時承擔了較高風險抵押品的利率。

但相對的，如果你是個喜好風險的 Degen，且有一天 Euler Prime 開設了 DOGE Prime Vault，你拿 DOGE 來 Euler 抵押借錢，就等於讓其他安全的抵押品幫你承擔一定的風險，應該能拿到相對較好的利率。

信任假設

另一個值得一提的差異在於 borrower 的信任假設：在 Euler 的框架中，一個借錢者可能從本來好好的，卻因為有人覺得你這樣危及協議安全，去改動清算參數讓你可以被清算。

資金利用率：Capital Efficiency & Rehypothecation

Monolithic 架構最大的優勢之一就是抵押品資產的再利用 (rehypotecate) ，這樣不但 borrower 可以賺利息，更能順便提供流動性給另一個借貸市場。

我們在介紹 Euler 的文章中有特別提過這個情境：假設有 Alice 與 Bob 兩個人，Alice 想要抵押 DAI 借 ETH，Bob 想要抵押 ETH 借 DAI，這兩個人在一個 Monolithic Lending 的市場 cluster 中，可以互相成為對方的流動性，如下圖綠色的部分。

反觀 Morpho 中（藍色區域），這兩個人必須要面對不同的市場，各自存入的每一塊錢抵押品，就真的完完全全是「抵押品」，會被鎖在 Morpho 合約裡面，確保清算的時候可以被清算，沒辦法再被借出去。

這裡有幾個角度可以去延伸，第一是借貸雙方的角色：

在 Euler 的架構中，其實大部分的 Borrower 也同時是 Supplier，因為他們大多會選擇把抵押品再借出去賺利息。由於這些市場彼此之間已經有「互相信任」的關係了，再借出去也沒有多餘的信任假設。在 Morpho 中，每個人在每個「小市場」中都必須明確選擇是 supplier 還是 borrower，每一分錢你也都可以清楚地看出這到底是 supplier 提供的流動性，還是是來自 borrower 的抵押品，這兩者之間涇渭分明。

第二是總所倉量（ TVL ）在借貸協議中的意義。

假如看 Morpho 這種協議，TVL 通常是隨著協議成長或使用量而成長，有個比較直接的正相觀。但站在 Euler （或是任何強調「資金利用率」的協議）的立場，他們通常不喜歡討論鎖倉量，因為整個合約存的多了、不見得代表使用的較多，尤其他們又想強調一塊錢的資本可以翹起比較大的槓桿。舉個簡單的例子：今天 Euler 裡所有的 supplier 突然都發病，開始用原本存進去的錢當抵押品，借點東西出來，其實這樣用量提高了，但會發現協議的總所倉量降低了，因為大家都把錢借了出去。

所以在比較借貸協議時，其實以「總 Borrow」來看通常是比較有效的指標：越多人來借錢，一個協議能創造的總收入就越高。

協議中的不同管理者

Euler：管理者全權負責市場與吸引流動性。

在 Euler 中，被管理的單位是「市場」。由於每一個市場都可能有很高的複雜度（要管理一個資產與不同抵押品之間的關係，例如用 BTC 最高能借多少USDC 、用 LINK 能借多少 USDC），所以每一個市場都有一個潛在的管理單位。由於一個「cluster」中的所有市場需要彼此信任，中間也有動態可改變的信任鏈，因此通常一整個 cluster 會由同樣的管理者管理。

當然，一個市場也可以沒有管理者，所以 Euler 也能做到去中心化的市場。但大部分比較複雜的設定都不敢做無管理的市場。

這些管理者要負責的就多了，除了定義這些參數，同時也包含尋找 supplier & borrower 雙方的流動性，因為自己開啟的新市場跟其他人開的市場，是沒有辦法共享 supplyer 或是 borrower 的。

Morpho: 完全無所有權的底層，配合 risk curator 管理 supply

而在 Morpho 的設計中，最底下的市場則是處在完全無人能管的自主狀態。他們所導入的管理者是中間聚合器層的 “risk curator”。

這群 risk curator 可以是一群專業的資產管理者，透過去調配不同的策略比例、吸引不同的使用者存錢進來，再把流動性分配到不同市場中。他們能做的管理其實只在於 supply side，負責幫忙一般只想存錢了事的大眾，分配資產到不同的市場中賺取利息。市場是無法被管理的，開創出來之後，就交給看不見的手去決定：如果有 borrower 有使用這個特定市場借錢的需求，就會來這個市場借錢。

流動性與網路效應 (Network Effect)

我們接著來看，每個 Protocol 一定會吵的流動性問題：到底怎麼樣的設計會讓流動性比較好？

其實不同設計，反映出的是大家認為要擴張會遇到的難點是什麼。我們認為一個比較好的思考方向，是比較兩者分別想在哪裡做出網路效應「或是規模經濟」，並且用什麼樣方式解決個別預想的問題：

Monolithic Lending (Euler) : 上層代幣化供給的網路效應

Monolithic Lending 的好處是，比較單一資產，若是能接受多種抵押品，能夠聚集起來的流動性通常容易比單一抵押品市場大很多：畢竟比較多不同種類的 borrower + supplier 能來到同一個市場中做借貸，例如想要拿 BTC 借 USDC 的人，跟想要拿 ETH 借 USDC 的人，如果都能來同一個市場操作，就代表這兩種人的流動性整合在一起了。

這讓每個 Vault 的流動性可以聚集的很大：例如所有信任 Euler Prime Cluster 的 USDC Supplier，全部都會把錢存到統一的市場裡，borrower 也會統一來這裡借錢，這裡的 Vault 代幣化資產 (例如叫做 eUSDC 之類的)，就會有很高的發行量。

除了整合不同需求進入同一個市場 ，這樣的架構也把 borrower 跟 supplier 的角色混在一起：上圖中的 Borrower，如果存入 DAI 當抵押品，也順便為 DAI 的市場提供了流動性。

如今的 Compound cUSDC 或是 Aave aUSDC 都可以想像成這樣成功聚合「USDC Supply & Borrowing」的市場。這些代幣化資產有可能會被更廣泛的接受，或是因為流動性足夠高，衍伸出 Curve 的現貨市場，或再被拿去做一些如 Pendle的衍伸性商品市場、或被當成含利息的穩定幣來使用。

我認為這在 DeFi 中是一個不可小覷的優勢：如果一個 ERC20 擴大到一個規模，它的可組合性會被放大，被更多的協議、錢包、交易所支援。

這樣的架構，就是期望能整合不同需求的借貸者、全部進入同一個借貸市場統一管理，並且靠流動性造成規模經濟。

Isolated Lending (Morpho): 無信任基礎的共享流動性

而反觀 Morho 這類協議，一般人存錢碰到 Vault 合約（也是代幣化的合約），其實只是單純的聚合器。每當有一塊錢存入其中時，它其實被分散到不同的底層市場（綠色方塊）中，並有獨立的利率：

由於真正的市場是綠色的方塊們，處於中間的聚合器會較難做出規模經濟，畢竟本身不是真正市場所在地、沒辦法因為只有這裡有流動性來強迫別人加入。因此儘管有一個 Vault 存量特別大，它也並相對不容易在「代幣化供給」這層做出壟斷。

相反的， Morpho 會希望看到的是，雖然每個底層最小市場單位的屬性不同，但透過自己「組合」的方式，每個人還是能拼出自己喜歡的商品，並且共享部分流通性是可以被共通的。

這裡有一個很大的特點：由於底層這些綠色市場沒有「所有權」的概念，因此每個人在選擇使用這些市場時，不需要對任何人有信任假設。加上上面提到的 risk curator 角色們，可以輕鬆開創一個新的 vault，把錢倒流到不同的市場，而且聚合器單純用策略差異化吸引不同的人來存錢賺利息。所以要在 Morpho 上開一個策略並開始吸引存錢賺 performance fee 非常簡單，不用擔心「怎麼先找到 borrower」的這種 cold start problem。

Cross-Vault network effect
這樣的架構，也是試圖整合不同的使用者，但並不是透過把他們吸引到同一個市場中，而是透過不同中間人，去創造不同的使用情境，但在底層市場單位中，在沒有任何信任假設的條件下，共享部分的流動性。

我們可以假設有 Alice 是一個只信任 ETH 的 supplier, Bob 是一個只追求高收益的 supplier。這兩個人在 monolithic 的市場中是不會把錢放在一起的，也就是他們的流動性不可能融合。但是在 Morpho 的架構中，他們可以分別存在不同的 Vault 裡，但各有一部分的錢最後被分配到相同的市場中，做到流動性整合。

因為這個體系下不會有任何一個需要大家信任的中心，成長過程中不會遇到「管理障礙」。 如果有一個 Vault 做得特別好，它也能連帶影響底下的市場受惠、這些市場也能變相回饋給其他的 Vault。這種不定義 usecase，但所有人都可能連接在一起的方式、是 Morpho 想要看到的網路效應。

兩種設計背後的精神與假設

我們最後可以思考一下兩種設計所內涵的精神是什麼。

Monolithic Lending：資金效率、合作與共享

Monolithic Lending 我覺得有個深層假設，就是「集中流動性與效率」代表一切：他們希望一個市場包含較多的元素，若有兩個 borrower 拿的抵押品不同，Euler 認為他們若是能夠被聚集在一起，總體還是會受益。上面提到過，這件事我認為在 DeFi 中可能更被放大，因為可組合性的關係，明明都是代幣化的 ERC20，如果能成長到一個規模大家把你視為「穩定幣」，就是一個重大歷程碑。

不過在這樣的假設下，也比較容易衍伸出管理相關的議題，它的隱含思想還是比較靠近「被管理」的一個大市場。上面提到的 Borrower UX 討論中這點也特別明顯，在這樣的架構下，不論是 borrower 還是 supplier 都必須要信賴一個「被管理」的市場、部分放棄自己的完全控制權。

但這不一定是負面的，我認為這也隱含了一個願意「合作」的信念：我把他理解成對於 “on-chain governance” 的信任，相信一定程度的管理與合作、結盟是對大家有益的。

EulerV2 很值得期待的點是，它們理論上可以被用來創建多個互不相關的 monolithic 市場，所以可以期待他們是否有機會透過「多個複雜大市場」來超越前面所有 monolithic lending 遇到的發展限制。

Isolated Lending：最大化無信任假設的流動性互通

Isolated Lending 的深層假設，則是「有信任基礎的合作」與「統整多種用途」的擴張模式都會遇到成長極限：不可能有一個市場可以滿足所有人，必須要讓所有人的借貸需求都被滿足，這部分就只能靠底層完全風險隔離、並容許客製化的方法完成。

這樣的假設似乎相信，要使 DeFi lending 成長到下一個階段，必須靠更多新的借貸場景提供流動性（比較不在意利用率，強調完全沒有信任假設的客製化），而不是停留在「建構一個滿足最大量 borrower 跟 supplier 的市場」這樣的目標。

這樣的精神更往「去除所有中間人」的想法靠攏，每個 Morpho 市場的參與者，都可以對自己的所有資產有完全自主權，其中又以 borrower 的角色尤為明顯， 在 isolated lending 被 Morpho 發揚光大之前，大部分的 DeFi lending 都包含了一定程度的信任假設，現在透過 Morpho 我們可以觀察到底有多少完全去中心化借、貸款需求。

我十分看好這種完全「自由」的擴張模式。如果觀察現在 Morpho 上所有開設的市場列表，會發現非常的瘋狂，光是已經被加入白名單的就有兩百多個，因此我也特別期待 Morpho 這樣的協議在下一輪牛市中能扮演的角色。

結語

Isolated Lending 與 Monolithic Lending 其實存在諸多本質上的差別、甚至可以說是「精神」上的差異。被包裝到最後，雙方都能站在自己的角度，說自己的流動性比較好、比較安全、比較能 scale，但其實大家的出發點是基於完全不同的假設。

希望這篇文章能夠幫助你看清這兩大協議之間實際的取捨是什麼，也可以讓大家 zoom out 並思考，究竟自己比較相信 DeFi 的未來會是基於合作與效率的大一統（或多統）世界、還是崇尚完全自主、無信任的金融樂園。

結局肯定是兩者並行，但大家可以玩個遊戲，在心裡自己做一個小預測：怎麼樣「假設」能夠在接下來的這個 cycle 中更可能被發揚光大呢？

透過機制設計看協議核心價值 was originally published in DeFi 燒酒螺 on Medium, where people are continuing the conversation by highlighting and responding to this story.

一起來拆解看似複雜的 Euler V2

感謝 Kevin, Jack 幫忙審稿

前言

今天來填個之前挖的坑，也就是 EulerV2 協議的介紹。Euler 可以算是 2024 年最被期待的借貸協議之一，因為它是一個非常有野心的嘗試，除了在底層做出完全去中心化的公共財特性（Hyperstructure！詳情請見在 Morpho 篇的介紹），也滿足了 DeFi 借貸協議需要的多資產抵押等特性。

由於 EulerV2 非常龐大，我覺得在比較 high level 的系統設計以及合約開發角度都有亮點，所以我會把介紹內容分成上下兩篇；上篇著重介紹 Euler 身為一個借貸協議的設計與特性；下篇著重於他們實作與開發上的特別之處以及更多可能性的討論。與之前介紹過的 Morpho 相比，Euler 的功能多了不少，在底層邏輯上也有十分大的差異，因此有許多特性不同，比較的部分則是整理在這篇文章中。

協議定位與組成

Euler V2 底層是一個完全去中心化的協議，每個人都可以利用 Euler 去部署新的借貸市場。但這裡的市場指的不只是「一種借出資產和一種抵押品」的配對那麼單純，而是涵蓋多種資產，彼此可以相互作為抵押品來進行借貸。

舉個例子：Euler 可以建構一個單純（像 Morpho 一樣 Isolated Lending）一樣的簡單市場，如下圖左： Loan Asset = USDC, Collateral = ETH，在這個市場中，就只能使用 ETH 當作抵押品借出 USDC。

但它同時也可以用來建立一個複雜的多資產生態，如下圖右：用戶可以放貸 USDC 或 DAI，要借出 USDC 可以用 ETH 或 DAI 當抵押品，要借出 DAI 只能用 ETH 當抵押品。

這種比較複雜的多資產、互相借貸關係，其實就是以前所有 DeFi 借貸協議試圖建構的：Aave, Compound, EulerV1 都是用這種模式各自開創自己的生態系。這些多資產借貸協議被稱為 Monolithic Lending Protocols，好處是有較高的資產利用效率、靈活度比較高，但通常整個協議之中存在複雜的互相信任假設。

我們在這裡可以先把 EulerV2 視為一個：「能夠用來部署同樣多資產特性的 monolithic 市場」的協議。它也能用來部署 isolated markets，但主要是為了服務 monolithic 的使用情境。

理解 Vault

EulerV2 的設計核心，在於一個叫 Vault 的東西，也就是上圖中的每一個「方塊」。 Vault 是協議中最小的運作單位，所有東西都必須被包裝成 Vault 才可以被 Euler 使用。

我自己覺得好的理解方式，是把 Vault 想像成一個個「資產管理」單位。目前唯一被實做出來的一個 Vault 叫做 EVault ，也就是一個借貸 Vault。現在所有的資產都必須被包裝成 Evault 才可以使用，不過為了簡化，我們這篇文章就都以 Vault 來代稱。

P.S. 這裏稍微提一下： EulerV2 這個框架可以拿來做借貸以外的事，例如透過不同種類的 Vault 來發行合成資產(Syncth) 甚至選擇權等。這方面會在下篇重點介紹。

Vault 的資產管理

每個 Vault 除了包裝、存提資產以外，同時也負責「管理」底下的資產。我們可以把每個 Vault 當成一個「借出資產」的管理者，也同時代表每個 Vault 能形成該資產的一個借貸市場（有一個市場利率）。如果我們換成用這個角度看待上面分類的不同「資產」的角色，就不存在 Loan, Collateral 或是同時是兩者的三種分類：只剩下 Borrowable or not。

已上圖右的多資產框框為例，三個 Vault 實際上是分別以獨立的方式，管理如何借出自己的資產。實際的管理方式透過分別設定這樣一個「核准抵押品」的 Config 來做到。

如上圖中，每一條線都是一條「核准成為抵押品」的設定關係：USDC Vault (USDC Market) 允許使用 ETH Vault 跟 DAI Vault 作為抵押品借出資產，各別的清算參數 (LLTV, Liquidation Loan to Value) 也會寫在 USDC Vault 合約裡；DAI Vault 也有一套參數，只接受 ETH Vault 作為抵押品。

比較特別的是 ETH Vault，它目前是一個只能當作抵押品的資產，因為這個 Vault 沒有設定任何的抵押品參數，因此沒有任何方法跟它借出 ETH。我們先把它擺在一邊，當作單純的「抵押品」來看，等我們看完使用者流程之後會有更深入這些不同的 Vault 種類的介紹。

使用者流程

Supplier 流程
繼續上述的市場設定，假如今天 Bob 是一個 Supplier，想要放貸 USDC 賺利息，他實際上需要考慮的就是 USDC 市場的兩種抵押品，他們的 Oracle 與清算參數是否合理，如果放心的話就可以把錢存到 (deposit) USDC Vault 中。

Borrower 流程
假設 Alice 想要來借 USDC，她第一步是需要存入資產到 USDC Vault 核准的任何一個抵押品 Vault 中，假設今天她選擇抵押 ETH，就必須先把資產（抵押品）存入 ETHVault，接著才可以去 USDC Vault 借錢。

在這個流程中可以注意幾個有趣的點：當 Alice 準備向 USDC Vault 借錢時，實際上是把抵押品存到 ETH Vault 當中，這些 ETH 並不是由 USDC Vault 直接掌管（但可以想像一定有某些清算權）；同時，在同個步驟存錢到 ETH Vault 時，其實 ETH Vault 也是不知道 Alice 之後要拿去幹嘛。

可以看出 Euler 試圖創造出的一個架構，是每個 Vault 各自為政，但彼此之間可能存在信任關係（可以上圖中的 USDC Vault 一定要信任 ETH Vault 不能把裡面的 ETH 隨便就拿走）。這必須仰賴一個統一高效的溝通介面，並需要一個 Vault 信任另一個 Vault ，才能把它底下的資產視為自己的合法抵押品。

Vault 的種類

我們可以透過上面的這個例子，了解一下 Euler 生態中的三種不同的 Vault 種類，它們分別反應了不同的「信任與去中心化」假設：

(1) Escrow Vault：如果有一個 Vault 在沒有設定任何抵押品狀況下，放棄了自己的 ownership，也就是再也無法被更改的話，它就能夠成為一種特殊的 Escrow Vault：它只負責 hold 這個資產，並被其他 Vault 當抵押品使用。例如，上例中的 ETH Vault 如果沒有了管理者的話，就會變成一個 Escrow Vault。

這樣的 Vault 資產沒辦法被借出去，因此無法產生利息（沒有 APY），但也完全不用擔心會因為清算等問題出現壞帳。如果上圖中的 ETH Vault 成為一個 escrow vault 的話，理論上 USDC Vault 對它就不需要有信任假設：裡面存了的 ETH 就會一直待在裡面。

(2) Governed Vault：大部分的 Vault 都預設是這個種類，有管理者地址 ，可以有權更改借貸參數。上述的 ETH Vault 如果有管理者，管理者就有可能未來啟用一些抵押品，把它從一個抵押品 Vault 變成一個市場：例如若是啟用了 USDC Vault 當抵押品的話，存在裡面的 ETH 就能夠被借出，並開始有利息。

(3) Ungoverned Vault: 除了上面討論的 ETH Vault 可以放棄所有權以外，其實 USDC Vault 跟 DAI Vault 也可以放棄自己的管理權，成為一個再也無法被改變的 Vault，那他就注定這輩子只能使用之前設定的抵押品跟參數出借自己的資產。因此 Euler 其實也可以用來部署完全去中心化的借貸市場！

Vault 之間的信任關係

上面的例子中可以看到：USDC Vault 允許自己的用戶用 ETH Vault 或 DAI Vault 當作抵押品來借出資產。但這代表怎麼樣的信任關係呢？

我們可以設身處地把自己當作一個 Vault，因為我可以自己定義 LLTV （一塊錢的抵押品能借多少錢）以及 Oracle，所以借錢條款和定價是自己可控的，真正需要的信任的在於資產本身。但這裡的「資產信任」又有兩層意義：

• 第一層是單純的「這個 Vault 管理什麼資產？」上面的這個例子中，可以簡單理解為 USDC Vault 相信 ETH 跟 DAI，願意拿這兩個資產當抵押品就借出自己的錢。
• 第二層則是「這個 Vault 底下又相信了哪些 Vaults ？」假如上圖中的關係變成下圖： DAI Vault 信任了 stETH Vault，那 USDC Vault 若是想要接受 DAI Vault 作為抵押品，它就等於也間接接受了 stETH 的資產風險，以及相信 DAI Vault 設定的清算參數能夠安全保護市場沒有壞帳。

今天若是 USDC Vault 用 DAI Vault 當作抵押品，但是 DAI 的借貸市場發生問題：例如有 stETH 突然大跌價，DAI 市場出現大量壞帳，那可以想像這時候被 USDC Vault 拿來當抵押品的 DAI Vault share 就跌價了（DAI Vault 裡實際上已經沒有那麼多 DAI 了）， USDC 這邊的市場也會受牽連。因此在信任一個 Vault 的時候，也等於要相信它底下關聯到的 Vaults，以及它的管理者與他設定的參數。

Cluster 的特性

因為上述的「信任」關係存在，一般比較保守的 Vault 可能只會使用 Escrow Vault 作為合法的抵押品（只需要信任資產本身），然後在通常在管理者相同的狀況下，能會再互相成為抵押品。這也是為什麼在 Euler 容易形成 cluster （叢集）的特性：在一群 Vault 中，每個 Vault 之間都同時是彼此直接信任的抵押品。

會有這個現象很符合直覺：如果一個 Vault 對另一個 Vault 有間接有曝險了，那還不如就直接當作合法的抵押品，增加使用者使用的靈活度。例如上圖中最上方的的 USDC Lending Vault，就算它不允許使用者直接用 stETH Lending Vault 當抵押品，今天 stETH Vault 出問題，仍然會影響 DAI, ETH Vault 然後間接影響到自己，所以還不如直接信任了唄。

在 Euler 官方平台中，這樣一群互相信任、且由同一個單位掌管的叢集會被稱為一個 Marketplace。現在最大的一個系列就是 Euler Prime 系列，應該佔了總共存款量的 90%。

Vault 之間的堆疊性

上述例子中，我們可以看出另一個有趣的點：每個 Vault 都可以透過設定自己合約裡面的參數，單方面的啟用另一個 Vault 作為抵押品。這就好像每個協議都可以自由使用其他 ERC20 一樣，很容易可以看出這個疊加的效果。

當有了第一層的 “Vault Cluster” 後，之後出現的 Vault 便可以再使用這個群 Vault 作為抵押品，再加上更多抵押品種類，繼續往上開闢更多借貸市場。越往上層，其抵押品的曝險就會越複雜，管理難度也會越來越大。

到底是 Vault 還是 Market 還是 Asset

這就是 Euler 協議中如何拼湊出各種奇形怪狀的生態系的邏輯，這種複雜的關係固然有變化性，但我也認為這是 Euler 第一個十分令人混淆的地方：每個單位都是一個 (E)Vault：如果它不開放借出，它就只是一個抵押品，容易被當成一個單純的「資產」；但若是它可以被借出，就是一個市場（你也可以理解成為一個會有利息收益的資產）。

所以在形容這個最小單位時，我覺得用「資產」或是「市場」來形容都有點奇怪。在 Euler 官方平台的語言中，他們還是將可以借出的 Vault 都形容為 市場（Market），也嘗試用簡單的語言在解釋市場的抵押品有哪些；我們以 Euler Prime USDC Vault 為例：官方平台中可以看到這個「市場」的利率、種類等等，貌似一個單純的借貸平台。

但一滑到 “Collateral Exposure” 的地方就比較反直覺，乍看之下有重複的代幣被列為不同抵押品。這就是因為其實這個市場用了多種不同的 Vault 當作抵押品，除了最純的資產（Escrow Vault）以外，他們也用了其他 Prime Vault 做為抵押品，如果是 wstETH Escrow Vault 跟 wstETH Prime Vault 實際上就是兩種抵押品，並且被設定了不同的 LLTV 參數。

Euler Explorer

如果想要精準解析的了解各個 Vault 之間的關係，推薦用一個叫做 Euler Explorer 的網站。我這裡一樣截一張 USDC Prime Vault 的圖給大家看看，也歡迎大家自己玩玩看：

這裡用圖表呈現一個 Vault 底下所連到的所有 “Collateral Vault”，一直到最底層的 Escrow Vault，有線就代表有直接允許做抵押的關聯，也可以想像就是有「曝險關係」。透過這樣的圖很容易可以看出我們上面說到的兩個特性：(1) 叢集：一大群密密麻麻連再一起的通常就是同一個 Cluster；(2) 堆疊性，能夠看出不同叢集之間的階層性：比較 degen 的 Vault 可以再把所有的 Primve Vaults 都當成自己的抵押品，在最高處「指向」所有的 Vault。

Vault 設計的好處

講了這麼多 Vaults 組合，現在來提幾個有趣的點：

疊疊樂

會這樣設計我覺得有很大的原因來自 Vaults 之間的堆疊能力：一個 Vault 可以單方面的允許另一個 Vault 作為自己的抵押品，也就是說我們可以不停的在現有「有息資產」上又增加使用情境（再去借錢）。（補充: Kevin Lin 同學的比喻：就像 ETF 們的 ETF）。

Euler 的官方 Blog 中有這麼一張圖，大概說明了他們希望這樣設計能帶來的正向循環：別的市場可以「簡單地使用 Vault」，能夠輕鬆的增加一個 Vault 的 utility，理論上就能吸引更多的人把錢存進來。

我認為這樣的設計也不難看出 Euler 對於資金利用率這件事的注重：一筆 supplier 存進來的流動性，儘管已經被借走了，他們還是透過協議在鼓勵其他人把這個代幣化的倉位（vault token）再疊為第二層的借貸市場，等於又可以把這個倉位當成抵押品去借錢。

這件事情其實就是 DeFi 很愛玩的套娃遊戲。例如 Aave aToken 你可以在拿到別的協議去借錢。但 Euler 就是希望大家還是用他們框架不斷的發行新的市場，這樣也不用用別人家的協議去借錢了，直接來我上面再開一個 Vault，把他跟原本某個 Vault 連在一起，就達到了這個目的。

1-to-1 Market

Euler 還可以做一件很酷的事情，就是開放只有兩個資產，彼此互為抵押的借貸市場。例如 Alice 想要槓多 ETH，Bob 想要空 ETH，他們都只信任 ETH 跟 DAI 兩種資產，就可以成立一個 ETH <> DAI 的市場來滿足各自需求：Alice 存了 ETH，借出 DAI 一直買來做多；Bob 存 DAI 一直借 ETH 出來空。這裏最大的好處是他們雙方都不用承擔「任何其他資產」壞掉的風險。這樣一個單純 Dai <> ETH 市場是幾乎找遍現在所有 Protocol 都找不到的。

這樣的使用情境會讓人容易聯想到 Morpho 這種 Isolated Lending 的一對一市場。不過跟 Morpho 比起來，這樣雙方流動性能夠「直接互借」資金利用率會高很多：在 Morpho 這類協議中，Alice 存 ETH 借出 DAI 必須去到一個 ETH-DAI 的市場，她的抵押品 ETH 就待在合約裡不能生利息；而 Bob 必須去另外一個 DAI-ETH 市場，存入 DAI 借出 ETH。 Alice 不能借走 Bob 的錢、Bob 也不能借走 Alice 的錢。

但在 “Monolithic” 的市場中，可以想像如果雙方都借好借滿，Alice 跟 Bob 都是拿走對方存進來的錢，其實最後留在兩個 Vault 合約裡的反而沒有多少錢（沒有閒置資金！利用率很高！）同時雙方在借錢的同時，抵押品都還可以賺利息。

總而言之，Euler 透過 Vault 的設計方式，讓各種不同的 usecase 都能被滿足，無論是一對一，或是多對多，任何形式的 cluster 都可以用這樣的框架來創建。這就是它厲害的地方。

特殊機制

講完了 Vault 的大概之後，就稍微提一下幾個特殊的機制：

清算機制

Euler V1 最引以為傲的設計之一就是它的清算機制：隨著 borrower 的 LTV (Loan to Value) 超過清算線越來越多，提供給清算者的 discount 也會越來越大。這樣理論上是一個較為公平的清算規則，免得給稍微不小心違規一下下的借錢者太大的懲罰，也確保有足夠的誘因來防止大規模的壞帳。用另一個角度想，這也是變相保護使用較「安全」的抵押品借錢的用戶。這個機制將會被沿用到他們的 V2。喜歡數學和微積分的朋友可以看一下他們專門寫的這篇Paper: Dutch Liquidation Analysis，算一下篇微分，從各個角度分析這樣機制的優勢和問題。

預言機 Oracle 的使用

Euler 在 V2 中加入了更多保護借錢者的機制，其中之一是來自預言機的報價方式，在 V2 中預言機需要回報三個價格: ask, mid, bid ，也就是大家容易理解的賣單價、平均還有買單價。一般在評斷倉位的 loan (debt) 時會使用最高的 ask，而抵押品則會用最低的 bid，確保最大程度保護協議沒有壞帳，不過在清算時，會用 mid 價格來計算 loan 的價值，也就是會比 ask price 低一些，這樣能夠保護借出一些流動性可能較低，高波動率資產的 borrower，不會因為 oracle 在特殊情況下的報價很 aggresitve，或是買賣價差很大，就遭到不合理的清算。

Borrow LTV 與 Liquidation LTV

除此之外，每個資產其實都有兩個 LTV：Borrow LTV 是用來衡量新的借貸倉位是否合法、Liquidation LTV 被用在清算上，這有點像是期貨或選擇權市場的 IM(Initial Margin) 跟 MM(Maintenance Margin)，中間能夠預留一個 buffer，可以讓用戶來得及「補錢」以避免清算，但在這個 buffer 間不能做使曝險加大的操作。

LTV Ramping

考慮到現在 EulerV2 開放大家都來開設並管理 Vault （市場），又要讓用戶放心使用所有 Vaults， 就必須要有讓 borrower 應對 Vault 各種管理者狀況的自我保護機制。

在 Vault governor 可以做的操作中，最重要的就是更動一個 Collateral Vault 的 LTV 參數。假如今天有個壞人開了一個 Vault，原本設定 LTV 90% 才會被清算，今天突然降低到 50%（原本 $100 可以借 $90，突然改成 $50），這會讓原本倉位 LTV 處於 50% — 90% 的用戶突然之間變得可以被清算。再考慮到上面提的清算機制：離清算線越遠、被清算的 bounty 越高，根本變相鼓勵這些管理者做壞事；但協議也不能不允許調低參數，否則一個正派的管理者無法在危急時刻透過調整參數確保市場沒有壞帳。為此，他們設計了這個 LTV Ramping 的機制：

在 Max LTV 被改動之後，這個改動不會馬上被 apply 到「清算 LTV」上，而是只會馬上影響到 Borrow LTV：這代表要開新倉位的同學們必須要馬上適用新的 max LTV，但如果你本來就借了， Liquidation LTV 會慢慢下降，這樣的好處有兩個：第一是有時間來補齊自己的抵押品，第二是假如我還是被清算了，至少清算所用的 LTV 會是比較高的 max LTV，所以處罰會比較少。

假設我的倉位 LTV 是 80%，原本 max LTV （清算線）是 90%，今天被降低到 60%，透過這個機制，如果我最終還是被清算，協議會把用 maxLTV = 79.99% 來算我的清算 penalty，所以等於我只是稍稍越線而已，而不是用 60% 來算。

每個 Vault 都可以自己設定冷卻時間這些參數，因此存款者可以看這些參數來決定是否要相信一個 Vault。

Hook

最後來講一個 2024 年合約一定要設計的東西: hook。單看 Euler 的市場架構我們可以很容易的看出 hook 的好處：由於每個 Vault 有完全的自主性，可以透過 hook 來對借貸雙方做一些限制，例如加個黑名單所以可以比較符合監管條件、加個「AI hack detection 自動 pause 合約」的保護機制等等。

除了這些基本招之外，Euler 還已經開發了一套 Synth 合約，使用 hook 來改變 EVault 「可以接受大家存錢」的屬性、配合一個特殊的 ERC20，就可以做到類似 CDP stablecoin 的效果，發行像 Aave GHO 穩定幣或 DAI 一樣。不過細節我們就下篇再討論。

小結

看到這裡，大概就是 Euler 的初步介紹：他們利用什麼方式做到足夠「模組化」的組合不同種類的 monolithic markets。如果有興趣的話，可以延伸看看下面這篇比較文，在裡面我對於兩種設計的特性有更完整的比較、並分享背後的底層邏輯。

透過機制設計看協議核心價值

這篇講了比較大方向的設計框架以及特性，我有空會整理專門針對 EulerV2 的下篇，更深入看 Euler 合約層到底還隱藏了什麼樣的功能、有什麼可拓展性，哪些是公共財，又有哪些可以偷抄。那就一起期待吧！

Euler V2 介紹 — (上) was originally published in DeFi 燒酒螺 on Medium, where people are continuing the conversation by highlighting and responding to this story.

前言

過去這一年，個人覺得 DeFi 世界沒有太特別的創新，但相對的處於一個非常實際的重建期：許多高品質的團隊開始用新的工程方法，更安全、高效率的方式，重新撰寫、部署許多 DeFi 的基礎設施，也出現不少完全去中心化的公共財。

Morpho 是這之中最經典的一個案例。今天就介紹一下他們是如何把複雜的借貸協議，拆解成簡單的小模組，最大化安全性與可重複使用性。對 DeFi 或是 Solidity 不太熟的人，我也非常推薦用 Morpho 作為入門，學習如何用簡潔的方法實作出實用的合約。

前情提要：借貸平台

借貸平台的核心可以很簡單的用兩群人來解釋：Supplier 想要把資產借出去賺取利息；Borrower 想要抵押資產 A 、借入資產 B，支付利息給 supplier 的同時， 換取彈性組合自己資產組合的機會。

比較老一派的借貸協議如 Aave 或是 Compound ，都是強調整個 protocol 就是一個很大的借貸市場：supplier 只需要選擇自己想要借出的資產，就可以很輕易的存款收利息。以 Aave 與 USDC 為例，用戶只要選擇借出 USDC，借出後會收到名為 aUSDC 的 interest bearing token，並不用去在意背後到底有什麼抵押品 (collateral)，或是各個抵押品的清算參數等等，因為這些所謂的風險管理都被 DAO 解決了，這也是為什麼 Aave Governance 常常有在更改參數、增加或是移除抵押品的投票。

Morpho 的核心概念

Morpho 的根本邏輯上有很大的差異：它是一個真正去中心化的協議，任何人都可以來上面開創任意 toke pair 的借貸市場。

一般 supplier 會與 Morpho 互動的最小單位被稱為 “vault”。Morpho 團隊並沒有推出任何的官方 vault，而是盡量的找不同的人或單位來建立並管理不同的 vault，來滿足不同 supplier 的需求。也就是說：身為一個 supplier，並不是決定把錢丟到 Morpho 就好，你還必須從眾多的 vault 中選擇你最尬意的。這讓 Morpho 處於一個很有趣的位置，他們不是直接決定用戶需要什麼市場的人，而把這些事情交給其他人 (vault curator）來決定。

上面提到的 vault，是面對一個一般 supplier 的單位。實際上一個 vault 又由多個 markets 來組成。下面我們將會從下而上介紹 market 與 vault 兩個重要元件，還有他們之間的關係。

Morpho Market (MorphoBlue) / 市場

在 Morpho 協議的最底層，是一個個相互獨立、不可改動、也沒有任何所有權概念的 markets （合約上被稱為 MorphoBlue）。市場一旦被創建出來就無法更改，而且允許任何人使用任意一組 ERC20 的 token pair，以及使用任意的 oracle 來創建 markets。

創建 Market

MorphoBlue 是一個 singleton contract，所有個別的 market 並不是新建立的合約，而是全部存在同一個合約地址，因此創建一個市場非常便宜（目前的 gas 可能只要幾塊美金）、並且能夠內建 flashloan 的功能，讓人能在一筆交易內借走所有 supplier 存在 MorphoBlue 裡面的錢。

創建一個市場需要的參數如下：

• collateral: 抵押品 ERC20
• loan: 被借貸的 ERC20
• oracle：預言機地址
• lltv* (liquidation loan to value)： 一個 borrower 借出總價值 / 抵押品總價高於這個比例時將被清算。
• irmModel* (Interest Rate Model)：決定利率變化邏輯的合約

上述的參數中，前三者如前面所說，並沒有任何限制；後面兩個參數則限制只能使用 governance 投票通過的 lltv 值以及 irm 合約。

當一個 market 被創建出來後，其實它就已經可以實現一個簡單借貸市場的功能了： 例如一個 USDC — ETH 的 market，supplier 可以直接存入 USDC 賺取利息、 borrower 則需存入超額 ETH 做抵押品，借款並支付利息。如果有任何 borrower 的倉位處於危險狀態，將會有 liquidator 來幫忙清算。

Liquidation

Morpho 的清算機制相對單純，並沒有任何拍賣類型的設計，而是單純固定價格先搶先贏：在一個 borrower underwater 的時候，liquidator 可以幫忙償還部分 debt，獲得價值較高的抵押品。

其中每個 market 會有一個固定的 LIF (Liquidation Incentive Factor), 由 lltv 決定。Liquidator 能拿到的抵押品就是代償還 loan 價值 * LIF：

關於 cursor 這個值的解釋，可以想像是對 liquidator 的 incentive factor，越高越有效率、但越有可能有壞帳：

在 cursor = 0 的時候 LIF = 1（還一塊錢 loan 拿到等值 collateral）很好理解就是 liquidator 沒有什麼動機幫忙清算倉位，但是最大程度保護 borrower 被清算時的資產損失； cursor = 1 的時候， LIF = 1 / lltv，假如一個 market 的 lltv = 0.9，則其 LIF = 1.11。而這個市場中一個倉位可以被清算代表它的 loan to value 已經大於 0.9，例如 0.91，這時候 liquidator 每還一塊錢的 loan，合約要付他 1.11 元的 collateral，最終這個清算就會有壞帳發生（抵押品不夠還）。

可以看出若把 cursor 設為 1，「理論上」會是最有效率清算機制的極值，但在區塊鏈上這不合理，因為 oracle 更新並非連續，只要更新後第一個瞬間，某個 borrower 的倉位 LTV 就「高於」 LLTV ，那麼這個倉位就一定會留下壞帳。因此合理的 cursor 一定是一個介於 0 到 1 之間的數字。

最後整個 MorphoBlue 協議選擇的參數為 0.3，可以理解為較保守、保護 borrower 較多，要冒的風險就是在 oracle 報價不準時，可能無法即時給出有足夠的清算誘因。我認為這樣的選擇還算合理的，因為 MEV 市場競爭很激烈，可以假設就算利潤薄弱也不會有人放過。

能做這樣的設計其實非常仰賴「一個 market 只由一個 loan asset 與 collateral asset 組成」這件事，正是因為 market 非常單純，這使得定價賣單一抵押品這件事情變得可行。如果一個 protocol 想要一次拍賣一卡車不同種類的抵押品，或是允許一個 borrower 一次有很多的 loan position，那實際上就很難直接透過這種直接靠 oracle 定價的方式來清算，所以大多會仰賴拍賣，那就會是更複雜的設計。

Gasless Authentication

這裡想要稍微提一個很有潛力的小設計：在 MorphoBlue 程式碼中有一個叫做 setAuthorizationWithSig 的函示，讓一個 EOA 可以透過一個簽名，來授權別的地址代為操作自己的倉位。這代表其實開發者可以去開發一些第三方合約，通過授權去做一些代管、代操作的服務。

小小結：Market 是最簡化的基本借貸單位

看到這裡，應該已經對於 market 有基本的認識，基本上就是一個非常小、功能有限的借貸市場。它的功能僅限於讓 supplier 借錢給單一抵押品市場、以及讓 borrower 放入一種資產並借出另一種資產。

這顯然是不夠的，因此就需要 vault 還有 allocator 來幫忙解決問題了。

P.S. MorphoBlue 合約只有約 500 行的程式碼，（一般人最聞之色變的清算機制也不過短短 50 行），寫得非常的簡潔，並且經過非常嚴密的審計以及 formal verification 驗證，我認為可以稱得上是目前主流 DeFi Infra 中最安全的一份程式碼，非常推薦給想學合約的大家學習。

Morpho Vaults (MetaMorpho)

前面介紹完了 market，其實對於頭腦最清楚，也想要花時間自己管理所有風險的使用者來說已經足夠了。但是大部分的 supplier 可能沒有這些能力，因此我們需要一些聚合工具、以及別的角色來幫助我們完成這個任務。

我們可以回顧一下，過去 DeFi 借貸情境中，有哪些「風險」是一個 DAO 會控制的？其實想來想去不外乎是選擇抵押品以及各種參數：

(1.) 抵押品：什麼樣的抵押品可以借走 supplier 的錢

(2.) 抵押品的 borrow cap：每個抵押品能借走的上限

(3.) 每個抵押品的清算線：不同的抵押品種類，價格相對穩定應該容許比較高的槓桿，例如存 $100 USDC 可以借走 $95 USDT，但存 $100 的 BTC 可能只能借 $80。

在 morpho 的定義裡，這些所謂的管理條件都會被視為不同的市場，所以每當要進行「風險管理時」，理論上在 morpho 的架構下，就需要換存到另外一個市場。例如清算線的改變：一個 USDC-DOGE-lltv-90% 的市場，代表存 DOGE 可以借走 90% 面值的 USDC，如果今天你覺得 DOGE 的風險提高了，你就需要改把自己的 USDC 提出來，轉存到一個新的 lltv-80% 的市場中。這顯然不是一般人會願意做的事情，因此就有了 vault 這個聚合器，再透過 curator 和 allocator 兩個風控小幫手，來幫存款者把倉位搬來搬去。這就是 Morpho Vault （合約上稱為 MetaMorpho）。

Allocator

首先先來介紹兩個風控小幫手。一個 vault 可以有多個 allocator，這些 allocators 有權限把原本存在一個市場的資產轉移到另一個市場。除此之外他們還可以更新 deposit queue & withdraw queue：顧名思義就是「存錢會先存到哪個市場」、以及「領錢從哪個市場開始領」。

Risk Curator

Risk curator 則是一個 vault 的控制者， 除了能設定 allocator（也擁有他們的權力），並能設定每個 market 的 supply 上限。

透過這兩個角色，我們就可以達到上面所說的三大風控種類：透過改變 queue 以及把流動性搬來搬去，我們相當於可以決定 markets，也就可以決定要不要更改抵押品、或是更改每個抵押品的清算線；再加上設定每個市場存款上限的功能，我們能夠調整整個池子的曝險。

ERC4626

值得一提的時，每個 vault 都是專門對一種 loan asset 設計的，也就是只接受存入單一資產。MetaMorpho 支援 ERC4626 的介面，存入之後會給你一個包含的利率的 ERC20 代幣，可以再把這個代幣拿到別的衍伸性金融商品的協議中，賭一些利率什麼的。

Performance Fee

最後再提一下，這些風控小幫手不是做慈善的，因此大多會要求透過 vault 存款的用戶服取一定比例賺取的利息來作為他們的佣金。如果不想付錢的話… 可以往下滑到最後結尾、幫你想好怎麼避開這些 fee 了 😆。

挑戰

大概 Morpho 的核心這樣就介紹完了，接下來我來提幾個，這樣的設計常常被拿出來討論的點。

Liquidity Fragmentation (?)

看到這樣的架構，第一直覺便是流動性分割：本來存到一個 vault 的錢現在反而要再被分散到不同的 markets 中，是不是代表流動性被分散了？

我認為「是也不是」：「是」是因為如果這個世界只有一個 vault，那確實流動性被分散到不同的 market 中，會造成 borrower 很多困擾。

但其實多個不同的 vaults 可以同時 supply 給同一個 market。如果有一個 market 非常的穩定，越來越多的 vault 可能會想存錢到這個 vault 裡，賺取比較穩定的利率。這樣反而讓 borrower 可以在同一個 market 就能借到來自不同 vault 用戶的流動性。

如果我們不只考慮 vaults，那這個優勢可能進一步的擴展：例如有其他智能合約或是 treasury 想要做一個簡單的生利息功能，它可能不想透過 vault，而直接把 USDC 存到一個 market 中去生利息，market 簡潔的設計讓更多協議可能願意做這件事，帶入更大量的流動性。MakerDAO 透過 D3M 的整合就是一個很好的例子。

Multi-Collateral Borrowing

我認為在 morpho 中，borrower 的 UX 會變得比較複雜，但究竟是好是壞可以用不同面向解釋：

以前所有的借貸協議、都有權力去改變 borrower 被清算的條件，部分原因是因為他們允許 borrower 一次放入很多抵押品、用一個 health score 來評量你的總倉位能借出多少錢。為了確保協議安全、在抵押品風險改變時，他們便可以透過改變一些參數、使得 borrower 變得可以被清算。儘管會有額外機制保護、但這終究是一個困難的考量點。

在 Morpho 中，borrower 的動作對象變為永久不可變動的 markets，這意味著你不用擔心任何人能夠改變你的借貸、清算條件。代價是，如果你打算抵押多種抵押品借出資產，你需要自己把不同的抵押品存入不同的 markets，同時自己維繫多個倉位、 rebalance，從這個角度來看便會十分不方便。

Per market risk premiums
這裡也補充一個新的論點：在 Spark 選擇使用 Morpho 的這篇介紹文中，它們提到：在傳統如 Aave v3 的借貸環境中，無論 borrower 拿怎麼樣的抵押品來這個池子裡，都付相同的利息，他們認為這不是很合理，因為不同的抵押品風險不同，若是有 borrower 使用低風險的資產應該只需要付較少的利息。

Rehypothecation

Morpho 最大的一個問題是最底層的抵押品資產利用率。其他很多借貸協議都允許你存入的抵押品同時被別人借走、讓你多收一點利息。但是 morpho 最底層的邏輯上就不允許 collateral 被借出，所以一定會有一些資產是「閒置」在合約中的。

關於這件事情究竟是不是真的重要，可能可以在我們之後介紹 Euler V2 的時候再來詳細展開。

結語: Building Hyperstructures

我記得第一次看到 Morpho 的合約應該就是去年的這個時候，就覺得這就是我一直期待可以看到有人實作的 lending infra。

除了合約乾淨、簡潔這些實作上的細節外，我十分喜歡這種不嘗試做所有事情、但把每個實用的單位拆分乾淨、以最小化為原則開發合約的精神。我認為這是開發合約最好的精神、因為越複雜的東西越容易有安全問題，也越不容易被別人重複利用。

除此之外， Morpho 這個完全去中心化、immtuable、而且最小化 governance 的設計，也完全符合了 Hyperstructure 的精神。

何謂 Hyperstructures?

如果沒有聽過 hyperstructure 這個詞，非常推薦去看 Jacob 大大的原文。我在這裡幫忙把定義抄過來。

Hyperstructures: Crypto protocols that can run for free and forever, without maintenance, interruption or intermediaries.

Jacob 在文章中進一步定義的幾大特性：

• Unstoppable: the protocol cannot be stopped by anyone. It runs for as long as the underlying blockchain exists.
• Free: there is a 0% protocol wide fee and runs exactly at gas cost.
• Valuable: accrues value which is accessible and exitable by the owners.
• Expansive: there are built-in incentives for participants in the protocol.
• Permissionless: universally accessible and censorship resistant. Builders and users cannot be deplatformed.
• Positive sum: it creates a win-win environment for participants to utilize the same infrastrastructure.
• Credibly neutral: the protocol is user-agnostic.

P.S. 原文的另一亮點是 “Valuable” 問題的延伸：這些合約可以擁有 ownership，也可以讓 ownership 有價值、但必須建立在完全不違反去中心化基礎上。一個好的例子就是 fee switch：一個控制開啟 fee switch 的 ownership 是有價值的、但 owner 永遠沒有長期動機開啟 fee switch。

我認為在現在的 DeFi 中，這樣的協議非常稀缺。除了 Uniswap 之外，幾乎沒有看過其他 protocol 符合這樣的條件。在 Morpho 的設計中，可以看出他們不只確保去中心化、也非常有意的在往 minimized governance 的方向靠攏，確保就算哪天就算 owner 變壞人了，這個合約也可以完全以 credibly neutral, 並不斷支援新的 market 的方式運作下去。

也正因如此，我非常的喜歡 Morpho（尤其是 market 的部分），所以前陣子花時間做了一個讓所有人可以直接 supply 到個別市場的工具： MonarchLend.xyz。如果是對於自己管理倉位很有信心的的人，我推薦直接使用這樣的方式 supply to markets，才不會被 vault 抽中間的手續費。未來我也想做一些客製化的功能，利用上面介紹的 authorization 功能，讓大家都可以自己定義想要的 supply 的市場組合、並且用自動化的工具做 rebalacnce。這方面就敬啟期待啦！

簡單漂亮的 Morpho 介紹完了，希望之後可以再介紹複雜大概 100 倍，但是一樣非常去中心化的 Euler V2！

借貸協議 Morpho 簡介 was originally published in DeFi 燒酒螺 on Medium, where people are continuing the conversation by highlighting and responding to this story.

前言

這幾天由於一個跟 AA 相關的 EIP3074 被確認排入下一次 Pectra 硬分叉，因此引起了社群廣泛的討論。Twitter 和一些區塊鏈媒體上都有許多關於 EIP3074 的介紹，但是由於 EIP3074 實際改動有點複雜，也有容易讓人誤解的地方，因此今天希望用這篇文章釐清大家對於這個 EIP 的疑慮。

EIP3074 的主要目的，可以用一句話概括：讓 EOA (externally owned account) 在不需要部署合約錢包 (smart contract wallet) 的情況下，擁有合約錢包的功能。這表示一般錢包用戶能直接「升級」自己的 EOA，就像安裝擴充功能一樣，不需要部署新合約或變更現有的地址。那究竟是怎麼做到的呢？

EIP3074 前的交易流程

大部分的合約在開發時，都仰賴 msg.sender 這個變數來判斷來者何人，即「呼叫此合約的帳戶」。如果有一連串的合約連續呼叫，則每次對外進行呼叫 (CALL)， 接收方收到的 msg.sender 都會更新。

由於合約都仰賴 msg.sender 來判斷呼叫者的身份，因此常常會不知不覺中限制了呼叫者的 UX。如果 Alice 用了一個 EOA (alice.eth) 收取了 ERC20 代幣，那麼她必須要從自己的 EOA 花 eth 發出交易，才能製造出呼叫者 msg.sender = alice.eth 這樣的條件，去呼叫合約進行轉帳。

同樣的原因，加上需要先對代幣合約進行 approve，才能給其他 Dapp 使用，也造成許多交易都必須用 EOA 發起兩筆交易才能完成。

這就最為人詬病的 UX 問題；也是所有 AA 文章都會介紹的兩點：必須要親自用 eth 付手續費、且不能使用批次交易。

在沒有 EIP3074 之前，我們必須仰賴合約錢包來解決這些問題，因為合約錢包能自動幫你打包多筆交易，並且讓別人代付手續費。但這樣的升級不是無痛的，你必須要把所有的資產轉移到你新的合約帳戶中，並且以這個新的合約錢包作為你去收錢、以及做合約互動的主體：

如上圖中，儘管透過一個合約能送多筆交易了，但實際對應用程式合約發送 Call 呼叫的主體從 EOA 變成了紫色的合約錢包，我們被記錄在 Dapp 中的地址也從原本的 alice.eth 變成 smartalice.eth ，是被當作不同的兩個實體。

這樣的解決方法其實很有效，但是對於很多既有的 EOA 用戶來說，遷移EOA 成本很高，不但要找出所有存在不同協議裡的倉位，哪天發現有忘記的錢或是有空投可以領又要大費周章轉 eth 回來付 gas。這或許是到今天為止合約錢包都不普遍的原因之一，畢竟大家剛開始接觸區塊鏈可能不會使用這麼 fancy 的錢包，也不會想要這些比較進階的功能，但使用久了又懶得換了。

EIP3074 的解決方法

如果退一步想，我們使用 msg.sender 是為了驗證發起交易者的身份，那麼其實只要確保 msg.sender 有正當的授權，我們並不一定要強制他一定要是呼叫本合約的「前一個地址」。

對於 EIP3074 很好的解釋方法，就是通過新的 OP code，和一個新的錢包外掛： invoker（調用者）合約，打破既有的 msg.sender 必須來自前一個呼叫地址的限制。一旦我們打破這個限制，我們可以允許客製化的「代理邏輯」寫在 invoker 合約中，創造非常多的變化。

A motivating use case of this EIP is that it allows any EOA to act like a smart contract wallet without deploying a contract.

EIP3074 新的交易流程圖如下：

新的 OP Code

這個 EIP 透過兩個新的 OP code 來做到這個效果： AUTH 與 AUTHCALL 。AUTH 就是授權的步驟，會確認 EOA 的持有者有簽過名，授權 invoker 做出代理呼叫，接著合約如果使用 AUTHCALL 取代 CALL ，則對外呼叫時 msg.sender 即可以被覆寫為 EOA 簽名者。

註：這個 EIP 剛提出時，其實只有一個 OP code，就是 AUTHCALL ，並且直接對著要對外呼叫的內容 (calldata) 進行簽章，相當於每個對外的授權呼叫就要簽名一次。但後考慮到 invoker 一個很大的使用情境是來幫大家做批次交易，如果每次對做 AUTHCALL 都要驗一次簽章，將會代表用戶如果要批次做多筆交易，就要簽名多次，體驗不是很好。因此後來轉向給予 invoker 最大的靈活度，把一個 OPCode 分成兩個階段，只要在同一個 call frame 中 AUTH 過一次，就可以做多次的 AUTHCALL 。

執得注意的 EIP 細節

Invoker 的角色

這個 EIP 在第一眼看到時，看起來非常的可怕，畢竟「允許合約代表我的 EOA」聽起來是一個潘朵拉的盒子，將引來無盡災禍。但我認為這是因為我們平時在理解合約的時候，會時常聯想到一些 DeFi Protocol，他們通常可升級、有一些信任假設，並且常常被 hacked。這些都讓我們不信任智能合約。因此很多人對於這個 EIP 的質疑，來自合約的安全性。

但我自己認為一個比較好理解方式，是把 invoker 當作錢包的一部分，而非是一個傳統的合約。換句話說，上述這兩個 Opcode 不應該被任何 DeFi protocol 使用，相反的，他們只應該被新的錢包外掛使用。

未來錢包跟 invoker 將會有一層信任關係：錢包方會自己開發 invoker、或使用開源並經過審計的 invoker，並且僅允許用戶使用他們審核過、並且相信的 invoker。我們未來對錢包商的信任基礎，也會包含這些 invoker，有點像是選用合約錢包時一樣，把它歸為整體錢包的一部分。

簽章內容

前面有提到，原本這個提案是主張一個 AUTHCALL 簽一次名，不過在決定分成兩個階段後的一個重要精神，就是把大部分可以由 invoker 做到的工作都交給 invoker，因此用戶所須簽的訊息只包含了以下幾點：

1. type byte (0x04)：為了確保不同種類的簽名結果不被別人亂用，以太坊上的簽章系統都會有一個特有的前綴。例如一般交易、signed message，EIP1559 都有不同的前綴。
2. chain id：目前的鏈 id
3. nonce：EOA 目前交易的計數（同一般交易所需要附帶的 nonce）
4. invoker：將會使用 AUTHCALL 的合約地址
5. commit：32 bytes，通常拿來放 invoker 客製化邏輯中，需要確認使用者有簽名確認的資訊 hash 結果。例如有個 invoker 的驗證邏輯是確保用戶有對 AUTHCALL 的 calldata 簽章，這個 invoker 就需要在合約的驗證流程中，自己把呼叫者丟進來的 calldata 都 hash 起來，看這樣能不能驗過簽章。

這個簽章內容其實還沒有蓋棺定論：其中比較有爭議的是 chainId 以及 nonce。其實一開始作者們是期望把所有東西都拿掉，只剩下 type, invoker, 以及 commit，這樣就把所有的實作空間都留給不同的 invoker 合約。但這樣的提案被 core devs 回饋有風險太多：

(1). 關於 chainId

沒有 chainId可能允許跨鏈的重送攻擊：如果有兩條 EVM chain 同時支援 EIP3074，那麼可能有用戶在第一條鏈上授權一個 invoker，該簽名卻被拿到另一條鏈上，被使用在一個同地址，卻不同實做的合約中，那麼用戶在第二條鏈上的資產就會有危險。

補充：理論上用 CREATE2 deployer 來部署 invoker 可以解決這個問題，因為這個問題的主要風險是來自在不同鏈上，同個地址可以存在不同合約。例如我用一個簡單的私鑰部署一個看似正當且去中心化的 invoker 到主網上，地址為 0xaaabbb，我等大家簽了 EIP3074 授權之後，再到 Arbitrum 上面在一樣的 0xaaabbb 地址部署一個可以對外做任何呼叫且沒有驗證的 invoker，那我這個壞人就可以偷走你在 Arbitrum 鏈上的 EOA 控制權。

要如何用 CREATE2 deployer 解決這個問題呢？因為 CREATE2 這個 Op code會強制一定要部署一樣的合約程式碼及一樣的 salt（亂數），才有辦法部署出一樣的地址。因此透過通用的 CREATE2 Deployer 部署出來的合約，你可以相信這個地址要嘛在其他鏈上不存在合約，如果存在，則合約內容一定跟主網一樣。

這裡列幾個常見的 CREATE2 Deployer，連結到他們的 repo 或是 etherscan:

• Seaport keyless CREATE2
• Deterministic-deployment-proxy
• Safe-singleton-factory

(2). 關於 nonce

沒有 nonce 則是可能允許 invoker 拿到無法撤銷的授權：假如今天一個 invoker 忘了實作簽章不能被重複使用的邏輯 (replay protection)，有可能造成壞人能無限制的使用一個用戶同個簽名發起多次 AUTHCALL 。如果保留這個 nonce 的驗證，用戶在任何時候只要發起一筆普通交易，就可以讓所有現在在外面的簽章無效化，過程大概是：

假設一個 EOA 現在 nonce 是 10 => 他的主人可以做一筆簡單的以太坊交易，例如轉帳給自己 => 以太坊紀錄的 EOA nonce 會增加 1 變成 11 => 之後驗證 AUTHCALL 都會使用 nonce = 11 來驗章，造成之前簽的簽章無效化。

這裡牽扯到的問題是，到底這個 EIP 要給 invoker 多大的自由與彈性：沒有了 chainId 的限制，invoker 可以透過多鏈部署，讓用戶享有「一個簽章、全部 EVM chain 都升級」的功能；而沒有 nonce 的限制的話，能夠讓錢包設計 invoker 跟 EOA 能同步做交易，做到更多自動化。

目前這些細節都還在討論中，以提案的現有狀況來說，作者 (SamWilsn) 其實也是偏好開放最大自由度的，但 core dev 的立場比較偏好不要一次加入太多的 attack vector，因此 nonce 跟 chainId 目前還是暫時被加回了需要簽章的資訊中。

重送攻擊的預防實作

儘管上面有說， EOA 交易的nonce 必須涵蓋在簽章中，但這只是為了確保「使用者 100% 可以讓 EIP3074 簽章無效化」，並不限制一個簽章能被用幾次。

這是因為當 AUTH 被使用的時候，他會檢查這個 nonce 是否等於使用者目前 EOA 交易的 nonce ，只要相同就會給過，但並不會更改 EOA 的 nonce ，因此一個簽名是可以被 AUTH 驗證數次的。

Invoker 有義務要自行實作一些重送攻擊的預防邏輯，但是可以有很多變化，另如自己做一個像是 Uniswap Permit2 的 nonce 系統，不要用遞增的方式來確保可以平行送出多筆交易、也可以批次取消等等。

風險與常見誤解

以下列出對於這個 EIP 常見的誤解：

1. EIP3074 讓釣魚詐騙變得更簡單了?

有了這個 EIP 之後，智能合約確實有了透過一個簽章得到 EOA 控制權的能力。但如前面所說的，invoker 應該要跟錢包是一個綁定的關係，錢包應該要拒絕所有不認識的 EIP3074 簽章請求。

由於每種不同的簽章有不同的前綴，目前所有市面上的錢包都會默認拒絕 EIP3074 的代理簽章，因此不用擔心你的錢包不支援讓你被騙。（也沒有任何錢包支援用 private key 盲簽未知交易格式。）

除了錢包方需要主動的去開啟這個功能，大家也並不預期錢包方會接受一個網站「要求簽署 EIP3074」簽章，因為像上面說的，這並不是一個正常的 DAPP 會要求錢包做的事情，因此我們可以預期錢包只會允許啟用他們自己認證過的 Invokers。

這跟釣魚網站不同的點是：錢包本來就會期待來自網站（Dapp 端）的交易請求，因此釣魚網站透過騙你點擊按鈕，傳送「惡意交易請求」給錢包端，如果錢包端沒有好的預防，你可能就會點下簽署交易。而 EIP 3074 的簽章是完全不同的形式，錢包也沒有理由要允許來自網站的「代管私鑰需求」， 因此不用擔心你的錢包會偵測不到。

這裡補上作者之一 lightclient 對此問題的回應。

雖然理論上錢包不該開啟客製 invoker 的功能，但還是有可能有些錢包為了給用戶最大自由度，而提供這個進階選項。如果真的有這樣的錢包，那就可能會出現類似釣魚網站的攻擊了：例如他們做一個很酷的網站告訴你加入 invoker 後能有什麼功能，騙用戶忽略錢包的一些警告而簽章。

2. 無法奪回的錢包控制權

有人在介紹 EIP3074 時寫到，這可能造成用戶一個無法駁回的單次授權，造成所有的控制權喪失。這也是不對的，在目前的 EIP 中，因為簽名內容保有 nonce，任何用戶都可以發交易來讓簽出去的簽章無效化。

若是 nonce 沒有被加入必要簽章格式中，這樣的情境仍然建立在「合約有漏洞」的情況下。在一般合約實作中，讓 nonce 無效化是很簡單的一個步驟功能，也有無數經過驗證的實作方法，除非遇到惡意的 invoker（惡意錢包），否則這方面要出錯的機率很低。

我認為討論這個風險（或是類似的多鏈重送攻擊）就好像討論「合約錢包可能讓你永久失去控制權」一樣，就是在討論合約存在 bug 的風險，考慮到這個問題的複雜度，要防範不會太困難。

潛在的風險

上面說的兩個點：惡意 invoker 釣魚網站，還有 bug 造成的永久喪失控制權，我都覺得不是可行的攻擊。但這個 EIP 確實還是有帶來風險，我認為比較大的風險會在攻擊硬體錢包這塊。

軟體錢包一直都有很大的風險：假如下載了一個假的軟體錢包，把私鑰存進去，那麼你的錢就會直接不見了，因此大家對於軟體錢包 App 已經有比較高的資安意識。但硬體錢包在以前是比較安全的，只要你的硬體不要掉，基本上不可能有人可以從中讀走你的私鑰。

但如果有開源的硬體錢包支援了 EIP3074 簽章，不能排除有人做一些新的 App，同樣去接硬體錢包，並推廣給用戶（例如做一個手機 App 可以跟 Ledger 一起使用）。這些惡意的錢包 App 就可以接著騙你簽一個簽名來獲得私鑰控制權。當然，這個前提也是要先讓你相信這個新的錢包 App 是真的，不過假如他們打著「跟老牌硬體錢包合作」的口號，可能很多用戶會忽略這個風險。或是未來有更多詐騙會嘗試攻擊錢包 App DNS 、騙你下載假的 Ledger App 等等，都能用來偷取既有硬體錢包用戶私鑰控制權。

總體來說，大家只要繼續謹記謹慎選錢包（無論軟硬體），就不會有上述問題。遇到錢包推出新的 invoker 功能時，記得以「審視合約錢包」的安全指標來審視 invoker，也能有效的避免一些 bug 造成的問題。

革新應用

這裡提幾個我覺得很有趣，非常值得期待的應用：

(1) 老地址空投領取器：

現在如果有舊地址收到空投，都需要轉一些 eth 回去當 gas，領了空投後再轉出來，如果有了 EIP3074，就可以用領到的空投代付手續費，直接一個簽名領取空投、付費並且轉到新地址中。或是以前老舊錢包裡的一些殘留 ERC20 也可以拿來付交易手續費。

(2) 簽署對 ENS 的交易：

以前 EOA 交易格式都是簽署轉帳到一個地址，未來可以讓用戶簽署「要轉給哪個 ENS」，透過 invoker 解析出地址再進行轉帳，大大增加轉帳的 UX。

(3) 簽署有到期日的交易：

以前的交易內容沒有到期日這樣的參數，如果你簽出去之後一直沒被 confirm，後面悔改了要手動取消，否則他就會一直處在 pending 狀態。有了 invoker 之後我們可以很輕鬆的加入「超過時間便無效」這種限制，簡單的製造出有到期日的交易格式。

(4) 更多元的錢包代理：

我們可以有更多「代理錢包」的玩法，甚至增加錢包的安全性：使用冷錢包授權不同的地址，指定各個地址只能做特定交易、有不同的到期時間，例如：每一個月用冷錢包授權一次我的 metamask 地址可以為我發起最多 10 筆 Uniswap 交易。這樣對於「私鑰」的安全等級我們可以有更多的彈性，也將不再受到「不同私鑰不能管同筆資產」的限制。

可能帶來的改變

我自己覺得比較宏觀來說，可能對整個市場帶來的改變有幾個：

1. 錢包差異化更大，用戶黏著度更高

以前做錢包的時候，最常想的就是如何留住用戶：畢竟大家私鑰自己存好、隨時想換別的錢包，只要下載安裝導入私鑰，馬上就搬家了。因為大家能做到的事情大同小異，就是發送交易。

未來有了 EIP3074 之後，各家 EVM 錢包 UX 可能會差的越來越多：有的可能單純支援 ERC20 付手續費、進階一點的就會有前述的代理、訂閱制的手續費、批次幫所有用戶一起交易等等。這些都會造成好的錢包跟一般錢包之間的差距放大，也會增加用戶黏稠度。

2. 錢包方可能擁有更大權力（交易排序權）

未來錢包可能在為用戶安排 orderflow 這塊會出現更大的競爭。我們可以越期越來越的用戶會習慣把真正「送出交易」的步驟代理給錢包方，錢包方也可以透過 invoker 做出「只有我能代理上鏈」的交易，相較於傳統交易在曝光到 mempool 後大家 （MEV searcher ) 都可以任意排序，錢包方可能也有動機去限制這些交易的順序，從中獲利。

3. 一般合約可以回歸更基礎的設計流程

以前為了提升 UX，合約設計中會考慮 permit 、multicall，meta-transaction, wrap ETH 等等。我一直很希望 AA 時代快點到來，就是因為覺得這些東西如果不需要在 protocol 層考慮，可以減少很多安全疑慮，例如完全讓錢包端處理 Wrap ETH 可以確保一個 protocol 完全不需要考慮 eth 的轉帳以及重入風險。這個 EIP 我覺得可以期望看到現有的錢包商如 Metamsk, Rabby 都馬上投入 invoker 的開發，大大增加了普及批次交易的機會，如果未來批次交易普及，就能省去很多這方面的合約優化。（不用每個人的合約都繼承 MultiCall 也是幫整個網路省空間吧！）

4. 對合約使用 msg.sender 與 tx.origin 的影響

最後一個講的比較細節，跟合約開發者相關的議題。

合約常常會使用 msg.sender == tx.origin 來做不同的限制。在 EIP3074 之後，使用者可以使用特別的 EIP3074 交易繞過這個檢查：最初發出交易的人(tx.origin) 可以透過一個中繼合約來做 AUTHCALL，同時附上自己的簽名，因此可以做到從中繼合約打出去的 AUTHCALL ，然後仍然符合 msg.sender == tx.origin 的條件。

大部分合約使用 msg.sender == tx.origin 的檢查是為了保證 msg.sender 為EOA，免得送 ETH 回去的時候觸發重入攻擊等。這個特性依然沒有改變，因為 tx.origin 必定是一個 EOA， msg.sender 也會指向最一開始的發起者，不用擔心不小心跟中繼合約互動，造成意想不到的後果。

不過這個 EIP 還是會影響到一些 usecase，例如用 tx.origin == msg.sender 來防止「合約依照一筆交易的狀態來控制後續交易的行為」。例如有人用合約 mint NFT，只要沒有成功 mint 出稀有的 NFT，就把整筆交易 revert 掉。但這個 usecase 其實已經可以透過 MEV 等等手法透過跟 builder 合作來破解了，所以算已經是無效的防護，影響並不大。

另一個會被影響的 usecase，是用同樣的條件來防止 flashloan。以前如果有合約不想被用戶透過 flashloan 使用，可以透過 tx.origin == msg.sender 確定來的人沒有透過 flashloan 借錢。現在發起者可以在 flashloan 借到錢後，透過中繼合約呼叫 AUTHCALL ，對協議方來說，看起來就會是 msg.sender 真的帶著大筆的鈔票來使用這個合約。

理論上，好的合約不應該使用 tx.origin 做任何判斷，因為這會破壞 AA 錢包或 meta-transaction 等體驗，使用 tx.origin也已經被大量推廣為 bad practice。因此儘管這個 EIP 打破了某些使用情境，對整體影響並不大。

結語

我自己十分期待下次升級的到來，畢竟 AA 說了這麼久了，真的看到做出抽象帳戶的錢包屈指可數，也一直沒有等來說好的大量從 EOA 到合約錢包的升級。

我認爲 EIP3074 給予了所有錢包開發商非常大的升級空間，因為大家可以幾乎無痛（不需遷移）的為用戶帶來體感上的大升級。真的很期待真的上線時，各個錢包商能變出什麼新玩法，這裡也小小許願，最後 EIP 可以以不限制 nonce 跟 chainId 的自由之姿進入硬分叉，這樣就有更多跨鏈錢包等等功能可以期待了。

Reference 與推薦讀物

• EIP 原文
• EIP 討論串
• Account Abstraction 抽象帳戶：EIP-3074 與 EIP-4337 簡介

EIP3074 簡介 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

(1) Panoptic 解析（一）：前世今生
(2) Panoptic 解析（二）：協議介紹

前言

在前一篇文章中，我們已經討論了為什麼「持有 “Uniswap LP Position” 就等於做空永續選擇權」，也簡單介紹了一下 Panoptic 存在的理由：即為了打造一個更有效率的 Uniswap LP 借貸市場。

有了這個借貸市場後，原本 Uniswap LP 的角色可以持續作為做空永續選擇權的一方，並把他們的 LP 倉位外借，讓作為對手方的用戶成為「做多」永續選擇權、也就是做多 IL 的一方。

基本角色與交易週期

以下簡單介紹一下最基本的多空雙方運作原理與週期：

XPO Seller

做空 (Short) XPO：原本 Uniswap LP，也是 Uniswap LP 的借方 (lender)

基本上就是原本 Uniswap LP，但是想要賺取更多收益的人，他們可以把他們的 LP Position 外借，收取比單純做 Uniswap LP 更多收益。

一個基本的 Uniswap LP 交易流程圖會如下：

原本一般的 LP 使用的是 Uniswap 官方的 NonFungiblePositionManager 合約（上圖黃色）提供流動性並獲得一個 NFT 作為憑證，但若是想要成為 Panoptic Seller，必需要使用一個新的 SemiFungiblePositionManager 合約來為 Uniswap 提供流動性：並獲得 ERC1155 的代幣作為憑證。ERC1155 的特性是 semi fungible，可以透過不同 token ID 定義多種 subcategory ，且每個 ID 都像 ERC20 一樣是 fungible，所以不同人提供的流動性只要特性相同（如 range 一樣），就是可以互相轉換的。

例如：Alice 想要成為 XPO seller，她可以在 ETH = 2000 的時候，存 2000 個 DAI 跟 1 個 ETH 到 LP contract 中，拿到 2000 個單位的 ERC1155 代幣。在這之後， Alice 就可以把這個 ERC1155 token 放到 Panoptic 的借貸市場上 (下圖中紫色的 Panoptic Pool)，等待其他人來借走。

註：上圖中的 ETH-DAI-R-1900–2100 代幣名稱是亂編的，但想要表達如果是同樣的 range ，可以鑄造一樣可替代代幣。

到這裡，Alice 作為一個空方的任務就做完了，可以想像是把 Uni LP 代幣存到 Panoptic Pool 之後就結束了，如果沒有任何人來媒合這個訂單，他的 Uni LP 就一樣幫他賺取 Uniswap 手續費的收入。

XPO Buyer

做多 (Long) XPO：需要借 Uniswap LP 的人，貸方 (borrower)

有了 Seller 願意借出流動性之後，XPO 買方就可以直接到 Panoptic Pool 借出目標的 ERC1155 token。實際上拿到這個 Uniswap LP Position 後，會由 Panoptic 把這個倉位銷毀，並且 Hold 原本的資產。

例如下圖中：假設 Bob 想要空 1000 個單位的同性質 Uniswap LP Position，他必須先付一筆一次性的佣金給 Panoptic，控制裡面 1000 個單位的 ETH-DAI-R-1900–2100 代幣。這 1000 個單位（也就是原本 Alice 存的總倉位的一半），共值 1000 個 DAI 與 0.5 個 ETH，這一半的流動性會被從 Uniswap 中提出來，以 1000 DAI + 0.5 ETH 的形式被保存在 Panoptic 合約裡。

上述這個過程就算是配對成功，一個多與空 XPO 的交易就形成了。一個注意的是 ERC1155 在這裡扮演的角色，由於是 semi fungible，原本 Alice 存進去的 2000 可以只有一半被 Bob 借走，剩下的就繼續在市場上等待配對。這樣可以解決 ERC721 NFT 時難以媒合的問題。

雙方利潤

在上述交易完成之後，其實狀態變得簡單了：假如只看配對成功的 1000 DAI 跟 0.5 ETH，他們其實變回原本代幣形式 HODL 在 Panoptic 合約裡。我們若回頭想想無常損失（Impermanent Loss）的基本定義，就是把純粹 HODL 兩個資產拿去跟 Uniswap LP 倉位相比的價差，Panoptic 交易邏輯其實就是「假裝 LP Position 還在，實際上買家出擔保品後由合約 HOD」最終買家只要償還賣家原本 LP 倉位的價值就好，也就等於做多 IL。

合約在一個交易達成之後會做以下紀錄：

賣家 (Alice) ：帳上有 1000 單位的 ERC1155：仍然假裝她這 1000 DAI 跟 0.5 ETH 仍然在做 LP，最終可以拿回 LP Position 值的錢 + 應賺手續費。

買家 (Bob) ：貸款 1000 單位的 ERC1155：Bob 要負擔 Alice 本來應該要賺到的手續費（這就是他們所謂的 streaming fee），並且最終要還 1000 單位 ERC1155 對應的資產。

以上面的例子來看：假如今天 ETH 的價格變成了 2100 ，原本 1000 單位的 Uniswap LP 現在應該值 2025 DAI + 0 ETH（超過設定的 upper bound，剛好全部轉換為 DAI），這裡跟純粹持有1000 DAI + 0.5 ETH 的差別，就是 Alice 原本就該吸收的 IL ，也剛好是 Bob 的利潤。

這時候 Bob 可以選擇把倉位關閉，實際上做的事情是，用 2025 DAI 重新鑄造出欠 Alice 的 1000 單位 ERC1155 Token，剩下多餘的錢就會是自己的利潤。此步驟完成後，合約就會回到 Bob 配對前的狀態：由合約持有 2000 單位的 ERC1155 LP Token。

上面的圖略過了一個小細節，就是實際上 Bob 還要從利潤中扣除「理論上 Alice 會賺到的 LP Fee」。這樣最終 Alice 在領錢的時候，就完完全全是拿回在 Uniswap 上面 LP 會賺到的錢，加上訂單配對成功時的權利金。

更多細節

上面的段落介紹了只有買賣雙方的交易邏輯。不過為了讓合約更實用，Panoptic 還加入了 PLP 這個角色，衍伸出來了更多的細節。

PLP (Panoptic Liquidity Provider) 與槓桿

Panoptic 的生態系中還有 PLP 的角色，即為賣方提供流動性來做槓桿，有點像是 gearbox 這樣的借貸市場。這個 PLP 不屬於做多或做空 XPO 的任何一方，單純把資金提供給賣方使用，並收取雙方佣金 (commission)。

對賣方而言，原本需要自己的資金來轉換成 Uniswap LP，可以想像在真正的 Panoptic 合約中，是透過一個 margin account 來開槓桿，只要存一點點的錢，就可以挪用比較多的資金並部署流動性到 Uniswap 中，因此可以有更好的資金效率。每次開空單的時候，賣方都需要付這筆一次性的佣金給 PLP。（P.S. 買方儘管不是直接使用 PLP 資金的一方，在跟賣單配對開倉時，一樣要付一筆佣金。）

在任一時候，Panoptic 都會追蹤 PLP 資金的「利用率」來動態調整賣家可以使用的槓桿大小：假如 Panoptic 合約剩下很多錢，則賣家可以做高用到 5 倍的槓桿。

Streamia (Streaming Premia)

上面有稍微提到，買家需要支付給賣家的權利金，就是「賣家在 Uniswap 上應該賺到的手續費」，不過實際上會多出一點，因為 Panoptic 使用了一個 SpreadMultiplier 來動態調整買家實際上要付權利金加成。這樣可以確保賣家會「賺的比單純去 Uniswap 多」，也以此吸引更多賣家的流動性。

由於他並不是一次性的，而是連續性的一筆 streaming 形式費用，因此在 Panoptic 裡面被稱為 streamia。

強制執行 (Force Exercise)

可以從上面的交易週期介紹中看出：不論一個 XPO 倉位開了多久，買家的成本只有一開始的一筆佣金，還有「能付出 streamia」的抵押品就好。如果買家們不斷的開倉關倉，就會有很多的佣金給 PLP 賺走，但如果一個人開了倉位之後就死不關，那其實就是變相地把錢鎖住了，且無法再造成多的 PLP 佣金收入。

或是我們不管 PLP，單純以賣家「借出」自己 Uniswap LP 的角度來看，也會有類似的問題：假如 Alice 今天不小心選了一個很糟糕的 range，導致她完全沒有任何手續費的收入，那跟他配對的買家也不需要支付任何的 streamia，等於買家一開始付一筆佣金給 PLP 之後，就可以幾乎無成本的繼續鎖著賣家的資產。這都是一些潛在的攻擊手段。

為了解決這個問題，Panoptic 設計了一個強制執行的機制，任何人都可以再付給買家一筆手續費，強制把他的倉位關掉。這確保買家沒有辦法透過永遠不關倉來鎖住大家的錢，但同時也造成買家 UX 上很大的問題（好好的多 XPO 卻隨時可能被平倉 OAO）。

多倉位組合：Multileg Position

上面提到的 SemiFungiblePositionManager 合約，可以支援最多四個不同的 range 的流動性同時被整合成一個倉位。如上面我們的例子中，Alice 提供流動性到 1900–2100 的區間，在 Panoptic 的術語中這就是 short 一個 2000 call。最多可以有四個 long or short position 被組合在一起，這使得可玩的倉位花樣多了很多。

其他想法

對於 Panoptic 這個協議的介紹就差不多到這裡結束了，以下是我的一些想法與覺得可以改進的地方。

跟 Uniswap 的整合

在合約設計上，我覺得綁定 Uniswap 並自己做一個 LP Token Manager 合約是滿聰明的一件事。這個新的 Manager 合約不需要綁定 Panoptic 核心協議設計，可以持續被使用到他們自己的下一個版本。

上一篇文章中我們說到：Panoptic 整個敘事最大的假設，就是 Uniswap 手續費足以帶來如選擇權權利金一樣的收入，我想他們使用 Uniswap ，除了是因為他們可以客製 range 以外，也是因為 Uniswap 有最高的 AMM 交易量，能帶來較高的手續費收益，他們也可以用「賺的一定筆 Uniswap 多」作為吸引 LP 遷移成為 Panoptic 賣家的口號。

對 Uniswap 流動性的影響

我曾經看到有人討論一個有趣的討論，可以分享給大家思考：假如今天所有的 Uniswap 流動性都透過 Panoptic 部署，那會對流動性市場有怎麼樣的影響？

Panoptic 提供了一個「動態調整 AMM 流動性」的媒介：在交易量很低（通常代表波動率很低）的時候，買家有動機要透過 Panoptic 買 XPO ，這可以看成做多波動率，他們這麼做的方法也正好是「減少 AMM 流動性」，因為他們把原本放在 Uniswap 裡面的流動性拿出來了，可能會讓波動率變高。

相反的現在若是交易量很大，應該很多賣家想要來用槓桿賺取手續費，也能透過 Panoptic 將 Uniswap 的資金量增加，降低了每單位流動性的手續費，也可能因而降低市場波動率。

這樣看來，它不但有可能讓 AMM 的「每單位流動性的平均交易量」更穩定，也有可能進一步的藉由「調節 AMM 流動性」，進一步讓資產的波動率受影響，變得更穩定。

產品的包裝以及 Perpetual Option 的敘事

Panoptic 雖然盡了很大的努力在推廣 XPO（或是說把 Uniswap LP 包裝成 XPO），但實際上到底會有多少人會使用 XPO 這個產品呢？我覺得我還是打一個很大的問號。

站在賣方的角度，Panoptic 其實無異於「可用槓桿的 Uniswap LP」，基本上已經被當作高機率賠錢、風險偏高的策略。儘管現在 Uniswap 上還是有大量的 LP，但我相信真的透過 LP 的「做空波動率」性質來賺取收益的人，相較於只是懶得管、想賺空投這種用戶，算是是少數。Panoptic 官方主要的敘事還是針對想要當高頻交易 XPO 賣方的人，並主打槓桿。

我認為若是在賣方的角度可以有別的專案出來以 Panoptic 為底，做主打「更高收益 LP」的產品，其實也是一個可行的路線。由於不少專案必須要在 Uniswap 為自己的代幣提供流動性，就算賠錢還是要做。這些角色其實就有動機使用 Panoptic，不但多一層的收益，也讓用戶多了「買 XPO」的玩法。

站在 XPO 買方的角度，跟傳統選擇權的 theta decay 相比，Panoptic 有機會付相對少的權利金（streamia）獲得很高的槓桿，但也要承擔比較難以預測的風險：例如價格不動但是交易量突然很大，他們的 stremia 支出就會大量增加，或是更直接的風險是上面提到的強制執行，這都會使得買方的使用情境受限。

它究竟是不是借貸市場？

雖說 Panoptic 追根究底，很像是把 Uniswap LP token 放到一個平台上去讓其他人媒合借走，但細心的朋友應該會發現，其實 Panoptic 的設計中並不像一般的借貸市場會有利率，而是都是靠著一次性的佣金。儘管買方需要持續支付稍高一點的權利金 (Streamia) ，但是這是純粹靠 Uniswap 交易狀況定義的變數，跟目前這個「借貸市場」的狀況沒有關係。

如上所述，如果這個借出來的 LP 現在是 out of range 的狀態，買方不需要支付 streamia，他是沒有任何動機要把倉位關閉的。這樣的設計有不少不合理的地方，上面提到的強制執行也是為了解決這個問題的一部分，但透過任何人都可以關閉倉位也製造了很多奇怪的使用限制。

如果回到借貸市場的角度來看，就會覺得這件事情一個更直覺的解決方法，是應該要加入一些利用率的計算：假如現在全部流動性都被借走了，那借走的人應該要持續支付比較高的利息。

當然，聽起好像很合理，但實際上可以想像出很多攻擊手段：例如這個利用率，應該要以每個不同的 range 分開計算還是和在一起計算呢？是否需要每個 tick 都有自己的借貸市場？

我認為一個更全面且健康的權利金支付方法是 Panoptic 急需解決的問題，否則這種「付一次錢可以開無限長的倉位」的做法勢必對買賣雙方到造成很大的限制。

小結

Panoptic 是一個充滿了創新，也充滿了奇怪小設計的協議。從它出道到現在，始終都包裹著一層神秘的面紗，在為所有 DeFi 用戶畫了一塊全新衍伸品大餅的同時，做著一套實際上能增進 Uniswap LP 體驗與效能的事。

我個人希望 Panoptic 未來能夠持續地針對「AMM LP 參與」的問題給出更好的答案。現在的版本其實已經給了一個大綱：透過多一層市場的借貸提供更多人參與 AMM LP 市場的動機。未來如果很多用戶可能心裡想的不是 LP，但卻能在市場最需要的時候，變相透過交易這些波動率衍伸品，達到動態調整流動性的目的，這或許對整個 DeFi 界會有很大的影響力。

Panoptic 解析(二)：協議介紹 was originally published in DeFi 燒酒螺 on Medium, where people are continuing the conversation by highlighting and responding to this story.

前言

Panoptic 在 2022 年發佈白皮書以來，一直算是 DeFi 圈帶著一點神秘光環的明星項目，上個月又公布多融了 7M，預計明年 Q1 要讓 V1 正式上線，也宣布 2025 會有 v2，是大家引頸期盼的下一個新星。大家都知道他們主打要通過 Uniswap v3 搞 options，但是好像很少人真的理解他們到底做了什麼，以及其背後的原理。今天我們一起就來覆盤一下這個神秘項目。

由於篇幅較長，而且有許多需要知道的先備知識以及跟 Protocol 設計沒有直接關係的「存在原理」，因此一共分成上下兩篇來介紹：
(1) Panoptic 解析（一）：前世今生
(2) Panoptic 解析（二）：協議介紹

本篇將會著重在介紹永續選擇權（Perpetual Option）、它與 AMM LP 之間的關係。主要將會解釋為什麼 Panoptic 會存在、會以什麼方式存在，還有他們白皮書提出來的重點假設。

P.S.有時候講買權賣權很容易搞混，以下統一使用英文 Call & Put

Option & Orderbook — 選擇權與訂單簿的關係

在進入 Panoptic 之前，我們先稍微提一個簡單的觀念，就是「訂單」跟「選擇權」間巧妙的關係。

首先我們回歸到一個 call （買權）的定義：持有 call 的人，可以在到期日之前選擇執行，並用行權價格 (strike price) 買到對應資產。例如我買了一個 $1000 ETH call ，我就可以在 ETH 高過 1000 的時候，仍然只用 1000 買到一個以太，所以只要以太漲到高於 1000 ，高出的價差就是賺到的錢。

這其實就相當於我在一個一般交易所中，拿了別人的一個訂單 (order)，然後我可以在任何時候選擇，要不要拿這個訂單給交易所媒合。

因此，如果我可以說服別人給我一個「賣單」，確保我可以用一個 1000 的價格買到一個 eth，其實這就跟我買到 (long) 一個 call option 是一樣的。相反的，在交易所掛一個以太的賣單，就是 short call option。在這個情況下，你設定的訂單失效時間，就是這個 option 的到期日。

因此這裡有一個小小的 takeaway，就是以後你在交易所掛單的時候，要知道這其實等於平白送給市場一個 option，代表你白白損失了一些本來可以收取的權利金！所以千萬不要掛一個長期有效的訂單，否則可能損失的收益比想像中還要高。

Uniswap V3

眾所周知，Uniswap V3 的一大特色就是集中流動性 (Concentrated Liquidity)，大家可以自由決定要在哪個價格區間提供流動性，也就代表你可以把 Uniswap 當作一個訂單簿來使用。唯一不同的是，在 Uniswap 中，提供一個 LP position是沒有到期日的，也就是說這裡「掛的單」是沒有有效期限的。所以，如果掛一般有效期的訂單是賣選擇權，掛一個沒有效期的訂單是不是就是賣「永續選擇權 perpetual option」？

Panoptic 的 CEO Guillaume Lambert 在 Uniswap V3 問世後不久，就寫了下面這篇文章，解釋了我們上面所說的猜想：Uniswap LP 其實跟 short perpetual option 是相同的。（還不確定什麼是 Perpetual option 沒關係，馬上就會說到了）

Uniswap V3 LP Tokens as Perpetual Put and Call Options

這篇文章算是由一個倉位價值（position value）的角度，解釋了上面的關聯性。把這篇文章總結在一張圖裡可以看出：

• 左圖：當我們提供流動性在一個比較寬的 range 時，看得出有一個弧線範圍，我們的 LP position 是由 ETH 與 Dai 組成。這就是我們一般比較常見的 LP position 價值、隨 underlying 變動的圖。
• 右圖：當我們把流動性集中在一個很窄的 range (single tick) 時，一但價格超過某個值，整個 LP position 就變成 Dai，相當於賣掉了原本的 delta 1 asset。這整個價值曲線，就變成經典的 covered call payout。

但別忘了，這個圖像的是 covered call 的 “payout diagram”。傳統上，賣一個 covered call 真正的收益其實是一開始收取的權利金 (premium)，接著在這個選擇權到期的時候，最終價值會收斂到上右圖這個 diagram。在 Uniswap 當 LP 並沒有權利金或到期日等概念，但可以賺取交易的手續費，因此不難猜，這裡暗示的，就是這樣新型態的 perpetual option 中，將會透過「交易手續費」來負擔 short 方的收益。

這篇文章其實沒有涵蓋太多東西，只是用另一個角度解釋我們的猜想 — Uniswap LP 可以當作 perpetual option。

Perpetual Option — 永續選擇權

前面一直提到這個叫 perpetual option 這個東西，這邊稍微展開一下。
其實 perpetual option 是一個傳統金融就存在的商品，簡稱為 XPO，就是永遠沒有到期日的選擇權。換個角度來說，它還是一個需要執行、實物交割的選擇權，只是沒有到期日。理論上一個到期日無限長的選擇權理論上價格是無限大（無法定價），因此無法一開始就預付一個權利金；反之，需要用 streaming 的方法，讓買方不斷的付給賣方錢，這樣才比較合理。

P.S. 傳統金融中定義上並沒有明確的講這種商品怎麼交易，以及權利金怎麼支付，只說通常只有很特定的情況下才會使用到這樣的合約。當買賣雙方決定進行一個 XPO 交易時，他們可能過了 一天，或 20 天、或 50 天就會關倉，也有可能一直等到有一方行權才結算。總之這個「賭注」不像一般選擇權有自動結束的一天。

Paradigm 研究員 Dave White 兩年前跟 SBF 一起發過一篇 Everlasting Option (EO) 的研究，跟它有點類似，但是 EO 是用 perp 與 funding rate 的觀念來詮釋這個衍生品。其中上面說到 streaming 權利金的地方，也改成利用 funding 支付，也沒有所謂的行權這件事了。不過這些跟 Panoptic 就比較沒有關係了，這些用 funding 來做的新衍生品都算是另外一個家族，這裡就不展開，有興趣的可以去看我之前對 Power Perp 的介紹。

Uniswap V3 與 Perpetual Option 的關係

我們再回來說道 Uniswap V3 與 perpetual option 的關係。上面的那篇文章沒有太多內容，但下面這篇文章就有趣了，也更大程度地奠定了 Panoptic 的基礎：

How to Create Perpetual Options in Uniswap v3

我這裡擷取了文章自己總結的 TL;DR 給大家：

Perpetual Options can be deployed right now between any two assets, for any expiration time (not just 1DTE), at any delta (not just ATM), and without the need to deploy an intermediary protocol.

簡單的說：他們找到了一個神奇的公式，讓你可以利用部署不同的 Uniswap LP Price Range，來達到模擬不同「到期時間」以及不同「delta」的 perpetual option 價值曲線的效果。例如：我想要模擬一個還有 45 天到期 (DTE, Days till expiry = 45)，並且 delta = 0.5 的 short call，就可以用它的神奇公式算出 price range。

近一步看一下兩個結論的分析：

(1) 透過選擇 r (tick range)，決定 LP Position 模擬了多少 DTE 的 option

其中兩者的關係像是下圖：左邊是不同的 covered call 價值在 DTE 變動下的變化，最右邊則是自定義的參數 r 變動下 LP Position 的價值變化。

其中 r = √(tH/tL) ，tH, tL 分別是 Tick 的 upper bound 以及 lower bound。 如果 r 值是 1.2，代表一個 range 的上下界差了 1.2²，代表我們要把設定一個 [k / r, k * r] 的 price range。假如 k 是 1000，即為 [833, 1200]。

厲害的是，他發現由 r 我們可以很好地去複製不同到期日的 option pricing，並且可以有一個公式可以把 DTE 對應到 r 上。 我們可以觀察到，右邊在 r = 1 的時候，就是 single tick liquidity，回歸到我們前面講的 “payout diagram”，相當是一個到期時間剩下 0 (DTE = 0) 的選擇權（左圖）；而當 r 越大 （price range 越寬），就相當於 short 一個比較長期的 option。

下面就是這篇文章最重要推導出來的公式：T (到期日）與 rT 之間的關係。

舉一個實際的例子：假如你今天要用 Uniswap LP 模擬一個 45 天後到期的 1000 Short Call, 我們只要把 45 / 365 代進上面的公式的，就可以得到 rT，決定 range 有多寬。假如 rT 的答案是 1.2 ，你接著只要把 K 設定在 1000，就代表你現在只要部署一個 [833, 1200] Range 的 Uniswap LP，就相當於 Short ㄧ個 45 天後到期的 1000 Call。

要注意的是，這裡的公式僅是一個「逼近直」。觀察上圖也可以發現其實兩者沒有完全重合，尤其是離 strike price 越來越越遠的時候，就會越不準。

(2) 可以透過選擇 Strike Price (mid price for the range) 鎖定 delta

後半段講的如何固定一個倉位的 “delta”：假如我不知道我想要的 strike price 是什麼，但是我想要確保這個 position 的 delta 為 0.3 ，那我可以用一條新公式來算，要怎麼決定這個 strike price，也就是我去設定 LP Range 的時候的 K。

有興趣的人可以去這篇文章裡面看一下剩下的例子，也可以直接用這個 Desmos 玩一玩。

P.S. 如果對 delta 不熟，可以看我之前的這篇介紹，我也不知道這裡為什麼特別討論「想要一個特別 delta 」的情境 ，但總之這是一個在選擇權界很常看的指標，在一些情境下可能比直接決定 strike price 還有意義。

上述的結論 (1) 可以算是該文章最重要的結論。但上面的 TLDR 如果有認真看的話，會發現他最後說：Perpetual Options can be deployed right now …. without the need to deploy an intermediary protocol.

如前述，我們直接使用 Uniswap LP，就可以達到 short perpetual option 的效果，這裡更是直接下結論不需要其他的 intermediary protocol。那…. Panoptic 到底還要做啥呢…？

答案是，有不少可以改進的空間，以下就簡易列出兩個「直接使用現有 Uniswap LP Token」會遇到的問題：

1. Long option 不容易: 原則上想要 long option，你要把別人的 LP position (short perpetual option) 借來賣，但現有的 Uniswap LP token 並不是 fungible，等於要遇到剛好有一個買方，想要一個一模一樣大小、執行價的，才有辦法跟賣方「媒合成功」。想要解決這個問題必須要重新設計 Uniswap Liquidity LP。
2. 不支援複雜的選擇權組合（策略）：現有的 LP NFT，只支援一個單純的 short option。這除了不夠酷以外，在資金利用率上有許多限制。

由上面兩點可以發現，其實要做到 perpetual option 交易市場，就是要打造新的 Uniswap LP 借貸市場。這也是 Panoptic 的本體：

改進現有的 Uniswap V3 LP Token，並用它做出資金效率更佳、更好用的借貸市場。

剩下更多 Panoptic 這個協議的詳細介紹，且聽下回分解。

補充：LP Fee 與 Option Premium 的關係

上述的文章證明了 Uniswap LP 以及 covered call 有著非常類似的價值曲線。但若現在 Panoptic 像要說服大家：我們可以直接把 Uniswap V3 LP 當成 short perpetual option，那他的收益（Fee）跟傳統選擇權的權利金 (Premium) 這部分又有什麼關係呢？

Option Pricing vs Theta (θ)

Panoptic 的白皮書中提出：LP 這種一但進入一個範圍就會開始收手續費的 收益，可以想像成一個 short option 隨時間累積的 theta (θ) 價值。

Theta (θ) 的定義是選擇權價格 (V) 對於時間的微分，為的是看出一個倉位隨時間改變，其價格 (V) 的變化。一個 short option 的 θ 為正，代表每過去一個時間單位，如果其他條件都不，則這個倉位是淨賺的。

依照「theta 是 V 對時間微分」定義，把 θ 對時間積分積回來，會變回 V 乍看之下是一件很合理的事情。但如果我們假設 underlying 的價格在這段時間是可以自由變動的，那就有點難證明了。

換句話說，假設一段時間內一個資產可以隨機變動，那直接去加總每個時間點的 θ，還會給我們趨近於 Black-Scholes 原本運算出來的結果嗎？這方面並沒有什麼既有的研究支持，因此，我們無法推論「只要把所有時間點的 θ 加總，就會得到跟 Black-Scholes Pricing 一樣的結果」，也無法解釋直接推論這種 Steaming 收費方式是合理的。唯一能做的，就只有跑模擬了。

模擬結果

在本篇 Paper 中有被提出的實驗結果，就是他們用蒙地卡羅模擬來模擬了許多不同的價格曲線，並直接觀察「Uniswap LP 的邏輯累計手續費加總」與「相對應之 Short Option 由 Black-Scholes 定價」之間是否有關聯。

結論是：有相關性（向 Black-Scholes 的結果收斂），但是也有許多例外的狀況。

結論（一）：高度取決於價格路徑 (path-dependent)
這一結論其實不難想像：下圖的灰色部分就是設定好的 LP price range，圖中簡單化出三條不同價格路徑，對應到的不同收益（與 BS, Black-Scholes比較）。其中路徑不同，fee 可能從原本的 0% 變成 500%。

但這其實很廢話，沒有講每條線出現的機率的話，任何倉位都可以這樣形容，因此下一張圖就是讓我們看出到底這樣的定價方式跟 Black-Scholes 重合度多高。

結論（二）：跟 BS 定價「相呼應」
下圖即可翻譯成上面看到的路線出現比例分佈。在模擬過程中，以 7 天到期日舉例，有 33% 的 LP 從頭到尾都沒有收到 Fee，也就是有 33% 的路線走出來的結果是上面的綠色路徑（也就是下圖最左邊）。

這樣的分布顯示，路徑發生機率並沒有特別趨向集中在 100% of BS Price，也就是沒有與 BS 的定價吻合。但這就是每個人可以自行解釋的地方了，也可以解釋成 100% BS 滿接近上圖的分佈高峰點。以下是白皮書自己的結論：

Interestingly, the result does converge to the Black-Scholes price, but the distribution of option price can be quite large

不過，這也不代表用 LP Fee 作為權利金就很不合理，因為其實大家都知道 Black-Scholes 方程式是有問題的，否則也不會再選擇權世界出現這麼多定價定不準的問題。

小結

這裡一起總結一下 TL;DR

1. 上述的 Paper 可以證明，Uniswap V3 LP 可以很好的復刻 short perpetual option position 的收益曲線（但當然無法完全複製）。透過改變不同的 tick range，其實就等於開不同 DTE 的 perpetual option。
2. 這代表我們只要能夠更有效做 uniswap V3 LP 借貸，就可以打到打造完整的永續選擇權交易市場。
3. 利用 Uniswap V3 打造出的 Perpetual Option，其中的 premium (權利金) 將透過交易手續費來補償。這方面模擬的結果到底有沒有說服你這個方式的合理性，可以自行下結論

以上就是關於 Panoptic 的前情提要，大概解釋了 Panoptic 作為一個協議是什麼，還有他要被稱為新的「Option AMM」其中隱含了哪些假設。希望大家看完這篇文章，對於 Oracle-less Option Protocol / AMM 這種 Buzz word 具備了一定的判斷能力，可以看懂他到底有多像 option 了！

更多關於他的設計細節，以及我對於 Panoptic 整體的評價，會放在下一篇文章裡。那我們就幾週後見啦！

Reference

• Investopedia: perpetual option
• Panoptic Docs
• Panoptic Whitepaper
• Guillaume Lambert: How to create Perpetual Option with Uniswap V3
• Joseph Clark : The Replicating Portfolio of a Constant Product Market with Bounded Liquidity

Panoptic 解析 (一)：前世今生 was originally published in DeFi 燒酒螺 on Medium, where people are continuing the conversation by highlighting and responding to this story.

從使用者角度，看 ERC4337 對合約錢包帶來的變化

特別感謝 Cyan Ho, NIC Lin, ChiHaoLu, Chang-Wu Chen 幫忙 review！

前言

抽象帳戶 (Account Abstraction)，俗稱 AA 錢包，可能是以太坊想要解決的大問題中，最古老的問題之一了。有在追蹤台北以太坊期刊的各位，對於抽象帳戶的概念或許已經滾瓜爛熟，其中一定聽過大名鼎鼎、由 V 神主導提案的 ERC4337。

但我個人認為，大部分關於 ERC4337 的介紹對於一般大眾並不是很好理解，因為一般人並不了解「以太坊中帳戶的定義」，我們在意的只有錢包以及交易流程而已，因此容易混淆 ERC4337 與「用戶體驗問題」之間的相互關係，這在我自己理解的過程中這成為很大的障礙。

因此希望能透過這篇文章，以一般使用者的角度，著墨於 ERC4337 的定位，讓大家以一個錢包使用者的角度，理解這個提案的核心理念、到底規範了什麼、理由為何。最後面也補充了現在有什麼現有的工具已經被實作出來，還有最後我對於整個未來走勢的想法。

如果是對於提案的前因後果十分熟悉，想要直接理解細節的人，推薦直接跳轉到 ChiHaoLu 之前寫過的幾篇介紹，不過也是可以看一下我最後的一些進度更新跟想法啦～

Account Abstraction 抽象帳戶：EIP-3074 與 EIP-4337 簡介

本文將包括以下幾個章節：

• 抽象帳戶 (Account Abstraction) 的各種定義
• ERC 4337 的定位與格局
• ERC 4337 的細節介紹
• 現有專案與進度
• 我的整體感想：問題以及突破方向

正文開始前，先分享一個冷知識：有些人會把 ERC 跟 EIP 當成兩個可以互換的詞，但實際上常常會因為不同的上下文而變換語意。

廣義上來說，所有公開發佈在 EIPs (Ethereum Improvement Proposal) 裏面的提案，都可以拿到一個 EIP 編號，因此任何提案能稱為「EIP」都沒有問題。不過細看會發現每個提案其實都有類別這欄，則再細分為以下4種：Core, Networking, Interface, ERC。其中 Core 指的就是會動到共識層的更新。例如加入新的 OPCode, EIP1559 手續費調整、The Merge 等等，這些提議必須要所有的客戶端同意後，一起安排進入硬分叉的升級。在許多情境下，大家也只會把這類別的提案稱為 EIP。

而 ERC (Ethereum Request for Comment) 則是一些在應用程式層的標準與規範，例如新的 Token 介面、新的 Proxy Pattern。這些提議不需要改動共識層，只要大家共同協商出一個好的標準就可以開始各自實作。

因此，儘管嚴謹上 ERC 屬於 EIP 的一種，但在很多地方我們還是會聽到有人說：「ERC4337 is an ERC not an EIP」這類的話，這是因為許多人習慣用 EIP 來形容核心共識層的改動、而用 ERC 來表示應用層的規範。為了因應大眾，很多人也會開始區分兩個縮寫免得造成混淆，這也是大為什麼許多文章都會使用 ERC4337 而非 EIP4337。

好啦不重要，正文開始：

抽象帳戶 (Account Abstraction) 的定義

關於抽象帳戶的定義，會依照所使用的情境有所不同。我在這裡把它分為兩種：(1) 廣義的定義：從用戶體驗的角度出發，對於一般錢包使用者比較好理解的定義； (2) 狹義的定義：以以太坊為出發點，比較嚴謹的定義。

（想要看這篇文章只要看得懂 (1) 廣義的定義就好 😂）

廣義的 Account Abstraction

在現今的以太坊中，任何人只要安裝一個簡單的錢包，就可以產生一把私鑰，並產生相對應的公鑰，再推導出帳號地址。如此被產生的帳號被稱為 EOA (External Owned Account)，就是透過一把私鑰可以控制的帳號。如果需要進行任何的鏈上交易（轉帳、合約交易等等），都必須要付一筆以太為手續費，交易才會被收入區塊中。

所謂的廣義抽象帳戶，就是優化了現有的使用者體驗中的以下兩個重大問題的解決方法：

1. 簽章方法不彈性：現有的簽名方法被固定為 ECDSA，對一般人來說管理困難或是沒有彈性、無法使用多簽或其他演算法。
2. 付費方式不彈性：所有人產生錢包之後，都一定要先有以太，才有辦法進行第一筆交易，這使得要使用以太坊的門檻大大增加。

基本上解決了這兩個問題的錢包都可以自稱 AA 錢包了，我覺得這也是大家口語上普遍在說「AA」時所隱含的標準。我這篇文章也會用這個 AA 定義，泛指所有達成上述兩個條件的 Solution ，並以這個定義來解釋 ERC4337 跟其他 AA Solution 的差異。

狹義的 Account Abstraction

但上述的定義其實是不嚴謹的，所以你可能看完了，還不懂到底抽象帳戶的抽象是個什麼概念。想要了解真正比較精確的定義，則可以參考 Safe 發表的文章: Account Abstraction is NOT coming，文中頗精準地定義了 AA：

“Account Abstraction is the idea of reducing the number of account types from 2 (EOA and smart contract) to 1 (just smart contract) in order to improve usability and flexibility in Web3.

This is achieved by moving the validity conditions of a transaction (signature verification, gas payment, replay protection) out of the core protocol level (consensus layer) and into the EVM smart contract level (execution layer).”

由上文可以看出，真正嚴謹的 Account Abstraction 定義，是以「以太坊協議」為出發點看待「帳戶」：未來以太坊將不再硬性規定什麼是一個「帳戶」，例如如何進行驗章、付手續費、檢查重送交易等等，也不再在意 EOA 與 Smart Contract Wallet 的區別。相反的，以太坊作為一個 Protocol，只需要固定一系列的流程，包含上述的幾種驗證程序，剩下的「定義」完全保留彈性給各個不同的帳戶提供商，因此被「抽象」掉了。
我把這樣的定義稱為「狹義的 AA」，因為這對於一般不了解共識層或是程式中抽象概念的讀者是比較難以理解的。值得一提的是，在狹義的定義下，後面會提到的 Safe 或是 Argent 也不算符合 AA 標準，因為「以太坊」還是把他們都視為合約，沒有任何新標準可言。

Account Abstraction is NOT coming

解決方法

話說回來，假設我們先把視角固定在「廣義的 AA」，也就是純粹以 UX 的角度來定義問題 。那麼我們可以先討論，想要解決使用者遇到上述兩大彈性問題（驗證彈性以及付費彈性）的話，大概可以分成兩個方向：

1. 在共識層解決：透過以太坊共識層的硬分叉升級，加入新的 OPCode 或升級驗章程序。這方面已經被提出來的提案有 EIP-2938 跟 EIP-3074 等等。缺點是不知道什麼時候才討論的出定案，並且要等增加以太客戶端團隊們已經龐大的工作量。
2. 在合約層解決：仰賴智能合約錢包 (SCW, Smart Contract Wallet)，利用合約層以 EVM 程式碼實現客製邏輯，因此可以把簽章、其他人代為付費上鏈等功能都用智能合完成。

其中 (2) 的方向，過去者幾年就已經有許多產品給出解決方案。比較有名的有 Argent 錢包、Safe Wallet + Gelato 的解決方案等等，兩者在開發上都已經提供上述兩個核心問題的解法：利用多簽等方法滿足驗證的彈性、以及可用代幣支付手續費完成支付的彈性。以 Safe + Gelato 組合拳為例，在合約層實作多簽驗章程序，跟 Gelato 網路的 Relayer 合作，讓任何人都能夠 Relay 成交易並送上鏈。

因此，很大程度上，我們可以說：AA 錢包早就已經被許多團隊實現了。

ERC4337 的特別之處

ERC4337 也是透過「只改動合約層」來達成使用者體驗提升的終極目標，因此我們可以把他歸類為上述的 (2) 。既然在 ERC4337 之前，已經有成熟的 AA Solution ，那麼 ERC4337 到底帶來了什麼改變呢？

這就需要我們稍微退一步，想像一個完美的 AA 達成的世界，並比較一下上述這些現有的 AA 合約錢包，還有什麼阻止我們邁向 mass adoption 的疑慮。以下是兩個重點：

• 鏈下架構 (Offchain Infra) 的中心化：這些現有錢包雖然也有不錯的錢包體驗，在合約層也可能達成去中心化（任何人都可以提交交易），但是其實現有產品們背後都必須仰賴中心化的服務，例如仰賴單一伺服器來完成用戶與打包者之間的溝通媒合、代幣手續費報價簽章等。由於過度仰賴一些後端服務幫忙溝通並進行交易上鏈，這些角色可以在整個網路中扮演決裁者的角色，使所有人對「AA 服務」的信任假設增加。
• 鏈下架構的互不相容：現在的錢包生態系中，各家錢包各做各的，就算假設大家都做到全面且去中心化，只要這些鏈下架構不相容，就會造成只有最大的一家 AA 錢包有足夠的利益誘因吸引大家加入他的鏈下網路，讓大者恆大。這除了迫使所有錢包商必須競爭鏈下架構的開發，無法專心開發錢包之外，還會因為沒有標準化造成開發能量分散，減少這些鏈下服務的多樣性，這將進一步增加網路整體因一個 bug 而集體失靈的機率。

以上兩個重點，大概就是「符合 ERC4337 規定的 AA 錢包」與「傳統 AA 錢包」最大的差異：透過一套 ERC4337 規範，我們想要復刻出跟以太坊現有交易一樣的去中心化程度的新系統。我們也可以進一步條列出 ERC4337 能達到的幾個目標：

• 支援上述 AA 錢包的兩大功能：彈性的驗章、彈性的手續費支付
• 確保鏈下架構跟以太坊節點一樣去中心化，無任何信任假設
• 讓合約錢包開發者與鏈下服務開發者能夠各司其職，促進錢包、鏈下架構的多樣性
• 確保上述所有「參與者」都有足夠經濟誘因使網路更趨向「去中心化」

因此，以用戶角度而言，ERC4337 不是為了解決使用者體驗問題，而是將消除現有的 AA 錢包面對的可拓展性與中心化疑慮。

所以，如果 ERC4337 被實現了，跟現有的 AA 合約錢包相比，其實對於大部分一般用戶的體驗不會有太大的影響，一樣所有人都可以只靠著簽章還有一些後端服務，達到最一開始說的 AA 的兩大彈性優化。但 ERC4337 會讓整個合約錢包體系更健康：用戶將得到最好的報價、不再仰賴單一伺服器不要壞掉、不會因為太多人使用而失靈，並且透過好的角色分工，讓開發錢包的開發者專心開發並推廣更安全、高效的錢包，而所有人也都可以運行一些鏈下節點來獲取收益。

因此我們可以說，ERC4337 的出現將統整現有的 AA 錢包。在此 ERC 被提出之後，各個團隊可以共同遵循一套相容的模式開發這個體系中不同的角色，

P.S. 其實如果用上述「狹義的 AA定義」來看的話，ERC4337 的其實就是「在合約層實作新的交易驗證、付費流程規範」這麼簡單。而在狹義的 AA 定義下，只要 AA 被實現了，不論是在合約層還是共識層，上章節提到的去中心化特質都應該被涵蓋在內。

ERC 4337 細節介紹

這裡我會著重介紹一下大致流程、各角色之間的關係，還有為什麼需要一些特殊的機制設計。希望對於想要看程式碼的人有一點幫助：

名詞介紹

1. Bundler （綑綁者）: 指的是負責接收用戶想要做的交易，經過驗證後負責打包成以太坊交易、支付手續費送上鏈的角色。他們會以類似節點的方法存在，並且理想上要能夠直接參與出塊、並跟其他 Bundler 節點利用P2P 的方式溝通。Bundler 將不只為特定合約錢包工作，且任何合約錢包的使用者都可以自由使用、切換各個不同的 Bundler 服務。
2. UserOperation （用戶操作）: 為了避免混淆，我們不再使用「交易」這個詞。用戶想要進行一個鏈上行為時必須簽署這個「操作」，並統一丟給 bundler，由他們代為打包上鏈。這裡的操作會跟一般的原生交易很類似，擁有 to, data 等等細節來描述要跟哪個合約互動。在 gas 方面比較特別，會分為「驗證」與「執行」兩階段分別限制 gas 用量，這個待會會細說。
3. Mempool：在這個提案中，同樣用 mempool 這個詞來描述所有 UserOperations 會存在的候選池。Bundler 會從裡面選取多筆操作，打包成一筆交易，並送上鏈。這也是為什麼 ERC4337 的標題叫做：Account Abstraction Using Alt Mempool。理想上，所有 bundler 將形成一個 P2P 網路，共同維繫並分享使用者提交的的操作池 (實際實作進度可參考最後面的更新)。

主要目標

要達成「整合所有 AA 合約錢包」這個目的，就必須達成以下兩大點：

1. 建立一套流程讓所有 Bundler 能夠統一所有錢包驗證、打包的流程，並確保 bundler 網路不受攻擊。
2. 保留合約錢包有完整的彈性，實現任意的驗證與手續費支付方法

ERC4337 提議，這套流程的執行，將會被統一實作在一個叫做 EntryPoint 的合約中（入口合約），並讓所有人共享。這個合約目前由 Ethereum Fundation 主導開發，項目名為 Infinitism，可在這裡檢視程式碼。任何一個 EVM 合規的鏈，想要支援 ERC4337 的，第一步就是要部署這個合約。

我們可以在上圖中看到，有了 EntryPoint 這個入口合約之後，後面有三個不同的合約角色，分別是

• Contract Account: 合約帳戶
• Aggregators: 聚合器合約
• Paymaster

上述三種角色中，唯一一定會用到的是「合約帳戶」。這裡的合約帳戶就是像傳統的合約錢包一樣，每個使用者自己部署的智能合約，最基本的功能就是要驗證傳進來的 UserOperation 指令是否經過「正確授權」（可以是簽章、多簽、或其他密碼學簽章，呼應我們前面說到的把驗證這步驟抽象化）。驗證無誤之後就可以直接照著指令呼叫外部合約，進行任意交易功能。

EntryPoint 流程大綱

EntryPoint 有一個特別的地方，就是強迫所有 ERC4337 錢包，把「驗證（Validation）」跟「執行（Execution）」分成兩個的步驟，也就是所有錢包把執行函式跟驗證分開，不能夠合在一起。下面是一段非常簡化的 pseudo-code，描述了 EntryPoint 主要會被呼叫的函示 handleOps 的大致架構:

// contract EntryPoint.sol

/// @dev the function that bundlers call to execute UserOperations
function handleOps(UserOperations calldata opts) external {
    // 1. validation loop
    for (opt in opts) {
      // 呼叫合約帳戶地址 進行驗證
      IAccount(opt.sender).validateUserOp(opt);
    }
    
    // 2. execution loop
    for (opt in opts) {
     // 執行時直接呼叫合約地址，失敗交易也不會 revert
      try {
         address(opt.sender).call(opt.callData);
      } catch {...}

      // ...postOpts, PayMaster logic
    }
}

你或許會覺得奇怪：為什麼要強制兩次呼叫合約帳戶呢？為什麼不能只定義一個函式就好，可以叫做 validateAndExecute 之類的，這樣應該可以省下一些 gas 吧？這就要回歸到上面介紹的重點，這其實是為了達成「去中心化」必須的一步。

驗證的意義

我們不妨回頭想想這裡的「驗證」要做的是什麼：說白了就是對應到以太坊上「ECDSA驗章」的功能。這個驗證手續是一個「所有節點」都必經的動作：如果你的交易附帶了不合法的簽名，根本不用傳到礦工手上，隨便一個節點都會拒絕你提交的交易，根本廣播不出去。除此之外，節點還會驗證你是否是把已經用過的交易進行重送，因此加入了「nonce」這個元素的驗證，確保一樣的交易不能重複被執行。

當驗證只是簡單的 ECDSA 的簽章與 nonce 兩步驟，並不會造成很大的計算負擔，因此以前的節點沒有很擔心你送了一萬筆交易，然後驗證這關卡住了過不了，造成節點掛掉的狀況。

但是如果現在「驗證」這步可以執行任意的合約程式碼，這對每個節點（或是 ERC4337 的 bundler）來說，就有可能會超過負荷，例如一個合約簽包可以要求驗證流程需要去讀取大量的磁碟讀取（SLOAD）。因此我們可以發現 ERC4337 有一半以上的篇幅都在討論鏈下驗證（Validation）的方式，就是要規定一套所有 bundler 跟錢包都同意的規範，確保對 bundler 來說可以有效率的檢驗避免 DDoS 攻擊、對錢包來說卻能保留大部分的彈性。例如，提案中有規定 bundler 應該在收到交易時，使用 IEntryPoint.simulateValidation 模擬驗證結果，它就會再去呼叫每個錢包實作的驗證邏輯，其中，所有錢包的對於這個「驗證邏輯」都要符合類似以下的規定：

1. 禁止使用跟環境相關的 OPCode：例如時間（timestamp）、區塊高度等等。理由是，不能讓一筆本來驗證成功的交易，會隨著時間、或真正被打包的區塊編號不同，而自動變為驗證不成功。因為如果驗證不成功，交易是會整筆 revert ，這樣的情況會變成 bundler 白白支付一筆失敗的交易手續費，而沒有拿到任何補償。
2. 禁止讀取合約帳戶以外的 storage ：如果驗證成不成功會因為外部合約狀況改變，那很高機率跟上述一樣，可能因為其他交易被收入區塊鏈，讓你上鏈時驗證過不了。所以你不能實作「如果 ETH Price > 1000 就成功」這種奇怪的規則，這不屬於「驗證用戶授權有沒有效」的範疇。

這些規定將會被 bundler 節點們實作在自己的驗證邏輯中，如果你的錢包實作的 validateUserOp 程式碼碰到這幾個 OPCode ，整筆交易就會直接被忽略。上述只是舉兩個好理解的例子，關於更多這方面的規定細節，可以參考提案原文中的 Simulation 章節。

下圖很好地總結了從用戶簽署操作開始，到 EntryPoint 定義的流程：我們可以發現 Validation Loop 跟 Execution Loop 是被分開的，這就是呼應到了我們強制每個錢包實作驗證邏輯、在鏈下可以簡單通過呼叫來驗證；到真正上鏈時我們則是先做完所有驗證才會進行後續的實際交易執行。理論上上鏈時的驗證步驟不應該失敗，否則 bundler 就需要承擔損失。

因此要實作一個與 ERC4337 合規的合約帳戶，僅需完成以下幾點

1. 實作 validateUserOp 一個函式，在不違背上面規則的前提下，實作任意驗證邏輯，並且支付gas費用
2. 執行時，只須確保呼叫者是 EntryPoint ，不必再進行上述驗證。基本上邏輯就是簡單的做對外呼叫。

對於合約本身有興趣的話，可以看一下 Infinitism 的 SimpleAccount 模板。

Global Entities

除了帳戶合約本身以外，前面有提到的聚合器 (Aggregator) 跟 Paymaster 兩者都是可選的，只有在用戶帶上特別參數、或是合約帳戶錢包指派時才會被引用。在提案中，他們有時候被稱為「Global Entities」，因為他們都是所有用戶操作都可能用到的合約。

Aggregator 聚合器

如果合約帳戶需要，可以略除驗證部分，把簽章依照任意邏輯聚合再一起，再一起由一個合約驗證。有設計這樣的流程是為了保留錢包驗證簽章的彈性，但是目前我還沒有看過有合約帳戶用到這個功能，這邊的邏輯也比較複雜，之後有更新會再補在比較深入的文章裡。

Paymaster

Paymaster 指的是負責處理付款的合約。在驗證的環節中， EntryPoint 會計算這筆交易最多需要消耗的 gas，並要求帳戶有足夠的 deposit 能夠付款給 bundler 。合約帳戶需要在執行驗證結束後付這些 gas，或是事先 deposit 一筆錢到 EntryPoint 裡面。（這部分運算在程式碼中被稱為 preFund ）。

如果一個操作有使用 paymaster 的話，EntryPoint 則是會檢查 paymaster 的 deposit 是否足夠（簡單說就是從 Paymaster 存的錢裡面扣款）。當然，是否要幫忙付款要經過 paymaster 的同意，因此 paymaster 需要實作 validatePaymasterUserOp 來判斷是否是合法授權的用戶操作。因此不難想像，Paymaster可以實作類似「只代付某特定交易」、「有上限的代付 gas」、「收取用戶 ERC20，代付 gas」等等邏輯，來達到手續費支付的抽象化。

在細節上，ERC4337還有設計一個叫做 postOp 的 hook，可以讓整筆交易做完的時候，再次通知 Paymaster 交易實際執行是否成功、剩下多少 gas 沒用完等等，讓 Paymaster 決定要不要採取 refund 之類的行動。

在整個 ERC4337 當中，paymaster 佔了非常重要的角色，並且在未來可能成為非常專業的服務提供者。這些角色的現況我們後面會在著重介紹。

考量到這兩個角色之後，可以把整個 EntryPoint 合約的流程（也就是ERC4337 規定的流程）整合成下圖。非常推薦想要深入 EntryPoint 合約的人可以配著這張圖對比一下實際實作：

Global Entity 限制

由於 Aggregator 和 Paymaster 這兩種合約都是「任意合約」，並且被多個 User Operations 共享，它們的實作方式都可能在執行時，影響其他用戶操作的「驗證階段」是否順利完成。因此在 ERC4337 中也有特別強調，該如何避免惡意的用戶利用這兩種合約造成 綑綁者計算資源的浪費。其中包含兩大方向：

1. 強制 staking 機制：所有的聚合器或是 paymaster 如果除了用戶帳戶合約以外，還要使用聚合器或 paymaster 自身 storage 就必須質押 (stake) 一定數量的以太在 EntryPoint 合約中。這能確保就算要透過外過合約本身state 更動，也不能毫無成本引發 bundler 做白工來進行女巫攻擊。注意這裡的 stake 跟上面提到用來手續費的 deposit 是不同的兩筆錢、會被分開使用，但是一率都由 StakeManager 這個父合約來實作。
2. Reputation 的機制：如果一個 global entity 不斷造成其他 UserOp 驗證失敗，即透過一些規則把他們的 reputation 降低。這方面會被實作在 bundler 節點上，也是一個可以比較彈性的地方。

這部分細節可以詳閱 ERC4337 的 Reputation scoring and throttling/banning for global entities 的章節。

ERC4337 的短板

介紹完了這些細節之後，我們可以再次快速帶過一些 ERC4337 這樣的架構，容易面臨的一些風險。這些可能是決定是否使用 ERC4337 錢包時要考慮的：

合約風險：EntryPoint 會承擔巨大的合約風險，如果裡面真的存在 bug，可能會造成最高所有錢包總額的損失。如果我們真的想要用這套模式架構提供使用者AA體驗，必定需要先想辦法確保這個合約的安全性。這方面必須引入更高效的 formal verification等等安全技術。

不過以另一個角度來說，EntryPoint 其實很大程度的承擔了每個錢包原本需要自行承受的合約風險。因為程序、付費等邏輯已經被 EntryPoint 實作掉了，帳戶合約的開發反而變得簡單，會比自己開發一個AA錢包要承擔的合約風險要小很多。這點對於促進合約錢包開發是有好處的。

DDoS 風險：這個提案的核心就是為了解決 bundler 們的 DDoS 風險，但他們還是承擔了很多沒有被 compensate 的運算量，而也是這個架構中最容易被攻擊的一環。經過上面的介紹，現在應該對於這個 attack surface 有比較多認識。關於更多為了達到去中心化 mempool 的細節，可以參考這篇文章文章：

Unified ERC-4337 mempool - HackMD

關於 ERC4337 比較細部的介紹就到這裡了。剩下就是一些進度更新，以及比較多我自己的感想。

現有 ERC4337 相關專案與進度

EntryPoint 實作

初代 EntryPoint 已經於今年(2023)三月部署到各大網路上。目前還有一些優化在進行，可以預期今年還會有新的迭代版本出現。

捆綁節點 Bundler實作

目前有幾家比較大的團隊在實作 bundler 的節點，都還沒有實現 P2P mempool 的功能，也就是現在的捆綁者們不是互通的，可以視為還是十分中心化的後端服務（Trusted Providers）：

• Infinitism: JS 實作的 bundler
• StackUp: Golang 實作的 bundler。支援 searcher mode 就是直接與 mev-boost溝通。
• Pimlico: Typescript 實作的 bundler: Alto
• Etherspot: Typescript 實作的 bundler: skandha

合約（帳戶 + Paymaster） 開發

• Infinitism: 前面提過，官方的 SimpleAccount 的模板，有經過審計，因為非常簡潔，可以算是 production-ready。
• ZeroDev: 實作名為 Kernel 的合約帳戶，目前在AA界名聲非常好的一家公司（遇到兩個團隊說看好他們會稱霸 ERC4337 錢包），有著非常彈性的架構，和大量難懂的 assembly 。
• Biconomy: 是最早開始實作4337的團隊之一，在此標準提出之前，也一直在 UX 這塊許多耕耘，之前有名的是他們的 meta-tx solution。實作自己的 SmartAccount，自稱最近有多方整合要上線
• *Safe: 最新版本v1.4 中，已經移除以前無法與 ERC4337 合規的部分，未來可以透過增加 Module的方式變成 ERC4337 compatible（關於之前的問題可以看這個 issue）。但目前 Safe 官方沒有實作，也不打算在其 V2 原生支援 ERC4337。

現有服務

簡單來說，目前大部分 AA 團隊，無論主打錢包還是捆綁者實作，都還是大幅賴提供一條龍的服務給專案方，包含節點營運、錢包選擇、Paymaster API 控管等等，我們把它稱為「AA As a Service」。以下我依照各家給出的整合方式來分類：

High Level SDK:

• Biconomy, ZeroDev, 都有提供非常 High level 的 AA SDK, 可以簡單地讓一個想要提供AA 流程的專案，可以在client端輕鬆整合。這方面必須包括了使用他們自家的錢包，並必須仰賴其後端 API server、以及固定的 paymaster 流程，因此缺乏彈性。

Low Level SDK

• Stackup: StakUp 提出的 userop.js sdk 裡面給予用戶更大的自由度，可以自由組合帳戶合約，並且沒有強制將 API 服務強制包含到 sdk中，因此進階用戶能透過這套 sdk 直接與 bundler url溝通，包含自由決定 paymaster ，因此能透過自架一些備援 bundler 的方式來最小化後端壞掉的機率。
• Alchemy: Alchemy 算是非常努力在支援4337的大團隊之一，Alchemy AA SDK 也算是客製化很高的 SDK，一個小缺點是強制 bundler 跟 RPC client 要是同一個節點（因為 Alchemy 現在的節點就有支援 ERC4337 的 RPC 接口)，如果想要分開的話要自己實作一個 viem client。也一樣可以選擇自己的 paymaster 或是使用 Alchemy 的服務。

值得一提的是，上述兩大種類其實在 paymaster 這塊都是差不多的解決方式，如果要用 ERC20 支付手續費，都還是需要仰賴他們後端自製的 API Server，用 API Key 等等方法驗證支付授權，因此更中心化。

ERC4337現在面對的客觀瓶頸

彈性是否足夠：上面在提到 Safe 的時候，我們有埋了一個小小的伏筆：Safe團隊已經表示他們未來不會成為原生 ERC4337 的錢包，而是會主打自己的V2的設計。理由是 ERC4337 為了防範 DDoS，造成太多設計上的限制，其中就影響了他們 V2 想要做的一個大功能：Nested Safe（由Safe管理另一個 Safe）的設計。這看得出 ERC4337 的提案中確實是限制了一些彈性。

仍是中心化後端架構：現在儘管有 bundler 的實作，在他們不能互相溝通的情況下，其實就還是要仰賴這個節點的正確運作。這其實就回到我們一開始講的，對於現有產品而言，ERC4337 尚未擁有去中心化的特性。

安全性考驗：現在公認最安全的 AA Solution，仍然是使用 Safe 多簽錢包為合約，配合一些如 Gelato 的上鏈服務。身為被部署過最多次的合約，大家對Safe 的信心都比較充足，對於大部分的專案來說，在「驗證」這一層多簽可以說是綽綽有餘，因此沒有必要冒太大的合約風險嘗試新的合約錢包。

ERC4337 的優勢

更健康的生態系：我們可以從上面進度看出，目前整個4337的生態系已經有很多多方合作在進行，這是因為錢包、 bundler 以及 Paymaster 都可以由不同的團隊進行實作、並且互相搭配使用。這除了給各個整合團隊很大的自由外，理論上用戶也已經可以自己搭配出自己理想的合約錢包。

個人感想

我個人很看好 ERC4337，因為這是要在非共識層，系統性解決用戶體驗問題的最佳法則，目前也正慢慢被社群接受。但在此我想提出除了上述比較客觀的障礙之外，其他在這次 research 中體會到的發展困境。

TLDR: 還沒有人做出好用的 「 AA錢包」，只有零星的 「AA-Dapp」。

困難 (1)：ERC4337 AA as a Service 服務對象的矛盾

上面我們說到，上述這些在實作 ERC4337 的團隊，都只有提供類似 AA as a Service 的服務，並且都是主打以「專案整合」為出發點：「如果一個專案想要給用戶提供 AA 的體驗，可以設定為使用者代付手續費，開放使用 ERC20 付款」… 這樣的邏輯。簡單的說，就是把一個 Dapp，透過他們得服務改造成為 AA-Dapp。這些 SDK 都能讓我們可以銜接任意的用戶錢包（不論瀏覽器錢包、硬體錢包或是手機錢包）讓我們在用戶不知情的情況下，為他們部署一個合約錢包，並支援上述所有功能。

最近這一篇文章很紅，描述了最近 ERC4337 為何最近開始起飛，會發現這符合我上面的敘述：現在所謂的「ERC4337表現好」大部分來自「某個提供 AA 體驗的專案起飛」，或是用上面的詞，某個「AA-Dapp」，例如 Polygon 上面的 CyberConnect，一次帶來了應該所有交易量的 80%：

MetaTrends #2: ERC-4337 Smart Accounts

但我為什麼說這存在矛盾呢？因為我認為 AA 最大的好處之一，是它不仰賴各智能合約（或是開發這能合約的團隊）來解決 UX 問題。以往你需要在 Dapp 合約層考慮使用者體驗的話，你可能會利用 meta-transaction 等技巧，天生支援 relayer 的角色來製造好的使用者體驗。但是 AA 的理想是：未來各種 Defi Team寫合約的時候，不用再特別去遵循什麼標準了，一律就用 msg.sender 到底，不用再考慮 meta-transaction 還是 MultiCall；相反的，我們可以讓「錢包層」來做使用者體驗的優化。

但目前既有的「與專案團隊合作把 Dapp 變成 AA-Dapp」的推廣路線跟上述理想是相矛盾的：如果我是一個考慮用戶體驗的團隊，其實我大可在我設計智能合約時，就能實作 meta-transaction ，尤其現在 ERC2771 成熟，在整合上是更安全、更快、也更省gas的。反之如果我是一個不太考慮用戶體驗的團隊，我也不太可能會多花很多時間多整合一套 sdk。

困難 (2)：升級困難：現有專案難以整合這些AA服務

除了剛剛說的「角色衝突」這個理由之外，對於一些已經有產品、既有用戶的Dapp而言，如果要「升級為 AA-Dapp」，就必須要把這個體驗套用在所有人用戶身上。這對於大部分繼有 Dapp 團隊來說很不方便，因為他們可能有一半的用戶都已經是熟練的 EOA 錢包使用者、甚至硬體錢包使用者，並不是所有人都樂見這樣的「升級」。

如下圖所示：通常在一般Dapp的前端實作上，大家都比較偏好 BYOW — Bring your own wallet 的模式：即我整合一個如 rainbow-kit, blocknative onboarding 之類的套件，它可以再去支援任何錢包，這樣用戶就可以選擇要用哪個錢包跟我的前端溝通。這基本上已經成為所有 Dapp 的起手式：除了更容易支援更種軟體、硬體錢包外，也外包很多關於後端節點、gas 等等的設定，讓各個團隊可以更專注的在開發前端的需要的各種功能，明顯是一般前端團隊的首選。

如果把這些「AA as a Service」的 sdk 畫在這個關係圖中，它現在處於 BYOW 模型的右側：也就是 Dapp 範疇之內，因為他的主要接口在於整合任何 “錢包” ，並多包一層 AA 的功能。一家 Dapp Team 要馬選擇做一個一般 Dapp，要馬會選擇使用這個服務，升級成為一個黃框框的 「AA-Dapp」：

如果你已經有許多 EOA 的用戶，那麼強制所有人升級肯定會造成混亂，如果真的要納入 AA，勢必要自己實作兩份流程（即改變自己的 Dapp 與 BYOW solution 之間的關係）：

• 使用 AA 錢包的用戶: Dapp -> AA SDK -> BYOW SDK (簽章)
• 一般 EOA 用戶：Dapp -> BYOW SDK (簽章)

這無疑是個膨大的工作量、並且不可避免地引發其他混亂（例如一個用戶能否同時是EOA用戶，也擁有AA錢包呢？）這是很多「現有 Dapp 」遲遲沒有做這些整合的重大原因。

困難 (3)：所有 AA-Dapp 的選擇將互不相容，最終讓使用者體驗更差

除了麻煩、角色衝突、難以搬遷既有用戶等上述問題之外，更大的一個問題是，所有 Dapp team 做出來的決策將互不相容：例如上圖中，假設 Cyber Connect 使用 Biconomy 作為所有用戶的錢包選擇，那用戶就要先在使用前打錢進入這個合約錢包；而用戶想要轉換到另外一個青蛙 Pepe Dapp 上，如果他們選擇使用 ZeroDev Wallet 的話，用戶就需要把錢轉到另一個合約錢包裡才能使用。這就是這種模型不合理之處。

因此我認為，要求每個 Dapp team 去做出「是否要提供AA服務」這樣的決定是不合理的；這種與團隊合作的推廣方式也不會將「AA錢包」推展至他們的極致。

我的感想與預測

就是上面的這句話的相反：

是否使用 AA 錢包應該是使用者的決定

在一條EVM有許多 Dapp 的假設下，我自己覺得比較合理的升級軌跡應該是讓用戶自行選擇 AA 錢包，也就是讓用戶自己做「要不要從 EOA 升級成 AA錢包」的這個決定。而 Dapp 應該保持不變，也無需做出任何流程上的變動。這樣既符合每個人自己管理自己錢包的原則，也不會出現因為 Dapp 做出不同決定而打架的行為。

好的 ERC4337 AA 錢包將成為關鍵

因此如果能夠有一個很好的瀏覽器插件 AA 錢包，已經整合進主流的 BYOW 套件中，可能會讓更多的 Dapp 願意支援。我們老字號 Argent + WalletConnect 可能從 2020 年就已經打出這套組合拳，但我覺得要透過手機的使用者體驗不是很好，無法媲美瀏覽器插件的體驗。

因此我自己的猜想是，這個生態系中，最缺的是一個好用的AA 錢包。我也在這邊大膽預測，如果能有有人做出一個好用的 AA 錢包，我們可以馬上看到大量的現有 Dapp 接通 AA 體驗（包括 Uniswap / Aave 這種最高等級的應用），直到那一天我們才能讓大量現有 Crypto 用戶升級，也才會真正迎來 ERC4337 大熱、交易量激增的 AA Summer。

目前我有聽到在做「ERC4337 錢包」的產品有：

• SoulWallet：比較有名的瀏覽器插件錢包，但是產品還沒釋出，而且打算自己開發自己的「錢包合約」
• Candide wallet： 手機錢包，現在還再 waitlist 階段

也很期待 Rabby 之類的 UX 大品牌趕緊整合推出自己的 AA 版錢包。（如果知道其他有潛力的品牌歡迎分享）

小結：未來的期待

總結來說，ERC4337 還有非常長一段路要走。現階段來說，還沒有達到理想上的去中心化，但是已經可以從開發社群中觀察到，這樣的架構帶來大家各司其職、實作不同角色的成果已經被慢慢體現出來。各家給出的時間軸都很不一樣，但我覺得最樂觀我們也需要到明年才可能體驗到真正比較去中心化的效果，或許到那時候才會真正在技術上體現他的優勢。

由於 ERC4337 一直到幾個月前才算是進入比較 production — ready 的階段，因此其實妄想要馬上看到其他可用「錢包」也是有點不切實際。但我個人還是很期待中短期內的兩大看點：

1. 「AA As A Service 」可能隨著 app-chain 的崛起而短暫崛起，因為在新的 app-chain 上，一個團隊比較有動機全面升級並掌控所有使用者的錢包體驗。但我覺得這些案例可能只是短期的曇花一現，而且並不能夠最大化 ERC4337 的價值，因為這些 app-chain rollup 目前幾乎都是中心化的，使用 ERC4337 其實浪費了其中捆綁者能夠「去中心化」的效果，但是這是讓大眾接納 ERC4337 的第一步。
2. 真正 AA 的落地會隨著更多的 AA 錢包被做出來，而快速被一般 Dapp 接納。只要有一個 UX 好的錢包被實作出來，現有 EOA 用戶的轉移可能是非常快速的，畢竟 EOA 真的有諸多不便。（不過這也可能只發生在 L2 上，畢竟主網還是貴）

當然，也很希望看到又有人想出 ERC4337 還有什麼新玩法，可能半路會殺出一個新的服務角色也說不定。

Account Abstraction 其實是所有以太坊用戶的相同願景。 ERC4337 只會是一個中期的解決方法，長期來看我們還是需要共識層的改動。無論如何 ERC4337 都是一個很好的學習機會，也是在長期這個願景達成以前唯一能在應用層增加體驗、並且開始試著實作的方法。這個時期大家的努力嘗試，都有助未來共識層改動提案前，我們最大幅度探索所有想要的 usecase。

希望這篇文章有讓大家對於 ERC4337 跟 Account Abstraction這個願景之間的聯繫有更深刻的認識。感謝 MidJourney 當插畫師，也再次感謝各位審稿老師給的寶貴意見！

推薦教材：

列出推薦教材前先謝謝贊助商！TEM Medium 2023 有獎徵稿 TEM Medium 目前正在進行有獎徵稿！詳情請參考：

TEM Medium 2023 有獎徵稿

以下是一些推薦的進階閱讀！

1. Alchemy 系列 ERC4337 解析：
這真的是⭐極推⭐。我對這系列真的是相見很晚，如果早點看到的話可以理解很多設計脈絡。整個系列會由最簡單的設計開始慢慢進化，一步一步了解為何 ERC4337 走到今天這副模樣。以下附上Part 1：

You Could Have Invented Account Abstraction: Part 1

2. 上面介紹過的：Unified ERC-4337 mempool
這算是比較深入的針對理想 ERC4337-mempool 狀態，完整的敘述我們需要哪些對於 bundler 的保護、以及所有 bundler 都需要遵守規定的原因。

Unified ERC-4337 mempool - HackMD

3. ETHTaipei Workshop!
想要實作 ERC4337 怎麼能不看最強團隊 imToken 的教學呢？以下附上教學影片以及一直有在更新的 repo。

GitHub - consenlabs/ethtaipei2023-aa-workshop: Account abstraction workshop @ ETHTaipei 2023

從抽象帳戶到ERC4337 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

前言

今天要介紹的Rysk Finance算是我自己比較熟悉的團隊（前同事創辦的），我也算是擔任了半個advisor，所以可能大家對於我給它的讚美可以打個親情折扣。正式的合約已經在前天正式在Arbitrum上線並且開放deposit，好像三分鐘就存滿上限500K USDC。(還好我是advisor可以先ape😝)，不過這只是第一階段的Launch，接下來幾週陸續解鎖其他功能。

雖說本質上目前的產品就是Option AMM，但我特別喜歡這個團隊為產品訂定的「屬性」，個人覺得是很特別也適合這個圈子，所以我會花一點篇幅介紹所謂「精神面」的團隊概念以及未來走向。

簡介

人如其名，Rysk 為什麼這樣取名，就是想要將「風險(Risk)」這個觀念帶入到使用者的投資視野之中。目前DeFi普遍還是被一般人視為高風險高報酬的賭場，但如果Defi想要被廣大用戶所採用，風險控管這個觀念就會變得至關重用。Rysk Finance的團隊理念就是設計以「風險管理」為核心的投資策略，在這樣的核心之下，第一個想要專注做的投資商品類型就是「不相關回報」 — Uncorrelated Return。

Why Diversification and Uncorrelated Return

”Diversification is the only free lunch.“

這句話是諾貝爾得主Harry Markowitz講過的名言。看起來很好理解：多樣性是穩健投資最重要的觀念之一，因為可以分散風險，確保不把雞蛋放在同一個籃子裡。這個國小老師好像就有教。

如果我們來看看DeFi世界的各種「投資商品」：從單純買幣、買指數、Uniswap LP 到各種token farming 甚至NFT，看似多種多樣，但仔細回想會發現，儘管我的投資組合好像十分的多元化，但在牛市下，你所有的投資策略都狂賺，而熊市下，所有的策略都暴虧。說好的Free Lunch呢？

這就是「相關回報」最好的例子：儘管表面上做到了投資多樣性、但由於大部分的投資組合都是彼此「高度相關」(correlated)，因此這其實不符合投資多樣化的條件。

一個簡單的分析方法是利用「風險調整後之報酬率」(Risk Adjusted Return) 來分析你的投資組合，最有名的公式之一就是Sharpe Ratio：

我覺得可以把這個公式簡單的想像成回報(Return)除以風險(Risk)的數字。

我們可以用Sharpe Ratio來分析自己的投資組合。假設現在你的投資組合是完全相關的 ETH 跟 BTC (如下)，那Risk那一欄的（也就是回報標準差），會是兩個標準差的平均數。在這樣的計算下你的Sharpe Ratio是2。（事實上ETH跟BTC的相關性大概是0.9）

但假如今天把BTC換成一個Return也是10%，但是相關係數為0的投資商品 (下圖的rysk)，那麼你整體投資組合的總風險是變小的，因為兩個不相關的分佈會彼此抵銷加總起來的標準差（想看這個範例確切的數字計算可以參考這個spreadsheet）。這樣算起來Sharpe Ratio就變高了。

一個更直白的幾解釋就是：兩個投資策略之間若呈現相關，則風險無法互相抵銷。所以其實在實現 Diversification時，找到「不相關回報」是比起找到不同投資標的更重要的指標。

The key to diversification is using more assets. The less correlated those assets, the better.

講了這麼多，只是為了介紹Rysk這個團隊做策略的核心就是做Uncorrelated Return。他們第一個做出來的產品叫做Dynamic Hedging Vault，其實就是一個「Option AMM」。但是值得一提的是他們的團隊目標並不是做選擇權AMM，而只是因為選擇權AMM剛好有符合uncorrelated這樣的條件，因此他們把這個當作第一個「策略」。因此在UI的設計上，整體也會著重在做成一個投資策略而非「交易所」。未來如果找到別的un-correlated return策略，他們也可能會去實作。

Dynamic Hedging Vault (DHV)

像上面說的，Dynamic Hedging Vault其實就是一個Delta-neutral option AMM。透過讓LP 存入USDC，這個Vault可以同時買跟賣option，並且透過多種手段做delta hedge。

註：Delta Neutral 的意思就是整體策略不論 underlying asset (ETH) 漲或跌、都不會直接關係到損益。 也就是賺錢與否與ETH漲或跌無關（也就與幣圈大波動無關） — 這就是最基本的no correlation。

Alpha Launch

值得先一提的是，儘管合約已經寫完了，但是現在完全體的AMM功能還沒有開放，目前只能被當作一個由他們跟做市商交易選擇權並且自動對衝的non-custodial策略。這一階段被稱為Rysk Alpha，之後下一個階段叫做 Rysk Beyond 才會完全開放所有買賣功能，成為一個可以不仰賴中心化交易的AMM。

機制介紹

以下我們透過幾個面向快速帶過DHV這個策略的基本介紹：

底層 Protocol

Rysk使用Opyn v2為基底，進行了些微改良，作為其所交易的所有選擇權的底層。這裡面最重要的一個改良功能就是USDC — collateralised call。

目前市面上一般的去中心化選擇權合約，都要求使用Underlying (ETH)來作為一個買權(Call) 的抵押物。理由是：身為一個選擇權的賣家，如果ETH無限上漲，若你有一個ETH當抵押物，那你永遠都付得出結算的損失。這樣「抵押ETH賣call」其實就是covered call。Opyn儘管有時做出partial collateralisation, 也就是不需要完整一個eth來當抵押物，壞處仍然明顯：對一個trader來說你沒辦法完全獲得negative delta，因為永遠必須持有一些ETH來開倉，持有ETH就持有delta。（理論上可以用USDC為抵押物去借ETH出來，但是這樣你的資金利用率就更低、合約也更難寫QQ)

開放使用USDC來抵押並且鑄造call option對於想要維持delta neutral的策略而言好處很明顯：可以比較簡單的來計算自己現在到底是有多少delta，因為stable coins delta 為0。也不用一直轉換ETH跟USDC，和計算到底合約要持有多少ETH跟USDC，全部都用USDC抵押就好。

用USDC作為抵押物當然就有被清算的風險。在這裡為了確保底層系統穩健不要破產，Rysk也改動了原本Opyn在partial collateralisation底下以拍賣為底的斷頭(Liquidation)機制。現在一旦一個倉位被認定是高風險，liquidator可以直接take over該賣家的short position，補足抵押物，並直接拿到前一個賣家所有的抵押物。這是為了確保在任何環境下，liquidator都有動機監控整個系統的健康程度。

Pricing

在AMM的定價方面，老實說並沒有太大的突破，算是比較常規的方法透過一個vol surface oracle，加上black-sholes進行定價。除了基本定價之外，還有兩個會影響定價的因素：

1. Delta Premium: 為了鼓勵大家對這個合約交易並幫助維繫AMM的delta = 0，如果一個交易會讓整個合約的delta更接近0的話，會獲得獎勵（可以用更低價買、或賣更高價）。
2. Utilisation Premium資金利用率：如果現在策略所剩的錢不多了，那麼要買選擇權就會變得更貴（因為AMM需要放更多抵押物來賣）。這一部分只會影響「買」的人，因為如果是反之希望AMM跟你買的話，是不需要抵押物的。

Hedging

為了達到Delta Neutral，在目前的架構下，DHV一共有兩條hedging的路徑，分別是透過Rage Trade的future，或是Uniswap 的spot trade。Rage Trade 其實比較好理解，可以直接抵押USDC選擇要long / short，唯一要注意的是抵押物不足可能被清算。而使用Uniswap則會同時會控制ETH跟USDC兩個資產。為了管理方便，每一個可以用來hedge的合約都被稱為一個「Reactor」，並且分別在各自的合約內持有資產，並負責報告目前持有的Delta。在一般狀況下，使用Rage來進行hedge比較有效率，因為多、可以空、還可以有leverage。不過如果在特殊情況下，使用perp的funding rate太高的話，也可以用uniswap直接spot trade。

合約基本架構

我這裡直接貼一張圖他們gitbook剪下來的圖，讓大家有個基本認知。我們可以從這張圖來分析一下投資的風險：

圖中的紅色圓圈是期待互動的角色，包括了

• 中間的Liquidity Provider: 也就是存USDC近來的人，主要服務對象
• 右上方的Option trader / Market maker / arbitrageur: 預計會來跟主要的vault進行交易的人。目前的Rysk Alpha版本中，是由 OptionHandler 這個合約來進行交易，方法是由rysk團隊控制的manager提交訂單，並且讓別人來fill Order，因此比較像是OTC的交易模式。

而三個綠色的圓圈則是確保系統正常運作的三個keeper bot:

• 左：調整抵押物，確保Option Position不要被清算
• 下：調整抵押物，確保Perp-trade-Account 不要被清算
• 右：負責透過Oracle更新Portfolio Value: 這就關係到現在Rysk是如何計算所有倉位的淨值：答案是自己用Chainlink Oracle報告 😶😶。這顯然是一個非常中心化的做法，但是是為了支援可以開任意數量的Position，如果要維持鏈上運算是一個運算量很大又會很不精準的工程。因此算是目前權衡之下的妥協方案。

這裡統整一下整個系統可能面對的風險，還有中心化風險

系統性風險 (哪邊可能壞掉):

1. Dependency on Rage Trade：Rage trade身為一個相對較新的perp trading protocol，有自己的合約漏洞風險，也可能被暫停交易。
2. Oracle Risks: 上面說過，現在是由Chainlink Oracle的架構自己報告總投資組合的價值以及delta。在AMM開放後這一塊的infra壞掉，可能會造成定價不公平，導致vault損失。
3. Bots (Keepers) Risks：三個Keeper bot裡面有兩個是為了保障option position以及perp position不被清算，這部分現在還是permissioned，也就是只能由授權的地址來觸發rebalance，因此如果這部分的infra壞掉，則可能造成兩個帳號被清算，可能損失大量抵押物。

中心化風險 (團隊作惡或是私鑰遺失的話會有的損失)

1. Portfolio Hedging Risk：目前所有的hedging也是由manager這個角色來觸發，並且也由manager輸入要hedge的數量。如果這裡沒有處理好，可能會造成對衝失效，策略不再delta neutral，在市場漲跌時發生損失。
2. 目前的交易都由 OptionHandler 由manager中心化掛單的方式成交。這可能導致惡意的manager直接用非常低的價格買到一些高價值的買權，理論上可以透過低價買「0元買權 (zero-strike call)」拿走所有的錢。

當然，所有合約儘管經過審計都還是有被駭的風險，雖然我自己覺得他們合約寫得滿漂亮的，算是我看過覺得易讀也好理解程式碼，但是大家也不要太相信我，可以自己參觀一下他們的程式碼 (Link to Github)。

小結

以上就是對於Rysk這個團隊、目前新Launch的產品的介紹。由於目前的產品還不是完全體，我也滿期待之後把AMM功能開放之後，能再有人來分析一下他們這樣的定價方式到底有沒有競爭力，還有LP到底多賺錢。

今天有一半是抱持著宣揚專案的心情來的(雖然我不是投資人QQ)，但個人是十分喜歡這個團隊的定位，還有這種iterative launch的方式。再加上我覺得Uncorrelated return好像是一個有用的小知識，所以就來分享一下。希望上面的分析還算是不失公正啦。

接下來幾週可能會比較不定時的增加DHV的存款上限，想要Ape的朋友們，可以進入Discord群Folllow一下。附上一下連結：

• website / app: https://www.rysk.finance/
• Twitter: https://twitter.com/ryskfinance
• Discord: https://discord.com/invite/62846YV7NY

Rysk Finance 簡介 was originally published in DeFi 燒酒螺 on Medium, where people are continuing the conversation by highlighting and responding to this story.