비탈릭: 이더리움의 더 버지 단계의 주요 목표

저자: 이더리움 창립자 비탈릭, 편집: 골든 파이낸스 덩 통

주: 이 글은 이더리움 창립자 비탈릭이 최근 발표한 "이더리움 프로토콜의 미래, 4부: 이더리움 프로토콜의 가능한 미래"에 대한 연재 글의 네 번째 부분으로, 이더리움 프로토콜의 가능한 미래, 4부: 더 버지"를 참조하세요. 3부는 "비탈릭: 이더의 더 스컬지 단계의 주요 목표"를 참조하세요. ", 2부는 "Vitalik: 이더리움 프로토콜이 서지 단계에서 어떻게 진화해야 하는가에서 확인하세요. ", 파트 1은 "이더리움 지분증명에서 개선할 수 있는 다른 것들"을 참조하세요. 다음은 4부 전문입니다.

피드백과 검토를 제공해 주신 Justin Drake, Hsiao-wei Wang, Guillaume Ballet, Ignacio, Josh Rudolf, Lev Soukhanov, Ryan Sean Adams, Uma Roy에게 특별히 감사의 말씀을 전합니다.

블록체인의 가장 강력한 기능 중 하나는 누구나 자신의 컴퓨터에서 노드를 실행하고 체인이 올바른지 확인할 수 있다는 것입니다. 온체인 합의(작업증명, 지분증명 ......)를 실행하는 노드의 95%가 즉시 규칙 변경에 동의하고 새 규칙에 따라 블록 생성을 시작하더라도 완전히 검증된 노드를 실행하는 모든 사람이 체인을 거부할 수 있습니다. 이러한 그룹에 속하지 않은 이해관계자는 자동으로 수렴하여 기존 규칙을 계속 따르고 완전히 검증된 사용자가 따르는 체인을 계속 구축할 것입니다.

이것이 블록체인과 중앙화된 시스템의 핵심적인 차이점입니다. 그러나 이 기능을 유지하려면 완전히 검증된 노드를 운영하는 것이 많은 사람들에게 실질적으로 실현 가능해야 합니다. 이는 위임자(위임자가 체인을 검증하지 않으면 실제로 프로토콜의 규칙을 시행하는 데 기여하지 않기 때문에)와 일반 사용자 모두에게 적용됩니다. 오늘날 일반 노트북(이 글을 작성하는 데 사용된 노트북 포함)에서 노드를 실행하는 것은 가능하지만, 그렇게 하는 것은 어렵습니다. 더 버지는 모든 모바일 지갑, 브라우저 지갑, 심지어 스마트워치에서 기본적으로 체인을 완전히 검증하는 계산 비용을 매우 저렴하게 만들어 이를 바꾸는 것을 목표로 하고 있습니다.

The Verge, 로드맵 2023.

원래 "더 버지"는 이더리움 상태 저장소를 보다 간결한 증명을 가능하게 하는 트리 구조인 버클 트리로 옮기자는 아이디어를 언급했습니다. 이를 통해 이더 블록의 상태 저장소 없는 검증이 가능해졌습니다. 노드는 하드 드라이브에 이더 상태(계정 잔액, 컨트랙트 코드, 스토리지 ......)가 없어도 이더 블록을 검증할 수 있지만, 수백 킬로바이트의 증명 데이터와 수백 밀리초의 추가 시간을 들여야만 검증을 수행할 수 있습니다. 오늘날, 버지는 이더체인의 자원 효율적 검증을 극대화하는 데 초점을 맞춘 더 큰 비전을 제시하며, 여기에는 상태 비저장 검증 기술뿐만 아니라 모든 이더 실행을 검증하기 위한 SNARK의 사용도 포함됩니다.

전체 체인에 대한 SNARK 검증에 대한 오랜 관심 외에도 또 다른 새로운 질문은 버클 트리가 최고의 기술인지에 관한 것입니다. 버클 트리는 양자 컴퓨터의 공격에 취약하기 때문에 현재 KECCAK 머클 패트리샤 트리를 버클 트리로 대체한다면 나중에 다시 교체해야 할 것입니다. 머클 트리의 자연스러운 대안은 바로 바이너리 트리에서 스타크 머클 브랜칭을 사용하는 것입니다. 과거에는 오버헤드와 기술적 복잡성으로 인해 실현 불가능한 것으로 여겨졌습니다. 하지만 최근에는 스타크웨어가 서클 스타크가 있는 노트북에서 초당 170만 개의 포세이돈 해시를 증명하는 것을 보았으며, GKR과 같은 기술 덕분에 "전통적인" 해시를 증명하는 데 걸리는 시간이 빠르게 줄어들고 있습니다.

그 결과, Verge는 지난 한 해 동안 훨씬 더 많은 가능성을 열어두게 되었습니다.

The Verge: 주요 목표

• 상태 저장소 없는 클라이언트: 완전히 검증된 클라이언트와 서약 노드는 몇 GB 이상의 스토리지가 필요하지 않습니다.

• (장기적) 스마트워치에서 체인(합의 및 실행)을 완전히 검증합니다. 일부 데이터를 다운로드하고 SNARK를 검증하면 완료됩니다.

이 글에서 다음 내용을 강조하세요:

• 무상태 검증: Verkle 또는 STARK

• EVM 실행의 유효성 증명

• 합의의 유효성 증명

무상태 검증: verkle 또는 STARK

어떤 문제를 해결하고자 하는가?

오늘날 이더 클라이언트는 블록을 검증하기 위해 수백 기가바이트의 상태 데이터를 저장해야 하며, 이 양은 매년 계속 증가하고 있습니다. 원시 상태 데이터가 매년 약 30GB씩 증가함에 따라 개별 클라이언트는 효율적인 업데이트 시도를 위해 추가 데이터를 저장해야 합니다.

