[Devcon5] Polkadot Overview

박정원(Aiden Park)
Oct 24 · 23 min read

Devcon5 에서는 Ethereum 2.0을 중심으로 향후 블록체인 생태계를 확장시킬 수 있는 다양한 블록체인 프로토콜에 대한 논의가 이루어졌습니다. 본 리뷰에서는 그 중 하나인 폴카닷(Polkadot)을 전체적으로 살펴봅니다. 폴카닷은 특히 이더리움 2.0의 핵심인 샤딩(Sharding)과 구조적으로 매우 비슷한 형태를 갖고 있기에 두 프로젝트가 확장성(Scalability)를 각자 어떤 방식으로 해결하고자 하는지를 비교하면서 보시면 더욱 흥미로울 것이라 생각됩니다.

Overview

폴카닷은 다수의 이종(heterogeneous) 블록체인을 연결하는 프로젝트입니다. 특이한 점은 폴카닷 네트워크의 외부가 아닌 내부에서도 서로 이종 체인을 연결한다는 점입니다.

폴카닷은 그림과 같이 크게 릴레이체인(Relay chain), 파라체인(Parachain)과 다른 네트워크와의 브릿지(Bridge)로 구성됩니다. 릴레이체인은 파라체인의 컨센서스와 파라체인간의 트랜잭션 전달을 담당합니다. 폴카닷에서 검증자(Validator)로 참여하기 위해서는 DOT을 릴레이체인에 예치해야 합니다. 또한 릴레이 체인의 트랜잭션 종류는 매우 제한적인데, 이는 대부분의 연산들은 파라체인에서 처리되기 때문입니다. 이더리움2.0에 익숙하신 분들은 릴레이체인은 이더리움 2.0의 비콘체인(Beacon chain)과 매우 닮아 있는 것을 알 수 있을 것입니다.

파라체인은 독자적인 상태 전이 함수(State Transition Function; STF)를 가지며, 이를 통해 파라체인에서 생성된 트랜잭션을 처리하게 됩니다. 중요한 점은 안전성(Security)이 릴레이 체인에 의존한다는 점입니다. 파라체인에는 검증자가 파라체인에서의 상태 전이(State Transition)를 정상적으로 검증할 수 있도록 증거(Proof)를 생성할 수 있어야 한다는것 외에는 그 구체적인 구현에 대해 어떠한 제약을 두지 않습니다.

브릿지(Bridge)는 폴카닷 네트워크의 외부의 다른 블록체인과 연결하는 역할을 합니다. 브릿지는 현재 여전히 활발히 연구중인 분야이고, 그 구체적인 구현이 확정되지 않았기 때문에 본 글에서는 깊게 다루지 않도록 하겠습니다.

Parachain

폴카닷에서 실질적으로 트랜잭션들을 처리하는 파라체인에 대해 더 자세히 살펴보도록 하겠습니다. 앞서 설명했듯, 파라체인의 안전성은 릴레이체인의 검증자들에 의해 결정됩니다. 하지만 파라체인의 운영 자체는 검증가가 아닌 콜레이터(Collator) 노드가 수행하게 됩니다.

콜레이터는 파라체인의 풀노드를 운영하면서, 필요한 모든 정보를 유지 관리하며, 새로운 블록 후보군들을 릴레이체인의 검증자들에게 전달하는 역할을 합니다. 콜레이터는 검증작업에 참여하는 것이 아니기 때문에, 검증자들과 달리 릴레이체인에 DOT 토큰을 예치할 필요가 없습니다.

또한 콜레이터들의 참여 유인은 각 파라체인에 맞게 설계할 수 있습니다. 파라체인에 직접 토큰 이코노미를 설계하여 콜레이터의 참여를 유도할 수도 있고, 불특정 다수의 콜레이터가 필요하지 않은 경우 컨소시움 블록체인과 같이 정해진 노드들만 콜레이터의 역할을 수행하도록 사전에 규정할 수도 있습니다. 때문에 각 파라체인은 퍼블릭(Public) 체인 혹은 프라이빗(Private)체인의 형태를 목적에 맞게 유연하게 구성할 수 있습니다.

