폴카닷 내려다보기

서울대학교 블록체인 학회 디사이퍼 (Decipher) 에서 작성한, 폴카닷 (Polkadot) 에 대한 소개글입니다. 폴카닷의 아키텍처, 합의 알고리즘, 브릿지 프로토콜과 XCM에 대해 다루고 있습니다.

1. Introduction

2016년 개빈 우드 (Gavin Wood)에 의해 처음으로 제안된 폴카닷의 백서 (Whitepaper)에서는 블록체인이 현실 세계에 적용되기 어려운 이유로 크게 5가지: Scalability, Isolatability, Developability, Governance, Applicability 를 언급하고 있다. 폴카닷은 이 중 처음 2개의 문제인 Scalability (일정 시간동안 얼마나 많은 트랜잭션이 처리될 수 있는지) 와 Isolatability (서로 다른 목적의 어플리케이션들이 같은 프레임워크 하에서 공존할 수 있는지) 의 해결에 집중한다. 쉬운 말로 표현하자면 더 빠르게 트랜잭션을 처리하고, 다양한 목적의 어플리케이션들이 하나의 시스템 안에 공존할 수 있게끔 하는 것이 주된 방향이라는 것이다. 백서에서는 이러한 방향을 언급하며, 폴카닷이 “Scalabe heterogeneous multi-chain” 을 목표로 하는 프로젝트라고 소개하고 있다.

확장성이 뛰어나고 다양한 체인을 하나로 연결하기 위해 폴카닷은 파라체인 (parachain)과 릴레이 체인 (relay chain) 의 구조를 택하고 있다. 하나의 릴레이 체인 폴카닷 내에 다양한 목적의 서로 다른 파라체인들이 존재하는데, 각 파라체인에서 병렬적으로 처리한 트랜잭션들을 폴카닷의 메인 체인인 릴레이 체인에서 처리하고 트랜잭션들에 대해 완결성 (finality)을 보장한다. 이러한 아이디어를 달성하고 구현하는 데 있어, 백서에서 제시된, 폴카닷이 추구하는 기본적인 원칙은 다음 4가지다.

1. Minimal : 가장 최소한의 기능을 가져야 함
2. Simple : base protocol 은 복잡성을 최소로 하고 단순해야 한다
3. General : 파라체인에 불필요한 요구조건이나 제약조건이 없어야 한다
4. Robust : 안정적이고 탈중앙화된 base layer를 만든다

여기서 언급된 base layer와 base protocol은 릴레이 체인에 관련된 개념이고, 물론 제시된 4가지 원칙은 뚜렷하게 구분되는 개념이 아니다. 하지만 백서에서 위 4가지 사항을 보면 폴카닷이 다양한 parachain들의 트랜잭션을 중앙에서 처리하는 형태를 고안하는 데 있어, 복잡한 구조가 아닌 심플함을 추구하고 파라체인의 진입장벽을 낮추고 최대한 open 된 환경을 만들고자 하는 생각을 엿볼 수 있다.

2. Polkadot Architecture

Overall Architecture

앞서 언급했듯이, 폴카닷은 서로 다른 목적의 파라체인들이 각각 병렬적으로 트랜잭션을 처리하고 이를 폴카닷의 베이스 체인인 릴레이 체인으로 제출하여 릴레이 체인에서 트랜잭션들을 최종적으로 검증하고 완결성을 부여하는 형태이다. 구조를 조금 더 자세하게 이해하기 위해 폴카닷 네트워크를 구성하는 노드들과 그들의 역할을 중심으로 살펴보도록 하자.

Participants

폴카닷 네트워크의 참여자는 크게 Collator, Fisherman, Validator, Nominator 4가지로 분류할 수 있다.

출처 : Polkadot Specification paper — Overview of Polkadot and its Design Considerations

Collator

Collator는 파라체인의 데이터를 릴레이 체인으로 전송하는 역할을 한다. 파라체인의 풀노드 역할을 하고, 담당하는 파라체인의 모든 트랜잭션들을 실행해보고 블록을 직접 생성한다. Collator들이 생성한 블록을 Validator에게 넘기고 Validator가 블록을 받아 검증 과정을 수행한다.