이미지 src="https://img.jinse.cn/7311620_watermarknone.png" title="7311620" alt="N13nN5TcdWgIqHRkceJqnNoKUK93zMDUJYOUtNgJ.jpeg">

이것은 완전히 검증된 이더 노드를 실행할 수 있는 사용자 수를 줄입니다. 하드 드라이브는 모든 이더 상태와 심지어 수년간의 기록을 저장하기에 충분히 크지만, 사람들이 기본적으로 구입하는 컴퓨터는 수백 기가바이트의 저장 공간만 가지고 있는 경우가 많습니다. 또한 스테이트의 크기는 노드를 처음 설정할 때 많은 문제를 일으킬 수 있습니다. 노드는 전체 스테이트의 다운로드가 필요하며, 이는 몇 시간 또는 며칠이 걸릴 수 있습니다. 이는 모든 종류의 노크 효과를 가져올 수 있습니다. 예를 들어, 서약자가 자신의 서약 설정을 업그레이드하기가 더 어려워집니다. 새 클라이언트를 시작하고 동기화될 때까지 기다린 다음 이전 클라이언트를 종료하고 키를 전송하는 등 다운타임 없이 이 작업을 수행하는 것이 기술적으로 가능하지만, 실제로는 기술적으로 복잡합니다. 무엇이며 어떻게 작동하나요?

무상태 인증은 노드가 전체 상태를 보유하지 않고도 블록을 검증할 수 있는 기술입니다. 대신, 각 블록은 (i) 블록이 접근할 상태의 특정 위치(예: 코드, 잔액, 스토리지)의 값과 (ii) 이러한 값이 정확하다는 암호학적 증명을 포함하는 증인을 전달합니다.

상태 비저장 인증을 실제로 구현하려면 이더넷 상태 트리 구조를 변경해야 합니다. 현재의 머클 패트리샤 트리는 특히 최악의 시나리오에서 암호화 증명 체계를 구현하는 데 매우 비우호적이기 때문입니다. 이는 "원본" 머클 브랜치와 STARK에서 머클 브랜치를 "래핑"할 수 있는 가능성 모두에 해당됩니다. 주요 어려움은 MPT의 두 가지 약점에서 비롯됩니다.

• 16진수 트리입니다(즉, 각 노드에 16개의 자식이 있습니다). 즉, 평균적으로 N 크기의 트리에서 증명은 32*(16-1)*log16(N) = 120*log2(N) 바이트, 즉 232개 항목 트리에서는 약 3840바이트가 됩니다. 이진 트리의 경우 32*(2-1)*log2(N) = 32*log2(N) 바이트, 즉 약 1024바이트에 불과합니다.

• 코드가 메르켈화되지 않았습니다. 즉, 계정 코드에 대한 액세스 권한을 제공하려면 최대 길이가 24000바이트인 전체 코드를 제공해야 합니다.

최악의 시나리오를 다음과 같이 계산할 수 있습니다.

30,000,000 Gas / 2,400("콜드" 계정 읽기 비용)*. (5 * 480 + 24,000) = 330,000,000바이트

분기가 많으면 분기의 상단이 반복되기 때문에 분기 비용은 약간 낮아집니다(8*480이 아닌 5*480). 하지만 그럼에도 불구하고 단일 슬롯에 다운로드되는 데이터의 양은 완전히 비실용적입니다. STARK로 감싸려고 하면 두 가지 문제에 부딪히게 됩니다. (i) KECCAK은 STARK에 비해 비우호적이고, (ii) 330MB의 데이터는 5백만 번의 KECCAK 라운드 함수를 증명해야 한다는 뜻인데, 이는 STARK가 KECCAK을 더 효율적으로 증명할 수 있다고 해도 가장 강력한 소비자 외에는 증명할 수 없는 것이 많습니다. 가장 강력한 하드웨어를 제외하고는 증명할 수 없는 것들이 많습니다.

육각 트리를 이진 트리로 바꾸고 Merkelize 코드를 추가하면 최악의 경우 대략 30,000,000 / 2,400 * 32 * (32 - 14 + 8) = 10,400,000 바이트 ~214 가지(여기서 8은 증명의 잎으로 길이)가 됩니다. 이렇게 하려면 각 개별 코드 청크에 액세스하는 데 부과되는 가스 비용을 변경해야 하는데, EIP-4762가 이를 수행합니다. 10.4MB가 훨씬 낫겠지만, 많은 노드에서 단일 슬롯에 다운로드하기에는 여전히 너무 많은 데이터입니다. 따라서 좀 더 강력한 기술을 도입해야 합니다. 이를 위해 버클 트리와 스타크 바이너리 해시 트리라는 두 가지 주요 솔루션이 있습니다.

베르클 트리

베르클 트리는 타원 곡선 기반 벡터 커밋을 사용해 증명을 더 짧게 만듭니다. 핵심은 각 부모-자식 관계에 해당하는 증명 조각이 트리의 폭에 관계없이 32바이트에 불과하다는 것입니다. 트리의 폭에 대한 유일한 제한은 트리가 너무 넓으면 증명의 계산 효율이 떨어진다는 것입니다. 이더넷에 권장되는 구현 폭은 256입니다.

따라서 증명에서 단일 브랜치의 크기는 32*log256(N) = 4*log2(N) 바이트가 됩니다. 이론적 최대 증명 크기는 약 30,000,000/2,400*32*(32-14+8)/8 = 1,300,000바이트가 됩니다(상태 블록의 고르지 않은 분포로 인해 실제로는 수학이 약간 다르지만, 첫 번째로 잘 작동합니다).