파라체인의 상태 전이는 모두 릴레이체인에 등록된 상태 전이 함수를 통해 검증되기 때문에, 파라체인의 구체적인 구현은 릴레이 체인의 검증자를 통해 검증될 수 있기만 하면 어떠한 형태이든 관계가 없습니다. 하나 이상의 콜레이터가 검증증명(Proof-of-Verification; PoV)블록의 형태인 여러개의 증명을 검증자에게 제출하여 파라체인의 검증이 이루어지게 됩니다.

이러한 점은 이더리움 2.0의 샤딩과 구별되는데, 샤딩의 경우 원래 하나의 체인에서 이루어지는 연산을 여러 체인에 나누어서 처리하려는 목적이지만, 폴카닷의 경우 서로 다른 여러 체인을 연결하고 해당 체인들의 안전성만 하나의 체인에서 보장하는 개념이기 때문입니다. 따라서 폴카닷의 경우 이더리움과 달리 각 파라체인에 대한 구현을 자유롭게 두고, 콜레이터에 대한 역할도 자유롭게 정할 수 있도록 하는 것입니다.

여기서 질문을 하나 해보겠습니다. 파라체인 내부의 컨센서스(Consensus)는 필요할까요?

정답은 No입니다.

있을 필요도 없고, 있다 하더라도 의미가 없습니다. 파라체인의 컨센서스는 릴레이체인의 컨센서스에 완전히 의존하기 때문입니다. 파라체인에서는 오직 블록의 생성에 대한 것만 규정할 수 있습니다.

이는 어떠한 측면에서 레이어2 솔루션 중 하나인 플라즈마(Plasma)와도 맞닿아 있습니다. 플라즈마에서는 각 플라즈마 체인이 모두 독립된 구조를 가질 수 있지만, 각 체인의 안전성은 모두 루트체인에 의존합니다. 따라서 플라즈마 체인 내부의 컨센서스는 블록 생성에 대한 권한을 규정하는것 외에는 어떠한 의미도 없습니다.

Shared security

폴카닷 네트워크에 연결된 모든 체인들은 하나의 안전성(Security)을 공유합니다 .이는 Shared security 혹은 Pooled security으로 폴카닷에서 가장 중요한 개념중 하나인데, 쉽게 말해 폴카닷 네트워크에 참여하는 모든 파라체인들이 동일한 안전성을 갖는다는 것입니다. 이는 릴레이체인의 컨센서스가 모든 파라체인의 안전성를 보장하기 때문인데, 이를 통해 파라체인으로 참여하는 당사자는 파라체인의 안전성를 위해 어떠한 노력도 할 필요가 없습니다. 물론 Shared security가 오직 장점만 있는 것은 아닙니다. 만약 릴레이체인의 안전성을 위협하는 문제가 발생할 경우(e.g 릴레이 체인의 staking token의 가치하락) 전체 네트워크를 한번에 공격하는 것이 매우 쉬워지기 때문입니다.

GRANDPA / BABE

폴카닷의 컨센서스는 GRANDPA와 BABE입니다. 두개의 용어로 미루어보아 눈치가 빠르신 분들은 폴카닷이 하이브리드 컨센서스를 사용한다는 점을 알 수 있을 것입니다. 하이브리드 컨센서스란 간단히 말해 블록의 생성 과정(Block production)과 확정성 부여 과정(Finality gadget)을 분리한 것을 의미합니다.

폴카닷에서 하이브리드 컨센서스를 사용하는 이유를 알기 위해서는 확률적 확정성(Probabilistic finality)와 증명가능한 확정성(Provable finality)가 무엇이고 어떤 의미를 갖는지에 대한 이해가 선행되어야 합니다.

Probabilistic finality

확률적 확정성(Probabilistic finality)은 말 그대로 확률적으로 확정성을 보장하는 것을 의미합니다. 사실 확률적이라는 점에서 확정성을 ‘보장’한다고 보기는 힘든 측면이 있습니다.

