Polkadot（波卡）是一个专注于跨链互操作性的区块链平台，其核心架构由中继链（Relay Chain）和平行链（Parachains）组成。中继链负责网络安全、共识和跨链通信，而平行链则是独立运行的区块链，可以根据自身需求定制规则。

目前，Polkadot 生态已发展出多个活跃的平行链，包括 Acala、Moonbeam、Astar、Phala 等，涵盖 DeFi、NFT、数据存储等多个领域。波卡的 XCM（Cross-Consensus Messaging）协议使得这些平行链可以安全、高效地进行资产和数据交互，真正实现多链互通。

在以太坊生态中，用户可以选择外部账户（EOA）或合约账户来管理资产。合约账户（如多签钱包、账户抽象账户）通常用于团队管理、DAO 资金管理等场景，但一个主要问题是：

• 在每条链上，用户需要单独部署合约账户（如 Safe），这不仅增加了管理复杂度，还导致跨链交互变得困难。

• 对于 DAO、基金管理等场景，成员需要单独维护各链的权限，不仅繁琐，还可能带来安全风险。

在 Polkadot 生态中，虽然 XCM 解决了资产的跨链转移问题，但账户管理仍然是一个挑战。用户希望在多个平行链上使用同一个账户，而不需要单独创建和管理多个账户，这正是账户抽象（Account Abstraction）需要解决的问题。

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 级别解决跨链账户管理问题。

在 Polkadot 生态中，账户主要有三种类型：

1. EOA（外部账户）：由私钥控制，天然具备跨链能力。

2. 多签账户（Multisig）：多个 EOA 共同控制，原生支持跨链。

3. Pure Proxy 账户：类似以太坊的合约账户，随机生成，由 EOA 或多签控制。

由于 Pure Proxy 账户是链上生成的，因此其控制关系必须存储在链上。这使得它在默认情况下无法跨链使用。总结来看，Polkadot 生态中的 EOA 和 Multisig 已经实现了跨链使用，唯一缺少的就是让 Pure Proxy 账户也能多链通用。

Remote Proxy 是 Polkadot 提出的跨链账户代理机制，允许用户在一条链上声明代理权限，并在另一条链上远程使用该权限。换句话说，用户可以在 Relay Chain（中继链）上设置代理账户，然后在不同的平行链上使用该代理进行操作。

这个解决方案来源于真实的用户问题：一开始有人因为不知道 Pure Proxy 无法跨链使用，导致资产丢失，这时大家想要恢复资产只能通过提国库提案来重新获得账户控制权：https://forum.polkadot.network/t/pure-proxy-replication-on-asset-hub-via-root-referendum/10802

这个事故引发了开发者们的深入讨论：既然 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 的关键技术基础，是 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 为用户提供 pure proxy 的跨链使用功能，可以参考下面这段代码示例：

代码示例：使用 Polkadot-JS 发送 Remote 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());

根据原作者介绍，目前只记录了最近一段时间（1min) 内 relaychain 状态根，这对普通交易没有任何阻碍，但是对于协调时间可能长达几天的多签交易流程来说就会变得不可用。对此，原作者也有考虑到，我们可以在代码中看到答案：

和普通交易调用 remote_proxy 方法不同，多签交易调用的是 remote_proxy_with_registered_proof，而这个方法并不需要立即提供 storage proof，只要多签的最后一个用户在提交交易时通过 register_remote_proxy_proof 方法提供 storage proof 即可，这里也是 polkadot-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，未来所有平行链都可以无缝支持该功能，进一步提升波卡生态的可用性和用户体验。