추가 경고로, 위의 모든 예에서 이 "최악의 경우" 시나리오는 최악의 경우가 아닙니다. 공격자가 트리에서 긴 공통 접두사를 갖도록 의도적으로 두 주소를 "채굴"하고 다음에서 읽는 경우 더 나쁜 경우가 될 수 있다는 점에 유의하세요. 이렇게 하면 최악의 경우 분기 길이가 약 2배 정도 늘어날 수 있습니다. 하지만 이러한 주의에도 불구하고 Verkle 트리는 최악의 경우 약 2.6MB의 증명을 제공하며, 이는 오늘날의 최악의 통화 데이터와 거의 일치합니다.

또한 이 주의 사항을 다른 용도로도 사용합니다. 동일한 컨트랙트의 많은 코드 블록 또는 인접 슬롯인 "인접" 스토리지에 액세스하는 것을 매우 저렴하게 만듭니다. EIP-4762는 인접성에 대한 정의를 제공하며, 인접성 액세스는 200가스로만 청구됩니다. 인접 액세스의 경우, 최악의 경우 증명 크기는 30,000,000/200*32 = 4,800,800 바이트가 되며, 이는 여전히 대략 허용 오차 범위 내에 있습니다. 보안을 위해 이 값을 줄이려면 인접 액세스의 비용을 약간 늘리면 됩니다.

스타크 이진 해시 트리

이 기법은 매우 자명합니다. 이진 트리를 만들고, 증명해야 하는 블록의 값에 대한 최대 10.4MB 증명을 취한 다음, 그 증명을 해당 증명의 스타크로 대체하는 것입니다. 이렇게 하면 증명 자체에는 증명되는 데이터와 실제 STARK의 약 100~300KB 고정 오버헤드만 포함된다는 사실을 알 수 있습니다.

여기서 가장 큰 문제는 증명 시간입니다. 위와 본질적으로 동일한 계산을 수행할 수 있지만, 바이트 수를 세는 대신 해시를 계산한다는 점이 다릅니다. 10.4MB 블록은 330,000개의 해시를 의미합니다. 공격자가 긴 공통 접두사가 있는 주소에 대해 트리를 '채굴'할 가능성을 더하면 실제 최악의 시나리오는 약 66만 개의 해시가 됩니다. 따라서 초당 약 20만 개의 해시를 증명할 수 있다면 괜찮습니다.

이 수치는 STARK 친화적으로 설계된 포세이돈 해시 함수를 사용하는 일반 노트북에서 도달할 수 있는 수치입니다. 그러나 포세이돈은 상대적으로 덜 성숙되어 아직 많은 사람들이 보안을 신뢰하지 않습니다. 따라서 현실적인 방법은 두 가지가 있습니다.

• 포세이돈에 대한 보안 분석을 많이 하고 익숙해져서 L1에 배포

• < p>SHA256 또는 BLAKE와 같은 보다 "보수적인" 해시 함수를 사용하세요

이 글을 쓰는 시점에서 Starkware의 STARK 증명자는 보수적인 해시 함수를 증명하려는 경우 일반 노트북에서 초당 약 10~30만 개의 해시 값만 증명할 수 있습니다. 일반 노트북에서는 초당 30만 개의 해시를 증명할 수 있습니다. 하지만 STARK 기술은 빠르게 발전하고 있습니다. 현재도 GKR 기반 기술을 사용하면 100~200만 개까지 늘릴 수 있는 잠재력을 보여줍니다.

검증 블록 이외의 사용 사례

검증 블록 외에도 보다 효율적인 상태 비저장 유효성 검사를 위한 세 가지 주요 사용 사례가 있습니다.

• < p>메모리 풀: 트랜잭션이 브로드캐스트될 때, P2P 네트워크의 노드는 트랜잭션을 재브로드캐스트하기 전에 트랜잭션이 유효한지 확인해야 합니다. 현재 유효성 검사에는 서명 확인뿐만 아니라 잔액이 충분한지, 난수가 올바른지 확인하는 것도 포함됩니다. 향후(예: EIP-7701과 같은 네이티브 계정 추상화 사용)에는 일부 상태 액세스를 수행하는 일부 EVM 코드를 실행하는 것이 포함될 수 있습니다. 노드가 스테이트리스인 경우 트랜잭션에 상태 객체에 대한 증명을 첨부해야 합니다.

• 포함 목록: 이는 (잠재적으로 규모가 작고 복잡하지 않은) 지분 증명 검증자가 (잠재적으로 규모가 크고 복잡한) 블록 생성자의 의사와 관계없이 다음 블록에 트랜잭션을 포함하도록 강제할 수 있는 제안된 기능입니다. 이는 트랜잭션을 지연시켜 강력한 플레이어가 블록체인을 조작할 수 있는 능력을 감소시킬 수 있습니다. 그러나 이를 위해서는 검증자가 포함 목록에 있는 트랜잭션의 유효성을 검증할 수 있는 방법이 필요합니다.

• 라이트 클라이언트: 사용자가 지갑(예: 메타마스크, 레인보우, 래비...)을 통해 체인에 액세스하도록 하려면 중앙화된 참여자를 신뢰하지 않고 체인에 접근하려면 라이트 클라이언트(예: 헬리오스)를 실행해야 합니다. 헬리오스의 핵심 모듈은 사용자에게 검증된 상태 루트를 제공합니다. 그러나 완전히 탈신뢰화된 경험을 위해서는 사용자가 각 개별 RPC 호출에 대한 증명이 필요합니다(예: eth_call 요청의 경우, 사용자는 호출 중에 액세스한 모든 상태에 대한 증명이 필요합니다).

이 모든 사용 사례의 공통점 중 하나는 상당히 많은 수의 증명이 필요하지만 각 증명이 작다는 점입니다. 따라서 STARK 증명은 이들에게는 적합하지 않으며, 머클 브랜칭을 직접 사용하는 것이 가장 현실적입니다. 머클 분기의 또 다른 장점은 업데이트가 가능하다는 것입니다. 블록 B에 루팅된 상태 객체 X의 증명이 주어졌을 때, 해당 증인이 있는 하위 블록 B2를 받으면 블록 B2에 루팅되도록 증명을 업데이트할 수 있습니다. 버클 증명 자체도 업데이트할 수 있습니다.

