Delphi Digital: 업계에서 가장 완벽한 이더리움 고급 가이드

BTC0.0₂₀

ETH0.0₂₀

HTX0.0₂₀

SOL0.0₂₀

BNB0.0₂₀

BTC0.0₂₀

ETH0.0₂₀

HTX0.0₂₀

SOL0.0₂₀

BNB0.0₂₀

Delphi Digital: 업계에서 가장 완벽한 이더리움 고급 가이드

DAOrayaki

2022-06-20 14:00

本文约24141字，阅读全文需要约97分钟

이 글은 당연하게 받아들일 수 없습니다. 이더리움의 야심 찬 로드맵을 광범위하고 미묘하게 살펴보고 싶다면 한 시간만 주시면 몇 달 간의 작업 시간을 절약해 드리겠습니다.

저자: 존 샤르보노

원제: 이더리움을 여행하는 히치하이커를 위한 안내서

핵심 포인트:

이더리움은 확장 가능한 통합 결제 및 데이터 가용성 계층을 구축하는 것을 목표로 하는 유일한 주요 프로토콜입니다.
롤업은 Ethereum의 보안을 활용하면서 계산을 확장합니다.
모든 길은 중앙 집중식 블록 생산, 탈중앙식 무신뢰 블록 검증 및 검열 저항의 최종 게임으로 이어집니다.
보안 또는 분산화 목표를 희생하지 않고 확장성을 달성할 수 있는 권한(구성 및 검증)의 분리를 가져오는 개시자-빌더 분리 및 약한 상태 비저장과 같은 혁신
MEV는 이제 전면 중앙에 있습니다. 디자인의 대부분은 MEV의 피해를 완화하고 중앙 집중화 경향을 방지하도록 계획되었습니다.
Danksharding은 최첨단 연구에 대한 여러 접근 방식을 결합하여 Ethereum의 롤업 중심 로드맵에 필요한 확장 가능한 기본 계층을 제공합니다.
목차

Vitalik이 오늘 태어난 사람이 서기 3000년까지 살 확률이 50-75%이며 영원히 살기를 희망한다고 말한 이후로 나는 합병의 시기에 대해 상당히 회의적이었습니다. 하지만 뭐야, 재미 좀 보자. 이 기회에 이더리움의 야심 찬 로드맵을 자세히 살펴보자.

이더리움 연구에는 추적해야 할 것이 많지만 분산된 유효성 검사를 희생하지 않고 계산을 확장하는 하나의 중요한 목표로 모두 연결됩니다.

Vitalik은 유명한 "endgame"이라는 말을 가지고 있습니다. 들어 보셨는지 모르겠습니다. 그는 이더리움을 확장하려면 어느 정도 중앙 집중화가 필요하다는 점을 인정했습니다. 블록체인에서 중앙화를 뜻하는 C는 무섭지만 현실이다. 우리는 분산되고 신뢰할 수 없는 검증을 통해 이 권한을 제어하기만 하면 됩니다. 여기에는 타협이 없습니다.

전문가는 L1 이상에 추가됩니다. 롤업은 L1에서 보안을 상속받는 반면, 이더리움은 간단한 분산 검증으로 매우 안전하게 유지됩니다. 그런 다음 이더리움은 정산 및 데이터 가용성을 제공하여 롤업을 확장할 수 있습니다. 여기서의 모든 연구는 궁극적으로 이 두 가지 역할을 최적화하는 동시에 블록체인의 완전한 검증을 그 어느 때보다 쉽게 만드는 것을 목표로 합니다.

다음 용어는 약 7~859회 반복됩니다.

DA – 데이터 가용성 데이터 가용성
DAS – 데이터 가용성 샘플링 데이터 가용성 샘플링
PBS - 제안자-빌더 분리 개시자 및 빌더 분리
PDS – 프로토 댄크샤딩 네이티브 다크샤딩
DS – 이더리움 샤딩 설계를 Danksharding
PoW – 작업 증명 워크로드 증명
PoS – 지분 증명 서약 증명

1부 Danksharding으로 가는 길

이더리움이 롤업 중심 로드맵으로 전환했다는 소식을 들었기를 바랍니다. 더 이상 실행 샤드 없음 - 이더리움은 대신 데이터 사용량이 많은 롤업을 위해 최적화합니다. 이것은 데이터 샤딩(Ethereum의 계획 중 일부) 또는 더 큰 블록(Celestia의 계획)을 통해 달성됩니다.

합의 계층은 샤딩된 데이터를 해석하지 않습니다. 데이터를 사용할 수 있는지 확인하는 작업이 하나뿐입니다.

롤업, 사기, ZK 증명과 같은 기본 개념과 DA(데이터 가용성)가 중요한 이유에 익숙하다고 가정하겠습니다. 익숙하지 않거나 복습이 필요한 경우 Can의 최근 Celestia 보고서를 참조하십시오.

원본 데이터 샤딩 설계 - 독립적인 샤딩 제안

여기에 설명된 디자인은 더 이상 사용되지 않지만 배경을 살펴볼 가치가 있습니다. 편의상 "샤딩 1.0"이라고 하겠습니다.

64개의 샤드 각각에는 검증자 세트에서 순환되는 개별 제안 및 위원회가 있습니다. 그들은 샤드의 데이터가 사용 가능한지 독립적으로 확인합니다. 처음에는 DAS(Data Availability Sampling)가 아닙니다. 데이터를 완전히 다운로드하기 위해 각 샤드의 유효성 검사기 집합의 정직한 대다수에 의존합니다.

이 디자인은 불필요한 복잡성, 더 나쁜 사용자 경험 및 공격 벡터를 도입합니다. 샤드 간에 유효성 검사기를 재구성하는 것은 위험할 수 있습니다.

매우 엄격한 동기화 가정을 도입하지 않는 한 투표가 단일 슬롯 내에서 수행된다는 보장도 어렵습니다. 비콘 블록 제안은 지연될 수 있는 모든 개별 위원회 투표를 수집해야 합니다.

(원래의 데이터 샤딩 설계에서는 각 샤드가 위원회 투표로 확정됩니다. 투표가 항상 단일 슬롯에서 이루어지는 것은 아니며 샤드는 최대 두 에포크까지 확정될 수 있습니다.)

DS(Danksharding)는 완전히 다릅니다. 유효성 검사기는 DAS를 수행하여 모든 데이터가 사용 가능한지 확인합니다(더 이상 별도의 샤드 위원회가 없음). 전용 빌더(Builder)는 Beacon 블록과 조각난 모든 데이터를 사용하여 큰 블록을 생성하고 이를 확인합니다. 따라서 DS가 분산된 상태를 유지하려면 PBS(제안과 빌더의 분리)가 필요합니다(큰 블록을 함께 구축하는 것은 리소스 집약적임).

데이터 가용성 샘플링(DAS)

롤업은 많은 데이터를 게시하지만 모든 데이터를 다운로드하기 위해 노드에 부담을 주고 싶지 않습니다. 이는 높은 자원 할당을 의미하므로 분산화를 손상시킵니다.

대신 DAS를 사용하면 노드(라이트 클라이언트 포함)가 모든 데이터를 다운로드하지 않고도 모든 데이터를 사용할 수 있는지 쉽고 안전하게 확인할 수 있습니다.

순진한 솔루션 - 블록에서 임의의 부분을 확인하십시오. 문제가 없으면 서명만 하면 끝납니다. 그러나 거래를 놓치면 모든 ETH가 나쁜 사람에게 소모됩니다. 이것이 안전할 수 있습니까(safu).
영리한 솔루션 - 데이터를 먼저 삭제 코드로 지정합니다. 데이터는 Reed-Solomon 코드를 사용하여 확장됩니다. 이는 데이터가 다항식으로 보간되어 다른 곳에서 평가할 수 있음을 의미합니다. 이것은 약간 복잡하므로 분해해 보겠습니다.

수학에 대해 걱정하지 마세요. 집중 코스가 있습니다. (여기서는 수학이 그렇게 무섭지 않다고 장담합니다. 이 부분을 작성하기 위해 칸아카데미 비디오를 몇 개 봐야 했지만 지금은 이해하고 있습니다).

다항식은 형태의 유한한 수의 항을 더한 표현입니다. 항의 수는 가장 높은 지수를 나타냅니다. 예를 들어, + + - 4는 3차 다항식입니다. 다항식에 있는 모든 좌표에서 차수의 다항식을 재구성할 수 있습니다.

