Polkadot は、クロスチェーンの相互運用性に重点を置いたブロックチェーン プラットフォームです。そのコアアーキテクチャはリレーチェーンとパラチェーンで構成されています。リレーチェーンはネットワークセキュリティ、コンセンサス、チェーン間通信を担当し、パラチェーンは独自のニーズに応じてルールをカスタマイズできる独立運用ブロックチェーンです。
現在、Polkadot エコシステムは、Acala、Moonbeam、Astar、Phala など、DeFi、NFT、データ ストレージなどの分野をカバーするいくつかのアクティブな並列チェーンを開発しています。 Polkadot の XCM (Cross-Consensus Messaging) プロトコルにより、これらの並列チェーンは資産やデータと安全かつ効率的にやり取りできるようになり、マルチチェーンの相互運用性が真に実現されます。
クロスチェーンシステムにおけるアカウント抽象化の問題
Ethereum エコシステムでは、ユーザーは資産を管理するために外部アカウント (EOA) または契約アカウントを選択できます。コントラクトアカウント（マルチシグネチャウォレットやアカウント抽象化アカウントなど）は通常、チーム管理やDAOファンド管理などのシナリオで使用されますが、大きな問題は次のとおりです。
各チェーンでは、ユーザーは個別の契約アカウント (Safe など) を展開する必要があり、これにより管理の複雑さが増すだけでなく、チェーン間の相互作用も困難になります。
DAO やファンド管理などのシナリオでは、メンバーが各チェーンの権限を個別に管理する必要があり、これは面倒なだけでなく、セキュリティ上のリスクをもたらす可能性もあります。
Polkadot エコシステムでは、XCM によって資産のクロスチェーン転送の問題が解決されますが、アカウント管理は依然として課題となっています。ユーザーは、複数のアカウントを個別に作成して管理することなく、複数のパラチェーンで同じアカウントを使用したいと考えています。これはまさに、アカウント抽象化が解決する必要がある問題です。
既存のソリューション: Ethereumのキーストアロールアップソリューション
キーストアの概念と歴史
Vitalik Buterin (V God) は、2023 年に「Keystore Rollups: ZKP を使用してウォレット管理を簡素化する」という記事で、Keystore Rollup の概念を初めて提案しました。このソリューションの主な目標は、ゼロ知識証明 (ZKP) を通じてウォレット管理を最適化し、ユーザーが各チェーンで個別にキーを管理することなく、チェーン間で同じアカウントを使用できるようにすることです。
下の図に示すように、eth メインネット上に作成されたアカウントは、複数のレイヤー 2 で同時に使用できます (チェーンごとに個別のコントラクト アカウントを作成する必要はありません)。
現在、Safe は Scroll および Base と協力して、Keystore Rollup ソリューションの実装に取り組んでいます。ただし、これらのソリューションはまだ PoC (概念実証) 段階にあり、実稼働環境に実際に適用されていません。
対照的に、Polkadot は、クロスチェーン アカウント管理問題を L1 レベルで直接解決するために、リモート プロキシという異なるアプローチを採用しています。
Polkadotアカウント抽象化の最後のピース：リモートプロキシ
背景知識:Polkadotアカウントの種類
Polkadot エコシステムには、主に 3 種類のアカウントがあります。
1. EOA（外部アカウント）：秘密鍵で制御され、当然クロスチェーン機能を備えています。
2. マルチシグ: 複数の EOA が共同で制御され、クロスチェーンをネイティブにサポートします。
3. ピュアプロキシアカウント：イーサリアムのコントラクトアカウントと同様に、EOAまたはマルチ署名によってランダムに生成され、制御されます。
Pure Proxy アカウントはオンチェーンで生成されるため、その制御関係もオンチェーンで保存する必要があります。これにより、デフォルトではチェーン間で使用できなくなります。要約すると、Polkadot エコシステムの EOA と Multisig はクロスチェーン使用を実現しました。唯一欠けているのは、Pure Proxy アカウントを複数のチェーンで使用できるようにすることです。
リモート プロキシとは何ですか?
リモート プロキシは、Polkadot が提案したクロスチェーン アカウント プロキシ メカニズムであり、ユーザーは 1 つのチェーンでプロキシ権限を宣言し、別のチェーンでリモートでその権限を使用できます。つまり、ユーザーはリレー チェーンにプロキシ アカウントを設定し、そのプロキシを使用して異なる並列チェーンを操作できます。
リモートプロキシの歴史
このソリューションは、実際のユーザーの問題から生まれました。最初は、Pure Proxy がチェーン間で使用できないことを知らなかったために資産を失った人もいました。現時点では、誰もが資産を取り戻したい場合、財務提案を提出することによってのみアカウントの制御を取り戻すことができました: https://forum.polkadot.network/t/pure-proxy-replication-on-asset-hub-via-root-referendum/10802
この事件は開発者の間で徹底的な議論を引き起こしました。Pure Proxy はアカウント抽象化の非常に一般的な方法であるため、各チェーンに再適用するのではなく、パスポートのように複数のチェーンで使用できるでしょうか?
その後、純粋なプロキシ アカウント複製の提案が登場しました。
https://github.com/polkadot-fellows/RFCs/pull/111
開発者の議論の焦点は、純粋プロキシ アカウントを複数のチェーンに複製できる場合、新しいチェーンに登録された純粋プロキシの制御をどのように処理する必要があるかということです。全体的には、オンデマンドの移行と 1 回限りの移行の 2 つの陣営に分かれます。その中で、xlc は非常に古典的なシナリオを提案しました。
1 回限りの移行: アカウント制御は元のチェーンから新しいチェーンに一度に「コピー」され、すべてのチェーンが同じプロキシ制御関係を共有します。
使用と移行の学派（最終的に採用）は、特定のチェーンで使用されるたびに、対応する制御関係を動的に生成し、必要に応じて移行するというものです。
一度の移行によって生じる問題は、純粋プロキシの制御が複数回コピーされ、複数のチェーンで使用される場合、制御に混乱が生じる可能性があることです。結局、Polkadot-sdk コア開発者の Bastian は、「使用して移行する」ソリューションを選択しました。
最新の Kusama AssetHub チェーン アップグレードでは、remote-proxy が使用されるようになり (Runtime 1.4.2 アップグレード)、正式に本番環境に導入されました。現在、リモート プロキシ コードはまだ http://github.com/polkadot-fellows/runtimes/ リポジトリにあります。バスティアン氏は、将来的にはこのコードがPolkadot-SDKに移行され、すべてのパラチェーンがこの機能を起動できるようになり、Polkadotのすべてのアカウントタイプのクロスチェーン使用が真に実現されるだろうと述べた。
リモートプロキシの技術原理
リモート プロキシの重要な技術的基盤は、Polkadot の「クロスチェーン信頼転送機能」であり、これはストレージ プルーフ メカニズムに具体的に反映されています。
簡単に言うと、リモート プロキシは各チェーン上でプロキシ関係を繰り返し作成するのではなく、リレー チェーン上でプロキシ関係を均一に記録し、その後「証明メカニズム」を使用して他のチェーンにプロキシ関係が真実であることを知らせます。
技術的に言えば、ターゲット チェーン上で、ストレージ コンテンツ (つまり、純粋プロキシの元の制御関係)、ソース チェーンのストレージ ルート、およびストレージ証明が送信され、ストレージ ルートが有効であれば、純粋プロキシの制御関係も有効になります。
残る疑問は、ストレージ ルートの権限を誰が保証するか (つまり、これが実際にリレーチェーンの有効なストレージ ルートであるかどうか) です。この問題が解決されれば、移行対象の純粋プロキシの制御関係が実際にリレーチェーンからのものであることが証明できます。このとき、Polkadot のクロスチェーン機構の設計が重要な役割を果たします。すべての並列チェーンがリレーチェーンのブロック ヘッダー (ストレージ ルートを含む) をリッスンして同期できるため、どの並列チェーンでも、この方法で並列チェーンの純粋なプロキシの制御関係/ロジックを効果的に移行できます。
ユーザーがチェーン全体で純粋なプロキシを使用するための操作シーケンスの確認:
1. 登録代理店関係
ユーザーは、Polkadot または Kusama リレー チェーンに Pure Proxy を登録し、たとえば、Alice を特定のアカウントのプロキシとして設定します。
2. クロスチェーントランザクションの送信時に保管証明を提供する
ユーザーがパラチェーン上で操作を開始すると、次の 3 つのものが同時に追加されます。
Pure Proxy の本来の代理関係（誰が誰を代表するか）
リレーチェーン上のブロックのストレージルート
ストレージ証明は、上記のプロキシ関係が状態ルートに存在することを証明するために使用されます。
3. パラチェーンはストレージ証明をローカルで検証する
この時点で重要な疑問が生じます。パラチェーンはどのようにしてこのストレージ ルートが本物であることを知るのでしょうか?良いニュースとしては、Polkadot のクロスチェーン設計により、すべての並列チェーンがリレーチェーンのブロック ヘッダーを同期できるようになり、ブロック ヘッダーにはストレージ ルートが含まれるようになります。
したがって、パラチェーンはリレーチェーンから同期されたブロックヘッダーからストレージルートを検証し、Merkle Proof を通じてプロキシ関係の信頼性を確認できます。
4. 取引が承認され、エージェントの実行が完了します
検証が成功すると、パラチェーンはプロキシ関係が有効であることを安全に判断し、アリスの指示に従って操作を実行できます。
リモート プロキシは、Polkadot の基盤となるクロスチェーン メカニズムに依存しており、トラストレス アプローチを採用することで、集中型サービスに依存せずに複数のチェーン上でプロキシ関係を安全に検証できるようにします。
開発者向け:リモートプロキシチュートリアル
リモート プロキシに基づく純粋なプロキシ クロスチェーン使用機能をユーザーに提供したい場合は、次のコード例を参照してください。
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());マルチ署名ユーザーは、チェーン全体で純粋なプロキシ アカウントをどのように使用するのでしょうか?
原作者によると、現在は最新の期間 (1 分) 内のリレーチェーン状態ルートのみが記録されます。これは通常のトランザクションを妨げるものではありませんが、調整時間が数日に及ぶ可能性があるマルチ署名トランザクションプロセスでは使用できなくなります。元の作者もこの点を考慮していて、その答えはコードの中にあります。
remote_proxy メソッドを呼び出す通常のトランザクションとは異なり、マルチ署名トランザクションは remote_proxy_with_registered_proof を呼び出します。この場合、ストレージ証明をすぐに提供する必要はありません。マルチ署名の最後のユーザーがトランザクションを送信するときに、register_remote_proxy_proof メソッドを通じてストレージ証明を提供していれば、それで十分です。これは、polkadot-sdk の抽象アーキテクチャの優位性を反映したものでもあります。つまり、トランザクションのコンテキストである dispatch_context という概念が抽象化されており、メソッド パラメータに加えて、トランザクションのコンテキストにコンテンツを挿入する別の方法があることを意味します。
最後の言葉
Polkadot の核となる価値は、独自のクロスチェーン相互運用性にあり、アカウント抽象化 (AA) はクロスチェーン ユーザー エクスペリエンスを向上させるための重要なリンクです。 Ethereum エコシステムの AA の探求により、ユーザーがチェーン全体でアカウントを管理し、セキュリティを向上できるようにする Keystore Rollup が誕生しました。 Polkadot エコシステムのリモート プロキシ ソリューションは、Polkadot のクロスチェーン セキュリティと柔軟性を直接継承し、よりネイティブで低コストかつ効率的なパスを提供します。
Web3 開発のより広い観点から見ると、アカウントの抽象化はシームレスな Web3 エクスペリエンスの鍵であり、Remote Proxy により、Polkadot エコシステムはこのビジョンを最初に実現し、ユーザーに安全で柔軟性があり、摩擦の少ないクロスチェーン アカウント管理方法を提供できるようになります。リモート プロキシが徐々により多くのパラチェーンに拡張されるにつれて、そのアプリケーション シナリオはより豊かになります。 DeFi、NFT、DAOなどの分野での複雑な権限管理をサポートするだけでなく、エンタープライズレベルのアカウント管理を強力にサポートし、Polkadotエコシステム全体をより成熟した段階に推進します。
Polkadot エコシステムの主要なアカウント抽象化ソリューションとして、リモート プロキシはクロスチェーン アカウント管理の新しい方法を提供します。 Ethereum の Keystore Rollup ソリューションと比較すると、Polkadot のリモート プロキシは正式にリリースされており、完全なストレージ証明メカニズムを備えています。
リモート プロキシが徐々に Polkadot SDK に統合されるにつれて、将来的にはすべてのパラチェーンがこの機能にシームレスに対応できるようになり、Polkadot エコシステムの使いやすさとユーザー エクスペリエンスがさらに向上します。
免責事項: PaperMoon が提供し、この記事に含まれる資料は、教育目的のみに使用されます。これらは財務または投資に関するアドバイスではなく、ビジネス上の決定の指針として解釈されるべきではありません。投資やビジネス関連の決定を行う前に、読者は独自の調査を実施し、専門家に相談することをお勧めします。 PaperMoon は、この記事の内容に基づいて行われたいかなる行為についても一切責任を負いません。
