L2Beat 詳細紀錄了幾乎所有 Ethereum 上的 L2，包含它們的 TVL、架構，合約地址、Admin 權限、安全等級及安全注意事項等等，還延伸包含了像是不同跨鏈橋與不同 Data Publication（即 Data Availability） 項目的安全性與分析。但要看懂不同分類、不同指標，並了解背後的差異並不容易，本篇文章將解析 L2Beat 上的各種資訊及其背後含意。

如果希望能更完整吸收這篇文章的內容，可以先閱讀過以下主題：

• Rollup 和 L2
• 跨鏈橋
• Data Publication

注意：本篇文章參考的是 2025/04 的 L2Beat 網站介面，網站未來可能會新增或刪去資訊導致看起來和文章裡的截圖不一樣。

L2s Summary

主頁 Summary 可以看到不同 L2 的排名，上圖中上方的三個標籤頁「Rollups」、「Validiums & Optimiums」、「Others」分別代表不同 Data Publication 設計的 L2。

• Rollup 將 L1 作為資料發佈層
• Validiums & Optimiums 採用 L1 以外的方案作為資料發佈層
• Others 裡的 L2 則是因為缺乏證明系統（ZK 或 OP 的挑戰機制）或足夠安全的資料保障，而被歸類在這

如上圖中所示，L2Beat 為 L2 列出的屬性包含 「RISKS」、「TYPE」及「STAGE」。「STAGE」目前是 Rollup 才有，非 Rollup 則是顯示其「DA LAYER」

1. RISKS：包含一個 L2 在不同功能上的安全程度
2. TYPE：這個 L2 是 ZK 還是 OP
3. STAGE：這個 Rollup 成熟的程度，總共三個階段
4. DA LAYER：這個 L2 將資料發佈到哪

1. RISKS

RISKS 裡共分為五個面向「STATE VALIDATION」、「DATA AVAILABILITY」、「EXIT WINDOW」、「PROPOSER FAILURE」及「SEQUENCER FAILURE」。如果點進去可以看到更完整的資訊。

STATE VALIDATION
“該 L2 的狀態有效性是如何被確保的”。可以是密碼學的 ZK Proofs 或挑戰機制的 Fraud Proofs。ZK Proofs 有分 ST(ARK) 或是 SN(ARK)；Fraud Proofs 有分 1R 或是 INT，代表一回合或多回合制的挑戰機制。如果發起挑戰機制有白名單限制的話評分會被降級（降為黃色或紅色）。

註：挑戰機制的設計會同時附註挑戰期（challenge period）的長度。

DATA AVAILABILITY
“該 L2 的資料發佈到哪”。Rollup 都是綠色的（顯示為 Onchain），代表資料沒有額外的信任假設；非 Rollup 則是紅色的（顯示為 External）。

另外 Onchain 有分是否有「（SD）」的備注：

• 有（SD）備註代表該 Rollup 上傳的資料是每個區塊壓縮過後的狀態差異（State Diff）
• 沒有（SD）備註代表上傳的是每個區塊的每一筆交易資料

註：ZK Rollup 才可以在不影響安全性的前提下選擇資料上傳是否要用 State Diff。

EXIT WINDOW
“如果該 L2 進行一個使用者不喜歡的版本升級，則使用者有多少時間可以退出該 L2”。

• 如果升級生效的時間足夠長到讓使用者成功發起離開請求並成功在 L1 取回該取得的資產的話，那就是綠色的，並顯示升級生效時間
• 如果有緊急保護措施例如安全委員會（Security Council）可以讓升級馬上生效的話就會降級為黃色
• 如果升級本來就會馬上生效的話那就是紅色的。

如果為綠色或黃色，則鼠標移到天數上時 L2Beat 還會詳細列出「升級生效時間」、使用者「發起退出請求」及「完成退出」最長各需要多少天。如果該 L2 合約為不可升級，則 EXIT WINDOW 會是無限（因為就不需要擔心合約被惡意升級）。

SEQUENCER FAILURE
“如果負責排序交易並出塊的排序器（Sequencer）下線了或在審查某些使用者的交易時，使用者可以怎麼繞過排序器並自行插入交易”。

• 如果使用者可以自行從 L1 插入交易並在延遲結束後自行完成插入，那就是綠色的（Self sequence）
• 如果使用者只可以插入交易但是不能自行「完成」插入的話，那就是橘色的（Enqueue via L1）
• 如果使用者完全沒辦法自行插入交易的話，那就是紅色的（No mechanism）。

