PolkaWorld 커뮤니티에 가입하여 Web 3.0을 함께 구축하십시오!

최종 Polkadot 1.0 릴리스와 파라체인이 다가옴에 따라 교차 합의 메시지 형식(Cross Consensus Message Format, 줄여서 XCM)이 첫 번째 생산 준비 버전을 출시할 예정입니다. 이것은 형식, 목표, 작동 방식에 대한 소개이며 일반적인 교차 체인 작업을 구현하는 데 사용할 수 있습니다.

최종 Polkadot 1.0 릴리스와 파라체인이 다가옴에 따라 교차 합의 메시지 형식(Cross Consensus Message Format, 줄여서 XCM)이 첫 번째 생산 준비 버전을 출시할 예정입니다. 이것은 형식, 목표, 작동 방식에 대한 소개이며 일반적인 교차 체인 작업을 구현하는 데 사용할 수 있습니다.

흥미로운 사실부터 시작하겠습니다. XCM은 "교차 체인"이 아니라 "교차 합의" 메시지 형식입니다. 이 차이는 형식이 궁극적으로 무엇을 달성하는지에 대한 신호이며, 체인 간의 통신뿐만 아니라 스마트 계약과 모듈 간의 통신은 물론 브리지와 샤드(예: Polkadot의 Spree)를 통해 다양한 아이디어를 보내는 형식입니다.

mdnice 편집기

🤟 프로토콜이 아닌 형식

브리지 및 계약 모듈을 제외하고 Polkadot에는 구성 체인 간에 실제로 XCM 메시지를 통신하기 위한 세 가지 고유 시스템인 UMP, DMP 및 XCMP가 있습니다. UMP(Up Message Passing)는 파라체인이 릴레이 체인에 메시지를 보낼 수 있도록 합니다. DMP(Downward Messaging)는 릴레이 체인이 파라체인으로 메시지를 전달할 수 있도록 합니다. XCMP는 파라체인 간에 메시지를 보낼 수 있게 해주는 가장 유명한 것입니다. XCM은 이 세 가지 통신 채널을 통해 메시지의 의미를 표현하는 데 사용할 수 있습니다.

체인 간에 메시지를 보내는 것 외에도 XCM은 다른 컨텍스트에서도 유용합니다. 예를 들어 이전에 잘 알지 못했던 트랜잭션 형식의 체인에서 트랜잭션을 수행하는 데 사용할 수 있습니다. 비즈니스 로직이 거의 변경되지 않는 체인(예: 비트코인)의 경우 트랜잭션 형식(또는 지갑이 체인에 명령을 보내는 데 사용하는 형식)은 정확히 동일하거나 최소한 호환 가능하며 무기한으로 유지되는 경향이 있습니다. Polkadot 및 그 구성 파라체인과 같이 고도로 진화 가능한 메타 프로토콜 기반 체인을 사용하여 단일 트랜잭션으로 네트워크 전체에서 비즈니스 로직을 업그레이드할 수 있습니다. 이것은 트랜잭션 형식을 포함하여 무엇이든 변경하여 지갑 관리자, 특히 오프라인으로 유지해야 하는 지갑(예: 패리티 서명자)에 잠재적인 문제를 일으킬 수 있습니다. XCM은 버전 관리가 잘 되어 있고 추상적이며 일반적이기 때문에 많은 공통 트랜잭션을 생성하기 위한 지속적인 트랜잭션 형식을 지갑에 제공하는 수단으로 사용할 수 있습니다.

mdnice 편집기

🥅 목표

모든 언어와 마찬가지로 일부 사람들은 다른 요소보다 특정 요소를 더 많이 사용합니다. XCM은 XCM을 지원하는 모든 시스템이 가능한 모든 XCM 메시지를 해석할 수 있도록 설계되지 않았습니다. 일부 메시지는 일부 시스템에서 합리적으로 해석되지 않습니다. 다른 것들은 합리적일 수 있지만 리소스 제약으로 인해 또는 동일한 콘텐츠가 보다 명확하고 정식적인 방식으로 표현될 수 있기 때문에 여전히 인터프리터에서 의도적으로 지원하지 않습니다. 시스템은 필연적으로 가능한 메시지의 하위 집합만 지원합니다. 심각하게 리소스 제약이 있는 시스템(예: 스마트 계약)은 매우 제한된 "방언"만 지원할 수 있습니다.

이러한 보급은 XCM 메시지 실행에 대한 지불과 같은 개념까지 확장됩니다. 우리는 XCM이 가스 측정 스마트 계약 플랫폼 및 커뮤니티 파라체인에서 시스템 파라체인과 릴레이 체인 간의 신뢰할 수 있는 상호 작용에 이르기까지 다양한 시스템에서 사용될 수 있음을 알고 있으므로 수수료 지불과 같은 요소를 굽고 싶지 않습니다. 너무 깊고 계약에서 돌이킬 수 없게됩니다.

mdnice 편집기

😬 기본 메시지 형식을 사용하지 않는 이유

