저자: 비탈릭 부테린

Ethereum 창립자 Vitalik Buterin은 최근 Proto-danksharding(일명 EIP-4844)과 관련된 질문에 답변했습니다. Danksharding은 Ethereum을 위해 제안된 새로운 샤딩 설계입니다.이 기술은 무엇을 가져올 수 있습니까?

댄샤딩이란?

Danksharding은 이더리움을 위해 제안된 새로운 샤딩 디자인으로 이전 디자인에 비해 몇 가지 중요한 단순화를 도입했습니다.

2020년 이후의 모든 최근 이더리움 샤딩 제안(Danksharding 및 이전 Danksharding 포함)과 대부분의 비이더리움 샤딩 제안 사이의 주요 차이점은 이더리움의 롤업 중심 로드맵입니다. 프로토콜 자체는 설명을 시도하지 않습니다.

Blob 유효성 검사는 단순히 Blob이 사용 가능한지, 즉 네트워크에서 다운로드할 수 있는지 확인합니다. 이러한 Blob의 데이터 공간은 높은 처리량 트랜잭션을 지원하는 레이어 2(레이어 2) 롤업 프로토콜에서 사용될 것으로 예상됩니다.

Danksharding이 도입한 주요 혁신은 병합된 수수료 시장입니다. 고정된 수의 샤드 대신 각 샤드에는 다른 블록과 다른 블록 제안자가 있습니다. Danksharding에서는 단 한 명의 제안자만 슬롯에 모든 트랜잭션과 모든 데이터를 입력하도록 선택합니다.

이 디자인에서 검증자에 대한 높은 시스템 요구 사항을 피하기 위해 우리는 제안자/빌더 분리(PBS)를 도입합니다. 즉, 블록 빌더라고 하는 특별한 참가자 클래스가 슬롯을 선택할 수 있는 권리에 입찰하고 제안자는 입찰만 선택하면 됩니다. 가장 높은 유효 헤더로 충분합니다. .

블록 빌더만 전체 블록을 처리하면 됩니다(여기서는 타사 분산 오라클 프로토콜을 사용하여 분산 블록 빌더를 구현할 수도 있음). 다른 모든 검증자와 사용자는 데이터 가용성을 매우 효율적으로 샘플링할 수 있습니다. 블록의 일부는 단지 데이터입니다).

proto-danksharding(일명 EIP-4844)이란 무엇입니까?

Proto-danksharding(일명 EIP-4844)은 전체 Danksharding 사양을 구성하는 대부분의 논리 및 "스캐폴딩"(예: 트랜잭션 형식, 유효성 검사 규칙)을 구현하지만 실제로 어떤 부분도 구현하지 않은 EIP(Ethereum Improvement Proposal)입니다. . proto-danksharding 구현에서 모든 검증자와 사용자는 여전히 전체 데이터의 가용성을 직접 확인해야 합니다.

proto-danksharding에 의해 도입된 주요 기능은 블롭이 있는 트랜잭션이라고 하는 새로운 트랜잭션 유형입니다. Blob이 있는 트랜잭션은 Blob이라는 추가 데이터도 전달한다는 점을 제외하면 일반 트랜잭션과 유사합니다. Blob은 매우 크고(~125kB) 비슷한 양의 호출 데이터보다 훨씬 저렴합니다. 그러나 EVM 실행은 blob 데이터에 액세스할 수 없으며 EVM은 blob에 대한 약속만 볼 수 있습니다.

유효성 검사기와 클라이언트는 여전히 전체 blob 콘텐츠를 다운로드해야 하므로 proto-danksharding의 데이터 대역폭 목표는 전체 16MB가 아닌 소켓당 1MB입니다. 그러나 이 데이터는 기존 Ethereum 트랜잭션의 가스 사용량과 경쟁하지 않기 때문에 여전히 큰 확장성 이점이 있습니다.

콜데이터를 10배 저렴하게 만드는 대신 모두가 다운로드해야 하는 청크에 1MB의 데이터를 추가해도 되는 이유는 무엇입니까?

이것은 평균 부하와 최악의 경우 부하의 차이와 관련이 있습니다. 오늘날 우리는 평균 블록 크기가 약 90kB이지만 이론적으로 가능한 최대 블록 크기(블록의 모든 30M 가스가 데이터를 호출하는 데 사용되는 경우)는 약 1.8MB인 상황에 직면했습니다. 최대 블록 수에 가깝게 처리하는 데 사용되는 Ethereum 네트워크.

