Proto-Danksharding 톺아보기 (하)

Published in

Decipher Media ｜디사이퍼 미디어

16 min readJan 19, 2024

Disclaimer : 서울대학교 블록체인 학회 디사이퍼(Decipher)에서 Proto-Danksharding을 주제로 Weekly Session에서 발표한 내용을 바탕으로 합니다. 본 아티클은 Proto-Danksharding의 개념, Proto-Danksharding 구현 방법론 등에 대한 내용을 다루고 있습니다. 이 보고서에 포함된 어떠한 내용도 투자 조언이 아니며, 투자 조언으로 해석되어서도 안 됩니다.

Series

Proto-Danksharding 톺아보기 (상)
Proto-Danksharding 톺아보기 (하)

Author

Merlyn of Decipher Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media) Reviewed By 김동혁, 박순종, 신성헌

Intro
KZG Commitment Scheme
- Setup
- Commit
- Challenge
- Open
- Verify
EIP-4844
- Blob
- Blob-Carrying Transaction
- Block Header
- Blob Gas Price
- Opcode & Precompile
EIP-4844 in Rollups
- EIP-4844 in Optimistic Rollups
- EIP-4844 in ZK-Rollups
Conclusion

1. Intro

현재 Etheruem은 Proto-Danksharding으로 알려진 EIP-4844의 도입을 앞두고 있습니다. Proto-Danksharding은 보다 많은 데이터를 저장하는 Blob이라는 새로운 방식을 통해 Ethereum의 확장성을 개선하기 위한 업그레이드로 확장성과 데이터 가용성에 관련된 로드맵인 The Surge의 Danksharding을 위한 초석입니다. 본 글은 EIP-4844에서 추가되는 Blob이라는 데이터를 첨부할 수 있는 새로운 형태의 트랜잭션을 살펴보고 이를 이해하기 위한 암호학적 지식까지 다룹니다.

2. KZG Commitment Scheme

💡해당 글은 Proto-Danksharding을 설명하기 위한 글이기에 수학적으로 너무 복잡한 개념들은 제외하였습니다. KZG Commitment에 대해 더 자세히 알고 싶다면 필자가 진행한 KZG Commitment 세션 영상을 참고하길 바랍니다.

EIP-4844의 핵심은 큰 데이터를 다항식의 형태로 만들어 이를 매우 작은 값으로 “Commit” 함으로써 비용을 절감하는 것입니다. 다항식을 Commit 하는 암호학적인 방법들을 Polynomial Commitment Scheme(PCS)이라고 합니다.

암호학에는 매우 다양한 Commitment scheme들이 있는데 EIP-4844는 그 중 KZG Commitment Scheme을 사용합니다. KZG는 타원곡선의 페어링을 사용하는 Polynomial Commitment Scheme입니다. Proto-Danksharding에서 여러 Commitment Scheme 중에 KZG를 사용하는 이유는 Proof 사이즈와 검증 비용이 매우 작기 때문입니다. 주로 PCS의 복잡도를 측정하는 지표는 다항식의 차수인데 KZG의 경우 차수의 크기에 관계없이 Proof 사이즈와 검증비용 모두 Constant한 복잡도 O(1) 을 가집니다.

다음은 이해하기 쉬운 추상적인 개념으로 설명한 KZG Commitment Scheme의 프로세스입니다. Setup, Commit, Challenge, Open, Verify 총 다섯 단계가 있습니다.

Setup

KZG Commit 연산에 사용되는 파라미터들을 셋업하는 과정입니다. KZG Commitment는 타원곡선 기반 Scheme인 만큼 Prover와 Verifier가 연산에 공통적으로 사용할 수 있는 신뢰할 수 있는 타원곡선 점들이 필요합니다. 이를 위해 Trusted Setup이라는 과정이 필요한데 KZG의 경우 다수의 Trusted Party에서 각자 난수를 생성하여 공통의 타원곡선 점들에 자신의 난수를 곱하는 형태의 Ceremony라는 셋업 과정을 거칩니다.

