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

Aiden Park
Tokamak Network
Published in
15 min readJan 13, 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

Overview

Phase 1의 핵심은 Phase 0에 도입된 비콘체인(Beacon chain)에 의해 검증될 여러개의 샤드체인(Shard chain)을 도입하는 것입니다. Phase 1에 샤드체인이 도입되기는 하지만 샤드체인은 실질적으로 어떠한 연산도 처리하지 않고, 오직 임의의 데이터만 저장하는 기능만 수행할 수 있습니다. 결국 Phase 1 또한 Phase 0와 같이 완전한 샤딩을 위한 준비단계라고 할 수 있습니다.

Shard Chain

당초 이더리움 2.0에 도입될 샤드체인의 수는 1024개로 예정되어 있었으나, 샤딩 구조를 보다 단순화하기 위해 64개로 줄어들었습니다. 따라서 Phase 1에 도입되는 샤드체인의 수도 64개입니다. 또한 샤드블록의 크기도 최대 64KB에서 최대 512KB로 변경되었습니다. 물론 이더리움의 궁극적인 목표는 샤드체인의 수를 점차 늘려 1024개의 샤드체인을 모두 도입하고, 블록 크기 또한 1MB까지 증가시키는 것입니다.

중요한점은 샤드체인의 수를 줄이면서 슬롯 당 최대 샤드 수도 16개에서 64개로 확대한 것입니다. 이는 매 비콘블록마다 모든 샤드체인의 샤드블록들을 포함할 수 있다는 것을 의미합니다.

Eth2 shard chain simplification proposal

예를 들어 단순하게 샤드체인이 총 2개가 존재한다고 할 때, 위 그림과 같이 모든 샤드체인의 블록이 매 비콘블록마다 포함되게 됩니다. 모든 샤드의 슬롯 N+1의 블록은 다른 모든 샤드의 슬롯 N의 블록을 확인할 수 있게 됩니다. 따라서 Merkle receipt를 통해 단일 슬롯 크로스샤드 통신(single-slot cross-shard communication)을 하는 것이 가능하게 됩니다. 기존의 복잡한 구조보다 훨씬 단순화되면서 모든 비콘블록마다 모든 샤드블록이 포함되기 때문에 가능한 구조입니다.

Shard state transition function

Overview에서 간략하게 언급했듯이 Phase 1의 샤드는 어떠한 연산도 수행하지 않습니다. 실제로 Phase 1 스펙의 상태 전이 함수(state transition function)을 확인하면 단순히 해싱과정만 거쳐 새로운 상태 루트(state root)값을 출력하는 것을 확인할 수 있습니다.

shard state transition function

Shard Committee

샤드체인의 블록들이 비콘체인의 위원회(Committee)에 의해 검증되고, 비콘체인에 포함되어 완결되기 위해서는 이러한 블록들을 위원회에 제안하는 역할을 수행할 사람이 필요합니다.

이러한 역할을 수행하는 이를 제안자(Proposer)라고 하며, 이는 비콘블록의 제안자와 별개의 개념으로 비콘체인의 위원회가 아닌 개별 샤드 위원회(Shard committee)에 소속된 제안자를 의미합니다. 샤드 위원회는 256에폭(약 27시간)마다 검증인들 중에서 랜덤하게 선정됩니다. 이렇게 선정된 샤드 위원회에서 샤드블록들을 제안할 제안자를 선정하게 됩니다.

하지만 샤드 위원회에서 제안자가 매번 선정된다고 해서 반드시 모든 샤드 블록들이 매번 정상적으로 위원회에 제안된다는 보장을 할 수는 없습니다. 따라서 이러한 경우 해당 슬롯의 위원회에 소속된 검증인들은 제안이 이루어지지 않았다는 의미로 “제안 없음"에 투표하게 됩니다.

Shard Fork Choice Rule

샤드 체인 또한 포크 선택 규칙(Fork-choice rule)으로 비콘체인과 같이 LMD GHOST방식을 따릅니다. LMD GHOST는 최근 메세지를 기반으로 가장 많은 지지를 받은 쪽을 선택하는 것으로, 간단하게 다음과 같이 동작합니다.

  • 상태가 올바르고 데이터가 모두 접근가능한 샤드블록 B에 대해, 검증인들이 B나 혹은 B의 자손블록에 대해 지지하는 가중치를 계산합니다. 이렇게 계산한 가중치를 B의 점수라고 하겠습니다. 물론 앞서 언급한 것처럼 해당 슬롯에 샤드블록이 없을수도 있기 때문에 빈 샤드블록 또한 점수를 가질 수 있습니다.
  • 다음 슬롯의 샤드블록으로 가장 높은 점수를 가진 샤드블록을 선택합니다.