그러나 단순히 calldata 가스 비용을 10배로 줄이면 평균 블록 크기가 여전히 허용 가능한 수준으로 증가하더라도 최악의 경우는 18MB가 되어 이더리움 네트워크에 너무 많습니다.

현재 가스 가격 체계는 이 두 가지 요소를 분리할 수 없습니다. 평균 부하와 최악의 경우 부하 사이의 비율은 calldata와 다른 리소스에 얼마나 많은 가스를 소비할지에 대한 사용자의 선택에 따라 달라집니다. 최악의 경우 의 우도 설정으로 인해 로드 평균이 시스템이 처리할 수 있는 것보다 불필요하게 낮아집니다.

그러나 가스 가격을 보다 명확하게 다차원 수수료 시장을 생성하도록 변경하면 평균 사례/최악 사례 로드 불일치를 방지하고 안전하게 처리할 수 있는 최대 데이터 양에 가까운 각 블록에 포함할 수 있습니다. Proto-danksharding과 EIP-4488은 이를 위한 두 가지 제안입니다.

proto-danksharding은 EIP-4488과 어떻게 비교됩니까?

EIP-4488은 동일한 평균 사례/최악 사례 부하 불일치 문제를 해결하기 위한 더 빠르고 간단한 시도입니다. EIP-4488은 두 가지 간단한 규칙을 사용하여 이를 수행합니다.

• Calldata 가스 비용이 바이트당 16가스에서 바이트당 3가스로 감소했습니다.

• 블록당 1MB 제한 + 트랜잭션당 추가 300바이트(이론적 최대: ~1.4MB)

엄격한 제한은 평균적인 부하가 크게 증가해도 최악의 경우 부하가 증가하지 않도록 하는 가장 쉬운 방법입니다. 가스 비용의 감소는 롤업 사용을 크게 증가시켜 잠재적으로 평균 블록 크기를 수백 KB로 증가시키지만 하드 제한은 10MB를 포함하는 단일 블록의 최악의 가능성을 직접 방지합니다. 실제로 최악의 경우 블록 크기는 지금보다 작을 것입니다(1.4MB 대 1.8MB).

대신 Proto-danksharding은 큰 고정 크기 blob에서 더 저렴하게 데이터를 저장하고 각 블록이 포함할 수 있는 blob 수를 제한하는 별도의 트랜잭션 유형을 생성합니다. 이러한 Blob은 EVM(Blob에 대한 커밋만)에서 액세스할 수 없으며 Blob은 실행 계층이 아닌 합의 계층(비콘 체인)에 의해 저장됩니다.

EIP-4488과 proto-danksharding의 실질적인 주요 차이점은 EIP-4488은 현재 필요한 변경 사항을 최소화하려는 반면 proto-danksharding은 현재 많은 변경 사항이 있으므로 향후 전체 샤딩으로 업그레이드하면 변경 사항이 거의 필요하지 않다는 것입니다.

전체 샤딩(데이터 가용성 샘플링 등 사용)을 구현하는 것은 복잡한 작업이었고 프로토 댄크샤딩 후에도 복잡한 작업으로 남아 있지만 이러한 복잡성은 합의 계층에 포함됩니다. proto-danksharding이 시작되면 전체 샤딩으로의 전환을 완료하기 위해 경영진 계층 클라이언트 팀, 롤업 개발자 및 사용자의 추가 작업이 필요하지 않습니다.

둘 사이의 선택은 둘 중 하나가 아닙니다. 가능한 한 빨리 EIP-4488을 구현한 다음 반년 후에 proto-danksharding으로 후속 조치를 취할 수 있습니다.

proto-danksharding은 완전한 darksharding의 어떤 부분을 구현합니까? 구현해야 할 다른 사항은 무엇입니까?

EIP-4844를 인용하면 이 EIP에서 수행된 작업은 다음과 같습니다.

• "전체 샤딩"에 존재해야 하는 정확히 동일한 형식의 새로운 트랜잭션 유형입니다.

• 전체 샤딩에 필요한 모든 실행 계층 논리.

• 전체 샤딩에 필요한 모든 실행/합의 교차 검증 논리.

• BeaconBlock 유효성 검사와 데이터 가용성 샘플링 Blob 간의 계층 분리.

• 전체 샤딩에 필요한 대부분의 BeaconBlock 로직.

• Blob에 대한 자체 조정 독립 가스 가격.

• 전체 샤딩을 달성하기 위해 수행해야 할 작업은 다음과 같습니다.

