Vitaliks의 새로운 기사: Ethereum의 가능한 미래, The Verge

5,575 0 8

원제: 이더리움 프로토콜의 가능한 미래, 4부: The Verge

Vitalik Buterin의 원본 기사

원문 번역: Mensh, ChainCatcher

Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy Ryan Sean Adams, Uma Roy에게 피드백과 리뷰에 대한 특별 감사드립니다.

블록체인의 가장 강력한 특징 중 하나는 누구나 자신의 컴퓨터에서 노드를 실행하고 블록체인의 정확성을 검증할 수 있다는 것입니다. 체인 합의(PoW, PoS)를 실행하는 모든 9596개 노드가 즉시 규칙을 변경하고 새로운 규칙에 따라 블록을 생성하기로 동의하더라도 완전히 검증된 노드를 실행하는 모든 사람은 체인을 수락하지 않을 것입니다. 이 음모 집단에 속하지 않은 코인 채굴자는 자동으로 오래된 규칙을 계속 따르고 이 체인을 계속 구축하는 체인으로 수렴할 것이고, 완전히 검증된 사용자는 이 체인을 따를 것입니다.

이는 블록체인과 중앙 집중형 시스템의 주요 차이점입니다. 그러나 이 속성이 유지되려면 충분한 수의 사람들이 완전히 검증하는 노드를 실행할 수 있어야 합니다. 이는 캠페인 참여자(캠페인이 체인을 검증하지 않으면 프로토콜 규칙을 시행하는 데 기여하지 않기 때문)와 일반 사용자 모두에게 적용됩니다. 오늘날 소비자용 노트북(제가 이 글을 쓰는 데 사용하는 노트북 포함)에서 노드를 실행할 수 있지만, 그렇게 하는 것은 어렵습니다. The Verge가 이를 바꿔서 모든 모바일 지갑, 브라우저 지갑, 심지어 스마트워치도 기본적으로 검증할 수 있도록 체인을 완전히 검증하는 데 컴퓨팅 비용이 적게 들도록 만들었습니다.

The Verge 2023 로드맵

처음에 Verge는 Ethereum 상태 저장소를 Verkle 트리로 이전하는 것을 언급했습니다. Verkle 트리는 더 컴팩트한 증명을 허용하는 트리 구조로, Ethereum 블록의 상태 없는 검증을 가능하게 합니다. 노드는 하드 드라이브에 Ethereum 상태(계좌 잔액, 계약 코드, 저장 공간 등)를 저장하지 않고도 Ethereum 블록을 검증할 수 있으며, 수백 KB의 증명 데이터와 증명을 검증하는 데 수백 밀리초의 추가 시간이 소요됩니다. 오늘날 Verge는 상태 없는 검증 기술뿐만 아니라 모든 Ethereum 실행을 검증하기 위해 SNARK를 사용하는 것을 포함하여 Ethereum 체인의 최대 리소스 효율적인 검증을 달성하는 데 초점을 맞춘 더 큰 비전을 나타냅니다.

SNARK가 전체 체인을 검증한다는 오랜 우려 외에도 Verkle 트리가 최고의 기술인지 여부와 관련된 또 다른 새로운 문제가 있습니다. Verkle 트리는 양자 컴퓨터의 공격에 취약하므로 현재 KECCAK Merkle Patricia 트리에 Verkle 트리를 넣으면 나중에 트리를 다시 교체해야 합니다. Merkle 트리의 자체 교체 방법은 Merkle 분기를 사용하는 STARK를 직접 건너뛰고 이진 트리에 넣는 것입니다. 이 방법은 역사적으로 오버헤드와 기술적 복잡성으로 인해 실행 불가능한 것으로 간주되었습니다. 그러나 최근 Starkware가 ckcle STARK를 사용하여 노트북에서 초당 170만 개의 Poseidon 해시를 증명하는 것을 보았고 GKB와 같은 기술의 등장으로 인해 보다 전통적인 해시에 대한 증명 시간도 빠르게 감소하고 있습니다. 따라서 작년에 Verge는 여러 가능성에 더욱 개방적이 되었습니다.

The Verge: 주요 목표

상태 비저장 클라이언트: 완전히 인증된 클라이언트와 서명된 노드는 몇 GB 이상의 저장 공간을 필요로 하지 않습니다.
(장기) 스마트워치에서 체인(합의 및 실행)을 완전히 검증합니다. 일부 데이터를 다운로드하고 SNARK를 검증하고 완료했습니다.

이 장에서는

무국적 클라이언트: Verkle 또는 STARK?
EVM 실행의 유효성 증명
합의 유효성 증명

무국적 검증: Verkle 또는 STARKs

우리는 어떤 문제를 해결하려고 하는가?

오늘날, 이더리움 클라이언트는 블록을 검증하기 위해 수백 기가바이트의 상태 데이터를 저장해야 하며, 이 양은 매년 증가하고 있습니다. 원시 상태 데이터는 매년 약 30GB씩 증가하고, 단일 클라이언트는 트리플을 효율적으로 업데이트하기 위해 그 위에 추가 데이터를 저장해야 합니다.

