用原生 L2 代幣來支付交易手續費
這篇短篇文章會介紹 L2 讓使用者用該 L2 的代幣來支付交易手續費的優缺點。
先備知識：
- 知道 Rollup 的運作機制及 Force Inclusion 機制
L2 幾乎都會發行自己的代幣，但絕大多數的實際用途都只是用來參加治理（Arbitrum、Optimism）。有些 L2 會提供質押 L2 代幣的功能，例如 Mantle 及 Manta。這些質押可以用來「決定誰可以排序交易的權力」、「決定生產零知識證明的權力」，或是用來「確保 L2 資料的資料發佈特性（Data Publication）有被保障」，詳細可參考官方文章或文件：StarkNet、zkSync、Mantle、Manta。
註：不過要注意「資料是否正確發佈」是沒辦法被客觀證明的，因此也就沒辦法進行懲罰，所以我個人對「為了資料發佈特性而質押 L2 代幣」的設計仍然存疑。資料發佈特性的介紹可參考：
那 L2 代幣可以用來支付使用者的交易手續費嗎？這麼做有什麼樣的優點和缺點？
優點
增加代幣用途，讓 L2 代幣不是只有單純治理功能。甚至可以搭配 EIP-1559 機制去銷毀 L2 代幣，讓 L2 代幣成為通縮代幣增加價值。
缺點
L2 的資料成本還是以 L1 代幣計價
Rollup Sequencer 在上傳資料到 Ethereum 上時，還是得以 ETH 支付手續費，所以 Sequencer 得要承擔風險 Rollup 代幣及 ETH 之間的價格波動風險。如果它在「收到 Rollup 代幣」到「將 Rollup 代幣兌換成 ETH」的期間，Rollup 代幣價格相對 ETH 價格下跌，那就表示賠錢；當然反之則是賺錢，不過 Sequencer 未必會想再多承擔一層風險。
註：如果該 L2 不是 Rollup、不是上傳資料到 Ethereum 而是改成上傳到其他 DA 層的話，一樣會遇到這個問題，只是 ETH 換成了該 DA 層的代幣。像是 Mantle 或 Manta 都是將資料上傳到其他 DA 層。
影響使用體驗
如果 L2 只能使用自己的代幣來支付手續費，會造成使用者的使用體驗變差，因為使用者進到該 L2 就得想辦法再換成該 L2 的代幣。例如 Polygon PoS，如果使用者第一次使用 Polygon PoS，以為把 ETH 存進去就可以開始使用，使用者會發現 ETH 沒辦法用來支付手續費，而且他也沒有用來付手續費的 Matic 代幣，因此也不能把 ETH 換成 Matic，所以他必須再一次在 L1 先換到 Matic 然後再把 Matic 存進 Polygon PoS才能正常使用。
註：嚴格來說 Polygon PoS 是屬於安全性較低的側鏈（Sidechain）而不是 L2，不過不影響這裡舉的使用體驗的例子。
如果每個 L2 都這麼做，那 N 個 L2 就會造成使用者 N 次麻煩。
L2 互通多一層阻礙
如果 L2 都用自己的代幣支付手續費，那 L2 之間的互通性（Interoperability）將會變得很差。例如單純的 L2 跨鏈轉帳，使用者不能單純地把 ETH 跨過去就可以順利在目標 L2 上開始交易，他會遇到和前面 Polygon 一樣的問題，所以他必須換成目標 L2 的代幣，例如（假設）從 ARB 換成 OP，而這還會受到 ARB <-> OP 的流動性所影響。如果有 N 條 L2，那流動性就要分割到 N-1 個池子，使用者也要兌換 N 次才能在 N 條 L2 上開始交易。更複雜的操作例如跨鏈借貸、跨鏈開倉、跨鏈清算，都隱含著要先跨手續費過去，等於每次都要支付一定成本在這上面。
或例如 Optimism 為互通性而打造的 Superchain，如果 Superchain 生態裡的每個 Rollup 都用自己的代幣支付手續費，那就等於直接牴觸 Superchain 的目的和願景。
不過以上「使用體驗變糟」及「L2 互通性變差」的前提都是 L2 都「只」接受用自己 L2 代幣來支付手續費。如果 L2 都開放讓使用者可以選擇以 ETH 或是 L2 代幣支付的話，就不會有上述這兩個缺點：使用者在做跨鏈操作時就以 ETH 為媒介，在 L2 上獨立操作的話就以 L2 代幣支付手續費。而 StarkNet 便是即將成為同時提供 ETH 或 STRK 來支付手續費的 L2。
STRK 做為交易手續費
StarkNet 去年底宣布將會支援「以 STRK 代幣支付手續費」的選項，使用者將可以選擇以 ETH 或 STRK 來支付手續費，Sequencer（StarkNet 稱為 Operator）會承擔 ETH <-> STRK 匯率變化的風險。那 Sequencer 要怎麼決定一筆原本是 0.1 ETH 手續費的交易如果改成 STRK 支付的話要收多少 STRK？
Sequencer 的權力
不管在 L1 還是 L2 中，使用者的交易基本上都是指定一個他願意付出手續費的最大值，例如在 Ethereum、Arbitrum 或 Optimism 等採用 EIP-1559 機制的鏈上，使用者都需要指定一個 maxFeePerGas 值，maxFeePerGas 乘上 gasLimit 就代表這筆交易的手續費最大值。如果是在非 EIP-1559（例如 Bitcoin 或是以前的 Ethereum）的鏈上，使用者就是指定一個固定的手續費。
註：StarkNet 雖然還沒有 EIP-1559，但一樣也是指定一個 maxFee 值。
不管在哪一條鏈上，有權排序、收入交易的人（礦工、驗證者、Sequencer 等等）都有權力可以審查交易、不收入特定交易，但只要某筆交易被收入了，那筆交易最多就是被徵收使用者指定的手續費最大值。
公開 Oracle 提供 ETH <-> STRK 報價？
有些人會覺得要有一個公開 Oracle 來提供 ETH <-> STRK 報價，這樣在把 0.1 ETH 的手續費轉換成 STRK 數量時才有一個公開公正的轉換匯率。不過如同前面一段提到的，Sequencer 可以不收入特定交易，但只要收入了，最多就是收取使用者指定的手續費最大值，所以重點是使用者指定了願意付出的手續費最大值（不管單位是 ETH 還是 STRK），剩下就是等交易被收入。ETH <-> STRK 的匯率是否公開根本沒有影響，只要 Sequencer 想要，他都有手段可以將使用者的交易手續費收到滿。
所以就不需要 Oracle 了嗎？
Off-chain Oracle for StarkNet Sequencer
實際上還是需要 Oracle，而且 StarkNet 也宣布會有 Oracle 來提供 ETH <-> STRK 報價，只是這個 Oracle 會是在鏈下專為 StarkNet Sequencer 提供報價的服務。但我覺得 Oracle 不應該用在這個場景，後面會說明。
如果 Oracle 是在鏈下去提供報價給 Sequencer，要怎麼說服社群 Sequencer 真的是照著 Oracle 報價來計算 STRK 手續費？Oracle 至少得公佈他們的報價，讓社群能比對 Sequencer 是否有如實按照報價計算，如果發現 Sequencer 沒有如實參考報價，那社群至少可以提出證據來譴責 Sequencer️。🤷♂️
如果 Oracle 的報價能寫到鏈上或是整合進協議裡，就能免除 Sequencer 作惡或失誤的可能，不過這得牽涉到協議層的改動，所以或許目前這個作法是以盡力取信於社群的最大折衷做法了，畢竟 StarkNet 其實是可以完全讓 Sequencer 自己決定的。反正如前述，使用者指定 maxFee 後剩下就是交由 Sequencer 決定了。
那 Oracle 在哪才會真的派上用場？
Force Inclusion 機制
為什麼 Force Inclusion 機制會需要 Oracle？先不論 StarkNet 目前還沒有實作出 Force Inclusion 機制，其他 L2 像是 Optimism 或 zkSync 都會在使用者在 L1 上執行 Force Inclusion 函式時，先向使用者收取 L2 的手續費。例如 Optimism 的 depositTransaction 函式會按照使用者指定的 L2 gas limit 去燒毀（消耗掉）相對應的 gas，也就是收取 L1 ETH 的意思；zkSync 的 requestL2Transaction 函式會算出 L2 交易的基本成本並要求 L1 交易要帶上足夠的 ETH 來支付基本成本。如果今天 Optimism 或 zkSync 也推出自己的代幣支付手續費的功能，那 Force Inclusion 機制會有什麼影響？
假設使用者從 L1 請求強制收入他的 L2 交易，但是 L1 收取的是 ETH 而 L2 手續費是用 OP 支付的話，要怎麼計算該在 L1 收他多少 ETH？如果沒有公正的匯率，就有可能造成使用者付出超額手續費，等於是懲罰 Force Inclusion 使用者；或是造成攻擊者濫用低廉手續費，都從 L1 去送交易而不是從 L2。而這才是我覺得 Oracle 該派上用場的場景：讓 L1 合約可以公正地計算 Force Inclusion 交易要收取的手續費。
不過 L2 可以規定 Force Inclusion 交易和 L2 交易都以 L2 代幣計價（例如都收取 OP），這樣就不需要煩惱 L1 與 L2 手續費單位換算的問題。但要注意的是，仍然有一個成本是無可避免要以 ETH 計價的 — 資料上傳的成本，所以使用者的 Force Inclusion 交易會變成要同時支付 ETH 以及 OP，這可能造成一些使用體驗上的摩擦，但這也是 L2 用自己代幣支付手續費本來就需要面對的挑戰。
總結
- L2 發行自己的代幣可以有不同用途，但如果將 L2 用於支付 L2 手續費會有什麼樣的優缺點？
- 優點很簡單：L2 代幣會有一個明確實際的用途，如果搭配 EIP-1559 燒毀代幣，可以進一步提升幣價
- 但缺點也不少：Sequencer 承擔風險變大、使用者的使用體驗變差、尤其跨 L2 的使用體驗會糟上許多
- 不過如果 L2 保持 ETH 和 L2 代幣都能用來支付手續費，那就不會影響到使用體驗（單 L2 或跨 L2）太多
- StarkNet 是幾個較知名 L2 中第一個計畫開放以 STRK 支付手續費的 L2，並會引進第三方 Oracle 項目來為 ETH <-> STRK 匯率進行報價
- 而這篇文章的重點是放在介紹「Sequencer 權力」及「Oracle 真正適合的場景」
- 「Sequencer 權力」：Sequencer 在收入及排序交易這件事上的權利是非常大的，使用者沒辦法去挑戰 Sequencer 的公平性，因為公平這件事是沒辦法在鏈上去證明的
- 使用者能做的就是指定好他願意為他這筆交易付出多少手續費（
maxFee、maxFeePerGas），剩下就是交給 Sequencer 並相信他了 - 「Oracle 真正適合的場景」：正因為「只要 Sequencer 想要，它就可以將使用者手續費收到滿」，所以 L2 交易引進一個 Oracle 來報價並沒有太大用途，更多是讓社群和使用者安心
- 真正有 Oracle 適合的場景應該是在 L1 上的 Force Inclusion 機制，因為 Force Inclusion 交易收取的手續費如果和 L2 手續費單位不同，且沒有公正的匯率的話，就會造成無辜使用者付出超額 Force Inclusion 手續費，或是攻擊者濫用低廉手續費，都從 L1 送交易
- 如果 L2 規定 Force Inclusion 手續費和 L2 手續費都用 L2 代幣的話，就不需要煩惱匯率的問題，不過使用者的 Force Inclusion 交易就要同時支付「交易資料上傳到 L1 的成本」及「L2 手續費」，分別是以 L1 代幣及 L2 代幣計價。這會影響到使用體驗，不過這本來就是 L2 使用自己代幣支付手續費就必須面對的挑戰
參考資料與推薦延伸閱讀
- https://docs.starknet.io/documentation/architecture_and_concepts/Economics-of-Starknet/#purpose_of_the_token
- https://docs.mantle.xyz/governance/parameters/tokenomics
- https://docs.mantle.xyz/network/introduction/concepts/data-availability#mantle-da-powered-by-eigenda-technology
- https://docs.manta.network/docs/mantaToken/
- https://mantanetwork.medium.com/manta-tokenomics-b226f911c84c
- https://twitter.com/KAndrewHuang/status/1694002513534660747
- https://community.starknet.io/t/starknet-v0-13-0-support-for-fee-payment-in-strk-reduced-transaction-fees/109608
- https://community.starknet.io/t/snip-strk-fee-token/101924
- https://book.starknet.io/ch03-01-02-fee-mechanism.html
TEM Medium 2024 有獎徵稿
TEM Medium 目前正在進行有獎徵稿！詳情請參考：
Special thanks to Kevin Mai-Hsuan Chia and Chang-Wu Chen for reviewing and improving this post