• 2D 샘플링을 허용하기 위해 컨센서스 계층에서 blob_kzgs의 저수준 확장.

• 데이터 가용성 샘플링의 실질적인 구현,

• 하나의 슬롯에서 32MB의 데이터를 처리하기 위해 단일 유효성 검사기가 필요하지 않도록 PBS(제안자/빌더 분할).

• 각 블록에서 샤드 데이터의 특정 부분을 검증하기 위한 각 검증자에 대한 에스크로 증명 또는 유사한 프로토콜 내 요구 사항.

나머지 모든 작업은 합의 계층 변경이며 클라이언트 팀, 사용자 또는 롤업 개발자가 수행할 추가 작업이 필요하지 않습니다.

이 모든 매우 큰 청크가 디스크 공간 요구 사항을 증가시키면 어떻게 됩니까?

EIP-4488과 proto-danksharding 모두 소켓당 약 1MB(12초)의 장기 최대 사용량으로 이어집니다. 이는 연간 약 2.5TB에 해당하며 오늘날 이더리움이 필요로 하는 성장률보다 훨씬 높습니다.

EIP-4488의 경우 이 문제를 해결하기 위해서는 이력 만료 방식(EIP-4444)이 필요하며, 클라이언트는 더 이상 일정 기간(영구적으로 1개월에서 1년까지 시간이 제안됨) 이상 이력을 저장할 필요가 없습니다. .

proto-danksharding의 경우 EIP-4444 구현 여부에 관계없이 합의 계층은 일정 기간(예: 30일) 후에 Blob 데이터를 자동으로 삭제하는 별도의 논리를 구현할 수 있습니다. 그러나 단기 데이터 스케일링 솔루션과 상관없이 EIP-4444는 가능한 한 빨리 구현하는 것이 좋습니다.

두 전략 모두 컨센서스 클라이언트의 추가 디스크 로드를 최대 수백 GB로 제한합니다. 장기적으로 일부 과거 만료 메커니즘을 사용하는 것은 본질적으로 필수입니다. 전체 샤딩은 연간 약 40TB의 과거 blob 데이터를 추가하므로 사용자는 실제로 잠시 동안 그 일부만 저장할 수 있습니다. 따라서 초기에 이에 대한 기대치를 설정하는 것이 좋습니다.

데이터가 30일 후에 삭제된 경우 사용자는 이전 Blob에 어떻게 액세스합니까?

이더리움 합의 프로토콜의 목적은 모든 과거 데이터의 영구 저장을 보장하는 것이 아닙니다. 대신 매우 안전한 실시간 게시판을 제공하고 장기 저장을 위해 다른 분산 프로토콜을 위한 공간을 남겨두는 것이 목적입니다.

게시판은 게시판에 게시된 데이터를 해당 데이터를 원하는 모든 사용자 또는 데이터 백업에 대한 장기 계약이 데이터를 가져와 다른 응용 프로그램으로 가져올 수 있는 충분한 시간을 가질 수 있도록 충분히 오랫동안 사용할 수 있도록 보장하기 위해 존재합니다. 또는 프로토콜.

일반적으로 장기 이력 저장은 쉽습니다. 연간 2.5TB는 일반 노드에 대한 요구 사항이 너무 크지만 전용 사용자에게는 매우 관리하기 쉽습니다. TB당 약 20달러에 초대형 하드 드라이브를 구입할 수 있으며, 이는 취미 생활자에게 충분합니다.

N/2-of-N 신뢰 모델이 있는 합의와 달리 기록 저장소에는 1-of-N 신뢰 모델이 있습니다. 정직하려면 데이터 저장 장치 중 하나만 필요합니다. 따라서 실시간 합의 검증을 수행하는 수천 개의 노드 대신 각 과거 데이터 조각을 수백 번만 저장하면 됩니다.

전체 기록을 저장하고 쉽게 액세스할 수 있는 몇 가지 실용적인 방법은 다음과 같습니다.

• Rollup과 같은 애플리케이션별 프로토콜은 노드가 애플리케이션과 관련된 기록의 일부를 저장하도록 요구할 수 있습니다. 손실된 기록 데이터는 프로토콜에 위험을 초래하지 않으며 개별 애플리케이션에만 영향을 미치므로 애플리케이션이 자신과 관련된 데이터를 저장하는 부담을 지는 것이 합리적입니다.

• 예를 들어 BitTorrent에 기록 데이터 저장. 블록의 Blob 데이터가 포함된 7GB 파일이 자동으로 생성되어 매일 배포됩니다.