이제 구체적인 예를 살펴보십시오. 아래에는 4개의 데이터 블록(to)이 있습니다. 이러한 데이터 블록은 주어진 지점에서 다항식 값에 매핑될 수 있습니다. 예를 들어, =. 그런 다음 이 값을 만족하는 최소 차수 다항식을 찾습니다. 이것은 4개의 데이터 블록이므로 3차 다항식을 찾을 수 있습니다. 그런 다음 동일한 다항식에 있는 4개의 값( 에 )을 추가하여 이 데이터를 확장할 수 있습니다.

핵심 다항식 속성을 기억하세요. 원래 4개의 청크뿐만 아니라 4개의 점에서 재구성할 수 있습니다.

DAS로 돌아갑니다. 이제 삭제 코딩된 데이터의 50%(4/8)를 사용할 수 있는지 확인하기만 하면 됩니다. 이를 통해 전체 데이터 블록을 재구성할 수 있습니다.

따라서 공격자는 데이터 블록의 50% 이상을 숨겨 DAS 노드가 데이터를 사용할 수 없을 때 데이터를 사용할 수 있다고 생각하도록 성공적으로 속여야 합니다.

많은 성공적인 임의 샘플링 후 데이터의 <50%를 사용할 수 있는 확률은 매우 적습니다. 삭제 코딩된 데이터를 30회 성공적으로 샘플링하면 사용할 수 있는 확률이 50% 미만입니다.

KZG 약속

자, 우리는 많은 무작위 샘플을 만들었고 모두 사용할 수 있습니다. 그러나 여전히 질문이 있습니다. 데이터 삭제가 올바르게 코딩되어 있습니까? 그렇지 않으면 블록 생산자가 블록을 확장할 때 50%의 쓰레기를 추가했을 수 있으며 샘플링은 시간 낭비였습니다. 이 경우 실제로 데이터를 재구성할 수 없습니다.

일반적으로 Merkle 루트를 사용하여 많은 양의 데이터를 커밋합니다. 이는 집합에 일부 데이터가 포함되어 있음을 증명하는 데 유용합니다.

그러나 모든 원본 데이터와 확장 데이터가 동일한 저차 다항식에 있다는 것도 알아야 합니다. 메르켈은 그것을 증명할 수 없습니다. 따라서 이 계획을 사용하는 경우 발생할 수 있는 실수를 방지하기 위해 사기 증거도 필요합니다.

(머클 루트는 우리가 데이터와 데이터 확장에 대한 약속을 할 수 있게 해주지만, 그것들이 동일한 저차 다항식에 해당하는지 여부를 알려줄 수는 없습니다.)

개발자는 이 문제를 두 가지 방향으로 해결할 수 있습니다.

Celestia는 사기 방지 경로를 사용하고 있습니다. 이 계획은 누군가가 지켜봐야 하며 블록이 잘못 삭제 코딩된 경우 사기 증거를 제출하여 모든 사람에게 경고합니다. 여기에는 표준 정직한 소수 가정 및 동시성 가정이 필요합니다(즉, 누군가 나에게 사기 증거를 보내는 것 외에도 내가 온라인 상태이고 제한된 시간 내에 받을 것이라고 가정해야 합니다).
Ethereum과 Polygon Avail은 KZG 약속(일명 Kate 약속)이라는 새로운 길을 걷고 있습니다. 이렇게 하면 사기 증명을 안전하게 유지하기 위해 정직한 소수 및 동시성 가정이 제거됩니다(아직도 존재하고 재구성에 사용되지만 곧 설명하겠습니다).

다른 솔루션이 없는 것은 아니지만 덜 찾는 솔루션입니다. 예를 들어 ZK 증명을 사용할 수 있습니다. 불행하게도, 그것들은 (현재로서는) 계산상 비실용적입니다. 그러나 향후 몇 년 동안 개선될 것으로 예상되므로 KZG가 양자 저항성이 없다고 약속함에 따라 Ethereum은 향후 STARK로 전환할 가능성이 높습니다.

(저는 여러분이 포스트 퀀텀 STARK에 대한 준비가 되어 있지 않다고 생각하지만, 여러분의 다음 세대는 그것을 좋아할 것입니다)

KZG 약정으로 돌아가서 다항식 약정 체계입니다.

약정 체계는 일부 가치에 대한 약정을 증명할 수 있도록 하는 암호화 방식일 뿐입니다. 가장 좋은 비유는 편지를 잠긴 상자에 넣고 다른 사람에게 전달하는 것입니다. 한 번 받은 편지는 변경할 수 없지만 열쇠로 열어 증명할 수 있습니다. 당신은 편지에 전념하고 열쇠는 증거입니다.

우리의 경우 모든 원본 데이터와 확장 데이터를 X,Y 그리드에 매핑한 다음 해당 데이터에 맞는 최소 차수 다항식을 찾습니다(이 프로세스를 Lagrangian 보간이라고 함). 이 다항식은 증명자가 약속한 것입니다.

(KZG 약속을 통해 데이터 및 데이터 확장에 대한 약속을 할 수 있으며 동일한 저차 다항식에 속함을 증명할 수 있습니다.)

몇 가지 핵심 사항:

먼저 다항식이 있습니다.
이 다항식 형식에 대한 증명자의 약속
이는 신뢰할 수 있는 타원 곡선 암호화 설정에 의존합니다. 이것이 어떻게 작동하는지에 관해서는 Bartek의 훌륭한 스레드가 있습니다.
이 다항식의 값에 대해 증명자는 증명을 계산할 수 있습니다.
인간의 말로 말하면: 증명자는 이러한 조각을 모든 검증자에게 제공하고 검증자는 특정 지점의 값(여기서 값은 뒤의 데이터를 나타냄)이 제출된 다항식에 올바르게 위치하는지 확인할 수 있습니다.
이것은 모든 값이 동일한 다항식에 있기 때문에 원본 데이터에 대한 확장을 정당화합니다.
참고: 검증자는 다항식을 사용할 필요가 없습니다.
중요 속성 — 준수할 약속의 크기 , 증명 크기 , 확인 시간 . 증명자의 경우에도 커밋 및 증명의 생성은 다항식의 차수인 의 복잡성을 가집니다.
직설적으로 말하면, (값의 수)가 증가하더라도(즉, 샤드 크기에 따라 데이터 세트가 증가하더라도) 커밋 및 증명의 크기는 일정하게 유지되고 확인에 필요한 작업량은 일정합니다.
Promise와 Proof는 모두 Pairing Friendly Curves의 타원 곡선 요소일 뿐입니다(여기서는 BLS12-381이 사용됨). 이 경우 각각 48바이트에 불과합니다(정말 작음).
따라서 많은 양의 원본 및 확장 데이터(다항식에 대해 많은 값으로 표현됨)에 대한 증명자의 약속은 여전히 48바이트에 불과하며 증명도 48바이트에 불과할 것입니다.
간단히 말해서: 합리적으로 잘 확장됨

여기서 KZG 루트(다항식 커밋)는 Merkle 루트(벡터 커밋)와 유사합니다.

원본 데이터는 다항식의 값입니다. ~까지 다항식을 평가하여 확장합니다. 모든 점은 동일한 다항식에 있음을 보장합니다.

한 문장으로: DAS를 사용하면 이레이저 코딩된 데이터를 사용할 수 있는지 여부를 확인할 수 있습니다. KZG는 원본 데이터가 올바르게 스케일링되었음을 증명하고 모든 데이터를 약속합니다.

음, 모든 대수학은 여기서 끝납니다.

KZG 약속 대 사기 증명

이제 KZG의 작동 방식을 이해했으므로 뒤로 물러서서 두 접근 방식을 비교해 보겠습니다.

KZG의 단점은 사후 양자 보안이 되지 않으며 신뢰할 수 있는 초기화가 필요하다는 것입니다. 이것은 걱정할 필요가 없습니다. STARK는 포스트 퀀텀 대안을 제공하는 반면 신뢰할 수 있는 초기화(공개 참여)에는 정직한 참가자 한 명만 필요합니다.

KZG의 장점은 사기 방지 설정보다 대기 시간이 짧다는 것입니다(앞서 언급했듯이 GASPER는 어쨌든 빠른 최종 결과를 얻지 못함) 사기 방지에 도입되지 않고 적절한 코드 삭제를 보장합니다. 몇 가지 가정입니다.

그러나 Ethereum이 여전히 블록 재구성에서 이러한 가정을 다시 도입한다는 점을 감안할 때 실제로 제거하지는 않습니다. DA 계층은 항상 블록이 초기에 사용 가능하다고 가정해야 하지만 노드는 블록을 다시 결합하기 위해 서로 통신해야 합니다. 이 재구성에는 두 가지 가정이 필요합니다.