像 ZKsync 目前就屬於 Enqueue via L1：使用者可以自行插入交易，但延遲結束後排序器可以選擇不處理，導致用戶的交易一樣無法被收入區塊中。不過排序器只能全都處理或全都不處理，不能單獨不處理某些使用者。

另外還有少數 L2 是屬於 Force via L1 的設計。在這種設計中，使用者可以自行插入交易，而如果排序器沒有在時限內收入使用者交易的話，使用者就可以觸發 L2 的暫停程序，該 L2 將完全停止並讓使用者各自提供資產證明來將資產退出 L2，這個機制稱為 Escape Hatch。

註：自行插入交易到完成插入之間會需要一段延遲是因為要避免惡意使用者透過直接在 L1 插入交易來影響或打亂排序器出塊的過程。想了解更多自行插入交易（Force Inclusion）的細節可以參考這篇文章：

Rollup 的 Force Inclusion 機制介紹

PROPOSER FAILURE
“如果負責提交 L2 最新狀態的 Proposer 下線了該怎麼辦”。

• 如果任何人都能接替成為 Proposer 或是有 Escape Hatch 機制來暫停 L2 並讓所有人撤離的話，那就是綠色的（Self propose 或 Use escape hatch）
• 如果只有白名單的人可以擔任 Proposer，但治理機制可以替換 Proposer 的話，那就是橘色的（橘色的 Cannot withdraw）
• 如果 Proposer 是白名單且沒辦法替換的話，那就是紅色的（紅色的 Cannot withdraw）。

2. TYPE

TYPE 有分「ZK Rollup」、「Optimistic Rollup」、「Validium」、「Optimium」四種。

• 把資料發佈到 L1 的是 Rollup。按照 State Validation 機制可分為用 ZK 或 Optimistic 兩種，例如 ZK Rollup 或 Optimistic Rollup。
• 如果是 ZK 機制但把資料發佈到 L1 以外的地方的話，會變成 Validium
• 如果是 Optimistic 機制但把資料發佈到 L1 以外的地方的話，會變成 Optimium

註：Validium 把資料發佈到其他地方並不會影響它的安全性，但 Optimium 的安全性和 Optimistic Rollup 相比則是大打折扣。想了解更多細節可以參考

Validity(ZK) Rollup 在上傳資料類型上的選擇

3. STAGE

STAGE 則是 Rollup 專屬，分為 STAGE 0~2。要成為至少 STAGE 0 得要符合以下條件：「定義自己為一個 Rollup」、「Rollup 的狀態根（State Root）要上傳至 L1 上」、「輸入到 State Transition Function 的資料要發佈至 L1 上」、「至少要有一個開源的軟體可以從發佈至 L1 的資料推導計算出該 Rollup 最新的狀態」，這幾個條件是為了要確保一個 Rollup 有最基本的安全性：

• Rollup 的狀態根（State Root）要發佈至 L1 上：狀態根要發佈到 L1 上，使用者才能透過狀態樹（State Tree）的 Merkle Proof 證明自己在 Rollup 上的資產多寡，或是證明自己在 Rollup 上發起的提款請求。否則只能仰賴中心化角色批准提款，沒辦法讓使用者自己證明的話，那安全性就會變得和 Side Chain 一樣低
• 輸入到 State Transition Function 的資料要發佈至 L1 上：「輸入到 State Transition Function 的資料」指的是例如 Rollup 交易資料，如果這些資料沒有發佈到 L1，那使用者就沒辦法推導計算出最新的 Rollup 狀態，也就沒辦法產生狀態樹的 Merkle Proof
• 至少要有一個開源的軟體可以從發佈至 L1 的資料推導計算出該 Rollup 最新的狀態：有了資料也仍然需要一個軟體可以推導計算出最新狀態，如果沒有一個開源軟體讓大家能下載使用，那等到出事時再寫可能就來不及了

STAGE 0：Full training wheel
當一個 Rollup 提供了最基本的安全性保障，但因為還在開發初期，所以沒有資源設置一個安全委員會來應付重大 Bug 或攻擊的發生，或 ZK/Fraud Proof 機制的運作仍然掌握在中心化角色手上，或甚至 ZK/Fraud Proof 還未上線。