• 이더리움 포털 네트워크(현재 개발 중)는 히스토리를 저장하도록 쉽게 확장할 수 있습니다.

• 블록 탐색기, API 공급자 및 기타 데이터 서비스는 전체 기록을 저장할 수 있습니다.

• 데이터 분석에 종사하는 개인 애호가 및 학자는 완전한 과거 기록을 저장할 수 있습니다. 후자의 경우 히스토리를 로컬에 저장하면 히스토리에서 직접 계산하기가 더 쉽기 때문에 중요한 가치를 제공합니다.

• TheGraph와 같은 타사 인덱싱 프로토콜은 전체 기록을 저장할 수 있습니다.

더 높은 수준의 과거 스토리지(예: 연간 500TB)에서는 일부 데이터를 잊어버릴 위험이 높아집니다(또한 데이터 가용성 확인 시스템에 더 많은 스트레스가 가해집니다). 이것이 샤딩된 블록체인의 확장성의 실제 한계일 수 있습니다. 그러나 현재 제안된 모든 매개 변수는 이 지점에서 매우 멀리 떨어져 있습니다.

Blob 데이터의 형식은 무엇이며 어떻게 제출됩니까?

Blob은 4096개의 필드 요소로 구성된 벡터이며 다음 범위의 숫자입니다.

0 <= x < 52435875175126190479447740508185965837690552500527637822603658699938581184513

얼룩은 수학적으로 위의 모듈러스를 가진 유한 필드에 대해 4096 미만의 다항식을 나타내는 것으로 간주되며, 여기서 얼룩의 위치 i에 있는 필드 요소는 wi에서 해당 다항식의 평가입니다. w는 w=1을 만족하는 상수이다.

blob에 대한 커밋은 다항식에 대한 KZG 커밋의 해시입니다. 그러나 구현 관점에서 다항식의 수학적 세부 사항에 신경을 쓰는 것은 중요하지 않습니다. 대신 타원 곡선 점의 벡터(신뢰할 수 있는 라그랑지안 설정 기반)만 있을 것이며 블롭에 대한 KZG 약속은 단순히 선형 조합이 될 것입니다. EIP-4844 코드 인용:

def blob_to_kzg(blob: Vector[BLSFieldElement, 4096]) -> KZGCommitment: computed_kzg = bls.Z1 for value, point_kzg in zip(tx.blob, KZG_SETUP_LAGRANGE): assert value < BLS_MODULUS computed_kzg = bls.add( computed_kzg, bls.multiply(point_kzg, value) ) return computed_kzg

BLS_MODULUS는 위의 모듈러스이고 KZG_SETUP_LAGRANGE는 라그랑주 기반의 신뢰 설정인 타원 곡선 점의 벡터입니다. 이제는 구현자가 단순히 블랙박스에 특화된 해시 함수로 생각하는 것이 합리적입니다.

KZG 대신 KZG의 해시를 직접 사용하는 이유는 무엇입니까?

EIP-4844는 Blob을 직접 나타내기 위해 KZG를 사용하는 대신 버전이 지정된 해시를 사용합니다. 단일 0x01 바이트(이 버전을 나타냄) 다음에 KZG의 SHA256 해시의 마지막 31바이트가 옵니다.

이는 EVM 호환성 및 향후 호환성을 위해 수행됩니다. KZG 약속은 48바이트인 반면 EVM은 보다 자연스럽게 32바이트 값을 사용합니다. 32바이트.

proto-danksharding에 도입된 두 가지 사전 컴파일은 무엇입니까?

Proto-danksharding은 blob 확인 사전 컴파일과 점 평가 사전 컴파일의 두 가지 사전 컴파일을 도입합니다.

blob 유효성 검사 사전 컴파일은 설명이 필요 없습니다. 버전이 지정된 해시와 blob을 입력으로 사용하고 제공된 버전이 지정된 해시가 실제로 blob에 대해 유효한 버전이 지정된 해시인지 확인합니다. 이 사전 컴파일은 낙관적 롤업에서 사용하기 위한 것입니다. EIP-4844 인용:

낙관적 롤업은 사기 증거를 제출할 때 기본 데이터만 실제로 제공하면 됩니다. 사기 증명 제출 기능을 사용하려면 사기 blob의 전체 콘텐츠를 호출 데이터의 일부로 제출해야 합니다. Blob 유효성 검사를 사용하여 이전에 커밋된 버전 해시에 대해 데이터 유효성을 검사한 다음 현재와 같이 해당 데이터에 대해 사기 방지 유효성 검사를 수행합니다.

