[이더리움2.0 깊이보기 시리즈] ETH 2.0 Explained: Execution Environment[9편]
Jason Hwang & Jake Song
이더리움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
Intro
Phase 2는 샤드 체인의 상태 정의(State Definition)및 상태 전이(State Transition)에 대한 구현을 목표로 하고 있습니다. Phase 2 아키텍쳐는 컨센서스 레이어를 최소화하여 단순화하고 그 위에 보다 복잡한 상태 실행 모델 레이어를 구현할 수 있도록 설계되었습니다.
상태 실행 모델 레이어는 실행 환경(Execution Environment) 이라고 하며 상태 및 상태 실행을 정의합니다. 예를 들어 이더리움 1.0에서는 계정 기반의 상태를 정의하고 있습니다. 이 상태는 이더리움 가상 머신 연산을 통해 변경되어 저장됩니다. 이 전체 과정을 통틀어 실행 환경이라고 할 수 있습니다.
이더리움 2.0 Phase 2에서는 위 그림처럼 컨센서스(eg. Casper FFG)와 상태 실행 모델을 구분합니다. 이로써 컨센서스를 기본 레이어로 두고 그 위에 실행 환경을 유연하게 구현할 수 있게 되었습니다. 즉, 같은 컨센서스 방식을 사용하지만 다양한 상태 실행 모델을 구성할 수 있습니다.
예를 들어 위 그림 처럼 이더리움 1.0과 같은 계정 기반 실행 환경 뿐만 아니라 비트코인의 UTXO 방식과 같은 실행환경을 구성할 수도 있습니다. 또한 기존 방식을 개선하거나 목적에 맞게 변경할 수도 있습니다. 아니면 기존 방식과 전혀 다른 새로운 실행환경 모델을 구성할 수도 있습니다.
다시 말하면 실행 환경은 샤드 체인의 상태 실행을 위한 모든 환경을 구성한다고 할 수 있습니다. 상태정의 및 연산을 정의하며 트랜잭션 타입도 정의합니다.
Beacon Chain Contract
비컨 체인 컨트랙트에서 실행환경 모델을 정의합니다. 비컨 체인의 컨트랙트들은 각각 다른 실행환경을 구성할 수 있습니다. 샤드 체인은 상태 정보만 가지고 있으며 비컨 체인 컨트랙트에서 상태 전이 함수를 정의합니다.
비컨 체인 컨트랙트는 이더리움 1.0에 배포되어있는 일반적인 스마트 컨트랙트(ex. Dapp)와는 다른 유형의 컨트랙트입니다. 일반적인 Dapp을 위한 컨트랙트들은 샤드 체인에 배포 되겠지만, 비컨 체인 컨트랙트들은 실행환경을 정의합니다.
얼핏 들으면 굉장히 다양한 형태의 비컨 체인 컨트랙트들이 생길것 같지만, 초기에는 다양한 비컨체인 컨트랙트가 만들어지지는 않을 것으로 생각합니다. 한편 비컨 체인 컨트랙트가 각각 다른 가상 머신을 나타내는 것으로 생각할 수도 있습니다. 하지만 비컨 체인 컨트랙트는 가상 머신 자체를 의미한다기 보다 가상 머신을 포함한 실행 환경을 정의한다고 볼 수 있습니다.
Scenario: Transfer Ether
기본적인 개념을 알아봤으니 이제 하나의 시나리오를 살펴 보도록 하겠습니다. 시나리오는 계정 기반 상태를 정의하고 있는 비컨 체인 컨트랙트가 있다고 가정하고 이더를 예치한 후, 특정 샤드로 예치한 이더를 보내는 것입니다. 보다 엄밀하게 얘기해서 비컨 체인 컨트랙트에 예치한 이더가 샤드로 옮겨가는 것이 아니고 예치한 이더는 묶인 상황이고 샤드에 새로운 이더가 생기는 것입니다. 이 새로운 이더는 새로 생긴 토큰이라고 보는 것이 적절할 것 같습니다.
실제로는 위 데이터는 비컨 체인에 receipt으로 발급되고 블록 제출자(ie. 마이너)에 의해 비콘 체인의 블록 데이터에 포함될 것 입니다. 이 receipt은 샤드 체인에 이더를 새로 만들기 전에 검증을 위해 사용됩니다.
위에서 언급한 것처럼 샤드 체인은 네이티브 이더라는 개념이 없는 대신, 이더를 비컨 체인 컨트랙트에 묶어둔 다음 그 이더를 샤드 체인에서 사용해야 합니다. 각 샤드 체인의 블록에는 상태가 생성되고, 샤드 체인 안의 상태는 항상 비컨 체인 컨트랙트에 직접적으로 매핑 됩니다. 이에 대해 비탈릭이 사용한 예제를 통해 한번 살펴보도록 하겠습니다.
위 그림의 objects 의 항목에 대한 인덱스는 각 비컨 체인 컨트랙트의 인덱스와 매핑되어 있습니다. 만약 두 종류의 비컨 체인 컨트랙트(ie. 실행환경)가 있다면, 해당objects 는 두 개의 항목만 갖게 됩니다. 예를 들어 계정 기반 이더리움 비컨 체인 컨트랙트의 인덱스는 0 이고 UTXO 기반의 인덱스는 1을 갖게 됩니다.
만약 어카운트 기반 이더리움 비콘 체인 컨트랙트 0와 UTXO 기반 비콘 체인 컨트랙트 1이 있다면 각 비콘 체인 컨트랙트는 아래 그림처럼 상태를 따로 관리합니다.
Moving Ether into the Shard Chain
비컨 체인 컨트랙트에 depositToShard 라는 함수를 정의합니다.
검증을 위해 비컨 체인에 Withdrawl Receipt을 제출합니다. 해당 검증이 유효한 경우, 사용자는 다음과 같이 생성되고 새 스토리지가 계정 데이터와 함께 기록됩니다.
Transferring Funds
이제 샤드 체인에 계정을 갖고 있으며, 이 계정을 통해 다른 계정으로 자금을 전송할 수 있습니다.
위 함수는 단지 우리 계정의 잔액을 줄이고, 트랜잭션을 수신하는 계정의 잔액을 증가시킵니다. 즉, 이러한 기능은 샤드체인 내의 상태를 변경합니다.
위 시나리오는 비탈릭이 제안한 Phase2 Proposal 2를 기반으로 만들어진 시나리오입니다. (원문 : https://medium.com/@william.j.villanueva/a-journey-through-phase-2-of-ethereum-2-0-c7a2397a36cb) 보다 깊은 기술적 이해를 위해 비탈릭의 제안을 살펴 보도록 하겠습니다.
Phase 2 Proposal 2
Phase 2 Proposal 2는 상태 및 트랜잭션 실행을 하기 위해 1) 비컨 체인에 대한 수정 제안, 2) 샤드 상태 및 상태 전이에 대해 설명합니다. 제안의 핵심은 컨센서스 레이어를 상대적으로 최소화하고, 레이어 2에서 상태 실행 모델을 정의하는 것입니다. 목표는 레이어 2에서 필요로 하는 모든 스마트 컨트랙트의 기능을 개발할 수 있는 충분한 능력을 제공하는 것입니다.
이 제안의 기본적인 접근은 비컨 체인에 실행환경 모델을 정의하는 특별한 컨트랙트가 존재하고 이더는 비컨 체인의 검증자 계정이나 비컨 체인 컨트랙트에만 저장할 수 있는 것입니다. 이 특별한 컨트랙트에서 샤드의 상태 및 상태 전환을 정의합니다.
Beacon Chain Changes
이를 위해 비컨 체인에 세 가지 거래 타입이 추가됩니다. 알아둘 것은 실행환경 모델(ie. 비컨 체인 컨트랙트)내에서 정의하는 거래 타입과는 다르다는 것입니다. 비컨 체인의 거래는 보다 근본적인 것으로 실행환경 모델 관리 및 이더 전송에 사용됩니다.
NewExecutionScript : 비컨 체인에 새로운 컨트랙트를 배포합니다. 이 컨트랙트는 특별한 컨트랙트로서 실행환경 모델을 정의합니다.
NewValidator : 비컨 체인 컨트랙트 계정에서 이더를 가져와 검증자 대기열에 들어가도록 합니다. 즉, 샤드 체인에 사용하기 위해 비컨 체인 컨트랙트 계정에 묶여 있던 이더를 풀고 검증자가 되기 위해 이더를 예치하는 것입니다. 검증자가 되면 비컨 체인과 샤드 체인의 블록을 검증할 수 있고 블록 보상을 받을 수 있습니다.
Withdrawal : 검증자가 이더를 인출하여 비컨 체인 컨트랙트에 넣습니다. 이더 전송에 대한 검증을 위해 아래 데이터를 기반으로 시나리오에서 설명드렸던 WithdrawalReceipt을 발행합니다.
다음은 비컨 체인에 데이터 구조를 정의 합니다.
ExecutionScript: 비컨 체인 컨트랙트의 데이터 구조입니다. 비컨 체인 컨트랙트는 Execution Script라고도 합니다.
WithdrawalReceipt: WithdrawalReceipt는 검증자의 인출이 유효한지 검증하는 데 사용됩니다.
그러면 이제 비컨 체인 컨트랙트를 생성하는 과정을 살펴 보겠습니다.
비컨 상태와 비컨 체인 컨트랙트 코드(ie. eWASM 바이트 코드)를 인자로 받아 새로운 비컨 체인 컨트랙트를 생성합니다. 거래 전송자의 상태(검증자 풀에서 나와 이더를 사용할 수 있는지)나 충분한 잔고가 있는지 등 검증 과정을 거칩니다. 다음 거래 전송자의 잔고에서 이더를 차감한 후 eWASM 바이트 코드를 비컨 체인 상태에 추가합니다.
다음은 다시 검증자 대기열로 올리는 과정입니다.
비컨 상태와 앞서 설명드린 NewValidator 데이터 타입을 인자로 받아 비컨 체인 컨트랙트에 예치한 이더를 풀고 검증자 대기열에 올라가도록 합니다.(새로운 검증자는 바로 검증자 풀에 들어가 검증할 수 있는 것이 아니고 일정 기간 대기열에 있게 됩니다.)
과정을 보면 먼저 샤드 체인에서 만들어진 new_validator_receipt의 유효성을 검증합니다. new_validator_receipt이란 검증자 대기열 신청할 때 만들어지는 receipt입니다. 그 다음 비컨 체인 컨트랙트의 잔고가 충분한지 확인 후 process_deposit_data이라는 다른 함수를 호출하여 비컨 상태에 예치 정보를 추가하여 이후 검증자 대기열에 들어갈 수 있도록 합니다.
다음은 반대로 검증자 풀에서 이더를 인출한 후 컨트랙트에 이더를 전송하는 과정입니다.
검증자 풀에 들어가 검증자 컨트랙트에 예치되어 있는 이더를 인출하여 원하는 특정 비컨 체인 컨트랙트에 이더를 전송합니다. 거래 전송자가 인출 가능한 상태인지 확인하고 거래 전송자의 공개 키와 서명이 유효한지 검증합니다. 위 함수를 실행하기 전 인출요청이 유효한지 검증할 수 있는 receipt을 생성하게 됩니다. 이 receipt이 위에 설명드린 Withdrawl Receipt입니다. 이를 비컨 상태에 withdrawl_receipts 목록에 넣습니다. 그 다음 비컨 체인 컨트랙트(Execution Script)에 이더를 전송하고 검증자 풀 목록에서 거래 전송자를 삭제합니다.
Shard chain processing
이번에는 샤드 체인의 상태가 어떻게 정의되고 상태가 이전되는 지 살펴보겠습니다.
ShardState는 다음과 같은 형식을 갖게 될 것입니다.
간단한 상태 이전 함수는 다음과 같이 구현될 수 있습니다.
샤드 상태, 비컨 상태, 샤드 블록을 인자로 받아 실행하게 됩니다. 비컨 체인에 저장되어 있는 Execution Script, 즉 비컨 체인 컨트랙트의 코드를 가져와서 execute_code 함수를 호출합니다. execute_code 함수는 연산 후 상태값을 반환합니다.
Implementing in-shard ETH transfers
위 비컨 체인의 함수들을 기반으로 이제 비컨 체인 컨트랙트에 실행환경 모델을 정의할 수 있습니다. 지금부터 설명드릴 내용은 간단한 샤드 체인에 이더리움 1.0과 같은 계정 기반의 상태가 있고 이더를 전송할 수 있는 실행 환경을 구성하는 것입니다. 비컨 체인 컨트랙트 내에서 아래 데이터 타입 및 함수를정의합니다.
먼저 정의할 함수는 processWithdrawl 함수입니다. 먼저 비컨 체인에서 인출 요청을 한 후 만든 Withdrawl Receipt이 유효한지 검증하고 타겟 샤드에 이더를 발행합니다. 알아 둘것은 비컨 체인의 이더가 타겟 샤드로 옮겨지는 것이 아니고 비컨 체인의 이더는 묶인 상태이고 타겟 샤드에 이더가 새로 생긴다는 것입니다.
상태 루트와 MyWithdrawal 타입의 거래를 인자로 받습니다. Withdrawl Receipt이 유효한 지 검증 후 샤드 체인의 상태 루트와 witness의 루트를 검증하는 작업을 거칩니다. witness는 거래 관련 데이터인데 이 데이터를 포함한 머클 루트 정보도 갖고 있다고 가정합니다.
- witness는 Stateless Client 구현시 필요한 개념입니다. 실행 환경 모델은 이 Stateless Client 환경 내에서 구현하게 됩니다. 따라서 검증자(블록 제출자 포함)들은 상태를 저장하지 않기 때문에 거래 전송자들은 상태가 유효한지 검증할 수 있는 witness를 거래와 함께 제출해야 합니다.
검증 작업을 거친 후 샤드 체인내에 계정에 이더를 생성합니다. 참고로 위 코드는 기존 계정에 이더를 생성하는 로직만 있습니다. 새로운 계정을 만드는 로직은 간단히 만들어 추가하면 될 것입니다.
다음은 계정 간에 이더를 전송하는 processTransfer 함수입니다.
상태 루트와 MyTransfer 타입의 거래를 인자로 받습니다. 샤드 체인내에서 이더를 전송할 수 있도록 합니다. 단순히 논스 및 잔고 체크를 하고 각 계정의 잔고를 변동 시킵니다.
다음은 비컨 체인의 검증자 풀에 다시 들어가기 위한 processDeposit 함수입니다.
상태 루트와 MyDeposit 거래 타입을 인자로 받습니다. 샤드 체인 내 계정에 있는 이더를 다시 비컨 체인의 검증자 컨트랙트에 보내 검증자 대기열에 올립니다.
다음은 블록에 저장된 거래에 따라 상태를 변경하는 process_block 함수입니다.
샤드 체인 상태, 샤드 블록을 인자로 받습니다. 전파받은 거래를 거래 타입MyWothdrawl, MyTransfer, MyDeposit에 따라 관련 함수를 호출하여 새로운 상태 정보나 검증자 풀에 들어가는 예치금 정보를 반환합니다.
From ETH transfers to complete state execution
단순 이더 전송이 아닌 완전한 상태 실행(eg. 이더리움 1.0과 같은 스마트 컨트랙트 실행 환경)구현을 위해서는 몇 가지 사항이 추가되어야 할 것입니다. 아래 내용은 비탈릭이 제안한 것으로 완전한 상태 실행을 위해 필요한 사항들을 살펴보겠습니다.
- 샤드 간 거래(Cross Shard Transaction)를 구현하기 위해서 호출 샤드에서 샤드 간 메세지를 보낼 함수를 구현해야 합니다. 또한 타겟 샤드에서 이 메세지를 받을 수 있는 함수도 구현해야 할 것입니다. 이 함수들은 비탈릭이 제시한 Eth 2.0 Phase 2 pre spec : cross-shard mechanics에서 제안하고 있습니다.
(참고: https://ethresear.ch/t/phase-2-pre-spec-cross-shard-mechanics/4970) - 거래 타입에 몇 가지 사항을 더 추가해야 할 것입니다. gasPrice, operations(이더전송 및 컨트랙트 함수 호출 등), witness 필드를 추가해야 합니다. 서명 검증은 반드시 BLS 서명 검증으로 할 필요는 없습니다. 대신에 추상화하여 어떤 서명 검증을 정할 지는 EE 구현에 따라 다르게 정하도록 합니다.
- 적절한 상태 전이 함수가 필요할 것입니다. 위의 모든 거래 타입을 연산하고 상태를 반영할 수 있어야 합니다.
- 단순 이더 전송 뿐만 아니라 컨트랙트 호출을 구현해야 할 것입니다. 즉 가상머신 모델을 구현해야 합니다. 이 역시 추상화하여 기존 EVM과 WASM 가상머신외에 상위의 스택부터 OPCODE로 연산하여 새로운 상태를 반영하는 가상 머신 모델을 생각할 수 있을 것입니다.
- 조건적 상태 로직을 구현해야 합니다. 이는 비동기 샤드 간 거래를 빠르게 하도록 하는 데 필요합니다.
참고: https://ethresear.ch/t/fast-cross-shard-transfers-via-optimistic-receipt-roots/5337 - 상태 저장 최적화를 위한 매커니즘이 필요합니다. (eg. 동면(Hibernation Mechanism)
참고: Cross-shard receipt and hibernation/waking anti-double-spending
Several Prototypes of Execution Environment
실행환경을 구현하여 실제 서비스에 사용하기 위해서는 다양한 실행환경을 구현해보고 테스트 및 벤치마킹을 해야 할 것입니다. 따라서 Phase 2에서는 다양한 실행 환경의 프로토타입을 구현하고 테스트 및 벤치마킹을 활발히 진행하고 있습니다.
테스트 및 벤치마킹의 목적은 실행 환경이 Stateless Client 모델에서 이상없이 동작하는지 확인하는 것입니다. 주로 Stateless Client 모델에 필요한 증거(proofs/witnesses)의 사이즈가 적합한지 확인하는 작업, 해당 증거를 사용하는 검증 시간이 어느 정도 소요되는지 등을 확인하는 작업을 하고 있습니다.
이와 같이 다양한 실행 환경을 구축하여 테스트 및 벤치마킹을 진행하기 위해서는 상태 실행 엔진이 필요합니다. Phase 2에서는 Scout이라고 하며 eWASM 기반의 가상 머신입니다. 현재는 프로토타입의 테스트 및 벤티마킹을 위한 기능만 구현되어 있지만 향후 이더리움 2.0 구현 진행에 따라 완전한 상태 실행을 수행할 수 있도록 구현될 것입니다.
Scout
- Github: https://github.com/ewasm/scout
Scout은 Ethereum 2.0 페이즈 2의 실행 엔진들의 프로토타입을 만들 수 있는 환경을 제공하는 도구입니다. eWASM API를 연결하여 실행 환경의 프로토타입 제작과 벤치마킹에 사용할 수 있도록 합니다.
Scout의 목적은 다음과 같습니다.
- 실행 스크립트라 불리는 몇 가지 예제 컨트랙트를 생성
- 스크립트를 만들 때 “쉬운” 온보딩을 사용하도록 설정
- 스크립트에 실제 사용 사례를 포함했을 때, 해당 설계를 벤치마킹하고 병목 현상에 대한 식별
Scout은 테스트 및 벤치마킹 목적으로 구현되었기 때문에 아직은 이더리움 2.0 클라이언트로는 사용할 수 없고, 단순히 비컨/샤드 상태에 대한 읽기 및 출력을 YAML 형태로 지원합니다.
Eth1 Related Execution Environment
이더리움 1.0에서 이더리움 2.0으로 전환하기 위해서는 이더리움 1.0의 실행 환경을 이더리움 2.0의 실행환경에 맞게 만드는 것이 필요 합니다. 가장 큰 과제는 이더리움 1.0을 Stateless Client 모델로 변경하고 EVM과 트랜잭션/계정 모델을 실행 환경에 맞게 변경하는 것 입니다. 다음은 이더리움 1.0 전환과 관련된 실행환경 구현체입니다.
SMPT Token
- Github: https://github.com/ewasm/scout/pull/11
- 참고자료: https://www.youtube.com/watch?v=8H1TCbW0LJQ&t=35m25s
그리고 이더리움 1.0과 관련된 실행환경의 첫 번째 프로토타입으로 Stateless Merkle Patricia Trie(SMPT) 토큰 이라는 것이 제안 되었습니다.
기본 이더리움 1.0 스타일의 Stateless 토큰의 초기 프로토타입이 갖는 특징은 다음과 같습니다.
- 머클 패트리샤 트리 사용
- 블록 데이터, 머클 증명의 데이터를 RLP 방식으로 인코딩
- 이더리움 1.0의 서명 방식을 사용
SMPT 토큰은 이더리움 1.0 의 모델을 모방하는 것을 목표로 하여 이더리움 1.0의 머클 트리(Hexary Merkle-Patricia) 및 RLP를 사용합니다. SMPT 토큰 모델을 벤치마킹 결과는 다음과 같습니다.
벤치마크: 70개의 거래와 5,000개의 계정/리프 노드(Leaf Node)
시간: 5 seconds
증명 크기(Proof Size): 235kb
초기 구현체보다 어느정도 성능의 개선이 이루어졌지만, SMPT 토큰을 이용했을 경우 실행에 소요되는 시간과 증명의 크기 모두 개선이 필요합니다. 패러티(Parity)의 Rust 기반 라이브러리를 wasm으로 컴파일 하면서 몇 가지 이슈들을 해결했지만, 다른 이슈는 웹 어셈블리에서 Rust 언어를 완벽히 지원하지 못하기 때문에 아직 컴파일 작업이 어렵다는 이슈가 있습니다.
Turbo Token
- Github: https://github.com/ewasm/biturbo
- 참고자료: https://medium.com/@gballet/turboproofs-light-clients-and-saving-private-eth1-487aaa9b386
터보 토큰은 이더리움 1.0의 Stateless Client 구현에 대해 연구했던 터보프루프를 활용합니다. 터보프루프는 위에 설명 드린 SMPT 방식과 같이 Stateless Client 구현에 적용할 수 있는 접근 방식 중 하나입니다.
터보 프루프를 통해 사용자는 라이트 클라이언트에서 관심 있는 데이터만 저장하고 블록체인과 상호 작용을 하고 싶을 때 해당 데이터에 대한 소유권을 증명할 수 있으며 터보 토큰을 사용했을 때 벤치마크 성능은 다음과 같습니다.
벤치마크: 70개의 거래와 5,000개의 계정/리프 노드
시간: 140 ms
증명 크기(Proof Size): 50kb
SMPT 프로토타입에 비해 실행 시간과 증명 크기에 대한 개선이 많이 이루어졌습니다. 하지만, 5,000개의 계정은 실제 이더리움 1.0의 머클 트리가 다루는 계정의 개수와는 차이가 많이 있다고 할 수 있습니다. 현재는 실제 상황과 동등한 규모에서 같은 테스트를 수행하는 작업을 진행하고 있습니다.
EVM Interpreter EE
이더리움 1.0의 실행환경을 지원하기 위해 실행 환경에 EVM 인터프리터(웹 어셈블리)를 구축해야 합니다. 인터프리터는 기존에 배포된 스마트 컨트랙트들을 eWASM 가상머신이 실행할 수 있도록 하기 위해 필요합니다.
위의 모든 구현체의 테스트는 이더리움1.0 실행 환경의 완전한 구현으로 이어지기 위한 것입니다. 이미 프로토타입을 제작할 수 있지만, 여러 가지 성능 문제를 아직 검토해야 합니다. 위에서 언급한 바와 같이, 이더리움 1.0의 실행환경을 구축하고 Stateless Client 모델에 구현하는 것을 목표로 팀이 최근에 만들어졌습니다.
Execution Environments — Eth2 Centric
다음 구현체는 이더리움 1.0에서 이더리움 2.0으로 전환하는 것보다 이더리움 2.0에서 새로운 실행 환경을 구현하는 것에 초점을 맞춘 것입니다.
C Merkle Token
Stateless Merkle Token은 온체인에 상태의 해시 값만 저장하고 모든 계정의 밸런스는 오프체인에 저장하는 방식을 사용합니다. 자세한 내용은 여기에 있습니다. 해당 구현체의 성능은 아래와 같습니다.
벤치마크: 2²²개의 계정과 40개의 계정이 증거에 포함됨(2²² accounts and 40 accounts in the proof)
시간: 20 ms (서명 증명이 필요 없음)
증명 크기(Proof Size): 25kb
현재로서는 이 구현체가 가장 뛰어난 성능을 보이고 있습니다. 벤치마크에는 서명 검증이 포함되지 않았지만, 포함되었다고 하더라도, 약 30ms 정도의 시간 증가가 예상됩니다. 더욱 최적화할 수 있는 방법은 여러 가지가 있습니다. 해시 및 프루프의 캐싱을 통해 검증에 필요한 시간과 크기를 줄일 수 있습니다. 네트워크가 성장함에 따라 해시 길이가 증가하는 적응형 해시 길이를 통해서도 프루프의 크기를 더 줄일 수 있습니다.
Shard Ether(Sheth)
- Github: https://github.com/quilt/sheth
- 참고자료: Devcon 5 Presentation
Sheth는 이더리움 2.0 컨트랙트 실행환경의 초기모델이며 단순 직렬화(SSZ; 이더리움 1.0의 RLP와 같은 데이터 인코딩 방식)를 기반으로 합니다. 또한, 샤드와 비컨 체인 사이에서 이더의 이동 메커니즘을 제공하는 이더리움 2.0을 위한 실행 환경입니다. 벤치마크 결과는 다음과 같습니다.
벤치마크: 50개의 계정과 50개의 트랜잭션
증명 크기(Proof Size): 517kb
Sheth의 현재 구현은 공간을 너무 많이 차지하며 느립니다. 0 패딩을 제거하거나 0 해시의 양을 조절하여 크기를 대폭 줄일 수 있습니다. 처리속도는 256비트 작업을 관리하는 호스트 기능과 필요한 코드 최적화를 도입하여 속도를 향상시켜야 합니다.
SimpleUmbrella — Eth2 Smart Contract EE
- Github: https://github.com/quilt/kernel
- 참고자료: Eth Research Proposal, https://github.com/quilt/ewasm-rt/pull/11
SimpleUmbrella는 Stateless Client 모델 내에 구현할 스마트 컨트랙트 실행 환경입니다. 이더리움 1.0의 실행환경과 같이 스마트 컨트랙트를 실행하는 것을 목표로 하지만 eWASM 가상머신으로 실행합니다. 최근에는 이더리움 2.0 실행환경 내에서 자식 컨트랙트를 생성하거나 실행하는 데 필요한 호스트 기능의 프로토타입이 개발되었습니다.
Conclusion
이더리움 2.0 Phase 2는 상태 정의 및 상태 전이에 대한 구현을 목표로 하고 있습니다. 컨센서스와 상태 실행을 구분하여 비컨 체인 컨트랙트에 실행환경 모델을 정의합니다.
실행환경 모델은 샤드 체인의 상태 실행을 위한 모든 환경을 구성한다고 할 수 있습니다. 비컨 체인 컨트랙트마다 고유한 실행 환경 모델을 정의할 수 있습니다. 구현 상 이슈가 있지만 이론적으로는 이더리움 1.0, 비트코인 UTXO, 그 밖의 다른 실행환경 모델을 구현할 수 있습니다. 이는 추상화(Abstraction)의 장점을 이용한 것으로 업그레이드에 따른 클라이언트의 부담을 줄이면서 다양한 실행 환경을 구성하기 위해서 입니다.
실행환경 모델은 현재 이론적 논의와 함께 이더리움 2.0의 상태 실행 엔진인 Scout을 통해 이더리움 1.0을 포함한 다양한 실행 환경이 구현되고 벤치마킹을 포함한 다양한 테스트가 진행중입니다.
테스트 및 벤치마킹을 거쳐 실행환경 구현이 완료된다면 가장 기대되는 점은 이더리움 2.0에서 스마트 컨트랙트를 실행할수 있는 환경을 갖추게 된다는 것입니다. 즉 오랜 디자인 논의 및 구현단계를 지나 개발자와 일반 유저들이 이더리움 2.0 네트워크에 참여하여 실제 서비스에 사용할 수 있게 될 것입니다.
Reference
https://ethresear.ch/t/proposed-further-simplifications-abstraction-for-phase-2/5445
https://ethresear.ch/t/eth-execution-environment-proposal/5507
https://ethresear.ch/t/phase-2-pre-spec-cross-shard-mechanics/4970
https://ethresear.ch/t/phase-2-pre-spec-cross-shard-mechanics/4970
https://medium.com/@william.j.villanueva/a-journey-through-phase-2-of-ethereum-2-0-c7a2397a36cb
https://medium.com/r/?url=https%3A%2F%2Fnotes.ethereum.org%2F%40vbuterin%2FBkoaj4xpN%3Ftype%3Dview
https://www.reddit.com/r/ethereum/comments/cgq0p6/eli5_execution_environments_in_1048_shards/