Shard Block Validation

이상적인 경우 샤드블록들은 매 슬롯마다 비콘블록에 포함될 것이고, 검증인 중 2/3보다 많은 수가 이를 동의하는 검증 투표를 할 경우에만 정상적으로 완결 과정을 거칠 수 있게 됩니다.

Eth2 shard chain simplification proposal

위 그림은 샤드블록의 처리 과정을 단순화하여 표현한 그림입니다. 이상적인 Best case의 경우 매 슬롯의 비콘블록마다 모든 샤드체인의 블록들이 포함됩니다. 이를 통해 아래 샤드체인의 블록 B는 다른 샤드체인의 이전 슬롯 블록을 비콘블록을 통해 확인할 수 있게 됩니다.

하지만 매번 비콘체인에 모든 샤드블록들이 포함되지 않는 경우도 존재할 수 있습니다. 아래의 Exceptional case가 그러한 경우인데, A2가 비콘체인에 포함되지 못했고, 다음 비콘블록에 A2를 포함하여 두개의 샤드블록이 동시에 포함되는 것을 확인할 수 있습니다. 이 경우 아래 샤드체인의 블록 B는 A1은 확인할 수 있지만 A2는 확인할 수 없게 됩니다.

Process

위 내용을 모두 종합하여 비콘블록과 샤드블록이 생성되는 과정을 다음과 같이 간단하게 정리할 수 있습니다.

  1. 비콘블록 N이 생성된다.
  2. 샤드 i에서, i의 제안자가 샤드블록을 제안한다. 이 샤드블록은 비콘블록 N을 포함한 이전 블록들의 루트를 모두 확인할 수 있다.
  3. 샤드 i에 할당된 검증인들이 검증 투표를 한다. 이는 슬롯 N의 비콘블록과 슬롯 N의 샤드 i의 샤드블록에 대한 투표이다. (물론 위 그림과 같이 예외적인 경우에 이전 샤드 블록에 대한 투표도 포함할 수 있다)
  4. 비콘블록 N+1이 생성된다. 이 블록은 모든 샤드에 대한 검증투표를 모두 포함하며, 투표 결과에 따라 모든 샤드의 최신 상태를 업데이트한다.

The Proof of Custody Game

Phase 1에서 샤드체인과 함께 도입되는 커스터디 게임(custody game)은 수 많은 샤드체인이 동작하는 이더리움 2.0에서 데이터 가용성(Data availability)을 확보하기 위한 방법 중 하나입니다. 따라서 이를 이해하기 위해서는 우선 데이터 가용성이 무엇이고, 또 샤딩의 관점에서 어떠한 의미를 갖는지 먼저 살펴볼 필요가 있습니다.

커스터디 게임에 대한 설명의 대부분은 EDCON 2019에서 Justin Drake의 발표에 기반하고 있습니다. 발표 영상은 여기서 직접 확인할 수 있습니다.

Data availability

EDCON 2019 Slides

보통 블록체인의 경우 위 그림과 같이 블록 데이터를 하나의 해시인 머클 루트(Merkle root)로 압축하여 표현합니다. 이 때 이 해시만 주어졌을 때 해당 데이터가 무엇인지 알기 위해서는 결국 데이터를 다운로드 해야 합니다.

이러한 방식은 기존의 이더리움이나 비콘체인과 같이 비교적 작은 데이터를 다룰 경우 크게 문제가 없지만, 샤딩과 같이 수 많은 샤드가 동작하고 상당한 크기의 데이터를 다뤄야 할 경우 문제가 발생하게 됩니다.

EDCON 2019 Slides

예를 들어, 각 샤드가 1분당 1MB의 대역폭을 갖는다고 가정해보겠습니다. 이 경우 1024개의 샤드가 있을 때 전체 네트워크가 감당해야 할 총 데이터 크기는 분당 1GB에 달하게 됩니다. 이 경우 모든 데이터를 무작정 다운로드하는 것은 매우 큰 부담이 될 것입니다.

EDCON 2019 Slides