둘째, 온체인의 일반적인 사용 사례는 단일 트랜잭션에 쉽게 맞지 않으며 자금을 인출하고 자금을 교환한 다음 결과를 모두 단일 트랜잭션으로 입금하려면 특별한 트릭이 필요할 수 있습니다. 일관된 예비 자산 프레임워크에 필요한 후속 전송 알림은 다른 사람에게 알려지지 않은 체인에 존재하지 않습니다.

셋째, 수수료 지불과 같은 작업은 수수료 지불이 스마트 계약 메시지처럼 협상되었다고 가정하는 모델에 쉽게 맞지 않습니다. 반대로 트랜잭션 엔벨로프는 지불 처리를 위한 일부 시스템을 제공하지만 일반적으로 합의 시스템 간에 통신할 때 의미가 없는 서명을 포함하도록 설계됩니다.

mdnice 편집기

🎬 일부 초기 사용 사례

XCM은 일반적이고 유연하며 미래에 대비하는 것을 목표로 하지만 물론 특히 체인 간 토큰 전송에 대한 실질적인 요구 사항을 충족해야 합니다. 선택적 수수료 지불(아마도 이러한 토큰 사용)은 교환 서비스를 위한 공통 인터페이스와 같은 또 다른 방법으로 DeFi 세계 전체에서 일반적입니다. 마지막으로 XCM 언어를 사용하여 일부 플랫폼별 작업을 수행할 수 있어야 합니다. 예를 들어, 기판 체인에서 특수 기능에 액세스하려면 해당 모듈 중 하나에 원격 호출을 발송해야 할 수 있습니다.

그 외에도 우리가 지원하고자 하는 많은 토큰 전송 모델이 있습니다. 단순히 원격 체인의 계정을 제어하고, 로컬 체인이 원격 체인의 주소를 갖도록 허용하여 자금을 받고 결국 자금을 전송하기를 원할 수 있습니다. 원격 체인의 다른 계정에 대한 제어.

특정 토큰에 대한 "네이티브 홈"인 두 가지 합의 시스템이 있을 수 있습니다. 여러 다른 체인에 인스턴스가 있고 완전히 상호 교환 가능한 USDT 또는 USDC와 같은 토큰을 상상해 보십시오. 한 체인에서 이러한 토큰을 소각하고 지원되는 다른 체인에서 해당 토큰을 주조하는 것이 가능해야 합니다. XCM 용어로 우리는 이를 텔레포트라고 부릅니다. 왜냐하면 자산의 이전은 실제로 한쪽에서 자산을 파괴하고 다른 쪽에서 클론을 생성함으로써 이루어지기 때문입니다.

마지막으로 세 번째 체인을 지정하려는 두 개의 체인이 있을 수 있으며 해당 체인 중 하나의 자산은 해당 자산의 예비로 사용되는 기본 자산으로 간주될 수 있습니다. 각 온체인 자산의 파생 형태가 완전히 지원되어 파생 자산을 이를 뒷받침하는 예비 체인의 기본 자산으로 교환할 수 있습니다. 이것은 두 체인이 반드시 서로를 신뢰하지는 않지만 (적어도 문제의 자산에 관한 한) 자산의 로컬 체인을 기꺼이 신뢰하는 경우일 수 있습니다. 예를 들어 서로 간에 DOT를 전송하려는 여러 커뮤니티 파라체인이 있습니다. 그들 각각은 Statemint 체인(DOT의 로컬 허브)에서 파라체인 제어 DOT에 의해 완전히 지원되는 네이티브 형식의 DOT를 가지고 있습니다. 기본 형태의 DOT가 체인 간에 전송되는 동안 "실제" DOT는 Statemint의 파라체인 계정 간에 이동합니다.

겉으로 보기에 평범해 보이는 이 기능 수준에도 상대적으로 많은 수의 구성이 있으며 사용이 바람직할 수 있으며 과적합을 방지하려면 몇 가지 흥미로운 디자인이 필요합니다.

XCM 분석

XCM 형식의 핵심에는 XCVM이 있습니다. 일부 사람들이 믿는 것과는 달리, 이것은 (유효한) 로마 숫자가 아닙니다(그렇다면 905를 의미할 수도 있음). 사실 이것은 Cross Consensus Virtual Machine의 약자입니다. 트랜잭션과 거의 동일한 수준으로 설계된 지침이 있는 매우 높은 수준의 튜링 완전하지 않은 컴퓨터입니다.

XCM의 "메시지"는 실제로 XCVM에서 실행되는 프로그램일 뿐입니다. 하나 이상의 XCM 지시어입니다. 프로그램은 끝까지 실행되거나 오류가 발생할 때까지 실행되며, 그 시점에서 종료되고(지금 당장은 설명하지 않겠습니다) 중지됩니다.

enum Instruction {
   TransferAsset {
       assets: MultiAssets,
       beneficiary: MultiLocation,
   }
   /* snip */
}

XCVM에는 여러 레지스터와 이를 호스팅하는 합의 시스템의 전체 상태에 대한 액세스가 포함됩니다. 명령은 레지스터를 변경하거나 합의 시스템의 상태를 변경하거나 둘 다 변경할 수 있습니다.

