Ethereum 2.0 Phase 0 Deep Dive

Jake Song
Jake Song
Oct 24 · 24 min read
Eth 2.0 Phase 0에 Beacon Chain이 런칭됩니다. 출처: Nugget’s News, Youtube

Devcon 5에서 중점적으로 다뤘던 주제 중 하나는 Eth 2.0 에 관한 주제입니다. 그 중 Eth 2.0 Phase 0 Deep Dive 세션은 Phase 0에 대해 기술적으로 상세하게 설명한 세션입니다. 세션은 구현에 관한 상세 설명으로 구성되었습니다.

  • FFG applied to PoS
  • LMD GHOST fork choice rule
  • Randomness in ETH 2.0
  • BLS signature and aggregation
  • Life of An Ethereum Beacon Chain Validator
  • State Transition Function

본 글의 슬라이드 이미지는 Devcon 5의 Ethereum Phase 0 Deep Dive 세션의 슬라이드입니다.

Beacon Chain

Phase 0에서는 Beacon Chain이 배포됩니다. Beacon Chain은 “system chain” 혹은 “spine chain”이라고도 불립니다. 모든 Shard Chain은 crosslinks로 연결됩니다. Shard Chain은 Phase 1과 Phase 2에 구현될 예정입니다.

Beacon Chain은 Validator의 등록 정보를 관리하고 저장합니다. 현재 구현 단계에서는 Ethereum 1 Chain에 있는 Deposit 컨트랙트에 deposit하면 Event가 발생하고 Beacon Chain에서 그 Event를 받아 Validator를 등록하고 있습니다.

Exit은 Voluntary Exit(자의적 exit)와 penalty로서 Forcible Exit(강제적 exit)이 있습니다.

Beacon Chain에서 중요한 액션 중 하나는 “attestation” 입니다. “attestation”은 shard block이나 Beacon Chain의 block에 투표하는 행위입니다. shard block에 일정 수의 attestation이 있으면 “crosslink”를 생성하게 됩니다.

“crosslink”는 샤드의 상태 정보를 Beacon Chain에 올리는 것으로 해당 샤드의 상태정보가 유효하다는 것을 입증합니다. 또한 “crosslink”는 샤드 간 거래, 즉 Cross Shard Communication에 사용됩니다.

FFG applied to PoS

Eth 2.0에서는 Beacon Chain에 finality를 보장하기 위해 FFG를 적용합니다. 구현을 위해 기존 Casper FFG를 수정하여 사용합니다.

수정된 Casper FFG가 기존 Casper FFG와 다른 점은 slot이라는 개념을 도입하여 slot을 기준으로 check point와 epoch을 정한다는 것입니다.

slot은 시간 단위로 나누어져 있으며 Block Proposer는 slot 기간 내에 블록을 제출해야 합니다. Phase 0에서는 6초로 지정되어 있습니다.

기존 Casper FFG는 블록 height를 기반으로 check point와 epoch을 정했습니다. 하지만 slot이라는 개념이 생겼기 때문에 몇 가지 변경점이 생겼습니다.

만약 위 그림과 같이 slot 2에 블록이 네트워크에 전파되지 않는 다면(e.g. Proposer가 오프라인이거나 network latency가 높을 경우) 다음 slot으로 넘어가게 됩니다.

Epoch 1에서 64번째 블록을 justified하고 어떤 이유로 해당 slot에서 블록을 받지 못 했다면 다음 Epoch 2에서 justified된 64번째 블록에서 블록을 쌓기 시작합니다.

Epoch 2에서 64번째 블록은 finalize됩니다. Epoch 1에서 64번째 블록은 justified되었고 Epoch 2에서 다시 justified되기 때문입니다. Epoch 2의 64번째 블록은 finality가 보장됩니다.

Justification Rule은 기존과 같습니다. epoch j에서 전체 stake의 2/3이상의 투표 즉, attestation을 받았을 때 justified되었다고 볼 수 있습니다. genesis block은 justified된 상태입니다.

