DSRV Report — Getting ready for Danksharding
Disclaimer: 이 글은 정보 전달을 위한 목적으로 작성되었으며, 특정 프로젝트에 대한 투자 권고, 법률적 자문 등 목적으로 하지 않습니다. 모든 투자의 책임은 개인에게 있으며, 이로 발생된 결과에 대해 어떤 부분에서도 DSRV는 책임을 지지 않습니다. 본문이 포괄하는 내용들은 특정 자산에 대한 투자를 추천하는 것이 아니며, 언제나 본문의 내용만을 통한 의사결정은 지양하시길 바랍니다. 추가로 이 글이 쓰인 시점과 현재 모두 DSRV는 이더리움의 벨리데이터로 참여하고 있었음을 알려드립니다.
‘머지(Merge), 서지(Surge), 버지(Verge), 스콜지(Scourge) 퍼지(Purge), 스플러지(Splurge)’
소녀시대 “Gee”를 떠올리게 하는 이 이름들은 이더리움의 로드맵입니다. 이 로드맵은 병렬적으로 진행되고 있는데요. 오늘은 그중에서도 샤딩을 통해 이더리움 확장성을 향상하려는 ‘서지’ 단계의 목표인 당크샤딩(Danksharding)과 그 첫걸음인 EIP-4844, 즉 프로토 당크샤딩(Proto-Danksharding)을 살펴보려고 합니다. 당크샤딩 및 프로토 당크샤딩이 무엇인지, 그리고 이를 위해 이더리움 생태계 참여자들은 어떠한 노력을 하고 있는지 알아보겠습니다.
당크샤딩(Danksharding)이 무엇인가요?
처음 이더리움이 확장성 로드맵으로 발표했던 샤딩은 1024개의 샤드가 각각 랜덤으로 선정된 벨리데이터로 구성된 샤드 위원회(Commitee)를 가지고 트랜잭션을 나누어 처리하여 블록을 생성하는 방식이었습니다.[1] 하지만 롤업의 발전으로 이더리움이 롤업 중심의 로드맵으로 전환하면서 이더리움에서 직접 트랜잭션을 처리해야 할 필요성이 낮아졌습니다. 따라서 이더리움의 트랜잭션을 병렬 처리하는 것이 아닌, 이더리움을 롤업에서 실행한 트랜잭션들의 데이터 가용성 레이어로 사용하는 데이터 샤딩(data-sharding)이 제안되었습니다. [2]
❗️ 용어 정리; 데이터 가용성 레이어란?
데이터 가용성 문제란 악의적인 블록 생성자가 잘못된 트랜잭션을 실행하였음에도 블록 생성자가 실행한 트랜잭션 데이터를 제공해주지 않아 이를 검증할 수 없게 되는 문제를 말합니다. 따라서 롤업 등은 데이터 가용성 문제로 인하여 실행한 트랜잭션을 검증할 수 있는 데이터를 보다 보안성이 높은 이더리움에 기록하고 있습니다. 이더리움을 데이터 가용성 레이어로 활용한다는 것은 롤업의 데이터를 저장할 수 있는 더 많은 공간을 제공한다는 것을 의미합니다.처음 제안된 데이터 샤딩에는 64개의 샤드 위원회가 존재합니다. 각 샤드 위원회는 DAS(Data Availability Sampling, 데이터 가용성 샘플링)를 통해 롤업의 데이터 가용성을 증명하여 샤드 블록을 생성한 뒤, 이를 비콘체인 블록에 다시 포함합니다. DAS는 전체 데이터를 다운로드하지 않고 일부 만을 샘플링하여 전체 데이터의 가용성을 확인할 수 있는 방식입니다. DAS에 사용되는 erasure coding은 원본 데이터의 크기를 두배로 늘리는대신, 늘어난 데이터의 50%로 나머지 데이터를 모두 복구할 수 있게 합니다. 따라서 샤드 블록의 50%가 확인되면 전체의 데이터 가용성을 보장할 수 있습니다. [3]
하지만 여전히 모든 샤드 위원회가 각각 블록을 생성하고 이를 다시 이더리움에 포함하는 방식은 매우 복잡하며, 지연이 발생할 수 있기 때문에 현재 이더리움이 목표하고 있는 당크샤딩이라는 새로운 디자인이 등장하게 됩니다. [4] 당크샤딩도 이더리움을 데이터 가용성 레이어로 사용하고자 하는 의도를 가지고 있으나, 기존의 데이터 샤딩과 달리 샤드 위원회가 존재하지 않습니다. 대신 당크샤딩은 하나의 이더리움 위원회가 일반 트랜잭션과 샤드 데이터가 함께 포함된 하나의 블록을 생성합니다.
당크샤딩은 블롭(blob)이라는 데이터 구조를 포함한 새로운 유형의 트랜잭션을 추가하여, 이더리움 블록에 데이터 가용성을 위해 평균적으로 16MB, 최대 32MB의 공간을 제공합니다. 하지만 블록의 크기가 증가하면, 블록을 생성하는 노드가 데이터를 저장하고 전파하기 위해 큰 저장공간 및 높은 대역폭을 유지해야 하는 부담을 가지게 됩니다. 따라서 당크샤딩에서는 노드의 부담을 낮추기 위하여 블록 생성 과정에서 PBS(Proposer Builer Seperation)라는 방식을 사용합니다. PBS는 블록 생성 과정의 역할을 분리하여 Builder가 하나의 큰 블록 내용을 구성하고, Proposer(벨리데이터)가 이를 받아 블록을 생성하는 방식입니다. [5]
💡DSRV’s Tip; 당크샤딩의 유래
처음에 PBS는 블록 내용을 구성할 수 있는 권한을 가진 중앙화된 벨리데이터가 MEV를 독점하는 것을 방지하기 위하여 제안되었습니다. 이더리움의 리서처인 Dankrad는 이 PBS를 샤딩에 활용하여 기존 데이터 샤딩을 개선할 디자인을 제안하였고, 따라서 PBS가 접목된 이 샤딩 디자인은 Dankrad의 이름을 따 당크샤딩이라고 명명되었습니다.또한 당크샤딩에서도 노드가 큰 크기의 블롭 데이터를 전부 다운로드 하지 않고 데이터 가용성을 확인하기 위하여 DAS가 필요합니다. 당크샤딩에서는 추가로 2D 샘플링 이라는 개념이 도입됩니다. 당크샤딩은 erasure coding으로 기존에 2배로 늘렸던 원본데이터를 한번 더 2배로 늘려 2D인 정사각형 형태로 확장시킨 후 샘플링을 수행합니다. 이는 하나의 블롭이 아닌 블록 당 샘플링을 하여 더 간단하게 DAS를 수행할 수 있게 합니다. [6]
이처럼 당크샤딩은 샤드 위원회를 제거하고 블롭이라는 커다란 공간을 롤업에 제공하기 위하여, PBS 및 DAS등을 통해 노드가 높은 사양으로 중앙화 되는 것을 방지하게 됩니다. 당크샤딩은 PBS 및 DAS 등 복잡한 구현이 필요한 만큼 단계적으로 진행될 예정입니다. 그 첫 번째 단계가 바로 프로토 당크샤딩입니다.
비탈릭은 최근 테슬라의 스타링크 위성의 사양이 프로토 당크샤딩이 도입된 노드를 작동시키기에 충분하다고 트윗하기도 하였는데요. 프로토 당크샤딩에서는 어떠한 변화가 이루어지는 것일까요?
프로토 당크샤딩(Proto-Danksharding)이 무엇인가요?
프로토 당크샤딩이라고 불리는 EIP-4844는 블롭을 포함한 트랜잭션 (“blob-carrying transactions”)을 도입하고자 하는 업그레이드 제안입니다. [7] EIP-4844에서는 이후 당크샤딩에서도 동일하게 호환되는 데이터 구조인 블롭을 미리 도입하여 당크샤딩을 준비하는 과정이라고 볼 수 있습니다.
현재 롤업은 데이터 가용성을 위하여 트랜잭션 데이터를 기록하기 위해 calldata라는 필드를 사용하고 있습니다. 이는 트랜잭션에 EVM에서 연산되기 위해 전달되는 코드 및 데이터를 적기 위한 필드입니다. 따라서 calldata를 통해 데이터를 기록하는 것은 1byte당 16가스의 비용이 들게 되며, 이더리움에 영구적으로 저장됩니다. 롤업의 데이터는 EVM을 통해 연산될 필요가 없고 단기적으로만 저장하면 되기 때문에, calldata를 사용하는 지금의 방식은 롤업이 필요한 것보다 더 많은 비용을 지불하고 있음을 의미합니다.
반면 당크샤딩은 지금처럼 calldata 필드에 롤업에서 실행된 트랜잭션 데이터를 저장하는 것이 아닌, 블롭이라는 데이터 구조를 도입합니다. 요지는 이 블롭이 EVM이 해석하지 않는 공간이며, 일정한 기간이 지나면 삭제되도록 하여 단기적으로 데이터를 저장할 수 있다는 것입니다. 따라서 블롭은 calldata보다 적은 비용으로 더 많은 공간을 사용할 수 있게 합니다.
EIP-4844는 평균적으로 블롭을 포함한 1MB의 블록을 생성하며, 최대 2MB 크기의 블록을 생성하도록 합니다. DAS가 아직 구현되지 않은 EIP-4844에서 노드들은 여전히 데이터 가용성을 확인하기 위해 모든 블롭 데이터를 다운로드하여야 합니다. 1MB의 블록이 1년동안 쌓이면 이는 2.5TB에 달하는 데이터가 되기 때문에 블롭 데이터는 일정한 기간(30~60일)이 지나면 삭제됩니다. 또한 EIP-4844에서는 대역폭 증가를 고려하여 현재 이더리움의 최대 블록크기인 약 1.8MB와 유사한 2MB로 최대 블록 크기를 제한하였습니다.
블롭은 하나 당 약 125kB의 크기를 가지고 있어 블록 당 평균적으로 8개, 최대 16개가 포함됩니다. (최종 당크샤딩이 되었을 때는 최대 32MB, 즉 블록 당 최대 256개의 블롭이 포함됩니다.) 이를 기반으로 EIP-4844는 이더리움에 일반 트랜잭션과 별도로 블롭에 대한 수수료 시장을 생성합니다. 일반 트랜잭션과 블롭은 각각 다른 가용치와 basefee를 가지며 블롭의 기본 수수료는 EIP-1559와 유사하게 블록 당 블롭 수가 목표치에 가까워 지도록 조정됩니다.
블롭을 포함한 트랜잭션(blob-carrying transaction)의 모습
DAS가 도입되기 전 EIP-4844에서 실제 블롭 데이터는 모든 노드에서 다운로드 되는 Consensus Layer(CL)의 ‘사이드카(sidecar)’ 라는 공간에 저장되고, Execution Layer(EL)의 EVM은 일반 트랜잭션과 블롭의 요약된 정보(KZG commitment)만을 전달받습니다.
블롭을 포함한 트랜잭션에서 EVM으로 전달되는 SignedBlobTransaction을 살펴보면 기존 형식에 하늘색으로 표시된 blob_versioned_hashes 필드만이 추가된 모습을 볼 수 있습니다. blob_versioned_hashes필드는 어떤 블롭들이 포함되어있는지를 나타냅니다. 블롭 데이터는 KZG commitment으로 변환된 후, 해시 함수를 거쳐 일정한 길이로blob_versioned_hashes에 표시됩니다.
💡DSRV’s Tip; KZG commitment는 왜 사용하나요?
KZG commitment 는 암호학적 방법의 일종으로, 다항식으로 표현된 데이터를 하나로 요약한 값을 나타냅니다. 이는 블롭의 데이터를 나타내는 동시에 위에서 살펴본 erasure coding이 원본 데이터에 정확하게 수행되었는지를 검증하기 위하여 사용됩니다. erasure coding는 원본 블롭의 데이터를 점에 대응하여 다항식으로 표현하고, 같은 다항식 위에 놓여진 점들을 추가하여 데이터를 연장하는데, KZG commitment를 사용하면 원본 데이터와 erasure coding된 추가 데이터가 같은 다항식에 놓여있는지를 확인할 수 있는 증명을 쉽게 생성할 수 있습니다. [8]EIP-4844를 위해 이더리움 재단, 그리고 DSRV를 포함한 생태계 참여자들은 무엇을 하고 있을까요?
현재 Prysm 및 geth 와 같은 클라이언트 팀들이 발표된 EL 및 CL 클라이언트 사양을 토대로 구현을 진행하고 있으며, EIP-4844를 위한 devnet v3이 11/30일에 시작할 예정입니다. [9] 하지만 몇가지 결정되지 않은 사양들도 남아있어, 블롭의 basefee 및 블롭을 얼마나 보관할 것인지, 그리고 KZG commitment를 사용하기 위한 설정인 KZG Ceremony에 대한 논의도 현재 진행중입니다. [10]
구현 뿐만 아니라 몇가지 테스트도 필요합니다. EIP-4844에서는 스펙에 따라 최대 2M의 블롭이 생성될 수 있습니다. 현재 이더리움 블록의 최대 크기인 1.8M을 넘어서는 크기의 블롭이 네트워크를 통해 전파되므로 EIP-4844를 위해서는 네트워크에 큰 크기의 데이터가 지속적으로 전파되었을 때 오버헤드는 없는지, 그리고 안정적으로 합의를 이룰 수 있는지가 테스트 되어야 합니다. [11]
따라서 테스트는 calldata를 채운 스팸 트랜잭션을 발생시켜 최대 블록 사이즈인 1.8M의 블록을 의도적으로 계속 생성하여 진행됩니다. 이러한 환경에서 노드들로부터 블록 및 다양한 메세지의 수신 시간과 대역폭 사용량의 변화등을 모니터링 합니다. 또한 블록이 딜레이 없이 생성되는지, 포크는 발생하지 않는지, Validator Sync Committee 퍼포먼스는 어떤지 등의 체인 데이터도 모니터링합니다. 이러한 데이터는 분석을 위해 다양한 클라이언트, 지역, 대역폭을 가진 노드들을 통해 수집됩니다.
이더리움의 벨리데이터로 참여중인 DSRV또한 위 테스트에 참여하고 있습니다. 테스트가 어떻게 진행되었는지, 그리고 결과는 어떠하였는지는 추후에 다른 아티클로 업데이트드릴 예정입니다.
마무리
지금까지 당크샤딩과 EIP-4844(프로토 당크샤딩)을 간단하게 살펴보고, EIP-4844가 어떻게 진행되고 있는지를 알아보았습니다. 머지 다음인 상하이 업그레이드에서 시행되는 것이 기대되고 있는 업그레이드는 단연 스테이킹된 이더리움의 출금 기능 과 EIP-4844입니다. 하지만 여전히 어떠한 업그레이드가 시행될 지는 확실하게 정해지지 않은 상황입니다. 11월 3일 상하이 업그레이드에 대해 의논하기 위해 진행된 All Core Developer콜에서도 EL클라이언트 개발팀인 Besu 및 Nethermind는 EIP-4844의 스펙이 아직 충분히 정의되지 않았다고 우려를 표했습니다. 이더리움 재단의 리서처인 Ansgar Dietrichs는 EIP-4844의 스펙에 대한 최종 결정이 앞으로 4주 안에 이루어질 수 있다고 말했으나 EIP-4844는 앞서 언급한 바와 같이 구현의 복잡성과 테스트 과정의 필요성으로 인해, 도입에 조금 더 시일이 걸릴 수도 있을 것으로 보입니다. [12]
지금까지 당크샤딩 및 EIP-4844의 개요와 진행 상황을 알아보았습니다. 본 글이 이더리움의 업그레이의 큰 줄기인 당크샤딩이 어떻게 도입되고 있는지를 이해하는데 도움이 되었기를 바랍니다. 읽어주셔서 감사합니다.
Written by
Youngbin Park, Research Engineer, DSRV Validator Team (Twitter@bin0_0bin)
References
[1] https://notes.ethereum.org/@vbuterin/HkiULaluS
[2] https://hackmd.io/@vbuterin/sharding_proposal[3] https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding
[4] https://notes.ethereum.org/@dankrad/new_sharding
[5] https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance
[6]https://docs.google.com/presentation/d/1-pe9TMF1ld185GL-5HSWMAsaZLbEqgfU1sYsHGdD0Vw/edit#slide=id.p2
[7] https://eips.ethereum.org/EIPS/eip-4844#on-the-path-to-sharding
[8] https://scroll.io/blog/kzg
[9] https://notes.ethereum.org/@timbeiko/4844-devnet-3
[10] https://github.com/ethereum/pm/blob/master/Breakout-Room/4844-readiness-checklist.md
[11] https://notes.ethereum.org/@djrtwo/rkgZs-YVMi
[12] https://www.galaxy.com/research/insights/ethereum-all-core-developers-call-148/