확률적 확정성(Probabilistic finality)의 대표적인 예는 비트코인에서 사용되는 나카모토 컨센서스(Nakamoto consensus)입니다. 나카모토 컨센서스에서는 항상 가장 긴 체인(Longest chain)이 올바른 체인(Canonical chain)이 됩니다. 하지만 어떠한 이유로든 네트워크 장애로 인해 더 긴 체인이 나중에 발견될 수 있습니다. 이 경우 기존의 올바른 체인은 더 이상 올바르지(Canonical) 않게 되며, 소위 재정렬(Reorg)라는 과정을 통해 다른 체인이 올바른 체인이 됩니다. 이러한 컨센서스는 언제인지 모르지만 결국에는 확정성에 이른다는 의미로 Eventual consensus라고 하기도 합니다. 특정 블록을 부모 블록으로 하는 체인이 길어질수록 해당 블록은 확정적일 가능성이 계속해서 높아지기 때문입니다.

이러한 확률적인 요소로 인해 발생하는 재정렬문제 등을 미루어 볼 때, 확률적 확정성은 블록체인에 긍정적인 영향을 준다고 보기 힘듭니다. 하지만 그럼에도 불구하고 확률적 확정성을 사용했을 때 얻을 수 있는 장점 또한 존재합니다. 대표적인 장점으로 네트워크에 문제가 발생하여 노드간의 연결이 끊어져 네트워크가 분할(Network Partition)이 발생했을 때도 블록의 생성자체는 계속 이루어질 수 있습니다.

Provable finality

증명가능한 확정성(Provable finality)은 특정 블록이 확정되었다는 것이 완벽히 증명가능한 것으로, 한번 확정된 블록은 어떠한 경우에도 다시 되돌려지지(Revert) 않습니다. 확률적 확정성에서 특정 블록이 얼마든지 재정렬로 인해 되돌려질 수 있었던 것과 정반대입니다.

이후 살펴볼 GRANDPA와 이더리움의 Casper FFG, Tendermint와 같은 것들이 증명가능한 확정성을 보장하는 대표적인 컨센서스입니다.

*Casper FFG 또한 폴카닷의 컨센서스와 같이 하이브리드 컨센서스로 분류됩니다.

증명가능한 확정성은 한번 확정된 블록은 절대로 되돌려질 수 없다는 점에서 매우 큰 장점을 갖지만 반대로 단점 또한 존재합니다. 만약 네트워크에 문제가 발생할 경우 블록 생성 자체가 멈추는 상황이 발생할 수 있기 때문입니다. 실제로 Tendermint에서는 정족수의 노드가 합의를 하지 못할 경우 다음 블록에 대한 합의로 넘어갈 수 없기 때문에 그대로 멈춰있게 됩니다.


폴카닷에서는 앞서 언급된 확률적 확정성과 증명가능한 확정성의 장점은 취하고 단점은 완화하기 위해 두가지 방식을 결합한 하이브리드 컨센서스를 사용합니다. 이를 통해 확률적 확정성에서 발생할 수 있는 문제인 잘못된 포크를 따라가는 경우나, 증명가능한 확정성에서 발생할 수 있는 문제인 새로운 블록을 생성하지 못하고 멈춰있는 경우를 방지할 수 있게 됩니다.

GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement)

GRANDPA는 릴레이체인에서 블록의 확정성을 결정하기 위해 사용되는 Finality gadget입니다. 앞서 언급된 증명가능한 확정성을 보장하기 위한 컨센서스에 해당합니다. 다른 BFT기반의 컨센서스와 같이 부분 동기 네트워크 모델(partially synchronous network model)에서 ⅔ 보다 많은 노드가 정직할(Honest) 경우에만 올바르게 동작합니다. GRANDPA는 특이하게도 블록이 아닌 체인에 대해 합의를 하며, 이를 통해 오랜 시간 네트워크에 문제가 생긴 이후에도 다시 빠르게 블록 확정 작업을 진행할 수 있습니다. 다음 그림을 통해 GRANDPA의 동작 원리를 간단하게 살펴보도록 하겠습니다.

GRANDPA에서 검증자들은 특정 블록을 대상으로 투표하는 것이 아니라 올바르다고 생각하는 가장 높은 블록(Highest block)을 대상으로 투표합니다. 이 경우 해당 검증자는 대상 블록의 모든 부모 블록이 올바르다고 투표를 한 것과 다름이 없게 됩니다.