기존 연구와의 연관성은 무엇인가요?

버클 트리:

존 쿠즈마을의 버클 트리 논문 원본:https://math.mit.edu/research/highschool/ primes/materials/2018/Kuszmaul.pdf

스타크웨어 증명 데이터: https://x.com/StarkWareLtd/status/1807776563188162562

포세이돈2 논문: https://eprint.iacr.org/2023/323

Ajtai(격자 경도에 기반한 대체 빠른 해시 함수): https://www.wisdom.weizmann.ac.il/~oded/COL/cfh.pdf

Verkle.info:https://verkle.info/

그 밖에 무엇을 해야 하고, 무엇을 고려해야 하나요?

주요 남은 작업은 다음과 같습니다.

• EIP-4762의 결과에 대한 추가 분석(국가별 가스 비용 변경)

• 상태 비저장 EIP의 복잡성 중 큰 부분을 차지하는 전환 프로세스 완료 및 테스트에 대한 추가 작업

• 포세이돈, Ajtai 및 기타 "STARK 친화적" 해시 함수에 대한 추가 보안 분석

• "보수적"(또는 "전통적인") 해시 함수를 위한 매우 효율적인 STARK 프로토콜의 추가 개발(예: 비니우스 또는 GKR 아이디어 기반).

우리는 곧 (i) 버클 트리, (ii) STARK 친화적인 해시 함수, (iii) 보수적인 해시 함수 중 어떤 것을 선택할지 결정하게 될 것입니다. 이들의 속성은 다음 표에 대략적으로 요약되어 있습니다:

이러한 "헤더 번호" 외에도 몇 가지 중요한 고려 사항이 있습니다.

• 오늘날, 버클 트리 코드는 상당히 성숙해졌습니다. 버클이 아닌 다른 것을 사용하면 실제로 배포가 지연되며, 대부분 하드 포크를 통해 이루어집니다. 특히 해시 함수 분석이나 증명자 구현에 추가 시간이 필요하고, 이더에 조만간 포함시키고 싶은 다른 중요한 기능이 있는 경우라면 더더욱 그렇습니다.

• 해시를 사용해 상태의 루트를 업데이트하는 것이 버클 트리를 사용하는 것보다 빠릅니다. 즉, 해시 기반 접근 방식은 노드 전체 동기화 시간을 줄여줍니다.

• V버클 트리에는 흥미로운 특징이 있습니다. 증인 업데이트 속성 - 버클 트리 증인을 업데이트할 수 있습니다. 이 속성은 메모리 풀, 봉쇄 목록 및 기타 사용 사례에 유용하며, 상태 객체를 업데이트하면 마지막 레벨을 읽지 않고도 두 번째 레벨의 증인을 업데이트할 수 있으므로 구현을 보다 효율적으로 만드는 데 도움이 될 수 있습니다.

• 버클 트리는 SNARK를 통해 증명하기가 더 어렵습니다. 증명 크기를 몇 킬로바이트까지 줄이려면 버클 증명이 몇 가지 어려움을 겪게 됩니다. 이는 버클 증명의 검증에 많은 수의 256비트 연산이 도입되기 때문에 증명 시스템에 많은 양의 오버헤드가 있거나 버클 증명에 사용되는 256비트 부분을 포함하는 자체적인 사용자 정의 내부 구조가 필요하기 때문입니다.

버클 증명의 업데이트가 양자적으로 안전하고 상당히 효율적인 방식으로 수행되기를 원한다면 격자 기반 머클 트리가 또 다른 가능한 경로입니다.

최악의 시나리오에서 증명 시스템이 충분히 효율적이지 않다면, 다차원 가스인 (i) 콜데이터, (ii) 연산, (iii) 상태 액세스 및 잠재적으로 다른 리소스에 대한 별도의 가스 제한을 사용하여 이를 보완할 수 있습니다. 제한 사항. 다차원 가스는 복잡성을 더하지만, 그 대신 평균적인 경우와 최악의 경우 사이의 비율을 더 엄격하게 제한합니다. 다차원 가스의 경우 이론적으로 증명해야 하는 최대 분기 수를 30,000,000/2400 = 12,500에서 3000으로 줄일 수 있습니다. 이렇게 하면 더 이상의 증명 개선 없이도 현재도 BLAKE3로 (간신히) 충분할 수 있습니다.

다차원 가스를 사용하면 블록의 리소스 제약이 기본 하드웨어의 제약에 더 가깝게 복제될 수 있습니다.

또 다른 "모자 속의 토끼"는 상태 루트 계산을 블록 뒤의 슬롯까지 지연시키는 제안입니다. 이렇게 하면 상태 루트를 계산하는 데 12초가 주어지며, 가장 극단적인 경우라도 초당 약 60,000개의 해시만 증명하면 충분하며, 이는 다시 BLAKE3가 거의 적절하지 않은 범위에 속한다는 것을 의미합니다.

이 접근법의 단점은 라이트 클라이언트 지연 시간이 일정 기간 증가한다는 점이지만, 이 지연 시간을 증명 생성 지연 시간으로만 줄이는 더 스마트한 버전의 기술도 있습니다. 예를 들어, 어떤 노드가 증명을 생성하자마자 다음 블록을 기다리지 않고 네트워크 전체에 해당 증명을 브로드캐스트할 수 있습니다.

다른 로드맵과 어떻게 상호작용하나요?