포인트 평가 사전 컴파일은 버전이 지정된 해시, x 좌표, y 좌표 및 증명(Blob의 KZG 약속 및 KZG 평가 증명)을 입력으로 사용합니다. P(x) = y인지 확인하기 위해 증명을 확인합니다. 여기서 P는 지정된 버전 해시가 있는 blob이 나타내는 다항식입니다. 이 사전 컴파일은 ZK Rollup에서 사용하기 위한 것입니다. EIP-4844 인용:

ZK 롤업은 트랜잭션 또는 상태 델타 데이터에 대해 두 가지 약속을 제공합니다. 즉, Blob의 KZG와 ZK 롤업이 내부적으로 사용하는 증명 시스템을 사용하는 일부 약속입니다. 그들은 kzg(사용 가능한 데이터를 가리키는 프로토콜 보증)와 ZK 롤업의 자체 약속이 동일한 데이터를 참조한다는 것을 증명하기 위해 포인트 평가 사전 컴파일을 사용하여 등가 프로토콜의 약속 증명을 사용할 것입니다.

대부분의 주요 낙관적 롤업 설계는 마지막 라운드에 소량의 데이터만 필요한 다단계 사기 방지 체계를 사용합니다. 따라서 Optimistic Rollup은 Blob 확인 사전 컴파일 대신 포인트 평가 사전 컴파일을 사용할 수도 있으며 그렇게 하는 것이 더 저렴할 것입니다.

KZG 신뢰할 수 있는 설정은 어떤 모습입니까?

바라보다:

신뢰할 수 있는 설정의 작동 방식에 대한 일반적인 설명

powers-of-tau에 대한 https://vitalik.ca/general/2022/03/14/trustedsetup.html 

모든 중요한 신뢰할 수 있는 설정 관련 계산의 구현 예

https://github.com/ethereum/research/blob/master/trusted_setup/trusted_setup.py

특히 우리의 경우 현재 계획은 네 가지 크기를 병렬로 실행하는 것입니다(n1=4096, n2=16), (n1=8192, n2=16), (n1=16834, n2=16) 및 (n1= 32768, n2=16) 의식(비밀이 다름). 이론적으로는 첫 번째 것만 필요하지만 더 큰 크기를 더 많이 실행하면 Blob 크기를 늘릴 수 있으므로 향후 적용 가능성이 향상됩니다. 블롭 크기와 동일하게 효과적으로 커밋할 수 있는 다항식의 수에 대한 엄격한 제한을 가질 수 있기를 원하기 때문에 우리는 더 큰 설정을 가질 수 없습니다.

가능한 실용적인 접근 방식은 Filecoin 설정으로 시작한 다음 이를 확장하기 위한 의식을 실행하는 것입니다. 브라우저 구현을 포함한 여러 구현을 통해 많은 사람들이 참여할 수 있습니다.

신뢰할 수 있는 설정 없이 다른 약정 체계를 사용할 수 없습니까?

안타깝게도 KZG 이외의 것을 사용하면(예: IPA 또는 SHA256) 샤딩 로드맵이 더 어려워집니다. 이에 대한 몇 가지 이유가 있습니다.

비산술 약정(예: 해시 함수)은 데이터 가용성 샘플링과 호환되지 않으므로 이러한 체계를 사용하는 경우 전체 샤딩으로 이동할 때 어쨌든 KZG로 변경해야 합니다.

IPA는 데이터 가용성 샘플링과 호환될 수 있지만 속성이 약한 더 복잡한 체계로 이어집니다(예: 자가 치유 및 분산 블록 구축이 더 어려워짐).

해싱과 IPA 모두 저렴한 포인트 평가 사전 컴파일 구현과 호환되지 않습니다. 따라서 해시 또는 IPA 기반 구현은 ZK 롤업을 효과적으로 활성화하거나 낙관적 롤업의 여러 라운드에서 저렴한 사기 증거를 지원할 수 없습니다.

따라서 불행하게도 KZG 이외의 것을 사용하는 기능의 손실과 복잡성 증가는 KZG 자체의 위험보다 훨씬 큽니다. 또한 모든 KZG 관련 위험이 적용됩니다. KZG 오류는 나머지 시스템이 아닌 Blob 데이터에 의존하는 롤업 및 기타 애플리케이션에만 영향을 미칩니다.

KZG는 얼마나 "복잡하고" "새로운" 것입니까?

