Data Availability Sampling（三）：Celestia, Avail and EigenDA
Celestia、Avail 及 EigenDA 各是怎麼實現 DAS 的？它們的設計之間有什麼不同或取捨？[2024/06/16 新增 Espresso 的 Tiramisu DA 介紹和比較]
先備知識：
- 知道 DAS 的目的及運作方式
以下會以 資料發布（Data Publication）來稱呼 資料可得性（Data Availability），但某些 Data Availability 相關的詞彙例如 DAS、DAC 則會保留原字，避免讀者無法和英文原文連結。關於 Data Publication 這個名稱的介紹可以參考：
上一篇介紹了 DAS 如何在 Ethereum 的 Danksharding 中實現，這篇將會介紹 DAS 如何在 Celestia、Avail、EigenDA 及 Tiramisu DA 中實現，以及不同設計之間的比較。
Celestia
Celestia 是一條專注在解決資料發布問題的公鏈，它沒有像是 Ethereum EVM 一樣複雜、功能繁多的虛擬機，它不對發布到它上面的資料做任何解讀和執行（而是由資料發布者自己解讀並執行），它做的唯一事情就是確保資料的排序以及確保資料是有被發布的、是可得的。
也因為它不會執行複雜的交易、沒有智能合約的概念，所以它儲存的狀態非常單純（例如一個地址有多少錢），也沒有像是 Ethereum 遇到的 State Bloat 的問題。
Namespaced Merkle Tree (NMT)
Celestia 使用 Namespaced Merkle Tree 來 Commit 資料。相比於 (Binary) Merkle Tree，NMT 的葉節點都會加上一個 Namespace 的前綴且葉節點會按照 Namespace 的值來進行排序。
如果沒有 Namespace，當 Rollup Sequencer 上傳資料到 Celestia，Rollup 的其他節點沒有辦法很方便地去向 Celestia 查詢該 Rollup Sequencer 上傳的資料，其他節點必須得下載完整的 Celestia 區塊資料然後再從中找出它想要的 Rollup 資料；如果有了 Namespace 前綴，Rollup 其他節點就可以很方便地向 Celestia 查詢特定 Namespace（例如 sha256(“MyRollup”)）的資料，取得它的 Rollup 的資料及驗證用的 Merkle Proof，而不需要下載任何該節點沒興趣的資料。
不過因為 NMT 也是屬於 Merkle Tree 的 Commit 方式，所以像前一篇提到的，它不像用 Polynomial Commitment 一樣本身就能證明資料有經過糾刪碼編碼，因此 Celestia 輕節點需要等待一段挑戰期，如果挑戰期結束前都沒有收到詐欺證明，那就相信資料有經過糾刪碼編碼。
註：挑戰期目前沒有定出一個明確的數字，只有理論上的「p2p 網路的傳輸延遲時間」上限，也就是相信當全節點發現資料沒有經過糾刪碼編碼，馬上就會做出詐欺證明並傳送到 p2p 網路中，而只要輕節點及 p2p 網路沒有問題，在 p2p 網路的傳輸延遲時間內輕節點就都會收到詐欺證明。
Celestia 選擇用 Merkle Tree 而不是使用 Polynomial Commitment 是因為 Polynomial Commitment 的運算資源需求更高，Celestia 不希望運算資源需求拉高導致成為驗證者的門檻提升，因而降低網路去中心化程度。
註：Celestia 也是這四個 DA 方案中唯一一個使用 Merkle Tree 作 Commitment 的，Danksharding、Avail 及 EigenDA 都是使用 Polynomial Commitment（KZG）作 Commitment。
不管哪一種 Commit，安全性都必須仰賴 p2p 網路有正常運作
有些人覺得用 Merkle Tree commit 需要等 p2p 網路有人傳詐欺證明的這個假設會降低安全性，覺得採用 Polynomial Commitment 就不需要擔心 p2p 網路出問題會影響安全性，但事實上還原完整區塊資料的過程還是需要仰賴 p2p 網路保持同步狀態，因為全節點要透過 p2p 網路搜集採樣，如果 p2p 網路出問題導致全節點沒收到足夠採樣，那就沒辦法成功還原，所以 p2p 網路保持正常運作、保持同步的假設是必須的。因此採用 Merkle Tree 作為 Commitment 並不會因此比採用 Polynomial Commitment 更不安全。
驗證者及輕節點
Celestia 的驗證者會下載完整的區塊資料並投票，不像 Danksharding 中驗證者只需要負責整個區塊中特定幾行及幾列的資料。和 Danksharding 一樣，Celestia 區塊的內容只會被保存一段時間（例如 30 天），稱為 Recency Window，30 天過後資料就會從節點上被刪除。資料的主人或是任何對該資料有興趣的要自己保存起來，例如 Rollup 節點們或是 Rollup 服務提供商會下載並保存該 Rollup 的完整資料。
註：但目前 Celestia 的實作還是會持續保存所有資料，刪除舊資料的功能還在實驗中。
Celestia 的輕節點們會運行 DAS，和 Danksharding 一樣，但和 Danksharding 不同的是 Celestia 會隨著輕節點數量來調整區塊大小：如果輕節點數量上升，那就可以將區塊加大而不會影響安全性；如果輕節點數量下降，那就需要將區塊縮小以維持一樣的安全性。如此便能做到「網路的參與者（即輕節點）越多，網路的 Throughput 就越高」，達到真正 Scaling 的效果，而且手續費還會跟著降低。
註：但目前「隨著輕節點數量調整區塊大小」的功能還沒有實作出來，還有一些棘手的挑戰需要解決：(1) 驗證者還是會下載完整區塊，所以加大區塊等於是增加驗證者的負擔，區塊大小很難真的能隨輕節點數量增加而無限加大，(2) 要怎麼確認這些輕節點是正常使用者所運行的輕節點，而不是攻擊者輕鬆用 AWS 跑起的一堆虛假輕節點？這和 p2p 網路的設計如何對抗女巫攻擊是一樣的問題。
輕節點的數量和 DAS 的安全性成正比，因此 Celestia 投入許多資源在輕節點的推廣上。Celestia 在今年五月推出輕節點挑戰來推廣輕節點，這個挑戰在 Twitter/X 上造成一股風潮，大家紛紛貼出各種用來運行輕節點的奇耙裝置、貼出在特別的地點或場景運行輕節點，以及製作各種輕節點迷因。有興趣的可以看八月公佈的比賽結果。
效能瓶頸
DAS 中主要的瓶頸不會是儲存空間的需求或是運算的需求，而是網路頻寬的需求，因為要頻繁透過網路索取或分享資料採樣。有人認為根據尼爾森定律（Nielsen’s Law of Internet Bandwidth），網路頻寬增加的速度會快過資料需求增長的速度，因此不需要擔心會碰到效能瓶頸，或甚至可以持續提高區塊大小。
p2p 網路
Celestia p2p 網路採用 IPFS 的 DHT 網路設計，但目前沒有看到任何關於 Celestia 如何預防女巫攻擊、p2p 惡意行為的考量，或著是要怎麼確保輕節點 p2p 網路會持續保存著過去的採樣以供索取。
Blobstream
Blobstream 是 Celestia 推出來吸引 Ethereum L2 的一個服務。對不將資料發布到 Etherum 的 L2（例如 Validium）來說，將資料發布到 Celestia 會比將資料交給一個 DAC 保管還來得安全許多。
L2 可以透過 Blobstream 來確認資料有被發布到 Celestia 上。Ethereum 上會有一個 Blobstream DA 合約來驗證 Celestia 的驗證者簽名，如果驗證者都對某個區塊簽名，L2 就相信資料有被發布到 Celestia 上。
但如果 Celestia 停止運作的話，L2 該怎麼辦？因此我們需要有一個 Fallback，在 Celestia 停止運作時還能持續將資料發布到某個地方，例如 Fallback 回 DAC 或直接發布到 Ethereum 上。Celestia 目前正在實驗透過 OP Stack 建立一個 Blobstream 的模組，讓 OP Stack 的 L2 在平時能藉由將資料發布到 Celestia 來降低成本，但在 Celestia 因意外停止運作時能 Fallback 回將資料發布到 Ethereum 上。
不過要注意的是：Blobstream 的使用者是 Ethereum 上的合約，合約本身沒辦法做 DAS，因為它的採樣都是公開的，攻擊者可以輕易地提供它採樣的資料讓它以為資料有被完整發布。因此 Blobstream 使用者（也就是 Ethereum 合約）的安全性是建立在 Honest Majority，也就是「大多數 Celestia 驗證者是好人」的前提下，而不像輕節點是更安全的 Honest Minority 假設。
輕節點的資料發布安全等級
Celestia 研究員為輕節點在資料發布這一塊的安全性劃分了不同等級，等級越高代表安全性越高。
等級 -1：全節點
作為一個比較的基準點，會親自下載完整資料的全節點的資料發布安全等級在 -1。
等級 0：沒有安全性保證
沒有任何人可以保證資料有被發布。文章中舉的例子是 NFT 的 IPFS URI。通常採用這種安全性的應用，其資料有沒有發布並不會影響安全性，NFT 的 IPFS URI 失效只是顯示不了圖片，但 NFT 還是你的🙂。
等級 1：Data Availability Committee
信任 DAC 會保管好資料。DAC 弄丟資料也只能雙手一攤，或是在現實世界中去對 DAC 咎責。
等級 2：DAC + Crypto-economic Security
相比於等級 1 必須完全信任 DAC，等級 2 的 DAC 如果作惡會受到經濟上的懲罰。DAC 必須要持有並抵押代幣，如此才能在作惡時被懲罰、銷毀抵押的代幣。但因為「藏資料」這個作惡行為沒辦法被證明，因此沒辦法直接在鏈上合約內去懲罰 DAC，而是得透過社會共識介入，大家一起硬分叉到一條新的鏈，在新的鏈上該 DAC 被懲罰，失去代幣。
註：其實 DAC 並非只是大家印象中的「由少數幾個可信角色組成的 DAC」，Celestia 驗證者們或其他鏈的驗證者們也可以視為是一種 DAC，不過是「會持有代幣的 DAC」。但當然這不表示 Celestia 就是屬於等級 2 的安全性，只是要強調這裡定義的 DAC 也涵蓋 Celestia 驗證者們。
等級 3：DAS but WITHOUT Honest Minority Light Clients
在這個安全性等級的設計中，輕節點們可以透過 DAS 來自己確認資料發布的安全性，但誠實的輕節點們數量卻不夠多到保證它們合力能用手上的採樣還原出完整的區塊，或甚至沒有一個 p2p 網路設計來讓輕節點們彼此分享採樣資料，因此雖然輕節點們都各自採樣了，但因為這些採樣不夠或不會共享，所以也沒人可以還原，等於是做半套的 DAS。
註：這種安全性設計出現的機率應該不高，只是單純作為定義上的區分而列出來。
等級 4：DAS with honest minority light clients
在等級 4 中有足夠多的誠實輕節點在進行採樣，而且它們能夠透過一個 p2p 網路分享採樣並合力還原，因此只要出塊者釋出足夠多的採樣就一定能還原出完整區塊。但因為採樣沒有隱私保護，所以出塊者可以鎖定特定輕節點並只釋出採樣給它們來騙它們上當（稱作 Selective Disclosure Attack）。
註：目前 Celesita 的設計應該是屬於等級 4 的安全性，全節點會透過 p2p 網路向輕節點們索取採樣並嘗試還原出完整區塊。但如果出塊者是惡意的，它還是可以鎖定特定輕節點來騙他們上當。
等級 5：隱私採樣
最高等級的安全性。輕節點採樣有隱私保護，因此出塊者沒辦法知道是誰來採樣、也沒辦法知道不同採樣是否來自於同一個輕節點，也就非常難騙到任何一個輕節點。
註：Celestia 論壇目前有幾篇文章在評估 Selective Disclosure Attack 及隱私方案。
Avail
Avail 和 Celestia 基本上非常相似，所以每一段介紹都會以 Avail 和 Celestia、Danksharding 的異同作為重點。
Avail 和 Celestia 一樣，都是專注在解決資料發布問題的公鏈，它不對發布到它上面的資料做任何解讀和執行，它做的唯一事情就是確保資料的排序以及確保資料是有被發布的、是可得的。同樣地，因為它儲存的狀態只有簡單的地址與餘額，也沒有像是 Ethereum 遇到的 State Bloat 問題。
一維糾刪碼編碼
從目前找的到的資料來看，Avail 會採用一維的資料糾刪碼編碼而不像 Danksahrding 或 Celestia 會將資料編碼成二維資料。一維編碼的優點是還原所需的門檻（50%）比二維（75%）低，但缺點是要還原就是得還原所有的資料，不像二維可以只還原其中一列或一行，因此還原的負擔會比較重。
KZG Commitment
Avail 和 Danksharding 一樣都是採用 KZG 來對資料進行 Commit，不像 Celestia 是使用 Merkle Tree。其優點是輕節點不需等待挑戰期和詐欺證明來確認資料是否經過糾刪碼編碼，缺點是產生 Commitment 需要使用更大量的運算資源。
Application ID
和 Celestia 的 Namespaced Merkle Tree 的用途一樣，Avail 也設計了類似的功能 — Application ID。不同 Rollup 會使用不同的 Application ID，Rollup 節點可以利用 Application ID 來識別自己 Rollup 的資料，也就不需下載其他它沒有興趣的（其他 Rollup 的）資料。
驗證者及輕節點
Avail 的驗證者和 Celestia 一樣都會下載完整區塊，輕節點也和 Celestia 及 Danksharding 一樣都會進行 DAS，但 Danksharding 的區塊大小是固定的，不像 Celestia 或 Avail 是能夠隨著輕節點數量而調整區塊大小。
不過調整區塊大小的功能還在討論設計階段，更詳細的分析可以參考 Avail 的這篇介紹文，基本上區塊大小的增減必須要在驗證者的工作量及全節點/輕節點的工作量之間做取捨。區塊加大可以分為「提高每個區塊可以收入的資料單位數量」或是「提高每個資料單位的大小」兩種方式，第一種方式會導致驗證者的工作量增加，而第二種方式則會造成全節點與輕節點的工作量增加。
p2p 網路
Avail 的 p2p 網路和 Celestia 一樣都是採用 DHT 網路設計，但目前也都沒有看到任何關於如何預防女巫攻擊、p2p 惡意行為，或著是要怎麼確保輕節點 p2p 網路會持續保存著過去的採樣以供索取的考量。
Attestation Bridge
和 Celestia 的 Blobstream 一樣，Avail 也有 Attestation Bridge 來讓 Ethereum 上的 L2 將資料發布到 Avail 上，再透過 Attestation Bridge 驗證資料有確實發布。和使用 Blobstream 的 L2 合約一樣，使用 Attestation Bridge 的 L2 合約也都不能做 DAS，所以也都必須仰賴「大多數 Avail 驗證者是好人」的假設。
另外 Avail 正在和 Succinct 合作開發一個雙向的輕節點跨鏈橋，而不像 Attestation Bridge 只是單向地將 Avail 上的驗整者簽章傳遞到 Ethereum 上去做驗證。這個雙向跨鏈橋會使用零知識證明來驗證彼此鏈的共識，透過零知識證明也能大幅降低驗證成本（也就是跨鏈成本）。
EigenDA
EigenDA 是 EigenLayer 團隊自己開發，也會是 EigenLayer 上第一個上線的服務。EigenDA 透過 EigenLayer 進行媒合，讓有資料發布需求的應用（例如 L2）能找到願意提供 DA 服務的驗證者。應用能享受到低廉的 DA 成本，而 Ethereum 的驗證者們也能從中獲得額外收益。
EigenDA 其實沒有 DAS！
相比於 Danksharding、Celestia 或 Avail，EigenDA 是基本上完全不一樣的設計，EigenDA 本身甚至不是一條鏈。EigenDA 像是一個有質押代幣的 DAC，也就是前面輕節點安全性等級中的等級 2：DAC + Crypto-economic Security。EigenDA 的安全性仰賴於「大多數的 EigenDA 驗證者是好人」。
EigenDA 沒有 DAS，輕節點沒辦法透過 DAS 自己確保資料有被正確發布，而因為 EigenDA 不是一條鏈，所以甚至可以說它沒有輕節點這種角色存在。為什麼會這樣設計？因為 EigenDA 將自己視為是 Ethereum Centric 的 DA 服務 — 它只服務 Ethereum 上的 DA 使用者（例如 Ethereum 上的 L2）。因此因爲需求不一樣，所以它也就不需要是一條鏈、不需要有 DAS！
為什麼 EigenDA 不需要是一條鏈？
EigenDA 意識到如果要服務的是 Ethereum 上的 L2，那 Ethereum 本身就在運行共識、對資料進行排序，在這種情況下 DA 服務本身只需要保管好資料，不需排序資料，也就不需要是一條鏈，因此省去運行共識驗算法的麻煩和成本。
註：自己運行一條鏈的 Celestia 或 Avail 更為通用，L2 不管是不是在 Ethereum 上都可以使用或直接搭建在 Celestia 或 Avail 上，將交易交給 Celestia 或 Avail 排序並確保資料發布，稱為 Sovereign Rollup。
為什麼不需要有 DAS？
因為 EigenDA 的使用者都是鏈上的合約（而不是鏈下的節點），如同前面提到，鏈上合約是沒辦法做 DAS 的，合約只能檢查 EigenDA 驗證者們的簽名來相信資料是否有被發布。
不過對 Ethereum 上的 L2 來說，其實不管是使用 Celestia、Avail 或 EigenDA，它身為一個合約都沒辦法做 DAS、沒辦法利用 DAS 來提升安全性，都得相信 DA 服務中的大多數驗證者是好人。所以對 Ethereum 上的 L2 來說，使用 EigenDA 所獲得的安全性保證並不會比 Celestia 或 Avail 來得低，比的其實都是驗證者的數量、去中心化程度和質押金額。
EigenDA 架構與運作流程
假設 EigenDA 的使用者是一個（Ethereum 上的）L2，該 L2 的 Sequencer 排序好 L2 交易和區塊後，會將資料交給一個 Disperser 角色（可以是 L2 自己或是第三方）。Disperser 要負責對 L2 資料做糾刪碼編碼以及 KZG Commitment，接著 Disperser 將編碼後的資料切不同段交給不同 EigenDA 驗證者。EigenDA 驗證者收到後會對資料做簽名並回傳簽名給 Disperser，Disperser 在搜集完驗證者簽名後將所有簽名聚合成一個，接著連同 KZG Commitment 和聚合簽章送到鏈上 L2 合約做紀錄，L2 合約會去驗證這些聚合簽名是有效的（是否是 EigenDA 驗證者們的簽名），驗證完後 L2 合約就相信 EigenDA 的驗證者們都有收到資料並會保管好資料。
註：Disperser 雖然是中心化角色，但它不影響安全性，頂多是它在無法運作時可能造成 L2 停擺，其實就和 Sequencer 一樣。
EigenDA v.s. Danksharding
撇除沒有 DAS 之外，EigenDA 其實和 Danksharding 非常相似，它們在資料編碼及 Commitment 方式上是一樣的，只是在將資料分配給不同驗證者時 EigenDA 是採用中心化的做法，由 Disperser 來負責分發給驗證者們，而 Danksharding 則是驗證者們透過 p2p 網路來進行採樣、獲取自己被分配到要保管的資料。透過這個中心化資料傳遞的作法以及不需運行共識演算法，EigenDA 的複雜度、成本與網路延遲的影響都大幅降低，連帶 DA 成本也能大幅降低，這讓 EigenDA 變成非常有競爭力的 DA 選項。
和 Danksharding 一樣，EigenDA 驗證者們針對每一份資料都只需要保管一定時間（目前都是約兩週），對資料有興趣的人都可以在保存期限內向驗證者索取（Danksharding 則是透過 p2p 網路索取）。
和 Danksharding 不一樣的是 EigenDA 每個驗證者負責保存的資料會和驗證者人數有關，越多驗證者加入，每個驗證者要負責保管的資料大小就越小，不像 Danksharding 中每個驗證者保管資料大小都是固定的，不管驗證者是多是少。如此 EigenDA 就能有效進行擴展 — 越多驗證者，網路能乘載的資料量就越多。
註：其實更精確地來說驗證者保管的資料量和他質押的金額有關，質押越多就要保管越多資料。不過相對地，這也表示硬體資源不多的驗證者還是可以參與質押（只是質押的少、賺的比較少），而不會出現質押多的人和質押少的人要保管一樣的資料量的情況，或是因為硬體需求門檻導致成本低的人沒辦法參與，這反而對去中心化有幫助。
另外 EigenDA 沒有 DAS，也就不需要煩惱輕節點 p2p 網路要保存資料多久、要怎麼避免網路因索取歷史資料造成壅塞、要怎麼防止節點惡意行為。
要怎麼確保驗證者真的都有下載資料來保管？
Eigen Layer 會透過 Proof of Custody 的技術來確保驗證者真的有把資料下載下來保管，而不是隨便簽名假裝有保管資料，或是多個驗證者共用同一份保存在雲端的資料而沒有各自下載並保管。Proof of Custody 要求：
- 保管資料的人要定期產生一個新的秘密值（Ephemeral Secret）並公布上一期的秘密值
- 如果秘密值被別人知道，則對方可以直接領走你的押金
- 保管資料的人要將資料搭配秘密值一起進行一個運算，運算的結果有兩種可能（以 0 或 1 代表），0 代表沒問題而 1 代表炸彈（要被懲罰）但要算出 1 的機率很低
因此真的有下載資料的人會確實進行運算，並在發現結果是 1 時選擇放棄、不簽名，雖然這會讓他錯過一次（小額）獎賞，但至少不會導致他被（大額）懲罰。而沒有真的下載資料的人因為沒辦法進行運算，所以沒辦法知道結果，因此只能進行盲簽。當每一個週期結束，大家公佈自己該期的秘密值時，有下載資料的人就可以用同一份資料搭配其他保管者的秘密值去驗算，看結果是不是 1，如果是 1 就表示那個保管者盲簽、根本沒下載資料，就可以沒收他的押金。沒有下載資料的人也不能請別人代為運算，因為運算需要秘密值，將秘密值交給對方，對方將可以直接領走押金。
註：Proof of Custody 機制是為了避免驗證者偷懶、多人共用同一份檔案而沒有各自保存，Proof of Custody 不是為了解決資料發布的問題。
較高的「即時」抗審查能力
EigenDA 強調他們的設計有較高的「即時」抗審查能力，「即時」指的是非常短期內、立即性的抗審查能力。這是因為 EigenDA 使用者（像是 L2 Sequencer）是「自己」向驗證者來遞送資料並收取簽名，而不像在 Celestia 或 Avail 中是由「每個區塊的出塊者」來決定要不要收取交易，因此 EigenDA 使用者不用擔心「短期內」有出塊者不願意收入交易而導致資料沒辦法被發布。
註：只要 Celestia 或 Avail 的驗證者們夠去中心化，就不用擔心「長期」交易被審查，所以 EigenDA 強調的是「短期」內的抗審查能力。不過這個的重要性就看每個使用者，並非每個 L2 都需要這個能力。
是否有自己代幣的差別
不像 Celestia 或是 Avail，EigenDA 不會有自己的代幣，因為它不是一條鏈，不需要靠代幣發行來獎勵驗證者或作為手續費。因此 EigenDA 不需要煩惱複雜困難的代幣經濟機制，但相對地，沒有自己的代幣的缺點是 — 當大多數驗證者一起作惡假裝資料有發布時，這些驗證者不會被懲罰！
在 Celestia 或 Avail 上，如果大多數驗證者作惡假裝資料有發布，這時運行 DAS 的輕節點不但不會上當，還能因此察覺到大多數驗證者正在聯合作惡，因為這些驗證者會對輕節點沒辦法採樣到的資料簽名。因此這些輕節點（也是網路中大多數人）可以透過社會共識進行硬分叉，將作惡的驗證者們從新分叉出去的鏈上移除，等於進行社會共識層上的 Slashing 懲罰。
但 EigenDA 做不到這件事，因為即便 EigenDA 驗證者有質押在 EigenLayer 上，但鏈上的合約沒辦法運行 DAS、沒辦法判斷到底資料有沒有發布，也就不能進行 Slashing。它只能相信大多數驗證者是好人！而且即便社會共識上大家同意 EigenDA 大多數驗證者正在作惡，但 Ethereum 也不可能為了 EigenDA 或 EigenLayer 而進行硬分叉去修改 EigenLayer 合約上的狀態、把作惡的 EigenDA 驗證者移除。
EigenLayer 當然也可以設置一個治理議會，交由議會經由社會共識來裁決、進行 Slash。但這會引入新的、對議會的安全性假設，如果議會作惡它就能任意 Slash 好的驗證者，而此時 Ethereum 一樣也不能透過硬分叉移除議會成員。因此這個方法未必是大家都能接受的方案。
彈性的付費方式與預留資料用量
如果一個 L2 要來使用 EigenDA，它不需要像 Celestia 或 Avail 一樣要先購買該條鏈的代幣來支付手續費，而是可以透過 EigenLayer 以 L2 自己的代幣來支付手續費給驗證者。
另外 EigenDA 也會讓使用者（L2）可以預訂資料用量，例如預訂未來半年共 100 GB 的資料用量，或是其他更客製化的選項，就像在使用 AWS 一樣。但是這在本身是一條鏈的 Celestia 或 Avail 上就做不到，除非某天 Celestia或 Avail 上出現了販售區塊空間的期貨市場。
Tiramisu DA [2024/06/16 新增]
Celestia/Avail DA 的生理，Eigen DA 的心理
Espresso 的 Tiramisu DA 和 Celestia/Avail DA 一樣都是跑一條鏈、運行共識演算法，它可以和 Celestia/Avail DA 一樣支援 Sovereign Rollup，但它的文檔卻甚少提到 Sovereign Rollup 或甚至沒有提到 DAS，而是和 Eigen DA 一樣主打服務（Ethereum 上的）Rollup，所以可以說 Tiramisu DA 像是 Celestia/Avail DA 與 Eigen DA 的混合體。
不過整體來說 Tiramisu DA 和 Celestia/Avail DA 還是比較像的，畢竟是否運行一條鏈、共識演算法仍是無法忽略的差異。如果 Celestia 與 Avail DA 也積極或甚至只專注於服務（Ethereum）L2，那它們和 Tiramisu DA 就會變得更像或甚至一樣 — 基本上都會直接廢棄掉 DAS，畢竟沒有用途。所幸目前 Celestia 是堅定地走在服務 Sovereign Rollup 的路上（Avail DA 則還未正式上線），否則看到它們捨棄辛苦打造的 DAS 而變成幾乎一樣的產品會是相當可惜。
為什麼還要運行一條鏈？
但如果 Tiramisu DA 和 Eigen DA 一樣專注於服務 Ethereum 上的 L2，那還運行共識演算法、一條鏈不就是沒事找事做嗎？這個問題的答案有兩個，首先 Espresso 並不是單純為了解決 DA 問題而設計出 Tiramisu DA，而是搭建在它原有的基礎之上 。Espresso 已經有運行共識演算法的基礎架構，它的 Sequencing Marketplace 與 Shared Finality Layer 這兩個元件都需要搭建在共識之上，而 Tiramisu DA 則是 Shared Finality Layer 元件能提供的其中一個用途。所以 Tiramisu DA 並不是為了解決 DA 而去運行共識演算法，而是利用共識演算法來順便解決 DA。
第二個答案是：相比於 Eigen DA，Tiramisu DA 其實有提供另一個特色，稱為 Optimistic Data Availability Certificate（Optimistic DAC），Optimistic DAC 由每一輪隨機選出的一個小委員會成員共同做出「資料已發布」的認可。只要 L2 願意相信「小委員會裡大多數的成員都是誠實的」，那該 L2 就無需等待所有 Tiramisu DA 節點們達成共識，算是提供一個安全性與速度之間的 Trade-off 給 L2 選擇。
Celestia、Avail、Danksharding 與 EigenDA 的比較
Commitment
除了 Celesita 使用 Merkle Tree 做 Commitment 之外，其他三者都使用 KZG。使用 Merkle Tree 沒辦法保證資料有經過糾刪碼，每收到一個新區塊都必須等待一段挑戰期，挑戰期間沒有收到詐欺證明才相信資料有經過編碼；使用 KZG 就不需要擔心資料沒有經過編碼，但相對地 KZG 比 Merkle Tree 更耗計算資源，製作 KZG Commitment 的節點硬體需求較高，且 KZG 需要經過可信設置（Trusted Setup）。
DAS & Light Client Security
只有 EigenDA 沒有 DAS，因此只有它的安全假設是 Honest Majority，也就是相信大多數驗證者是好人；其他有支援 DAS 的協議只需要仰賴 Honest Minority 的假設，只要有少數節點是好人即可。
註：EigenDA 的輕節點指的不是使用者自己在鏈下運行的輕節點客戶端，而是 Ethereum 鏈上的 L2 合約。
DAS p2p
Celestia 與 Avail 已經有在運行的輕節點 p2p 網路，都採用 DHT 設計，但都還沒有考慮攻擊者在 p2p 網路作惡的情況；Danksharding 則是還在設計中，不確定會用什麼樣的 p2p 設計。EigenDA 則沒有 p2p 網路。
DAS p2p Privacy
Celestia 與 Avail 都還沒有支援輕節點 p2p 網路的隱私，因此都沒辦法防止惡意出塊者想要欺騙被鎖定的輕節點；Danksharding p2p 網路還在設計中。
Expandable Block Size
Celestia、Avail 與 EigenDA 都可以隨著參與者數量調整區塊大小，Danksharding 沒辦法。Celestia 與 Avail 的參與者指的是輕節點，EigenDA 的參與者則是驗證者。
總結
- Celestia 研究員將輕節點的 DA 安全性區分成五個等級：(1) 最基本、安全性最低的純信任制 DAC、(2) 由 Crypto-economic 取代信任的 DAC、(3) 最基本的、沒有足夠輕節點或沒有 p2p 網路的 DAS、(4) 有 p2p 網路讓輕節點可以合力還原的 DAS，再到最高安全性的 (5) 提供隱私保護的 p2p 網路的 DAS
- Celestia、Avail 與 EigenDA 都是專注於解決 DA 問題的協議，做為 Danksharding 的競爭者
- Celestia 與 Avail 很相似，差異在鏈的共識算法、Commitment 及其他細節上，但兩者都支援 DAS，都提供一樣的安全性。Celestia 用 NMT 的資料結構方便其使用者僅需下載他有興趣的資料，而不需下載完整區塊內容；Avail 也透過 Application ID 達成一樣的目的。另外兩者為了吸引 Ethereum 上的 L2 來使用，都各自推出 DA 橋（Blobstream 與 Attestation Bridge）讓 L2 來使用
- EigenDA 則是為了不同目的而做出不同 trade-off：EigenDA 旨在服務 Ethereum 上的 L2，所以它不需自己運行一條鏈、運行共識演算法、運行 p2p 網路，也不需煩惱代幣經濟機制的設計，而是單純作為保管資料的用途，而且它還可以輕鬆支援彈性的付費方式及預留資料用量
- 但相對地 EigenDA 沒有 DAS，表示 EigenDA 的使用者需要仰賴大多數驗證者是好人的假設，而不能像在 DAS 中靠著自己去採樣來獲得更高的安全保證
- 另外 EigenDA 沒有自己代幣也就表示大多數 EigenDA 驗證者一起作惡時，它們沒辦法被懲罰，因為要 Slash 這些驗證者需要進行硬分叉來直接改寫鏈的狀態，而 Ethereum 不會為了 EigenDA 進行硬分叉
- 不過其實對 Ethereum L2 合約來說，使用 Celestia、Avail 或 EigenDA 的安全性假設都是一樣的 — 都必須仰賴大多數驗證者是好人，因為合約沒辦法進行 DAS。所以對 Ethereum L2 合約來說，使用 EigenDA 將會是較合理的選擇
參考資料與推薦延伸閱讀
Celestia
- https://members.delphidigital.io/reports/pay-attention-to-celestia
- https://docs.celestia.org/learn/how-celestia-works/data-availability-layer
- https://docs.celestia.org/learn/how-celestia-works/data-availability-faq
- Namespaced Merkle Tree: https://docs.celestia.org/learn/how-celestia-works/data-availability-layer#namespaced-merkle-trees-nmts
- Namespaced Merkle Tree: https://github.com/celestiaorg/nmt
- Blobstream: https://blog.celestia.org/introducing-blobstream/
- Celestia-app spec: https://celestiaorg.github.io/celestia-app/index.html
- 輕節點的不同等級安全性：https://forum.celestia.org/t/security-levels-for-data-availability-for-light-nodes/919
Avail
- Avail paper: https://github.com/availproject/data-availability/blob/master/reference%20document/Data%20Availability%20-%20Reference%20Document.pdf
- https://github.com/availproject/data-availability/tree/master
- https://docs.availproject.org/about/introduction/
- https://docs.availproject.org/faqs/
EigenDA
- https://www.blog.eigenlayer.xyz/intro-to-eigenda-hyperscale-data-availability-for-rollups/
- EigenLayer 創辦人分享 EigenDA 的由來：https://twitter.com/sreeramkannan/status/1741252007745528020
- https://github.com/Layr-Labs/eigenda/blob/master/docs/spec/overview.md
- https://docs.eigenlayer.xyz/eigenda-guides/eigenda-overview
- Proof of Custody: https://dankradfeist.de/ethereum/2021/09/30/proofs-of-custody.html
- DA Myth Buster: https://youtu.be/Zksr-oBkvjA?si=uMtuDfI1yF-3fJY0
- Celestia 回覆關於 EigenDA 沒有原生代幣的缺點的 thread：1、2、3
Tiramisu DA
Celestia、Avail 與 EigenDA 三者比較
TEM Medium 2024 有獎徵稿
TEM Medium 目前正在進行有獎徵稿！詳情請參考：
Special thanks to Kimi Wu, Kevin Mai-Hsuan Chia and Peter Lai for reviewing and improving this post