Fisherman

Fisherman은 파라체인이 제대로 동작하는지에 대해 추가적인 안전성 (Security) 검사를 진행한다. 일반적인 블록 검증자보다는 악의적인 행동을 발견 할 때 큰 보상을 얻게 되는 “Bounty hunters”에 가깝다. 유효하지 않은 상태 변화가 블록에 포함되지 않는지를 끊임없이 감시하는 역할이다. 옵티미스틱 롤업에서 챌린지를 제시하는 사람과 비슷하다고 이해할 수 있다. Fisherman 노드를 운영하기 위해서는 파라체인의 풀노드여야 한다. 폴카닷 네트워크의 일부로 Overview paper에서 소개되고 있긴 하지만, Fisherman이 없어도 네트워크의 안전성이 훼손되는 것은 아니고 아직까지 인센티브 구조가 구체화되지 않았다. 현재 작성 시점(22.01)에서도 Fisherman에 대한 구현은 없는 상태이다.

Validator

Validator들은 릴레이 체인의 풀노드이고 파라체인의 Collator들과 소통하며 전체 네트워크 안전성을 보장하는 역할을 한다. (Validator들은 모든 파라체인 각각의 풀노드를 운영할 필요는 없다.) Validator는 일정금액을 예치 (deposit)하고, 릴레이 체인의 클라이언트 프로그램을 실행시킴으로써 검증에 형태로 참여할 수 있다. Validator 노드는 매 블록마다 특정 파라체인 블록을 검증 (validate)하는 역할을 수행한다. 담당하는 파라체인은 수시로 바뀌지만, 모든 파라체인의 블록을 다 가지고 있어야 한다는 뜻은 아니다. 모든 파라체인에 fully synchronized 되어있는 것은 리소스 비용이 크고, 파라체인이 많아질수록 지속 불가능해지기 때문이다. 파라체인의 새로운 블록 제안은 Collator가 담당한다. 특정 파라체인에 할당된 Validator 그룹이 그 파라체인의 새로운 블록들을 검증하고 승인하면, Validator들은 릴레이 체인의 블록을 새로 검증해야 한다. 어떤 파라체인의 출력 큐 (output queue)에서 다른 파라체인의 입력 큐 (input queue)로의 트랜잭션 큐 (transaction queue)를 업데이트 하는 것과 릴레이 체인의 트랜잭션들을 실행하는 것 등이 검증하는 내용에 포함한다. 제 역할을 하지 않는 Validator들은 그들이 미리 예치해둔 폴카닷에서 일정 부분 slash 당하는 메커니즘 또한 존재한다.

Nominator

Nominator들은 폴카닷 네트워크의 합의과정에 직접적으로 참여하지는 않지만 그들의 폴카닷을 스테이킹하여 전체 네트워크의 안전성을 높이는 역할을 한다. 조금 더 구체적으로 살펴보면, Nominator들은 직접 특정 Validator 후보들을 선택하여 그들에게 스테이킹된 폴카닷을 위임한다. Validator가 올바른 검증과정을 진행하여 보상을 얻게 되면 Nominator들은 위임한 금액에 비례해 수익을 얻을 수 있다. 반대로 Validator가 제 기능을 하지 못해 금액이 차감된다면 Nominator 또한 손해를 볼 수 있다. 따라서 Nominator들은 정직한 Validator들에게 그들의 자본을 위임하고자 하는 유인이 존재하고, 전체 네트워크에 모인 폴카닷의 양이 많아질수록 네트워크가 안전해지는 것이다. 현재 시점 Nominator들의 최소 예치액은 120 DOT으로 한화로 약 250만원 정도를 가지고 있으면 얼마든지 Nominator로 참여할 수 있다. 물론 Nominator들은 릴레이 체인의 라이트 클라이언트 (light client)로도 동작할 수 있다. 요약하자면 Nominator들은 폴카닷을 staking 하는 것 이외에는 직접적으로 주어진 역할은 딱히 없고, 그들이 지정한 validator들의 성과에 따라 보상을 받기도 하고 예치금액이 차감되기도 한다.

