jakiro
作者：Rui，SevenX Ventures投資人；翻譯：0xjs@比特鏈視界
在Rollup熱潮中，我們只能通過為用戶簡化基礎設施的複雜性來實現。這意味著所有跨鏈操作都只需要一個帳戶、一個籤名和一種 Gas。然而，挑戰仍然存在，例如帳戶狀態同步、籤名聚合、原子執行和延遲最終性。
1、什麼是鏈抽象
在最終階段，終端用戶將不需要任何基礎知識。他們只需表達自己的意圖或指定訂單，籤署交易，然後將其餘的工作（路由、Gas轉換、構建、訂單和跨鏈操作）留給自動處理。 本文特別關注跨鏈抽象。
2、為什麼鏈抽象很重要
藉助胖協議理論，區塊鏈 Rollup 或替代 L1 構建者正在成倍增加，而Rollup-As-A-Service正在將新的區塊鏈創建速度加快到一天之內。話雖這麼說，那些缺乏活動的區塊鏈將在 6-18 個月內消失。儘管如此，由於對靈活性的持續需求，實現統一的區塊鏈壟斷似乎不太可能。即使在更加集中的長期場景下，各種區塊鏈的存在也將繼續導致用戶體驗和流動性碎片化。
3、鏈抽象分解
統一地址：錢包將不同的 EVM 和非 EVM 地址合併為一個。
籤名聚合：智能合約帳戶(EVM) 或MPC 籤名者合約（非EVM）管理籤名聚合。
狀態同步：Keystore Rollup或Hub有助於跨鏈錢包狀態同步。
單一Gas：Paymaster 合約支持使用ERC20 付款，甚至贊助所有付款。
區塊構建和中繼：Mempool 構建者驗證、排序和批量交易，而 RPC 監控每條鏈上的每個交易狀態並按順序協調執行。
統一流動性：跨鏈流動性由UniswapX 或流動性hub等Solver處理。
4、誰是主要玩家
鏈抽象處於與錢包、基於意圖的系統、MEV 解決方案和橋的交叉點。
重點項目如 Safe、Clave、Flashbot、LayerZero、Union ，其他人則扮演主動或被動的角色。
今年，特定的鏈抽象參與者的目標是將各種模塊整合為統一的前端解決方案，例如
Particle Network 使用 Cosmos SDK 開發了 1 層解決方案，允許用戶使用任何代幣或PARTI作為跨 EVM、Solana 和 BTC 交易的 Gas。
Light 提供兼容4337的跨鏈智能合約錢包，支持狀態同步和籤名聚合，
Burnt（xion） 是一種通用的鏈抽象協議，具有元帳戶設計，允許不可知籤名、參數化費用層和狀態機更新。
NEAR協議 集成 MPC 層來解決跨鏈交易。
5、多鏈統一地址
為每條鏈維護單獨的帳戶對於用戶和開發者來說都是負擔，要求後者管理多個代碼庫。對於智能合約錢包項目，例如
Particle Network和Light可以使用確定性部署代理，該代理可以部署到 EVM 內同一地址的任何鏈，並使用 CREATE2 在確定性位置部署任何合約。對於外部區塊鏈，地址可以從 EVM 地址、chainID 和提供的路徑中得出，每個帳戶在每個鏈上接收無限數量的遠程地址。對於 EOA 帳戶，例如NEAR協議從NEAR地址（example.near）、派生路徑（例如Ethereum-1的字符串）和MPC服務的公鑰派生出外部地址。
6、跨鏈錢包狀態同步
當用戶在 2 層更改籤名密鑰時，更改如何同步到其他鏈？它要求實時更新、最小的更新成本和合理的傳播時間。以下是當前的三種解決方案：Keystore rollup、Light sync 和 Keystore hub。
Keystore rollup
Vitalik Buterin的設計中，最小Keystore rollup是基於 L1 排序的Rollup，將其 Merkle 樹狀態根存儲在 L1 上。為了創建錢包，用戶創建一個 zk 電路，定義驗證和更新籤名者的邏輯，每個用戶都有數據 + 驗證密鑰（vk）。用戶創建一個 SCW，將其密鑰硬編碼為不可變值。要通過此 L2 更改 SCW 籤名者，用戶可以提交其原始密鑰、新密鑰、當前 vk、IMT 中編碼的數據值以及針對當前 vk 進行驗證的證明。或者，用戶可以直接向 L1 上的 Keystore 合約提交 tx。
這種方法是中立且無需信任的，但是，激勵措施可能具有挑戰性，假設更新籤名者不是頻繁的行為，用戶必須預先支付 tx 證明以補貼 Rollup 證明者，否則不會向證明者提供任何價值。
Light State Sync
Light實現輕錢包同步，由來自0xsequence的Agusx1211發明。它使錢包能夠在 SCA 中創建不附加到網絡 chainID 的自定義消息模式，從而允許將「控制委託」籤名籤署給一組新的籤名者，並且這些籤名者稍後可用於籤署任何常規交易或留言。然而，直到用戶對任何一條鏈進行操作時，狀態才會更新，另一筆交易可以作為其中一個 baching tx 進行標記，以更新鏈狀態以匹配最新的「預籤名」狀態。
這種方法實現了實時性和成本效益，但是它嚴重依賴鏈下數據的可用性，如果數據丟失，錢包將無法訪問其最新狀態，甚至變得無法使用，因此錢包客戶端通常負責存儲所有數據的副本。此外，此方法在刪除籤名者時並不能提供強有力的保證，因為它沒有禁用鏈上的任何內容。
Keystore Hub
Particle Network使用Keystore Hub。智能帳戶的代碼邏輯和存儲分離，keystore hub存儲籤名者信息，用戶通過Hub部署和更新保證多鏈狀態的一致性。簡而言之，Keystore 中心負責將更新的交易發送到不同的鏈。
這種方法是最直接的方法，假設更新籤名者操作不是頻繁的操作，因此批量交易費用是可以接受的，但是，它需要信任和一些延遲。
7、籤名聚合
用戶現在可以使用單個籤名發起多鏈交易。項目如Light利用基於 Merkle Tree 的全鏈籤名聚合，確保用戶只需籤名一次。然而，當談到非 EVM 時，像NEAR這樣的項目利用 MPC 籤名者合約，合約將返回重建籤名所需的元素，而不是 tx 本身的籤名，從而允許它們概括多個區塊鏈的籤名過程（即在比特幣中，返回 r 和 s 值），並將其轉發給相應的網絡。需要注意的是，如果需要的話，在此過程中需要收集並聚合付款人（贊助商gas）的籤名。
8、Gas抽象
更好的體驗是Gas由其他方（錢包或dApp）贊助或在erc20中支付，更重要的是在跨鏈場景中，統一Gas降低了複雜性。 Gas 包括所有相關鏈的執行費。在構建 tx 的過程中，Paymaster 通過提供自己的籤名與參與者籤訂合約，當 Bunler 進行鏈下模擬時，會檢查 Paymaster 的餘額，Paymaster 在 Bundler 上執行時將 Gas 直接返回給 Bundler目標鏈。
Layer1類似Particle Network允許用戶以任何代幣或PARTI支付並處理跨鏈gas；
Light允許使用任何代幣和自定義付款人進行支付，以完全贊助特定訂單流的Gas；
Clave目前贊助「所有」用戶交易的 Gas。
9、區塊構建
從較高的層面來看，我們將擁有一個即插即用的內存池和去中心化的區塊構建器來處理交易。用戶偏好涵蓋從單個域內的簡單傳輸到跨多個區塊鏈的複雜序列。用戶可以指定域內的執行細節或提供抽象指令，將最佳路由留給執行者。
SUAVE 的概念描繪了一個理想的場景：多個鏈共享去中心化排序層，最大限度地提高驗證者的網絡彈性和區塊空間收入，同時確保構建者和搜索者的開放訪問。
10、中繼
為了實現跨鏈原子性，中繼工作與區塊構建密切相關，通過中繼節點/如 Flashbots RPC 監控每個鏈上的 tx 執行，並協調捆綁器/構建器將下一個 tx 發送到相應的鏈。重複該過程，直到在目標鏈上執行所有交易並處理未使用的Gas費用。
理論上，等待時間就是區塊鏈的出塊時間，當出塊太慢時，籤名就會失效。我們可以將 tx 設置為原子性的，這樣當一個 tx 失敗時，整個 tx 就會失敗。
11、Particle Network
Particle 構建了一個模塊化的 Cosmos L1 作為通用結算層，支持跨 EVM、BTC、Solana 等的鏈抽象。通過使用之前的錢包即服務集成和 BTC connect 作為入口，通過 EVM 中的keystore合約處理帳戶存儲和同步，他們利用去中心化捆綁器服務來構建 UserOps、消息傳遞協議來進行跨鏈交易和中繼器負責整個執行生命周期。有了PARTI作為Particle鏈的中心，Particle和其他鏈上的gas都可以被抽象出來。在基礎層之上，L1 可以利用 Babylon 雙重質押的安全性並採用聚合 DA。Particle Chain將成為最終用戶和 dApp 的一站式解決方案。