데이터를 결합할 수 있는 충분한 힘이 있는 데이터를 샘플링하는 충분한 노드(경량 또는 중량)가 있습니다. 이것은 다소 약하고 피할 수 없는 정직한 소수 가정이며 걱정할 것이 없습니다.
동시성 가정이 다시 도입되었습니다. 노드는 재조립되기 전에 특정 시간 내에 통신해야 합니다.

이더리움 유효성 검사기는 PDS(네이티브 다크샤딩)에서 샤드 데이터를 완전히 다운로드하는 반면 DS에서는 DAS(지정된 행 및 열 다운로드)만 수행합니다. Celestia는 유효성 검사기가 전체 블록을 다운로드하도록 요구합니다.

두 경우 모두 재구성을 위한 동기화 가정이 필요합니다. 블록이 부분적으로만 사용 가능한 경우 전체 노드는 다른 노드와 통신하여 블록을 결합해야 합니다.

Celestia가 검증자에게 전체 데이터를 다운로드하도록 요구하는 것에서 DAS만 수행하는 것으로 이동하려는 경우 KZG의 대기 시간 이점이 작용할 것입니다(이러한 전환은 현재 계획되지 않음). 그런 다음 그들은 또한 KZG 약속을 이행해야 합니다. 사기 증명을 기다리는 것은 블록 간격을 크게 늘리는 것을 의미하며 잘못 인코딩된 블록에 대한 유효성 검사기 투표의 위험도 높을 것입니다.

KZG 약속이 어떻게 작동하는지 더 깊이 이해하려면 다음 기사를 읽는 것이 좋습니다.

(상대적으로 이해하기 쉬운) 타원 곡선 암호화의 기본
Vitalik의 타원 곡선 쌍 탐색
Dankrad의 KZG 다항식 약속
Vitalik의 신뢰할 수 있는 초기화 원칙

프로토콜 내에서 개시자와 빌더의 분리

오늘날의 합의 노드(채굴자)와 병합된 합의 노드(검증자)는 서로 다른 역할을 합니다. 실제 블록을 만든 다음 검증을 위해 다른 합의 노드에 제출합니다. 광부는 이전 블록에 "투표"하고 병합 후 유효성 검사기는 블록이 유효한지 여부에 대해 직접 투표합니다.

PBS(개시자와 빌더의 분리)는 이를 분리합니다. 즉, 새로운 프로토콜 내 빌더 역할을 명시적으로 생성합니다. 전담 빌더가 블록을 함께 배치하고 생성자(검증자)가 블록을 선택하도록 입찰합니다. 이는 MEV의 중앙 집중식 전력에 대응합니다.

Vitalik의 "엔드게임"을 되돌아보면 모든 길은 신뢰할 수 없고 분산된 검증을 통해 중앙 집중식 블록 생산으로 이어집니다. PBS는 한 단계 더 나아갑니다. 우리는 네트워크의 유효성과 검열 저항을 제공하기 위해 정직한 빌더가 필요하지만(두 개가 더 효과적일 것입니다) 검증자 세트에는 정직한 다수가 필요합니다. PBS는 유효성 검사기의 분산화를 지원하기 위해 개시자의 역할을 가능한 한 간단하게 만듭니다.

빌더는 우선 수수료 팁과 인출할 수 있는 MEV를 받습니다. 효율적인 시장에서 경쟁적인 빌더는 블록에서 추출할 수 있는 전체 가치(고가의 하드웨어 등과 같은 상각 비용 제외)에 대해 입찰할 것입니다. 모든 가치는 분산된 검증자 세트로 흘러내릴 것입니다. 이것이 바로 우리가 원하는 것입니다.

정확한 PBS 구현은 아직 논의 중이지만 2슬롯 PBS는 다음과 같습니다.

빌더는 입찰하는 동안 블록 헤더를 커밋합니다.
비콘 블록 발신자는 낙찰된 블록 헤더와 입찰가를 선택합니다. 발신자는 빌더가 블록 본체를 생산하지 못하더라도 낙찰에 대해 무조건 돈을 받습니다.
증명자 위원회는 승리한 블록 헤더를 확인합니다.
건축업자는 낙찰 대상을 공개합니다.
증인으로 구성된 다른 위원회가 승리한 조직을 선출합니다(승리한 건축업자가 조직을 제시하지 않으면 존재하지 않음을 증명하기 위해 투표합니다).

개시자는 표준 RANDAO 메커니즘을 사용하여 검증자 그룹에서 선택됩니다. 그런 다음 위원회에서 블록 헤더를 확인할 때까지 전체 본문을 공개하지 않는 확약-공개 전략을 사용합니다.

Promise-disclosure가 더 효율적이며(수백 개의 전체 블록 바디를 전송하면 p2p 계층의 대역폭을 압도할 수 있음) MEV 도용도 방지할 수 있습니다. 빌더가 전체 블록을 제출하면 다른 빌더가 이를 보고, 전략을 파악하고, 통합하고, 더 나은 블록을 신속하게 게시할 수 있습니다. 또한 정교한 이니시에이터는 사용된 MEV 전략을 감지하여 빌더를 보상하지 않고 이를 복제할 수 있습니다. 이렇게 MEV를 훔치는 것이 균형을 이루는 힘이 되면 빌더와 창시자의 합병을 장려할 것이므로 이를 피하기 위해 약정-공개 전략을 사용합니다.

이니시에이터가 우승한 블록 헤더를 선택한 후 위원회에서 이를 확인하고 포크 선택 규칙에서 강화합니다. 그런 다음 수상한 빌더는 우승한 전체 "빌더 블록" 본문을 게시합니다. 제 시간에 게시되면 다음 위원회에서 이를 인증합니다. 제 시간에 출판하지 못하더라도 여전히 창작자에게 전액을 지불해야 합니다(그리고 모든 MEV와 수수료를 잃게 됩니다). 이 무조건적인 지불로 인해 개시자는 빌더를 신뢰할 필요가 없습니다.

이 "이중 슬롯" 설계의 단점은 대기 시간입니다. 병합된 블록은 고정된 12초이므로 새로운 가정을 도입하지 않고 전체 블록 시간(2개의 12초 슬롯)에 24초가 필요합니다. 8초 슬롯(블록 시간 16초)은 보안 타협처럼 보이지만 연구가 진행 중입니다.

검열 저항 목록(crList)

불행히도 PBS는 빌더에게 거래를 검토할 수 있는 많은 기능을 제공했습니다. 건축업자가 당신을 좋아하지 않아서 당신의 거래를 무시했을 수도 있습니다. 어쩌면 그들은 너무 잘 작동하여 다른 빌더들이 포기할 수도 있고, 아니면 그들이 당신을 정말로 좋아하지 않기 때문에 블록에 높은 가격을 책정할 수도 있습니다.

crLists는 이를 방지합니다. 특정 구현은 다시 개방형 설계 공간이지만 "하이브리드 PBS"가 가장 인기 있는 것 같습니다. 빌더는 mempool에서 볼 수 있는 모든 적합한 트랜잭션 목록을 지정하고 빌더는 블랭킷 트랜잭션을 수락해야 합니다(블록이 가득 차 있지 않은 경우).

개시자는 모든 적합한 트랜잭션과 함께 crList 및 crList 다이제스트를 게시합니다.
빌더는 제안된 블록 본문을 생성한 다음 crList 다이제스트의 해시를 포함하는 입찰을 그들이 본 증거로 제출합니다.
개시자는 낙찰자의 입찰 및 블록 헤더를 수락합니다(그들은 아직 블록 본문을 보지 못했습니다).
빌더는 crList에 모든 트랜잭션을 포함했거나 블록이 가득 찼다는 증거를 포함하여 블록을 게시합니다. 그렇지 않으면 포크 선택 규칙에 의해 블록이 승인되지 않습니다.
목격자(입증자)는 게시된 주체의 유효성을 확인합니다.

여기에는 아직 해결해야 할 몇 가지 중요한 문제가 있습니다. 예를 들어, 한 가지 지배적인 경제 전략은 개시자가 빈 목록을 제출하는 것입니다. 그렇게 하면 심사를 받아야 하는 건축업자도 최고가를 입찰하는 한 경매에서 낙찰받을 수 있습니다. 이 문제를 해결하는 방법이 있습니다(또는 다른 방법이 있습니다). 저는 여기서 디자인이 견고하지 않다는 점을 강조하고 있습니다.