출처 : https://polkadot.js.org/apps/#/chainstate

위 그림의 예시에서는 6개의 파라체인과 하나의 릴레이 체인이 나타나 있다. 그림 상에서 보면 각 파라체인에는 5명의 Collator과 3명의 Validator들이 있고, 다른 블록체인과도 브릿지를 통해 연결되어 있을 수 있다. 여기서 그림만 보고 오해하지 말아야 할 것은 Collator들은 각 파라체인에 독립적으로 존재하는 것이기 때문에 Collator의 수가 위 그림처럼 일정할 필요는 없다는 것이다. Validator도 파라체인마다 꼭 같은 수만큼 존재하는 것이 아니며, 일정 시간 간격마다 다른 Validator들이 각각 다른 파라체인의 검증에 할당되는 형태이다.

3. Polkadot Consensus

3.1 NPoS

폴카닷은 릴레이 체인의 합의 메커니즘으로 지명지분증명 방식 (NPoS : Nominated Proof-of-Stake)을 사용하고 있다. 2-Architecture의 Nominator 부분에서 언급했듯이, 폴카닷은 다른 지분증명 체인들과는 다르게 Nominator와 Validator가 따로 존재한다. Nominator들이 그들이 신뢰하는 최대 16명의 Validator 후보들을 선택하면, 네트워크가 자동적으로 그들이 예치한 DOT을 그들이 지정한 Validator들에게 분배한다. Validator가 올바른 검증과정을 진행하여 보상을 얻게 되면 Nominator들은 위임한 금액에 비례해 수익을 얻고, 반대로 올바르지 않은 행동을 할 경우 금액에 비례해 손해를 입을 수 있다. 일반적으로 NPoS는 위임지분증명 방식 (DPoS : Delegated Proof-of-Stake) 방식과 유사하다고 여겨지는데, DPoS와의 가장 큰 차이점은 DPoS에서는 위임받은 Validator들이 악의적인 행동을 해도 위임자들은 그들이 예치한 금액을 잃지 않는다는 점이다. 또한 16명의 후보들에게 특정 규칙에 의해 예치액을 분배하는 NPoS와는 다르게, DPoS에서는 위임자가 어떤 Validator들에게 위임할 것인지 구체적인 액수를 정할 수 있다.

NPoS 스킴을 통해, 특정 Validator 한 명이 가지고 있는 DOT 양보다 훨씬 많은 양의 지분을 가지고 Nominator들이 Validator들을 선택할 수 있기 때문에, NPoS는 Validator 선출 과정을 금권 지배 (plutocracy) 보다 능력주의 (meritocracy) 에 가깝게 만드는 작용을 한다.

기본적인 NPoS 스킴과 함께, 블록을 누가 생성할 것이고 블록이 어떻게 완결성이 보장될 것인지에 대한 알고리즘도 필요한데 이에 관한 내용이 BABE와 GRANDPA 이다. BABE는 릴레이 체인의 블록 생성 메커니즘을 정의한 것으로, 블록 생성자를 어떤 식으로 랜덤하게 선택할 것인지에 관한 것이고 이는 확률적 완결성 (Probabilistic Finality) 을 제공한다. 그러나 확률적 완결성의 경우 블록이 revert 되는 위험이 항상 존재하는데, 여러 체인 간의 다리 역할을 하고자 하는 폴카닷의 목표에 이와 같은 특성은 불리할 여지가 많고, 결정론적 완결성 (Deterministic Finality) 가 필수적이다. 블록 생성 메커니즘인 BABE와는 독립적으로, 폴카닷의 GRANDPA는 증명 가능하고 (provable), 결정론적인 완결성을 제공하고자 한다.

3.2 BABE

