폴카닷은 크로스체인 상호운용성에 초점을 맞춘 블록체인 플랫폼입니다. 핵심 아키텍처는 릴레이 체인과 파라체인으로 구성됩니다. 릴레이 체인은 네트워크 보안, 합의, 크로스체인 통신을 담당하는 반면, 파라체인은 자체 요구 사항에 따라 규칙을 사용자 정의할 수 있는 독립적으로 운영되는 블록체인입니다.
현재 폴카닷 생태계는 Acala, Moonbeam, Astar, Phala 등을 포함하여 DeFi, NFT, 데이터 저장 및 기타 분야를 망라하는 여러 개의 활성 병렬 체인을 개발했습니다. 폴카닷의 XCM(Cross-Consensus Messaging) 프로토콜은 이러한 병렬 체인이 자산 및 데이터와 안전하고 효율적으로 상호 작용할 수 있도록 하여 진정한 멀티 체인 상호 운용성을 실현합니다.
크로스체인 시스템의 계정 추상화 문제
이더리움 생태계에서 사용자는 자산을 관리하기 위해 외부 계정(EOA) 또는 계약 계정을 선택할 수 있습니다. 계약 계정(다중 서명 지갑 및 계정 추상화 계정 등)은 일반적으로 팀 관리 및 DAO 자금 관리와 같은 시나리오에서 사용되지만 주요 문제는 다음과 같습니다.
각 체인에서 사용자는 별도의 계약 계정(예: Safe)을 배포해야 하는데, 이는 관리 복잡성을 증가시킬 뿐만 아니라 체인 간 상호 작용을 어렵게 만듭니다.
DAO나 펀드 관리 등의 시나리오에서, 구성원들은 각 체인에 대한 권한을 별도로 유지해야 하는데, 이는 번거로울 뿐만 아니라 보안 위험을 초래할 수도 있습니다.
폴카닷 생태계에서 XCM은 자산의 크로스체인 전송 문제를 해결하지만 계정 관리가 여전히 어려운 과제로 남아 있습니다. 사용자는 여러 계정을 별도로 만들고 관리하지 않고도 여러 파라체인에서 동일한 계정을 사용하고 싶어합니다. 이는 바로 Account Abstraction이 해결해야 할 문제입니다.
기존 솔루션: Ethereum의 Keystore Rollup 솔루션
키스토어 개념 및 역사
비탈릭 부테린(V God)은 2023년에 "키스토어 롤업: ZKP를 사용하여 지갑 관리를 간소화하기"라는 제목의 기사에서 키스토어 롤업이라는 개념을 처음 제안했습니다. 이 솔루션의 핵심 목표는 영지식 증명(ZKP)을 통해 지갑 관리를 최적화하여 사용자가 각 체인에서 별도로 키를 관리하지 않고도 여러 체인에서 동일한 계정을 사용할 수 있도록 하는 것입니다.
아래 그림에서 보듯이, 이더리움 메인넷에 생성된 계정은 여러 레이어2에서 동시에 사용할 수 있습니다(각 체인에 대해 별도의 계약 계정을 생성할 필요 없음).
현재 Safe는 Scroll 및 Base와 협력하여 Keystore Rollup 솔루션을 구현하려고 노력하고 있습니다. 하지만 이러한 솔루션은 아직 PoC(개념 증명) 단계에 있으며 실제 운영 환경에 적용되지 않았습니다.
이와 대조적으로 폴카닷은 원격 프록시라는 다른 접근 방식을 채택하여 L1 수준에서 직접 크로스체인 계정 관리 문제를 해결합니다.
Polkadot 계정 추상화를 위한 퍼즐의 마지막 조각 : 원격 프록시
배경 지식: Polkadot 계정 유형
Polkadot 생태계에는 세 가지 주요 계정 유형이 있습니다.
1. EOA(External Account): 개인 키로 제어되며, 자연스럽게 크로스체인 기능을 갖추고 있습니다.
2. 멀티시그: 여러 EOA가 공동으로 제어되며 기본적으로 크로스 체인을 지원합니다.
3. 순수 프록시 계정: 이더리움의 계약 계정과 유사하며 무작위로 생성되고 EOA 또는 다중 서명으로 제어됩니다.
Pure Proxy 계정은 체인상에서 생성되므로 해당 제어 관계도 체인상에 저장되어야 합니다. 이로 인해 기본적으로 여러 체인에서 사용할 수 없습니다. 요약하자면, 폴카닷 생태계의 EOA와 멀티시그는 크로스체인 사용을 달성했습니다. 유일하게 부족한 점은 Pure Proxy 계정을 여러 체인에서 사용할 수 있도록 하는 것입니다.
원격 프록시란 무엇인가요?
원격 프록시는 폴카닷이 제안한 크로스체인 계정 프록시 메커니즘으로, 사용자가 한 체인에서 프록시 권한을 선언하고 다른 체인에서 원격으로 해당 권한을 사용할 수 있도록 해줍니다. 즉, 사용자는 릴레이 체인에 프록시 계정을 설정한 다음 해당 프록시를 사용하여 여러 병렬 체인에서 작업할 수 있습니다.
원격 프록시의 역사
이 솔루션은 실제 사용자 문제에서 비롯되었습니다. 처음에는 일부 사람들이 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
개발자들의 토론의 초점은 순수 프록시 계정을 여러 체인에 복제할 수 있다면 새로운 체인에 등록된 순수 프록시에 대한 제어는 어떻게 처리해야 하는가입니다. 전반적으로 수요에 따른 이주인가, 일회성 이주인가? 두 가지 범주로 나뉜다. 그중에서도 xlc는 매우 고전적인 시나리오를 제안했습니다.
일회성 마이그레이션: 계정 제어는 원래 체인에서 새 체인으로 한 번에 "복사"되고 모든 체인은 동일한 프록시 제어 관계를 공유합니다.
사용-이전 학파(궁극적으로 채택됨)는 특정 체인에서 사용될 때마다 해당 제어 관계를 동적으로 생성하고 필요에 따라 이를 마이그레이션하는 것입니다.
일회성 마이그레이션으로 인해 발생하는 문제는 순수 프록시의 제어가 여러 번 복사되어 여러 체인에서 사용될 경우 제어에 혼란이 발생할 가능성이 있다는 것입니다. 결국 Polkadot-sdk 핵심 개발자 Bastian은 "사용 및 마이그레이션" 솔루션을 선택했습니다.
최신 Kusama AssetHub 체인 업그레이드에서는 remote-proxy가 사용되기 시작했으며(런타임 1.4.2 업그레이드) 공식적으로 프로덕션 환경에 들어갔습니다. 현재 원격 프록시 코드는 여전히 http://github.com/polkadot-fellows/runtimes/ 저장소에 있습니다. 바스티안은 향후 코드가 Polkadot-SDK로 마이그레이션되어 모든 파라체인이 이 기능을 출시하고 Polkadot의 모든 계정 유형의 크로스체인 사용을 실제로 실현할 수 있을 것이라고 말했습니다.
원격 프록시의 기술 원리
Remote Proxy의 핵심 기술적 기반은 Polkadot의 "크로스체인 신뢰 전송 기능"이며, 이는 구체적으로 Storage Proof 메커니즘에 반영됩니다.
간단히 말해서, 원격 프록시는 각 체인에 반복적으로 프록시 관계를 생성하지 않고, 릴레이 체인에 프록시 관계를 균일하게 기록한 다음, "증명 메커니즘"을 사용하여 다른 체인에 프록시 관계가 사실임을 알립니다.
기술적으로 말하면, 대상 체인에서 저장 내용(즉, 순수 프록시의 원래 제어 관계), 소스 체인의 저장 루트, 저장 증명이 제출되면 저장 루트가 유효하면 순수 프록시의 제어 관계도 유효합니다.
그러면 남은 질문은 누가 스토리지 루트의 권한을 보장할 것인가(즉, 이것이 실제로 릴레이체인의 유효한 스토리지 루트인지 여부)입니다. 이 문제가 해결되면, 마이그레이션되는 순수 프록시의 제어 관계가 실제로 릴레이체인에서 나온다는 것을 증명할 수 있습니다. 이때 폴카닷의 크로스체인 메커니즘 설계가 핵심 역할을 합니다. 모든 병렬 체인이 릴레이체인의 블록 헤더(스토리지 루트 포함)를 수신하고 동기화할 수 있게 해주므로, 모든 병렬 체인이 이런 방식으로 병렬 체인의 순수 프록시의 제어 관계/논리를 효과적으로 이전할 수 있습니다.
사용자가 체인 전반에서 순수 프록시를 사용하기 위한 작업 순서 검토:
1. 등록 대리점 관계
사용자는 Polkadot 또는 Kusama 릴레이 체인에 Pure Proxy를 등록하여, 예를 들어 Alice를 특정 계정의 프록시로 설정합니다.
2. 크로스체인 거래 제출 시 저장 증명 제공
사용자가 파라체인에서 작업을 시작하면 세 가지가 동시에 연결됩니다.
Pure Proxy의 원래 프록시 관계(누가 누구를 대표하는가)
릴레이 체인의 블록의 저장 루트
저장 증명은 위의 프록시 관계가 상태 루트에 존재한다는 것을 증명하는 데 사용됩니다.
3. Parachain은 로컬에서 저장 증명을 검증합니다.
이 시점에서 중요한 질문이 생깁니다. 파라체인은 이 저장 루트가 실제라는 것을 어떻게 알 수 있을까요? 좋은 소식은 Polkadot의 크로스체인 디자인을 통해 모든 병렬 체인이 릴레이 체인의 블록 헤더를 동기화할 수 있으며, 블록 헤더에 스토리지 루트가 포함된다는 것입니다.
따라서 파라체인은 릴레이 체인에서 동기화된 블록 헤더로부터 스토리지 루트를 검증한 후, 머클 증명을 통해 프록시 관계의 진위를 확인할 수 있습니다.
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라는 개념을 추상화합니다. 즉, 메서드 매개변수 외에도 트랜잭션 컨텍스트에 콘텐츠를 삽입하는 또 다른 방법이 있다는 의미입니다.
마지막 말
폴카닷의 핵심 가치는 독특한 크로스체인 상호 운용성에 있으며, 계정 추상화(AA)는 크로스체인 사용자 경험을 개선하는 데 중요한 연결 고리입니다. 이더리움 생태계에서 AA를 탐색하면서 Keystore Rollup이 탄생했습니다. Keystore Rollup은 사용자가 여러 체인에서 계정을 관리하고 보안을 강화할 수 있도록 하는 것을 목표로 합니다. Polkadot 생태계의 원격 프록시 솔루션은 Polkadot의 크로스체인 보안과 유연성을 직접 계승하여 보다 고유하고 저렴하며 효율적인 경로를 제공합니다.
Web3 개발의 더 넓은 관점에서 볼 때, 계정 추상화는 원활한 Web3 경험의 핵심이며, Remote Proxy를 통해 Polkadot 생태계는 이 비전을 최초로 실현하여 사용자에게 안전하고 유연하며 마찰이 적은 크로스체인 계정 관리 방법을 제공할 수 있습니다. 원격 프록시가 점차 더 많은 파라체인으로 확장됨에 따라 적용 시나리오도 더욱 풍부해질 것입니다. DeFi, NFT, DAO 등 다양한 분야에서 복잡한 권한 관리를 지원할 뿐만 아니라, 기업 수준의 계정 관리에도 강력한 지원을 제공하고, 폴카닷 생태계 전체를 더욱 성숙한 단계로 끌어올립니다.
Polkadot 생태계의 주요 계정 추상화 솔루션인 Remote Proxy는 크로스체인 계정 관리를 위한 새로운 방식을 제공합니다. 이더리움의 키스토어 롤업 솔루션과 비교했을 때, 폴카닷의 원격 프록시는 공식적으로 출시되었으며 완전한 저장 증명 메커니즘을 갖추고 있습니다.
Remote Proxy가 점진적으로 Polkadot SDK에 통합됨에 따라 향후 모든 파라체인은 이 기능을 원활하게 지원할 수 있게 되며, 이를 통해 Polkadot 생태계의 사용성과 사용자 경험이 더욱 향상될 것입니다.
면책 조항: PaperMoon에서 제공하고 이 기사에 포함된 자료는 교육 목적으로만 사용됩니다. 이는 금융 또는 투자에 대한 조언을 구성하지 않으며, 어떠한 사업적 결정에 대한 지침으로 해석되어서는 안 됩니다. 독자 여러분께서 투자나 사업 관련 결정을 내리기 전에 독립적인 조사를 수행하고 전문가와 상의하시기를 권장합니다. PaperMoon은 이 기사의 내용을 바탕으로 취해진 모든 조치에 대해 책임을 지지 않습니다.