GRANDPA에서 검증자들이 이와 같이 투표를 하고, 특정 블록에 2/3를 초과하는 검증자들의 예치금(Stake)이 투표되었을 경우 해당 블록은 확정되게 됩니다. 위 그림을 보면 노드1은 자신의 예치금 $20를 D1에 투표하였고, 노드2는 $40을 F1에, 노드 3은 $15를 E2에 투표한 것을 확인할 수 있습니다. 이 때 D2는 총 $55가 투표되어 전체 예치금인 $100의 2/3를 초과하지 못했기 때문에 아직 확정되지 않은 상태입니다. C의 경우 총 $75가 투표되었으므로 확정된 상태입니다.

GRANDPA의 장점은 마지막으로 확정된 블록 이후에 아무리 많은 블록이 쌓여있더라도 새로운 블록을 쉽게 확정할 수 있다는 점입니다. 이는 단일 블록을 대상으로 투표를 진행하는 것이 아니라 가장 높은 블록을 대상으로만 투표를 진행하기 때문입니다. 때문에 네트워크 지연율이 낮을때는 거의 즉시 확정할 수 있게 되고, 네트워크에 장기간 문제가 발생했을 경우에도 복구속도가 매우 빠르다는 것이 GRANDPA의 장점이라고 할 수 있습니다.


GRANDPA는 Casper FFG에서 영감을 받아 설계된만큼 두 컨센서스는 매우 비슷한 구조를 갖고 있습니다. 다만, Casper FFG에서 검증자들이 특정 체크포인트(Checkpoint)마다 투표를 하는 것과 달리, GRANDPA에서는 체크포인트라는 단위도 없이 아무 블록이나 투표가 가능하다는 것이 근소한 차이점입니다.

BABE (Blind Assignment for Blockchain Extension)

GRANDPA가 블록의 확정성을 결정하는 과정이었다면, BABE는 새로운 블록을 생성하는 권한을 결정하는 블록 생성 메커니즘입니다. BABE의 핵심은 블록 생성에 대한 권한을 검증인들에게 무작위적으로 부여한다는 점입니다.

BABE에서는 검증가능한 랜덤 함수(Verifiable random function; VRF)을 통해 무작위적으로 블록 생성 권한을 부여합니다. 먼저 VRF가 어떠한 기능을 하는지 간략하게 살펴보겠습니다.

VRF는 크게 3가지 알고리즘으로 구성됩니다.

● Keygen(r) → (VK, SK).

Keygen은 임의의 입력을 받아 검증키 VK와 비밀키 SK를 생성합니다.

● Evaluate(SK, X) → (Y, ⍴).

Evaluate는 비밀키 SK와 메세지 X의 입력을 받아 의사 랜덤 문자열 Y와 증명 ⍴을 생성합니다. 이 때 Y는 SK에 대해 고유한 값입니다.

● Verify(VK, X, Y, ⍴) → 0/1.

Verify 알고리즘은 검증 키 VK, 메시지 X, 문자열 Y, 증명 ⍴의 입력을 받아 Y가 Evaluate(Sk, X)에서 생성된 문자열임을 검증하며, 검증에 성공할 경우 1을 출력하고 그렇지 않을 경우 0을 출력합니다.

이를 이용해 블록의 생성권한을 랜덤하게 결정할 수 있게 됩니다. 예를 들어 사전에 VK와 SK를 모두 등록하고, Evaluate(SK, X)의 출력값 Y가 특정 범위안에 위치할 경우 블록 생성권한을 부여하는 것입니다. 물론 이 때 X는 사전에 예측할 수 없는 값이어야 하고, 중간에 키를 변경할 수 없어야 합니다. 특정 범위안에 위치한 Y값을 출력한 SK의 소유자는 Verify(VK, X, Y, ⍴)를 통해 해당 Y값이 본인의 SK로 부터 출력된 값임을 증명할 수 있고, 블록 생성 권한을 부여받게 됩니다.

폴카닷에서 블록 생성자가 되기 위해서는 DOT을 예치함과 동시에 VRF 키를 등록해야 합니다. VRF를 통해 해당 키를 보유한 자가 언제 블록을 생성할 수 있는지를 결정하는 랜덤값을 생성하게 되는 구조입니다. 물론 VRF 키를 의도적으로 특정 값으로 등록할 수 있기 때문에 Evaluate(SK, X)의 X값은 반드시 VRF 키가 생성된 이후에 생성된 퍼블릭 랜덤값만 포함되어야 합니다.