Finalization Rules도 대부분 기존과 같지만 약간의 변경이 있습니다.
기존 Casper에서는 직접적인 자식블록이 justified되면 부모블록이 finalized했지만(i.e. k=1) 수정된 Casper에서는 justified된 블록 + k 블록이 justified되었다면 그 사이에 있는 블록은 justified되고 부모블록이 finalized 블록이 됩니다.

Eth 2.0의 finality rule은 기존 case k=1과 함께 case k=2도 고려하여 finalized point를 생성합니다. 이는 finality issue를 피하기 위함입니다. (Eth 2.0의 fork choice rule인 LMD GHOST fork choice rule인 경우 bounce attack으로 finalized point를 만들 수 없는 이슈가 있습니다.) bounce attack 이슈는 뒤에 설명하겠습니다.

LMD GHOST fork choice rule

Eth 2.0에서는 fork choice rule로 LMD Ghost를 사용합니다. LMD Ghost는 기존 GHOST 방식을 수정한 것으로 가장 최근의 블록까지 voting 숫자를 합산하여 canonical 체인을 결정합니다. LMD Ghost fork choice rule을 사용하는 이유는 1) 기존 fork choice 방식인 longest chain fork choice rule이나 Eth 1.0의 기존 GHOST fork choice rule보다 네트워크의 consensus; 지지도를 민감하게 반영하고 2) Parallel conformations가 가능하기 때문입니다.

그림을 통해 1)의 경우를 설명하겠습니다.

그림 1) Longest Chain rule

그림 2) LMD GHOST

두 그림은 같은 block tree를 갖고 있습니다. 그림 1)의 Longest chain rule은 가장 긴 블록 height를 따라 위쪽 fork가 canonical 체인이 됩니다. 하지만 그림 2)의 LMD GHOST rule은 투표합산에 따라 아래쪽 fork가 canonical 체인이 됩니다. 아래쪽 fork는 투표를 더 많이 받은 fork이므로 위 쪽 fork보다 네트워크의 concensus 비중(혹은 지지도)가 더 높다고 할 수 있습니다. LMD GHOST rule은 아래쪽 fork를 선택하여 consensus; 지지도를 반영했다고 볼 수 있습니다.

LMD GHOST에 따른 진행 방식은 블록 생성할 때 투표하여 canonical체인을 정하기 때문에 기존 비트코인이나 이더리움 1.x의 conformation 과정과 비교하면 Parallel Conformations 하다고 볼 수 있습니다. 기존 비트코인 체인이나 이더리움 1.x 체인은 블록이 어느 정도 진행한 후에 conformation이 되었다고 통상적으로 얘기합니다. (비트코인의 경우 6 blocks confirm, 이더리움의 경우 12 blocks confirm)

하지만 LMD GHOST는 블록을 생성할 때마다 투표를 하여 canonical 체인을 정해 나갑니다. 대부분의 경우 위 그림 2)와 같이 아래 포크가 canonical 체인으로 결정되면 위 체인으로 reorg되지 않습니다. 따라서 블록이 생성되면서 conformation도 같이 되는 특징이 있습니다.

Saved message attacks이란 공격자가 투표를 하지 않고 있다가 어느 시점에 투표를 한번에 하는 방식으로 fork choice를 변경할 수 있습니다. 이 공격 방식은 LMD GHOST rule에서 justification point를 각기 다른 fork에 만들어 finalized point만드는 것을 다소 지연할 수 있습니다. 이 공격 방법을 사용하려면 특정 조건이 충족되어야 합니다. 예를 들어 2개의 fork가 있다고 가정하고 공격자가 자신의 투표로 fork를 바꿀 수 있게 양 fork에 투표가 배분되어 있어야 합니다.

참조 : https://ethresear.ch/t/decoy-flip-flop-attack-on-lmd-ghost/6001

