*본 보고서는 2024년 7월에 발간된 'Demystifying JAM'의 번역본입니다. Parity Technologies의 Engineering Lead인 Kian Paimani에 의해 작성되었으며, Technical Writer인 Terri에 의해 번역되었습니다.
본 아티클은 폴카닷 1.0, 폴카닷 2.0, 그리고 이들이 JAM으로 발전하는 과정에 대한 기초적인 설명을 담고 있습니다. 폴카닷에 익숙하지 않지만 블록체인 시스템에 대한 개략적인 이해를 갖춘 독자, 그리고 기술적 수준에서 다른 생태계에 익숙한 독자들을 대상으로 하며, 본격적으로 JAM 그레이페이퍼를 탐독하기 이전에 좋은 예비 지식을 제공합니다.
1. 배경 지식
이하에서는 다음 개념이 등장하며, 이에 대한 이해를 전제로 합니다.
- 상태 전환 함수(State Transition Function)로서의 블록체인
- “상태”(State)에 대한 이해
- 두 개념 모두 여기에 설명됨
- 경제적 보안성(Economic Security)과 지분 증명(Proof of Stake)
2. 서문: 폴카닷 1.0
우선 폴카닷 1.0의 가장 혁신적인 특징을 요약하자면 아래와 같습니다.
- 사회적 측면:
- 폴카닷은 모든 면에서 하나의 거대한 DAO라고 볼 수 있습니다. 포크리스(fork-less) 런타임 업그레이드를 포함한 네트워크 거버넌스는 완전히 체인 위에서 자체 실행 방식으로 이루어집니다.
- 미국 증권거래위원회(SEC)는 DOT을 증권이 아닌 소프트웨어로 간주합니다.
- 대부분의 네트워크 개발은 회계 상의 회사(예: 패리티)가 아닌 폴카닷 펠로우십이 담당합니다.
- 기술적 측면:
- 보안의 공유 및 샤딩(블록체인 네트워크의 데이터를 “샤드”로 분할하여 처리하는 기법)된 실행(sharded execution)
- WASM 기반 메타 프로토콜 사용. 블록체인 코드를 바이트코드 형태로 상태에 저장함으로써 대부분의 업그레이드를 포크리스로 진행할 수 있으며, 이를 통해 폴카닷에서 샤딩뿐만 아니라 이종(heterogeneous) 샤딩이 가능해집니다. 자세한 내용은 이종성을 참고해 주시기 바랍니다.
이제 샤딩된 실행을 자세히 살펴 보도록 하겠습니다.
3. 샤딩된 실행의 핵심: 코어
*본 아티클에서는 폴카닷이나 이더리움 같이 다른 L2 “블록체인”을 호스팅하는 L1 네트워크를 다루고 있습니다. 이에 따라, L2와 파라체인(Parachain)은 동의어로 간주하겠습니다.
블록체인 확장성의 핵심적인 문제는 다음과 같이 요약할 수 있습니다. 밸리데이터 집단이 존재하며, 이들이 실행하는 코드는 지분 증명이라는 암호 경제학적 개념을 통해 신뢰가 보장됩니다. 밸리데이터들은 기본적으로 서로의 작업 전체를 재실행해야 합니다. 즉, 이 시스템은 모든 밸리데이터들이 항상 모든 것을 (재)실행하도록 강제하는 한 확장될 수 없습니다.
윗 문단에서 언급한 재실행 원칙이 유지되는 이상 이 모델에서는 밸리데이터의 수가 증가한다고 해서 시스템의 처리량도 함께 증가하는 것이 아님에 주목할 필요가 있습니다.
위의 설명은 샤딩과 대비되는 모놀리틱(monolithic) 블록체인의 특징을 서술하고 있습니다. 인풋(예: 블록)은 모든 네트워크 밸리데이터에 의해 하나씩 처리되는 방식입니다.
만약 이러한 시스템에서 L1이 더 많은 L2를 호스팅하고자 한다면, 모든 밸리데이터들은 모든 L2의 작업을 재실행해야 합니다. 당연히 이러한 시스템에서 확장성을 기대할 수 없습니다. 이 문제를 우회하기 위한 방법으로 옵티미스틱(Optimistic) 롤업이 있는데, 재실행(일명 사기 증명, fraud proof)하는 상황이 누군가가 사기가 발생했다고 주장했을 경우에만 발생하도록 하는 것입니다. SNARK-기반 롤업은 SNARK 증거를 생성하는 것보다 검증하는 비용이 현저히 저렴하다는 사실에 기반하여, 모든 밸리데이터들이 SNARK 증거를 검증할 수 있도록 허용합니다. 더 자세한 내용은 부록의 Scalability Space Map을 참고해 주시기 바랍니다.
샤딩의 단순한 해결책은 밸리데이터 집단을 더 작은 하위 집단(subset)으로 나눈 뒤, 이 작은 하위집단이 L2 블록을 재실행하는 것입니다. 이 접근법에는 어떤 문제가 있을까요? 바로 네트워크의 실행 및 경제적 보안을 샤딩하고 있다는 것입니다. L2의 보안은 L1에 비해 이미 취약한데, 밸리데이터 집단을 더 많은 샤드로 조각낼수록 보안성은 더 약해질 수밖에 없습니다.
매번 트랜잭션을 재실행할 수 없는 옵티미스틱 롤업과는 달리, 폴카닷은 트랜잭션을 샤딩하도록 고안되었습니다. 이는 밸리데이터의 하위 집단들이 L2 블록을 재실행할 수 있도록 만들며, 모든 네트워크 참여자에게 L2 블록의 진실성이 마치 전체 밸리데이터 집단이 블록을 재실행한 것만큼 안전하다는 암호경제학적 증거를 제공합니다. 이는 최근에 공식 발표된 ELVES 메커니즘을 통해 가능합니다.
ELVES는 "시니컬 롤업(Cynical Rollup)" 메커니즘이라고도 볼 수 있습니다. 밸리데이터들이 다른 밸리데이터들에게 L2 블록의 유효성을 확인받는 과정을 몇 차례 반복하면서, L2 블록이 실제로도 유효할 가능성이 높다고 확인할 수 있는 것입니다. 분쟁이 발생하는 경우에 단시간 내 전체 밸리데이터 집단이 참여 요청을 받게 되며, 이 내용은 폴카닷의 공동 창업자인 롭 하버마이어(Rob Habermeier)의 글에 잘 설명되어 있습니다.
폴카닷이 일반적으로 상호 배타적(mutually exclusive)인 것으로 취급되는 “샤딩된 실행”과 “공유된 보안” 두 가지 특성을 모두 지닐 수 있는 것도 ELVES 메커니즘 덕분이며, 이것이 확장성에 있어서 폴카닷 1.0이 남긴 주된 기술적 성과이기도 합니다.
이제 “코어" 비유로 넘어가겠습니다.
실행 샤드(execution-sharded) 블록체인은 CPU에 비유할 수 있습니다. CPU가 병렬적으로 명령을 처리할 수 있는 다수의 코어를 지니고 있듯이, 폴카닷도 병렬적으로 L2 블록을 처리할 수 있습니다. 그러한 이유로 폴카닷에서 L2를 파라체인(parachain)[1], 밸리데이터의 하위 집단이 단일 L2 블록을 실행하는 환경을 "코어”라고 칭합니다. 개별 코어는 “협업하는 밸리데이터 집단”이라고 요약될 수 있습니다.
모놀리틱 블록체인이 어느 타임 슬롯에서든 단일 블록만 처리할 수 있다면, 폴카닷은 코어 및 타임 슬롯 당 각각 하나의 릴레이 체인 블록과 파라체인 블록을 처리할 수 있습니다.
3.1. 이종성
지금까지 확장성과 폴카닷의 샤딩된 실행에 대해서만 이야기했으며, 한 가지 중요한 사실은 폴카닷의 각각의 샤드가 완전 별개의 애플리케이션이라는 점입니다[2]. 이는 바이트코드로 저장되는 메타 프로토콜을 사용함으로써 구현되었으며, 메타 프로토콜이란 블록체인의 정의가 바이트코드의 형태로 블록체인 상태에 저장되는 프로토콜입니다. 폴카닷 1.0에서는 WASM이 바이트코드로 사용되었고, JAM에서는 PVM/RISC-V가 채택되었습니다.
결론적으로, 이것이 폴카닷이 이종 샤딩 블록체인(heterogeneous sharded blockchain)으로 불리는 이유입니다. 각각의 L2는 서로 완전히 다른 별개의 애플리케이션이라고 할 수 있습니다.
4. 폴카닷 2.0
폴카닷 2.0에서 강조하는 부분은 코어를 더 유연하게 사용할 수 있도록 만드는 것입니다. 기존의 폴카닷 모델에서는 한 코어를 한 번에 6개월에서 최대 2년까지 임대할 수 있었습니다. 이는 가용 자원이 많은 비즈니스의 경우 적합한 모델이지만, 소규모 팀들에게는 그렇지 않습니다. 폴카닷의 코어를 더 유연하게 사용할 수 있도록 한 기능은 "애자일 코어타임(agile coretime)"라고 불리며, 애자일 코어타임에서는 폴카닷의 코어를 한 번에 한 블록부터 최대 한 달까지 대여할 수 있으며, 장기 임대를 원할 경우 상한 가격(price cap)도 보장됩니다.
현시점 폴카닷 2.0은 다른 기능들과 함께 진행 중이므로, 여기서는 추가 설명을 생략하겠습니다.
5. 코어 내부 vs. 온체인
JAM(Polkadot 3.0)을 이해하려면, L2 블록이 진입했을 때 폴카닷 코어에서 무슨 일이 벌어지는지 이해해야 합니다.
다음은 많이 단순화된 내용을 포함하고 있습니다.
코어는 기본적으로 밸리데이터 집단으로 구성됩니다. “데이터를 코어로 보냈다”는 것은 데이터가 밸리데이터 집단에 전달되었다는 것을 의미합니다.
0.하나의 L2 블록과 해당 L2 상태의 하위 집단이 코어로 전송됩니다. 이것이 L2 블록을 처리하는 데 필요한 유일한 데이터입니다[3].
1.코어를 구성하는 밸리데이터의 하위 집단이 L2 블록을 재실행하며, 합의와 관련된 작업을 진행합니다.
2.코어 밸리데이터들은 (코어 외부에 있는) 다른 밸리데이터들이 재실행에 필요한 데이터들을 사용할 수 있도록 합니다. ELVES 규칙에 따라 더 많은 밸리데이터들이 L2 블록을 재실행하고자 할 수 있는데, 이때 이 데이터가 필요합니다.
모든 작업은 폴카닷의 메인 블록과 상태 변경 함수와 별개로 외부에서 이루어진다는 점을 기억해야 합니다. 지금까지 설명한 모든 과정은 코어와 데이터 가용성 레이어 내부에서 발생합니다.
3.L2가 전송한 최신 상태가 폴카닷 릴레이 체인 상태에 저장됩니다. 이 작업은 L2 블록을 재실행하는 것보다 훨씬 저렴하며, 메인 폴카닷 상태에 영향을 미치고, 폴카닷 블록에도 기록되며, 모든 폴카닷 밸리데이터들에 의해 처리됩니다.
앞서 설명한 내용에 더해, 폴카닷이 수행하는 작업에 대해 좀 더 알아보겠습니다:
1번에서 폴카닷에는 일반적인 블록체인 상태 전환 함수와는 다른 처리 방식이 존재함을 알 수 있었습니다. 일반적으로 네트워크의 모든 밸리데이터들이 작업을 실행하면 그 결과로 메인 블록체인 상태가 업데이트되며, 이를 온체인 작업(on-chain operation)이라고 부릅니다. 이 작업이 3번에 해당합니다. 하지만 코어 내부(1번)에서 발생하는 일들은 다릅니다. 이 새로운 블록체인 연산 방식을 인코어 처리(in-core execution) 라고 부릅니다.
2번에서 유추할 수 있는 사실은, 폴카닷이 이미 네이티브 데이터 가용성 레이어(DA)를 제공하며, L2는 DA를 처리 증거로서 자동으로 일정 시간 동안 사용한다는 것입니다. 그리고 이 DA[4] 레이어에 올라갈 수 있는 데이터는 고정되어 있으며, 이 데이터는 L2 블록을 재실행하기 위해 항상 필요한 증거입니다. 또한 파라체인의 코드는 DA 레이어에서 데이터를 읽어올 수 없습니다.
위 내용은 JAM의 기능을 이해하는 데 근간이 됩니다. 요약하자면 다음과 같습니다.
- 인코어 처리: 코어 내부에서 발생합니다. 풍부한 자원(abundance)과 확장 가능성을 가지며, 암호 경제학과 ELVES를 기반으로 “온체인 처리”만큼의 안전성을 가집니다.
- 온체인 처리: 밸리데이터의 작업입니다. 경제적 유인을 지닌 밸리데이터들에 의해 보안이 유지되며, 모두가 모든 것을 처리하기 때문에 더 비싸고 제한적입니다.
- 데이터 가용성: 폴카닷 밸리데이터들이 일정 기간 사용 가능한 데이터를 다른 밸리데이터들에게 제공하는 것입니다.
6. JAM(Polkadot 3.0)
앞서 설명한 내용을 이해했다면 JAM의 개념이 더욱 쉽게 와닿을 것입니다.
JAM은 폴카닷에 크게 영향을 받았고, 폴카닷과 완전히 호환 가능하며, 폴카닷의 릴레이 체인을 대체하고 코어의 사용을 근본적으로 비편향적(un-opinionated[5])으로 만들려는 새로운 프로토콜입니다.
JAM은 폴카닷 2.0을 기반으로 합니다. 폴카닷 코어의 사용성을 애자일 코어타임보다 근본적으로 유연하고 비편향적인 방식으로 높이고자 합니다.
- 폴카닷 2.0에서는 L2의 코어 배포가 더 유동적입니다.
- JAM의 핵심은 폴카닷 코어에 블록체인/L2의 형식에 국한되지 않은 어떤 애플리케이션이든 배포할 수 있다는 점입니다.
이것이 가능한 주된 이유는 이전 섹션에서 설명했던 세 가지 요소, 즉 인코어 및 온체인 처리, 그리고 데이터 가용성을 개발자들에게 제공하기 때문입니다.
다시 말하자면 JAM은 개발자들에게 다음과 같은 기능을 제공합니다.
- 인코어와 온체인에서 이루어지는 작업을 프로그래밍할 수 있습니다.
- 폴카닷 DA 레이어에서 임의의 데이터를 읽고 입력할 수 있습니다.
이상으로 JAM이 추구하는 방향의 기본적인 내용을 살펴보았습니다. 물론 많은 부분이 단순화되었으며, 프로토콜은 계속 발전 중에 있습니다.
여기까지의 설명을 기반으로 JAM의 내용을 더 세부적으로 살펴보겠습니다.
6.1. 서비스와 작업 아이템
JAM의 시스템에서는 L2/Parachain라고 불리던 것이 서비스(Service)로, 그리고 블록/트랜잭션은 작업 아이템(Work-Item) 또는 작업 패키지(Work-Package)로 불리게 됩니다. 부연하자면 작업 아이템은 서비스에 속하며, 작업 패키지는 작업 아이템의 그룹을 칭합니다. 두 단어 모두 블록체인/L2에 국한되지 않는 활용 사례를 포함할 수 있도록 일반적인 용어로 선택되었습니다.
서비스는 세 개의 엔트리 포인트로 설명될 수 있는데, 그중 두 가지는 fn refine()과 fn accumulate()[6]입니다. 전자는 인코어 서비스가 하는 일을 설명하고, 후자는 온체인에서 서비스가 하는 일을 설명합니다.
마지막으로 두 엔트리 포인트의 명칭이 프로토콜의 이름 JAM(Join Accumulate Machine)과 관련이 있습니다. Join은 fn refine()으로, 모든 폴카닷 코어가 병렬적으로 다양한 서비스들을 위해 많은 작업을 수행하는 것입니다. Join에서는 데이터가 더 작은 서브셋으로 정제되어 다음 단계로 전달됩니다. Accumulate는 앞서 언급한 과정의 결과가 메인 JAM 상태로 모이는 것으로, 이는 온체인 실행에 해당하는 부분입니다.
6.2. 준일관성
폴카닷 파라체인 간 커뮤니케이션의 언어인 XCM에 관련된 기존 자료에 따르면, 모든 커뮤니케이션은 비동기적입니다. 즉, 메시지가 전송된 후 응답을 위해 대기하지 않는 것입니다.
비동기성(Asynchrony)은 비일관적(incoherent) 시스템의 특성이자, 폴카닷 1.0, 폴카닷 2.0 그리고 이더리움의 기존 L2 집단과 같이 영구적으로 샤딩이 구현된 시스템의 대표적인 문제점입니다.
하지만 그레이페이퍼의 섹션 2.4에서 설명되었듯, 모든 구성원을 대상으로 한 항상 동기적이고 완전히 일관된 시스템은 일반성(generality), 접근성(accessibility), 회복탄력성(resilience)을 희생하지 않고서는 성장하기 어렵습니다.
이것이 바로 JAM의 강점이 돋보이는 또 하나의 영역입니다. JAM은 다양한 특성(property)을 도입함으로써 준일관성 시스템(semi-coherent system)이라는 참신한 균형점을 찾았습니다. 즉, 자주 소통을 하는 다양한 서브시스템들 간에는 일관된 환경을 조성할 기회가 주어지지만, 시스템 전체에 이를 강요하지는 않는 것입니다. 해당 내용은 그레이페이퍼의 저자인 개빈 우드 박사의 인터뷰에서 자세하게 조명됩니다.
또 다른 관점은 폴카닷, 그리고 JAM을 샤드 간의 경계가 유동적이고 매 순간 결정되는 샤딩 시스템으로 보는 것입니다.
폴카닷은 항상 샤딩된, 그리고 완전히 이종적인 블록체인이었습니다.이제는 샤딩과 이종성에 더불어 @gavofyork가 https://t.co/tjAboJL9IA 에서 준일관적 시스템이라고 칭했던, 샤딩의 경계가 유동적으로 결정되는 블록체인이 될 것입니다.
— Kian Paimani (@kianenigma) May 15, 2024
이를 가능하게 하는 특징들은 다음과 같습니다:
- 특정 블록에서 동일한 코어에 있는 서비스들만 동기적으로 상호작용할 수 있는 무상태(state-less) 및 병렬 인코어 실행(parallel in-core execution), 그리고 한 서비스가 전체 코어에 걸쳐 존재하는 모든 서비스들의 결과에 접근할 수 있는 온체인 실행에 대한 접근을 제공합니다.
- JAM은 특정 서비스 스케줄링을 강제하지 않습니다. 자주 소통하는 서비스들은 시퀀서들이 자주 소통하는 서비스의 작업 아이템을 포함하는 작업 패키지를 생성하도록 경제적인 유인을 제시할 수 있습니다. 이들은 동일한 코어에 존재하면서 동기적인 환경에 있는 것과 마찬가지로 소통할 수 있습니다.
- JAM 서비스는 DA 레이어에 접근할 수 있으며, 이를 일시적이지만 굉장히 저렴한 데이터 레이어로 활용할 수도 있습니다. 데이터가 일단 DA에 전송되면 즉시 모든 코어에 전파되며, 동일한 코어에서 즉시 이용 가능해집니다. 이에 따라 JAM 서비스들은 순차적인 블록[7]의 동일한 코어에서 자체 스케줄링을 통해 데이터에 대한 높은 접근성을 누릴 수 있습니다.
상기 내용은 JAM에서 가능한 기능이지만, 프로토콜 레이어에서 강제되지는 않음을 기억할 필요가 있습니다. 일부 인터페이스들은 이론적으로 비동기적이나, 실제로는 정교한 추상화와 인센티브를 통해 동기적으로 동작할 수 있을 수 있습니다. 이를 보여주는 예시가 다음 섹션에서 설명할 코어플레이(CorePlay)입니다.
6.3. 코어플레이
이 섹션에서는 JAM의 실험적 아이디어인 코어플레이에 대해 설명합니다. 코어플레이는 스마트 컨트랙트를 프로그래밍하는 새로운 모델로, 글 작성 시점에는 명확하게 규정되지 않았으며[8], 아직 아이디어 단계에 있습니다.
코어플레이를 이해하기 위해서는 우선 JAM의 가상머신인 PVM을 살펴볼 필요가 있습니다.
6.3.1. PVM
PVM은 JAM과 코어플레이의 중요한 요소입니다. PVM의 세부적이고 기술적인 설명은 해당 분야 전문가가 작성한 그레이페이퍼에 잘 설명되어 있으며, 이 글에서는 PVM의 몇 가지 특징만 설명하겠습니다:
- 효율적인 자원 사용량 측정
- 실행 중단 및 재개 기능
특히 후자는 코어플레이에 중요한 기능입니다.
코어플레이는 JAM의 유동적인 프리미티브를 사용하여 프로그래밍 인터페이스를 지닌 확장 가능한 스마트 컨트랙트 환경을 만든 사례입니다. 코어플레이는 JAM 코어에 행위자 중심 스마트 컨트랙트를 직접 배포하여 동기적인 프로그래밍 인터페이스를 가능하게 하는 방식을 제안합니다. 일반적인 fn main()로 코딩을 하고, let _result = other_coreplay_actor(data).await?을 사용하여 소통하는 것입니다. 만약 other_coreplay_actor가 해당 JAM 블록의 동일한 코어에 있다면, 이 호출은 동기적이며, 다른 코어에 있는 경우 행위자는 중단하고 이후의 JAM 블록에서 재개합니다. 이것이 가능한 이유는 JAM의 서비스와 유연한 스케줄링, 그리고 PVM의 특성들 덕분입니다.
6.4. 코어체인 서비스
마지막으로 JAM이 폴카닷과 완전히 호환된다고 언급한 이유를 다시 짚어보며 글을 마치겠습니다. 폴카닷의 메인 프로덕트인 애자일 코어타임 방식의 파라체인은 JAM에서도 유지됩니다.
JAM에 배포될 최초의 서비스는 코어체인(CoreChain)이나 파라체인이라고 불리는 것들이 될 것입니다. 폴카닷 2.0 스타일의 파라체인들이 JAM에서 실행될 수 있도록 하는 서비스입니다.
더 많은 서비스들이 JAM에 배포될 수 있으며, 기존의 코어체인 서비스도 이들과 소통할 수 있지만, 폴카닷이 기존에 제공하던 기능도 여전히 중요하게 취급될 것이며, 기존 파라체인 팀들에게도 새로운 기회들이 열릴 것입니다.
부록: 데이터 샤딩
이 글의 대부분은 샤딩된 실행의 관점에서 확장성을 논의했지만, 데이터 관점에서도 논의가 가능합니다. 흥미롭게도, 준일관성에서 언급된 것과 유사한 상황에 직면하게 됩니다. 완전히 일관적인 시스템은 원칙적으로는 더 나을 수 있지만 확장이 어렵습니다. 완전히 비일관적인 시스템은 확장이 가능하지만 이상적이지 않습니다. 준일관성을 표방하는 JAM은 새로운 가능성을 제시합니다.
완전히 일관적인 시스템: 솔라나와 같은 완전히 동기적인 스마트 컨트랙트 플랫폼이나, 이더리움 L1에만 배포하는 용감한 플랫폼에서 볼 수 있습니다. 모든 애플리케이션 데이터는 체인 상에 저장되어 다른 모든 애플리케이션에서 쉽게 접근할 수 있습니다. 프로그램 가능성에 있어서는 완벽한 특성이지만 확장성은 없습니다.
비일관적인 시스템: 애플리케이션 데이터는 L1 외부에 있는 각각 다른 샤드에 저장됩니다. 굉장히 확장성이 높지만 상호호환성(composability) 측면에서는 좋지 않습니다. 폴카닷과 이더리움 롤업 모델이 이에 해당됩니다.
JAM은 위의 두 가지를 전부 제공하면서, 프로그래머들이 온체인과 오프체인 데이터의 중간 지대라고 볼 수 있는 JAM DA 레이어에 임의의 데이터를 게시할 수 있도록 합니다. 이를 통해 애플리케이션 데이터의 대부분은 DA 레이어를 이용하고, JAM 상태에는 완전히 중요한 정보만 포함시킴으로써 완전히 새로운 유형의 애플리케이션을 구축할 수 있습니다.
부록: Scalability Space Map
이 부분에서는 블록체인 확장성에 대한 견해를 다시 설명합니다. 그레이페이퍼에도 설명되어 있는 내용의 더 간결한 버전입니다.
블록체인에서 확장성은 대부분 전통적인 분산 시스템에 사용된 접근 방식, 즉 스케일 업(수직적) 및 스케일 아웃(수평적)을 따릅니다.
솔라나와 같은 플랫폼은 스케일 업에 해당합니다. 코드와 하드웨어를 최적화하여 최대 처리량을 달성하는 방식입니다.
이더리움과 폴카닷은 스케일 아웃에 해당합니다. 즉, 모두가 수행해야 할 작업량을 줄이는 것입니다. 전통적인 분산 시스템에서는 더 많은 복제된 기계를 추가함으로써 이를 달성합니다. 블록체인에서는 "연산 기계(computation machine)"가 전체 밸리데이터 집단입니다. 이들을 나누어 작업을 분할하거나(ELVES 방식) 그들의 의무를 경감시켜(옵티미스틱 롤업 방식) 전체 밸리데이터 집단의 작업 부하를 줄이고, 그 결과 시스템을 수평적으로 확장시킬 수 있습니다.
요약하자면 아래와 같습니다.
- 스케일 업: 강력한 하드웨어를 기반으로 최적화를 수행하는 모놀리틱 블록체인의 방식
- 스케일 아웃:
- 옵티미스틱 롤업
- SNARK-기반 롤업
- ELVES: 폴카닷의 시니컬 롤업
부록: 같은 하드웨어, 커널 업데이트
이 부분에서는 Sub0 2023: Polkadot: Kernel/Userland | Sub0 2023 - YouTube에서 롭 하버마이어의 발표를 기반으로, 폴카닷의 업그레이드로서 JAM이 어떻게 같은 하드웨어에 이루어지는 커널 업데이트로 비유될 수 있는지를 설명합니다.
일반적인 컴퓨터에서는 전체 시스템 스택을 다음과 같은 세 가지로 구분할 수 있습니다.
- 하드웨어
- 커널
- 유저 공간
앞서 설명했듯, 폴카닷에서는 코어가 연산과 데이터 가용성을 제공하는 핵심 주체인 하드웨어 역할을 합니다.
폴카닷의 커널은 실질적으로[9] 다음의 두 가지로 구성되어 있습니다.
- 파라체인 프로토콜: 코어를 사용하는 경직적이고 의견이 명확한 방식.
- DOT 토큰, 전송 기능, 스테이킹, 거버넌스 등 일련의 로우레벨 기능 집합.
이 두 가지는 현재 폴카닷 릴레이 체인에 존재합니다.
유저 공간 애플리케이션은 파라체인들과 그들의 네이티브 토큰, 그리고 그 위에 구축된 모든 것들을 지칭합니다.
이는 다음과 같이 시각화할 수 있습니다.
폴카닷은 항상 핵심 기능들을 1등급 유저들인 파라체인으로 옮기고자 했습니다. 미니멀 릴레이 RFC(Minimal Relay RFC)의 목적도 이와 같습니다.
이는 폴카닷 릴레이 체인이 오직 파라체인에 프로토콜을 제공하는 데만 초점을 맞추기 때문에 커널 공간이 어느 정도 감소됨을 의미합니다.
해당 아키텍처가 구현되면 JAM으로의 마이그레이션이 어떤 모습일지 쉽게 상상할 수 있습니다. JAM은 폴카닷의 커널 공간을 대폭 줄이고, 보다 광범위하게 활용할 수 있게 만들 것입니다. 또한, 파라체인 프로토콜이 유저 공간으로 이동하는데, 이는 동일한 코어(하드웨어)와 JAM(커널) 상에서 애플리케이션을 작성할 수 있는 몇 안 되는 방법 중 하나이기 때문입니다.
다시 말해, JAM 마이그레이션은 커널 업그레이드로 볼 수 있습니다. 기본 하드웨어는 그대로 유지되며, 기존 커널의 많은 부분이 간소화를 위해 유저공간으로 이동하는 것입니다.
참고자료
Parallel Chain. ↩︎
블록체인 또는 상태 전환 함수. ↩︎
폴카닷 1.0에서는 L2의 상태 증명을 PoV (Proof of Validity), 그리고 상태 증명과 파라체인 블록의 조합을 PVF (Parachain Validation Function)라 칭했다. ↩︎
그레이페이퍼에서는 DA 레이어를 분산 데이터 레이크(Distributed Data Lake, DDL)라고 칭한다. 본 글에서는 편의를 위해 DA, 또는 DA 레이어로 표현한다. ↩︎
JAM은 폴카닷의 릴레이 체인만을 대체한다는 사실이 중요하다. 파라체인을 비롯하여 폴카닷 위에서 동작하는 모든 애플리케이션은 코어체인 덕분에 그대로 유지된다. ↩︎
세 번째는 on_message로, 다른 서비스에서 메시지가 올 때 호출된다. ↩︎
서비스 스케줄링에 대한 자세하 내용은 그레이페이퍼의 "Authorization" 섹션을 참고하라. ↩︎
"사실상"이라는 말이 중요하다. 언급했던 영상에서도 롭은 파라체인 프로토콜을 폴카닷의 유저 공간 애플리케이션이라 칭했다. 하지만 이는 이론적인 가정일 뿐, 파라체인 프로토콜은 코어 폴카닷 프로토콜, 즉 커널 자체에 통합되어 있다. ↩︎