폴카닷에서 블록을 랜덤하게 생성할 수 있게하는 이유는 궁극적으로 파라체인의 블록이 콜레이터가 아닌 검증자에 의해 생성되기 때문입니다. 콜레이터는 블록을 생성하여 그 후보군들을 검증자에게 전달할 뿐 블록을 생성할 수 있는 권한이 없습니다. 문제는 어떤 이유로든 악의적인 검증자가 특정 파라체인의 블록을 검열하여 지속적으로 블록의 생성을 막을 수 있다는 점입니다. 따라서 특정 파라체인에 대한 블록 생성자를 랜덤하게 할당하게 하여 이러한 검열 문제를 최소화 할 수 있게 됩니다.


이더리움 2.0의 샤딩에서도 검증자를 무작위적으로 배정하기 위해 랜덤 샘플링을 이용합니다. 하지만 폴카닷의 BABE에서 VRF를 사용하는 것과 달리 이더리움 2.0은 RANDAO와 VDF(Verifiable Delay Function)을 사용한다는 차이가 있으며, 이 외에도 큰 차이점이 하나 더 있습니다.

폴카닷에서는 블록의 생성권한만 랜덤하게 부여하는 반면, 이더리움 2.0의 샤딩은 블록의 검증자 또한 랜덤하게 배정을 합니다. 이는 이더리움 2.0에서 모든 검증자가 모든 샤드의 블록을 검증하는 것이 아니라 검증자 풀의 일부가 하나의 샤드를 검증하기 때문입니다. 반면 폴카닷의 경우 릴레이체인의 검증자들은 모두 전체 파라체인의 블록들을 검증합니다. 즉, 추가적인 랜덤 샘플링이 필요치 않은 것입니다.

두 방법 모두 장단점이 존재한다고 생각됩니다. 이더리움 2.0의 경우 랜덤 샘플링이 문제 없이 작동해야만 안전성이 보장될 수 있지만, 폴카닷의 경우 안전성의 측면에서 추가적인 랜덤 샘플링에 대한 고려를 하지 않아도 됩니다. 하지만 이더리움 2.0은 모든 검증자가 모든 샤드체인을 검증해야 하는 것이 아니기 때문에 폴카닷에 비해 검증작업이 보다 효율적으로 이루어질 수 있을것입니다.

Interchain Message Passing (ICMP)

ICMP는 폴카닷 프로토콜의 일부로, 파라체인 혹은 릴레이체인간의 추가적인 신뢰 메커니즘 없이 메세지를 전달하는 방법을 정의합니다.

ICMP에 대해 구체적으로 설명하기 전에 폴카닷에서 각 파라체인을 검증하는 작업이 어떻게 이루어지는지 간략하게 살펴볼 필요가 있습니다. 파라체인은 단일 상태 전이 시스템이므로, 파라체인의 검증함수를 다음과 같이 간단하게 표현할 수 있습니다.

(head_data’, messages_out) = V(head_data, header, extrinsics, witness, messages_in)

검증함수 V는 파라체인의 상태 전이가 올바르게 되었는지를 검증합니다. 여러 파라미터가 있지만 핵심은 이전 파라체인 블록헤더의 해시값인 head_data에서 다음 블록인 head_data’로 올바르게 연산되었는지를 검증한다는 점입니다. 여기서 messages_in과 messages_out에 주목할 필요가 있습니다. messages_in은 다른 파라체인에서 해당 파라체인으로 보낸 메세지들을 의미하고 messages_out은 해당 파라체인에서 다른 파라체인으로 보내는 메세지들을 의미하기 때문입니다. 즉, messages_in과 messages_out 또한 검증자가 해당 파라체인의 상태 전이를 검증할 때 모두 검증하게 되는 것입니다.

messages_in, messages_out은 다음과 같이 단순한 형태로 표현되고 Endpoint는 메세지의 목적지를 나타내고, 실제 메세지 내용은 blob-vectors의 형태로 저장됩니다.

messages_in: Vec<EndPoint, Vec<Vec<u8>>>

messages_out: Vec<EndPoint, Vec<Vec<u8>>>

