[Ethereum 2.0] 3. EIP-4844 (Proto-danksharding)

Woojin Jeong

Published in

slcf

17 min readAug 4, 2022

Reviewed by: Seongwan Park

[Ethereum 2.0] Contents

1부: Danksharding Overview
- Original sharding과의 비교
- DAS (data availability sampling)
- 2D KZG commitment
2부: PBS (Proposer Builder Separation)
- What is PBS?
- PBS scheme (Two-slot PBS, Hybrid PBS…)
3부: Proto-danksharding (EIP-4844)
- Blob-carrying transaction
- 2 dimensional Fee market
4부: Danksharding Deep dive
- KZG commitment

Intro

EIP-4844는 올해 2월 ETH Denver에서 OP Labs의 Diederik Loerakker에 의해 처음 소개되었다. 롤업 중심의 이더리움 2.0 로드맵에서 목표로 하는 전체 샤딩 스킴(현재로서는 Danksharding)을 구현하기 위한 중간 단계의 EIP로, Proto-danksharding으로도 불린다. PoC 단계의 Danksharding보다는 구현이 좀 더 현실적이어서 올해 하반기 예정된 이더리움 상하이 하드포크에 반영되는 것을 기대해볼 수 있다.

Proto-danksharding는 “Blob”이라는 새로운 형태의 데이터 구조를 포함하는 트랜잭션 포맷을 제시하여 롤업 사용 수수료를 크게 절감(100배 정도)하는데 기여할 EIP다. 특히 데이터 가용성 측면에서 잠정적인 Full sharding 스킴(현재로서는 Danksharding)과의 높은 호환성을 강조하여 이더리움 2.0 연구자들의 적잖은 지지를 받고 있다.

Danksharding recap

먼저 이더리움 2.0 초창기에 거론되었던 샤딩 스킴과 롤업 중심 로드맵 이후 등장한 Danksharding의 차이를 확실히 짚고 넘어가자. Danksharding은 롤업을 위해 존재하는 스킴이다. 초창기 샤딩 스킴은 한번에 많은 트랜잭션들의 유효성을 검증하기 위해 비콘 블록에 여러 개의 샤드 블록들을 연결하여 트랜잭션 데이터가 임시로 저장되는 공간을 확장시키고자 하였다.

반면 Danksharding(또는 Proto-Danksharding) 스킴에서는 Layer 2에서 트랜잭션들이 번들 형태로 제출되면 롤업 오퍼레이터(또는 Sequencer)가 평균 1MB 정도 되는 블롭 데이터가 담긴 새로운 형태의 트랜잭션(이하 블롭 트랜잭션)을 만들어 Layer 1에 올리도록 한다. 블롭 데이터는 Execution과는 관련이 없으며 데이터 가용성(Data Availability)을 검증 받기 위해 존재한다. 여기서 데이터 가용성이란 컨센서스 노드가 검증 시 필요한 블롭 데이터를 정상적으로 다운받아 열람할 수 있는지 여부를 의미한다. 데이터 가용성이 보장되지 않으면 롤업 오퍼레이터가 이상한 값을 Layer 1에 업데이트한 경우 validator들이 이를 검증할 때 필요한 데이터에 즉각 접근 할 수가 없다.