LMD GHOST rule에 FFG를 적용했을 때 블록 진행방식입니다.
1. finalied된 block 또는 genesis block(B1)을 선택합니다.
2. 그 다음 가장 높은 epoch의 justified block(B2)을 선택합니다. (justified block은 finalized block의 자손 블록입니다.)
3. B2부터 canonical 체인을 찾기 위해 LMD GHOST rule을 사용합니다.

가능성이 희박하지만(edge case)로 특정 조건을 충족할 때, 즉 공격자가 자신의 투표로 fork를 정할 수 있는 경우 saved message attack으로 finalized point 생성을 막을 수 있습니다. 다시 말하면 양 쪽 fork에 justified point를 만들어 finalize를 못 하게 하는 것입니다.

이 공격을 완화(mitigate)하기 위해 Eth 2.0의 finality rule은 case k=1, case k=2를 가정하여 finalized point를 생성합니다.

참조 : https://ethresear.ch/t/analysis-of-bouncing-attack-on-ffg/6113

Randomness in ETH 2.0

예상할 수 없고 비 편향적인 무작위 난수를 구하는 것은 Proof of Stake에서 매우 중요합니다. 왜냐하면 블록을 제출하는 Proposer, 블록을 검증하는 Committe를 선택할 때 무작위 난수를 사용하기 때문입니다. Eth 2.0에서는 RANDAO를 통해 무작위 난수를 구합니다.

RANDAO의 기본 아이디어는 다음과 같습니다.
예를 들어 n명의 사람이 무작위 난수를 만든다고 합시다. 각자 한명씩 숫자(x)를 만들어 냅니다. 그 다음 XOR값을 계산합니다. (Compute XOR(x1, x2, …)) 이로써 무작위 난수를 만들어 낼 수 있습니다.
하지만 문제는 마지막 사람은 모든 제출된 값을 볼 수 있기 때문에 자신의 값을 바꿔 원하는 난수를 얻으려고 할 가능성이 있다는 것입니다.

따라서 제출된 값을 보지 못하게 먼저 제출된 값의 해쉬값을 제출하고 나중에 해쉬값으로 제출된 값을 검증하는 방법을 사용하게 됩니다. 이 방법에 따라 위 예를 변경하면 n명의 사람이 무작위 난수를 만든다고 했을 때 각자 한명씩 숫자(x)를 만들어 내고 그 값을 해쉬하여 제출합니다. (i.e. hash(x)) 그리고 XOR값을 계산합니다. (Compute XOR(x1, x2, …))
이것으로 모든 사람들의 x값이 노출되었기 때문에 난수를 조작할 수 없습니다. 하지만 그 전에 해쉬값의 preimage 값인 x값을 노출하지 않으면 process를 멈추게 할 수 있습니다.

무작위 난수를 만들기 위한 값(reveal11, reveal12, reveal13, …)을 BLS Signature로 서명(i.e. reveal = BLS_SIGN(e, sk)); e = epoch, sk = secret key 하여 블록에 제출합니다. 그다음 reveal 값을 XOR 연산하여 무작위 난수를 만듭니다.

마지막 revealer가 무작위 난수값을 미리 계산하여 마음에 들지 않으면 블록을 제출하지 않을 수 있습니다. 만약 revealer가 다른 slot에 자신의 다른 validator 노드를 갖고 있다면 편향은 더 커질 수 있습니다.
만약 RANDAO + longest chain fork choice를 사용한다면 36%의 stake로 네트워크가 공격받을 수 있습니다.

참조: https://ethresear.ch/t/verifiable-delay-functions-and-attacks/2365

VDF(Verifiable delay functions)의 기본 아이디어는 연산과정을 늦춰 마지막 revealer가 그 값을 예상할 수 없게 하는 것입니다. 마지막 revealer는 다른 revealer와 마찬가지로 결과값을 알지 못한 채 reveal 값을 제출해야 합니다.

BLS signature and aggregation

BLS signature가 어떻게 동작하는지 알아보겠습니다. N은 어떤 group의 member의 수, S는 private key, SIG는 S로 sign한 message, P는 S로부터 만들어진 public key라고 하겠습니다.

