EIP-4844 심층 해석: Layer2 비용을 100배 줄이는 방법?

原문作者：Chuan Lin

原文来源：A\&T Capital

01、引子

Vitalik은 2022년 11월 5일 업데이트된 이더리움 로드맵을 발표했습니다. 이는 이전 2021년 12월 2일 발표된 로드맵과 비교할 때, 다가오는 The Surge 단계의 업데이트가 분명히 가장 주목할 만한 점입니다.

아래 그림과 같이, 이 단계의 업데이트는 명확히 더 많은 세부 사항을 추가했습니다 ------ 우리는 "기본 Rollup 확장성"을 실현하기 위해 이더리움 커뮤니티가 EIP-4844: Proto-Danksharding을 제안했다는 것을 분명히 볼 수 있습니다. 이 제안은 2023년 5월에서 6월 초에 시행될 예정이며, 그때 Rollup의 비용은 100배 감소할 것이며, 이는 이더리움 L2의 사용자 경험을 매우 크게 최적화할 것입니다. 이렇게 큰 최적화는 반드시 Web3 커뮤니티의 논의와 관심의 초점이 될 것입니다.

원래 이더리움 관련 문제는 어디에 있었을까요? EIP-4844는 어떤 사고방식과 방안으로 이 문제를 해결했을까요? 본문은 여러분이 EIP-4844를 간결하게 이해하는 데 도움을 줄 것입니다.

이더리움의 기본 아키텍처 업데이트를 따라가고, 커뮤니티의 논의를 실시간으로 따라가고 싶다면, 본문을 놓치지 마세요!

02、正文

一、EIP-4844 起源：数据可用性引起的L2费用瓶颈

1.1 현재 L2와 L1 데이터 상호작용의 기본 상황

현재 이더리움 L2는 대부분 Rollup을 기본 기술 경로로 하고 있으며, Vitalik은 이더리움의 업데이트를 "A Rollup-Centric Roadmap"으로 설명했습니다. 이는 Rollup이 L2 생태계를 거의 지배하고 있음을 보여줍니다.

Rollup의 기본 원리는 거래 묶음을 이더리움 메인 체인 외부에서 실행하고, 실행이 완료된 후 실행 결과와 거래 데이터를 압축하여 L1으로 다시 전송하여 다른 사람들이 거래 결과의 정확성을 검증할 수 있도록 하는 것입니다. 명백히, 다른 사람들이 데이터를 읽을 수 없다면 검증을 완료할 수 없습니다. 따라서 다른 사람들이 거래 원본 데이터를 얻을 수 있도록 하는 것이 매우 중요하며, 이는 "데이터 가용성" (Data Availability)이라고도 불립니다.

하지만 현재 이더리움의 아키텍처에 제한되어 L2에서 L1으로 전송되는 데이터는 거래의 Calldata에 저장됩니다. 그러나 Calldata는 처음 이더리움 설계 시 단순히 스마트 계약 함수 호출의 매개변수로, 모든 노드가 동기화하여 다운로드해야 하는 데이터입니다. Calldata가 팽창하면 이더리움 네트워크 노드의 높은 부하를 초래하므로 Calldata의 비용은 상당히 비쌉니다. 이것이 현재 L2 비용의 주요 원인입니다.

1.2 문제의 개선 사고방식

독자 여러분은 이 문제에 대한 최적화 방안을 설계한다면 어떤 방향으로 개선할 것인지 생각해 보시기 바랍니다.

사실 우리는 L2의 거래 압축 데이터 업로드가 다른 사람들이 다운로드하여 검증할 수 있도록 하기 위한 것일 뿐, L1에서 실행될 필요는 없다는 것을 관찰할 수 있습니다. Calldata 비용이 높은 이유는 그것이 함수 호출의 매개변수로, 기본적으로 L1에서 실행될 수 있기 때문에 전체 네트워크의 노드가 동기화해야 하기 때문입니다.

이로 인해 불일치가 발생합니다: 예를 들어, 나는 단순히 데이터를 클라우드 스토리지에 전송하여 필요한 다른 사람들이 일정 기간 내에 다운로드할 수 있도록 하고 싶었는데, 결과적으로 내 데이터를 내가 필요로 하지 않는 전체 네트워크 방송 동기화로 강제하여 모든 사람이 제한된 시간 내에 다운로드를 완료해야 하며, 그 서비스에 대해 나에게 높은 비용을 청구하는 것입니다. 이는 분명히 부적절하며 개선이 필요합니다.