要前進到 STAGE 1，Rollup 必須要達成「ZK/Fraud Proof 要上線並正常運作」、「如果是採用 Fraud Proof 機制，則至少要有五名開發團隊以外的角色可以發起挑戰或防禦」、「使用者可以自行退出 Rollup，不需中心化角色協助」、「需設立安全委員會，且至少要有 8 名成員與 75% 以上的執行同意門檻」及「如果是比安全委員會更中心化的角色啟動了一個異常升級，則使用者必須要有至少七天的窗口能退出該 Rollup」，這幾個條件是為了要確保一個 Rollup 足夠去中心化，讓使用者的安全性至少掌握在像安全委員會而非中心化角色手上。

• ZK/Fraud Proof 要上線並正常運作：如果沒有正常運作的 ZK/Fraud Proof，那該 Rollup 的安全性基本上就和 Side Chain 一樣
• 如果是採用 Fraud Proof 機制，則至少要有五名開發團隊以外的角色可以發起挑戰或防禦：確保發起挑戰或防禦的權利不會只落在開發團隊手上，在攻擊發生時有人能跳出來保障使用者
• 使用者可以自行退出 Rollup，不需中心化角色協助：即便 ZK/Fraud Proof 可以確保使用者安全性，但如果退出 Rollup 還把持在中心化角色手上，則還是有被審查的風險
• 需設立安全委員會，且至少要有 8 名成員與 75% 以上的執行同意門檻：安全委員會是在緊急狀況發生時能直接介入啟動立即升級的角色，主要是確保 ZK/Fraud Proof 機制或 L1 合約出問題可以及時修補漏洞，但也因此它的去中心化及執行同意門檻要求也特別高
• 如果是比安全委員會更中心化的角色啟動了一個異常升級，則使用者必須要有至少七天的窗口能退出該 Rollup：確保如果安全委員會不存在或安全委員會無法正常運作，則在 L1 合約出現漏洞或中心化角色作惡導致觸發惡意升級時，使用者要有足夠時間可以退出該 Rollup

STAGE 1：Limited training wheel
進到 STAGE 1 後 Rollup 已經有基本的去中心化程度 — 安全委員會可以及時介入或是使用者有足夠多的時間在無退路的情況下退出 Rollup，剩下的就是再進一步降低信任需求。

要進到 STAGE 2，Rollup 必須要達成以下條件：

1. 「如果是採用 Fraud Proof 機制，則任何人都要可以發起挑戰或防禦」：也就是真正實現 Fraud Proof 的 1-of-N 安全假設 — 只要該 Rollup 有至少一個人在監督就可以確保所有人的安全，不需仰賴白名單裡的人去監督
2. 「如果使用者不喜歡最新的升級改動，他是否有至少 30 天的時間可以退出該 Rollup」：當一個 Rollup 決議進行升級後，讓使用者們有充足的時間決定是否要留下或退出該 Rollup
3. 「安全委員會能立即升級的權力是否能限縮於出現漏洞的情況」：如果 安全委員會立即升級的操作能限縮在 ZK/Fraud Proof 或 L1 合約出現漏洞的情況，使用者們就不需擔心安全委員會如果作惡可以突然進行升級

這幾個條件是為了要確保一個 Rollup 足夠成熟能讓不認同該 Rollup 的使用者在充足的時間下決定是否要留下或退出，以及更進一步限縮關鍵角色的權力和中心化程度。

STAGE 2：No training wheel
STAGE 2 已盡可能降低信任需求，且使用者有充足的時間可以退出，不過目前只有少數 Rollup 達到 STAGE 2。

想了解更多關於 Rollup Stage 的介紹可以參考 L2Beat 的文章：

Introducing Stages — a framework to evaluate rollups maturity

註：但仍然有些人覺得可升級合約和安全委員會是安全隱患，所以提出了叫 Unstoppable Rollup 的概念。

4. DA LAYER

Validiums & Optimiums 因為不是將資料發佈到 L1 上，所以 L2Beat 會記錄它們將資料發佈到哪。除了有額外的信任需求（例如發佈到 Celestia 就要額外相信 Celestia 的安全性），Validiums & Optimiums 還需要額外煩惱跨鏈橋的安全性，因為 Validiums & Optimiums 的 L1 合約沒辦法知道資料到底發佈了沒、發佈的到底是不是正確的，所以合約必須仰賴一個跨鏈橋將訊息從資料發佈層（例如 Celestia）帶過來驗證。以 Manta 為例，它將資料發佈到 Celestia 上，它在 L1（Ethereum）的合約就會需要有人將 Celestia Validator 們的簽名帶過來驗證，以確保它預期的資料真的有發佈到 Celestia 上、被 Celestia Validator 們所保管著。但因為這通常牽涉到一次驗證數百、數千個簽章且頻率很高，所以目前基本上大部分的 Validiums & Optimium 都不支援 DA 跨鏈橋，因為成本划不來。