EndPoint: enum { Para(uint32), Relay }

ICMP에는 Upward, Downward, Lateral의 총 3가지 메세지 전달 방향이 존재합니다. 여기서는 파라체인간의 메세지 전달에 해당하는 Lateral Messages만 다루도록 하겠습니다. Lateral Messages에서 릴레이 체인은 실제 메세지 데이터들을 저장하거나 확인하지 않습니다. 검증 과정에서 오직 해당 메세지 데이터의 해시만 체크하게 됩니다. 이를 통해 만약 메세지를 전달받은 다른 파라체인이 올바르지 않은 메세지 데이터를 이용하게 되면 해시 체크에 실패하는 형식입니다.

물론 이 경우 문제가 한가지 발생할 수 있습니다. 바로 데이터 가용성(Data availability)문제입니다. 예를 들어 A파라체인에서 B파라체인으로 메세지 M을 보냈다고 하겠습니다. 이 때 A가 M의 데이터를 B에 전달하지 않을 경우 B는 messages_in을 올바르게 구성할 수 없게 되고, 따라서 올바른 상태 전이를 연산할 수 없게 됩니다. 이 경우 릴레이체인 R은 오직 hash(M)만을 체크하고 있기 때문에, A는 올바르게 메세지를 전달했지만 B는 해당 메세지를 올바르게 처리하지 못한 것으로 판단할 수 밖에 없게 됩니다.

이를 방지하기 위해 폴카닷에서는 메세지 데이터를 릴레이 체인에 명시적으로 저장하지는 않지만, 해당 메세지가 포함된 파라체인의 블록들을 검증했던 검증자들이 필요시 데이터를 제공할 수 있도록 강제합니다.

ICMP의 전체 과정을 간략하게 살펴보면 다음과 같습니다.

  • 파라체인 A의 스마트 컨트랙트에서 파라체인 B의 다른 스마트 컨트랙트로 자산이 이동하는 메세지를 생성하려고 합니다.

ICMP는 이더리움 2.0의 크로스 샤드 커뮤니케이션(Cross shard communication)과 비교해 볼 수 있습니다. 결론부터 말하자면 ICMP는 일종의 비동기 크로스 샤드 커뮤니케이션(Asynchronous cross shard communication)과 유사합니다. ICMP는 특정 파라체인에서 먼저 메세지를 생성하고 처리한 후 다른 파라체인이 이어서 처리하는 구조이기 때문입니다.

이더리움 2.0의 크로스 샤드 커뮤니케이션은 동기 크로스 샤드 커뮤니케이션(Synchronous cross shard communication)을 포함합니다. 동기 크로스 샤드 커뮤니케이션은 간단하게 말해 동시에 여러 샤드 체인의 컨트랙트에 접근하여 트랜잭션을 처리할 수 있도록 하는 내용입니다. 자세한 내용은 train and hotel problem을 살펴보시기 바랍니다.

반면 폴카닷은 다수의 체인이 동일한 안전성(Shared Security)만을 공유할 뿐 어디까지나 개별적인 블록체인이 모여있는 것이기 때문에, 이더리움 2.0과 같이 여러 파라체인에서 동기적으로 메세지를 처리하는 요소는 고려할 필요가 없다고 보는듯합니다.

Differences between Polkadot & Cosmos

폴카닷과 코스모스는 모두 인터체인 프로젝트로 자주 비교되고, 비슷하게 여겨지곤 합니다. 하지만 엄밀히 말하면 체인을 서로 연결한다는 점 외에는 아키텍처상으로 다른 점이 많습니다. 여러가지 차이가 있지만 핵심은 바로 Security model의 차이점에 관한 것입니다. 앞서 Shared security에서 언급되었듯이 폴카닷은 네트워크에 참여하는 모든 파라체인들의 안전성이 릴레이체인에 의존합니다. 즉, 폴카닷 네트워크의 모든 체인들은 안전성을 모두 공유합니다. 따라서 각 파라체인들은 컨센서스에 대한 고려 없이 비교적 쉽게 네트워크에 참여할 수 있습니다.