때문에 이더리움 2.0에서 비콘체인은 샤드체인의 요약본만을 포함할 뿐 모든 샤드체인의 데이터를 포함하지 않습니다. 즉, 모든 검증인들이 모든 샤드의 데이터를 다운로드 해야 할 필요가 없습니다.

EDCON 2019 Slides

모든 검증인들이 모든 샤드 데이터를 확인하고 검증하지 않기 때문에, 해당 샤드에 대해 일부 검증인들만 데이터를 확인하고 검증하게 됩니다. 문제는 바로 여기서 발생합니다.

해당 샤드 블록을 검증하지 않은 다른 노드들이 관련 데이터에 접근할 수 없는 상황이 발생할 수 있기 때문입니다. 이미 샤드 블록은 비콘 블록에 문제 없이 포함 되었지만, 해당 블록의 데이터가 무엇인지 알 수 없다면 이는 큰 문제를 야기할 것입니다. 이를 샤딩에서의 데이터 가용성 문제라고 합니다.

Data availability solutions

EDCON 2019 Slides

데이터 가용성 문제를 해결하기 위한 방법에는 여러가지가 있습니다. Phase 1에서는 커스터디 증명(custody proof)과 챌린지(challenge)를 활용한 커스터디 게임을 활용하여 이를 해결합니다. 하지만 Phase 2 이후 커스터디 게임과 같이 문제를 암호경제학적으로 해결하는 것이 아니라 암호학적으로 해결하는 방향을 도입하는 것을 계획하고 있습니다.

먼저 커스터디 게임이 무엇인지 자세히 알아보기 전에 어떠한 맥락에서 이 솔루션이 도출되었는지 살펴보겠습니다.

EDCON 2019 Slides

우선 Gasper와 같이 모든 검증인 중 적어도 2/3보다 많은 검증인들이 정직하게 행동한다는 가정에서 시작해 봅시다. 이 때 편향되지 않은 랜덤값을 통해 선정된 위원회 중 적어도 과반수 이상은 정직할 확률이 매우 높을 것입니다.

따라서 적어도 이 중에서 투표를 한 사람 중에 정직한 사람이 한명 이상일 확률은 매우 높을 것입니다. 즉, 최소한 한명 이상은 데이터를 모두 다운로드해서 제대로 확인했을 가능성이 매우 높다는 것입니다.

EDCON 2019 Slides

그런데 문제가 하나 있습니다. 바로 경제적 유인의 부재입니다. 위 그림에서 풀 노드(full node)를 운영하는 검증인은 항상 데이터를 모두 다운로드하고 검증투표를 하고, 반대로 라이트 노드(light node)를 운영하는 검증인은 데이터를 확인하지 않고 다른 검증인이 투표한 것을 확인한 후 이를 따라 투표한다고 가정해보겠습니다.

라이트 노드를 운영하는 검증인은 검증 투표에 소모되는 자원은 최대한 절약하면서 풀 노드를 운영하는 검증인과 보상은 동일하게 가져갈 수 있게 됩니다. 항상 풀 노드보다 라이트 노드를 운영하는 것이 경제적으로 이익이 되기 때문에, 대다수의 검증인들은 풀 노드가 아닌 라이트 노드를 운영할 가능성이 매우 높습니다.

하지만 대다수가 라이트 노드를 운영할 경우, 검증은 이루어졌지만 실질적으로 해당 샤드블록이 어떻게 구성 되었는지에 대해서는 확인한 검증인이 없거나 혹은 매우 적은 상황이 발생할 수 있습니다. 극단적인 경우에는 유효하지 않은 블록이 포함될수도 있을 것입니다. 따라서 이러한 행위를 강력하게 그리고 효율적으로 방지할 수 있는 장치가 반드시 필요합니다.

EDCON 2019 Slides

그 장치가 바로 커스터디 비트(custody bit)입니다. 커스터디 비트는 오직 1bit의 크기로 해당 데이터를 모두 확인했는지 아닌지를 증명할 수 있는 증거(proof)입니다. 그렇다면 어떻게 이 커스터디 비트를 이용해 데이터를 확인했음을 증명할 수 있는지, 또 어떻게 위와 같은 행위를 방지할 수 있는지 살펴보겠습니다.

