[이더리움2.0 깊이보기 시리즈] ETH 2.0 Explained: Phase 2[8편]

Published in

Tokamak Network

17 min readJan 21, 2020

이더리움2.0 깊이보기 시리즈는 개발이 진행되고 있는 이더리움2.0에 관한 스펙과 작동원리에 대해서 이해의 저변을 넓히고자 하는 목적으로 온더에서 기획되었습니다. 연재는 다음 순서로 이어집니다.

[1편] — ETH 2.0 Explained: Phase 0
[2편] — Cross Shard Communication -1- 비동기 커뮤니케이션
[3편] — Cross Shard Communication -2- 동기 커뮤니케이션
[4편] — CBC casper explained (1/2)
[5편] — CBC casper explained (2/2)
[6편] — ETH 2.0 Explained: Phase 1
[7편] — 스태이트리스 클라이언트(Stateless Client)
[8편] — ETH 2.0 Explained: Phase 2
[9편] — Execution Environment

출처: https://media.consensys.net/the-roadmap-to-serenity-bc25d5807268

Overview

Phase 2에서 중점을 두는 것은 샤드 체인의 상태 및 상태 실행을 정의하는 것입니다. 샤드 체인에서 상태 및 상태 실행을 처리하게 되며 다양한 스마트 컨트랙트가 작동할 수 있게 됩니다. 즉, Phase 2 구현이 완료되면 이더리움 2.0의 샤드 체인 위에서 이더리움 1.0에 배포된 스마트 컨트랙트를 작동할 수 있게 된다는 것입니다.

Phase 1 and Phase 2

Phase 1과 비교해서 설명하자면, Phase 1은 비컨 체인에 의해 검증될 여러 개의 샤드 체인을 도입하는 단계입니다. Phase 1에서 중점을 두는 것은 각 샤드의 데이터에 대한 검증방식 구현입니다. 데이터의 검증 방식에 집중하기 때문에 샤드 체인에는 의미없는 임의의 데이터만 저장될 뿐 상태 실행을 처리하지 않습니다.

Phase 2에서 중점을 두는 것은 샤드 체인의 상태 및 상태 실행을 정의하는 것입니다. 샤드 체인에서 상태 및 상태 실행을 처리하게 되며 다양한 스마트 컨트랙트가 작동할 수 있게 됩니다. Phase 1에서 샤드 체인의 데이터는 의미없는 데이터 조각이었다면 Phase 2에서 샤드 체인의 데이터는 상태가 되고 상태 실행 엔진(eWASM)에 의하여 연산되어 변경됩니다.

Phase 1에서 샤드 체인은 단순한 데이터를 제공하는 역할이기 때문에 실제 사용할 수 있다기 보다는 이더리움 2.0 구현에 기반이 되는 기술에 대한 테스트에 가깝다고 볼 수 있습니다. 하지만 Phase 2 구현이 완료되면 기존 이더리움 1.0의 스마트 컨트랙트 환경을 구성하고 truffle, web3.js 등의 도구도 사용할 수 있을 것입니다. 따라서 이더리움 2.0 체인에서 스마트 컨트랙트과 같은 복잡한 연산이 가능해질 것입니다.

Phase 2 Implementation

Phase 2의 목적은 위에 말씀드렸듯이 각 샤드 체인에 구조화된 데이터, 즉 상태를 갖게 하고 상태 실행을 구현하는 것입니다. 이를 위해 Phase 2에서는 실행환경(Execution Enviornment)라는 개념을 제시합니다.

실행 환경이란 상태 및 상태 실행을 정의한 것입니다. 이더리움 1.0을 예를 들어 설명해보면 이더리움 1.0은 계정 기반(Account Based)의 상태를 가지고 있습니다. 한편 거래 타입은 단순 이더 전송 및 컨트랙트 함수 호출로 정의되어 있습니다. 이러한 상태는 거래에 따라 가상 머신(EVM) 연산을 통해 변경 및 저장됩니다. 이 전체를 통틀어 이더리움 1.0의 실행 환경이라 할 수 있습니다.

