Layer 2 讓你選對 Layer 3

$38B TVL 把 Layer 2 和 Layer 3 的安全取捨講得很直接。

我看 Ethereum scaling 方案看久了，最煩的就是那種一上來就說自己「更彈性」「更客製」「更適合未來」的簡報。我用過幾個 rollup，也碰過幾個 app chain 提案，感覺都一樣：先把詞堆滿，再把風險藏起來。Layer 2 明明已經把手續費和可用性拉回正常範圍，Layer 3 卻常被包裝成下一層神秘升級。問題是，很多團隊其實只是想要自己的鏈，還想順便借 Ethereum 的安全敘事而已。

真正讓我把這件事想清楚的，是 FinanceFeeds 的這篇整理，它把 Layer 2 / Layer 3 的差別跟大概 $38B TVL 放在一起看。它也引用了 Ethereum 與 Vitalik Buterin 對 Layer 3 的提醒。這個錨點很有用：Layer 2 是把 Ethereum 變得能用，Layer 3 是把某個應用變得更專門。

Layer 2 是把 Ethereum 拉回可用範圍的那一層

Layer 2 networks process transactions off the main chain to reduce fees and increase speed while inheriting the base layer’s core security guarantees.

翻譯一下就是：Layer 2 把大部分交易工作搬離主鏈處理，最後再把結果回寫到 Layer 1 結算。它不是在發明新魔法，只是在不改變整個信任模型的前提下，讓小額交易不要每筆都去搶昂貴的區塊空間。

我以前真的看過有人把 $20 gas fee 當成「先撐一下，等網路順了就好」。沒有，根本不會自己變好。需求一上來，主鏈就是會塞。Layer 2 之所以站得住腳，就是因為它改的是經濟結構，不是只換一個漂亮名詞。

這篇文章把 Layer 2 拆成兩種大家最常碰到的路線：Arbitrum、Optimism、Base 這類 optimistic rollup，跟 zkSync、Starknet 這類 ZK rollup。前者先假設交易有效，後者先用密碼學證明再送上鏈。這兩條路都在做同一件事：把 Ethereum 的成本壓下來。

我自己的實操寫法很簡單：如果你的產品要的是低費用、熟悉錢包、最少的橋接摩擦，我會先選 Layer 2。不要在使用者還沒證明會回來第二次之前，就急著把架構升級成更複雜的東西。

• 需要低費用但不想重做整套信任模型，就先看 Layer 2。
• 優先選已經有流動性和工具鏈的 rollup，不要追新名詞。
• 先算橋接成本，很多「便宜」產品最後都死在這裡。

$38B TVL 不是炫耀數字，是重力方向

FinanceFeeds 引用 L2BEAT 的資料，說到 2025 年 12 月左右，Layer 2 TVL 大概有 $38 billion，其中 Arbitrum 約 $16.7B，Base 約 $12.5B。這不是拿來發推文炫耀的數字，這是在告訴我：資本已經在哪裡停下來。

我看到這種量級，就不會再把 Layer 2 vs Layer 3 當成純理論題。資金會挑地方放，開發者會挑地方部署，流動性會挑地方聚集。等某幾條 rollup 變成預設值，其他方案就得拿出很強的理由，才能叫人搬家。

文章也提到 Base 在月交易量上常常很強，而 Optimism 的市占就沒那麼好看。我不會把每個交易數都硬拗成同一種比較口徑，但方向已經很明顯：市場在收斂，不是越多鏈越好看。只要補貼退潮，大家最後還是回到最省事、最有流動性的地方。

我之前評估過一個 app chain 案子，團隊一開始都很愛「自己掌控路線圖」這件事。等我們把使用者、錢包、索引器、橋接、流動性全畫出來，大家臉色就變了。原來最貴的不是部署，是說服別人跟著移動。

我現在的做法是先問三件很土但很有效的問題：流動性在哪裡、工具在哪裡、使用者已經在哪裡。如果答案都指向一兩條主流 rollup，就別硬逆風，除非你真的有別人沒有的需求。

• TVL 代表信任累積，不代表永遠贏。
• 補貼結束後，集中通常比碎片化更耐打。
• 選能減少使用者搬家的鏈，不要選最會講故事的鏈。

Layer 3 不是更會擴容，是更窄的野心

Layer 3 protocols sit on top of Layer 2 to deliver application-specific customization for use cases like gaming, privacy, and real-world asset tokenization.

白話一點講，Layer 3 是給那些想要自己規則的應用用的。它不是拿來跟 Layer 2 比吞吐量，而是拿來把某個特定工作流做得更順、更便宜，或更好管。

很多 crypto 解說會把這件事講得像階梯升級，好像只要往上疊一層，就自動變成更高級的架構。沒有這回事。Layer 3 比較像專用車道，不是高速公路的升級版。你如果是遊戲、隱私、RWA、企業內部流程這種很窄的需求，它可能有用；如果你只是想「更快」，那通常是想太多。

我自己最常看到的誤區，是團隊把 Layer 3 當成控制慾的出口。想要自訂費率、想要自訂驗證、想要自訂合規邏輯，這些都可以理解。但一旦真的上線，使用者、錢包、監控、索引、橋接都要一起承擔多一層複雜度。白板上很乾淨，prod 裡很吵。

實操上，我只會在這三種情況認真考慮 Layer 3：你需要特殊隱私、你需要非常客製的執行規則、或你的流程在一般 rollup 上就是彆扭。其他情況先別急，很多時候你要的是產品設計，不是新鏈。

Vitalik 那句話其實是在擋大家亂疊層

Vitalik Buterin wrote that Layer 3 protocols can only be justified if they enhance existing Layer 2 solutions.