우선 검증인들은 2048에폭(약 9일)마다 보조키(subkey)를 생성할 수 있는데, 이 보조키가 바로 커스터디 비트를 생성하기 위해 사용되는 키입니다. 보조키는 2048에폭마다 검증인의 공개키에 따라 고유하게 결정됩니다. 따라서 검증인이 이더를 예치하는 순간 검증인의 모든 보조키들은 결정됩니다. 중요한점은 해당 검증인이 보조키를 직접 공개하지 않는 한 다른 사람들은 이러한 보조키들을 사전에 알 수 없다는 것입니다. 또한 특정 보조키가 어떠한 검증인의 것인지 항상 검증할 수 있습니다.

검증인은 블록을 검증할 때, 데이터를 일정한 단위(e.g 512 byte)인 청크(chunk)로 나눕니다. 이렇게 나누어진 청크를 보조키를 이용하여 의사 난수 함수(Pseudo random function)를 통해 비트 단위로 나타냅니다. Phase 1에서는 의사 난수 함수로 르장드르 기호(Legendre symbol)를 비트 단위로 표준화한 함수를 사용합니다. 이렇게 청크 개수만큼 비트가 출력되면, 이 비트들을 다시 XOR연산을 통해 하나의 비트로 나타내고, 이것이 바로 커스터디 비트가 됩니다.

EDCON 2019 Slides

중요한 점은 커스터디 비트를 구하는 연산을 반드시 본인이 실행할 강력한 유인이 존재한다는 것입니다. 예를 들어 이러한 커스터디 비트의 연산조차 다른 제 3자에게 위임한다고 가정해 봅시다. 이 경우 제 3자가 연산을 하기 위해서는 이를 의뢰한 검증인의 보조키가 필요합니다. 이는 곧 마음만 먹으면 얼마든지 올바르지 않은 커스터디 비트를 생성하여 해당 검증인의 예치금을 삭감시킬 수 있음을 의미합니다. 이를 막기 위해 키를 공유하지 않는 경우 결국 커스터디 비트를 직접 계산하는 수 밖에 없습니다.

이제 커스터디 비트를 통해 특정 검증인이 커스터디 비트가 올바르게 생성하지 않았을 경우, 해당 검증인의 보조키를 이용하여 다른 검증인들이 이를 확인하여 챌린지를 할 수 있게 됩니다. 챌린지는 2단계로 이루어진 query-respond 방식으로 이루어집니다.

우선 챌린저(challenger)는 데이터는 모두 보유하고 있기 때문에 대상 검증인의 보조키를 확인한 후 이를 이용하여 커스터디 비트가 일치하는지 아닌지, 또는 커스터디 비트는 일치하지만 청크 단위의 비트가 올바른지 아닌지 확인할 수 있습니다.

먼저 비트 챌린지(bit challenge)는 챌린저가 옳다고 생각하는 청크의 bit-field를 제출하고, 이에 대한 루트인 커스터디 비트가 기존에 제출된 것과 일치하지 않음을 보입니다. 이 경우 챌린지를 당한 응답자는 챌린저가 제출한 bit-field가 올바르지 않음을 증명하는 일부 머클 브랜치(Merkle branch)를 제출하여 챌린저가 올바르지 않음을 증명할 수 있게 됩니다. 만약 비트 챌린지가 올바르게 응답될 경우 챌린저의 예치금이 삭감되며, 72시간 내에 어떠한 응답도 없을 경우 응답자의 예치금이 삭감됩니다.

청크 챌린지(chunk challenge)의 경우 챌린저가 검증인이 할당된 데이터의 일부에 대한 인덱스를 특정하고, 응답자는 해당 데이터에 대한 머클증명을 제출해야 합니다. 이 경우에도 동일하게 72시간 내에 어떠한 응답도 없을 경우 응답자의 예치금이 삭감됩니다.

Conclusion

Phase 1은 이더리움 2.0에 본격적으로 샤드체인이 도입되는 단계인만큼 여전히 많은 논의가 진행중이며, 관련 스펙도 계속해서 광범위한 업데이트가 되고 있는 상황입니다. Phase 1이 완료되더라도 샤드체인에서 실질적인 연산은 할 수 없기 때문에 큰 의미가 없다고 볼 수도 있지만, 데이터 자체는 저장할 수 있다는 측면에서 레이어-2 솔루션과의 연계가 활발하게 이루어질 것으로 예상됩니다. 특히 플라즈마와 같은 레이어-2 솔루션의 데이터 가용성을 해결하는 측면에서 Phase 1이 큰 역할을 할 수 있을것으로 기대됩니다.

References

--

--