짐작할 수 있듯이 자산은 양도할 자산을 나타내는 매개 변수이며 수혜자는 해당 자산을 누구/어디에 제공할지 지정합니다. 물론 우리는 자산을 누구에게서/어디서 얻을 수 있는지에 대한 또 다른 정보를 놓치고 있습니다. 이것은 원래 레지스터에서 자동으로 추론됩니다. 프로그램 초기에 이 레지스터는 일반적으로 전송 시스템(네트워크, XCMP 등)에 따라 메시지가 실제로 오는 곳을 반영하도록 설정되며, 수신자는 동일한 유형의 정보입니다. 오리진 레지스터는 보호된 레지스터로 작동합니다. 어떤 식으로든 변경하는 데 사용할 수 있는 두 가지 명령이 있지만 프로그램이 임의로 설정할 수는 없습니다.

사용되는 유형은 XCM의 매우 기본적인 아이디어입니다. MultiAsset으로 표시되는 자산, MultiLocation으로 표시되는 합의 내의 위치입니다. Origin Register는 선택적 MultiLocation입니다(필요한 경우 완전히 지울 수 있으므로 선택 사항).

mdnice 편집기

📍 XCM 위치에서

MultiLocation 유형은 합의 세계에 존재하는 모든 단일 위치를 식별합니다. 이것은 확장 가능한 다중 샤드 블록체인(예: Polkadot)에서 합의에 존재하는 파라체인의 하위 수준 ERC-20 자산 계정에 이르기까지 모든 것을 나타낼 수 있는 상당히 추상적인 아이디어입니다. 컴퓨터 과학 용어로는 크기나 복잡성에 관계없이 실제로 전역 단일 데이터 구조에 불과합니다.

MultiLocation은 항상 현재 위치에 상대적인 위치를 나타냅니다. 파일 시스템 경로처럼 생각할 수 있지만 파일 시스템 트리의 "루트"를 직접 표현할 방법이 없습니다. 이에 대한 간단한 이유가 있습니다. Polkadot의 세계에서 블록체인은 다른 블록체인에 병합되거나 다른 블록체인에서 분기될 수 있습니다. 블록체인은 매우 독립적으로 생명을 시작할 수 있으며 결국 더 큰 합의에서 파라체인으로 승격될 수 있습니다. 그렇게 하면 "루트"의 의미가 하룻밤 사이에 변경되어 XCM 메시지와 MultiLocation을 사용하는 모든 항목이 혼란스러울 수 있습니다. 단순화를 위해 이 가능성을 완전히 배제했습니다.

XCM의 위치는 계층적이며 합의의 일부 위치는 합의의 다른 곳에서 완전히 캡슐화됩니다. Polkadot의 파라체인은 우리가 내부 위치라고 부르는 전체 Polkadot 합의 내에 전적으로 존재합니다. 더 엄밀히 말하면, 한 합의 시스템의 변경이 다른 합의 시스템의 변경을 의미할 때마다 전자 시스템은 후자의 내부에 있다고 말할 수 있습니다. 예를 들어 Canvas 스마트 계약은 이를 호스팅하는 계약 모듈 내에 있습니다. 비트코인의 UTXO는 비트코인 ​​블록체인 내부에 있습니다.

이것은 XCM이 "who"와 "where" 질문을 구분하지 않는다는 것을 의미합니다. XCM과 같이 상당히 추상적인 것의 관점에서 보면 구별은 중요하지 않습니다. 두 가지가 흐려지고 본질적으로 같은 것이 됩니다.

MultiLocations는 XCM 메시지가 전송되는 위치, 자산을 수신할 수 있는 위치를 식별하는 데 사용되며 자산 유형 자체를 설명하는 데 도움이 됩니다. 매우 유용한 것들.

• 이와 같은 텍스트로 작성하면 일부 ..(또는 합의 시스템을 캡슐화하는 "부모") 구성 요소로 표시되고 그 뒤에 일부 조인 포인트가 있으며 모두 / 로 구분됩니다. (이것은 Rust와 같은 언어로 표현할 때는 일반적으로 발생하지 않지만 널리 사용되는 친숙한 디렉토리 경로와 유사하기 때문에 문서상으로는 의미가 있습니다.) 캡슐화된 합의의 연결 내부 위치 시스템을 식별합니다. 상위 노드/접합점이 전혀 없으면 위치가 여기에 있다고 합니다.

• 예를 들어:

• ../Parachain(1000): 파라체인에서 평가합니다. 이는 인덱스 1000으로 형제 파라체인을 식별합니다. (Rust에서는 ParentThen(Parachain(1000)).into())

Parachain(42)/AccountKey20(0x1234...abcd): 릴레이 체인에서 평가되며, 이는 parachain 번호 42에서 20바이트 계정 0x1234...abcd를 식별합니다(아마도 Moonbeam 호스팅 Ethereum 호환 계정과 유사).

키, 인덱스, 이진 BLOB 및 복수형 설명과 같은 다양한 방식으로 체인에서 찾을 수 있는 위치를 식별하는 데 사용되는 다양한 유형의 조인 포인트가 있습니다.

mdnice 편집기

💰 XCM의 자산