BABE (Blind Assignment for Blockchain Extension)는 Validator 노드들 중 누가 블록을 생성할 것인지를 결정하는 알고리즘이다. Validator의 예치된 금액과 randomness cycle을 고려하여 선정하게 된다. 일정한 시간 간격을 정하여 이를 slot이라 하고 각 slot마다 블록 생성 후보자가 할당된다. 블록 생성 후보자를 정하는 과정은 완전히 private하게 이루어지기 때문에 “Blind Assignment”라는 이름이 붙은 것이다. 또, 후보자 노드들은 랜덤한 메커니즘으로 정해지는데, 한 slot에 여러 명의 후보자가 나올 수도 있고, 후보자가 아예 없을 수도 있다. 만약 slot에 블록 생성 후보자가 아무도 할당되지 않거나, 정해진 후보자들이 블록을 제안하지 않을 경우 그 slot을 empty slot이라고 부른다. 이 slot을 채우기 위한 secondary 블록 생성 메커니즘으로 Aura라는 알고리즘을 사용하는데, 본 아티클에서는 자세하기 다루지 않는다.

BABE 알고리즘에는 epoch이라는 시간 단위도 존재하고, 각 epoch은 여러 개의 slot들로 이루어져 있다. 각 epoch이 시작할 때 그 epoch 내에 존재하는 slot의 모든 블록 생성 후보자들은 자신이 어떤 블록을 제안할 수 있는지를 알 수 있게 된다. 그리고 자신이 할당된 slot의 차례가 오면 블록을 생성하고 자신이 후보자로 정해졌다는 증명을 제출하게 된다. 이더리움 2.0의 비콘 체인에서와 용어와 구조가 굉장히 유사한 것을 확인할 수 있다.

블록 생성 후보자를 고르는 과정은 Validator들만 알고 다른 노드들은 알 수 없게 해야 하는데, 폴카닷에서는 이들을 랜덤하게 고르는 메커니즘으로, 알고랜드, 에이다와 같은 체인들에서 많이 사용되는 VRF(Verifiable Random Function)을 사용한다. VRF 에 대한 자세한 메커니즘은 뒤로 하고, 기본적으로 어떤 개인의 공개키와 randomness를 입력값으로 했을 때 특정 한계값 k보다 작으면 선정되는 방식인데, 폴카닷에서는 randomness를 두 epoch 전에 생성한다. 그리고 slot number와 자신의 공개된 식별자를 VRF에 넣었을 때의 값을 확인하여 자신이 어떤 slot의 블록 생성자 후보가 되었는지를 알 수 있다. 그리고 자신이 공개된 식별자의 주인이라는 증명을 만들어 내는 메커니즘이 존재하는데, 자신의 비밀키를 노출시키지 않으면서 임계값 k보다 낮은 결과를 받았다는 것을 증명할 수 있다. 특정 한계값의 파라미터를 크게 하면 더 많은 생성자들이 후보로 선정될 것이고, 파라미터 값을 작게 하면 empty slot이 만들어질 가능성이 상대적으로 더 높아질 것이다.

3.2 GRANDPA

GRANDPA (GHOST-based Recursive Ancestor Deriving Prefix Agreement)는 폴카닷의 릴레이 체인 블록에 finality를 부여하기 위한 알고리즘이다. 만들어진 블록이 revert 되는 경우가 없게끔 보장하는 역할로서, 이더리움 2.0에서 블록의 완결성을 부여하는 Casper FFG와 유사한 메커니즘으로 이해할 수 있다. GRANDPA에 적용된 기본적인 아이디어는 체인 상에서 비잔틴 동의 (Byzantine Agreement) 를 이루는 블록을 정의하는 것인데, 2/3 이상의 Validator들이 동의한 블록에 대해 완결성을 보장하는 방식이다. GRANDPA에서는 validator들이 마지막으로 자신이 확인한 블록까지 투표를 하고, 특정 블록 입장에서 그 블록 또는 그 이후의 블록에 투표한 validator 수가 2/3 이상이 되면 완결성이 부여되는 방식이라고 이해할 수 있다. 아래 그림과 같은 상황이 이 메커니즘을 잘 표현했는데, Initial votes 에서처럼 투표가 이루어진 경우 색칠한 블록의 합의 비율은 포크된 양쪽 모두의 비율을 더한 100%임을 알 수 있다.

출처 : Polkadot Overview Paper