무국적 문제를 해결하면 개별 서약의 편의성이 크게 높아집니다. 개별 서약의 최소 잔액을 줄일 수 있는 기술(예: Orbit SSF 또는 애플리케이션 계층 정책(예: 스쿼드 서약))을 사용할 수 있게 되면 그 가치는 더욱 높아집니다.

다차원 가스도 EOF가 도입되면 더 쉬워집니다. 다차원 가스의 실행을 위한 주요 복잡성 중 하나는 부모 호출을 통과하지 못하는 전체 가스의 하위 호출을 처리하는 것이지만, EOF는 이러한 하위 호출을 단순히 불법으로 만드는 것으로 이를 처리하기 때문입니다(그리고 네이티브 계정 추상화는 부분 가스 하위 호출의 현재 주요 사용 사례인 인에 대한 프로토콜 대안을 제공할 수 있습니다).

또 다른 중요한 시너지는 스테이트리스 검증과 기록 만료 사이의 시너지입니다. 오늘날 클라이언트는 거의 테라바이트에 달하는 기록 데이터를 저장해야 하며, 이 데이터는 상태 데이터보다 몇 배 더 큽니다. 클라이언트가 스테이트리스인 경우에도 클라이언트의 히스토리 저장 책임을 덜어주지 않는다면 클라이언트에 저장할 필요가 거의 없다는 꿈은 실현될 수 없습니다. 이 방향의 첫 번째 단계는 토렌트나 포털 네트워크에 기록 데이터를 저장하는 것을 의미하는 EIP-4444입니다.

EVM 구현의 유효성 증명

어떤 문제를 해결하려고 하나요?

이더넷 블록 검증의 장기적인 목표는 명확합니다. (i) 블록을 다운로드하고, 블록의 일부만 다운로드하여 데이터 가용성을 샘플링하고, (ii) 블록이 유효하다는 증거의 일부를 검증하여 이더넷 블록을 검증할 수 있어야 한다는 것입니다. 이는 모바일 클라이언트, 브라우저 지갑, 심지어 (데이터 가용성 부분 없이) 다른 체인에서 수행할 수 있는 매우 리소스 집약적인 작업입니다.

이를 위해서는 (i) 합의 레이어(즉, 지분 증명)와 (ii) 실행 레이어(즉, EVM)에 대한 SNARK 또는 STARK 증명이 있어야 합니다. 전자는 그 자체로 어려운 문제이며 합의 계층의 추가 개선(예: 단일 슬롯 최종 결정론)에서 해결해야 합니다. 후자는 EVM 실행 증명이 필요합니다.

이것은 무엇이며 어떻게 작동하나요?

공식적으로 이더넷 사양에서 EVM은 상태 전환 함수로 정의됩니다. 즉, 사전 상태 S와 블록 B가 있고 사후 상태 S' = STF(S, B)를 계산하고 있는 경우입니다. 사용자가 라이트 클라이언트를 사용하는 경우, S와 S', 심지어 전체 B도 없고 대신 사전 상태 루트 R, 사후 상태 루트 R', 블록 해시 H가 있습니다. 증명해야 하는 전체 문은 대략 다음과 같습니다.

• 공개 입력: 상태 전 루트 R, 상태 후 루트 R', 블록 해시 H.

• 개인 입력: 블록 본문 B, 블록 Q가 접근한 상태의 객체, 블록 Q' 실행 후 상태의 객체, 상태 증명(예: a 머클 분기) P.

• 클레임 1: P는 Q가 R로 표현되는 상태의 일부를 포함한다는 유효한 증명입니다.

• 클레임 2: Q에서 STF를 실행하면 (i) 실행은 Q 내부의 객체에만 접근하고 (ii) 블록은 유효하며 (iii) 결과는 Q' 입니다.

• 명제 3: Q'와 P의 정보를 사용하여 새로운 상태 루트를 다시 계산하면 R'을 얻을 수 있습니다.

이러한 클라이언트가 존재한다면, 이더 EVM 실행을 완전히 검증할 수 있는 라이트 클라이언트를 가질 수 있습니다. 이 경우 클라이언트는 이미 리소스가 상당히 부족합니다. 진정한 완전 검증 이더리움 클라이언트를 얻으려면 컨센서스 측에서도 동일한 작업을 수행해야 합니다.

EVM 계산을 위한 유효성 증명 구현은 이미 존재하며 L2에서 많이 사용되고 있습니다. 그러나 EVM 유효성 증명을 L1에 적용하기 위해서는 아직 해야 할 일이 많습니다. 기존 연구와의 연관성은 무엇인가요?

EC PSE ZK-EVM(더 나은 대안이 존재하므로 현재 사용되지 않음):https://github.com/privacy-scaling-explorations/zkevm- Circuits

Zeth는 EVM을 컴파일하여 작동합니다. https://github.com/risc0/zeth

EVM을 RISC-0 ZK-VM으로 컴파일하여 작동하는 Zeth: https://github.com/risc0/zeth

Zeth, RISC-0 ZK-VM으로 컴파일하여 작동합니다. 왼쪽;">ZK-EVM 공식 검증 프로젝트: https://verified-zkevm.org/

그 밖에 무엇을 해야 하고, 무엇을 검토해야 하나요?

오늘날, EVM의 유효성 증명은 보안과 증명 시간이라는 두 가지 측면에서 불충분합니다.

안전한 유효성 증명을 위해서는 SNARK가 실제로 EVM 계산의 유효성을 검사하고 오류가 없는지 확인해야 합니다. 보안을 개선하기 위한 두 가지 주요 기술은 다중 증명자와 공식 검증입니다. 다중 증명자는 마치 여러 클라이언트가 있는 것처럼 독립적으로 작성된 여러 유효성 증명 구현을 보유하고, 이러한 구현 중 충분히 큰 하위 집합이 해당 블록을 증명하는 경우 클라이언트가 블록을 수락하도록 하는 것을 의미합니다. 형식적 검증은 수학 정리를 증명하는 데 일반적으로 사용되는 도구(예: Lean4)를 사용하여 유효성 증명이 Python으로 작성된 기본 EVM 사양의 올바른 구현만 입력으로 받아들인다는 것을 보여줍니다.