Group의 각 member는 private key의 일부만 들고 있습니다. si라고 하겠습니다. 그러므로 누구도 전체 private key인 S를 갖고 있지 않고 혼자서 SIG를 만들어 낼 수 없습니다. 각 member는 자신의 si를 가지고 message에 sign합니다. sigi라고 하겠습니다. sigi를 aggregate하여 SIG를 만들게 됩니다.

BLS signature를 사용하는 목적은 블록에 attestation, 즉 투표를 집계하고 검증할 때 현저한 효율을 보여주기 때문입니다. 예전 모델에서는 Eth 1.0의 Casper 컨트랙트에서 각자 private key로 sign한 vote를 하나씩 검증했습니다. 하지만 이 방법은 Eth 1.0의 한계로 현실적인 방안이 되지 못 합니다.

BLS signature를 도입함으로써 propose, attestation를 효과적으로 집계 및 검증할 수 있게 되어 참여 가능한 Validator를 늘리고 체인에 참가하기 위한 예치금을 낮출 수 있었습니다.

BLS signature는 Beacon Block propose, Beacon Block attestation, Eth1 data voting, cross link attestation 등 다수의 서명을 모으고 검증하는 데 사용됩니다.

Life of An Ethereum Beacon Chain Validator

Validator Status는 Activation Eligibility, Activation, Exit, Withdrawable로 나누어져 있습니다. 이중 Withdrawable은 Phase 2에 구현될 예정입니다.

Weak subjectivity는 Proof of Stake에서 생길 수 있는 문제로 유효한 체인을 일정 기한내에 찾지 못하여 공격자가 유효하지 않은 블록을 전파 하더라도 받아 들일 위험이 있는 경우를 말합니다.

예를 들어 6개월 후에 공격자가 유효하지 않은 블록을 만들어 전파한다고 하겠습니다. 공격자는 4개월 후에 이미 exit하고 6개월 후에 유효하지 않은 블록을 만들어 전파합니다. 6개월 후에 새로 참여한 사용자가 있다고 하겠습니다. 이 사용자는 공격자의 유효하지 않은 블록을 받을 가능성이 있습니다.

하지만 공격자는 이미 exit하여 처벌을 할 수 없습니다. (이 문제는 deposit length(e.g. 4개월)를 두어 해결할 수 있습니다. deposit length를 넘는 기간을 revert하는 거래는 refuse 하도록 하고 deposit length 기간마다 기록을 남기게 하는 것입니다.)

하지만 가능성은 희박하지만 이 문제가 생길 경우가 있습니다. 사용자가 네트워크에 새로 참여하거나 deposit length(e.g. 4개월)기간 동안 오프라인 상태에 있다가 다시 참여하는 경우입니다.

Rate-limiting entry / exit queues는 epoch 당 entry와 exit을 제한하여 보다 보수적으로 Validator set을 운영하기 위함입니다.

churn rate를 사용하여 epoch 당 가능한 enter / exit을 조절합니다.

Validator가 되려면 Eth1 Chain의 Deposit 컨트랙트에 최소 32 ether를 예치합니다. Deposit 컨트랙트에서 이벤트를 발생시키고 Beacon Chain에서는 이벤트를 받아 Validator 관련 프로세스를 진행합니다.

예치한 다음 Validator 대기열에 들어가게 됩니다. 4 epochs(~25.6분)의 시간이 지나고 churn rate에 따라 특정 epoch에 Activated 상태가 됩니다.

Activated가 된 후 Validator는 2**9 epochs(9일) 동안 인출할 수 없습니다. Voluntary Exit은 자기 의사에 따라 exit하는 것으로 exit 대기열에 들어가게 됩니다. 이후 4 epochs(~25.6분)의 시간이 지나고 churn rate에 따라 특정 epoch에 Unslashed n’ Exited 상태가 됩니다. Unslashed n’ Exited 상태가 되는 다른 경우도 있습니다. balance가 부족한 경우 시스템에 의해 exit 대기열로 옮겨지게 됩니다.

