원작자: 추안 린

첫 번째 레벨 제목

01. 소개

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

아래 그림에서 볼 수 있듯이 이 단계의 업데이트는 분명히 더 많은 세부 정보를 추가합니다. "기본 롤업 확장"을 달성하기 위해 Ethereum 커뮤니티가 EIP-4844: Proto-Danksharding을 제안했음을 분명히 볼 수 있습니다. 이 제안은 2023년 5월부터 6월 초까지 시행될 예정이며, 이 때 롤업 비용이 100배 감소하여 이더리움 L2의 사용자 경험을 크게 최적화할 것입니다. 이러한 대규모 최적화는 Web3 커뮤니티에서 토론과 관심의 초점이 될 수밖에 없습니다.

Ethereum과 관련된 문제는 어디에 있습니까? EIP-4844는 이 문제를 해결하기 위해 어떤 아이디어와 솔루션을 사용합니까? 이 문서는 EIP-4844를 간결하게 이해하는 데 도움이 됩니다.

첫 번째 레벨 제목

02. 텍스트

1. EIP-4844의 기원: 데이터 가용성으로 인한 L2 수수료 병목 현상

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

현재 대부분의 Ethereum L2는 Rollup을 기본 기술 경로로 사용하고 있으며, Vitalik은 "A Rollup-Centric Roadmap"으로 이더리움의 업데이트를 설명하기도 하는데, 이는 Rollup이 기본적으로 L2 영역을 지배하고 있음을 보여줍니다.

롤업 작업의 기본 원리는 이더리움 메인 체인 외부에서 트랜잭션 묶음을 실행하는 것이며, 실행 후 실행 결과와 트랜잭션 데이터 자체를 압축하여 L1으로 다시 전송하여 다른 사람들이 트랜잭션 결과의 정확성을 확인할 수 있도록 합니다.분명히 다른 사람이 데이터를 읽을 수 있는 방법이 없다면 검증을 수행할 수 없습니다. 따라서 원시 트랜잭션 데이터를 다른 사람이 사용할 수 있도록 하는 것이 매우 중요하며, 이를 "데이터 가용성"이라고도 합니다.

그러나 Ethereum의 현재 아키텍처에 의해 제한되어 L2에서 L1로 전송되는 데이터는 트랜잭션의 Calldata에 저장됩니다.그러나 Calldata는 Ethereum이 처음 설계되었을 때 스마트 계약 함수 호출의 매개 변수일 뿐이며 모든 노드가 동기적으로 다운로드해야 하는 데이터입니다. Calldata가 확장되면 Ethereum 네트워크 노드에 높은 부하가 발생하므로 Calldata 비용이 상대적으로 비쌉니다. 이것은 또한 현재 L2 수수료에 기여하는 주요 요인입니다.

1.2 문제에 대한 개선 아이디어

이 문제에 대한 최적화 계획을 설계하라는 요청을 받는다면 어떤 방향으로 개선하시겠습니까?

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

이것은 불일치를 만듭니다: 예를 들어, 데이터가 필요한 다른 사람들이 일정 기간 동안 데이터를 다운로드할 수 있도록 데이터를 네트워크 디스크로 전송하고 싶습니다. 모든 사람이 제한된 시간 내에 다운로드를 완료하도록 강요한 다음 이 서비스에 대해 높은 요금을 청구합니다. 이것은 분명히 부적절하며 개선이 필요합니다.

그렇다면 어떻게 개선해야 할까요?L2에서 전달된 데이터에 대해 별도의 데이터 유형을 설계하고 L1의 Calldata와 분리할 수 있습니다. 이러한 유형의 데이터는 특정 기간 내에 필요한 다른 사람이 액세스하고 다운로드할 수 있으면 되며 전체 네트워크를 동기화할 필요가 없습니다.사실 이 점은 이더리움 기술 커뮤니티의 많은 구성원들에 의해서도 생각되었습니다.

EIP-4844의 개선은 실제로 이러한 맥락에서 수행됩니다.

2. EIP-4844의 핵심: 블롭과의 트랜잭션

EIP-4844가 수행하는 작업을 한 문장으로 요약하면 다음과 같습니다."Blob과의 트랜잭션"이 새로운 트랜잭션 유형입니다. Blob은 위에서 언급한 L2 데이터 전송을 위해 특별히 설계된 데이터 유형입니다.

따라서 Blob에 대한 세부 사항을 명확하게 이해했다면 EIP-4844를 기본적으로 이해했다고 말할 수 있습니다.

2.1 Blob 온톨로지: 합의 계층의 노드에 저장된 L2 압축 데이터를 배치하는 데 사용되는 "빅 데이터 블록"

Blob이라는 이름은 실제로 Binary Large Object의 약어이며 문자 그대로 "Binary Large Data Block"으로 번역됩니다. 그것은 L2의 원래 트랜잭션의 압축된 데이터를 운반하도록 설계되었으며, 이는 이전에 L2의 데이터를 Calldata에 넣었다가 이제 Blob에 넣는 것과 같습니다. Calldata와 비교할 때 Blob의 데이터 크기는 최대 125KB로 매우 클 수 있습니다.

Blob은 Blob의 두 가지 핵심 기능을 제공하는 Calldata와 같은 메인 체인에 직접 업로드되지 않고 합의 계층의 노드에 의해 저장됩니다.

• Calldata와 같은 EVM에서 읽을 수 없음

• 수명이 있으며 30일 후 삭제됩니다.

보다 구체적으로 Blob 자체는 4096개의 요소로 구성된 벡터(Vector)입니다. 이 벡터의 각 차원은 범위가 0에서 52435875175126190477474050818596525252527637826036999938584513인 매우 큰 숫자입니다.