KZG 약속은 2010년 논문에 소개되었으며 2019년부터 PLONK 스타일의 ZK-SNARK 프로토콜에 널리 사용되었습니다. 그러나 KZG가 약속하는 기본 수학은 타원 곡선 연산 및 페어링의 기본 수학 위에 상대적으로 간단한 산술입니다.

사용된 특정 곡선은 2002년 Barreto-Lynn-Scott이 발명한 BLS12-381입니다. KZG 약속을 검증하기 위해 필요한 타원 곡선 쌍은 매우 복잡한 수학이지만 1940년대에 발명되어 1990년대부터 암호학에 사용되었습니다. 2001년까지 페어링을 사용하는 여러 암호화 알고리즘이 제안되었습니다.

구현 복잡성의 관점에서 보면 KZG는 IPA보다 구현하기 어렵지 않습니다. 약속을 계산하는 기능(위 참조)은 다른 타원 곡선 점 상수 세트를 사용하는 것 외에는 IPA의 경우와 정확히 동일합니다. Point-verify 사전 컴파일은 쌍 평가를 포함하므로 더 복잡하지만 수학은 EIP-2537(BLS12-381 사전 컴파일) 구현에서 이미 수행된 것과 동일하며 bn128 쌍 사전 컴파일과 매우 유사합니다(최적화 참조). 파이썬 달성). 따라서 KZG 검증을 구현하기 위해 복잡한 "새로운 작업"이 필요하지 않습니다.

proto-danksharding 구현의 다른 소프트웨어 부분은 무엇입니까?

네 가지 주요 구성 요소가 있습니다.

1. 실행 계층 합의가 변경되었습니다(자세한 내용은 EIP 참조).

• Blob을 포함하는 새로운 트랜잭션 유형

• 현재 트랜잭션에서 i번째 blob의 버전 해시를 출력하는 opcode

• Blob 유효성 검사 사전 컴파일

• 도트 평가 사전 컴파일

2. 컨센서스 레이어 컨센서스 변경 사항(저장소의 이 폴더 참조):

• BeaconBlockBody의 Blob KZG 목록

• 전체 blob 콘텐츠가 BeaconBlock에서 별도의 개체와 함께 전달되는 "사이드카" 메커니즘

• 실행 계층의 Blob 버전 해시와 합의 계층의 Blob KZG 간 교차 확인

3. 메모리 풀

• BlobTransactionNetworkWrapper(EIP의 네트워크 섹션 참조)

• 큰 Blob 크기를 보상하기 위해 더 강력해진 Anti-DoS 보호

4. 블록 생성 로직

• mempool에서 트랜잭션 래퍼를 수락하고 트랜잭션을 ExecutionPayload에 넣고 KZG를 비콘 블록에 넣고 사이드카에 본문을 넣습니다.

• 2차원적 수수료 시장 대응

최소 구현의 경우 mempool이 전혀 필요하지 않으며(두 번째 레이어 트랜잭션 번들 시장에 의존할 수 있음) 블록 구축 논리를 구현하는 클라이언트만 있으면 됩니다. 실행 계층과 합의 계층의 합의 변경에만 상대적으로 가벼운 광범위한 합의 테스트가 필요합니다. 이러한 최소 구현과 모든 클라이언트가 블록 생성 및 mempool을 지원하는 "전체" 배포 사이의 모든 것이 가능합니다.

proto-danksharding 다차원 수수료 시장은 어떤 모습입니까?

Proto-danksharding은 별도의 부동 가스 가격과 별도의 한도가 있는 두 가지 리소스(가스 및 블롭)가 있는 다차원 EIP-1559 수수료 시장을 도입합니다.

이더 리움

Blob 수수료는 가스로 청구되지만 장기적으로 블록당 평균 Blob 수가 실제로 목표 금액과 같도록 조정되는 가변 가스 양입니다.

2차원적 특성은 블록 빌더가 더 어려운 문제에 직면하게 됨을 의미합니다. 거래가 소진되거나 블록 가스 한도에 도달할 때까지 우선 순위가 가장 높은 거래를 수락하는 대신 두 가지 다른 제한에 도달하는 것을 피해야 합니다.

다음은 예입니다. 가스 한도가 70이고 blob 한도가 40이라고 가정해 보겠습니다. mempool에는 블록을 채울 만큼 많은 트랜잭션이 있으며 두 가지 유형이 있습니다(tx 가스에는 blob 가스가 포함됨).

• 우선 수수료 가스당 5, 블롭 4개, 총 가스 4개

• 가스당 우선 수수료 3, 블롭 1개, 총 가스 2개