2D KZG 전략

우리는 KZG 약속을 통해 어떻게 데이터에 커밋하고 데이터가 올바르게 확장되었음을 증명할 수 있는지 확인했습니다. 그러나 이것은 이더리움이 실제로 하는 일을 단순화한 것입니다. 하나의 KZG 커밋으로 모든 데이터를 커밋하지는 않습니다. 블록은 많은 KZG 커밋을 사용합니다.

우리는 이미 전담 빌더가 있는데 그들이 거대한 KZG 커밋을 만들도록 놔두지 않는 이유는 무엇입니까? 문제는 리팩토링을 위해 강력한 슈퍼노드가 필요하다는 것입니다. 초기 빌드에 대한 슈퍼노드 요구 사항을 수락할 수 있지만 재구축에 대한 가정을 피해야 합니다. 재구축을 처리하려면 공통 엔터티가 필요하므로 KZG 약정을 여러 공유로 분할하는 것이 좋습니다. 주어진 데이터의 양을 감안할 때 재구성은 상당히 일반적이거나 이 디자인의 기본 가정일 수도 있습니다.

재구성을 더 쉽게 하기 위해 각 블록은 m개의 KZG 약속으로 인코딩된 m개의 샤드 데이터로 구성됩니다. 현명하지 못한 경우 이렇게 하면 많은 샘플링이 발생합니다. 사용 가능한지 확인하기 위해 각 샤드 청크에서 DAS를 수행하게 됩니다(m*k 샘플이 필요하며 여기서 k는 청크당 샘플 수임).

따라서 Ethereum은 2D KZG 전략을 사용합니다. 우리는 다시 Reed-Solomon 코드를 사용하여 m 약속을 2m 약속으로 확장합니다.

0-255와 동일한 다항식에 있는 추가 KZG 확약(여기서는 256-511)을 확장하여 2D 정책으로 만듭니다. 이제 모든 샤드 데이터의 가용성을 보장하기 위해 위의 테이블에서 DAS를 수행하기만 하면 됩니다.

2D 샘플링은 데이터의 75%를 사용할 수 있어야 합니다(앞서 언급한 50%와 반대). 즉, 더 고정된 수의 샘플을 그려야 합니다. 1D 전략의 이전 단순 버전은 30개의 샘플이 필요하며 여기서는 사용 가능한 블록을 재구성할 확률이 일관되도록 보장하기 위해 75개의 샘플이 필요합니다.

샤딩 1.0(1D KZG 약정 전략에 해당)에는 30개의 샘플만 필요하지만 64개의 샤드를 샘플링해야 하고 전체 확인에는 1920개의 샘플이 필요합니다. 각 샘플은 512B이므로 다음과 같습니다.

(512 B x 64 슬라이스 x 30 샘플) / 16초 = 60KB/s 대역폭

실제로 검증자는 모든 샤드를 개별적으로 확인하지 않고 무작위로 선택됩니다.

2D KZG 전략으로 블록을 병합하면 전체 DA 검증이 매우 쉬워집니다. 병합된 단일 블록에서 75개 샘플만 선택하면 됩니다.

(512 B x 1 블록 x 75 샘플) / 16초 = 2.5KB/s 대역폭

Danksharding

PBS was initially designed to blunt the centralizing forces of MEV on the validator set. However, Dankrad recently took advantage of that design realizing that it unlocked a far better sharding construct – DS.

DS leverages the specialized builder to create a tighter integration of the Beacon Chain execution block and shards. We now have one builder creating the entire block together, one proposer, and one committee voting on it at a time. DS would be infeasible without PBS – regular validators couldn’t handle the massive bandwidth of a block full of rollups’ data blobs:

PBS는 원래 유효성 검사기 그룹에서 MEV의 중앙 집중화 기능을 헤지하도록 설계되었습니다. 그러나 Dankrad는 최근 이 설계를 활용하여 더 나은 샤딩 체계인 DS(Danksharding)를 고안했습니다.

DS는 전용 빌더를 활용하여 비콘 체인 실행 블록과 샤드 간의 긴밀한 통합을 달성합니다. 이제 전체 블록을 생성하는 빌더, 제안자 및 투표하는 위원회가 있습니다. DS는 PBS 없이는 실현 불가능합니다. 일반 빌더는 수많은 롤업 블록을 포함하는 블록을 만족시키기 위한 거대한 대역폭을 가질 수 없습니다.

샤딩 1.0에는 64개의 독립적인 위원회와 개시자가 포함되어 있어 각 샤드가 독립적으로 문제를 제기할 수 있습니다. 이 긴밀한 통합을 통해 완전한 데이터 사용 가능(DA)을 한 번에 보장할 수 있습니다. 데이터는 여전히 블랙박스에서 "샤딩"되지만 실제적인 관점에서 보면 샤드가 데이터 덩어리처럼 느껴지기 시작합니다.

Danksharding - 정직한 다수 검증

검증자가 데이터를 신뢰할 수 있음을 증명하는 방법을 살펴보겠습니다.

이를 위해서는 대부분의 정직한 검증자에 의존해야 합니다. 단일 검증자로서 내 열과 행을 사용할 수 있지만 전체 블록을 사용할 수 있다는 통계적 확신을 주기에는 충분하지 않습니다. 그 결론을 내리려면 정직한 다수가 필요합니다. 분산 검증이 중요합니다.

이것은 앞에서 논의한 75개의 임의 샘플과 다릅니다. 프라이빗 랜덤 샘플링은 프로비저닝이 낮은 개인이 가용성을 쉽게 확인할 수 있음을 의미합니다(예: DAS 라이트 노드를 실행할 수 있고 블록이 사용 가능한지 알 수 있음). 그러나 유효성 검사기는 가용성을 확인하고 블록 재구성을 안내하기 위해 행 및 열 접근 방식을 계속 사용할 것입니다.

Danksharding - 재구축

단일 행 또는 열의 50%를 사용할 수 있는 한 샘플링된 검증기로 쉽게 완전히 재구성할 수 있습니다. 특정 행/열에서 누락된 블록을 재구성할 때 해당 블록을 직교 라인에 재분배합니다. 이는 다른 유효성 검사기가 필요에 따라 교차하는 행과 열에서 누락된 블록을 재구성하는 데 도움이 됩니다.

여기서 사용 가능한 블록을 재구성하기 위한 안전한 가정은 다음과 같습니다.

블록을 재구성하기에 충분한 데이터를 집합적으로 가질 수 있도록 샘플 요청을 수행하는 노드가 충분합니다.
각각의 블록 샤드를 브로드캐스팅하는 노드 간의 동기화 가정

그렇다면 얼마나 많은 노드가 충분할까요? 대략적인 추정에는 64,000개의 개별 인스턴스가 필요합니다(지금까지 380,000개 이상). 이것은 또한 동일한 검증자에 의해 실행되는 노드의 교차가 없다고 가정하는 매우 보수적인 계산입니다(노드가 32 ETH 인스턴스로 제한되는 경우와는 거리가 멉니다). 2개 이상의 행과 2개 열을 샘플링하면 교차로 인해 일괄적으로 검색될 가능성이 높아집니다. 이는 2차적으로 확장되기 시작합니다. 예를 들어 유효성 검사기가 10개 또는 100개의 유효성 검사기와 함께 실행되는 경우 64,000개의 요구 사항이 몇 배로 떨어질 수 있습니다.

DS는 온라인 유효성 검사기 수가 매우 낮아지기 시작하면 샤드 블록 수를 자동으로 줄이도록 설정할 수 있습니다. 따라서 보안 가정은 안전한 수준으로 축소됩니다.

Danksharding - 개인 무작위 샘플링을 통한 악의적 다수 보안

우리는 DS의 검증이 블록을 증명하기 위해 정직한 다수에 의존한다는 것을 알고 있습니다. 나는 개인으로서 여러 등급을 다운로드하여 블록이 사용 가능하다는 것을 증명할 수 없습니다. 그러나 개인 무작위 샘플링은 누구도 신뢰하지 않고 이러한 보증을 제공할 수 있습니다. 앞에서 설명한 노드가 75개의 무작위 샘플을 검사할 때 이런 일이 발생합니다.

DS는 초기에 개인 무작위 샘플링을 포함하지 않을 것입니다. 이는 네트워킹 측면에서 해결하기 매우 어려운 문제이기 때문입니다(PSA: 아마도 당신이 그들을 도울 수 있을 것입니다!).

