以太萎靡的背景下，Rollup方案的破局之路在哪？

正文

➢通用層案例解析：Entangled Rollup&GOAT Network

今天我將延續昨日的[通用層]話題，展開另外一個用於構建[通用層]狀態的方案以及已經落地的案例，全文大約3400字。

📍我認為[通用層]這個趨勢是目前Rollup在以太系萎靡背景下的破局之路。

通過讓自己聯通其他的生態系，尋求更多的應用場景。

在功能性上，已經出現了多鏈互操的趨勢，這種趨勢的出現，我覺得主次關係並不是其他L1多麼需要一個L2，而是這些L2需要主動去兼容這些生態相對活躍的L1。

1.領先的通用層方案：來自ProjectZKM的Entangled Rollup🔻

似乎從OP推出超級鏈之後，加上模塊化敘事的興起，市場已經開始出現了不少可以讓L2快速構建的方案(ALT就是做這一個賽道的)。

這也是後來應用Rollup開始批量出現的源頭；

之前曾說過，應用Rollup的趨勢不會停止，會成為一個團隊在行業內構建應用的方案備選。

因此目前的主要競爭已經不再侷限於Rollup了，而是更上游的Rollup構建以支持應用鏈的發展。

目前Entangled Rollup所提供的方案，其實和OP所提供的方案邏輯稍微有點相似，只是在鏈的互操作方面，要領先一步：Entangled Rollup方案讓Rollup在構建之初，就天然支持跨鏈的互操作。

Entangled Rollup 的核心思想是將不同區塊鏈的底層機制“糾纏”在一起，通過遞歸零知識證明來同步狀態。

讓兩個獨立的L1，通過相同框架構建的L2實現互聯的目的，[甚至有可能實現一個L2鏈接多個L1的通用層格局]。

具體怎麼實現的原理其實大家不必要知道，只需要知道在它這個方案的影響下，會在市場上出現兩種可能性：

（1）兩個L1之間，因為L2從而可以實現兩個L1彼此間的跨鏈互操作（2）一條L2鏈接多條L1

上述兩種可能性的共同點都是：L2的功能和邏輯開始近似於跨鏈橋。有點打不過就加入的感覺，但我覺得仍需要重申的是，並不是一些L1需要L2，而是這種方案讓執行層擁有更多的服務對象，擴大潛在的市場用例的用戶群體，給了一些L2更多的可能性。

2.釋放$BTC資本效率的通用層方案：GOAT Network🔻

GOAT的構建是基於上面所介紹Entangled Rollup通用層方案，除了具有通用層的特性之外，還需要著重展開一些通用層之外的差異化細節。

同事GOAT也是分階段的，雖然是基於Entangled Rollup方案，但在第一階段會更加側重成為一個BTC L2。

在排序器的組成上，GOAT優先追求讓排序器網絡去中心化：這個理念是幾乎所有rollup都需要去追求的狀態，並不是說這個階段會給業務帶去多麼大的增幅，但作為Web3的基礎設施和應用，[去中心化]這件事天然的就有著最高的優先級。

在以太系的Rollup譜系中，Metis是首先實行這一階段的Rollup，而GOAT現階段則是一個切入BTC生態的Rollup，同樣也將排序器去中心化放在了比較高的優先級裡面 另外排序器的運行，質押的資產是BTC原鏈1:1封裝的BTC(goatBTC)。

除了作為質押資產獲得一定的利息收益之外，在GOAT上構建的BTCFI市場將以封裝的BTC為核心去創造衍生收益。

這也是絕大多數做BTCFI的共同點，都企圖進一步的解鎖BTC除了持有之外的資本效率。

從資產屬性上來說，過去的BTC在資本效率上幾乎=0，既不像證券一樣可以持股分紅，也不像 $ETH 那樣可以去參與鏈上生態獲得一些潛在的幣本位收益。

幾乎是等於我持有BTC，只能等它上漲然後出清獲得這種低買高賣的資本利得收益，少數的一些進一步獲得利息的渠道可能就是放到交易所獲得一些利息。

但隨著BTC生態的提出與發展，BTC持有者可以獲得潛在的新項目空投+Defi收益池+節點運行等多個方面的潛在收益，加持資產持有權益，創造更豐富的市場需求。

關於GOAT如果你本身對以太系的L2比較熟悉的話，你可以將GOAT給理解為：BTC版本的Metis+Blast🔺

在底層架構實現排序器去中心化的優先級下，進一步去解鎖BTC的資本效率，這就是其主要在做的事情。

3.BTC是否需要BTCFI❓

昨天在一個社群我看到一個很有意思的爭論：BTCCFI就是一幫沒有BTC的人在想辦法賦能BTC。

這個說法乍這麼一聽好像挺對的，但仔細這麼一琢磨，這個公式其實可以套在任何一個L1上面，這也是為什麼我上面著重有在提關於BTC資本效率這件事。

GOAT雖然最終的目的是基於[Entangled Rollup]方案的基礎成為多個鏈的[通用層]，但是現階段還是專注於BTCFI的。

包括延續比較傳統的路徑，給網絡上的BTC持有者(節點、生態構建方)空投本身的L2代幣，此外還允許圍繞其封裝的BTC資產開展生態建設，無論是將BTC作為池子的交易對錨定還是構建跨生態系統的流動性，都對BTC的原生需求有促進作用。

我甚至看到市場有種觀點：BTC不需要生態，只需要成為某個或多個國家的儲備貨幣，就可以坐享其成。