- Ethereum 1.0 Simple Architecture Diagram (출처: Crosslink 2019 Taiwan) –

기존 이더리움 1.0의 실행 환경은 위 다이어그램과 같이 하나밖에 가질 수 없습니다. 컨센서스 레이어(Fork Choice Rule, POW 등)와 상태 실행 레이어가 결합되어 있기 때문입니다. 만약 상태 실행 레이어에 보안상 문제가 생기거나 변경(eg. opcode 추가 또는 gas cost 변경등)하고자 한다면 커뮤니티의 의견을 모아 하드포크를 해야 하는 부담이 있습니다.

– Ethereum 2.0 Simple Architecture Diagram (출처: Crosslink 2019 Taiwan)

반면 이더리움 2.0 Phase 2에서는 컨센서스 레이어와 상태 실행 레이어를 분리하여 구현하게 됩니다. 컨센서스 레이어(Casper FFG, Shuffled Validator committe 등)를 기반으로 여러 상태 실행 레이어(실행 환경)를 구현할 수 있도록 하였습니다. 이는 기존의 이더리움 1.0의 컨트랙트 환경 뿐만 아니라 다양한 실행 환경을 구성할 수 있게 하여 보다 개선된 모델 또는 기존과는 다른 혁신적인 모델을 구현할 수 있는 가능성을 열어 둔 것이라고 할 수 있습니다.

– Ethereum 2.0 architecture (출처: Crosslink 2019 Taiwan) –

Phase 2 구현은 크게 보면 Stateless Client 모델위에서 어떻게 실행 환경을 구현할 것인가 라는 것에 초점이 맞춰 있습니다. Stateless Client 모델이란 간단히 말해 블록 검증자나 네트워크의 사용자는 상태를 저장하지 않는 모델입니다. 다른 역할군이 상태를 저장하고 제공합니다. Stateless Client 모델은 샤드 체인을 운영하기 위한 필수적인 모델이라고 할 수 있습니다.

따라서 Phase 2를 이해하기 위해선 먼저 핵심 개념이라 할 수 있는 실행 환경(Execution Enviornment) 과 Stateless Client를 이해해야 합니다.

Execution Environments

출처: https://medium.com/@william.j.villanueva/a-journey-through-phase-2-of-ethereum-2-0-c7a2397a36cb

실행 환경은 비컨 체인의 컨트랙트 형태로 배포되며 상태 및 상태 실행에 관해 정의합니다. 또한 거래 타입, 서명 방식, accumulator(accumulator는 일정한 크기의 압축된 루트값을 산출하는 자료구조 방식이라 할 수 있습니다. 예를 들어 머클트리는 accumulator의 한 종류라고 볼 수 있습니다.) 등 그 외 실행 환경들을 정의합니다.

실행 환경을 정의하는 컨트랙트는 특별한 컨트랙트라고 볼 수 있습니다. 기존 이더리움 1.0에 배포된 컨트랙트와는 의미가 다릅니다. 실행 환경 컨트랙트는 기존 이더리움 1.0에 있는 프리 컴파일 컨트랙트와 의미가 가깝다고 볼 수 있습니다.

이러한 실행 환경은 위에 설명드렸듯이 개발자가 원하는 대로 구성할 수 있습니다. 따라서 개발자는 기존 이더리움 1.0 방식의 실행 환경 뿐만 아니라 비트코인의 UTXO 방식의 실행 환경을 구성할 수도 있고 페이스북의 Libra 방식의 실행 환경을 구성할 수도 있습니다. 아니면 기존 방식과 전혀 다른 새로운 실행 환경 모델을 구성할 수도 있습니다.