2**8 epochs(~27시간) 이 지나 인출이 가능한 Withdrawable 상태가 됩니다. Withdrawable 상태가 되기 전 일정 시간을 두는 이유는 Validator의 악의적인 행동을 잡아 slash하기 위해서 입니다.또한 마지막 Shard 보상을 받을 수 있게 시간을 제공해 주는 목적도 있습니다. custody 게임 챌린지를 위한 목적도 있습니다.(custody 게임은 Phase 1에 구현될 예정입니다. 여기서는 언급하지 않겠습니다.)

Slashing 당한 경우입니다. 4 epochs 기간이 지나 Slashed n ‘Exited 상태가 바뀌고 2 ** 13 epochs(~36 기간이 지나면 거쳐 Withdrawable 상태가 됩니다. 룰에 어긋나는 행위로 Exit하기 때문에 Withdrawable 상태가 될 때까지 다소 긴 기간을 두고 있습니다.

State Transition Function

Beacon Chain은 크게 BeaconState와 BeaconBlock으로 나누어 볼 수 있습니다. BeaconState는 Beacon Chain이 기능하기 위한 전반적인 정보를 저장합니다. BeaconBlock는 slot 기준으로 정보를 저장하고 그에 따라 BeaconState의 정보를 변경합니다.

BeaconState

  • History : 머클링하여 block root, state root를 저장합니다.
  • Eth1: 블록 제출자, 즉 Proposer들의 50%이상이 eth1_data에 합의하면 state에 저장됩니다. deposit 정보는 Merklizing되어 eth1_data root에 포함됩니다.
  • Shuffling :Randomness를 위한 RANDAO 관련 필드입니다.
  • Attestations :Attestations 정보가 담겨 있습니다.
  • Finality : Casper FFG의 적용(finality point생성)과 관련이 있습니다.
  • CrossLinks 필드는 CrossLinks 정보를 담고 있습니다.

BeaconBlockBody

  • randao_reveal : randomness를 생성하기 위한 참여자의 reveal값입니다. reveal값은 BLS public key로 signing한 BLS signature 값입니다.
  • eth1_data: eht1_data(deposit data)에 대한 block voting 정보등이 있습니다.
  • graffiti: 임의의 정보를 넣을 수 있습니다.
  • operations: 일반 사용자 간 transaction이 아닌 system-level transaction을 의미합니다.

1) proposer_slashings : proposer(블록 제출자)의 slashing 정보를 관리합니다.

2) attester_slashings : attester(블록 검증자)의 slashing 정보를 관리합니다.

3) attestations : attestation data를 저장합니다.

4) deposits, voluntary exits : validator registry와 관련이 있습니다.

Beacon Chain을 구성하고 있는 모듈입니다. 각 모듈은 상속관계가 아닌 독립적인 모듈로 작동합니다. 각 모듈에 대한 상세 설명은 State Transition 과정 설명 때 하도록 하겠습니다.

기능에 따라 분류해 보면

  • TIME, ROOTS, RANDOMNESS : Beacon Chain에서 전반적으로 사용되는 모듈로 볼 수 있습니다.
  • EXITS, REGISTRY, DEPOSITS, ETH1 :Validator regestry와 관련이 있습니다.
  • SLASHING, CROSSLINKS, ATTESTATIONS, JUSTIFICATION, FINALISATION은 finalized point를 만드는 것과 관련이 있습니다.

State Transition 과정을 하나씩 보도록 하겠습니다. 파란색은 BeaconState, 녹색은 BeaconBlock을 나타냅니다.
State Transition이 일어나면 slot 필드의 slot이 하나씩 증가합니다. genesis_time과 fork는 Beacon Chain 업그레이드를 하지 않는 한 변경되지 않습니다.

block root와 state root가 slot 단위로 Merklizing되어 BeaconState에 저장됩니다. historial_roots는 찾고자 하는 특정 블록 및 state에 대한 대한 Merkle Proof를 제공합니다.