XCM에서 작업할 때 종종 일종의 자산을 참조해야 합니다. 이는 거의 모든 기존 퍼블릭 블록체인이 내부 경제 및 보안 메커니즘의 중추를 제공하기 위해 일부 기본 디지털 자산에 의존하기 때문입니다. 비트코인과 같은 작업 증명 블록체인의 경우 네이티브 자산(BTC)은 블록체인을 개발하고 이중 지출을 방지하는 채굴자에게 보상하는 데 사용됩니다. Polkadot과 같은 지분 증명 블록체인의 경우 네이티브 자산(DOT)은 네트워크 관리자(스테이커라고 함)가 유효한 블록을 생성하고 물리적 보상을 받기 위해 부담해야 하는 일종의 담보로 사용됩니다.

struct MultiAsset {
  id: AssetId,
  fun: Fungibility,
}

일부 블록체인은 여러 자산을 관리합니다. 예를 들어 Ethereum의 ERC-20 프레임워크를 사용하면 다양한 자산을 온체인에서 관리할 수 있습니다. Ethereum의 ETH와 같이 대체 불가능 자산을 관리하는 일부 자산은 대체 불가능 — 고유 인스턴스입니다. 크립토키티는 이러한 대체 불가능 토큰 또는 NFT의 초기 예입니다.

plain
enum AssetId {
   Concrete(MultiLocation),
   Abstract(BinaryBlob),
}

XCM은 이러한 모든 자산을 손쉽게 처리하도록 설계되었습니다. 이를 위해 데이터 유형 MultiAsset과 관련 유형 MultiAssets, WildMultiAsset 및 MultiAssetFilter가 있습니다. Rust의 MultiAsset을 살펴보겠습니다.

enum Fungibility {
  Fungible(NonZeroAmount),
  NonFungible(AssetInstance),
}

따라서 자산을 정의하는 두 개의 필드가 있습니다. id와 fun은 XCM이 자산을 처리하는 방법을 잘 보여줍니다. 먼저 전체 자산 ID를 제공해야 합니다. 대체 가능 자산의 경우 이는 단순히 자산을 식별합니다. NFT의 경우 자산의 전체 "클래스"를 식별합니다. 이 클래스 내에 다른 자산 인스턴스가 있을 수 있습니다.

자산 ID는 구체적 또는 추상적인 두 가지 방법 중 하나로 표현됩니다. Abstract는 실제로 사용되지 않지만 자산 ID를 이름으로 지정할 수 있습니다. 이것은 편리하지만 발신자가 기대하는 방식으로 이름을 해석하기 위해 수신자가 의존하므로 항상 쉽지는 않을 수 있습니다. 콘크리트는 일반적으로 위치를 사용하고 사용하여 자산을 명확하게 식별합니다. 기본 자산(예: DOT)의 경우 자산은 종종 자산을 발행한 체인으로 식별됩니다(이 경우 Parachain이 있는 Polkadot 릴레이 체인 .. ). 체인 모듈 내에서 주로 관리되는 자산은 해당 모듈 내에서 인덱싱된 위치를 포함하여 식별할 수 있습니다. 예를 들어 Karura 파라체인은 ../Parachain(1000)/PalletInstance(50)/GeneralIndex(42) 에서 Statemine 파라체인의 자산을 참조할 수 있습니다.

둘째, 대체 가능하거나 대체 불가능해야 합니다. 대체 가능한 경우 0이 아닌 관련 수량이 있어야 합니다. 교체할 수 없는 경우 수량보다는 어떤 인스턴스인지에 대한 표시가 있어야 합니다. (이는 일반적으로 인덱스로 표시되지만 XCM은 배열 및 이진 블롭과 같은 다양한 다른 데이터 유형도 허용합니다.) 여기에는 MultiAsset이 포함되지만 때때로 세 가지 다른 관련 유형을 사용합니다. MultiAssets는 그 중 하나이며 실제로 MultiAsset 항목 집합을 의미합니다. 그런 다음 하나 이상의 MultiAsset 항목을 일치시키는 데 사용할 수 있는 와일드카드인 WildMultiAsset이 있습니다. 실제로 두 개의 와일드카드만 지원합니다. All(모든 자산과 일치) 및 AllOf는 특정 ID(AssetId) 및 대체 가능성이 있는 모든 자산과 일치합니다. 특히 후자의 경우 수량(대체 가능한 경우) 또는 인스턴스(비대체 가능한 경우)를 지정할 필요가 없으며 모두 일치합니다.

👉 Holding Register

마지막으로 MultiAssetFilter가 있습니다. 이것은 가장 일반적으로 사용되며 실제로는 MultiAsset과 WildMultiAsset의 조합으로, 와일드카드 또는 자산의 명시적(즉, 와일드카드가 아닌) 목록을 지정할 수 있습니다.

WithdrawAsset(MultiAssets),

Rust XCM API에서는 이러한 데이터 유형을 가능한 한 쉽게 작업할 수 있도록 다양한 변환을 제공합니다. 예를 들어 Polkadot 릴레이 체인에 있을 때 분할 불가능한 DOT 자산 단위 100개와 동일한 대체 가능한 MultiAsset(아는 사람들을 위한 Planck)을 지정하려면 (Here, 100).into()를 사용합니다.

