Polkadot（波卡）是一個專注於跨鏈互通性的區塊鏈平台，其核心架構由中繼鏈（Relay Chain）和平行鏈（Parachains）組成。中繼鏈負責網路安全、共識和跨鏈通信，而平行鏈則是獨立運行的區塊鏈，可以根據自身需求自訂規則。

目前，Polkadot 生態已發展出多個活躍的平行鏈，包括Acala、Moonbeam、Astar、Phala 等，涵蓋DeFi、NFT、資料儲存等多個領域。波卡的XCM（Cross-Consensus Messaging）協定使得這些平行鏈可以安全、有效率地進行資產和資料交互，真正實現多鏈互通。

跨鏈系統中的帳戶抽象問題

在以太坊生態中，使用者可以選擇外部帳戶（EOA）或合約帳戶來管理資產。合約帳戶（如多簽錢包、帳戶抽象帳戶）通常用於團隊管理、DAO 資金管理等場景，但一個主要問題是：

• 在每條鏈上，使用者需要單獨部署合約帳戶（如Safe），這不僅增加了管理複雜度，還導致跨鏈互動變得困難。

• 對於DAO、基金管理等場景，成員需要單獨維護各鏈的權限，不僅繁瑣，還可能帶來安全風險。

在Polkadot 生態中，雖然XCM 解決了資產的跨鏈轉移問題，但帳戶管理仍然是一個挑戰。使用者希望在多個平行鏈上使用同一個帳戶，而不需要單獨建立和管理多個帳戶，這正是帳戶抽象化（Account Abstraction）需要解決的問題。

現有方案：以太坊的Keystore Rollup 方案

Keystore 的概念與歷史

Vitalik Buterin（V 神）在2023 年的一篇文章《Keystore Rollups: Using ZKPs to Simplify Wallet Management》中首次提出了Keystore Rollup 的概念。該方案的核心目標是透過零知識證明（ZKP）來優化錢包管理，使得用戶可以跨鏈使用相同的帳戶，而不必在每條鏈上單獨管理金鑰。

如下圖所示，在eth 主網建立的帳戶，可以同時在多個layer2 中使用（而不需要每條鏈單獨再建立合約帳戶）。

目前，Safe 正在與Scroll 和Base 合作，嘗試將Keystore Rollup 方案落地。不過，這些方案仍處於PoC（概念驗證）階段，尚未真正應用於生產環境。

相較之下，Polkadot 採用了不同的方式，即Remote Proxy，直接在L1 層級解決跨鏈帳戶管理問題。

波卡帳號抽象的最後一塊拼圖：remote-proxy

背景知識：波卡的帳戶種類

在Polkadot 生態中，帳戶主要有三種：

1. EOA（外部帳戶）：由私鑰控制，自然具備跨鏈能力。

2. 多簽帳戶（Multisig）：多個EOA 共同控制，原生支援跨鏈。

3. Pure Proxy 帳戶：類似以太幣的合約帳戶，隨機生成，由EOA 或多簽控制。

由於Pure Proxy 帳戶是鏈上產生的，因此其控制關係必須儲存在鏈上。這使得它在預設情況下無法跨鏈使用。總結來看，Polkadot 生態中的EOA 和Multisig 已經實現了跨鏈使用，唯一缺少的就是讓Pure Proxy 帳戶也能多鏈通用。

什麼是Remote Proxy？

Remote Proxy 是Polkadot 提出的跨鏈帳戶代理機制，允許使用者在一條鏈上聲明代理權限，並在另一條鏈上遠端使用該權限。換句話說，使用者可以在Relay Chain（中​​繼鏈）上設定代理帳戶，然後在不同的平行鏈上使用該代理進行操作。

Remote Proxy 的發展歷史

這個解決方案來自真實的使用者問題：一開始有人因為不知道Pure Proxy 無法跨鏈使用，導致資產遺失，這時大家想要恢復資產只能透過提國庫提案來重新取得帳號控制權：https://forum.polkadot.network/t/pure-proxy-replication-on-asset-hub-via-root-referendum/10802um/108

這起事故引發了開發者們的深入討論：既然Pure Proxy 是一種很常見的帳戶抽象方式，那能不能讓它像護照一樣，在多個鏈上通用，而不是每條鏈都重新辦一次？

接著就出現了這樣一份pure proxy 帳戶的複製提案：

https://github.com/polkadot-fellows/RFCs/pull/111