이렇게 하면 완전히 검증된 Ethereum 노드를 실행할 수 있는 사용자 수가 줄어듭니다. Ethereum의 모든 상태, 심지어 수년간의 기록을 저장할 수 있을 만큼 큰 하드 드라이브는 쉽게 구할 수 있지만, 사람들이 기본적으로 구매하는 컴퓨터에는 수백 기가바이트의 저장 공간만 있는 경향이 있습니다. 상태 크기는 또한 처음으로 노드를 설정하는 과정에 엄청난 마찰을 일으킵니다. 노드는 전체 상태를 다운로드해야 하며, 이는 몇 시간 또는 며칠이 걸릴 수 있습니다. 이는 온갖 파급 효과를 낳습니다. 예를 들어, 노드 제작자가 노드 설정을 업그레이드하는 것을 훨씬 더 어렵게 만듭니다. 기술적으로 다운타임 없이 업그레이드를 수행할 수 있습니다. 즉, 새 클라이언트를 시작하고 동기화될 때까지 기다린 다음 이전 클라이언트를 종료하고 키를 전송합니다. 하지만 실제로는 기술적으로 매우 복잡합니다.

어떻게 작동하나요?

무상태 검증은 노드가 전체 상태를 알지 않고도 블록을 검증할 수 있는 기술입니다. 대신, 각 블록에는 다음을 포함하는 증인이 제공됩니다. (i) 블록이 액세스할 상태의 특정 위치에 있는 값, 코드, 잔액, 저장소 (ii) 암호화폐이러한 값이 정확하다는 것을 그래픽으로 증명합니다.

사실, 무상태 검증을 구현하려면 Ethereum의 상태 트리 구조를 변경해야 합니다. 이는 현재의 Merkle Patricia 트리가 모든 암호화 증명 체계의 구현에 매우 비우호적이기 때문이며, 특히 최악의 경우에 그렇습니다. 이는 원래 Merblk 브랜치와 STARK로 패키징할 가능성 모두에 해당합니다. 주요 어려움은 MPT의 몇 가지 약점에서 비롯됩니다.

1. 이것은 6방향 트리(즉, 각 노드에 16개의 자식이 있음)입니다. 즉, 크기 N의 트리에서 증명은 평균 32*(16-1)*log16(N) = 120*log2(N) 바이트, 즉 2^32개 항목의 트리에서 약 3840바이트를 차지합니다. 이진 트리의 경우 32*(2-1)*log2(N) = 32*log2(N) 바이트, 즉 약 1024바이트만 차지합니다.

2. 코드는 Merkle-ified되지 않았습니다. 즉, 계정 코드에 대한 모든 액세스를 증명하려면 전체 코드가 필요하며, 최대 24,000바이트입니다.

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

30000000 가스 / 2400(콜드 계정 읽기 비용) * (5 * 488 + 24000) = 330000000 바이트

브랜치 비용은 브랜치가 더 많을 때 브랜치의 상단 부분이 반복되기 때문에 약간 감소합니다(8*480 대신 5*480). 하지만 그렇더라도 타임 슬롯에서 다운로드할 데이터 양은 완전히 비현실적입니다. STARK로 캡슐화하려고 하면 두 가지 문제에 부딪히게 됩니다. (i) KECCAK은 비교적 STARK에 친화적이지 않습니다. (ii) 330MB의 데이터는 KECCAK 라운드 함수에 대한 500만 개의 호출을 증명해야 한다는 것을 의미하는데, STARK가 KECCAK이 더 효율적임을 증명할 수 있다 하더라도 가장 강력한 소비자 하드웨어를 제외하고는 증명하기 어려울 것입니다.

16진수 트리를 이진 트리로 직접 대체하고 코드의 추가 Merkle-ification을 수행하면 최악의 경우는 대략 30000000/2400* 32*(32-14+ 8) = 10400000바이트가 됩니다(14는 2^14 분기의 중복 비트를 뺀 값이고 8은 코드 블록에서 리프에 진입하는 증명의 길이입니다). 이렇게 하려면 각 개별 코드 블록에 액세스하는 데 청구하는 가스 비용을 변경해야 합니다. 영어: EIP-4762 (한국어: EIP-4762) 이렇게 합니다. 10.4MB가 훨씬 더 좋지만, 여전히 많은 노드가 단일 시간 슬롯에 다운로드하기에는 너무 많은 데이터입니다. 따라서 더 강력한 기술을 도입해야 합니다. 이와 관련하여 두 가지 주요 솔루션이 있습니다. Verkle 트리와 STARKed 바이너리 해시 트리입니다.

Verkle 트리

Verkle 트리는 타원 곡선을 기반으로 하는 벡터 커미트먼트를 사용하여 더 짧은 증명을 만듭니다. 이를 잠금 해제하는 열쇠는 각 부모-자식 관계에 해당하는 증명의 일부가 트리의 너비와 관계없이 32바이트에 불과하다는 것입니다. 증명 트리의 너비에 대한 유일한 제한은 증명 트리가 너무 넓으면 증명이 계산적으로 비효율적이 된다는 것입니다. Ethereum에 제안된 구현은 너비가 256입니다.

따라서 증명에서 단일 브랜치의 크기는 32 - 1 og 256(N) = 4* log 2(N) 바이트가 됩니다. 따라서 이론적인 최대 증명 크기는 대략 30000000 / 2400 * 32 * ( 32 - 14 + 8) / 8 = 130000 바이트입니다(실제 계산 결과는 상태 블록의 불균일한 분포로 인해 약간 다르지만 첫 번째 근사치로는 괜찮습니다).

또한 위의 모든 예에서 이 최악의 경우가 최악의 경우가 아니라는 점에 유의하세요. 최악의 경우는 공격자가 의도적으로 두 주소를 채굴하여 트리에서 긴 공통 접두사를 갖게 하고 그 중 하나에서 데이터를 읽어 최악의 경우 분기 길이를 2배 더 늘릴 수 있는 경우입니다. 하지만 이 경우에도 Verkle 트리의 최악의 경우 증명 길이는 2.6MB로, 현재 최악의 경우 검증 데이터와 거의 일치합니다.