다른 XCM 명령인 WithdrawAsset을 살펴보겠습니다. 표면적으로 이것은 TransferAsset의 전반부와 약간 비슷합니다. 원래 계정에서 일부 자산을 인출합니다. 하지만 그게 그들에게 무슨 상관이 있겠습니까? 어디에도 입금하지 않으면 꽤 쓸모없는 작업임에 틀림 없습니다. Rust 선언을 보면 사용법에 대한 더 많은 단서를 찾을 수 있습니다.

enum Instruction {
   DepositAsset {
       assets: MultiAssetFilter,
       max_assets: u32,
       beneficiary: MultiLocation,
   },
   /* snip */
}

따라서 이번에는 하나의 매개변수(Origin Register의 소유권에서 인출해야 하는 자산을 지정하는 MultiAssets 유형)만 있습니다. 그러나 자산을 어디에 둘지 지정하지 않습니다.

이렇게 일시적으로 보관된 미사용 자산을 보관 레지스터라고 합니다. ("Holding"은 무기한 지속되지 않는 임시 위치에 있기 때문에 "Register"는 작업 데이터를 저장하는 장소인 CPU 레지스터와 비슷하기 때문에 "Register"입니다.) 홀딩 레지스터에서 작동하는 명령이 많이 있습니다. 매우 간단한 지시어는 DepositAsset 지시어입니다. 한번 살펴봅시다:

아하! 기민한 독자라면 이것이 TransferAsset 지시문의 누락된 절반과 매우 유사하다는 것을 알아차릴 것입니다. 우리는 자산 매개변수를 가지고 있는데, 이는 온체인에 예치하기 위해 보유 레지스터에서 제거해야 하는 자산을 지정합니다. max_assets를 사용하면 XCM 작성자가 수신자에게 예치할 고유 자산 수를 알릴 수 있습니다. (자산을 예치하는 것은 비용이 많이 드는 작업일 수 있기 때문에 Holding Register의 내용을 알기 전에 수수료를 계산할 때 유용합니다.) 마지막으로 TransferAsset 작업에서 이전에 만난 것과 동일한 매개 변수인 수혜자가 있습니다. Holding Register에서 수행할 작업을 나타내는 많은 지시문이 있으며 DepositAsset은 가장 간단한 것 중 하나입니다. 다른 것들은 더 복잡합니다.

🤑 XCM에서 수수료 지불

XCM에서 수수료 지불은 상당히 중요한 사용 사례입니다. Polkadot 커뮤니티의 대부분의 파라체인은 "트랜잭션 스팸" 및 서비스 거부 공격에 대한 문을 열지 않도록 대담자가 원하는 작업에 대한 비용을 지불하도록 요구합니다. 예외는 체인이 대담자가 잘 행동할 것이라고 믿을만한 충분한 이유가 있는 경우에도 존재합니다. 이는 Polkadot 릴레이 체인이 Polkadot Statemint 공익 체인과 통신하는 경우입니다. 그러나 일반적인 경우 수수료는 XCM 메시지와 해당 전송 프로토콜이 과도하게 사용되지 않도록 하는 좋은 방법입니다. XCM 메시지가 Polkadot에 도달하면 요금이 어떻게 지불되는지 살펴보겠습니다.

• 앞서 언급했듯이 XCM은 일급 시민으로서 수수료 및 수수료 지불을 포함하지 않습니다. 이더리움 거래 모델과 달리 수수료 지불이 프로토콜에서 요구되지 않는 것이 되려면 이를 우회해야 합니다. Rust의 제로 비용 추상화와 마찬가지로 수수료 지불은 XCM에서 중요한 설계 오버헤드가 없습니다.

• 결제가 필요한 시스템의 경우 XCM은 자산을 사용하여 실행 리소스를 구매할 수 있는 기능을 제공합니다. 대체로 여기에는 세 부분이 포함됩니다.

• 먼저 일부 자산을 제공해야 합니다.

둘째, 자산은 계산 시간(기판 용어의 가중치)과 교환되어야 합니다.

마지막으로 XCM 작업이 지시에 따라 실행됩니다.

WithdrawAsset((Here, 10_000_000_000).into()),

첫 번째 부분은 자산을 제공하는 여러 XCM 지시문 중 하나에 의해 관리됩니다. 우리는 이미 이러한 지시어 중 하나( WithdrawAsset )를 알고 있지만 나중에 볼 몇 가지 다른 지시어가 있습니다. 물론 Holding Register의 결과 자산은 XCM 실행과 관련된 비용을 지불하는 데 사용됩니다. 수수료를 지불하는 데 사용되지 않은 모든 자산은 대상 계정에 예치됩니다. 이 예에서는 XCM이 Polkadot 릴레이 체인에서 발생하고 1 DOT가 거래된다고 가정합니다(즉, 10,000,000,000 분할 불가 단위).

enum Instruction {
   /* snip */
   BuyExecution {
       fees: MultiAsset,
       weight: u64,
   },
}