먼저 우리와 익숙한 Casper와 크게 다르지 않아 보이는데, Casper와의 차이점을 통해 GRANDPA를 더 이해해보도록 하겠다. GRANDPA의 대표 설계자인 Alstair Stewart는, GRANDPA가 Casper FFG와 가장 큰 다른점은 Casper에서 체크포인트 블록에서만 투표를 하는 것에 반해 GRANDPA에서는 체인 자체에 대해 동의를 이룬다는 점이다. 또 Tendermint 와 같이 모든 블록 각각에 대해 비잔틴 동의 (Byzantine Agreement) 를 이루는 방식과 비교하면 GRANDPA에서는 한 번에 많은 블록에 대해 비잔틴 동의를 이뤄낼 수 있고, 따라서 더 많은 Validator들이 동의를 이루는 데 참여하기가 쉬워진다고 언급하였다.

4. Bridging Methods, XCM

폴카닷 내 파라체인들끼리 통신을 하거나, 외부의 블록체인 간 통신을 안전하기 위해서 bridge 기술이 필요하다. 구체적인 Bridging 방법으로는 Bridge pallets, Smart contracts, Higher-order protocols 가 제시되어 있고, 다양한 방법들이 새로 나오고 있어 아직까지 이 부분은 현재 진행형이라고 할 수 있다. 간단하게 세 가지 방식의 특징과 사용처를 살펴보고, 이종 컨센서스 간 통신 포맷인 XCM 에 대해 살펴보도록 한다.

4.1 Bridge pallets , Smart Contracts, Higher-order Protocols

먼저 Bridge pallets는 Substrate-native 체인들끼리 통신하기 위해 주로 사용되는 방식이다. 여기서 Substrate 는 블록체인을 만드는 데 쓰이는 프레임워크이고, 폴카닷과 대부분의 파라체인이 Substrate 기반으로 만들어졌다. 폴카닷의 파라체인을 구성하는 추상 레이어로 이해할 수 있을 것이다. Kusama도 대표적인 Substrate 기반 체인이므로, 폴카닷과 Kusama가 통신할 때에는 Bridge pallet을 이용하는 것이 가장 안전하고 빠르다.

Bridge pallet 이외에, Substrate 기반이 아닌 체인들과 통신하기 위한 방법으로는 스마트 컨트랙트가 있다. 대부분의 튜링완전한 스마트 컨트랙트 언어를 사용하는 많은 블록체인 플랫폼들과 폴카닷 생태계와 통신하는 방식이기도 하다. Parity Bridge를 예시로 들면 두 개의 스마트 컨트랙트로 구성이 되어있는데, 연결하고자 하는 이더리움 메인 체인과 사이드체인 각각의 스마트컨트랙트에서 한 쪽에서 예치 이벤트가 일어나면 다른 체인에서 같은 양의 잔액이 생기는 방식으로 이루어진다. 이는 현재 대부분의 lock-and-mint 방식의 브릿지와 유사하고 프로토콜에 따라 중앙화되어있을 수도, 탈중앙화되어있을 수도 있다.

Higher-order 프로토콜들은 위 두 가지 옵션들이 불가능할 때 마지막으로 사용하도록 권장되는 프로토콜이다. XCLAIM이 대표적인 예시인데, 교환 가능한 자산이 더 큰 가치의 담보 자산을 필요로 하는데, 이러한 이유로 유동성의 낭비가 존재한다는 점이 단점이다. 비트코인 네트워크 또한 Substrate 기반도 아닐 뿐더러 스마트 컨트랙트도 지원하지 않기 때문에 이러한 방식의 프로토콜이 필요하다.

4.2 XCM

What is XCM?