Ceremony의 특징은 다수가 생성한 파라미터에서 다른 모든 참여자들이 담합을 하더라도 단 한명만 정직하다면 파라미터 키값의 역연산이 불가능하게 됩니다. 이는 타원곡선의 ECDLP가 안전하다는 가정에서 가능한 특징입니다. 실제 파라미터는 다음과 같은 형태입니다.

KZG Public Parameters

실제로 2023년에 종료된 Ethereum KZG Summoning Ceremony에 총 141,416명이 참여하여 셋업 파라미터를 구성하였고 해당 파라미터가 Proto-Danksharding을 위한 파라미터로 쓰일 예정입니다.

Commit

Commit은 다항식을 어떤”값”으로 바꾸는 과정입니다. 다항식은 인풋에 의해 함수값이 정해지는 함수인데 이런 함수의 정보를 타원곡선의 특정 점으로 Hash 한다는 개념으로 받아들여도 무방합니다. Prover는 이러한 방식으로 자신이 알고 있는 다항식을 Commitment(타원곡선 점)의 형태로 Verifier에게 넘기게 되고, Verifier는 해당 Commitment의 값으로부터 다항식을 역연산할 수 없습니다. 다항식 Commit은 다음과 같이 다항식의 계수에 각 차수에 해당하는 타원곡선 파라미터를 곱하는 형태입니다.

Challenge

위의 Commit이 “올바른 다항식을 안다”라는 사실을 주장하는 과정이라면 Challenge는 해당 주장을 확인하기 위한 과정입니다. Verifier 입장에서는 다항식의 Commitment만 받은 상황이기에 해당 타원곡선 점이 올바른 다항식으로부터 Commit된 값인지 알 수 없습니다. 따라서 이를 확인하기 위해 랜덤한 점 u를 뽑아 Prover에게 전달합니다.

Open

Prover는 Verifier를 확신시키기 위해 Challenge에 대한 증명을 해야 하고 이 과정을 Open이라고 합니다. Prover는 Challenge 값으로 받은 u를 다항식 P(X)에 대입하여 P(u) = v 를 계산합니다. Prover가 Challenge를 올바르게 연산했다면 위 식에 의해 P(u) — v = 0 이고, P(X) — v 라는 다항식이 X = u 일 때 P(X) — v = 0 을 만족합니다. 이는 다시말해 P(X) — v 라는 다항식이 (X — u)를 인수로 포함하고 있다는 의미이고, 따라서 다음 등식이 성립합니다.

위와 같이 인수 (X — u)로 나눈 Quotient 다항식 Q(X)가 존재함을 증명함으로써 원래 올바른 다항식 P(X)를 알고 있음을 증명할 수 있습니다. 만약 Prover가 틀린 다항식에서 Open했다면 Verifier가 뽑은 Challenge 값을 우연히 틀린 다항식에 대입했을 때 0 이 될 확률은 무시해도 될 만큼 매우 작습니다 (Schwartz–Zippel lemma 참고). Prover는 다시 Verifier에게 Challenge에 대한 Evaluation 값 v와 Q(X)의 Commitment인 [Q(t)]₁ = Q(t) * G₁을 보냅니다.

Verify

Verifier는 지금까지 Prover로부터 받은 [P(t)]₁, v, [Q(t)]₁를 이용해 실제로 Prover가 올바른 다항식을 가지고 있는지 검증합니다. KZG에서는 타원곡선의 Pairing을 이용하는데, Pairing은 타원곡선의 스칼라값을 역연산하는 것은 불가능하지만 서로 같은 값인지는 확인할 수 있는 성질이 있습니다. 따라서 다음과 같은 연산으로 검증할 수 있습니다(e는 Pairing함수).