另外還需要考慮的是如果資料發佈層的保管者沒有確實下載資料並保管呢？該資料發佈層是否有機制能懲罰它們？在下方的「Data Availability 章節」會再深入介紹資料發佈層的安全性分級。

Project Detail

每個 L2 點擊進去都有更完整的資訊，除了基本的 TVL、TPS、L1 合約之外，從技術架構介紹到風險分析，甚至項目的里程碑及重大事件都有記錄。

以 Arbitrum 為例：

Risk Summary

• 如果 L1 合約進行惡意升級的話，則使用者資產有可能被全部盜走。升級除了由安全委員會執行是立即生效之外，都會有 17 天 8 小時的延遲（點擊連結的話會進到技術及天數計算的解釋）
• 如果攻擊者在 Arbitrum 的 Fraud Proof 機制中透過和守護者打消耗戰的方式拖過挑戰期的話，則使用者資產有可能被全部盜走
• 如果挑戰機制設計或實作有誤，則使用者有可能遺失資產
• 如果排序器作惡，則可以從使用者交易中套取 MEV

L2Beat 也為每個 L2 紀錄相當完整的技術和架構細節，如果該 L2 提供的文檔和開源程式碼越多，L2Beat 就能記錄得越詳盡。

State derivation & validation

State derivation 及 validation 介紹 L2 的狀態是如何推導計算而來、採用的交易格式及資料壓縮技術，以及如何進行驗證（ZK 或 Fraud Proof），甚至不同 Fraud Proof 機制也一樣有圖片搭配簡介：

Operator & Sequencing

Operator 及 Sequencing 的部分介紹排序器是否中心化、使用者是否有權力自行安插交易，以及如何自行安插交易：

• Arbitrum Operator（即排序器）為中心化，所以如果作惡的話可以榨取使用者交易的 MEV
• 使用者可以到 L1 自行安插交易，排序器必須要在最晚一天等待期內收入使用者交易，否則使用者在等待期結束後可以自己完成安插

Other considerations

L2Beat 也會紀錄一些 L2 標準技術以外，但值得留意的事情，例如：

• Arbitrum 同時支援 EVM 及 WASM VM，開發者可以利用 Solidity 或 Stylus 語言開發智能合約，不過這也增加了其挑戰機制的複雜度，如果挑戰機制設計或實作出了問題，使用者可能會因此遺失資產
• Arbitrum DAO 可以對 L2 & L1 合約進行升級：Arbitrum DAO 的治理發生在 L2，每次治理通過 L2 合約升級會首先有一個 8 天的延遲，接著升級 L1 合約會再經過 3 天延遲，然後因為升級 L1 合約是由 L2 所發起，所以和一般 L2->L1 交易一樣會經過 6 天 8 小時挑戰期，所以一共需 17 天 8 小時來完成 L2 & L1 合約升級

Upgrades & Governance

L2Beat 也詳盡地列出 L2 治理的執行過程，包含整體架構、牽涉到的合約，以及參與的角色等等：

Data Availability

Data Availability 頁面紀錄每個 L2 在資料發佈方面的技術方案及相關的安全等級，包含「DA LAYER」、「DA BRIDGE」、「RISKS」、「TYPE OF DATA」。

DA LAYER

L2 將資料發佈到哪？（對 Ethereum L2 來說）最安全的是發佈到 Ethereum，就完全不需要額外的信任假設，而 Rollup 都是發佈到 Ethereum。而屬於 Validiums & Optimiums 的 L2 就會發佈到其他地方，例如 EigenDA、Celestia、Avail、DAC，這些資料發佈解決方案有各自的安全假設及不同的經濟安全性，另外也要注意是否有 DA BRIDGE 來讓 L2 驗證 DA LAYER 的驗證者簽章，而不是單純相信 DA LAYER 會保管好資料。

DA BRIDGE