현재 XCM 지시어는 다음과 같습니다.

이것은 XCM에서 우리에게 지불하기 위해 계산 시간에 대한 대가로 이러한 자산(일부)을 교환하는 두 번째 부분으로 이어집니다. 이를 위해 XCM 명령어 BuyExecution 이 있습니다. 어떻게 생겼는지 봅시다:

첫 번째 항목 수수료는 Holding Register에서 인출하여 수수료를 지불하는 데 사용해야 하는 금액입니다. 미사용 잔액은 즉시 환불되므로 엄밀히 말하면 이는 최대치일 뿐입니다.

WithdrawAsset((Here, 10_000_000_000).into()),
BuyExecution {
   fees: (Here, 10_000_000_000).into(),
   weight: 3_000_000,
},

지출되는 최종 금액은 해석 시스템에 달려 있습니다. 수수료는 한도에 불과하며, 해석 시스템이 원하는 실행에 대해 더 많은 비용을 지불해야 하는 경우 BuyExecution 명령으로 오류가 발생합니다. 두 번째 항목은 구매 실행 시간을 지정합니다. 이것은 일반적으로 XCM 프로그램의 총 가중치보다 작아서는 안 됩니다.

이 예제에서는 모든 XCM 명령에 대해 가중치를 100만이라고 가정하고 있으므로 지금까지 200만 개의 프로젝트(WithdrawAsset 및 BuyExecution)가 2개 있고 앞으로 하나 더 추가될 예정입니다. 우리는 해당 수수료를 지불하기 위해 필요한 모든 DOT를 사용할 것입니다(이는 대상 체인이 미친 수수료가 없다고 신뢰하는 경우에만 의미가 있습니다-그렇다고 가정). 이제 XCM을 살펴보겠습니다.

WithdrawAsset((Here, 10_000_000_000).into()),
BuyExecution {
   fees: (Here, 10_000_000_000).into(),
   weight: 3_000_000,
},
DepositAsset {
   assets: All.into(),
   max_assets: 1,
   beneficiary: Parachain(1000).into(),
},XCM의 세 번째 부분은 나머지 자금을 보유 등록부에 예치하는 것입니다. 이를 위해 DepositAsset 지시어를 사용합니다. Holding Register에 얼마가 남아 있는지 실제로 알 수는 없지만 예치해야 하는 자산에 대한 와일드카드를 지정할 수 있으므로 문제가 되지 않습니다. 우리는 그것들을 Statemint(Parachain(1000)로 식별됨)의 주권 계정에 넣습니다.

따라서 최종 XCM 지시어는 다음과 같습니다.

자산을 다른 체인으로 보내는 것은 아마도 인터체인 메시징의 가장 일반적인 사용 사례일 것입니다. 하나의 체인이 다른 체인 고유의 자산을 관리하도록 허용하면 다양한 파생 사용 사례(말장난이 아님)가 허용되며, 가장 단순한 것은 분산형 교환이지만 종종 분산형 금융 또는 De-Fi로 묶입니다.

일반적으로 체인이 서로의 보안 및 논리를 신뢰하는지 여부에 따라 자산이 체인 간에 이동하는 두 가지 방법이 있습니다.

mdnice 편집기

✨ 텔레포트

WithdrawAsset((Here, 10_000_000_000).into()),
InitiateTeleport {
   assets: All.into(),
   dest: Parachain(1000).into(),
   xcm: Xcm(vec![
       BuyExecution {
           fees: (Parent, 10_000_000_000).into(),
           weight: 3_000_000,
       },
       DepositAsset {
           assets: All.into(),
           max_assets: 1,
           beneficiary: Parent.into(),
       },
   ]),
}

서로를 신뢰하는 체인(예: 동일한 전체 합의 및 보안 우산 아래의 동종 샤드)의 경우 기본적으로 보내는 쪽에서 자산을 파괴하고 받는 쪽에서 자산을 발행하는 것을 의미하는 순간 이동이라는 Polkadot의 프레임워크를 사용할 수 있습니다. 이 방어 방법은 간단하면서도 효율적입니다. 두 체인의 조정만 필요하고 양쪽에서 한 가지 조치만 필요합니다. 불행하게도, 받는 체인이 보내는 체인이 자신이 발행하는 자산을 실제로 파괴한다는 것을 100% 신뢰할 수 없다면(실제로 자산의 합의된 규칙을 벗어나 자산을 발행하지 않는 경우), 보내는 체인은 실제로 자산을 발행할 이유가 없습니다. 메시지.

XCM이 Polkadot 릴레이 체인에서 Statemint의 주권 계정으로 (대부분) 1 DOT를 전송하는 것이 어떤 모습인지 살펴보겠습니다. Polkadot이 이미 수수료를 지불했다고 가정합니다.

보시다시피 이것은 지난번에 본 직접 인출-매수-입금 모델과 매우 유사해 보입니다. 차이점은 마지막 두 지시어(BuyExecution 및 DepositAsset) 주위에 삽입되는 InitiateTeleport 지시어입니다. 배후에서 전송 체인(Polkadot 릴레이 체인)은 InitiateTeleport 명령을 실행할 때 완전히 새로운 메시지를 생성하고 있습니다. Statemint는 Polkadot 릴레이 체인이 메시지를 보내기 전에 측면에서 1 DOT를 파괴했다고 믿습니다. (그리고 그건!)