한편 샤드 체인은 여러개의 실행 환경을 가질 수 있습니다. 예를 들면 하나의 샤드체인에서 이더리움 1.0 방식과 비트코인의 UTXO 방식의 실행 환경을 동시에 가질 수 있습니다. 반대로 동일한 실행 환경이 여러 개의 샤드 체인에 생길 수 있습니다. 알아두어야 할 것은 비컨 체인에서 상태 실행에 대해 정의하고 샤드 체인에는 상태 데이터만 갖고 있을 뿐이라는 것입니다.

이러한 상태 환경은 Stateless Client 모델 위에 구현되어야 합니다. 위에 간략히 설명했듯이 Stateless Client 모델은 샤드 체인을 운영하기 위해 필요한 것이고 블록 검증자나 네트워크의 사용자는 상태를 저장하지 않는다고 했습니다. 그렇다면 여기서 당연히 드는 의문은 “Stateless Client 모델이 왜 샤드 체인에 필요한가? 또는 상태를 저장하지 않고 어떻게 블록체인의 탈중앙성을 유지할 수 있을까?” 일 것입니다.

다음 섹션에서는 Stateless Client 모델이 무엇이고 왜 이더리움 2.0에서 왜 필요한지 살펴보도록 하겠습니다.

Needs for Stateless Client

출처: https://medium.com/@akhounov/data-from-the-ethereum-stateless-prototype-8c69479c8abc

현재 이더리움 1.0에서는 거래를 실행하기 위해서는 모든 상태를 저장하고 있어야 합니다. 이 방법은 기존 이더리움 1.0 에서는 병목현상이 있긴 하지만 가능한 방법입니다. 하지만 이더리움 2.0에서는 실질적으로 불가능하다고 할 수 있습니다.

이더리움 2.0의 샤드 체인 검증 과정을 보면 각 샤드의 검증자(블록 제공자 포함)는 일정 기간 후에 무작위로 다른 샤드 체인을 배정받습니다. 검증자들은체인을 배정받을 때마다 거래를 실행하기 위해 그 체인의 상태를 다운로드해야 합니다. 하지만 이더리움 2.0에서 이 방법은 실용적이지 않습니다. 다음 배정을 받을 시간(합리적인 시간을 정한다면)동안 샤드 체인의 상태를 저장하는 것은 실질적으로 불가능합니다. 만약 검증자들이 모든 샤드 체인의 상태를 가지고 있는 슈퍼 풀노드라면 이 방법도 가능하겠지만 그건 사실상 의미가 없습니다. 모든 검증자들이 슈퍼 풀노드가 된다면 기존 하나의 체인에 블록 사이즈 및 데이터 저장 용량을 늘린 것과 다름 없습니다. 컴퓨팅 자원이 많이 필요해짐에 따라 검증자들의 중앙화 문제가 생길 수 있을 것입니다.

Stateless Client는 이와 같은 거래 실행에 따른 부담을 줄이기 위해 검증자는 상태를 저장하지 않고 블록에 머클 루트해쉬값만 저장하는 것입니다. 샤드 체인의 상태는 각 샤드 체인마다 특정 역할군(State Provider; 상태 제공자)이 저장하게 됩니다. 검증자는 머클 루트 해쉬값을 연산하여 저장하는 데 이 때 필요한 정보가 witness입니다. 따라서 거래 전송시 witness를 함께 검증자에게 보냅니다. witness란 거래와 관련 있는 계정의 머클 브랜치와 그에 해당하는 데이터 베이스 정보입니다.

사용자는 거래 전송시 상태 제공자에게 witness를 제공받아 검증자(블록 제공자)에게 보냅니다. 블록 제공자는 연산하여 머클 루트 해쉬값(상태 루트)를 블록에 저장합니다. 기존 방법과는 달리 Stateless Client 모델에서는 샤드 체인의 검증자가 샤드 체인을 새로 배정받아도 상태를 다시 받지 않고 검증에 참여할 수 있습니다. 따라서 Stateless Client 모델에서는 무작위로 검증자들이 배치되어도 원활한 검증 작업을 수행할 수 있을 것입니다. 실행환경은 이 Stateless Client 모델 위에서 구현되어야 합니다.