開發者爭論的焦點是，如果pure proxy 帳戶可以進行多鏈複製，那麼在新鏈上登記的pure proxy 控制權應該如何處理？整體分為了兩派：即用即遷移還是一次性遷移？其中xlc 提出了一個很經典的場景：

• 一次性遷移派：帳戶控制權一次從原鏈「複製」到新鏈，所有鏈共享同一個Proxy 控制關係。

• 即用即遷移派（最終被採納）：每次在某條鏈上使用時，再動態產生對應的控制關係，按需遷移。

一次性遷移引發的問題就是，如果pure proxy 的控制權會被複製多次在多條鏈中使用的話，很可能會造成控制權混亂。於是最終，polkadot-sdk 核心開發Bastian選擇了「即用即遷移」的方案。

在最近一次的Kusama AssetHub 鏈升級中，remote-proxy 已經上線使用（Runtime 1.4.2升級），正式進入生產環境。目前，remote-proxy 的程式碼仍在http://github.com/polkadot-fellows/runtimes/倉庫中，Bastian 表示未來還會將程式碼遷移去Polkadot-SDK，這樣所有平行鏈都可以上線這個功能，真正實現波卡所有帳號類型的跨鏈使用。

Remote Proxy 的技術原理

Remote Proxy 的關鍵技術基礎，是Polkadot 的“跨鏈信任傳遞能力”，具體體現在Storage Proof（儲存證明）機制上。

簡單來說，Remote Proxy 不是在每條鏈上重複創建代理關係，而是統一把代理關係記錄在Relay Chain（中​​繼鏈）上，然後通過一種“證明機制”，讓其他鏈知道這份代理關係是真的。

用技術的話來說，在target 鏈上，如果提交了儲存內容（即pure proxy 的原始控制關係）、來源鏈的storage root 以及storage proof，如果storage root 有效，則pure proxy 的控制關係也有效。

那麼剩下的問題就是誰來保證storage root 的權威性（即這確實是relaychain 的有效存儲根），如果這個問題解決了，那麼就能證明要遷移的pure proxy 的控制關係確實來自relaychain。此時波卡的跨鏈機制設計起到了關鍵性作用：它允許所有平行鏈監聽和同步relaychain 的區塊頭（包含了storage root )，這也意味著任何平行鏈都可以透過這種方式有效遷移平行鏈的pure proxy 的控制關係/邏輯。

使用者跨鏈使用pure proxy 的操作順序回顧：

1. 註冊代理關係

用戶在Polkadot或Kusama中繼鏈上註冊一個Pure Proxy，例如設定Alice是某個帳戶的代理。

2. 提交跨鏈交易時提供儲存證明

當使用者在某個平行鏈上發起操作時，會同時附上三樣東西：

• Pure Proxy的原始代理關係（誰代理誰）

• 中繼鏈上某個區塊的Storage Root（狀態根）

• 儲存證明（Storage Proof），用於證明上述代理關係確實存在於該狀態根中

3. 平行鏈本地驗證這份儲存證明

這時就有個關鍵問題：平行鏈如何知道這個Storage Root 是真的？好消息是，Polkadot的跨鏈設計本來就允許所有平行鏈同步中繼鏈的區塊頭，而區塊頭中就包含了Storage Root。

所以平行鏈可以從Relay Chain 同步來的區塊頭中，驗證Storage Root，然後再透過Merkle Proof 來確認代理關係的真實性。

4. 交易通過，完成代理執行

一旦驗證通過，平行鏈就可以安全地認定這個代理關係是有效的，然後按Alice 的指令去執行操作。

Remote Proxy 依靠波卡底層跨鏈機制，採用了一種去信任（Trustless） 方式，確保代理關係在多個鏈上都可以安全驗證，而無需依賴中心化服務。

寫給開發者： Remote Proxy 使用教學課程