이 경고를 활용해 우리는 또 다른 작업을 수행합니다. 인접한 저장소에 접근하는 비용을 매우 저렴하게 만듭니다. 즉, 동일한 계약의 여러 블록이든 인접한 저장소 슬롯이든 상관없습니다. 영어: EIP-4762 (한국어: EIP-4762) 제공합니다 디파이인접성 결정, 인접성 접근에 대해 200가스만 청구합니다. 인접 접근의 경우 최악의 증명 크기는 30000000 / 200*32 – 4800800바이트가 되며, 이는 여전히 대략 허용 범위 내에 있습니다. 안전을 위해 이 값을 줄이려면 인접 접근에 대한 요금을 약간 높일 수 있습니다.

STARKed 바이너리 해시 트리

이 기술은 매우 자명합니다. 이진 트리를 만들고, 최대 10.4MB의 증명을 얻고, 블록의 값을 증명한 다음, 증명을 증명의 STARK로 대체하기만 하면 됩니다. 이런 식으로 증명 자체에는 증명되는 데이터만 포함되고, 실제 STARK에서 100-300kB의 고정 오버헤드가 추가됩니다.

여기서 가장 큰 과제는 검증 시간입니다. 우리는 본질적으로 위와 같은 계산을 할 수 있지만, 바이트를 세는 대신 해시를 세는 것입니다. 10.4MB 블록은 330,000개의 해시를 의미합니다. 공격자가 긴 공통 접두사가 있는 주소 트리를 채굴할 가능성을 추가하면 최악의 해시는 약 660,000개의 해시가 됩니다. 따라서 초당 200,000개의 해시를 증명할 수 있다면 괜찮을 것입니다.

이러한 숫자는 다음을 사용하여 소비자용 노트북에서 달성되었습니다. 포세이돈 해시 함수 , STARK 친화적으로 특별히 설계되었습니다. 그러나 포세이돈 시스템은 아직 비교적 미숙하기 때문에 많은 사람들이 아직 보안을 신뢰하지 않습니다. 따라서 두 가지 현실적인 경로가 있습니다.

Poseidon에 대한 광범위한 보안 분석을 신속하게 수행하고 L1에 배포할 수 있을 만큼 익숙해지십시오.
SHA 256 또는 BLAKE와 같은 보다 보수적인 해시 함수를 사용하세요.

보수적인 해시 함수를 증명하는 경우, Starkware의 STARK 서클은 글을 쓰는 시점에서 소비자용 노트북에서 초당 10-30k 해시만 증명할 수 있습니다. 그러나 STARK 기술은 빠르게 개선되고 있습니다. 오늘날에도 GKR 기반 기술은 이 속도를 100-200k 범위로 높일 수 있는 능력을 보여주었습니다.

블록 검증을 넘어서는 증인 사용 사례

블록 검증 외에도 더 효율적인 무상태 검증이 필요한 세 가지 주요 사용 사례가 있습니다.