이더 리움

실행 클라이언트는 이제 블록 생산을 최적화하기 위해 복잡한 다차원 배낭 알고리즘을 구현해야 합니까? 아니요, 몇 가지 이유가 있습니다.

• EIP-1559는 대부분의 블록이 한도에 도달하지 않도록 보장하므로 소수의 블록만 실제로 다차원 최적화 문제에 직면합니다. mempool이 한도에 도달하기에 충분한(충분한 지불) 거래가 없는 일반적인 경우, 모든 광부는 그들이 보는 모든 거래를 포함하여 최적의 수익을 올릴 수 있습니다.

• 실제로는 매우 간단한 휴리스틱이 최적에 가까워질 수 있습니다. 유사한 상황에서 이에 대한 일부 데이터는 Ansgar의 EIP-4488 분석을 참조하십시오.

• 다차원 가격 책정은 전문화에서 가장 큰 수익원이 아닙니다. MEV는 전문화입니다. 온체인 DEX 차익 거래, 청산, 선행 NFT 판매 등에서 전용 알고리즘을 통해 추출된 전용 MEV 수익은 총 "추출 가능한 수익"(즉, 우선 수수료)의 상당 부분을 차지합니다. 전용 MEV 수익은 평균 약 0.025 ETH로 나타납니다. 영역 블록당 총 우선 순위 수수료는 일반적으로 블록당 약 0.1 ETH입니다.

• 제안자/빌더 분리는 고도로 전문화된 블록 생산을 중심으로 설계되었습니다. PBS는 블록 구축 프로세스를 전문 참가자가 블록 생성 특권을 위해 입찰하는 경매로 바꿉니다. 일반 유효성 검사기는 가장 높은 입찰가만 수락하면 됩니다. 이는 MEV 중심의 규모의 경제가 검증자 중앙 집중화로 스며드는 것을 방지하기 위한 것이지만, 블록 구축 최적화를 더 어렵게 만들 수 있는 모든 문제를 처리합니다.

이러한 이유로 더 복잡한 수수료 시장 역학은 중앙 집중화나 위험을 크게 증가시키지 않으며 실제로 더 광범위하게 적용되는 원칙은 실제로 DoS 공격의 위험을 줄일 수 있습니다!

지수 EIP-1559 블롭 수수료 조정 메커니즘은 어떻게 작동합니까?

오늘의 EIP-1559는 다음과 같이 특정 목표 가스 사용 수준 t를 달성하기 위해 기본 요금 b를 조정합니다.

여기서 b(n)은 현재 블록의 기본 수수료, b(n+1)은 다음 블록의 기본 수수료, t는 목표, u는 사용된 가스입니다.

이더 리움

평균 사용량은 t이지만 기본 요금은 63/64로 떨어집니다. 따라서 기본 요금은 사용량이 t보다 약간 높은 경우에만 안정적이며, 정확한 수치는 분산에 따라 다르지만 실제로는 약 3% 더 높습니다.

더 나은 공식은 지수 조정입니다.

exp(x)는 지수 함수 e^x이며 여기서 e≈2.71828입니다. x의 값이 작은 경우 exp(x)≈1+x. 그러나 트랜잭션 순열과 관련이 없는 편리한 속성이 있습니다: 다단계 조정

이더 리움

따라서 포함된 동일한 트랜잭션은 서로 다른 블록에 어떻게 분산되어 있든 상관없이 동일한 최종 기본 수수료가 발생합니다.

위의 마지막 공식도 자연스러운 수학적 해석이 있습니다. (u1+u2+...+u/n-nt)라는 용어는 실제로 사용된 총 가스와 사용하려는 총 가스 간의 차이로 중복되는 것으로 볼 수 있습니다.

현재 기본 요금은 다음과 같습니다.

초과분은 매우 좁은 범위를 넘을 수 없다는 사실: 8t*60을 넘으면 기본료는 e^60이 되어 누구도 지불할 수 없을 정도로 터무니없이 높으며, 0 미만이면 자원은 기본적으로 공짜다. 초과가 0 이상으로 돌아올 때까지 체인은 스팸 처리됩니다.

조정 메커니즘은 정확히 다음과 같이 작동합니다. 실제 총계(u1+u2+...+u/n)를 추적하고 목표 총계(nt)를 계산하고 차이의 지수로 가격을 계산합니다. 계산을 쉽게 하기 위해 e^x 대신 2^x를 사용합니다. 거짓 지수는 거의 항상 실제 값의 0.3% 이내입니다.