但這件事本身並不是衝突的，在價值層的捕獲上，BTC並沒有給持有者實現更多的衍生效益，這並不是一個良好的資產所應該具備的屬性，誠然如黃金，都有其一定的工業價值、

4.GOAT的核心經濟驅動🔻

本段給你梳理一下GOAT可能看似有些複雜的網絡經濟設計，站在我的角度，其實是在當下主流的ETH L2方案中做了不少的改進。

GOAT的經濟組成部件如下：

（1）基於封裝BTC的去中心化排序器網絡🗝️

➢GOAT的排序器節點質押資產是一種封裝的BTC(goatBTC)，這是一種傳統的原鏈封裝，目標鏈鑄造的錨定方案，BTC通過特殊的腳本被鎖定在L1上面，鎖定期為6個月，這是成為一個排序器節點的基礎。

（2）yBTC的權益證明🗝️

➢除了自己成為排序器節點之外，普通的小型BTC持有者可以通過參與POS機制來參與到排序器節點的利益分配，在GOAT上質押BTC，將能夠獲得yBTC，這是參考的當下主流的流動性質押生息的設計（也給未來的再質押套娃埋下了種子）。

（3）以yBTC作為拆分的經濟設計🗝️

➢這個yBTC可以被成分成pBTC和yToken，這是有點借鑑了Pendle的債息分離的設計，基於相似的設計，GOAT有了衍生BTC收益市場豐富玩法的基礎；

➢這兩個資產同樣和Pendle一樣被設計為有到期日，如果你覺得這個設計有點抽象，我建議你去了解一下Pendle這個協議，也許會更加有助於你理解這個設計；

➢GOAT相當於內置了一個原生的[BTCPendle]。（4）以goatBTC為鏈上GAS🗝️

➢這是採取L2比較傳統的設計，將L1的資產作為鏈上GAS，只是在BTC這裡和ETH有區別的是，採用的是封裝資產而不是原生的資產，而採取這一設計也意味著排序器節點的收入也來自於BTC。

（5）原生的代幣權益：GOAT🗝️

➢原生代幣的持有者可以通過質押GOAT來提高排序獎勵和獲得鑄造贖回的獎勵；

➢關於鑄造贖回獎勵的說明：由於BTC和goatBTC之間是一比一的鑄造關係，因此在這個鑄造和贖回的環節當中，GOAT基金會將收取一定的贖回費用，例如0.2%(最大值為0.002BTC)；

➢這部分的費用會有一部分被分配給鎖倉GOAT的持有者，其餘的部分被用作市場回購代幣和生態開發支出。

上述五點，是我梳理的GOAT整個網絡的經濟構成，不難看出這個設計其實主要是以原生的BTC封裝資產為核心，通過排序器的分散化讓不同規模的持有者都可以參與到基本的網絡運轉並從中獲益。

但裡面的供需設計理所當然的依賴於發展階段鏈上所產生的對GAS的需求，這樣才能夠供應排序器節點以及L1主網驗證者的運轉。

幾乎可以說，經濟模型良性運轉的源頭都來自於網絡的生態活躍，網絡越活躍，市場對yBTC這些權益資產的需求就可能越大，所能衍生的Defi市場就可能越活躍，從而給排序器帶去更多的手續費收入，同時進一步激勵GOAT的正向鎖倉。

5.代幣經濟分析：GOAT&veGOAT🔻

（1）GOAT將整個代幣的絕大部分(42%)組成一個對排序器長期激勵的礦池，這是POW乃至重節點設計的網絡比較常見的做法，不過這個設計在市場的低谷期或者是自帶有節點中心集群的高發採礦設計的協議中，容易造成代幣分配的集中，我目前沒有看到GOAT有展現這個特性(雖然它們的早期節點是通過白名單的方式)；

（2）而投資者佔比的部分不到20%(含KOL輪)，除了礦池的42%，也就團隊的20%佔比是相對較大的比例；

（3）目前還沒找到有關大額比例的釋放細節，因此我也無法評價太多，但可以確定一點的是，被劃分給社區空投的部分，是不少的，即使是在多方的佔比裡，都是相對大額的部分，只是不知道這個空投是一次發放還是長期的線性發放設計；

（4）關於GOAT的質押權益，比較實際的其實就是瓜分BTC的贖回手續費費用以及提高排序的獎勵加成；

（5）veGOAT：是通過鎖定GOAT獲得的一種[治理證明]，這個代幣不參與流通，僅是作為一種網絡治理和長期鎖定的憑證。這個代幣更像是一種特殊的鏈上身份，通過這一鏈上身份，基本鏈上涉及到收益的地方，你都可能會獲得加成，一句話總結就是這個，不過多展開。

關於通用層的設計，現階段GOAT是作為一個BTC L2方案推出，我不確定未來隨著更多生態系的接入，是否會從源頭上重構設計。

還是說依舊沿用當下以 $BTC  為核心的設計；

又或者在未來，GAS的使用是可選的或者說是自動化的，因為目前意圖執行和鏈抽象方案的相繼推出，和通用層的這一發展趨勢實際上是貼合的。

試想一下，如果未來GOAT兼容了TON網絡，那麼對於TON生態的用戶來說，如果依舊使用 $BTC 為核心的資產進行交互，我想還是會比較彆扭的。

這是目前我看到這個方案有必要去做一些針對用戶的賬戶抽象方面的改進設計。