Mempool: 트랜잭션이 브로드캐스트될 때 P2P 네트워크의 노드는 트랜잭션을 다시 브로드캐스트하기 전에 트랜잭션이 유효한지 확인해야 합니다. 오늘날 검증에는 서명을 검증하는 것뿐만 아니라 잔액이 충분하고 접두사가 올바른지 확인하는 것도 포함됩니다. 미래에는(예: EIP-7701과 같은 기본 계정 추상화 사용) 일부 상태 액세스를 수행하는 일부 EVM 코드를 실행하는 것이 포함될 수 있습니다. 노드가 무상태인 경우 트랜잭션에는 상태 객체를 증명하는 증명이 수반되어야 합니다.
포함 목록: 이것은 (잠재적으로 작고 정교하지 않은) 지분 증명 검증자가 (잠재적으로 크고 복잡한) 블록 빌더의 희망과 관계없이 다음 블록에 거래를 포함하도록 강제할 수 있도록 하는 제안된 기능입니다. 이것은 강력한 당사자가 거래를 지연시켜 블록체인을 조작하는 능력을 감소시킬 것입니다. 그러나 이를 위해서는 검증자가 포함 목록에 있는 거래의 유효성을 검증할 방법이 필요합니다.
Light Client: 사용자가 지갑(예: Metamask, Rainbow, Rabby 등)을 통해 체인에 액세스하도록 하려면 Light Client(예: Helios)를 실행해야 합니다. Helios 코어 모듈은 사용자에게 검증된 상태 루트를 제공합니다. 완전히 신뢰할 수 없는 경험을 하려면 사용자는 수행하는 각 RPC 호출에 대한 증명을 제공해야 합니다(예: Ethereum 호출 요청의 경우(사용자는 호출 프로세스 중에 액세스한 모든 상태를 증명해야 함).

이러한 모든 사용 사례의 공통점은 꽤 많은 증명이 필요하지만 각각은 매우 작다는 것입니다. 따라서 STARK 증명은 실용적이지 않습니다. 대신 가장 현실적인 접근 방식은 Merkle 분기를 직접 사용하는 것입니다. Merkle 분기의 또 다른 장점은 업데이트 가능하다는 것입니다. 블록 B에 루트된 상태 객체 X에 대한 증명이 주어지면 자식 블록 B 2와 해당 증인이 수신되면 증명을 블록 B 2에 루트되도록 업데이트할 수 있습니다. Verkle 증명도 기본적으로 업데이트 가능합니다.

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

또 무엇을 할 수 있을까?

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

1. EIP-4762(무국적 가스 비용 변경)의 결과에 대한 추가 분석

2. 무상태 환경에 대한 구현 계획의 복잡성의 주요 부분인 전환 절차를 완료하고 테스트하기 위한 추가 작업

3. Poseidon, Ajtai 및 기타 "STARK 친화적" 해시 함수에 대한 보안 분석 강화

4. Binius 또는 GKR의 아이디어를 기반으로 한 보수적(또는 전통적인) 해싱을 위한 초고효율 STARK 프로토콜 기능의 추가 개발.

더욱이, 우리는 곧 세 가지 옵션 중 하나를 선택하기로 결정할 것입니다: (i) Verkle 트리, (ii) STARK 친화적 해시 함수, (iii) 보수적 해시 함수. 이들의 특징은 다음 표에 대략 요약될 수 있습니다:

이러한 주요 수치 외에도 고려해야 할 중요한 사항이 있습니다.

Verkle 트리 코드는 요즘 상당히 성숙해졌습니다. Verkle 외의 것을 사용하면 배포가 지연되고 하드 포크가 발생할 가능성이 큽니다. 특히 해시 함수 분석이나 검증기 구현에 추가 시간이 필요하거나 다른 중요한 기능을 더 빨리 포함하려는 경우에는 괜찮습니다.
해시를 사용하여 상태 루트를 업데이트하는 것은 Verkle 트리를 사용하는 것보다 빠릅니다. 즉, 해시 기반 접근 방식은 전체 노드의 동기화 시간을 줄일 수 있습니다.
Verkle 트리는 흥미로운 위트니스 업데이트 속성을 가지고 있습니다. Verkle 트리 위트니스는 업데이트 가능합니다. 이 속성은 mempool, 포함 목록 및 기타 사용 사례에 유용하며 구현을 보다 효율적으로 만드는 데 도움이 될 수도 있습니다. 상태 객체가 업데이트되면 마지막에서 두 번째 계층의 위트니스는 마지막 계층의 내용을 읽지 않고도 업데이트할 수 있습니다.
Verkle 트리는 SNARK하기가 더 어렵습니다. 증명 크기를 몇 킬로바이트로 줄이려면 Verkle 증명이 몇 가지 어려움을 초래합니다. 이는 Verkle 증명의 검증이 많은 256비트 연산을 도입하기 때문에 증명 시스템에 많은 오버헤드가 필요하거나 256비트 Verkle 증명 부분을 포함하는 사용자 지정 내부 구조가 필요하기 때문입니다. 이는 무상태 자체에는 문제가 되지 않지만 더 많은 어려움을 초래합니다.

양자 안전하고 상당히 효율적인 방식으로 Verkle 증인 업데이트 가능성을 확보하려면 격자 기반 머클 트리가 가능한 또 다른 접근 방식입니다.

증명 시스템이 최악의 경우에 충분히 효율적이지 않다면, 우리는 다차원 가스라는 예상치 못한 도구를 사용하여 이 결함을 메울 수도 있습니다. (i) 호출 데이터, (ii) 계산, (iii) 상태 액세스 및 가능한 다른 다양한 리소스에 대한 별도의 가스 제한입니다. 다차원 가스는 복잡성을 증가시키지만, 그 대가로 평균 사례와 최악의 사례 간의 비율을 더 엄격하게 제한합니다. 다차원 가스를 사용하면 이론적으로 증명해야 하는 최대 분기 수가 12500에서 예를 들어 3000으로 줄어들 수 있습니다. 이렇게 되면 BLAKE 3는 오늘날에도 (거의) 충분할 것입니다.

다차원 가스를 사용하면 블록의 리소스 제한이 기본 하드웨어의 리소스 제한에 더 가까워질 수 있습니다.

또 다른 예상치 못한 도구는 블록 이후의 타임슬롯까지 상태 루트 계산을 지연시키는 것입니다. 이렇게 하면 상태 루트를 계산하는 데 12초가 주어지는데, 이는 가장 극단적인 경우에도 초당 60,000개의 해시만 증명 시간으로 충분하다는 것을 의미하며, 이는 BLAKE 3가 간신히 충분하다고 생각하게 만듭니다.

이 접근 방식의 단점은 가벼운 클라이언트 지연 시간 슬롯 하나를 추가한다는 점이지만, 이 지연 시간을 증명 생성 지연 시간으로 줄일 수 있는 더욱 영리한 기술이 있습니다. 예를 들어, 다음 블록을 기다리지 않고 노드가 증명을 생성하자마자 증명을 네트워크에 브로드캐스트할 수 있습니다.

로드맵의 나머지 부분과 어떻게 상호 작용하나요?

무국적 문제를 해결하면 싱글 플레이어 타겟팅의 어려움이 크게 증가합니다. Orbit SSF와 같이 싱글 플레이어 타겟팅의 최소 균형을 줄일 수 있는 기술이나 분대 타겟팅과 같은 애플리케이션 수준 전략이 있으면 더 실현 가능해질 것입니다.

EOF도 도입하면 다차원 가스 분석이 훨씬 쉬워집니다. 이는 다차원 가스의 주요 실행 복잡성이 부모 호출의 전체 가스를 통과하지 않는 하위 호출을 처리하는 데서 발생하고, EOF는 이러한 하위 호출을 불법으로 만드는 것만으로 이 문제를 사소하게 만들 수 있기 때문입니다(그리고 네이티브 계정 추상화는 현재 가스의 주요 용도 중 일부에 대한 프로토콜 내 대안을 제공합니다).

상태 없는 검증과 기록 만료 사이에는 또 다른 중요한 시너지가 있습니다. 오늘날 클라이언트는 거의 1TB의 기록 데이터를 저장해야 합니다. 이 데이터는 상태 데이터의 몇 배입니다. 클라이언트가 상태 없는 경우에도 기록 데이터를 저장하는 책임에서 클라이언트를 해방하지 않는 한 거의 저장소가 없는 클라이언트라는 꿈은 실현되지 않을 것입니다. 이와 관련된 첫 번째 단계는 EIP-4444로, 이는 또한 토런트나 포털에 기록 데이터를 저장하는 것을 의미합니다.

EVM 실행의 유효성 증명

우리는 어떤 문제를 해결하려고 하는가?

이더리움 블록 검증의 장기적 목표는 명확합니다. 이더리움 블록을 검증하는 것은 다음을 통해 가능해야 합니다. (i) 블록을 다운로드하거나 블록의 데이터 가용성을 약간 샘플링합니다. (ii) 블록이 유효하다는 작은 증거를 확인합니다. 이는 모바일 클라이언트, 브라우저 지갑 또는 다른 체인(데이터 가용성 부분 없음)에서 수행할 수 있는 매우 낮은 리소스 작업이 될 것입니다.

이를 달성하기 위해 (i) 합의 계층(즉, 지분 증명) 및 (ii) 실행 계층(즉, EVM)에 대한 SNARK 또는 STARK 증명이 필요합니다. 전자는 그 자체로 과제이며 합의 계층의 지속적인 개선 과정에서 해결해야 합니다(예: 단일 슬롯 확정성). 후자는 EVM 실행 증명이 필요합니다.

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

공식적으로, 이더리움 사양에서 EVM은 상태 전이 함수로 정의됩니다. 사전 상태 S, 블록 B가 있고 사후 상태 S = STF(S, B)를 계산하고 있습니다. 사용자가 라이트 클라이언트를 사용하는 경우 S와 S, 또는 E를 전부 가지고 있지 않습니다. 대신 사전 상태 루트 R, 사후 상태 루트 R, 블록 해시 H가 있습니다.

공개 입력: 이전 상태 루트 R, 사후 상태 루트 R, 블록 해시 H
개인 입력: 블록 본문 B, 블록 Q가 접근하는 상태의 객체, 블록 Q를 실행한 후의 동일한 객체, 상태 증명(예: Merkle 분기) P
주장 1: P는 R이 나타내는 상태의 일부를 Q가 포함하고 있다는 것을 유효하게 증명합니다.
주장 2: Q에서 STF를 실행하면 (i) 실행 프로세스는 Q 내부의 객체에만 액세스하고 (ii) 데이터 블록은 유효하며 (iii) 결과는 Q입니다.
주장 3: Q와 P의 정보를 사용하여 새로운 상태 루트를 다시 계산하면 R을 얻습니다.

이것이 존재한다면, Ethereum EVM 실행을 완전히 검증하는 가벼운 클라이언트를 가질 수 있을 것입니다. 이것은 클라이언트 리소스를 이미 상당히 낮게 만듭니다. 진정으로 완전히 검증하는 Ethereum 클라이언트를 달성하려면 컨센서스 측에서도 동일한 작업을 수행해야 합니다.

EVM 계산을 위한 유효성 증명의 구현은 이미 존재하며 L2에서 많이 사용됩니다. L1에서 EVM 유효성 증명을 실현 가능하게 만들기 위해 해야 할 일이 아직 많이 있습니다.

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

또 무엇을 할 수 있을까?

오늘날 전자 회계 시스템의 효율성은 보안과 검증 시간이라는 두 가지 측면에서 부족한 것으로 입증되었습니다.

안전한 유효성 증명에는 SNARK가 실제로 EVM 계산을 검증하고 취약점이 없음을 보장해야 합니다. 보안을 개선하는 두 가지 주요 기술은 다중 검증자와 형식 검증입니다. 다중 검증자는 여러 클라이언트가 있는 것처럼 여러 개의 독립적으로 작성된 유효성 증명 구현이 있으며, 클라이언트는 이러한 구현의 충분히 큰 하위 집합에서 증명되는 경우 블록을 허용합니다. 형식 검증에는 Lean 4와 같이 수학적 정리를 증명하는 데 일반적으로 사용되는 도구를 사용하여 유효성 증명이 기본 EVM 사양(예: EVM K 의미론 또는 Python으로 작성된 Ethereum 실행 계층 사양(EELS))의 올바른 실행만 허용한다는 것을 증명하는 것이 포함됩니다.

충분히 빠른 검증 시간은 모든 이더리움 블록이 4초 이내에 검증될 수 있다는 것을 의미합니다. 오늘날 우리는 이 목표에서 아직 멀었지만, 2년 전 생각했던 것보다 훨씬 더 가까이 다가왔습니다. 이 목표를 달성하려면 세 가지 방향으로 진전을 이루어야 합니다.

병렬화 - 현재 가장 빠른 EVM 검증기는 평균 15초 안에 이더리움 블록을 증명할 수 있습니다. 이는 수백 개의 GPU에서 병렬화한 다음 마지막에 작업을 함께 집계하여 수행합니다. 이론적으로 우리는 O(log(N)) 시간 안에 계산을 증명할 수 있는 EVM 검증기를 만드는 방법을 정확히 알고 있습니다. GPU가 각 단계를 수행한 다음 집계 트리를 만듭니다.

이를 구현하는 데는 어려움이 있습니다. 최악의 경우, 매우 큰 거래가 전체 블록을 차지하는 경우에도 계산은 거래별로 분할할 수 없고, 오히려 연산 코드(EVM 또는 RISC-V와 같은 기본 가상 머신의 연산 코드)로 분할해야 합니다. 가상 머신의 메모리가 증명의 여러 부분 간에 일관성을 유지하도록 하는 것은 구현에서 핵심 과제입니다. 그러나 이 재귀적 증명을 구현할 수 있다면, 다른 것은 개선되지 않았더라도 최소한 증명자 대기 시간 문제는 해결되었다는 것을 알 수 있습니다.

증명 시스템 최적화 – Orion, Binius, GRK 등과 같은 새로운 증명 시스템은 일반 목적 계산에 대한 검증 시간을 또 다시 상당히 단축시킬 가능성이 높습니다.
EVM 가스 비용에 대한 다른 변경 사항 – EVM의 많은 사항은 특히 최악의 시나리오에서 증명자에게 더 유리하도록 최적화할 수 있습니다. 공격자가 증명자를 10분 동안 차단하는 블록을 구성할 수 있다면 4초 안에 일반 Ethereum 블록을 증명할 수 있는 것만으로는 충분하지 않습니다. 필요한 EVM 변경 사항은 대략 다음 범주로 나눌 수 있습니다.

– 가스 비용의 변화 — 연산을 증명하는 데 오랜 시간이 걸리는 경우, 계산이 비교적 빠르더라도 가스 비용이 높아야 합니다. EIP-7667은 이와 관련하여 최악의 문제를 해결하기 위해 제안된 EIP입니다. 이러한 함수의 명령어와 사전 컴파일이 비교적 저렴하기 때문에 (전통적인) 해시 함수의 가스 비용을 상당히 증가시킵니다. 이러한 가스 비용 증가를 보상하기 위해 증명이 비교적 저렴한 EVM 명령어의 가스 비용을 줄여 평균 처리량을 그대로 유지할 수 있습니다.

– 데이터 구조 교체 – 상태 트라이를 STARK 친화적인 것으로 교체하는 것 외에도 거래 목록, 영수증 트라이 및 증명 비용이 많이 드는 다른 구조도 교체해야 합니다. Etan Kissling의 거래 및 영수증 구조를 SSZ로 옮기는 EIP는 이 방향으로 나아가는 한 걸음입니다.

또한, 이전 섹션에서 언급한 두 가지 도구(다차원 가스와 지연된 상태 루트)도 이와 관련하여 도움이 될 수 있습니다. 그러나 무상태 검증과 달리 이 두 도구를 사용하면 현재 필요한 작업을 수행할 수 있는 충분한 기술이 이미 있다는 것을 의미하며, 이러한 기술을 사용하더라도 전체 ZK-EVM 검증에는 더 많은 작업이 필요합니다. 그저 덜 작업할 뿐입니다.

위에서 언급하지 않은 한 가지는 증명 하드웨어입니다. GPU, FPGA 및 ASIC을 사용하여 증명을 더 빠르게 생성합니다. Fabric Cryptography, Cysic 및 Accseal은 이 분야에서 진전을 이루고 있는 세 회사입니다. 이는 L2에 매우 귀중하지만 L1에 대한 결정적인 고려 사항이 되지는 않을 것입니다. L1이 고도로 분산된 상태를 유지하려는 강한 욕구가 있기 때문입니다. 즉, 증명 생성은 Ethereum 사용자가 합리적으로 도달할 수 있어야 하며 단일 회사의 하드웨어로 인해 병목 현상이 발생해서는 안 됩니다. L2는 더 공격적인 트레이드오프를 할 수 있습니다.

다음 분야에서는 해야 할 일이 더 많습니다.

증명을 병렬화하려면 증명 시스템의 여러 부분이 메모리를 공유할 수 있어야 합니다(예: 조회 테이블). 이를 수행하는 기술은 알고 있지만 구현해야 합니다.
최악의 검증 시간을 최소화하는 이상적인 가스 비용 변동 세트를 파악하기 위해 추가 분석이 필요합니다.
우리는 증명 시스템에 대해 더 많은 작업을 해야 합니다.

발생 가능한 비용은 다음과 같습니다.

보안 및 검증자 시간: 보다 공격적인 해시 함수, 보다 복잡한 증명 시스템, 또는 보다 공격적인 보안 가정이나 다른 설계 선택을 선택하면 검증자 시간을 줄일 수 있습니다.
분산화와 증명 시간: 커뮤니티는 타겟으로 삼을 증명 하드웨어의 "사양"에 동의해야 합니다. 증명자가 대규모 엔터티여야 한다고 요구하는 것이 괜찮을까요? 고급 소비자용 노트북이 4초 안에 이더리움 블록을 증명할 수 있기를 원할까요? 그 중간쯤일까요?
이전 버전과의 호환성을 깨는 정도: 다른 결함은 보다 공격적인 가스 비용 변경으로 보상할 수 있지만, 이는 일부 애플리케이션의 비용을 불균형적으로 증가시켜 개발자가 경제적으로 실행 가능한 상태를 유지하기 위해 코드를 다시 작성하고 재배포하도록 강요할 가능성이 더 큽니다. 다시 말하지만, 두 도구 모두 고유한 복잡성과 단점이 있습니다.

로드맵의 나머지 부분과 어떻게 상호 작용하나요?

L1 EVM 유효성 증명을 달성하는 데 필요한 핵심 기술은 크게 두 가지 다른 영역과 공유됩니다.

L2 유효성 증명(일명 ZK 롤업)
Stateless STARK 바이너리 해시 증명 방법

L1에서 유효성 증명을 성공적으로 구현하면 결국 쉬운 1인 스테이킹이 가능해집니다. 가장 약한 컴퓨터(휴대폰이나 스마트워치 포함)도 스테이킹할 수 있습니다. 이를 통해 32 ETH 최소값과 같은 1인 스테이킹의 다른 제한 사항을 해결하는 가치가 더욱 커집니다.

또한 L1의 EVM 유효성 증명은 L1의 가스 한도를 크게 증가시킬 수 있습니다.

합의 유효성 증명

우리는 어떤 문제를 해결하려고 하는가?

SNARK를 사용하여 Ethereum 블록을 완전히 검증하려면 EVM 실행이 우리가 증명해야 할 유일한 부분이 아닙니다. 또한 입금, 출금, 서명, 검증자 잔액 업데이트 및 Ethereum의 지분 증명 구성 요소의 다른 요소를 처리하는 시스템 부분인 합의도 증명해야 합니다.

합의는 EVM보다 훨씬 간단하지만, 문제는 L2 EVM 컨볼루션이 없기 때문에 대부분의 작업을 어차피 해야 한다는 것입니다. 따라서 모든 스크래치 증명 Ethereum 합의 구현은 스크래치부터 시작해야 하지만 스크래치 증명 시스템 자체는 그 위에 구축할 수 있는 공동의 노력입니다.

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

비콘 체인은 EVM과 마찬가지로 상태 전환 함수로 정의됩니다. 상태 전환 함수는 세 가지 주요 부분으로 구성됩니다.

ECADD(BLS 서명 확인용)
페어링(BLS 서명 검증용)
SHA 256 해시 값(상태 읽기 및 업데이트에 사용됨)

각 블록에서 검증자당 1-16개의 BLS 12-381 ECADD를 증명해야 합니다(서명이 여러 세트에 포함될 수 있으므로 둘 이상일 수 있음). 이는 부분집합 사전 계산 기술로 보상할 수 있으므로 각 검증자는 BLS 12-381 ECADD를 하나만 증명하면 된다고 할 수 있습니다. 현재 슬롯당 30,000개의 검증자 서명이 있습니다. 미래에는 단일 슬롯 확정성이 달성됨에 따라 이는 두 가지 방향으로 바뀔 수 있습니다. 무차별 대입 방식을 사용하면 슬롯당 검증자 수가 100만 개로 늘어날 수 있습니다. 동시에 Orbit SSF를 채택하면 검증자 수가 32,768개로 유지되거나 8,192개로 줄어들 수도 있습니다.

BLS 집계가 작동하는 방식: 전체 서명을 검증하려면 참가자당 ECADD 하나만 필요하고 ECMUL은 필요하지 않습니다. 하지만 30,000개의 ECADD는 여전히 많은 증거입니다.

페어링 측면에서 현재 슬롯당 최대 128개의 증명이 있으며, 이는 128개의 페어링을 검증해야 한다는 것을 의미합니다. EIP-7549와 추가 수정을 통해 슬롯당 16개로 줄일 수 있습니다. 페어링 수는 적지만 비용은 매우 높습니다. 각 페어링은 ECADD보다 실행(또는 증명)하는 데 수천 배 더 오래 걸립니다.

BLS 12-381 연산을 증명하는 데 있어서 가장 큰 과제는 BLS 12-381 필드 크기에 맞는 편리한 차수 곡선이 없다는 것입니다. 이는 모든 증명 시스템에 상당한 오버헤드를 추가합니다. 반면, Ethereum에 제안된 Verkle 트리는 Bandersnatch 곡선을 사용하여 구축되므로 BLS 12-381 자체가 SNARK 시스템에서 Verkle 분기를 증명하기 위한 기본 곡선이 됩니다. 순진한 구현으로 초당 100G 1 추가를 증명할 수 있습니다. 증명을 충분히 빠르게 하려면 GKR과 같은 영리한 기술이 필요할 가능성이 큽니다.

현재 SHA 256 해시의 최악의 경우는 에포크 전환 블록으로, 여기서 전체 검증자 숏 밸런스드 트리와 많은 수의 검증자 잔액이 업데이트됩니다. 각 검증자 숏 밸런스드 트리는 1바이트에 불과하므로 1MB의 데이터가 다시 해시됩니다. 이는 32768개의 SHA 256 호출과 동일합니다. 1,000개의 검증자가 임계값 위나 아래의 잔액을 가지고 있는 경우 검증자 레코드의 유효 잔액을 업데이트해야 하며, 이는 1,000개의 Merkle 분기와 동일하므로 아마도 10,000개의 해시가 필요할 것입니다. 셔플 메커니즘은 검증자당 90비트(따라서 11MB의 데이터)가 필요하지만, 이는 에포크에서 언제든지 계산될 수 있습니다. 단일 슬롯 확정성의 경우 이러한 숫자는 상황에 따라 증가하거나 감소할 수 있습니다. 셔플링은 불필요해지지만 Orbit이 어느 정도 필요성을 회복할 수 있습니다.

또 다른 과제는 블록을 검증하기 위해 공개 키를 포함한 모든 검증자 상태를 다시 가져와야 한다는 것입니다. 검증자가 100만 명인 경우 공개 키를 읽는 데만 4,800만 바이트와 Merkle 분기가 필요합니다. 이를 위해서는 에포크당 수백만 개의 해시가 필요합니다. PoS의 유효성을 증명해야 한다면 현실적인 접근 방식은 점진적으로 검증 가능한 계산의 일종이 될 것입니다. 효율적인 조회에 최적화된 증명 시스템 내에 별도의 데이터 구조를 저장하고 해당 구조에 대한 업데이트를 증명하는 것입니다.

요약하자면, 과제는 수없이 많습니다. 가장 효과적으로 이를 해결하려면 비콘 체인을 심층적으로 재설계해야 할 가능성이 높으며, 이는 단일 슬롯 최종성으로의 전환과 병행하여 수행될 수 있습니다. 이러한 재설계의 특징은 다음과 같습니다.

해시 함수의 변경: 이제 전체 SHA 256 해시 함수를 사용하고 있으므로 각 호출은 패딩으로 인해 기본 압축 함수에 대한 두 호출과 일치합니다. 대신 SHA 256 압축을 사용하면 최소 2배의 이득을 얻을 수 있습니다. 대신 Poseidon을 사용하면 잠재적으로 100배의 이득을 얻을 수 있으므로 모든 문제를 완전히 해결할 수 있습니다(적어도 해시율 측면에서): 초당 170만 해시(54MB)로, 백만 개의 검증 레코드도 몇 초 안에 증명으로 읽을 수 있습니다.
Orbit의 경우, 섞인 검증자 레코드는 직접 저장됩니다. 특정 수의 검증자(예: 8192 또는 32768)가 주어진 슬롯의 위원회로 선택되면, 이들은 바로 옆에 있는 상태로 들어가므로 모든 검증자 공개 키를 증명으로 읽어들이는 데 최소한의 해싱만 필요합니다. 이를 통해 모든 잔액 업데이트를 효율적으로 수행할 수도 있습니다.
서명 집계: 모든 고성능 서명 집계 체계에는 일종의 재귀적 증명이 포함되며, 여기서 네트워크의 여러 노드가 서명 하위 집합에 대한 중간 증명을 수행합니다. 이는 자연스럽게 증명 작업을 네트워크의 여러 노드에 분산시켜 최종 증명자의 작업 부하를 크게 줄입니다.
다른 서명 방식: Lamport+ Merkle 서명의 경우 서명을 검증하기 위해 256 + 32 해시가 필요합니다. 32768명의 서명자를 곱하면 9437184개의 해시가 됩니다. 서명 방식에 대한 최적화는 작은 상수 요소로 이 결과를 더욱 개선할 수 있습니다. Poseidon을 사용하면 단일 슬롯에서 이를 증명할 수 있습니다. 하지만 실제로는 재귀적 집계 방식을 사용하는 것이 더 빠릅니다.

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

아직 해야 할 일은 무엇이며 어떻게 선택해야 하는가:

실제로, 이더리움 합의의 타당성 증명을 얻는 데는 몇 년이 걸릴 것입니다. 이는 단일 슬롯 확정성, Orbit을 달성하고, 서명 알고리즘을 수정하고, Poseidon과 같은 급진적인 해시 함수를 사용할 만큼 충분한 확신을 갖는 데 필요한 보안 분석에 걸린 시간과 거의 같습니다. 따라서 가장 현명한 접근 방식은 이러한 다른 문제를 해결하고 이를 해결하는 동안 STARK 친화성을 고려하는 것입니다.

주요 트레이드오프는 아마도 Ethereum의 컨센서스 계층을 개혁하는 데 있어 보다 점진적인 접근 방식과 한 번에 여러 가지 접근 방식을 사용하는 보다 급진적인 변화 사이의 작업 순서일 것입니다. EVM의 경우, 이전 버전과의 호환성에 대한 중단을 최소화하기 때문에 점진적인 접근 방식이 합리적입니다. 컨센서스 계층의 경우, 이전 버전과의 호환성에 미치는 영향이 작고, 비콘 체인이 SNARK 친화성을 최적화하기 위해 어떻게 구축되는지에 대한 다양한 세부 사항을 보다 전체적으로 재고하는 데 이점이 있습니다.

로드맵의 나머지 부분과 어떻게 상호 작용하나요?

Ethereum PoS의 장기적인 재설계에서는 STARK 친화성이 최우선 고려 사항이어야 하며, 특히 단일 슬롯 확정성, Orbit, 서명 체계 변경 및 서명 집계가 중요합니다.

이 기사는 인터넷에서 발췌한 것입니다: Vitalik의 새로운 기사: Ethereum의 가능한 미래, The Verge

관련: 몰락한 슈퍼스타: 암호화폐 인물 체포 사건을 돌아보며

소개: 파벨 두로프 체포 2024년 8월, 텔레그램 설립자 파벨 두로프가 파리에서 체포되었습니다. 이 사건은 암호화폐 커뮤니티에서 광범위한 주목과 논의를 불러일으켰습니다. 두로프의 체포는 Toncoin 프로젝트에 직접적인 부정적인 영향을 미쳐 시장 성과가 폭락하고 가격과 거래량이 모두 급격히 떨어졌을 뿐만 아니라 암호화폐 분야의 법적 및 규제적 위험도 부각되었습니다. Toncoin은 고속, 보안 및 확장 가능한 블록체인 네트워크를 제공하는 것을 목표로 하는 Telegram Open Network(TON)를 기반으로 개발된 암호화폐 프로젝트입니다. 그러나 불법 거래와 아동 포르노 소지 및 배포에 연루된 혐의로 두로프가 체포되면서 이 프로젝트의 미래에 그림자가 드리워졌습니다. 두로프의 체포 소식이 전해진 후 크렘린은 재빨리…