그럼 어떻게 개선할까요? 우리는 L2에서 전송된 데이터를 별도의 데이터 유형으로 설계하고, 이를 L1의 Calldata와 분리할 수 있습니다. 이 데이터 유형은 일정 시간 내에 필요한 다른 사람들이 접근하여 다운로드할 수 있도록 하는 것만 필요하며, 전체 네트워크 동기화는 필요하지 않습니다. 실제로 이 점은 많은 이더리움 기술 커뮤니티의 구성원들이 생각해낸 것입니다.

EIP-4844의 개선은 사실 이 맥락을 중심으로 진행되고 있습니다.

二、EIP-4844 的核心：带 Blob 的交易

EIP-4844가 무엇을 했는지 한 문장으로 요약하자면: "Blob을 포함한 거래"라는 새로운 거래 유형을 도입했습니다. Blob은 앞서 언급한 L2 데이터 전송을 위해 특별히 설계된 데이터 유형입니다.

따라서 Blob과 관련된 세부 사항을 명확히 이해하면 EIP-4844를 기본적으로 이해했다고 할 수 있습니다.

2.1 Blob의 본체: L2 압축 데이터를 위한 "대용량 데이터 블록", 합의 계층의 노드에 존재

Blob이라는 이름은 사실 Binary Large Object의 약자로, 직역하면 "이진 대용량 데이터 블록"입니다. 이는 L2의 원본 거래 압축 데이터를 수용하기 위해 설계된 것으로, 이전 L2의 데이터가 Calldata에 저장되었던 것이 이제 Blob에 저장되는 것입니다. Calldata와 비교할 때, Blob의 데이터 크기는 매우 클 수 있으며, 최대 125 KB에 달합니다.

Blob은 합의 계층의 노드에 의해 저장되며, Calldata처럼 메인 체인에 직접 올라가지 않기 때문에 Blob의 두 가지 핵심 특징이 있습니다:

• EVM에 의해 읽힐 수 없습니다.

• 수명 주기가 있으며, 30일 후에 삭제됩니다.

조금 더 세부적으로 말하자면, Blob 자체는 4096개의 요소로 구성된 벡터(Vector)입니다. 이 벡터의 각 차원은 매우 큰 숫자가 될 수 있으며, 값의 범위는 0에서 52435875175126190479447740508185965837690552500527637822603658699938581184513 사이입니다 ------ 이 매우 큰 숫자는 소수이며, 타원 곡선 암호학 알고리즘과 관련이 있습니다.

이 벡터의 각 차원의 숫자는 4096차 이하의 유한체 다항식의 각 계수로 볼 수 있으며, 예를 들어 i번째 차원의 숫자는 w^i 앞의 계수입니다. 여기서 w는 상수이며 w^4096 = 1을 만족합니다. 이 구조 설계는 KZG 다항식 약속의 생성을 용이하게 하기 위해 마련되었습니다.

2.2 Blob과 관련된 아키텍처 설계: 사이드카(Sidecar)

Blob 아키텍처를 이해하기 전에 하나의 개념을 설명해야 합니다: Execution Payload(실행 페이로드). 이더리움 병합 이후, Consensys Layer와 Execution Layer로 나뉘었으며, 각각 두 가지 주요 기능을 담당합니다: 전자는 PoS 합의를 담당하고, 후자는 EVM을 실행합니다. Execution Payload는 간단히 EL 층 내의 일반적인 L1 거래로 생각할 수 있습니다.

Blob과 현재 이더리움 아키텍처의 융합은 오토바이 본체와 오토바이 사이드카(Sidecar) 간의 관계에 비유할 수 있습니다. 아래와 같이: (왼쪽이 오토바이의 사이드카입니다)

사이드카는 공식적인 비유입니다. 그 의미는 Blob의 작동이 메인 체인에 의존하지만, 어느 정도는 메인 체인과 평행하며 상당한 독립성을 가진다는 것입니다.

아래 그림과 같이, 이제 Blob과 관련된 실행 프로세스를 살펴보아 이 비유를 더 잘 이해해 보겠습니다:

• 먼저, L2 Sequencer가 거래를 결정하고, 거래 결과와 관련 증명(노란 부분) 및 데이터 패킷(Blob, 파란 부분)을 L1의 거래 풀에 전송합니다.

