Polkadot is a blockchain platform focused on cross-chain interoperability, and its core architecture consists of the Relay Chain and Parachains. The Relay Chain is responsible for network security, consensus, and cross-chain communication, while the Parachain is an independently operated blockchain that can customize rules according to its own needs.
At present, the Polkadot ecosystem has developed a number of active parachains, including Acala, Moonbeam, Astar, Phala, etc., covering DeFi, NFT, data storage and other fields. Polkadot's XCM (Cross-Consensus Messaging) protocol enables these parachains to interact with assets and data safely and efficiently, truly realizing multi-chain interoperability.
Account abstraction issues in cross-chain systems
In the Ethereum ecosystem, users can choose external accounts (EOA) or contract accounts to manage assets. Contract accounts (such as multi-signature wallets, account abstraction accounts) are usually used in scenarios such as team management and DAO fund management, but a major problem is:
On each chain, users need to deploy a separate contract account (such as Safe), which not only increases management complexity, but also makes cross-chain interaction difficult.
For scenarios such as DAO and fund management, members need to maintain the permissions of each chain separately, which is not only cumbersome but may also bring security risks.
In the Polkadot ecosystem, although XCM solves the problem of cross-chain asset transfer, account management is still a challenge. Users want to use the same account on multiple parachains without having to create and manage multiple accounts separately, which is exactly the problem that Account Abstraction needs to solve.
Existing solution: Ethereum's Keystore Rollup solution
Keystore concept and history
Vitalik Buterin first proposed the concept of Keystore Rollup in an article titled "Keystore Rollups: Using ZKPs to Simplify Wallet Management" in 2023. The core goal of this solution is to optimize wallet management through zero-knowledge proof (ZKP), so that users can use the same account across chains without having to manage keys separately on each chain.
As shown in the figure below, the account created on the eth mainnet can be used in multiple layer2s at the same time (without the need to create a separate contract account for each chain).
Currently, Safe is working with Scroll and Base to try to implement the Keystore Rollup solution. However, these solutions are still in the PoC (proof of concept) stage and have not yet been truly applied to production environments.
In contrast, Polkadot adopts a different approach, namely Remote Proxy, to solve the cross-chain account management problem directly at the L1 level.
The last piece of the puzzle for Polkadot account abstraction : remote-proxy
Background knowledge: Polkadot account types
In the Polkadot ecosystem, there are three main types of accounts:
1. EOA (External Account): Controlled by a private key, it naturally has cross-chain capabilities.
2. Multisig: Multiple EOAs are jointly controlled and natively support cross-chain.
3. Pure Proxy Account: Similar to Ethereum’s contract account, it is randomly generated and controlled by EOA or multi-signature.
Since the Pure Proxy account is generated on-chain, its control relationship must be stored on-chain. This makes it impossible to use it across chains by default. In summary, EOA and Multisig in the Polkadot ecosystem have already achieved cross-chain use. The only thing missing is to make Pure Proxy accounts also multi-chain universal.
What is Remote Proxy?
Remote Proxy is a cross-chain account proxy mechanism proposed by Polkadot, which allows users to declare proxy permissions on one chain and use the permissions remotely on another chain. In other words, users can set up a proxy account on the Relay Chain and then use the proxy to operate on different parallel chains.
The History of Remote Proxy
This solution comes from a real user problem: At first, some people lost their assets because they didn’t know that Pure Proxy could not be used across chains. At this time, if everyone wanted to recover their assets, they could only regain control of their accounts by submitting a treasury proposal: https://forum.polkadot.network/t/pure-proxy-replication-on-asset-hub-via-root-referendum/10802
This incident triggered an in-depth discussion among developers: Since Pure Proxy is a very common way of account abstraction, can it be used on multiple chains like a passport, instead of having to be re-applied for each chain?
Then a pure proxy account replication proposal appeared:
https://github.com/polkadot-fellows/RFCs/pull/111
The focus of the developers' debate is, if the pure proxy account can be replicated on multiple chains, then how should the control of the pure proxy registered on the new chain be handled? The overall debate is divided into two camps: migration as soon as it is used or one-time migration? Among them, xlc proposed a very classic scenario:
One-time migration: Account control is "copied" from the original chain to the new chain at one time, and all chains share the same Proxy control relationship.
The use-and-migration school (ultimately adopted) is to dynamically generate the corresponding control relationship each time it is used on a certain chain and migrate it as needed.
The problem caused by a one-time migration is that if the control of the pure proxy is copied multiple times and used on multiple chains, it is likely to cause confusion in control. So in the end, Bastian, the core developer of polkadot-sdk, chose the "use-and-migrate" solution.
In the latest Kusama AssetHub chain upgrade, remote-proxy has been put into use (Runtime 1.4.2 upgrade), and has officially entered the production environment. Currently, the remote-proxy code is still in the http://github.com/polkadot-fellows/runtimes/ warehouse. Bastian said that the code will be migrated to Polkadot-SDK in the future, so that all parachains can launch this function and truly realize the cross-chain use of all account types of Polkadot.
Technical principles of Remote Proxy
The key technical foundation of Remote Proxy is Polkadot’s “cross-chain trust transfer capability”, which is specifically reflected in the Storage Proof mechanism.
Simply put, Remote Proxy does not repeatedly create proxy relationships on each chain, but records the proxy relationships uniformly on the Relay Chain, and then uses a "proof mechanism" to let other chains know that the proxy relationship is true.
In technical terms, on the target chain, if the storage content (i.e. the original control relationship of the pure proxy), the storage root of the source chain, and the storage proof are submitted, if the storage root is valid, the control relationship of the pure proxy is also valid.
Then the remaining question is who will guarantee the authority of the storage root (that is, this is indeed the effective storage root of the relaychain). If this problem is solved, it can be proved that the control relationship of the pure proxy to be migrated is indeed from the relaychain. At this time, Polkadot's cross-chain mechanism design plays a key role: it allows all parallel chains to monitor and synchronize the block headers of the relaychain (including the storage root), which means that any parallel chain can effectively migrate the control relationship/logic of the pure proxy of the parallel chain in this way.
Review of the operation sequence for users to use pure proxy across chains:
1. Registered Agency Relationship
The user registers a Pure Proxy on the Polkadot or Kusama relay chain, for example, setting Alice as the proxy of a certain account.
2. Providing storage proof when submitting cross-chain transactions
When a user initiates an operation on a parachain, three things are attached at the same time:
Pure Proxy's original proxy relationship (who represents whom)
Storage Root of a block on the relay chain
Storage Proof, used to prove that the above proxy relationship does exist in the state root
3. Parachain locally verifies the storage proof
At this point, there is a key question: How does the parachain know that this Storage Root is real? The good news is that Polkadot's cross-chain design allows all parachains to synchronize the block header of the relay chain, and the block header contains the Storage Root.
Therefore, the parachain can verify the Storage Root from the block header synchronized from the Relay Chain, and then confirm the authenticity of the proxy relationship through Merkle Proof.
4. The transaction is approved and the agent execution is completed
Once the verification is successful, the parachain can safely determine that the proxy relationship is valid and then execute the operation according to Alice's instructions.
Remote Proxy relies on Polkadot's underlying cross-chain mechanism and adopts a trustless approach to ensure that proxy relationships can be securely verified on multiple chains without relying on centralized services.
For developers: Remote Proxy tutorial
If you want to provide users with pure proxy cross-chain usage capabilities based on remote-proxy, you can refer to the following code example:
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());How do multi-signature users use pure proxy accounts across chains?
According to the original author, currently only the relaychain state root within the most recent period (1 minute) is recorded, which does not hinder ordinary transactions, but becomes unavailable for multi-signature transaction processes that may take several days to coordinate. The original author has also considered this, and we can see the answer in the code:
Unlike ordinary transactions that call the remote_proxy method, multi-signature transactions call remote_proxy_with_registered_proof, which does not require the immediate provision of storage proof. As long as the last user of the multi-signature provides the storage proof through the register_remote_proxy_proof method when submitting the transaction, it is sufficient. This is also a reflection of the superiority of the abstract architecture of polkadot-sdk: it abstracts a concept called dispatch_context, which is the context of the transaction, which means that in addition to method parameters, there is another way to insert content into the context of a transaction.
Last words
The core value of Polkadot lies in its unique cross-chain interoperability, and Account Abstraction (AA) is a key link in improving the cross-chain user experience. Ethereum's exploration of AA has given rise to Keystore Rollup, which attempts to enable users to manage accounts across chains and improve security. The Remote Proxy solution of the Polkadot ecosystem provides a more native, low-cost and efficient path, which directly inherits Polkadot's cross-chain security and flexibility.
From a broader perspective of Web3 development, account abstraction is the key to a seamless Web3 experience, and Remote Proxy enables the Polkadot ecosystem to be the first to realize this vision, providing users with a secure, flexible, and low-friction cross-chain account management method. As Remote Proxy gradually expands to more parachains, its application scenarios will become richer, not only supporting complex permission management in DeFi, NFT, DAO and other fields, but also providing strong support for enterprise-level account management, pushing the entire Polkadot ecosystem towards a more mature stage.
As a key account abstraction solution for the Polkadot ecosystem, Remote Proxy provides a new way for cross-chain account management. Compared with Ethereum's Keystore Rollup solution, Polkadot's Remote Proxy has been officially launched and has a complete storage proof mechanism.
As Remote Proxy is gradually integrated into the Polkadot SDK, all parachains in the future will be able to seamlessly support this function, further improving the usability and user experience of the Polkadot ecosystem.
Disclaimer: The materials provided by PaperMoon and included in this article are for educational purposes only. They do not constitute financial or investment advice and should not be interpreted as guidance for any business decision. We recommend that readers conduct independent research and consult professionals before making any investment or business-related decisions. PaperMoon assumes no liability for any actions taken based on the contents of this article.
