看Polymer 如何將IBC引入所有生態系統

我們相信將會出現各種各樣的區塊鏈，而且這些區塊鏈會隨著應用程序數量的增長而增長。

更多的區塊鏈帶來的一個不可避免的結果是，互操作性將變得越來越重要。因此，隨著世界變得越來越模塊化，我們預計會出現大量的跨鏈橋。我們看到的最令人興奮的是Polymer。我們將在下面深入探討他們如何將IBC引入所有生態系統。

IBC

區塊鏈間通信(IBC)的核心是同質區塊鏈的跨鏈消息傳遞協議。這意味著它連接了具有類似功能的鏈，在本例中是Tendermint共識算法提供的即時確定性和具有輕客戶端功能的鏈。 IBC的運作方式是，兩個有興趣相互連接的鏈將在目標鏈上提出治理建議。這通常是通過Cosmos Hub或Osmosis(目前Osmosis有45個peer，而Cosmos有40個)來實現的。這意味著在協議層面上存在一致，因此，在外部跨鏈橋中不需要可信的第三方。

然後，這兩條鏈需要對方鏈上的輕客戶端以加密方式驗證兩條鏈之間的共識狀態，此外還需要一個中繼者在兩條鏈上的輕客戶端之間傳遞信息。讓我們來探索一下這在實踐中是怎樣的：

這意味著信任假設位於連接的區塊鏈的兩個驗證者集合中，因此與其他類型的跨鏈橋和消息傳遞協議相比，信任假設要少得多。例如，對於Polkadot生態系統中的XCMP，信任假設完全取決於中繼鏈(Polkadot)。

為了展示IBC在Cosmos生態系統中的兼容性和廣泛程度，以及它連接了多少條鏈，讓我們看一看當前的實時連接圖：

關於IBC，有兩個重要的含義需要注意。那就是連接和通道：

1. 連接是兩條獨立鏈上的兩個有狀態的對象—CosmosSDK中的IBC模塊。

2. 通道是與鏈/應用程序的特定連接，它將提供訂購等消息傳遞信息，這就是所謂的中繼者。

ICS

ICS是Interchain Standard的縮寫，為使用IBC的鏈之間發生的交易設置參數。 ICS基本上是IBC交易的模塊規範。兩條鏈要使用IBC進行通信，就必須擁有相同的ICS規範。其中一個有趣且獨特的ICS是ICS-27，也被稱為鏈間賬戶。

Polymer將支持現有的ICS。因此，與Polymer相連的鏈將能夠利用Polymer長期貢獻的更廣泛的IBC社區所做的大量偉大工作。

輕客戶端

輕客戶端是區塊鏈的重要組成部分。在目前的形式中，它們使硬件密集型較低的機器能夠參與區塊鏈的驗證過程中，並有助於促進與其他設備的連接。它們通過只下載區塊頭而不是整個區塊來實現這一點。他們相信誠實的全節點能夠提供準確的信息，因此不是無信任的。

輕客戶端隨著Cosmos生態系統的出現而受到關注，並因其在區塊鏈擴展功能方面所允許的可能性而獲得了極大的歡迎。這裡我們指的是Celestia如何利用輕客戶端參與數據可用性抽樣，以擴展網絡中的節點數量。這將允許輕客戶端擁有與全節點幾乎相似的信任假設，同時仍然不需要下載整個區塊。這導致輕客戶端和終端用戶成為他們所在網絡的一等公民。

在大多數原始的單體區塊鏈中，用戶被要求運行一個全節點，如果他們想要參與驗證，他們必須在那裡存儲整個區塊鏈數據。這為去中心化帶來了障礙，因為隨著區塊鏈的規模和歷史的增長，對全節點的硬件要求也在增加。這個問題通常被稱為state bloat。對於輕客戶端，只要他們連接到一個誠實的全節點，它們就能夠通過掃描區塊頭來參與，而不是像全節點那樣掃描整個區塊。

這是全節點和輕客戶端之間關係的簡化圖。在實際情況下，許多節點都參與了點對點網絡。

ZK輕客戶端

因此，輕客戶端顯然是一個偉大的發明，但我們如何使其更偉大呢？在Polymer的案例中，他們正在使用ZK輕客戶端這項新發明。 ZK輕客戶端將允許增加信任最小化和交易效率。通過利用ZK證明，我們可以將輕客戶端驗證邏輯編碼到電路中，從而更有效地批量驗證區塊頭。但是需要注意的是，區塊頭中還包含前一個區塊的哈希值，這就是我們能夠創建區塊“鏈”的原因。從本質上講，區塊頭包含了不屬於原始元數據列表本身的數據。

輕客戶端效率的一個很好的例子是，假設你的區塊鏈有10.000個1MB的區塊，那麼你將在每個全節點上消耗10GB的空間。然而，通過對相同的區塊使用區塊頭，你所佔用的空間會少一個數量級。利用ZK證明及其遞歸性質將進一步提高這一點。至關重要的是，它們使資源較少的設備可以執行驗證，並允許支持輕客戶端的區塊鏈讀取另一個區塊鏈的狀態。

利用遞歸zk證明可以提高中繼過程的效率，並使用更少的空間。遞歸zk證明是指你採取多個證明，然後將其匯總成一個單一證明。只有在所有內在證明都有效的情況下，這個單一證明才是有效的，而且驗證起來容易得多，成本也低得多。當在鏈上驗證證明時，這一點特別有吸引力。數以千計的證明可以壓縮成一個證明，這在驗證過程中節省了巨大的成本。這是因為遞歸zk證明證明了之前有效證明的存在。

另一個需要遞歸ZK snark進行鏈上驗證的原因是，在以太坊上運行Tendermint“輕客戶端”非常昂貴。即使進行了優化，實際的驗證成本也很昂貴。如果你只是想在以太坊上驗證Tendermint輕客戶端的驗證邏輯，它甚至有可能超過區塊的gas限制。遞歸驗證ZKP將使鏈上驗證過程更加簡單。

之所以要用遞歸證明來驗證區塊頭，是為了並行地生成幾個證明，然後一起遞歸地證明它們。這意味著驗證單個區塊頭(其中可能只有單個跨鏈交易)的通常成本可以並行遞歸地降低。這也意味著你現在只需驗證鏈上的有效性證明，而不是整個區塊頭。這與我們用ZK-rollup實現可擴展性的方式類似。

實際的鏈上區塊頭驗證將在ECDSA算法的secp256k1橢圓曲線參數下進行。 secp256k1是以一種系統的方式構建的，這使得計算特別高效。因此，如果實現得到充分優化，它通常比其他曲線快30%以上。 Secp256k1曲線在比特幣和以太坊中都有使用。然而，它不是對SNARK最友好的，因此我們也將研究其他曲線。

需要注意的一點是，仍然需要存儲所有交易的通用調用數據及其Merkle樹。我們將在下一節中討論如何使之更有效率。如果你有興趣深入了解實現ZK輕客戶端和IBC邏輯背後的原因，那麼我建議你閱讀最新發布的Polymer文章，其中涵蓋了這些問題的部分內容。

Verkle樹

Verkle樹是一種更有效的狀態承諾數據結構。這樣做的好處是可以減少證明的大小和鏈上證明的驗證成本。一般來說，Merkle/Verkle樹帶來的能力是確保數據的綁定直到最後一個字節都是相同的，這使我們能夠向區塊鏈節點提供最終協議。

要理解Verkle樹與Merkle樹的不同之處，首先要了解後者。 Merkle樹和Verkle樹在結構上相當相似，但有幾個組成部分使它們作為狀態承諾的數據結構非常不同。

在Tendermint/CosmosSDK結構中，Merkle樹用於在節點之間共享交易數據，特別是在全節點和輕節點之間，以便輕節點驗證特定區塊。在這種情況下，輕節點從全節點獲得承諾並獲得見證，這使輕客戶端能夠在區塊頭中構建根。

在以太坊中，Merkle樹被用於執行層，其中區塊頭由Merkle樹的3個根組成。它們是狀態根、交易根和收據根。

還有以太坊的全局狀態樹，它會隨著時間的推移而更新，因此也會隨著時間的推移而增加規模。這也是以太坊在未來版本中探索使用Verkle樹，以最小化以太坊全節點需要持有的狀態量的原因之一。這就是所謂的無狀態(弱)，我們稍後會觸及到這一點。這同樣也說明了為什麼輕客戶端兼容性對區塊鏈如此重要，以及為什麼以太坊也在尋求在未來添加它們，因為它使擁有較小硬件的客戶端能夠驗證區塊鏈本身。狀態膨脹問題也是為什麼由於EIP-4844而增加的調用數據(交易數據)需要歷史過期的原因。一般來說，如果你不感興趣或不願意增加節點的硬件需求，狀態膨脹對區塊鏈來說是一個巨大問題，因為它阻礙了去中心化。有多種方法可以緩解這個問題，Verkle樹就是其中之一。

讓我們看看Merkle樹是什麼樣子的，這將使我們稍後能夠了解它們與Verkle樹的區別。

Merkle樹中的見證者的大小為lgxN(x-1)。在Merkle樹中，證明是樹中所有節點的集合，這些節點與通往被證明節點的路徑中的節點共享母節點。這意味著你必須在見證中包括大量的節點，以便能夠證明承諾。當然，這在非常大的樹中會呈指數級增長，因為你需要證明的樹的頂部也會變得非常大。

Merkle樹和Verkle樹之間的主要區別在於它們如何構造它們的見證者，因此它們的大小也不同。在我們研究Verkle樹的結構之前，讓我們詳細介紹見證者是如何在其中工作的。首先需要注意的是，所有積極的事情都有權衡。在Verkle樹的情況下，移動到lgxN(2)的見證大小會降低計算效率。然而，它使我們能夠減少證明的大小，因此也降低了證明的鏈上驗證成本。如果你試圖在以太坊之間進行橋接，這一點尤其重要，因為以太坊目前的gas成本相當高昂。為了降低成本，verkle樹和遞歸證明可以與整個以太坊的許多其他可擴展性解決方案一起提供極大的幫助。

在Verkle樹中，不需要提供共享母節點的所有節點，只需要提供到根的路徑。因此，在一棵非常寬的樹上，與Merkle樹承諾中必須提供的所有姐妹節點(見證)相比，路徑將是相當小的。在Verkle樹中，與路徑一起需要的另一個附加承諾是向量承諾(多項式，它可以為任何點創建證明)，它取代了Merkle樹中姐妹節點的功能。這意味著它們會驗證某個子節點(母節點下的節點)是否確實是樹中的正確節點，而只提供路徑本身。

在樹中的證明構造中不需要姐妹節點。你只需給出路徑本身，加上一些簡短的證明，將路徑中的每個承諾與下一個聯繫起來。

如果你有興趣了解Verkle樹是如何在聚合物中構建的，如何在Polymer中構建的，那麼我們強烈建議你查看他們對Verkle樹內部情況的精彩介紹。在開始時，Polymer不會使用Verkle樹。然而，在未來由於狀態的膨脹和證明驗證的價格，進行轉換是有意義的。因此，Polymer正在為未來做準備。

除了Verkle樹和多項式承諾的基本功能之外，我們還可以添加進一步的優化，以支持無數其他不可思議的未來實現。讓我們簡單介紹一下：

這些優化通過多項式承諾所支持的屬性實現。主要的能力是使固定大小的證明將任何長度或路徑上的節點連接起來。這是通過Fiat Shamir Heuristics(FSH)為非交互式證明提供一個確定性的隨機性來源來實現的。 FSH使我們能夠通過隨機評估實現多重證明。這也是Merkle和Verkle樹之間的權衡所在——計算多項式的證明生成。這個單一的多項式證明就可以起到證明正確路徑的作用。

如果你有興趣深入研究如何實現單一有效的多重證明，我們強烈建議你查看Dankrad的文章。

Verkle樹的實現將允許一些相當獨特有趣的功能，有助於區塊鏈的可擴展性和去中心化。讓我們特別看一下無狀態，同時也略微觸及另一種方法，即狀態租用。這兩種方法都是為了緩解所有區塊鏈的狀態膨脹問題。正如Vitalik在大約一年前的“狀態到期和無狀態路線圖”中指出的那樣：“以太坊的狀態大小正在迅速增長。目前，僅狀態就有35GB左右，包括所有Merkle證明在內的容量超過了100GB，而且還在以每年大約一半的速度增長。”

無狀態或弱無狀態是指只要求區塊提議者存儲狀態，然後讓網絡中的其他節點驗證該區塊，而不必持有和存儲區塊鏈的狀態。這需要Verkle樹和多重證明，這將使客戶端能夠驗證全局狀態，而無需實際持有任何狀態本身。計劃在以太坊上與弱無狀態一起添加的另一個附加功能是狀態到期。在狀態到期的情況下，狀態仍然需要去往某個地方。這可能是在存檔節點上，或者我們也可以使用一種稱為狀態租用的方法。

狀態租用是“出租”要存儲的狀態並在其他鏈上或鏈本身的特定節點內證明其可訪問性的概念。 Laconic等各種各樣的項目正在研究這種解決方案，但以Polymer的結構，你也可以設想一個Polymer也被用於狀態租用的世界。還有一種方法可以通過可證明的可檢索性來分散狀態。 Joachim Neu在模塊化峰會上發表了一篇非常有趣的論文，我們很高興與Celestia共同主辦了這次峰會。如果你想了解更多，你可以閱讀該論文。

以太坊上Solidity中的IBC及遞歸snark

最近有幾個團隊在研究如何在以太坊添加輕客戶端兼容性之前將IBC引入以太坊。例如，Electron Labs提出了IBC的一個“版本”，他們讓以太坊上的一個智能合約充當鏈上輕客戶端(IBC需要)。這與以太坊rollup的跨鏈橋/rollup合約的工作方式類似。然而，這樣做的問題是，你實際上信任的是一個智能合約(它通常是可升級的或由中心化團隊控制的)，這顯然不允許在協議層面上實現信任最小化的橋接。 Tendermint/CosmosSDK鏈上的IBC的美妙之處在於，它們內置了輕客戶端支持，並使鏈能夠在協議層面上達成一致，以最小化信任的方式在它們之間建立連接。目前，Electron Labs只有一個用於ed25519簽名驗證的電路，而沒有實際的輕客戶端邏輯。為了使智能合約充當具有IBC邏輯的輕客戶端，他們需要進行其他必要的更改。

那麼，Polymer打算如何在以太坊生態系統中提供IBC呢。讓我們深入了解一下Polymer的GitHub，看看他們到目前為止所做的工作。

目前，在某種程度上實現IBC，使其在以太坊上運行的最佳方法是實現ZK-IBC結構。這裡的有效性證明在鏈上進行驗證，以證明在連接鏈上進行的交易的有效性。如前所述，Electron Labs也有一篇很好的博文介紹瞭如何實現這一點，但我認為有幾件事是需要注意的。 IBC模塊需要轉換為solidity，以便IBC交易能夠被正確驗證+我們還需要一個用於Plonky2的solidity驗證器這是目前對遞歸snark最快的驗證系統——這是我們高效實現zkIBC所需要的東西之一)。如果你對Polymer正在進行的Plonky2驗證器的開發感興趣，我強烈建議你查看他們的GitHub

目前，Polymer已經在開發網絡上創建了智能合約，充當以太坊和BSC的鏈上輕客戶端。這使智能合約能夠接收IBC數據包，因為他們已經在Solidity中重寫了IBC模塊。同樣，Polymer也為其他各種兼容EVM的鏈做了測試，如幣安、Avalanche、Fantom、Polygon和Solana。

Polymer

IBC e2e

除了標準的IBC之外，Polymer還將推出一種稱為端到端IBC的副產品。這非常符合我們看待模塊化世界形成的方式，因為連接的鏈在該產品中被認為是“rollup”。 E2E IBC是允許本地IBC和輕客戶端支持的遠程VM。 E2E IBC可以被所有的鏈採用，包括特定於應用程序的鏈、其他L1、L2和各種執行環境。

這意味著連接的鏈可以有自己的“rollup”，作為具有輕客戶端支持和本機IBC連接的遠程VM工作。因此，通常不能利用輕客戶端的鏈可以擁有一個可以連接和使用IBC邏輯的環境，而無需實際實現模塊本身。

這些遠程VM將通過Polymer的鏈間賬戶智能合約API進行交互。通過這種方式，它們將解耦鏈通常依賴的網絡層，並允許遠程VM作為支持原生IBC連接的Polymer本身的擴展運行。這意味著Polymer能夠代表連接的鏈維護IBC連接。

E2E IBC的狀態將在Polymer上進行驗證，就像通過CosmosSDK和Tendermint支持的通過輕客戶端進行rollup一樣。在Polymer方面將會有IBC智能合約(有時也被稱為以太坊上的跨鏈橋合約)。他它們將處理從Polymer到非IBC鏈的移動。原生的輕客戶端支持意味著信任最小化可以輕鬆實現。

Polymer還將推出所謂的xApp，它將作為多鏈應用程序在Polymer的基礎上以rollup的形式運作。這將使他們能夠立即訪問各種可在其上進行結算和處理交易的鏈。

Polymer理論

Polymer正在利用現有的Cosmos技術，通過構建一個通用的IBC路由協議來支持非Tendermint 鏈之間的端到端IBC連接和通道，甚至在這些第1層頂部進行rollup來發揮IBC的優勢。 Polymer還採用了一種模塊化方法構建其網絡協議，以便在堆棧的每個部分進行優化。

因此，它們將使IBC能夠連接到所有相連的鏈，這將使構建在Polymer之上的應用程序具有原生的鏈間組合性。 Polymer的功能是作為一個與鏈無關的IBC網絡層，他們通過解耦網絡層來實現這一點，這將允許rollup IBC作為跨多個鏈應用程序邏輯的數據層發揮作用。這是通過使用IBC所依賴的輕客戶端實現的，通過使用ZK輕客戶端，可以將驗證邏輯編碼到電路中，從而使批量的區塊頭驗證更有效率。

e2e IBC是與遠程VM的集成，它允許IBC層與Polymer連接的鏈解耦。這通過以Merkle/Verkle樹發布批量承諾來實現。驗證時間和證明大小將通過在未來啟用Verkle樹而減少。

因此，Polymer將代表連接的鏈維護IBC連接和通道。這應該也將允許跨非原生Cosmos鏈的鏈間帳戶。

Polymer還與Celestia合作，通過IBC的Optimistic輕客戶端實現成為構建在Celestia之上的Optimistic Rollups之間的橋接供應商。