타원곡선 Pairing은 매우 복잡한 수학적 로직들을 이해해야하고 Proto-Danksharding의 개념을 이해하는 목적이라면 넘어가도 무방합니다.

⚠️ 이 글에서는 Pairing에 대한 내용은 다루지 않지만 관심이 있는 독자들은 Pairings For Beginners 라는 아티클을 추천합니다. 그러나 타원곡선 Pairing은 매우 복잡한 수학적 로직들에 대한 이해가 필요하기 때문에 Proto-Danksharding의 개념을 이해하는 목적이라면 넘어가도 무방합니다.

3. EIP-4844

EIP-4844는 새로운 데이터 형태인 Blob을 첨부할 수 있는 Blob-carrying Transaction을 도입하는 업그레이드입니다. 이는 다가오는 Dencun 업그레이드의 핵심적인 스펙 중 하나입니다. Proto-Danksharding은 Etheruem의 롤업 중심 확장성 솔루션에서 매우 중요한 역할을 하는데, 해당 업그레이드가 Ethereum의 확장성 향상에 어떤 영향을 주는지에 대한 자세한 내용은 Proto-Danksharding 톺아보기 (상)을 참고하기 바랍니다.

Blob

Blob은 타원곡선의 종류 중 하나인 BLS12–381의 Field element 4096개로 구성되어있습니다. BLS12–381의 Field element는 32 bytes로 하나의 Blob은 총 131,072 bytes의 데이터를 저장할 수 있습니다. Blob data는 Calldata와 다르게 EVM에서 직접 접근이 불가능하고, 컨센서스 노드에 저장되어 18일 이후에 삭제됩니다. Blob 데이터는 18일 이후 사라지지만 다음 세가지 단계를 거쳐 versioned_hash 라는 형태로 블록에 기록됩니다.

Polynomial
- Blob의 각 element를 함수값으로 갖는 다항식 P(X)를 구성
- Lagrange Interpolation을 통해 4096개의 점 (w⁰, B₀),(w¹, B₁),…,(w⁴⁰⁹⁵, B₄₀₉₅) 를 지나는 유일한 4095차 이하의 다항식을 찾을 수 있음
Blob Commitment
- 위에서 살펴본 KZG Commitment Scheme을 이용하여 다항식 P(X)를 Commit
- Commit P(X) to [P(t)]₁
Versioned Hash
- Blob Commitment값의 Hash값
- 다양한 Commitment scheme에 대해 동일한 사이즈로 변환하기 위해 Hash값을 저장
- versioned_hash = 0x01 || sha256(blob_commitment)[1:]

Blob-Carrying Transaction

Blob이라는 새로운 데이터 형태가 추가됨에 따라 트랜잭션의 타입도 추가되었습니다. Blob-carrying Transaction이라고 불리는 Type3 트랜잭션은 EIP-1559의 Type2 트랜젝션에 max_fee_per_blob_gas 와 blob_versioned_hash 가 추가된 새로운 타입입니다.
- max_fee_per_blob_gas : 지불할 blob_gas_price의 상한
- blob_versioned_hash : 업로드할 blob의 versioned_hash 리스트

Type3 트랜잭션은 to 필드가 None인 경우를 허용하지 않는데 이는 Contract 배포에 적합하지 않은 형태이기 때문입니다. 또한 당연하게도 Blob 데이터가 반드시 존재해야하고 현재 스펙상으로는 블록당 최대 6개의 Blob을 올릴 수 있습니다.

Transaction Fee의 경우 기존 EIP-1559와 별도로 Blob에 대한 Fee가 존재합니다. 따라서 최종 Transaction Fee는 EIP-1559의 Gas fee와 Blob Fee의 합입니다.
- blob fee = blob의 수 * blob 당 가스량 * blob_gas_price

Block Header