Danksharding scheme (Source: https://notes.ethereum.org/@vbuterin/proto_danksharding_faq)

Is blob necessary?

현재 롤업(Optimistic rollup, ZK rollup)에서는 트랜잭션 데이터가 Calldata 형태로 저장된다. 더 높은 수준의 확장성을 위해 롤업 수수료가 걸림돌이 된다면 단순히 콜데이터 가격을 낮추면 해결되는게 아닐까? 그러나 이는 이론 상 최대 블록 사이즈도 동시에 높아짐을 의미한다. 지금도 이더리움 네트워크가 감당하기 벅찬 블록 사이즈가 간헐적으로 발생하는데 확장성을 위해 콜데이터 가격을 낮춰버리는 방식은 이론 상 최대 블록 사이즈를 더 크게 만들 것이다.

최대 블록 사이즈 뿐만 아니라 평균적인 블록 사이즈도 다른 측면에서 문제가 된다. EIP-1559에서 제시한 블록 당 소요하는 타겟 가스량(T/2)이 15M인 것으로부터 네트워크가 무리를 느끼지 않는 블록 사이즈 평균은 15M/16 gas per byte ≈1MB임을 유추할 수 있지만, 현재 평균 블록사이즈(약 90kB)는 이 값에 훨씬 미치지 못한다.

이것이 롤업에서 블롭 트랜잭션이 필요한 이유다. 블롭은 4096개의 필드(각 32 bytes)로 구성되어 있어, 블록 당 최대 16개 블롭을 포함하도록 제한한다면 위에서 말했던 최악의 경우 블록 사이즈에는 영향을 미치지 않으면서(4096 fields * 32 bytes * 16 ≈ 2.1MB) 평균 블록 사이즈를 1MB 정도로 늘릴 수 있다. 또한, EVM 상 트랜잭션 실행과 관련된 콜데이터와는 달리, 블롭은 단순 저장을 위해 구현된 데이터 구조이기 때문에 같은 양의 calldata보다 저렴하다는 장점도 있다.

Blob-carrying transaction

블롭 트랜잭션은 전체적으로 네트워크 래퍼(Wrapper)로 감싸져 있고, 그 안에 트랜잭션(tx), 블롭에 대한 커밋 정보가 담긴 blob_kzgs , 블롭 데이터(blobs)이 있다. 트랜잭션(tx) 내 BlobTransaction은 기존 트랜잭션과 거의 비슷하지만 새롭게 blob_versioned_hashes 필드가 추가되었다.

Versioned hash는 블롭마다 계산되는 것으로, 버전을 나타내는 1 byte의 값과 각 블롭에 대한 KZG commitment를 SHA256 함수를 통해 32 bytes로 변환 시 마지막 31 bytes을 합친 값이다. 커밋 값에 한번 더 해시 연산을 해준 이유는 KZG 커밋의 계산 값이 48 bytes라 32 bytes에 최적화된 EVM 연산과의 호환성을 높이기 위해서다. 버전 필드를 추가해준 것도 KZG 외 다른 커밋 방식을 사용하는 추후 스킴과의 호환성을 위함이다.

Changes in consensus layer

위의 블롭 트랜잭션 구조에서 각 블롭에 대한 커밋 값들을 리스트로 모은 blob_kzgs 와 블롭 데이터 자체(blobs) 는 SignedBlobTransaction 외부에 있다는 점이 주목할 만하다. 이것은 블롭 트랜잭션이 롤업 오퍼레이터에 의해 생성되고 Layer 1에서 어떻게 전파되는지와 관련이 있는데, 아래 그림을 살펴보자.

롤업 오퍼레이터가 올린 블롭 트랜잭션은 Layer 1 트랜잭션 풀에 있다가 비콘 proposer에게 전달된다. Proposer는 블롭 트랜잭션을 두 부분으로 나누어 이웃 검증인 노드들에게 P2P 전파시키는데, 블롭 트랜잭션의 SignedBlobTransaction부분은 Exec Payload에, 나머지 부분은 별도의 블롭 사이드카(Blob sidecar) 형태로 전파된다.

여러 블롭들의 커밋 값이 담긴 사이드카와 Exec payload는 비콘 체인의 검증인들에 의해 가용성을 검증받는다. 가용성을 검증하기 위해서는 Exec payload 안의 versioned hash가 사이드카 내의 커밋 값과 대응되는지를 체크하면 된다. 실제 트랜잭션 데이터가 담긴 비콘 블록과 별개로 블롭 커밋 값만 모아놓은 사이드카 메커니즘을 통해 검증해야 할 트랜잭션 수가 급증하더라도 P2P 전파에 무리가 없다. EIP-4844에서는 가용성 검증을 위해 전체 블롭 데이터를 다운받아야 하지만, Danksharding에서는 DAS을 통해 네트워크의 모든 비콘 노드에서 모든 블롭을 다운받지 않아도 검증 가능한 스킴을 목표로 하고 있다. (1부 참고)

사이드카 내의 블롭 데이터는 한달간 비콘 체인 상에 존재하며 이후에는 삭제된다. 한달 동안만 컨센서스 노드들이 해당 블롭의 availability를 검증할 수 있는 것이다. 만약 블롭 데이터가 삭제되지 않는다면 대략 연간 2.5TB 만큼의 데이터가 네트워크 상에 축적되는데 이는 오늘날 이더리움이 필요로 하는 성장률보다 훨씬 높은 값이다. 그리고 블롭 데이터가 삭제되어도 실제 트랜잭션 데이터가 담겨 있는 Exec payload는 여전히 Layer 1에 남아있다.

Then, how are transactions validated?

초반에 잠깐 언급하였듯이 블롭 데이터는 트랜잭션 실행과 관련이 없다. EIP-4844를 구현할 때에는 execution layer에 대해 에너지를 쏟을 필요가 없을 것이다. EVM은 블롭 데이터 자체에는 접근할 수 없으며, 블롭 데이터의 커밋 값만 볼 수 있다.

블롭 데이터가 가용성을 보장해주기는 하지만, Layer 1의 validator들은 트랜잭션 데이터가 유효하다는 것을 어떻게 검증할 수 있는 것일까? 가용성은 단지 유효성 검증에 필요한 데이터의 유무를 체크하는 과정일 뿐인데 말이다.

유효성을 검증하는 다른 특별한 방법이 있는 것이 아니라, EIP-4844에서도 롤업 시퀀서에 의해 제출된 트랜잭션이 Layer 1에서 검증되는 방식(Optimistic 롤업의 경우 fraud proof, ZK rollup의 경우 validity proof)이 동일하게 적용된다. 블롭에 의해 데이터 가용성이 보장되었기 때문에, 블롭의 KZG 커밋 값들이 fraud proof나 validity proof 시 어떻게 잘 녹아 들어 갈 수 있는지에 대해서만 고민하면 된다. 이에 대하여 EIP-4844에서는 각 롤업의 검증방식에 대한 precompile 방식을 따로 제시하였다. 언제든지 KZG 대신 다른 커밋 방식으로 교체되어도 롤업이 문제 없이 작동할 수 있도록 하기 위하여 KZG 커밋을 직접 검증하는 대신 precompile 방식을 도입하였다고 한다. Optimistic 롤업의 blob verification precompile 방식과 ZK 롤업의 point evaluation precompile에 대한 더 자세한 내용은 기회가 된다면 4부에서 작성하도록 하겠다.

2-dim Fee Market

한편, Proto-danksharding이 도입된다면 기존의 트랜잭션 외에도 블롭 트랜잭션이 멤풀에 존재하게 된다. 즉, 블록을 만드는 주체(miner or maybe builder)는 가스 뿐만 아니라 블롭에 대해서도 신경을 써야 한다. 예를 들어, 블록 당 가스 리밋은 70, 블롭 리밋은 40이라 가정해 보자. 그리고 멤풀에는 다음과 같이 두 종류의 트랜잭션만 있다. 순서대로 (가스 당 마이너 팁, 포함 블롭 수, 소요 가스량)을 의미한다.

Type 1: (5, 4, 4)
Type 2: (3, 1, 2)

이 때 마이너가 최대 수익을 얻으려면 블록 구성을 어떻게 해야할까? Type 1 트랜잭션으로 블록을 가득 채우게 된다면 블롭 리밋 때문에 최대 10개를 포함시킬 수 있으며 이 때 수익은 5*10*4=200이 된다. Type 2로 가득 채운다면 가스 리밋 때문에 최대 35개를 포함시킬 수 있으며 이 때 수익은 3*35*2=210이다. 그러나 아래 그래프처럼 주어진 제약조건 하에서 최대 수익은 Type 1 트랜잭션 3개, Type 2 트랜잭션을 28개 포함시켰을 때 얻을 수 있는 5*3*4+ 3*28*2 = 228이다.

기존 EIP-1559에서는 대다수 마이너들이 별도의 컴퓨팅 리소스를 들이지 않고 최대 이득을 볼 수 있는 블록을 만들 수 있었다. 멤풀 안에 트랜잭션이 포화 상태도 아니었고 수요가 급증하는 특수 케이스를 배제하면 거의 블록 target size를 유지했기 때문이다. 그러나 Danksharding에서처럼 블록 사이즈가 커지고 가스 외에 블롭이라는 변수가 생겨 2차원 수수료 시장이 형성된다면, 위의 예시처럼 빌더들은 일종의 배낭 문제(knapsack problem) 해결을 통해 수익을 극대화해야 할 것이기 때문에 빌더 중앙화를 가속화하는 요소가 되지 않을까하는 우려가 있을 수 있다.

Are execution clients going to have to implement complex multidimensional knapsack problem algorithms to optimize their block production now? No, for a few reasons: ….
(from https://notes.ethereum.org/@vbuterin/proto_danksharding_faq)

비탈릭은 이에 대해 별 문제가 아니라는 입장을 취했다. 빌더들은 블록 당 평균 0.025ETH 만큼의 MEV라는 다른 수입원도 있으므로, 굳이 가스와 블롭 기반의 최적화된 수익을 잘 계산하지 못하더라도 이것이 빌더에게 더 이상의 블록 제작 인센티브를 상실하게 만드는 것으로 이어지지는 않을 것이기 때문이다. 또한 배낭 문제의 최적해를 구하지 못한다 하더라도 적절한 휴리스틱으로 근사치를 쉽게 구할 수 있을 것이라는 것도 그 의견을 뒷받침한다. 배낭 문제의 일반화된 경우처럼 변수가 많은 것도 아니고, 현재로서는 가스 외에 블롭만이 고려 대상인데 이를 NP-complete한 knapsack problem으로 확장시켜 어려움을 우려하는 것은 성급한 감이 있어 보인다.

What’s going on..

최근에도 계속해서 EIP-4844에 대한 미팅이 진행 중이다. 가장 최근에는 Fee Market에 대한 논의가 주로 이루어졌다. EIP-4844에서 제시한 블롭 트랜잭션이 멤풀에 생기게 되면 수수료는 어떻게 계산되어야 하는지에 대한 얘기다. 기존에는 블록 내 트랜잭션들이 사용한 가스량에 가스 가격(Gas price)을 곱하여 수수료를 계산하였다. 블롭 트랜잭션과 일반 트랜잭션이 섞여 있는 블록의 수수료 역시 기존처럼 사용한 가스량에 가스 가격을 곱한 값으로 계산되기는 하지만, 블록 내 블롭 당 추가 가스가 더해진다. EIP-1559에서 유저들의 수요를 반영하여 Basefee가 업데이트 됐던 것과 비슷한 방식으로 블롭 당 가스(아래 그림에서 Blob price)가 계산된다.

EIP-1559와 비슷한 방식으로 Blob price는 초과 블롭 수가 클수록 지수적으로 증가한다. Blob price의 책정 단위가 gas라 이를 블롭 트랜잭션 내 가스량을 의미하는 것으로 혼동하기 쉽다. 그러나 트랜잭션 실행 시 소요되는 가스량은 수수료에 이미 포함된 것이고, Blob price는 오로지 블록 안 포함된 블롭 갯수에 의해서 추가되는 수수료를 의미한다.

Fee calculation of blocks including Blob-carrying transaction

N+1번째 블록의 proposer가 지불해야 할 수수료를 계산해보자. N+1번째 블록 안 블롭의 가격은 포크 이후부터 N번째 블록까지의 블롭 수를 바탕으로 계산된다. 현재 EIP-4844에서 목표로 하는 블록 당 트랜잭션 수는 16의 절반인 8이기 때문에, Target은 포크 이후부터 N번째 블록까지의 블록 수에 8을 곱한 값이다. 초과 블롭은 실제에서 이 타겟 값을 뺀 블롭 수이며, 0보다 작은 경우(실제 포함된 블롭 수가 목표 값에 미치지 못한 경우)에는 N+1번째 블록의 블롭 사용료는 공짜다.

또한, N+1번째 블록 안 Blob price가 계산이 된 후에 실행되는 스토리지 업데이트 코드를 보면 한 가지 특이한 점이 있다. 위 코드에서 new_total 변수가 (의미 상으로는) 포크 이후 N+1번째 블록까지 실제 포함된 블롭 수이다. 하지만 코드 상으로는 실제 값과 targeted_total 중 더 큰 값으로 업데이트 한다. 실제가 목표에 미치지 못한 경우에는 실제 값을 목표 값으로 대체하자는 것인데 이유가 뭘까? Proposer들이 계속해서 블록 안 블롭 수를 타겟에 훨씬 못 미치게 블록을 만드는 경우, blob price가 장기간 동안 0이 되는 것을 막기 위함이다. 실제 포함된 블롭 수를 상향 조정함으로써 가격 조정 메커니즘을 통해 블롭 가격이 한쪽으로 기울지 않고 타겟 근방을 유지할 수 있도록 하였다.

이처럼 EIP-1559는 단기간 동안의 트랜잭션 수요 분포에 기초하여 가격 조정이 이루어지는 반면, EIP-4844에서는 포크 이후로의 전체 시간 동안 초과 블롭을 기반으로 조정이 이루어진다. 가격 조정이 좀 더 stable하게 이루어진다는 것인데 이것의 장단점을 논하는 것은 독자의 영역으로 남겨두겠다.

https://github.com/ethereum/EIPs/pull/5353#issuecomment-1199277606

@protolambda는 초과 블롭이 한 블록 내에서 몰아서 발생하는 경우와 여러 블록에 걸쳐 조금씩 분포하는 경우 블롭 가격을 비교하여 블롭 가격 메커니즘에 대한 새로운 관점을 제시하였다. 후자의 경우에 대한 예시로 연속된 8개 블록에서 계속해서 직전 블록보다 1만큼의 초과 블롭이 발생했다고 하자. 이 경우 blob price는 2**(1/64)+2**(2/64)+2**(3/64)+2**(4/64)+2**(5/64)+2**(6/64)+2**(7/64)+2**(8/64) ≈ 8.40이 된다. 한편 8개 블록 중 한 개의 블록에서 36만큼의 초과 블롭이 한번에 발생한 경우 blob price는 2**(36/64) ≈ 1.47 정도다. 작지만 꾸준한 초과 블롭이 발생하는 상황도 바람직하진 않지만 네트워크 관점에서는 드물어도 큰 초과 블롭이 발생하는 경우(burst)가 훨씬 부담이기 때문에 excess burst에 대한 페널티가 더 클 수 있도록 가격 업데이트 방식에 대한 개선이 이루어질 필요가 있어 보인다. 이 부분은 multidimensional EIP-1559을 읽은 후에 생각해보면 좋을 것 같다.

이처럼 기존 gas fee 조정 메커니즘과 더불어 blob price도 고려하는 multi-dimensional fee 메커니즘을 일반화하여 앞으로는 L2 pricing으로 부를 예정이라 한다. 현 시점 기준으로 EIP-4844 제안 당시 계획했던 스펙 대다수가 구현되었지만, 블롭 검증 과정을 최적화하는 것과 정상 블롭 트랜잭션 비율이 크지 않아 DoS 공격 요소로 작용할 수 있다는 약간의 이슈가 해결 과제로 남아 있는 상황이다. 자세한 내용은 아래 링크를 참고하기 바란다.

EIP-4844 Breakout Room Notes (July 29, 2022, 14:00 UTC)

본 글에서는 KZG 커밋과 관련된 내용은 거의 다루지 않았다. Danksharding에서 왜 하필 다양한 커밋 방식 중 KZG를 사용하는지, 이를 위한 trusted setup 구현은 어떤 방향성을 가지고 진행되어야 하는지, 그리고 롤업(ZK, Optimistic)과의 연관성에 대해 4부에서 자세히 알아볼 예정이다.