• L1의 노드(Beacon Proposer)는 거래를 보고, 새로운 블록 제안(Beacon Block) 내에서 관련 거래를 실행하고 방송합니다. 그러나 방송할 때 Blob을 분리하여 합의 계층 CL에 남기고, 실행 계층의 새로운 블록에는 넣지 않습니다.

• 다른 L1 노드(Beacon Peer)는 새로운 블록 제안과 거래 결과를 받습니다. 만약 그들이 L2 검증자가 되어야 한다면, Blobs 사이드카에서 관련 데이터를 다운로드할 수 있습니다.

아래 그림은 다른 각도에서 Blob 생애 주기를 설명합니다. 우리는 blob 데이터가 L1 메인 체인에 올라가지 않고, 오직 합의 계층 노드에만 존재하며, 서로 다른 생애 주기를 가지고 있음을 명확히 볼 수 있습니다.

따라서, Blob이 EVM, 즉 L1의 스마트 계약에 의해 직접 읽힐 수 없는 이유를 이해하는 것도 어렵지 않습니다: 읽힐 수 있는 것은 실행 계층으로 전송된 것들뿐이며, Blob은 오직 합의 계층에만 남아 있으므로 이 기능이 없기 때문입니다. 사실, 이러한 분리는 Rollup 비용이 감소할 수 있는 이유이기도 합니다.

2.3 Blob의 저장: 새로운 수수료 시장

앞서 언급했듯이, Blob 데이터는 합의 계층 노드에 존재하며, 생애 주기를 가지고 있습니다. 그러나 분명히 이러한 서비스는 무료가 아니므로, L1 가스 요금과 독립적인 새로운 수수료 시장을 가져올 것입니다. 이는 Vitalik이 주장한 다차원 수수료 시장(Multi-dimensional Fee Market)입니다. 이 수수료 시장의 관련 세부 사항은 아직 반복적으로 개선되고 있으며, 자세한 내용은 Github의 관련 논의 및 업데이트를 참조하십시오: https://github.com/ethereum/EIPs/pull/5707

또한, 노드 측면에서 이러한 데이터를 단기적으로만 저장할 수 있다면, 장기 저장은 어떻게 이루어질까요? 이에 대해 Vitalik은 해결책이 사실 많다고 밝혔습니다. 여기서의 보안 가정은 높지 않으며, "1 of N 신뢰 모델"로, 누군가가 실제 데이터를 저장할 수 있으면 됩니다. 현재 대형 저장 하드웨어는 TB당 20달러에 불과하며, 매년 2.5TB의 데이터 저장은 관심 있는 사람에게는 작은 문제일 뿐입니다. 또한, 다양한 탈중앙화 저장 솔루션도 선택지가 될 수 있지만, Vitalik은 여기서 구체적인 프로젝트를 언급하지 않았습니다.

三、EIP-4844 的影响

아키텍처 측면에서 EIP-4844는 새로운 거래 유형인 Blob-carrying Transaction을 도입했습니다. 이는 이더리움이 L2를 위해 독립적으로 데이터 계층을 처음으로 구축한 것이며, 이후 Full Danksharding 구현의 첫걸음입니다.

경제 모델 측면에서 EIP-4844는 blob에 새로운 수수료 시장을 도입할 것이며, 이는 이더리움이 다차원 시장(Multi-dimensional Market)으로 나아가는 첫걸음이 될 것입니다.

사용자 경험 측면에서, 사용자가 가장 직관적으로 느끼는 것은 L2 비용의 대폭 감소입니다. 이 기본적인 중요한 개선은 L2 및 그 응용 계층의 폭발적인 성장을 위한 중요한 기반을 제공할 것입니다.

四、EIP-4844 后的展望：Fully Danksharding

현재, EIP-4844는 이미 이더리움 상하이 업그레이드 시리즈에 명확히 포함되어 있으며, 현재 커뮤니티 구성원들이 제시한 일정에 따르면 내년 5월에서 6월 초에 완료될 것으로 예상됩니다.

EIP-4844는 "Proto-Danksharding"에 불과하며, 이는 Danksharding의 프로토타입을 의미합니다. 완전한 Danksharding의 구상은 아래 그림과 같이, 각 노드가 데이터 가용성 샘플링(Data Availability Sampling)을 통해 L2 데이터의 정확성을 실시간으로 검증할 수 있도록 하는 것입니다. 이는 L2의 보안성과 성능을 더욱 향상시킬 것입니다.