증명 시간이 충분히 빠르다는 것은 모든 이더넷 블록을 4초 이내에 증명할 수 있다는 것을 의미합니다. 2년 전에 생각했던 것보다 훨씬 가까워졌지만 오늘날 우리는 여전히 그 목표에 도달하지 못했습니다. 목표에 도달하기 위해서는 세 가지 측면에서 진전이 필요합니다.

• < strong>병렬화 - 오늘날 가장 빠른 EVM 증명자는 평균 15초 안에 이더 블록을 증명할 수 있습니다. 이는 수백 대의 GPU를 병렬 처리한 다음 최종적으로 작업을 합산하는 방식으로 이루어집니다. 이론적으로, 우리는 O(log(N)) 시간 내에 계산을 증명할 수 있는 EVM 증명자를 만드는 방법을 정확히 알고 있습니다: 하나의 GPU가 각 단계를 수행하도록 한 다음 "집계 트리"를 수행합니다:

이를 구현하기는 어렵습니다. 최악의 경우(즉, 전체 블록을 차지하는 매우 큰 트랜잭션)에서도 작동하려면 계산된 분할이 트랜잭션별로 이루어질 수 없으며, 오퍼랜드별(EVM 또는 기본 VM(예: RISC-V))로 이루어져야 합니다. 이를 완전히 사소하지 않게 만드는 주요 구현 과제는 VM의 "메모리"가 증명의 여러 부분에서 일관성을 유지해야 한다는 것입니다. 그러나 이러한 재귀적 증명을 수행할 수 있다면 다른 축에서는 개선이 없더라도 적어도 증명자 대기 시간 문제는 해결된 것입니다.

• 증명 시스템 최적화 -- Orion , Binius, GKR 및 기타 새로운 증명 시스템은 범용 컴퓨팅의 증명 시간을 또 한 번 크게 단축할 수 있습니다.

• EVM의 가스는 다른 변경 사항을 소비합니다 -- 특히 최악의 경우 EVM의 많은 부분을 최적화하여 증명자에게 더 친화적으로 만들 수 있습니다. 공격자가 증명자의 시간 중 10분이 걸리는 블록을 만들 수 있다면 평균적인 이더 블록을 4초 만에 증명하는 것만으로는 충분하지 않습니다. 필요한 EVM 변경은 크게 두 가지로 나눌 수 있습니다.

• 가스 비용 변경 -

• 가스 비용 변경 -. - 연산 증명에 오랜 시간이 걸리는 경우 계산이 상대적으로 빠르더라도 가스 비용이 높아야 합니다. EIP-7667은 이와 관련하여 가장 심각한 문제를 해결하기 위해 제안된 EIP로, 상대적으로 저렴한 연산 코드와 사전 컴파일로 공개되어 있는 (기존) 해시 함수의 가스 비용을 크게 증가시킵니다. 이러한 가스 비용 증가를 보상하기 위해 상대적으로 저렴한 EVM 연산 코드를 증명하는 데 드는 가스 비용을 줄여 평균 처리량을 동일하게 유지할 수 있습니다.

• 데이터 구조 교체 -- 상태 트리를 STARK에 더 적합한 대안으로 교체하는 것 외에도 트랜잭션 목록, 영수증 트리 및 입증 비용이 많이 드는 기타 구조를 교체해야 합니다. 에단 키슬링의 EIP는 트랜잭션과 영수증 구조를 SSZ([1] [2] [3])로 옮기는데, 이는 그 방향의 한 걸음입니다.

이 외에도 이전 섹션에서 언급한 두 가지 '모자에서 나온 토끼'(다차원 가스 및 지연 상태 루트)도 도움이 될 수 있습니다. 그러나 현재 필요한 작업을 수행할 수 있는 충분한 기술이 있다는 것을 의미하는 상태 비저장 검증과 달리, 이러한 기술을 사용하더라도 완전한 ZK-EVM 검증에는 더 많은 작업이 필요하다는 점에 유의할 필요가 있습니다(단지 작업량이 적을 뿐).

위에서 언급하지 않은 한 가지는 증명 하드웨어로, GPU, FPGA, ASIC을 사용하여 증명을 더 빠르게 생성하는 것입니다. 패브릭 크립토그래피, 사이직, 엑씰이 이를 주도하는 세 회사입니다. 이는 레이어 2에서는 매우 유용하지만, 레이어 1에서는 고도로 탈중앙화된 레이어를 유지하고자 하는 강한 욕구가 있기 때문에, 증명 생성이 상당한 규모의 하위 집합의 역량 내에 있어야 한다는 의미에서 결정적인 고려사항이 되지는 않을 것으로 보입니다. 이더넷 사용자는 단일 회사의 하드웨어에서 병목 현상이 발생해서는 안 됩니다. 레이어 2는 보다 근본적인 트레이드오프를 허용합니다.

다음 영역에서 더 많은 작업이 필요합니다:

• 병렬 증명은 증명의 여러 부분이 "메모리를 공유할 수 있는 증명 시스템을 필요로 합니다. "(예: 조회 테이블)을 공유할 수 있는 증명 시스템이 필요합니다. 이를 위한 기술은 알고 있지만 구현이 필요합니다.

• 최악의 증명 시간을 최소화하기 위한 이상적인 가스 비용 변형을 찾기 위해 더 많은 분석이 필요합니다.

• 증명 시스템에 대한 더 많은 작업이 필요합니다

가능한 트레이드오프는 다음과 같습니다:

• < strong>보안 및 증명 시간: 해시 함수를 사용하는 긍정적인 선택, 더 복잡하거나 긍정적인 보안 가정을 가진 증명 시스템 또는 기타 설계 선택은 증명 시간을 줄일 수 있습니다.

• 탈중앙화와 증명 시간: 커뮤니티는 대상 증명자 하드웨어에 대한 "사양"에 합의해야 합니다. 증명자가 거대한 실체여야 할까요? 하이엔드 소비자 노트북이 4초 안에 이더리움 블록을 증명할 수 있기를 원하나요? 아니면 그 중간 정도?

• 이전 버전과의 호환성이 깨지는 정도: 다른 영역의 결함은 가스 비용을 더 공격적으로 변경하여 보완할 수 있지만, 이는 특정 애플리케이션의 비용을 불균형적으로 증가시키고 개발자가 경제성을 유지하기 위해 코드를 다시 작성하고 다시 배포하도록 강요할 가능성이 더 높습니다. 다시 말하지만, '모자 속의 토끼'는 그 자체로 복잡성과 단점이 있습니다.

다른 로드맵과 어떻게 상호 작용하나요?

레이어 1에서 EVM의 유효성 증명을 구현하는 데 필요한 핵심 기술은 다른 두 영역과 크게 공유됩니다.

• 레벨 2 유효성 증명( "ZK 롤업")

• "STARK 바이너리 해시 증명" 상태 비저장 방식

1계층 유효성 증명을 성공적으로 구현하면 다음을 수행할 수 있습니다. 개인 서약의 궁극적인 간편성: 휴대폰이나 스마트워치를 포함한 가장 약한 컴퓨터로도 서약을 할 수 있습니다. 이는 개별 서약의 다른 한계(예: 최소 32 이더리움 필요)를 해결하는 가치를 더욱 높입니다.

또한, L1에 대한 EVM 유효성 증명은 L1의 가스 한도를 크게 개선할 수 있습니다.

합의 유효성 증명

어떤 문제를 해결하고자 하는가?

SNARK로 이더 블록의 유효성을 완전히 검증하려면 EVM 실행만 증명해야 하는 것은 아닙니다. 예금, 출금, 서명, 검증자 잔액 업데이트 및 이더 지분 증명 부분의 기타 요소를 처리하는 시스템 부분인 합의도 증명해야 합니다.

합의는 EVM보다 훨씬 간단하지만, 레이어 2 EVM 집계가 없기 때문에 대부분의 작업을 직접 수행해야 한다는 문제에 직면해 있습니다. 결과적으로 이더넷 합의 증명 시스템 자체는 그 위에 구축할 수 있는 공유 작업임에도 불구하고, 이더넷 합의 증명을 구현하려면 "처음부터" 작업을 수행해야 합니다.

비콘이란 무엇이며 어떻게 작동하나요?

비콘 체인은 EVM과 같은 상태 전달 함수로 정의됩니다. 상태 전달 함수는 다음 세 가지 요소에 의해 결정됩니다.

• ECADD(BLS 서명 확인용)

• 페어링(BLS 서명 확인용)< /p>

• SHA256 해시(상태 읽기 및 업데이트용)

각 블록에서 각 검증자에 대해 1-16개의 BLS12-381 ECADD를 증명해야 합니다(서명이 여러 집합에 포함될 수 있으므로 하나 이상일 수도 있음). 이는 하위 집합 사전 계산 기술로 보완할 수 있으므로 각 검증자는 BLS12-381 ECADD라고 말할 수 있으며, 현재 시간 슬롯당 약 30,000개의 검증자 서명이 있습니다. 향후에는 단일 슬롯 최종 결정론과 관련하여 (여기 참고 참조) 어느 방향으로든 변경될 수 있습니다. "견고한" 경로를 선택하면 시간 슬롯당 검증자가 백만 명으로 늘어날 수 있습니다. 동시에 Orbit SSF를 사용하면 32,768명으로 유지되거나 8,1명으로 감소할 수도 있습니다.

BLS 집계 작동 방식. 집계 서명을 확인하려면 각 참가자의 ECMUL이 아닌 ECADD만 있으면 되지만, 30,000개의 ECADD는 여전히 증명해야 할 양이 많습니다.

쌍의 경우 현재 슬롯당 최대 128개의 증명이 가능하며, 이는 128개의 쌍을 검증해야 한다는 의미입니다. EIP-7549와 추가 변경 사항을 적용하면 슬롯당 16개로 줄어들 수 있습니다. 쌍의 수는 적지만 비용은 매우 높습니다. 각 쌍을 실행(또는 증명)하는 데 ECADD보다 수천 배 더 오래 걸리기 때문입니다.

BLS12-381 연산 증명의 주요 과제 중 하나는 BLS12-381 필드 크기와 동일한 커브 순서를 가진 편리한 커브가 없어 모든 증명 시스템에 상당한 오버헤드를 추가한다는 것입니다. 반면에 이더넷용으로 제안된 버클 트리는 밴더스내치 커브를 사용하여 구성되므로, BLS12-381 자체가 SNARK 시스템에서 버클 브랜치를 증명하는 데 자연스러운 커브가 됩니다. 상당히 간단한 구현으로 초당 약 100개의 G1 추가를 제공할 수 있으며, 이를 충분히 빠르게 증명하려면 GKR과 같은 영리한 기술이 필요할 것입니다.