ReceiveTeleportedAsset((Parent, 10_000_000_000).into()),
BuyExecution {
   fees: (Parent, 10_000_000_000).into(),
   weight: 3_000_000,
},
DepositAsset {
   assets: All.into(),
   max_assets: 1,
   beneficiary: Parent.into(),
},

수혜자는 Parent.into() 로 선언되며, 기민한 독자라면 이것이 Polkadot 릴레이 체인의 맥락에서 무엇을 의미하는지 궁금할 것입니다. 대답은 "아무것도 아니다"이지만 여기에는 잘못된 것이 없습니다. xcm 매개변수의 모든 것은 수신자의 관점에서 작성되므로 이것은 Polkadot 릴레이 체인에 공급되는 전체 XCM의 일부이지만 실제로는 Statemint에서만 실행되므로 해당 컨텍스트 다음에 Statemint가 사라집니다.

아시다시피 이것은 이전 WithdrawAsset XCM과 매우 유사해 보입니다. 유일한 주요 차이점은 로컬 계정에서 인출하여 수수료 및 보증금을 조달하는 대신 DOT가 실제로 보낸 사람(Polkadot 릴레이 체인)에서 소각된다는 것을 신뢰하여 ReceiveTeleportedAsset 메시지를 존중한다는 것입니다. 우리가 Polkadot 릴레이 체인에 보낸 1 DOT의 자산 식별자(여기서 릴레이 체인 자체는 DOT의 기본 환경임)가 Statemint: Parent.into(), Statemint 컨텍스트에서 릴레이 체인의 위치.

수혜자는 또한 Polkadot 릴레이 체인으로 지정되므로 주권 계정(Statemint에서)은 새로 발행된 1 DOT에서 수수료를 뺀 금액으로 적립됩니다. XCM은 수혜자 또는 다른 것에 대한 계정을 쉽게 지정할 수 있습니다. 실제로 이 1 DOT는 릴레이 체인에서 보낸 후속 TransferAsset을 사용하여 이동할 수 있습니다.

mdnice 편집기

🏦 준비금

체인 간에 자산을 전송하는 또 다른 방법은 약간 더 복잡합니다. 예약이라고 하는 제3자가 사용됩니다. 이 이름은 특정 공표된 가치 약속에 대한 신뢰성을 부여하기 위해 자산을 "예약"하는 은행의 준비금 시스템에서 유래했습니다. 예를 들어, 독립적인 파라체인에서 발행된 각각의 "파생" DOT가 정확히 1개의 "진정한" DOT(예: 릴레이 체인의 Statemint 또는 DOT)로 교환될 수 있다고 믿을 만한 이유가 있는 경우, 우리는 파라체인 DOT를 다음과 같이 만들 수 있습니다. 실제 DOT와 경제적으로 동등한 것으로 간주됩니다. (대부분의 은행은 부분 준비금 은행 업무를 수행합니다. 즉, 준비금을 액면가보다 적게 보관합니다. 이것은 일반적으로 괜찮지만 너무 많은 사람들이 상환하려고 할 때 금방 잘못될 수 있습니다.) 따라서 준비금은 "진짜"를 저장하는 장소입니다. 발신자와 수신자 모두가 논리와 보안을 신뢰하는 전송 목적의 자산. 발신자와 수신자의 모든 해당 자산은 파생 상품이지만 "실제" 예비 자산으로 100% 뒷받침됩니다. 파라체인이 잘 작동한다고 가정하면(즉, 버그가 없고 거버넌스가 예비금을 훔쳐 달아나기로 결정하지 않은 경우) 파생 DOT가 기본 예비 DOT와 거의 동일한 값이 됩니다. 예비 자산은 예비 체인의 발신자/수신자 주권 계정(즉, 발신자 또는 수신자 체인이 제어하는 ​​계정)에 보관되므로 파라체인에 문제가 없는 한 이러한 자산이 잘 보호될 것이라고 믿을만한 충분한 이유가 있습니다. 의.

WithdrawAsset((Parent, 10_000_000_000).into()),
InitiateReserveWithdraw {
   assets: All.into(),
   dest: ParentThen(Parachain(1000)).into(),
   xcm: Xcm(vec![
       BuyExecution {
           fees: (Parent, 10_000_000_000).into(),
           weight: 3_000_000,
       },
       DepositReserveAsset {
           assets: All.into(),
           max_assets: 1,
           dest: ParentThen(Parachain(2001)).into(),
           xcm: Xcm(vec![
               BuyExecution {
                   fees: (Parent, 10_000_000_000).into(),
                   weight: 3_000_000,
               },
               DepositAsset {
                   assets: All.into(),
                   max_assets: 1,
                   beneficiary: ParentThen(Parachain(2000)).into(),
               },
           ]),
       },
   ]),
},