블록을 생성할 때 무작위 난수를 생성하기 위한 정보를 제출합니다.

randao_mixes를 통해 각 블록의 randao_reveal을 취합하여 XOR 연산 하여 randao_mix로 BeaconState에 저장됩니다. 매 epoch마다 반복하게 됩니다.

Validator와 예치금을 관리합니다.

Validator는 2개의 Public Key를 갖고 있습니다. 하나는 온라인에 노출되어 있는 hot key라고 볼 수 있으며 attestation에 쓰입니다.(pubkey 필드), 또 다른 하나는 온라인에 노출되어 있지 않은 키로 cold key라고 볼수 있으며 deposit한 ETH를 withdraw할 때 사용합니다. 따라서 공격자가 해킹하여 hot key와 연관된 secret key를 알아도 deposit ETH를 withdraw 할 수는 없습니다.

Validator가 되려면 ETH 1 체인에 배포된 deposit contract에 ETH를 deposit해야 합니다.

deposit 정보는 ETH 1 체인에 있기 때문에 deposit 정보가 유효한지 검증하는 투표를 해야 합니다.

Active Validator 중에 선출된 Eth1 committee는 ETH 1 체인의 블록에 투표합니다. eth1_data는 투표한 블록의 hash값이 저장되어 있습니다.

Block Proposer는 ETH 1 data를 Beacon Block에 포함하여 블록을 제출합니다.

Honest Majority Assumption은 Beacon Chain의 Validator 중에 2/3이상이 정직하다면 random sampling을 통해 1/2 이상의 정직한 Validator를 선출할 수 있다는 가정입니다.

BeaconBlock에서 slot 단위로 attestation이 합산되어 BeaconState에 저장됩니다.

  • Attestation
    aggregation_bits : BLS signature를 aggregate하여 Validator의 attestations 여부를 저장합니다.
    data : AttestationData를 참조합니다.
  • AttestationData
    beacon_block_root : LMD GHOST fork choice rule을 위한 vote입니다.
    source : Casper FFG vote에서 source로 쓰이는 checkpoint입니다.
    target : Casper FFG vote에서 target으로 쓰이는 checkpoint입니다.
    crosslink : crosslink의 data가 유효한지에 대한 vote입니다.
  • Checkpoint
    epoch : 해당 checkpoint의 epoch입니다.
    root : 해당 블록의 root hash입니다.
  • Crosslink
    shard : shard number입니다.
    start_epoch : Crosslink의 시작 epoch입니다.
    end_epoch : Crosslink의 끝 epoch입니다.
    data_root : shard data의 root hash입니다.

Justification Point를 생성합니다. attestation은 BLS signature로 justification_bit에 저장되고 2 / 3 이상의 attestation이 있다면 justified_checkpoint로 저장하게 됩니다.

Finalized Checkpoint를 생성합니다.

slashing을 관리합니다. rule을 어기는 행동을 할 경우 block에 false proof가 저장되고 즉시 balances가 차감됩니다.

Crosslink는 각 샤드 체인의 state / block 정보를 Beacon Chain에 올려 둔 것입니다. 일반적인 경우 하나의 epoch 당 하나의 Crosslink를 만들게 됩니다. Phase 0에서는 샤드 체인을 구현하지 않으므로 0으로 채워진 32 bytes value가 만들어 집니다.

결론
Beacon Chain은 샤드 체인의 원활한 운영을 위해 Validator 등록 및 탈퇴 관리, 무작위 난수 생성, Proof of Stake 컨센서스 제공, crosslink를 통한 샤드 간 커뮤니케이션 관리 등의 역할을 수행합니다. 이를 위해 Casper FFG + LMD GHOST(컨센서스), RANDAO(무작위 난수 생성), BLS Signature(다수의 서명 검증) 등 다양한 기술을 구현하고 있습니다.

Onther-Tech

Building an Ethereum Blockchain ECO system to Change the World

Jake Song

Written by

Jake Song

blockchain engineer, Onther Inc developer, interested in developer’s culture

Onther-Tech

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