그리고 이 벡터의 각 차원의 수는 4096 차수 이하의 유한체다항식의 각 계수로 볼 수 있다. 상수이고 w^4096 = 1을 만족합니다. 이 구조는 KZG 다항식 커밋 생성을 용이하게 하도록 설계되었습니다.

2.2 Blob: Sidecar 관련 아키텍처 설계

Blob 아키텍처를 이해하기 전에 실행 페이로드라는 개념을 설명해야 합니다. Ethereum 합병 후 Consensys Layer와 Execution Layer가 분리되어 두 가지 주요 기능을 담당합니다. 전자는 PoS 합의를 담당하고 후자는 EVM을 실행합니다. 실행 페이로드는 단순히 EL 계층에서 일반적인 L1 트랜잭션으로 간주할 수 있습니다.

Blob과 현재 Ethereum 아키텍처의 통합은 다음과 같이 오토바이 본체와 오토바이 사이드카(Sidecar) 간의 관계에 비유할 수 있습니다. (왼쪽에 있는 것이 오토바이의 사이드카입니다.)

사이드카(오토바이 사이드카)는 공식적인 은유입니다. 그 의미는 실제로 Blob의 작동이 메인 체인에 의존하지만 메인 체인과 어느 정도 평행하며 상당한 독립성을 가지고 있다는 것입니다.

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

• 먼저 L2 Sequencer가 트랜잭션을 결정하고 트랜잭션 결과 및 관련 증명(노란색 부분)과 데이터 패킷(Blob, 파란색 부분)을 L1의 트랜잭션 풀로 전송합니다.

• L1 노드(Beacon Proposer)는 트랜잭션을 보고 새로운 블록 제안(Beacon Block)에서 해당 트랜잭션을 실행하여 브로드캐스팅하지만 브로드캐스팅할 때 Blob을 분리하여 합의 레이어 CL에 남겨두고, 실행 계층의 새 블록에 넣습니다.

• 다른 L1 노드(Beacon Peer)는 새로운 블록 제안과 거래 결과를 받게 됩니다. L2 검증자가 되어야 하는 경우 Blob 사이드카로 이동하여 관련 데이터를 다운로드할 수 있습니다.

아래 그림은 다른 관점에서 Blob 수명 주기를 나타낸 그림입니다.BLOB 데이터가 L1 메인 체인에 업로드되지 않고 합의 레이어 노드에만 존재하며 다른 수명 주기를 가지고 있음을 분명히 알 수 있습니다. .

그러므로,EVM, 즉 L1 스마트 컨트랙트에서 Blob을 직접 읽을 수 없는 이유를 이해하는 것은 어렵지 않습니다. 읽을 수 있는 것은 실행 레이어로 전달되는 것입니다. 지금은 그런 기능이 없습니다.실제로 이러한 분리는 롤업 비용을 줄일 수 있는 이유입니다.

2.3 Blob 스토리지: 새로운 수수료 시장

앞에서 언급했듯이 Blob 데이터는 합의 계층 노드에 저장되며 수명 주기가 있습니다. 그러나 분명히 이 서비스는 무료가 아니므로 L1 가스 수수료와 독립적인 새로운 수수료 시장을 가져올 것입니다. 이는 Vitalik이 주창하는 다차원 수수료 시장이기도 합니다. 이 수수료 시장의 관련 세부 사항은 계속해서 개선되고 있습니다.자세한 내용은 Github의 관련 토론 및 업데이트를 참조하십시오: https://github.com/ethereum/EIPs/pull/5707

또한 노드 수준에서 이러한 데이터를 짧은 시간 동안만 저장할 수 있는 경우 장기 저장을 달성하는 방법은 무엇입니까? 이와 관련하여 Vitalik은 실제로 많은 솔루션이 있다고 말했습니다. 여기서의 보안 가정은 그다지 까다롭지 않기 때문에 누군가가 실제 데이터 저장을 완료할 수 있는 한 "1 of N 신뢰 모델"입니다. 대용량 스토리지 하드웨어가 TB당 20달러에 불과한 상황에서 연간 2.5TB의 데이터 스토리지는 원하는 사람들에게 작은 문제입니다. 이 외에도 다양한 탈중앙화 스토리지 솔루션도 옵션이 될 예정이지만 비탈릭은 여기서 구체적인 프로젝트를 언급하지 않았다.

3. EIP-4844의 영향

아키텍처 수준에서 EIP-4844는 이더리움이 L2를 위한 별도의 데이터 계층을 구축한 최초의 새로운 트랜잭션 유형인 Blob 운반 트랜잭션을 도입했으며 Full Danksharding 실현의 첫 번째 단계이기도 합니다.

경제 모델 수준에서 EIP-4844는 Blob에 대한 새로운 수수료 시장을 도입할 것이며, 이는 이더리움이 다차원 시장으로 이동하는 첫 번째 단계이기도 합니다.

사용자 경험 수준에서 사용자의 가장 직관적인 인식은 L2 수수료의 실질적인 감소이며, 하단 계층에서의 이러한 중요한 개선은 L2 및 해당 응용 계층의 폭발적인 성장을 위한 중요한 기반을 제공할 것입니다.

4. EIP-4844 이후의 전망: 완전 단크샤딩

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

그리고 EIP-4844는 Danksharding의 프로토타입을 의미하는 "Proto-Danksharding"일 뿐입니다. Danksharing 정식 버전의 아이디어는 아래 그림과 같으며 각 노드는 Data Availability Sampling을 통해 L2 데이터의 정확성을 직접 검증할 수 있습니다. 이렇게 하면 L2의 보안과 성능이 더욱 향상됩니다.