송금 메커니즘으로 돌아가서, 송금인은 송금인이 소유한 자산을 수령인의 소버린 계좌로 송금하고(동일한 자산의 자체 버전을 위한 준비금으로 사용) 준비금에 지시할 것입니다. 보낸 사람!) 수신자에게 새 자산을 알립니다. 이는 발신자와 수신자가 서로의 논리나 보안을 신뢰할 필요가 없고 예비로 사용되는 체인의 논리나 보안만 신뢰할 필요가 있음을 의미합니다. 그러나 세 당사자가 조정해야 하므로 전체 비용, 시간 및 복잡성이 추가됩니다.

WithdrawAsset((Parent, 10_000_000_000).into()),
InitiateReserveWithdraw {
   assets: All.into(),
   dest: ParentThen(Parachain(1000)).into(),
   xcm: /* snip */
}

필요한 XCM을 살펴보겠습니다. 이번에는 파라체인 2000에서 파라체인 2001로 1 DOT를 보낼 것입니다. 파라체인 1000에서 예비 지원 DOT를 사용합니다. 다시 말하지만, 우리는 수수료가 발신인에게 이미 지불되었다고 가정합니다.

/*snip*/
   xcm: Xcm(vec![
       BuyExecution {
           fees: (Parent, 10_000_000_000).into(),
           weight: 3_000_000,
       },
       DepositReserveAsset {
           assets: All.into(),
           max_assets: 1,
           dest: ParentThen(Parachain(2001)).into(),
           xcm: /* snip */
       },
   ]),
/*snip*/

앞서 말했듯이 조금 복잡할 것입니다. 프로세스를 살펴보겠습니다. 외부 부분은 보낸 사람(파라체인 2000)에서 1 DOT를 인출하고 Statemint(파라체인 1000)에서 해당 1 DOT를 인출하는 일을 담당합니다. 이를 위해 InitiateReserveWithdraw를 사용합니다.

/*snip*/
   xcm: Xcm(vec![
       BuyExecution {
           fees: (Parent, 10_000_000_000).into(),
           weight: 3_000_000,
       },
       DepositAsset {
           assets: All.into(),
           max_assets: 1,
           beneficiary: ParentThen(Parachain(2000)).into(),
       },
   ]),
/*snip*/

이제 우리는 Statemint의 Holding Register에 1 DOT를 보유하고 있습니다. 다른 작업을 수행하기 전에 Statemint에서 실행 시간을 구입해야 합니다. 프로세스도 친숙해 보입니다.

ReserveAssetDeposited((Parent, 10_000_000_000).into()),
BuyExecution {
   fees: (Parent, 10_000_000_000).into(),
   weight: 3_000_000,
},
DepositAsset {
   assets: All.into(),
   max_assets: 1,
   beneficiary: ParentThen(Parachain(2000)).into(),
},

우리는 수수료를 지불하기 위해 자체적으로 1 DOT를 사용하며 XCM 작업당 100만 개를 가정합니다. 이 하나의 작업에 대한 비용을 지불한 후 Parachain 2001의 주권 계정에 1 DOT(수수료를 빼고 게을러서 그냥 All.into()를 사용함)를 예치하는데 이것은 예비 자산으로 수행됩니다. 우리는 또한 Statemint에게 이 수신 체인에 알림 XCM을 보내도록 요청하여 전송 및 결과 파생 자산에서 실행될 몇 가지 지침을 알려줍니다. DepositReserveAsset 지시문이 항상 작동하는 것은 아닙니다. 작동하려면 dest가 예비 체인에서 자금을 합리적으로 보유할 수 있고 예비 체인이 XCM을 보낼 수 있는 위치여야 합니다. Brother parachains는 계산서에 정확히 맞습니다.

마지막 부분은 파라체인(2001)에 도착하는 메시지 부분을 정의합니다. 전송 작업을 시작하는 것과 마찬가지로 DepositReserveAsset은 새 메시지를 작성하고 보냅니다. 이 경우 ReserveAssetDeposited 입니다. 우리가 정의한 XCM 프로그램을 포함하고 있지만 수신 파라체인에 도달하는 것은 이 메시지입니다. 다음과 같습니다.

(이는 Statemint가 실제로 수수료를 받지 않았고 전체 1 DOT가 통과되었다고 가정합니다. 이것은 특별히 현실적이지 않으므로 자산 라인의 숫자가 더 낮을 수 있습니다.) 이 메시지의 대부분은 친숙해 보일 것입니다. 이전 섹션에서 본 ReceiveTeleportedAsset 메시지와 눈에 띄는 차이점은 최상위 지시문 ReserveAssetDeposited 입니다. 이것은 "전송 체인이 자산을 파괴하므로 동등한 자산을 발행할 수 있습니다"라는 점을 제외하고는 유사한 목적을 달성합니다. "전송 체인이 자산을 수신하고 귀하를 위해 보관하므로 전체 자산으로 뒷받침되는 파생 상품을 만들 수 있습니다." 어느 쪽이든 대상 체인은 이를 보유 준비금으로 발행하고 수신 체인의 발신자의 소버린 계정에 예치합니다. 🎉

“

🏁 결론