Implement Execution Enviornments

Phase 2 구현을 위해선 다양한 실행 환경을 Stateless Client 모델 위에 구현하고 테스트 및 벤치마킹 하는 과정을 거쳐야 합니다. Scout은 eWASM 가상머신 구현체로 실행 환경 테스트 및 벤치마킹을 하기위한 상태 실행 엔진입니다.

Scout은 우선 실행 환경 모델을 테스트 및 벤치마킹하기 위해 만들었지만 향후 이더리움 2.0 가상머신의 역할을 하도록 확장될 것입니다.

Eth 1 -> Eth 2 Switchover

Phase 2에서 가장 중요한 구현 중 하나는 이더리움 2.0에 이더리움 1.0 실행환경을 옮기는 것입니다. 이를 위해 이더리움 2.0의 실행환경 모델로서 이더리움 1.0 실행환경을 정의해야 합니다. 제일 큰 이슈는 이더리움 1.0의 실행 환경을 Stateless Client 모델안에서 구현하는 것이고 계정 기반 상태 및 EVM을 정의해야 한다는 것입니다. 아직 디자인에 대한 논의가 진행중이라고 볼 수 있습니다.

Relayer Market

출처 : https://ethresear.ch/t/state-providers-relayers-bring-back-the-mempool/5647

Stateless Client 모델에 대한 초기 논의는 중계자(Relayer)라는 역할군을 두어 일반 사용자들이 거래를 중계자에게 보내도록 하자는 것이었습니다. 중계자들은 상태 데이터를 저장하고 있어 전송받은 거래에 대한 witness를 생성할 수 있습니다. 중계자는 사용자에게 일정 수수료를 받아 witness를 거래에 추가합니다.(사용자와 중계자 간에 어떤 식으로 수수료를 주고 받을 지에 대한 논의는 구체적으로 이루어 지진 않았습니다. 사용자와 중계자 간의 거래는 프로토콜에 정의된 거래가 아니며 오프체인에서 이뤄지게 될 것입니다. 현재 State Channel을 통한 방법을 논의 중입니다.) 그 다음 사용자들로부터 받은 거래를 함께 묶어서 프로토콜에 정의된 수수료를 내고(이 과정은 온체인에서 이뤄집니다.) 블록 검증자(블록 제출자)에게 보내자는 것이었습니다.

이 모델에서 중요한 이슈는 중계자가 사용자의 요청에 따라 올바른 witness를 제공하였는지, 또는 witness를 제공한 것에 대한 올바른 보상을 받는 지를 보장할 수 있는 가입니다. 또한 실행 환경 구현을 함께 고려해봤을 때 이슈는 중계자가 witness를 생성하기 위해서 샤드 체인의 실행 환경의 모든 상태를 가지고 있어야 한다는 것입니다. 즉, 중계자가 되기 위해서는 하드웨어 (디스크 저장 용량 및 연산 능력)적인 자원이 필요합니다. 그렇다면 좋은 컴퓨터 자원을 갖고 있는 중계자는 거래를 보내는 사용자에 대한 비용을 책정할 때 보다 싼 가격에 서비스를 제공할 수 있을 것입니다. 이에 따라 중계자의 진입장벽이 높아지고 중앙화 이슈가 발생할 가능성이 있습니다. 중계자 네트워크가 소수에 집중된다면 자신들의 뜻대로 거래 패키지를 만드는 거래 검열문제(Transaction Censership) 문제가 발생할 수 있고 담합하여 블록 제출자에게 보내는 거래 수수료를 낮출 수도 있을 것입니다.

Bring Back the Mempool