장기간의 저활용으로 인해 장기간 2x 전체 블록이 발생하는 것을 방지하기 위해 추가 기능을 추가했습니다. 초과 블록이 0 아래로 떨어지지 않도록 합니다. actual_total이 target_total보다 낮으면 actual_total을 target_total과 동일하게 설정합니다. 극단적인 경우(blob 가스가 0까지 내려가는 경우) 이것은 트랜잭션 순서 불변성을 깨뜨리지만 추가된 안전성으로 인해 이를 허용 가능한 절충안으로 만듭니다.

또한 이 다차원 시장의 흥미로운 결과에 주목하십시오. proto-danksharding이 처음 도입될 때 처음에는 사용자가 거의 없을 가능성이 높으므로 한동안 blob 비용은 "일반"의 경우에도 거의 확실하게 매우 저렴할 것입니다. 이더리움 블록체인 활동은 여전히 ​​비쌉니다.

저자는 이 수수료 조정 메커니즘이 현재 접근 방식보다 낫다고 생각하므로 결국 EIP-1559 수수료 시장의 모든 부문이 이를 사용하도록 이동해야 합니다.

더 길고 자세한 설명은 Dankrad의 게시물을 참조하십시오.

fake_exponential은 어떻게 작동합니까?

편의상 다음은 fake_exponential에 대한 코드입니다.

def fake_exponential(numerator: int, denominator: int) -> int: cofactor = 2 ** (numerator // denominator) fractional = numerator % denominator return cofactor + ( fractional * cofactor * 2 + (fractional ** 2 * cofactor) // denominator ) // (denominator * 3)

이더 리움

목표는 (QX)의 많은 인스턴스를 함께 연결하는 것이며, 그 중 하나는 각 [2^k,2^(k+1)] 범위에 대해 적절하게 이동되고 크기가 조정됩니다. Q(x) 자체는 다음 속성에 대해 선택된 0≤x≤1에 대한 2^x의 근사치입니다.

• 단순성(이차방정식)

• 왼쪽 가장자리의 정확성(Q(0)=2^0=1)

• 오른쪽 가장자리 정확성(Q(1)=2^1=2)

• 부드러운 기울기(Q'(1)=2*Q'(0)임을 확인하므로 Q의 각 shift+scaled 복사본은 오른쪽 가장자리에서 다음 복사본이 왼쪽 가장자리에 있는 것과 동일한 기울기를 가집니다.)

마지막 3개는 3개의 알려지지 않은 계수가 주어진 3개의 선형 방정식을 필요로 하며 위에 주어진 Q(x)는 유일한 솔루션을 제공합니다.

이더 리움

proto-danksharding에서 어떤 문제가 여전히 논의되고 있습니까?

참고: 이 섹션은 쉽게 구식입니다. 특정 문제에 대한 최신 생각을 제공한다고 믿지 마십시오.

• 모든 주요 낙관적 롤업은 다중 라운드 증명을 사용하므로 블롭 검증 사전 컴파일 대신 (훨씬 저렴한) 포인트 평가 사전 컴파일을 사용할 수 있습니다. Blob 확인이 정말로 필요한 사람은 누구나 직접 구현할 수 있습니다. 입력으로 Blob D와 버전이 지정된 해시 h를 취하고, x=hash(D,h)를 선택하고, 중심 평가를 사용하여 y=D(x)를 계산하고 예측합니다. 컴파일하고 h를 확인합니다. (x)=y. 그렇다면 Blob 유효성 검사 사전 컴파일이 정말로 필요한가요, 아니면 그냥 제거하고 포인트 평가만 사용할 수 있나요?

• 오래 지속되는 1MB 이상의 블록을 처리하는 체인의 능력은 어느 정도입니까? 위험이 너무 크면 먼저 대상 Blob 수를 줄여야 합니까?

• Blob은 가스 또는 ETH(소각)로 표시되어야 합니까? 수수료 시장에 대한 다른 조정이 있어야 합니까?

• 새 트랜잭션 유형을 Blob 또는 SSZ 객체로 간주해야 합니까? 후자의 경우 ExecutionPayload를 공용체 유형으로 변경해야 합니까? ("지금 더 많은 일을 하라"와 "나중에 더 많은 일을 하라"는 절충안입니다.)

• 신뢰할 수 있는 설정 구현의 정확한 세부 사항(기술적으로 EIP 자체의 범위를 벗어남, 이러한 설정은 구현자에게 "단지 상수"이지만 여전히 수행해야 함).