[이더리움2.0 깊이보기 시리즈]Cross Shard Communication — Sync [3편]
동기적 샤드 간 커뮤니케이션(Sync Cross Shard Communication)
이더리움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
샤드 간 통신(Cross Shard Communication)에서 동기적인 통신 방법을 사용할 수 있다면 기차와 호텔 문제(Train and Hotel Problem)는 쉽고 간단하게 풀릴 수 있습니다. 하나의 거래로 서로 다른 샤드에 있는 기차 컨트랙트와 호텔 컨트랙트에서 예약을 한다면 비동기적인 통신 방식과 같이 일정 시간(Crosslink Finalization)을 기다릴 필요없이 거래를 확정할 수 있습니다. 만약 예약 중에 하나라도 실패한다면 거래는 단순히 상태를 되돌리거나(revert) 또는 throw하면 될 것입니다. 하지만 동기적 샤드 간 거래(Sync Cross Shard Transaction)를 구현하는 것은 상당히 어려운 문제입니다. 아직은 아이디어에 대한 논의 진행 단계라고 볼 수 있으며 구현에 대한 구체적 논의는 이루어지진 않고 있습니다. 이 글에서는 동기적 샤드 간 거래(Sync Cross Shard Transaction)에 대한 논의의 기반이 되는 개념인 지연 상태 실행(Delayed State Execution)을 소개하고 비탈릭이 제시한 모델(A Simple Synchronous Cross Shard Transaction Protocol)을 소개하면서 동기적 샤드 간 거래(Sync Cross Shard Transaction)에 대해 논의해보도록 하겠습니다.
지연 상태 실행(Delayed State Execution)
동기적 샤드간 거래(Synchronous Cross Shard Transfers)에 대한 논의는 지연 상태 실행(Delayed State Execution)에 기반을 두고 있습니다. 지연 상태 실행의 기본 개념은 합의과정(Consensus)과 상태 실행(State Execution)을 분리하는 데 있습니다. 예를 들어 이더리움 1.0은 합의 과정과 상태 실행은 같이 이루어 집니다. Fork Choice Rule(이더리움 1.0의 경우 GHOST protocol)에 따라 체인이 정해지고 마이너는 블록에 거래를 저장하고 상태 루트를 연산하여 저장합니다. 그리고 블록을 전파하면 다른 노드는 블록에 저장된 거래를 다시 실행하여 상태 루트를 연산하여 검증을 합니다. 하지만 지연 상태 실행(Delayed State Execution)은 합의과정(Consensus)와 상태 실행(State Execution)을 분리합니다. 다시 말하면 Fork Choice Rule에 따라 정해진 블록에 거래를 기록하는 과정과 블록에 기록된 거래를 연산하여 상태 루트(State Root)를 만드는 과정을 분리하는 것입니다. 이더리움 2.0에서 간단한 모델을 가정해 보면,
- 이더리움 2.0에 예치한 누구나 상태 루트 제출(State Root Claim)에 참여할 수 있게 합니다.
- 특정 시기(Epoch)마다 상태 루트를 제출(Claim)할 수 있도록 합니다.
- 이 제출(Claim)은 이더리움 2.0 체인에 저장됩니다.
- 제출(Claim)은 [height, shard, state_root, signature]의 형태가 될 수 있습니다.
- 한편 상태를 연산하여 상태 루트를 산출하는 특정 사용자 그룹이 있다고 가정합니다.
- 산출한 상태 루트와 제출(Claim)의 상태 루트가 같을 경우 제출(Claim)을 한 사용자에게 예치금에 비례하여 보상을 해줍니다.
- 만약 다를 경우 제출(Claim) 사용자의 예치금을 삭감합니다.
이 모델은 풀노드를 가지고 있어 상태를 직접 연산할 수 있거나 풀 노드로부터 정보를 받아 연산할 수 있어야 합니다. 이를 위해서는 슈퍼 풀 노드, 즉 샤드체인 전체의 정보를 가지고 있는 노드이거나 특정 하나의 샤드의 정보를 가지고 있고 다른 샤드의 정보는 라이트 클라이언트(Light Client)를 통해서 가져올 수 있어야 합니다. 실제로는 슈퍼 풀 노드보다는 하나의 샤드에서만 풀 노드이고 나머지는 라이트 클라이언트로 다른 샤드의 정보를 가져오는 형태가 일반적일 것입니다. 또는 트루빗 검증게임과 같은 시스템을 추가하는 것도 가능할 것입니다.
A Simple Synchronous Cross Shard Transaction Protocol
동기적 샤드 간 거래(Synchronous Cross Shard Transaction)는 바로 지연 상태 실행(Delayed State Execution)에 기반하여 만든 개념입니다. 동기적으로 거래를 처리한다는 것은 하나의 거래로 두개의 샤드의 상태를 아토믹(Atomic)하게 변경할 수 있어야 합니다. 기차와 호텔문제(Train And Hotel Problem)을 예로 들어보면
하나의 거래로 A 샤드 체인에서 기차 예약을 한 다음 B 샤드 체인에서 호텔을 예약합니다.
하지만 A 체인이 재구성(reorg)된다면 기차 예약 정보는 없어지고 B체인에 호텔 예약 정보만 남게 되어 거래는 실패하게 됩니다. 만약 Fork Choice Rule을 변경하여 A체인이 재구성(reorg) 되면 B체인도 재구성(reorg)시킬 수도 있을 것입니다. 하지만 이 문제는 성능 저하 및 Dos 공격에 노출될 위험도 있습니다.
이러한 동기적 샤드간 거래 문제를 해결하기 위해 상태 실행 엔진(State Execution Engine) 즉 상태(State)를 직접 연산할 수 있는 클라이언트가 제시되었습니다.
A 샤드에서 블록 높이 N-1일 때의 상태를 알고, 나머지 샤드의 블록 높이 N-1일 때의 상태 루트를 알고 있는 노드를 가정합니다. 그리고 A 샤드의 블록 높이 N의 유효한 블록 해시, 블록 데이터를 알고 있다고 가정합니다. 여기서 유효한 블록 해시가 주어졌다고 가정 했지만 만약 위 재구성(reorg)의 예와 같이 특정 샤드체인이 상태(State)가 되돌려(revert)진다면 상태(State) 실행 프로세스(State execution process)도 상태(State)가 되돌려(revert)질 것입니다. 하지만 다른 샤드의 상태(State) 실행 프로세스(state execution process)는 상태(State)가 되돌려질(revert) 필요가 없습니다.
녹색은 노드가 알고 있는 정보, 회색은 아직 알려지지 않은 정보, 노란색은 블록, 사각형은 상태 루트(State Root), 원은 블록을 포함한 모든 데이터를 의미합니다.
그 다음 블록에 key => value 형식의 머클 트리를 가정합니다. 맵핑은 address => tx의 형식으로 하며 tx는 각각 [shard[1], address[1], shard[2], address[2] … shard[n], address[n], data]의 형식을 갖습니다. tx를 특정 샤드에서 실행한다면 다음과 같은 조건을 만족시켜야 합니다. tx가 정의하고 있는 모든 (shard, address) 짝은 특정 샤드 블록의 머클 트리에 접근했을 때 tx에 정의되어 있는 샤드의 주소에서 tx를 반환(return)할 수 있어야 합니다. 예를 들어 tx에 [A, 123, A, 485, B, 769, data] 다음과 같이 정의되어 있다면 데이터를 실행하기 위해서 거래는 반드시 A 샤드의 블록 N의 address 123, A 샤드의 블록 N의 address 485, B 샤드의 블록 N의 address 769에서 반드시 반환(return)되어야 합니다.
이러한 규칙을 정한 이유는 두 개의 샤드 간 거래(Cross Shard Transaction)가 같은 블록 높이에서 같은 계정에 한 번만 영향을 주도록 하기 위해서 입니다. 만약 한 계정에 여러 거래가 영향을 미친다면 클라이언트는 각각의 상태를 제대로 실행하기 위해 하나씩 다운로드하여 검증하여야 합니다. 예를 들어 [A.a, B.b]는 A 샤드의 a계정, B 샤드의 b계정이라고 해보겠습니다. 만약 100개의 샤드가 있다고 가정할 때 tx가 [A.a, B.b], [A.a, C.c], [A.a, D.d], …[A.a, N.n] (N = 100) 이라면 클라이언트가 tx들을 실행하기 위해서는, 즉 동일한 블록 높이에서 한번에 거래들이 실행되도록 하려면 하나씩 상태를 받아 실행해야 합니다. 예를 들어 [A.a, B.b]의 거래를 실행한 다음 [A.a , C.c]를 실행하려면 다시 A 샤드와 B 샤드의 변경된 상태를 받아 [A.a, C.c]를 실행해야 하고 이런 과정을 100번 반복해야 하는 문제가 발생할 수 있습니다. 또는 [A.a, B.b], [B.b, C.c], [C.c, D.d] … 와 같은 식으로 서로 연쇄적으로 실행하는 경우에도 같은 문제가 발생할 수 있습니다.
클라이언트는 다음과 같이 이 모델을 구현할 수 있습니다.
- 먼저 샤드 A의 블록 N을 다운로드 합니다.
- tx에 정의된 샤드의 블록 N-1의 계정의 상태를 가져옵니다. 구체적으로 해당 샤드의 관련된 계정의 Merkle Branch를 가져옵니다. 또한 블록 N을 가져옵니다.
- 샤드 A의 블록 N의 모든 거래에 대해 위의 규칙을 적용하여 유효한지 검증합니다.
네트워크에 요청한 Merkle Branch 정보를 갖고 샤드 A의 모든 tx의 (shard_id, addr)을 체크하여 거래 T를 반환(return)하는지 확인합니다. 만약 반환(return)하지 않는 다면 상태를 되돌리거나(Revert) 또는 Throw 처리합니다.
- 검증 과정을 통과했다면 다른 샤드에서 가져온 블록 N과 Merkle Branch를 가지고 상태 실행(State Execution)을 합니다. 다른 샤드의 상태 루트를 제출(claim)합니다.
- 제출(Claim)한 상태 루트를 검증하기 위한 방법으로 Cryto Economical Design을 사용합니다. 예를 들어 상태 루트를 제출(Claim)하는 방법으로 ZK-SNARK proof를 만들어 상태 루트를 제출(Claim)할 수도 있을 것입니다. 또는 트루빗 검증게임 방식을 사용할 수도 있습니다. Claim을 검증하고 검증 결과에 따라 보상 및 처벌을 할 수 있는 방식이라면 다른 방법도 가능합니다.
각 샤드 체인을 동기화하기 위해 블록 높이 대신 slot을 사용합니다. slot은 시간에 따라 구간을 나눈 것으로 일정 시간(하나의 slot)에 블록 하나를 제출(이더리움 1.0의 경우 마이닝)해야 하며 제출하지 않았다면 빈블록으로 간주합니다.
Conclusion
Phase 2에서 구현될 예정인 샤드 간 통신(Cross Shard Communication)은 현재 구현을 위해 스펙을 정의하는 단계 보다는 어떻게 디자인할지 논의하는 단계에 가깝다고 할 수 있습니다. 앞으로 리서치 및 논의에 따라 많은 부분이 변경될 수도 있습니다. 하지만 현재까지 리서치 진척 상황을 볼 때 풀지 못 한 난제는 없다고 생각되며 현재 리서치에서 집중하는 부분은 보다 더 효율적으로 안정적으로 구현할지에 대해서 입니다. 이제 이더리움 2.0은 아이디어 제시나 개념 증명은 거의 마무리 되었으며 실제 구현 단계에 와 있습니다. 여러 팀들이 Phase 0 단계 구현을 진행하고 있고 테스트넷을 런칭하고 있습니다. 이더리움 2.0이 실제로 눈 앞에 다가올 날이 머지 않았습니다.
Reference
- Delayed Execution Model
https://ethresear.ch/t/delayed-state-execution-in-practice/1041 - Simple Synchronous Cross Shard Transaction Protocol
https://ethresear.ch/t/simple-synchronous-cross-shard-transaction-protocol/3097