XCM은 서로 다른 체인 (cross-chain)을 넘어, 서로 다른 합의 방식 (cross-consensus)의 시스템 간 통신에 사용되는 메세지 포멧이다. 단순히 레이어 1 메인체인 간의 통신 뿐만 아니라, 스마트 먼트랙트나 pallet 사이에서 의 메세지 전달 방식에서 사용되는 형식이라고 할 수 있다. 아직 개념이 많이 추상적으로 느껴지는데, XCM이라는 것은 결국 ‘규격’이다. 어떤 절차와 순서를 규정해놓은 프로토콜 (protocol)이 아니고, 서로 다른 시스템 간 메세지가 이동될 떄 그 메세지가 어떤 형태여야 하는지를 구체적으로 정의한 것이라고 이해할 수 있다. 프로토콜이 아니기 때문에 시스템 사이에 메세지를 전송하는 데 그 자체로는 쓰일 수는 없고 무엇이 행해져야 하는지를 표현한 것이다.

XCM은 체인 간 메세지 전송 뿐 아니라 다른 상황에서도 중요한 의미를 가진다. 트랜잭션의 형태를 미리 알지 못하는 체인과도 트랜잭션을 주고받을 수 있게끔 돕는 역할을 할 수 있다. 각기 다른 표준과 방식을 사용하고 있는 스마트 컨트랙트, 샤드 등 사이의 통신에 사용된다. 또한, 비트코인과 같이 프로토콜이 자주 변하지 않는 체인일 경우 트랜잭션 포맷 또한 거의 변하지 않겠지만, 폴카닷의 작은 규모의 파라체인들과 같이 빠르게 변하는 경우 트랜잭션의 포맷이 이전 버전과 호환 불가능해지는 경우가 많다. XCM을 통해 더 추상적인 레이어에서 일반화된 포맷을 정의함으로써 이 문제를 완화하고자 하는 것이다. 결국 한마디로 XCM은 시스템들 사이의 통신을 추상화하여, forward-compatible 하고, 확장 가능 (extensible) 한 기본적인 프레임워크를 만듬으로써, 종류가 다른 데이터 시스템들 사이의 상호작용을 촉진시키고자 한다.

폴카닷은 XCM 메세지 전달을 위한 3가지 주요 transport system (communication channel) : XCMP와 두 가지 종류의 VMP인 UMP와 DMP 을 가지고 있다. 먼저 XCMP (Cross-chain message passing)의 경우 파라체인과 또 다른 파라체인 사이의 안전한 메세지 전송에 사용되며, 2가지 형태인 Direct와 Relayed 가 존재한다. Direct 방식에서는 메세지 데이터가 릴레이 체인을 거치지 않고 파라체인끼리 직접 전송되며 확장성이 아주 뛰어나다는 장점이 있다. Relayed에서는 메세지 데이터가 릴레이 체인을 통해 전달되고, direct 방식에 비해서는 확장성이 떨어지는 편이다. 또 사용되는 큐에 쌓인 데이터가 과도하게 커지면 쓰레드가 메세지를 못 받을 수도 있다. VMP (Vertical Message Passing)는 릴레이체인과 파라체인의 통신을 정의한 채널인데, UMP (Upward Message passing)는 파라체인에서 릴레이체인으로 보낼 때 사용되며, DMP (Downward Message Passing)은 반대로 릴레이체인에서 파라체인으로 보내는 데에 사용된다.

XCM Anatomy

XCM의 기본적인 개념과, 어떤 시스템 상에서 사용되는 지를 알아보았으므로 실제로 이게 무엇이고 어떻게 구현되어있는지 간단하게 살펴보도록 하겠다. 지금부터 언급할 예시들은 개빈 우드 (Gavin Wood)의 미디엄 내용을 참조한 내용이다. (원본링크)

XCM은 XCVM (Cross-chain Virtual Machine) 이라는 튜링 불완전한 가상 머신 위에서 실행된다. XCM 형태로 된 메세지는 XCVM 위에서 돌아가는 프로그램으로 생각할 수 있고, 여러 개의 XCM instruction들로 구성되어 있다. Instruction의 한 예시로 TransferAsset이 있는데 이는 다른 시스템으로 자산을 이동하는 함수이다. 아래 Rust 코드를 보면 TrasnferAsset은 assets와 beneficiary로 구성되어 있고, 말 그대로 assets는 이동시키고자 하는 자산을 특정하고 beneficiary는 어디로 이동할 것인지를 의미한다. 어디로부터 이동시킬 것인지는 조작되어서는 안되므로 format 내에 명시하는 것이 아니라, 메세지가 실행될 때 Origin Register라는 임의로 조작될 수 없는 레지스터에 적히는 형태이다.