如果要基於remote-proxy 為使用者提供pure proxy 的跨鏈使用功能，可以參考下面這段程式碼範例：

 import { ApiPromise, WsProvider } from '@polkadot/api'; const YOUR_ACCOUNT = '5EjdajLJp5CKhGVaWV21wiyGxUw42rhCqGN32LuVH4wrqXTN';const PROXIED_ACCOUNT = 'D9o7gYB92kXgr1UTjYWLDwXK5BeJdxR2irjwaoDEhJnNCfp'; // Connect to Kusama and AssetHub Kusamaconst kusama_wsProvider = new WsProvider('wss://kusama.public.curie.radiumblock.co/ws');const kusama_api = await ApiPromise.create({ provider: kusama_wsProvider }); const ah_wsProvider = new WsProvider('wss://kusama-asset-hub-rpc.polkadot.io');const ah_api = await ApiPromise.create({ provider: ah_wsProvider }); const proxyDefinitionKey = kusama_api.query.proxy.proxies.key(PROXIED_ACCOUNT); console.log("ProxyDefinition key: " + proxyDefinitionKey); const blockToRoot = JSON.parse(await ah_api.query.remoteProxyRelayChain.blockToRoot());// Get the latest block for which AH knows the storage root.const proofBlock = blockToRoot[blockToRoot.length - 1][0];const proofBlockHash = await kusama_api.rpc.chain.getBlockHash(proofBlock); console.log("Fetching proof for block " + proofBlock) // Build the proof on Kusamaconst proof = JSON.parse(await kusama_api.rpc.state.getReadProof([proxyDefinitionKey], proofBlockHash)); // The call that will be executed by the proxied accountconst your_wrapped_call = ah_api.tx.balances.transferAll(YOUR_ACCOUNT, false); // Construct the proxy callconst proxy_call = ah_api.tx.remoteProxyRelayChain.remoteProxy( PROXIED_ACCOUNT, null, your_wrapped_call.method, { RelayChain: { proof: proof.proof, block: proofBlock }},); console.log("The call: " + proxy_call.method);console.log("Send via PJS: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-asset-hub-rpc.polkadot.io#/extrinsics/decode/" + proxy_call.method.toHex());

多簽用戶如何跨鏈使用pure proxy帳戶

根據原作者介紹，目前只記錄了最近一段時間（1min) 內relaychain 狀態根，這對普通交易沒有任何阻礙，但是對於協調時間可能長達幾天的多簽交易流程來說就會變得不可用。對此，原作者也有考慮到，我們可以在程式碼中看到答案：

和普通交易呼叫remote_proxy 方法不同，多簽交易呼叫的是remote_proxy_with_registered_proof，而這個方法並不需要立即提供storage proof，只要多籤的最後一個用戶在提交交易時透過register_remote_proxy_proof 方法提供storage proof 即可，這裡也是polka-sdk架構抽象的優越性體現：它抽象化了一個概念叫做dispatch_context，這就是交易的上下文，也意味著除了方法參數，還有另一種方法可以往一筆交易的上下文中塞入內容。

寫在最後

Polkadot 的核心價值在於其獨特的跨鏈互通性，而帳戶抽象化（Account Abstraction, AA）則是提升跨鏈使用者體驗的關鍵一環。 Ethereum 生態在AA 方面的探索催生了Keystore Rollup，試圖讓用戶能夠跨鏈管理帳戶並提升安全性。而Polkadot 生態的Remote Proxy方案，則提供了一條更原生、低成本且高效的路徑，直接繼承了Polkadot 的跨鏈安全性和靈活性。

從更廣闊的Web3 發展視角來看，帳戶抽像是通往無縫Web3 體驗的關鍵，而Remote Proxy 使得Polkadot 生態可以率先實現這一願景，為用戶提供安全、靈活、低摩擦的跨鏈帳戶管理方式。隨著Remote Proxy 逐步擴展到更多平行鏈，其應用場景將更加豐富，不僅可以支援DeFi、NFT、DAO 等領域的複雜權限管理，還可以為企業級帳戶管理提供強大支撐，推動整個Polkadot 生態邁向更成熟的階段。

Remote Proxy 作為波卡生態的關鍵帳戶抽象方案，為跨鏈帳戶管理提供了一種全新的方式。相較於以太坊的Keystore Rollup 方案，波卡的Remote Proxy 已經正式落地，並具備完整的儲存證明機制。

隨著Remote Proxy 逐步整合到Polkadot SDK，未來所有平行鏈都可以無縫支援該功能，進一步提升波卡生態的可用性和使用者體驗。

免責聲明：由PaperMoon提供並包含在本文中的資料僅用於學習目的。它們不構成財務或投資建議，也不應被解讀為任何商業決策的指導。我們建議讀者在做出任何投資或商業相關的決定之前，先進行獨立研究並諮詢專業人士。 PaperMoon對根據本文內容採取的任何行動不承擔任何責任。