如果資料並非發佈在 Ethereum 上，那就需要一個橋來讓部署在 Ethereum 上的 L2 合約知道「資料是否已被正確發佈」，通常會包含驗證該 L2 使用的 DA LAYER 的驗證者的簽章，例如 Manta 將資料發佈到 Celestia 上，那 Manta 在 Ethereum 的合約就會需要透過 Celestia 提供的 DA BRIDGE 去驗證 Celestia 驗證者們的簽章，確保 Celestia 驗證者們真的有好好保管這些資料。不過單純驗證簽章也仍然不夠安全，因為這代表驗證者們欺騙該 L2 是沒有成本的，更可靠的做法是在驗證者們說謊時能懲罰他們。

TYPE OF DATA

L2 發佈的是「交易資料（Transaction data）」還是「區塊的前後狀態差異（State diff）」，以及這些資料是否有經過壓縮再發佈。採用 State diff 在某些假設下可以產生更少的資料，資料發佈的成本也就越低，但相對地在鏈下網路要去同步交易資料就會比較複雜。

RISKS

如果點進一個 L2 的 RISKS 圖示，會跳轉到更詳細的 Data Availability 分析頁面，分析不同 DA LAYER 及 DA BRIDGE 的風險：

L2Beat 將資料發佈風險的考量分為 DA LAYER 及 DA BRIDGE 兩類。

• DA LAYER 有兩點風險考量：「ECONOMIC SECURITY」、「FRAUD DETECTION」
• DA BRIDGE 有三點風險考量：「COMMITTEE SECURITY」、「UPGRADEABILITY」、「RELAYER FAILURE」

DA LAYER — ECONOMIC SECURITY
如果 DA LAYER 驗證者說謊的話，他們會不會付出代價？如果說謊會導致他們質押的代幣被銷毀，那就是綠色的（Staked assets）；如果是影響他們的聲譽，那就是橘色的（Public committee）；如果什麼代價都不必付出，那就是紅色的（No slashing）。

DA LAYER — FRAUD DETECTION
那要怎麼知道驗證者們說謊？要看該資料發佈解決方案的設計，像是 Celestia 或 Avail 就有提供 Data Availability Sampling（DAS）技術，來讓使用者可以透過鏈下節點「偵測」驗證者們是否有真的保管好資料，或甚至是讓使用者們可以合力「還原」出完整資料，進一步提高驗證者們作惡的難度。更多關於 DAS 的介紹可以參考：

Data Availability Sampling（一）：為什麼會需要 DAS？

如果有提供 DAS 並支援「還原」資料的能力，那就是綠色的（DAS）；如果只有支援「偵測」資料發佈不完整的能力，但不支援還原的話，那就是橘色的（DAS）；如果不提供 DAS，那就是紅色的（None）。

不過要特別注意，這些「偵測」與「還原」能力僅只限於鏈下的使用者才能使用，Ethereum 上的 L2 合約無法自己運行節點並執行 DAS，它只能仰賴別人告訴它，而鏈上最可靠的資訊來源就是透過 DA BRIDGE 傳來的驗證者們的簽章，如果超過一定數量的驗證者簽名表示資料已發佈，那 L2 合約就相信資料已發佈。這表示如果驗證者們說謊，它們是可以騙過 L2 並造成傷害的，這時會需要仰賴鏈下使用者們發現驗證者們說謊並透過 Slashing、治理或硬分叉機制去懲罰驗證者們。

DA BRIDGE — COMMITTEE SECURITY
要說服 L2 合約「資料已發佈」，會需要超過一定數量的驗證者的簽名，這個門檻的選擇會影響該 L2 的安全性及活性（Liveness）：如果門檻越高（例如 2/3），那就越安全，但也表示只要超過 1/3 驗證者不在線、不簽名，那該 L2 就會停擺；如果門檻越低（例如 1/2 或 1/3），那就能容忍越多驗證者不在線或不簽名，越不容易停擺，但相對的要騙過 L2 合約就變得越容易。

目前 L2Beat 定義如果「驗證者數量太少」、「驗證者同不夠多樣化」、「門檻定義的不夠嚴謹」或其他原因例如「資料發佈仰賴該 L2 的中心化排序器在線」，那 COMMITTEE SECURITY 就會是紅色的；如果驗證者夠多樣化且門檻夠高，使得只要少數（< 33%）驗證者是好的就能防止 L2 合約被騙，那就是橘色的；如果驗證者的組成不是由中心化角色所決定，那就能從橘色變成綠色的。