공격자가 귀하의 익명성을 해제하면 적은 수의 샘플링된 노드를 스푸핑할 수 있기 때문에 "비공개"가 중요합니다. 그들은 당신이 요청한 정확한 데이터 청크를 반환하고 나머지는 보류할 수 있습니다. 따라서 모든 데이터가 자신의 샘플링에서만 제공된다는 것을 알 수 없습니다.

Danksharding - 주요 요약

DS는 단지 좋은 이름이 아니라 매우 흥미진진합니다. 마침내 통합 결제 및 DA 계층에 대한 이더리움의 비전을 실현합니다. 비콘 블록과 샤드의 긴밀한 결합은 실제 블록을 샤딩하지 않는 효과를 얻을 수 있습니다.

실제로 "샤딩"으로 간주되는 이유를 정의해 보겠습니다. 여기서 유일한 샤딩은 유효성 검사기가 모든 데이터를 다운로드할 책임이 없다는 사실입니다. 아무것도.

따라서 이것이 진정한 샤딩인지 의문이 든다면 제정신이 아닙니다. 이것이 바로 PDS(곧 설명하겠습니다)가 "샤드"로 간주되지 않는 이유입니다(이름에 "샤드"가 포함되어 있음에도 불구하고 혼란스럽습니다). PDS는 각 검증인이 모든 블록을 완전히 다운로드하여 가용성을 증명하도록 요구합니다. 그런 다음 DS는 샘플링을 도입하여 개별 검증자가 특정 부분만 다운로드하도록 했습니다.

Minimal sharding은 sharding 1.0보다 더 단순한 디자인을 의미합니다(따라서 전달이 더 빠르죠?). 간소화된 콘텐츠에는 다음이 포함됩니다.

샤딩 1.0 사양과 비교할 때 DS 사양은 수백 줄의 코드가 적을 수 있습니다(클라이언트 측에서는 수천 줄 적음).
더 이상 인프라로서의 샤드 위원회가 없으며, 위원회는 메인 체인에서만 투표하면 됩니다.
개별 샤드 블롭 확인을 추적할 필요가 없습니다. 이제 모두 메인 체인에서 확인되거나 확인되지 않습니다.

이것의 좋은 결과는 데이터에 대한 통합 수수료 시장입니다. 샤딩 1.0은 이 모든 것을 다른 블록을 만드는 다른 생성자로 조각화합니다.

디샤딩 위원회도 효과적으로 뇌물 수수에 저항했습니다. DS 유효성 검사기는 각 에포크에서 한 번씩 전체 블록에 투표하므로 전체 유효성 검사기 그룹의 1/32(각 에포크에서 32자리)에 의해 데이터가 즉시 확인됩니다. 샤드 1.0 검증자도 에포크당 한 번 투표하지만 각 샤드에는 재구성이 필요한 자체 위원회가 있습니다. 따라서 각 샤드는 1/2048 검증자 그룹(64개 샤드에 1/32 분할)에 의해서만 확인됩니다.

논의한 바와 같이 2D KZG 커밋 체계와 결합된 블록은 DAS를 훨씬 더 효율적으로 만듭니다. 샤딩 1.0은 모든 샤드의 모든 DA를 확인하기 위해 60KB/s의 대역폭이 필요하고 DS는 2.5KB/s만 필요합니다.

ZK 롤업과 L1 이더리움 실행 간의 동기식 호출인 DS에 대한 흥미로운 가능성도 있습니다. 모든 것이 동일한 비콘 체인 블록에서 생성되기 때문에 샤드 블록의 트랜잭션을 즉시 확인하고 L1에 쓸 수 있습니다. 샤딩 1.0은 별도의 샤드 확인으로 인해 이러한 가능성을 제거합니다. 이것은 공유 유동성(예: dAMM)과 같은 것에 매우 가치가 있을 수 있는 흥미로운 디자인 공간을 남깁니다.

Danksharding——블록체인 확장에 대한 제약

모듈식 레이어는 우아하게 확장됩니다 — 탈중앙화를 통해 더 많은 확장이 가능합니다. 이것은 오늘날 우리가 보는 것과 근본적으로 다릅니다. DA 계층에 더 많은 노드를 추가하면 데이터 처리량을 안전하게 늘릴 수 있습니다(예: 롤업을 허용할 공간이 더 많음).

블록체인의 확장성은 여전히 제한적이지만 오늘날에 비해 훨씬 더 향상시킬 수 있습니다. 안전하고 확장 가능한 기본 계층을 통해 구현을 신속하게 확장할 수 있습니다. 데이터 스토리지 및 대역폭의 개선은 시간이 지남에 따라 데이터 처리량도 증가시킬 것입니다.

이 문서에서 예상한 DA 처리량을 초과하는 것은 확실히 가능하지만 이 최대값이 어디까지 떨어질지는 말하기 어렵습니다. 명확한 레드 라인은 없지만 특정 가정을 뒷받침하기 어려워지기 시작하는 간격을 열거할 수 있습니다.

데이터 저장 - 이것은 DA 및 데이터 검색 가능성에 관한 것입니다. 합의 계층의 역할은 데이터를 무한정 검색할 수 있도록 보장하는 것이 아니라 데이터를 다운로드하려는 사람은 누구나 우리의 보안 가정을 충족할 수 있을 만큼 충분히 오랫동안 데이터를 사용할 수 있도록 하는 것입니다. 그런 다음 모든 곳에서 버려집니다. 기록이 N 신뢰 가정 중 1 개이기 때문에 편안합니다. 우리는 실제로 그렇게 많은 데이터, 그렇게 큰 계획에 대해 이야기하고 있지 않습니다. 그러나 처리량이 증가함에 따라 불편한 영역에 들어갈 수 있습니다.
유효성 검사기 - DAS는 블록을 공동으로 재구축하기 위해 충분한 노드가 필요합니다. 그렇지 않으면 공격자가 가만히 앉아 수신한 쿼리에만 응답할 수 있습니다. 제공된 이러한 쿼리가 블록을 재구성하기에 충분하지 않은 경우 공격자는 나머지를 보류할 수 있으며 우리는 죽습니다. 처리량을 안전하게 늘리려면 더 많은 DAS 노드를 추가하거나 데이터 대역폭 요구 사항을 늘려야 합니다. 여기서 논의된 처리량의 경우 이는 문제가 되지 않습니다. 그러나 처리량이 이 디자인보다 몇 배나 증가한다면 불편할 수 있습니다.

빌더는 병목 현상이 아닙니다. 32MB의 데이터에 대한 KZG 증명을 신속하게 생성해야 하므로 최소 2.5GBit/s의 대역폭을 가진 GPU 또는 합리적으로 강력한 CPU가 필요합니다. 어쨌든 전문화된 역할이고 그들에게는 무시해도 될 정도의 비즈니스 비용입니다.

네이티브 댄크샤딩(EIP-4844)

DS는 훌륭하지만 인내심을 가져야 합니다. PDS는 우리를 도와줄 것입니다. PDS는 빡빡한 일정(상하이 하드포크를 목표로 함)에 따라 필요한 순방향 호환성 단계를 구현하여 전환하는 동안 수십 배의 확장성을 제공합니다. 그러나 실제로 데이터 샤딩을 구현하지는 않습니다(즉, 유효성 검사기는 모든 데이터를 개별적으로 다운로드해야 함).

오늘의 롤업은 저장을 위해 L1 호출 데이터를 사용하며, 이는 체인에서 영원히 지속될 수 있습니다. 그러나 롤업에는 짧은 시간 동안만 DA가 필요하므로 다운로드에 관심이 있는 사람에게는 충분한 시간이 있습니다.

EIP-4844는 롤업이 향후 데이터 저장에 사용될 새로운 Blob 운반 트랜잭션 형식을 도입합니다. Blob은 많은 양의 데이터(약 125KB)를 전달하며 비슷한 양의 calldata보다 훨씬 저렴합니다. 데이터 Blob은 1개월 후 노드에서 정리되므로 스토리지 요구 사항이 줄어듭니다. 이것은 우리의 DA 보안 가정을 만족시키기에 충분한 시간을 허용합니다.

확장된 컨텍스트의 경우 현재 Ethereum 블록은 일반적으로 평균 약 90KB입니다(calldata는 이 중 약 10KB입니다). PDS는 Blob이 한 달 후에 가지치기될 때 더 많은 DA 대역폭(목표 ~1MB, 최대 ~2MB)을 확보합니다. 그들은 항상 노드에 부담을 주지 않습니다.