這句話很直接：如果你只是把同樣的東西再包一層，吞吐量不會自己長出來，複雜度倒是會先上去。Layer 3 不是拿來證明你很懂架構的，它必須真的補到 Layer 2 沒辦法舒服處理的缺口。

FinanceFeeds 也提到他在 2022 年提過幾個合理用途：像是客製化功能、弱信任擴容、以及跨鏈橋接。這個框架我很認同，因為它不是在說「不要做 Layer 3」，而是在說「你先把理由講清楚」。

我很怕那種只會講 layer 名稱的人。好像把架構層數說得越多，產品就越厲害。其實剛好相反，層數越多，維運、除錯、支援、教育使用者的成本都會往上疊。

所以我現在看任何 Layer 3 提案，都會先問一句：它到底比 Layer 2 多解了什麼？如果你只能回答「更彈性」或「更專用」，那還不夠。你要能說出具體場景，最好是一句話就講完。

實操寫法很簡單：先寫下 Layer 3 的唯一價值。如果你寫不出來，就先停。多半不是你需要 Layer 3，而是你還沒把需求拆乾淨。

安全繼承一往後退，信任假設就變多

Layer 3 networks inherit security from their parent Layer 2, which creates an additional trust assumption in the chain.

這句話才是整件事最現實的地方。Layer 2 至少是直接靠近 Ethereum 結算；Layer 3 再往上一層，就得先相信它底下那層 Layer 2 沒出事。每多一層，信任鏈就多一個節點。

很多 pitch deck 會把這件事講得很輕鬆：「多一層而已，不影響。」我每次聽到都會皺眉。因為在鏈上世界裡，額外依賴就是額外風險。尤其是 DeFi、RWA、或任何有實際抵押品的東西，這種風險不是理論題，是會變成事故的。

文章的比較其實很清楚：Layer 2 是直接從 Ethereum 的安全模型獲益，Layer 3 則是從 Layer 2 再繼承一次。這個差別對工程師來說很重要，因為它會反映在暫停機制、審查能力、跨層失效、以及最終資產安全上。

我以前看過團隊很愛講「我們的設計已經夠安全了」。這句話通常不是壞話，但也常常代表他們還沒真的列出失敗模式。對我來說，這是紅旗。你如果連誰能停鏈、誰能審查、父層出問題怎麼辦都講不清楚，使用者不會替你補答案。

實操上，我會要求團隊把 trust chain 用白話寫出來：誰控制哪一層、誰能中止、誰能回滾、出了事怎麼走。這份文件比漂亮的架構圖更重要。

費用下降之後，很多 Layer 3 故事就沒那麼站得住

文章提到 Ethereum 在 EIP-4844 之後費用明顯下降，這會直接影響 Layer 3 的商業理由。這點很現實，因為很多 Layer 3 的故事本來就是建立在「Layer 1 太貴」這個痛點上。

現在問題來了：如果 Layer 2 已經把費用壓下來了，那你還要 Layer 3 幹嘛？如果你的答案還是便宜，那多半沒戲。因為便宜這個理由，Layer 2 已經先做掉了。

但如果你的答案是「我需要特殊隱私」「我需要特定執行邏輯」「我需要一種在一般 rollup 上很彆扭的工作流」，那 Layer 3 仍然有位置。它的戰場變窄了，不代表消失。

我自己的經驗是，基礎層一升級，很多團隊會忘記重新檢查自己的假設。結果就是產品還在照舊開發，但底層條件早變了。這種情況最容易讓人做出過時架構，還以為自己很前瞻。

實操寫法：每次 base layer 的費用、DA、結算條件有大變動，就重跑一次架構評估。不要把舊痛點當永久需求。

可抄的模板

# Layer 2 vs Layer 3 決策模板

## 先選 Layer 2 的情況

- 你要的是低費用、快結算、一般用途的應用。

- 你想盡量保留接近 Ethereum 的安全繼承。

- 你需要現成的流動性、錢包支援、工具鏈與使用者習慣。

## 才考慮 Layer 3 的情況

- 你真的需要客製隱私、治理規則或執行邏輯。

- 你的場景很窄，例如遊戲、RWA、特定企業流程。

- 你能清楚說出 Layer 2 做不到、但 Layer 3 做得到的那件事。

## 我會直接問團隊的 5 個問題

1. Layer 3 具體解決了什麼，Layer 2 解不了？

2. 我多加了一個什麼 trust assumption？

3. 使用者從哪裡橋過來，多久會橋一次？

4. 父層 Layer 2 壅塞或故障時怎麼辦？

5. 如果 Layer 2 再便宜一半，這個選擇還成立嗎？

## 一句話規則

如果答案只是「更快」或「更多」，先留在 Layer 2。

如果答案是「更專門的行為」，Layer 3 才有討論空間。

## 可直接貼進架構文件的版本

我們先選 Layer 2，因為我們需要較低費用、較高流動性、以及更直接的 Ethereum 安全繼承。

只有在我們需要 app-specific 隱私、客製執行、或 Layer 2 無法乾淨支援的工作流時，才會評估 Layer 3。

任何 Layer 3 設計都必須在上線前寫清楚 trust assumptions、橋接路徑、停機與故障模式。

我對這篇 FinanceFeeds 文章的結論很簡單：Layer 2 是主力擴容，Layer 3 是專門化選項。前者解決的是「Ethereum 變得能用」；後者解決的是「某個應用想要更特殊」。這兩件事完全不同，混在一起講，只會讓團隊多做很多沒必要的功課。

來源：FinanceFeeds 原文。我用它當起點，補了我自己的工程判斷、取捨框架和可直接複製的模板；技術背景另外參考了 L2BEAT、Ethereum scaling docs、以及 Vitalik Buterin 的文章。