DA BRIDGE — UPGRADEABILITY
如果用來通知 L2 合約「是否有足夠多的驗證者已簽名」的 DA BRIDGE 合約是可被立即升級的，那就有可能被攻擊者替換掉並欺騙 L2 合約，那 UPGRADEABILITY 就是紅色的（No delay）；如果升級有延遲，但延遲不夠久或有安全委員會可以執行立刻升級，那就是橘色的；如果升級延遲久到讓 L2 使用者有足夠時間退出，那就是綠色的（但目前沒有 DA BRIDGE 達成綠色的 UPGRADEABILITY）。

DA BRIDGE — RELAYER FAILURE
負責將驗證者帶到 DA BRIDGE 合約的 Relayer 角色是否是中心化的？如果是中心化且沒有機制可以替換掉 Relayer，那就表示 Relayer 一但下線，L2 就會停擺，那就是紅色的（No mechanism）；如果有機制（例如 Governance）可以替換 Relayer，那就是橘色的；如果任何人都可以當 Relayer，那就是綠色的（Self propose）。

DA Layer Detail

每個 DA LAYER 點擊進去都有更完整的資訊，有基本的 Total Value Secured（TVS）、經濟安全性（Economic security）、資料頻寬（Max throughput）、資料保存時間（Duration of storage）、被哪些 L2/L3 所使用，另外像技術架構介紹到風險分析，甚至項目的里程碑及重大事件也一樣都有記錄。

• Total Value Secured：所有使用該 DA LAYER 的 L2/L3（但不包含 Sovereign Rollup）的總 TVL
• 經濟安全性：該 DA LAYER 的驗證者們說謊時是否會受到經濟上的懲罰，而這懲罰金額有多少
• 資料頻寬：該 DA LAYER 每秒可以發佈多少 MiB 的資料上去
• 資料保存時間：資料發佈到該 DA LAYER 後，它的驗證者們會保管資料多久（這段時間是用來確保資料有正確被發佈、可被檢驗，不是用來確保資料「永遠可取得」，永遠可取得的特性是 L2/L3 要自己確保的，例如 Archive 節點）

以 EigenDA 為例，它細分為「No DA Bridge」與「有 DA Bridge（Service Manager）」兩種分析：

以下以「有 DA Bridge（Service Manager）」為例。

Risk Summary

• EigenDA 負責處理資料發佈的 Disperser 角色可以審查、不處理使用者的交易。目前 Disperser 是由 Eigen Labs 營運，如果未來由 L2 自己營運且能去中心化的話，那就能免去使用者交易被審查的風險
• 如果 EigenDA 的 DA Bridge 合約、Eigen DA 仰賴的 EigenLayer 合約、提供經濟安全性的 EIGEN 代幣合約，任一個合約進行惡意升級導致 L2 上當相信一個其實沒有被正確發佈的資料，那就會導致資料不可得，使用者可能沒辦法獲得 L2 最新的狀態來證明自己的資產
• 如果 EigenDA 的驗證者們被惡意踢除，或 DA Bridge 合約因技術問題導致可以被惡意驗證者欺騙，那一樣會導致資料不可得，使用者可能沒辦法獲得 L2 最新的狀態來證明自己的資產
• 如果中心化 Relayer 下線或 DA Bridge 合約被暫停，那 L2 就會停擺，使用者無法提取資產

L2Beat 也會介紹每個 DA Layer 的技術架構和合約細節。

Technology

Architecture 介紹 DA Layer 的架構。以 EigenDA 為例，L2 排序器將交易排序好後，交給 Disperser 進行資料發佈的準備，準備完後將不同段的資料交給不同 EigenDA 節點（即驗證者）保管。另外有一個 Retriver 角色是代為需要資料的使用者去向節點請求不同資料片段並進行組裝與還原。

每一個 DA LAYER 的架構和技術方案都不一樣，不像 Rollup 有許多共同的基礎元件可以互相比較不同 Rollup 設計，但 L2Beat 仍然非常詳盡地記載這些 DA LAYER 的技術細節。

參考資料與推薦延伸閱讀

• https://l2beat.com/scaling/summary
• https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe
• https://l2beat.com/scaling/projects/arbitrum
• https://l2beat.com/scaling/data-availability
• https://l2beat.com/data-availability/projects/celestia/no-bridge#da-layer

TEM Medium 2025 有獎徵稿

TEM Medium 目前正在進行有獎徵稿！詳情請參考：

TEM Medium 有獎徵稿

Special thanks to and for reviewing and improving this post

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