이에 따라 중계자의 중앙화 이슈를 완화하기 위해 중계자의 역할을 제한하는 아이디어가 제시되었습니다. 중계자는 더 이상 거래를 묶어서 한 번에 블록 제출자에게 보내지 않고 거래를 받으면 witness를 추가하여 mempool에 전파합니다. 블록 제출자는 mempool에서 거래를 받아 블록에 기록합니다. 기존 이더리움 1.0에서 사용하는 방식과 유사하게 거래를 중계자가 네트워크의 mempool에 올리면 블록 제출자들의 선택에 따라 블록에 기록합니다. 더 이상 중계자(Relayer)의 개념이 필요하지 않으므로 이 역할군은 상태 제공자(State Provider) 또는 라이트 클라이언트 서버(Light Client Server)라고 바꿔 부를 수 있을 것입니다.

Cross Shard Transactions

Phase 2에서는 샤드 체인 간 거래를 전송할 수 있는 샤드 간 통신을 구현하게 됩니다. 샤드 체인은 독립적인 체인으로 각각 별도의 데이터를 저장하고 처리합니다. 각 샤드 체인 간에 같은 실행 환경을 갖고 있다면 샤드 간 통신(Cross Shard Communication)을 통해 샤드 체인 간 같은 실행 환경을 서로 연결할 수 있습니다. 이 글에서 상세히 언급하기에는 내용이 많기 때문에 간략히 설명하도록 하겠습니다. 관심 있으신 분은 아래 링크를 참고해 주시기 바랍니다.

Asynchronous Cross Shard Transactions
비동기 통신 방식은 주로 Yanking 방식이 논의되고 있으며 Phase 2 스펙에 포함되어 있습니다. 작동 과정을 간략히 설명하면 샤드 체인 A와 B가 있다고 가정했을 때 샤드 A의 컨트랙트를 지운 다음(yanking) 샤드 B에서 샤드 A의 컨트랙트를 생성합니다. 샤드 B에서 생성된 컨트랙트에서 임의의 작업을 수행한 후 다시 컨트랙트를 지우고(yanking) 샤드 A로 보냅니다. 각 샤드의 거래가 확정되는 것을 기다려야 하기 때문에 (약 6분) 실제로 사용하기에는 비효율적이라 할 수 있습니다. 이 방식은 느린 비동기 샤드 간 거래(Slow Asynchronous Cross Shard Transactions)라고도 합니다.

Optimistic Asynchronous Cross Shard Transactions
빠른 비동기 샤드 간 거래(Fast Asynchronous Cross Shard Transactions)는 기존 느린 비동기 샤드 간 거래(Slow Asynchronous Cross Shard Transactions)의 단점을 극복하고자 제시된 모델입니다. 이 방식은 이더리움 2.0 Phase 2 현재 스펙인 Contract Yanking 방식을 확장한 것입니다. 조건적 상태 개념의 도입으로 기다리는 시간을 현저히 줄일 수 있습니다.(약 4초)

Synchronous Cross Shard Transactions
동기 샤드 간 거래는 하나의 거래로 두개의 샤드의 상태 실행을 순차적으로 처리하는 방법입니다. 구조적으로 간단하지만 두 개의 샤드 체인간에 이 모델을 어떻게 구현하는 가는 상당히 어려운 문제입니다.

Conclusion

Phase 2 에서는 상태 및 상태 실행을 정의하여 샤드 체인에서 상태 실행을 처리할 수 있도록 합니다. Phase 2의 핵심 개념은 실행 환경이라 할 수 있으며 실행 환경을 통해 이더리움 1.0을 비롯한 다양한 환경을 구현할 수 있습니다. Phase 2에 대한 논의는 주로 실행 환경을 Stateless Client 모델 위에서 구현하는 것에 집중하고 있습니다. Phase 2 구현이 완료되면 가장 기대되는 것은 물론 이더리움 2.0 체인에서 스마트 컨트랙트를 작동시킬 수 있다는 것입니다. 또한 기존 이더리움 1.0 실행환경을 개선한 모델이나 이더리움 2.0에 맞는 새로운 실행 환경 모델이 구현될 것도 기대되는 부분입니다.