여기서 자산의 수신자의 타입은 MultiLocation인데, 특이하게도 Multilocation이 나타내는 location은 상대적인 위치이다. 폴카닷의 세계에서는 블록체인들이 다른 체인에 병합될 수도 있고, 분리될 수도 있기 때문에 절대적인 위치로 할 경우 root가 바뀌어 혼란이 야기되는 경우를 막기 위함이다. 예시로, 한 파라체인에서 ../Parachain(1000)을 참조하면 index 1000의 sibling parachain을 의미하는 것이고, ../AccountId32(0x1234..cdef)는 릴레이 체인 상의 어떤 주소를 의미하는 것이다.

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

XCM은 또한 서로 다른체인에서 존재하는 다양한 asset들을 표현하기 쉽게 설계되었다. MultiAsset이라는 데이터 타입으로 정의하는데 id와 fun이라는 필드로 구성되어 있다.

struct MultiAsset {
	id : AssetId,
	fun : Fungibility
}

AssetId는 Concrete 또는 Abstract로 표현되는데,

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

대부분의 경우 Abstract가 아닌 Concrete 타입이다. 주로 쓰이는 Concrete의 경우 앞서 언급한 location이라는 타입을 사용한다. DOT과 같은 native 토큰들은 체인의 상대적인 위치(e.g. 파라체인에서 .. 은 릴레이 체인을 표현 ) 그 자체로 표현이 된다. 체인의 pallet 내에서 정의된 asset은 pallet 내의 Index를 지정함으로써 표현할 수 있다. (e.g. ../Parachain(100)/PalletInstance(50)/GeneralIndex(42) )

Fungibility 타입은 Fungible 또는 NonFungible 타입인데, fungible의 경우 액수로 표현될 것이고 non-fungible의 경우에는 그 asset이 무엇을 나타내는지를 명시한다.

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

Conclusion

XCM에 대한 구체적인 형태에 대한 설명을 끝으로, 폴카닷 Overview를 마무리하고자 한다. 본 아티클에서는 전반적인 폴카닷의 목표, 신조, 아키텍처부터, 주요 합의 알고리즘과 폴카닷 내에서 사용되는 체인 간 통신 프로토콜, 규격 등을 살펴보았다. Pallet나 컨트랙트를 통한 체인 간 통신 프로토콜은 아직까지 완성된 형태가 아니라 빠르게 연구, 개발되는 단계이고 폴카닷에서 제시하는 주요 메세지 포맷인 XCM 또한 아직 릴리즈 예정 단계에 있다. 크로스체인이라는 영역이 블록체인 연구의 한 섹터로서 미완 단계에 있고 최근 들어 브릿지의 대규모 해킹 사건들이 많이 일어나고 있으며, 비탈릭 또한 레딧을 통해 현재의 크로스체인 기술 방향이 네트워크 공격 유인을 증가시킨다는 점에서 우려하기도 하였다. 상호운용성을 메인으로 집중하는 체인들인 폴카닷, 코스모스, 그리고 많은 연구와 새로운 시도들이 제안되는 이더리움 리서치 등에서 연구자들이 블록체인의 상호운용성 (interoperability) 문제에 대한 새로운 해결책들을 다방면으로 제시하고 있다고 생각하고, 많은 경쟁과 논의를 통해 크로스체인 기술이 발전하고 안정화되기를 기대한다.

Reference

1. (Polkadot Original White Paper) POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK
2. (Polkadot Specification paper) Overview of Polkadot and its Design Considerations
3. https://medium.com/polkadot-network/xcm-the-cross-consensus-message-format-3b77b1373392
4. https://medium.com/polkadot-network/polkadot-proof-of-concept-3-a-better-consensus-algorithm-e81c380a2372
5. https://wiki.polkadot.network/docs/glossary##substrate
6. https://polkadot.network/blog/xcm-the-cross-consensus-message-format/