Blob은 각각 32바이트인 4096개의 필드 요소로 구성된 벡터입니다. PDS는 블록당 최대 16개의 Blob을 허용하는 반면 DS는 이를 256개로 늘립니다.

PDS DA 대역폭 = 4096 x 32 x 16 = 블록당 2MiB, 대상은 1MiB

DS DA 대역폭 = 4096 x 32 x 256 = 블록당 32MiB, 목표는 16MiB

각 단계는 크기 확장의 순서입니다. PDS는 여전히 데이터를 완전히 다운로드하기 위해 합의 노드가 필요하므로 보수적입니다. DS는 유효성 검사기 간에 데이터 저장 및 전파 부하를 분산합니다.

다음은 DS로 가는 도중에 EIP-4844가 도입한 몇 가지 장점입니다.

blob을 포함하는 트랜잭션 형식 데이터
Blob에 대한 KZG의 약속
DS에 필요한 모든 실행 계층 로직
DS에 필요한 모든 실행/합의 교차 검증 로직
비콘 블록 유효성 검사와 DAS Blob 간의 계층 분리
DS에서 요구하는 대부분의 비컨 블록 로직
Blob에 대한 자체 조정 독립 가스 가격(인덱스 가격 책정 규칙이 있는 다차원 EIP-1559)

DS는 또한 향후에 다음을 추가할 예정입니다.

PBS
DAS
2D KZG 전략
각 검증인이 블록당 샤드 데이터의 특정 부분(약 1개월)의 가용성을 확인할 수 있도록 하는 관리 증명 또는 유사한 프로토콜 내 요구 사항

이러한 데이터 Blob은 실행자 체인에서 새로운 트랜잭션 유형으로 도입되지만 실행자에게 추가 부담을 주지는 않습니다. EVM은 데이터 블록에 연결된 커밋만 봅니다. EIP-4844에 의해 도입된 구현 계층 변경 사항은 DS와도 호환되며 여기에서 추가 변경이 필요하지 않습니다. PDS에서 DS로 업그레이드하려면 합의 계층만 변경하면 됩니다.

PDS에서 데이터 블록은 합의 클라이언트에 의해 완전히 다운로드됩니다. 이제 데이터 블록이 참조되지만 비콘 블록 본문에 완전히 인코딩되지는 않습니다. 본문에 전체 콘텐츠를 포함하는 대신 blob의 콘텐츠가 "사이드카"로 별도로 전파됩니다. 각 블록에는 Blob 사이드카가 있으며, 이는 PDS에서 완전히 다운로드된 다음 DS 유효성 검사기에 의해 DAS(Data Availability Sampling)에 다운로드됩니다.

앞에서 KZG 다항식 약정을 사용하여 blob에 약정하는 방법에 대해 논의했습니다. 그러나 KZG를 직접 사용하는 대신 EIP-4844는 우리가 실제로 사용하는 버전 해시를 구현합니다. 이것은 KZG의 SHA256 해시의 마지막 31바이트가 뒤따르는 단일 0x01 바이트(버전을 나타냄)입니다.

EVM 호환성 및 향후 호환성을 위해 이렇게 합니다.

EVM 호환성 - KZG 약속은 48바이트인 반면 EVM은 보다 자연스럽게 32바이트 값을 사용합니다.
순방향 호환성 - KZG에서 다른 것으로 전환하면(양자 저항을 위한 STARK와 같은) 약속은 계속 32바이트가 될 수 있습니다.

다차원 EIP-1559

PDS는 궁극적으로 맞춤형 데이터 계층을 생성합니다. 데이터 블록은 독립적인 유동 가스 가격 및 한도를 가진 고유한 수수료 시장을 갖습니다. 따라서 일부 NFT 프로젝트가 L1에서 많은 원숭이 땅을 판매하더라도 롤업 데이터 비용은 상승하지 않습니다(증명 결제 비용은 상승하지만). 이것은 오늘날 모든 롤업 프로젝트의 주요 비용이 증명이 아닌 L1에 데이터를 게시하는 것임을 보여줍니다.

가스 수수료 시장은 변경되지 않았으며 데이터 블록이 새로운 시장으로 추가되었습니다.

Blob 수수료는 가스로 청구되지만 자체 EIP-1559 메커니즘에 따라 조정되는 가변 금액입니다. 블록당 Blob의 장기적 평균 수는 명시된 목표와 같아야 합니다.

여기에는 실제로 두 개의 병렬 경매가 있습니다. 하나는 계산용이고 다른 하나는 DA용입니다. 이것은 효율적인 리소스 가격 책정을 위한 큰 진전입니다.

흥미로운 디자인을 볼 수 있습니다. 예를 들어 현재 가스 및 블롭 가격 메커니즘을 선형 EIP-1559에서 새로운 지수 EIP-1559 메커니즘으로 변경하는 것이 합리적일 수 있습니다. 현재 구현은 목표 블록 크기에 대한 평균을 내지 않습니다. 오늘날의 기본 수수료 안정성은 좋지 않아 블록당 평균적으로 목표보다 약 3% 높은 가스 사용량이 관찰되었습니다.

2부 역사와 상태 관리

기본 개념의 빠른 요약:

역사 - 체인에서 일어난 모든 것. 빠른 액세스가 필요하지 않으므로 하드 드라이브에 직접 넣을 수 있습니다. 이것은 장기적으로 N 정직한 가정 중 하나입니다.
상태 - 모든 현재 계정 잔액, 스마트 계약 등의 스냅샷 풀 노드(현재)는 거래를 검증하기 위해 이 데이터를 가지고 있어야 합니다. RAM에 비해 너무 크고 하드 드라이브는 너무 느립니다. SSD에 잘 맞습니다. 높은 처리량의 블록체인을 통해 이 상태는 일반 사람들이 노트북에서 유지할 수 있는 것보다 훨씬 빠르게 빠르게 성장할 수 있습니다. 일상적인 사용자가 그 상태를 유지할 수 없다면 완전히 확인할 수 없으며 탈중앙화는 불가능합니다.

요컨대, 이러한 것들은 매우 커질 수 있으므로 노드를 실행하기가 어려우며 필요한 경우 노드는 이 데이터를 유지해야 합니다. 노드를 실행하는 것이 너무 어렵다면 우리 일반 사람들은 노드를 실행하지 않습니다. 이것은 짜증나므로 이런 일이 발생하지 않도록 해야 합니다.

Calldata 가스 비용 절감 및 총 calldata 제한(EIP-4488)

PDS는 DS를 향한 좋은 단계이며 많은 최종 요구 사항을 충족합니다. 합리적인 기간 내에 PDS를 구현하면 DS 일정을 앞당길 수 있습니다.

구현하기 쉬운 수정은 EIP-4488입니다. 덜 우아하지만 여전히 현재 수수료의 긴급성을 해결합니다. 아쉽게도 DS에 대한 단계를 알려주지 않아 부득이하게 추후 추가될 예정입니다. PDS가 우리가 원하는 것보다 느리다고 느끼기 시작하면 EIP-4488(단지 몇 줄의 코드 수정)을 빠르게 통과한 다음 6개월 후에 PDS에 진입하는 것이 합리적일 수 있습니다. 우리는 시간을 할애할 자유가 있습니다.

EIP-4488에는 두 가지 주요 구성 요소가 있습니다.

호출 데이터 비용이 바이트당 16가스에서 바이트당 3가스로 감소했습니다.
블록당 1MB의 Calldata 제한과 트랜잭션당 추가 300바이트를 늘립니다(이론적으로 최대 총 약 1.4MB).

최악의 상황을 방지하려면 한도를 늘려야 합니다. 호출 데이터로 가득 찬 블록은 18MB에 도달하며, 이는 이더리움이 처리할 수 있는 것보다 훨씬 많습니다. EIP-4488은 이더리움의 평균 데이터 용량을 증가시키지만 이 콜데이터 제한(3천만 가스/콜데이터 바이트당 16가스 = 1.875MB)으로 인해 버스트 데이터 용량은 실제로 약간 감소합니다.

EIP-4488에 대한 지속적인 부하는 PDS보다 훨씬 높습니다. 이는 여전히 호출 데이터 대 데이터 블록(한 달 후에 정리할 수 있음)이기 때문입니다. EIP-4488을 사용하면 성장률이 의미 있게 증가하지만 노드 실행에 병목 현상도 발생합니다. EIP-4444가 EIP-4488과 동시에 구현되더라도 1년 후에 실행 페이로드 이력이 줄어들 것입니다. PDS의 지속 부하가 낮을수록 분명히 바람직합니다.

실행 클라이언트에서 기록 데이터 검증(EIP-4444)

EIP-4444를 통해 고객은 1년 이상 된 기록 데이터(헤더, 본문 및 영수증 포함)를 로컬에서 정리하도록 선택할 수 있습니다. 클라이언트가 p2p 계층에서 이러한 가지치기된 과거 데이터 제공을 중단하도록 규정합니다. 기록 데이터 정리를 통해 고객은 사용자의 디스크 스토리지 요구 사항을 줄일 수 있습니다(현재 수백 기가바이트 및 계산 중).

이것은 이미 중요하지만 EIP-4488이 구현되면 기본적으로 필수가 될 것입니다 (이력 데이터를 크게 늘리기 때문에). 우리는 이것이 비교적 짧은 시간 안에 이루어질 수 있기를 바랍니다. 결국 어떤 형태의 기록 만료가 필요할 것이므로 지금이 이를 처리하기에 좋은 시기입니다.

체인의 전체 동기화에는 기록이 필요하지만 새 블록의 유효성을 검사하는 데는 필요하지 않습니다(상태만). 따라서 클라이언트가 체인의 맨 위에 동기화되면 JSON-RPC를 통해 명시적으로 요청하거나 피어가 체인을 동기화하려고 시도하는 경우에만 기록 데이터가 검색됩니다. EIP-4444가 구현되면 이에 대한 대체 솔루션을 찾아야 합니다.

클라이언트는 오늘날처럼 devp2p와 "완전한 동기화"를 수행할 수 없습니다. 대신 약하게 주관적인 체크포인트에서 "체크포인트 동기화"를 수행하며, 이를 제네시스 블록으로 볼 수 있습니다.

약한 주관성은 추가 가정이 아니며 PoS로의 이동과 함께 불가피한 것입니다. 원격 공격의 가능성으로 인해 동기화를 위해 효과적으로 약한 주관성 체크포인트를 사용해야 합니다. 여기서 가정은 클라이언트가 유효하지 않거나 오래되고 약한 주관성 체크포인트에서 동기화되지 않는다는 것입니다. 이 체크포인트는 과거 데이터 정리를 시작하는 기간(여기서는 1년 이내) 내에 있어야 합니다. 그렇지 않으면 p2p 레이어에서 필요한 데이터를 제공할 수 없습니다.

또한 점점 더 많은 고객이 가벼운 동기화 전략을 채택함에 따라 네트워크에서 대역폭 사용량도 줄어듭니다.

과거 데이터 복원

EIP-4444는 1년이 지나면 기록 데이터를 정리하고 PDS는 blob을 더 빠르게 정리합니다(약 한 달 후). 이는 노드가 모든 데이터를 저장하고 분산된 상태를 유지하도록 요구할 수 없기 때문에 필요한 조치입니다.

EIP-4488 - 장기적으로 소켓당 약 1MB가 필요하며 연간 약 2.5TB의 스토리지가 추가됩니다.
PDS - 소켓당 ~1MB 목표, 연간 ~2.5TB 스토리지 추가
DS - 소켓당 ~16MB 목표, 연간 ~40TB 스토리지 추가

하지만 데이터는 어디로 갔습니까? 여전히 필요합니까? 예, 하지만 기록 데이터 손실은 프로토콜에 대한 위험이 아니라 개별 애플리케이션에만 해당된다는 점에 유의하십시오. 따라서 이더리움 코어 프로토콜의 작업에는 이러한 모든 합의 데이터를 영구적으로 유지하는 것이 포함되어서는 안 됩니다.

그렇다면 누가 이 데이터를 저장할까요? 다음은 몇 가지 잠재적 기여자입니다.

개인 및 기관 자원봉사자
블록 탐색기(예: etherscan.io), API 공급자 및 기타 데이터 서비스
TheGraph와 같은 제3자 인덱싱 프로토콜은 고객이 Merkle 증명으로 과거 데이터에 대해 서버에 비용을 지불하는 인센티브화된 시장을 만들 수 있습니다.
포털 네트워크(현재 개발 중)의 클라이언트는 체인 히스토리의 임의 부분을 저장할 수 있으며 포털 네트워크는 자동으로 데이터 요청을 데이터를 소유한 노드로 보냅니다.
예를 들어 BitTorrent는 매일 블록에 대한 Blob 데이터가 포함된 7GB 파일을 자동으로 생성하고 배포합니다.
특정 애플리케이션 프로토콜(예: 롤업)은 노드가 애플리케이션과 관련된 기록의 일부를 저장하도록 요구할 수 있습니다.

장기 데이터 저장 문제는 앞서 논의한 바와 같이 N 신뢰 가정 중 하나이기 때문에 비교적 쉬운 문제입니다. 이 문제는 블록체인 확장성에 대한 궁극적인 한계가 되기까지 수년이 걸립니다.

약한 무국적자

좋아, 우리는 기록 관리에 대해 잘 알고 있지만 상태는 어떻습니까? 이것은 실제로 현재 Ethereum의 TPS를 개선하는 데 있어 주요 병목 현상입니다.

전체 노드는 이전 상태 루트를 취하고 블록의 모든 트랜잭션을 실행하고 이후 상태 루트가 블록에서 제공한 것과 일치하는지 확인합니다. 이러한 트랜잭션이 유효한지 확인하려면 현재 보유 상태를 확인해야 합니다.

상태 비저장 - 해당 역할을 수행하기 위해 가까이에 있는 상태가 필요하지 않습니다. 이더리움은 "약한 상태 비저장"을 위해 노력하고 있습니다. 즉, 상태는 블록을 검증하는 데 필요하지 않지만 블록을 구축하는 데 필요합니다. 유효성 검사는 순수한 기능이 됩니다. 완전히 격리된 블록을 제공하면 작동하는지 알려줄 수 있습니다. 기본적으로 다음과 같습니다.

빌더는 PBS로 인해 여전히 상태가 필요하며 이는 허용 가능합니다. 어쨌든 더 중앙 집중화되고 구성이 높은 엔티티가 될 것입니다. 우리의 초점은 검증인의 탈중앙화에 있습니다. 약한 상태 비저장은 빌더에게는 조금 더 많은 작업을 생성하고 검증자에게는 훨씬 적은 작업을 생성합니다. 좋은 거래.

우리는 증인을 사용하여 이 마법 같은 상태 비저장 실행을 달성합니다. 증인은 올바른 상태 액세스의 증거이며 빌더는 모든 블록에 이러한 증거를 포함하기 시작합니다. 실제로 블록을 검증하기 위해 전체 상태가 필요한 것은 아닙니다. 해당 블록의 트랜잭션에서 읽거나 영향을 받은 상태만 있으면 됩니다. 빌더는 주어진 블록의 트랜잭션에 의해 영향을 받는 상태 조각을 포함하기 시작하고 증인을 사용하여 해당 상태에 올바르게 액세스했음을 증명합니다.

예를 들어 보겠습니다. 앨리스는 밥에게 1ETH를 보내고 싶어합니다. 이 거래에 대한 블록의 유효성을 검사하려면 다음을 알아야 합니다.

거래 전 - Alice는 1 ETH를 가지고 있습니다.
Alice의 공개 키 - 서명이 올바른지 알 수 있습니다.
Alice의 nonce - 트랜잭션이 올바른 순서로 전송되었음을 알 수 있습니다.
트랜잭션을 실행한 후 Bob은 1 ETH를 얻었고 Alice는 1 ETH를 잃었습니다.

약한 상태 비저장 세계에서 빌더는 앞서 언급한 증인 데이터를 블록에 추가하고 그 정확성을 증명합니다. 유효성 검사기는 블록을 수신하고 실행하고 유효한지 여부를 결정합니다. 괜찮아.

유효성 검사기 관점에서 몇 가지 의미는 다음과 같습니다.

상태를 유지하는 데 필요한 막대한 SSD 요구 사항은 사라졌습니다. 오늘날 확장에 중요한 병목 현상입니다.
이제 증인 데이터와 증거도 다운로드하므로 대역폭 요구 사항이 약간 증가합니다. 이것은 Merkle-Patricia 트리의 병목 현상이지만 Verkle Tries가 직면한 병목 현상과 같은 큰 문제는 아닙니다.
완전히 검증하기 위해 여전히 트랜잭션을 실행합니다. 무국적은 이것이 현재 이더리움 확장의 병목 현상이 아니라는 사실을 인정합니다.

약한 상태 비저장은 또한 이더리움이 실행 처리량에 대한 자체 부과 제약을 완화할 수 있도록 하며 상태 팽창은 더 이상 시급한 문제가 아닙니다. 가스 한도를 3배로 늘리는 것이 합리적일 수 있습니다.

이 시점에서 대부분의 사용자의 실행은 L2에서 이루어지지만 L1 처리량이 높을수록 이점이 있습니다. 롤업은 DA(샤드에 게시) 및 정산(L1 실행 필요)을 위해 이더리움에 의존합니다. 이더리움이 DA 계층을 확장함에 따라 증명 발급 비용이 롤업 비용(특히 ZK-롤업의 경우)에서 더 큰 부분을 차지할 수 있습니다.

Verkle 시도 (Verkle 시도)

우리는 이러한 증인이 작동하는 방식을 의도적으로 건너뛰었습니다. Ethereum은 현재 Merkle-Patricia 트리를 사용하여 상태를 저장하지만 필요한 Merkle 증명이 너무 커서 이러한 증인을 실현할 수 없습니다.

이더리움은 Verkle이 상태를 저장하려고 시도할 것입니다. Verkle 증명은 훨씬 더 효율적이므로 약한 무국적을 달성하기 위한 실행 가능한 증인으로 사용할 수 있습니다.

먼저 머클 트리가 어떻게 생겼는지 검토해 봅시다. 모든 트랜잭션은 해시로 시작합니다. 맨 아래에 있는 이러한 해시를 "리프"라고 합니다. 모든 해시 값은 아래 두 자식 노드의 해시 값인 "노드"라고 합니다. 결과 해시는 "Merkle 루트"입니다.

이 데이터 구조는 전체 트리를 다운로드하지 않고도 트랜잭션의 무결성을 증명하는 데 매우 유용합니다. 예를 들어 트랜잭션 H4가 포함되었는지 확인하려면 Merkle 증명에서 H12, H3 및 H5678이 필요합니다. 블록 헤더에서 H12345678이 있습니다. 따라서 경량 클라이언트는 전체 노드에 이러한 해시를 요청하고 트리의 경로에 따라 함께 해시할 수 있습니다. 결과가 H12345678이면 H4가 트리에 있음을 성공적으로 증명한 것입니다.

그러나 나무가 깊을수록 바닥까지의 경로가 길어지므로 정당화하려면 더 많은 항목이 필요합니다. 따라서 얕은 트리와 넓은 트리가 효율적인 증명에 더 적합합니다.

문제는 각 노드 아래에 더 많은 자식을 추가하여 Merkle 트리를 더 넓게 만들려고 하면 매우 비효율적이라는 것입니다. 전체 트리를 터치하려면 모든 피어 노드의 해시 값을 함께 해시해야 하므로 Merkle 증명을 위해 더 많은 피어 노드의 해시 값을 수락해야 합니다. 이것은 증거의 크기를 엄청나게 만들 것입니다.

이것이 효율적인 벡터 약속이 하는 일입니다. Merkle 트리에서 사용되는 해시는 실제로 벡터 커밋입니다. 두 요소에만 효과적으로 커밋할 수 있는 나쁜 커밋일 뿐입니다. 따라서 우리는 그것을 확인하기 위해 모든 피어를 받을 필요가 없는 벡터 커밋을 원합니다. 이것이 있으면 트리를 더 넓게 만들고 깊이를 줄일 수 있습니다. 이것이 우리가 효율적인 증명 크기를 달성하여 제공해야 하는 정보의 양을 줄이는 방법입니다.

Verkle 트리는 Merkle 트리와 유사하지만 간단한 해시 대신 효율적인 벡터 커밋(따라서 "Verkle"이라는 이름)을 사용하여 자식을 커밋합니다. 기본 아이디어는 각 노드가 많은 자식을 가질 수 있지만 증명을 확인하기 위해 모든 자식이 필요하지는 않다는 것입니다. 폭에 관계없이 크기가 일정하다는 증거입니다.

사실, 우리는 이전에 이러한 가능성에 대한 좋은 예를 다루었습니다. KZG 약정은 벡터 약정으로도 사용될 수 있습니다. 사실 이것은 이더리움 개발자들이 원래 여기서 사용하려고 계획한 것입니다. 그들은 나중에 유사한 역할을 수행하기 위해 Pedersen의 노력을 기울였습니다. 그것은 256개의 값을 약속하는 타원 곡선(여기서는 Bandersnatch 참조)을 기반으로 할 것입니다(2개보다 훨씬 낫습니다!).

그렇다면 가능한 한 넓게 깊이 1의 트리를 구축하지 않는 이유는 무엇입니까? 그는 이제 초소형 증명을 가지고 있기 때문에 이것은 검증자에게 좋습니다. 그러나 검증자가 이 증명을 계산할 수 있어야 하며 더 넓을수록 더 어렵다는 실질적인 절충안이 있습니다. 따라서 Verkle 시도는 1~256 값 너비의 두 극단 사이에 놓입니다.

만료된 상태

약한 상태 비저장은 유효성 검사기에서 상태 인플레이션 제약을 제거하지만 상태는 마술처럼 사라지지 않습니다. 거래 비용은 상한선이 있지만 상태를 증가시켜 네트워크에 영구적인 세금을 부과합니다. 주의 성장은 네트워크에 영구적인 장애물로 남아 있습니다. 우리는 이 근본적인 문제를 해결하기 위해 무언가를 해야 합니다.

이것이 상태 만료가 필요한 이유입니다. 장기간(예: 1년 또는 2년) 비활성 상태이면 블록 빌더가 포함할 수 있는 항목도 제외됩니다. 활성 사용자는 아무 변화도 느끼지 못하며 더 이상 필요하지 않은 무거운 상태를 버릴 수 있습니다.

만료된 상태를 복원해야 하는 경우 증명을 제시하고 재활성화하기만 하면 됩니다. 이는 N 스토리지 가정 중 하나로 돌아갑니다. 누군가가 여전히 전체 기록(블록 탐색기 등)을 가지고 있는 한 그들로부터 필요한 것을 얻을 수 있습니다.

약한 상태 비저장은 기본 계층에서 상태 만료에 대한 즉각적인 필요성을 약화시키지만 장기적으로는 특히 L1 처리량이 증가함에 따라 좋습니다. 처리량이 많은 롤업의 경우 이 도구가 더 유용합니다. L2 상태는 더 높은 속도로 성장하여 높은 구성 빌더도 끌어내릴 것입니다.

3부 모든 것은 MEV의 잘못이다

PBS는 DS(Danksharding)의 안전한 구현을 위한 필수 조건이지만 원래 설계는 MEV의 중앙 집중식 전력에 대응하기 위한 것임을 기억하십시오. 오늘날 이더리움 연구에서 되풀이되는 추세를 보게 될 것입니다. MEV는 이제 암호경제학의 선두이자 중심입니다.

블록체인을 설계할 때 MEV를 고려하는 것이 보안과 탈중앙화를 유지하는 데 중요합니다. 기본 프로토콜 수준 메서드는 다음과 같습니다.

유해한 MEV를 최대한 완화(예: 단일 슬롯 최종성, 단일 비밀 리더 선택)
나머지 민주화(예: MEV-Boost, PBS, MEV 스무딩)

나머지는 쉽게 캡처되어 유효성 검사기 간에 전파되어야 합니다. 그렇지 않으면 정교한 검색자와 경쟁할 수 없기 때문에 유효성 검사기 그룹을 중앙 집중화합니다. 이것은 MEV가 합병 후 검증자 보상의 훨씬 더 높은 비율로 인해 악화됩니다(스테이킹 발행은 채굴자에게 주어진 인플레이션보다 훨씬 낮습니다). 이것은 무시할 수 없습니다.

오늘날의 MEV 공급망

오늘의 이벤트 순서는 다음과 같습니다.

마이닝 풀은 여기서 빌더 역할을 합니다. MEV Seeker는 Flashbots를 통해 거래 번들(해당 입찰과 함께)을 마이닝 풀로 전달합니다. 마이닝 풀 운영자는 완전한 블록을 집계하고 블록 헤더를 각 채굴자에게 전달합니다. 광부는 PoW를 사용하여 블록을 증명하고 포크 선택 규칙에서 가중치를 부여합니다.

Flashbot은 전체 스택의 수직적 통합을 방지하기 위해 존재합니다. 그러면 검열 및 기타 불쾌한 외부인에게 문이 열릴 수 있습니다. 플래시봇이 탄생했을 때,

ETH

DAOrayaki

作者文库