또한 블록 헤더에도 변화가 있는데 blob_gas_used 와 excess_blob_gas 가 추가되었습니다.
- blob_gas_used : 해당 블록에서 Blob이 사용한 총 가스량
- excess_blob_gas : 이전 블록까지 누적된 Blob의 수가 기댓값에 비해 초과한 가스량
- 기댓값은 블록당 3 blobs이고, 3개를 넘으면 넘은 가스량만큼 증가하고 적으면 그만큼 감소
- 계속 3개보다 작으면 0으로 유지됨

Blob Gas Price

앞서 언급한 바와 같이 Blob에 대한 Fee는 기존의 Fee와는 독립적인 체계를 가지는데, blob_gas_price 는 오로지 excess_blob_gas 에만 의존하여 결정됩니다.

blob_gas_price =
e**(parent.excess_blob_gas / BLOB_GAS_PRICE_UPDATE_FRACTION)
- e는 자연상수 2.72…
- BLOB_GAS_PRICE_UPDATE_FRACTION: 3,338,477

blob_gas_price는 위와 같이 자연상수의 지수형태이기 때문에 excess_blob_gas가 특정 구간을 넘어가면 오히려 Calldata보다 더 비싸질 수도 있습니다.

Opcode & Precompile

또한 Blob을 위한 Opcode와 Precompile도 추가되었습니다.

Opcode
- BLOBHASH : 트랜잭션에 첨부된 versioned_hash 를 로드함
Precompile
- point_evaluation_precompile : KZG Commitment Scheme에서 opening을 검증하는 기능으로, 어떤 특정 데이터가 해당 Commitment에 포함되어있는지 확인할 수 있음

4. EIP-4844 in Rollups

Proto-Danksharding이 롤업을 위한 업그레이드인 만큼 롤업에서도 업데이트가 반드시 필요합니다. 우선 모든 롤업에서의 공통적인 구현사항은 롤업 데이터를 어떻게 압축하여 Blob의 형태로 빌드하고 L1에 올릴것이냐입니다. 또한 롤업의 대표적인 두가지 형태인 Optimistic Rollup과 ZK-Rollup에서 구현해야하는 기능에 약간의 차이가 있습니다.

EIP-4844 in Optimistic Rollups

Optimistic Rollup의 경우 EIP-4844가 적용되기 이전에는 challenger가 직접 calldata의 tx들을 실행시켜보고 결과가 같지 않을시에 챌린지를 거는 방식이었는데, Blob은 Calldata와 달리 EVM에서 직접 접근이 불가능하기 때문에 point_evaluation_precomile을 통해 간접적으로 검증해야합니다. Blob 데이터로 직접 실행은 불가능하지만 Blob 데이터를 커밋하고 Hash 함으로써 해당 블록의 Versioned Hash값과 비교하는 방식으로 검증할 수 있습니다.

EIP-4844 in ZK-Rollups

ZK-Rollup의 경우 Optimistic Rollup처럼 L1에서 직접 실행시키는 방식이 아니기 때문에 Validity Proof를 Calldata에 넣어 L1의 Verify contract로 검증하는 방식은 동일합니다. 따라서 프로토콜 구현에서는 롤업 데이터를 Blob으로 업로드하는 것을 제외하고는 이전과 동일합니다. 그러나 EVM과 완전 호환을 지향하는 ZK-Rollup이라면 zkEVM circuit에서 새로운 Type3 트랜잭션과 Opcode, Precompile 등에 대한 모든 Constraint들을 기존 Circuit에 추가 구현해야 합니다.

5. Conclusion

EIP-4844는 Ethereum 업데이트 로드맵 중 확장성과 데이터 가용성 분야인 The Surge의 Danksharding을 구현하기 위한 초석입니다. Proto-Danksharding이 적용되면 사실상 Execution layer에서는 Danksharding을 위한 준비가 거의 마무리 되었다고 볼 수 있습니다. 이후 Consensus Layer까지 댕크샤딩이 도입됐을 때 Ethereum 생태계에 어떤 변화가 있을지 귀추가 주목됩니다.