SHA256 해시의 경우, 현재 최악의 시나리오는 전체 검증자 짧은 잔액 트리와 많은 수의 검증자 잔액이 업데이트되는 에포크 전환 블록입니다. 검증자 짧은 잔액 트리에는 검증자당 1바이트만 있으므로 약 1MB의 데이터가 다시 해시됩니다. 이는 32,768개의 SHA256 호출에 해당합니다. 천 개의 검증자 잔액이 임계값보다 높거나 낮으면 검증자 기록의 유효 잔액을 업데이트해야 하는데, 이는 천 개의 머클 브랜치에 해당하므로 해시가 10,000개 더 늘어날 수 있습니다. 머클 메커니즘은 유효성 검사기당 90비트(따라서 11MB의 데이터)가 필요하지만, 이는 에포크 동안 언제든지 계산할 수 있습니다. 단일 에포크 최종성의 경우, 세부 사항에 따라 이 숫자는 다시 증가하거나 감소할 수 있습니다. 트랙이 어느 정도 셔플링의 필요성을 회복할 수 있지만, 셔플링은 불필요해집니다.

또 다른 문제는 블록을 검증하기 위해 모든 검증자 상태(공개 키 포함)를 읽어야 한다는 것입니다. 1백만 개의 유효성 검사기와 머클 브랜칭의 경우, 공개 키를 읽는 데만 4,800만 바이트가 소요됩니다. 이를 위해서는 기간당 수백만 개의 해시가 필요합니다. 오늘날 관심 증명 검증을 증명해야 한다면, 효율적인 조회에 최적화된 별도의 데이터 구조를 증명 시스템에 저장하고 이 구조에 대한 업데이트를 제공하는 증분 검증 가능한 계산의 형태가 현실적인 접근 방식이 될 것입니다.

요약하면, 많은 어려움이 있습니다.

이러한 문제를 가장 효과적으로 해결하려면 비콘 체인의 심층적인 재설계가 필요하며, 이는 단일 시간 슬롯 완결성으로의 전환과 함께 이루어질 수 있습니다. 이러한 재설계에는 다음과 같은 특징이 포함될 수 있습니다.

• 해시 함수 변경: 현재, "full " SHA256 해시 함수를 사용하므로 패딩으로 인해 각 호출은 기본 압축 함수에 대한 두 번의 호출에 해당합니다. 최소한 SHA256 압축 함수로 전환하면 2배의 이득을 얻을 수 있습니다. 포세이돈으로 전환하면 약 100배의 이득을 얻을 수 있어 (적어도 해시의 경우) 초당 170만 개의 해시(54MB)와 "백만 개의 인증자 레코드 읽기"까지 모든 문제를 완전히 해결할 수 있습니다. "를 몇 초 안에 증명할 수 있습니다.

• 오빗의 경우 스크램블된 검증자 기록을 직접 저장: 특정 수의 검증자(예: 8,192 또는 32,768)를 주어진 슬롯의 위원회로 선택한 경우, 모든 검증자 공개키를 증명에 읽는 데 필요한 최소 해싱 양이 되도록 서로 옆에 있는 상태에 직접 넣으면 됩니다. 증명으로 읽습니다. 이렇게 하면 모든 잔액 업데이트가 효율적으로 수행될 수 있습니다.

• 서명 집계: 고성능 서명 집계 체계는 실제로 일종의 재귀적 증명을 포함하며, 네트워크의 개별 노드에서 서명 하위 집합의 중간 증명을 수행합니다. 이렇게 하면 자연스럽게 네트워크의 많은 노드에 증명 부하가 분산되어 '최종 증명자'의 작업량이 훨씬 줄어듭니다.

• 기타 서명 체계: 램포트+머클 서명의 경우, 서명을 검증하려면 256+32개의 해시가 필요하며 서명자 32,768명을 곱하면 9,437,184개의 해시가 나옵니다. 서명 체계를 최적화하면 이 수치를 작은 상수 계수만큼 더 개선할 수 있습니다. 포세이돈을 사용하는 경우, 이는 단일 슬롯에서 증명 범위 내에 있습니다. 그러나 실제로는 재귀적 집계 체계를 사용하면 이보다 더 빨라집니다.

기존 연구와의 연관성은 무엇인가요?

간결하게, 이더넷 합의 증명(동기화 위원회만 해당):https://github.com/succinctlabs/eth-proof-of-consensus

클린, SP1 내 헬리오스: https:/. /github.com/succinctlabs/sp1-helios

클린, 사전 컴파일된 BLS12-381: https://blog.succinct.xyz/ succinctshipsprecompiles/

Halo2 기반 BLS 종합 서명 검증: https://ethresear.ch/t/zkpos-with-halo2-pairing-for-verifying-aggregate-bls-signatures/14671

그 밖에 필요한 사항 해야 하는 것은 무엇인가요?

현실적으로 이더리움 합의의 유효성을 증명하기까지는 몇 년이 걸릴 것입니다. 이는 포세이돈과 같은 "급진적인" 해시 함수를 사용할 수 있을 만큼 확신을 갖기 위해 단일 슬롯 완결성, 궤도, 서명 알고리즘 변경, 잠재적인 보안 분석을 달성하는 데 필요한 시간과 거의 동일합니다. 따라서 이러한 다른 문제를 해결하고 STARK 친화성을 염두에 두고 해결하는 것이 가장 합리적입니다.

주요 절충점은 이더넷 합의 계층을 개혁하기 위한 점진적 접근 방식과 보다 공격적인 "한 번에 많은 변경"의 접근 방식 사이에서 작업 순서에 있을 것입니다. EVM의 경우 점진적 접근 방식이 이전 버전과의 호환성 손상을 최소화하기 때문에 합리적입니다. 합의 계층의 경우 이전 버전과의 호환성은 문제가 되지 않으며, 비콘 체인이 어떻게 구성되는지에 대한 세부 사항을 "전체론적으로" 다시 생각하여 SNARK 친화성을 최적화하는 것이 이점이 있습니다.

다른 로드맵과 어떻게 상호작용하나요?

STARK 친화성은 이더리움 지분 증명 합의의 장기적인 재설계, 특히 단일 슬롯 완결성, 궤도, 서명 체계 변경, 서명 통합의 주요 초점이 되어야 합니다.