코스모스의 아키텍처는 핵심은 각 허브(Hub) 존(Zone)이 독립적인 컨센서스를 갖는다는 것입니다. 따라서 허브는 존의 안전성에 대해 어떠한 책임도 지지 않습니다. 또한 폴카닷에서 릴레이체인이 단 하나였던것과 달리 코스모스의 허브는 여러개가 될 수 있습니다. 폴카닷이 Shared security였다면, 코스모스는 Independent security라 할 수 있습니다. 따라서 코스모스에 참여하는 각 체인들은 안전성을 보장하기 위해 독립적으로 컨센서스를 구성해야 합니다.

폴카닷과 코스모스의 차이점들은 대부분 다른 Security model로 인해 발생하기 때문에, 두 프로젝트를 비교할 때 가장 중요한 것은 바로 이 점을 이해하는 것입니다.

또한 각 프로젝트의 Security model중 어느것이 더 우월한가를 따지는 논쟁은 무의미하다고 생각됩니다. 각자 모두 장단점이 존재하기 때문입니다. 폴카닷의 경우 파라체인이 릴레이체인의 안전성을 쉽게 이용할 수 있다는 것이 장점이지만, 반대로 릴레이체인에 문제가 생길 경우 콜레이터의 행동과 관계 없이 모든 파라체인들 또한 문제가 발생하게 된다는 점은 단점이 될 수 있습니다.

코스모스 또한 각 체인이 독립적으로 컨센서스를 구성해야 한다는 것은 단점이 될 수도 있지만, 반대로 각 체인의 문제를 오직 해당 체인만으로 국한시킬 수 있다는 점에서는 전체 네트워크의 관점에서 보다 안전한 모델이라고 바라볼 수 있습니다.

Differences between Polkadot & Ethereum 2.0

폴카닷과 이더리움 2.0은 유사한 측면이 매우 많습니다. 폴카닷의 릴레이체인과 파라체인은 각각 비콘체인과 샤드체인과 구조적으로 매우 유사합니다. 물론 차이점 또한 존재합니다. 우선 이더리움의 샤드체인은 모두 스펙이 동일한 동종체인(homogeneous)인 반면 폴카닷의 파라체인은 각각 스펙이 다르게 정의될 수 있는 이종체인(heterogeneous)입니다. 또한 컨센서스도 서로 다르며, 체인간의 통신을 정의하는 방법인 ICMP와 크로스 샤드 커뮤니케이션에 있어서도 차이가 존재합니다.

이외에도 여러 차이가 존재하지만 결정적인 차이는 바로 확장성 문제를 해결하는 ‘방향’이라고 생각됩니다. 이더리움은 이더리움 체인 내부의 확장성 문제를 해결하기 위해 샤딩이라는 방향을 선택했고, 폴카닷은 여러 체인들을 하나의 Security를 공유할 수 있도록 하는 방향을 선택했습니다.

해결하고자 하는 문제는 동일하지만 방향은 서로 다른 두 프로젝트, 앞으로가 매우 기대됩니다.

References

https://polkadot.network/PolkaDotPaper.pdf

https://wiki.polkadot.network/en/

https://polkadot.network/Polkadot-lightpaper.pdf

https://www.parity.io/a-brief-summary-of-everything-substrate-polkadot/

https://github.com/w3f/polkadot-re-spec/blob/master/runtime-environment-spec/polkadot_re_spec.pdf

https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf

https://medium.com/polkadot-network/polkadot-proof-of-concept-3-a-better-consensus-algorithm-e81c380a2372

https://research.web3.foundation/en/latest/polkadot/BABE/Babe/

https://medium.com/algorand/algorand-releases-first-open-source-code-of-verifiable-random-function-93c2960abd61

https://github.com/paritytech/polkadot/wiki/ICMP

https://research.web3.foundation/en/latest/polkadot/ICMP/

https://github.com/ethereum/wiki/wiki/Sharding-FAQ#what-is-the-train-and-hotel-problem

https://github.com/ethereum/wiki/wiki/Sharding-FAQ#how-can-we-facilitate-cross-shard-communication

https://medium.com/@juliankoh/5-differences-between-cosmos-polkadot-67f09535594b

Onther

Building an Ethereum Blockchain ECO system to Change the World

박정원(Aiden Park)

Written by

Entrepreneur, Developer

Onther

Onther

Building an Ethereum Blockchain ECO system to Change the World

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade