Across V4 引入了全新且改進的跨鏈架構。
該系統結合了意圖和零知識證明（ZKP），以更快地擴展到更多鏈。
以下是技術細節。🧵
之前，Across 使用了「標準橋接」或特定鏈適配器來驗證來自以太坊 HubPool 的消息。
這對於像 Arbitrum 和 Optimism 這樣的 L2 來說運作良好，因為它們暴露了以太坊已確認的狀態。
但這種設計是有限制的…
對於像 BSC 這樣的非 EVM 鏈，這個模型無法運作。
沒有標準的方法來驗證以太坊的狀態。這意味著要麼建立自定義適配器，要麼根本不支持這些鏈。
這兩者都不是最佳解決方案。因此，我們找到了使用 ZKP 的更好方法。
這是過程：
當中繼者填寫跨鏈訂單時，交易會被批量打包成中繼者還款包，然後由 @UMAProtocol 的樂觀預言機進行驗證。
這總是在以太坊主網上發生。
一旦捆綁包被驗證，Across HubPool 會觸發結算過程。
然後，它將還款消息哈希寫入 HubPoolStore 合約的特定存儲槽中。
這個存儲事件也會在以太坊主網上發生。
HubPoolStore 合約中的每個消息哈希對應於在目標鏈上償還中繼者的意圖。
請注意，L1 → L2 消息可以代表多次償還（包括慢速填充）。這是因為它們是根捆綁。
當 HubPoolStore 合約寫入一個儲存的訊息哈希時，它會發出一個 StoredCallData 事件。
這個事件包含了訊息哈希和儲存槽。
事件加上儲存的數據形成了 ZK 驗證下游的錨點。
一個名為 finalizer 的服務會監聽這些事件。
一旦它檢測到新的事件，就會啟動一個過程來證明該消息的哈希確實已經寫入以太坊。
每條消息的哈希被存儲後，都有一個目標，該目標可以特定於其鏈。
這個證明允許消息在目標鏈上安全執行。
但以太坊的最終性並不是瞬時的。
一旦最終者將數據發送到 ZK API，該 API 會在以太坊的最終性窗口中等待，然後再生成證明。
要生成有效的 ZK 證明，以太坊同步委員會必須對特定的已完成區塊簽署。
如果該消息在該區塊中或之前被包含，則所需的簽名將可用於開始生成 ZK 證明。
最終化器查詢 ZK API，以生成證明，證明特定的消息哈希已寫入已知的 HubPoolStore 存儲槽中，並且該槽位於已最終化的以太坊區塊中。
這使得在任何目的鏈上無需信任的驗證中繼者的還款成為可能。
ZK API 準備了證明輸入，包括（但不限於）：
- 最終化的信標標頭
- 同步委員會簽名
- 來自以太坊執行層的存儲 Merkle 證明
這些構成了生成證明的基礎。
Across 在目標鏈上部署了一個通用堆疊：
- 一個驗證者合約（驗證 ZK 證明）
- 由 @Succinct 提供的 SP1Helios（存儲已完成的以太坊狀態）
- UniversalSpokepool 合約（在執行過程中驗證消息的真實性）
一旦 ZK 證明被驗證且狀態被確認，executeMsg() 可以安全地在目標鏈上運行有效載荷。
無信任。安全。通用。
這意味著 Across 不再需要為每個鏈提供自定義適配器。
只需一個在任何地方都能運作的管道：
storeMsg() 在以太坊上 → ZK 證明 → 在任何能夠驗證 SP1Helios 證明的目標鏈上執行 executeMsg()。
不信任假設。
沒有整合開銷。
只有意圖 + ZK。
這為什麼是個大問題？
它通過解鎖對無法本地驗證以太坊狀態且沒有標準橋接的長尾鏈的支持，顯著擴大了Across的覆蓋範圍。
這使得上線過程更快、更安全且更具可擴展性。
Across 不需要這些鏈的標準橋接。它只需要能夠驗證以太坊狀態的 ZK 證明。
這減少了整合的開銷，避免了集中式橋接的風險，並加強了以太坊作為跨鏈真相根源的角色。
8,239
42
本頁面內容由第三方提供。除非另有說明，OKX 不是所引用文章的作者，也不對此類材料主張任何版權。該內容僅供參考，並不代表 OKX 觀點，不作為任何形式的認可，也不應被視為投資建議或購買或出售數字資產的招攬。在使用生成式人工智能提供摘要或其他信息的情況下，此類人工智能生成的內容可能不準確或不一致。請閱讀鏈接文章，瞭解更多詳情和信息。OKX 不對第三方網站上的內容負責。包含穩定幣、NFTs 等在內的數字資產涉及較高程度的風險，其價值可能會產生較大波動。請根據自身財務狀況，仔細考慮交易或持有數字資產是否適合您。