원제: 이더리움 프로토콜의 가능한 미래, 4부: The Verge
원작자: 비탈릭 부테린
원본 편집: Mensh, ChainCatcher
피드백과 리뷰를 주신 Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy Ryan Sean Adams 및 Uma Roy에게 특별히 감사드립니다.
블록체인의 가장 강력한 기능 중 하나는 누구나 자신의 컴퓨터에서 노드를 실행하고 블록체인의 정확성을 확인할 수 있다는 것입니다. 체인 합의(PoW, PoS)를 실행하는 9596개의 노드가 모두 즉시 규칙 변경에 동의하고 새로운 규칙에 따라 블록을 생산하기 시작하더라도 완전히 검증된 노드를 실행하는 모든 사람은 체인 수락을 거부할 것입니다. 이러한 도당의 일부가 아닌 채굴자들은 이전 규칙을 계속 따르고 이 체인을 계속 구축하는 체인에 자동으로 모일 것이며, 완전히 검증된 사용자는 이 체인을 따를 것입니다.
이것이 블록체인과 중앙 집중식 시스템의 주요 차이점입니다. 그러나 이 기능이 유효하려면 완전히 검증된 노드를 실행하는 것이 실제로 충분한 사람들에게 실행 가능해야 합니다. 이는 캠페인 담당자(캠페인 담당자가 체인을 검증하지 않으면 프로토콜 규칙 시행에 기여하지 않기 때문에)와 일반 사용자 모두에게 적용됩니다. 현재는 소비자 노트북(이 글을 쓰고 있는 노트북 포함)에서 노드를 실행할 수 있지만 그렇게 하기는 어렵습니다. The Verge는 이러한 상황을 변화시켜 체인을 완전히 검증하는 데 드는 계산 비용을 낮추어 모든 모바일 지갑, 브라우저 지갑, 심지어 스마트 시계까지 기본적으로 이를 검증하는 것을 목표로 합니다.
더 버지 2023 로드맵
원래 Verge는 이더리움 상태 저장소를 Verkle 트리로 이동하는 것을 의미합니다. Verkle 트리는 보다 컴팩트한 증명을 허용하여 이더리움 블록의 무상태 검증을 가능하게 하는 트리 구조입니다. 노드는 수백 KB의 증거 데이터와 수백 밀리초의 추가 시간을 희생하여 하드 드라이브에 이더리움 상태(계정 잔액, 계약 코드, 저장 공간...)를 저장하지 않고도 이더리움 블록을 확인할 수 있습니다. . 오늘날 Verge는 상태 비저장 검증 기술뿐만 아니라 모든 Ethereum 실행을 검증하기 위한 SNARK 사용을 포함하는 Ethereum 체인의 최대 리소스 효율적인 검증을 가능하게 하는 데 초점을 맞춘 더 큰 비전을 나타냅니다.
전체 체인의 SNARK 검증에 대한 장기적인 초점 외에도 Verkle 트리가 최고의 기술인지 여부에 대한 또 다른 새로운 질문이 제기되었습니다. 버클 트리는 양자컴퓨터의 공격에 취약하기 때문에 현재의 KECCAK Merkle Patricia 트리를 버클 트리로 교체한다면 나중에 다시 트리를 교체해야 할 것입니다. Merkle 트리에 대한 독립적인 대안은 Merkle 분기를 사용하여 STARK를 건너뛰고 이진 트리에 넣는 것입니다. 역사적으로 이 접근 방식은 오버헤드와 기술적 복잡성으로 인해 실행 불가능한 것으로 간주되었습니다. 그러나 최근에는 Starkware가 노트북에서 ckcle STARK를 사용하여 초당 170만 개의 포세이돈 해시를 증명하는 것을 보았고 GKB와 같은 기술 덕분에 보다 전통적인 해시에 대한 증명 시간도 급격히 줄어들고 있습니다. 그래서 지난 1년 동안 Verge는 더욱 개방적이 되었고 여러 가지 가능성을 갖게 되었습니다.
The Verge: 주요 목표
상태 비저장 클라이언트: 클라이언트를 완전히 인증하고 노드를 표시하는 데 필요한 저장 공간은 몇 GB를 초과해서는 안 됩니다.
(장기) 스마트워치에서 완전히 검증된 체인(합의 및 실행)입니다. 일부 데이터를 다운로드하고 SNARK를 확인하면 완료됩니다.
이 장에서는
상태 비저장 클라이언트: Verkle 또는 STARK
EVM 실행의 효율성 증명
합의의 타당성 증명
무상태 검증: Verkle 또는 STARK
우리는 어떤 문제를 해결하려고 합니까?
오늘날 Ethereum 클라이언트는 블록을 검증하기 위해 수백 기가바이트의 상태 데이터를 저장해야 하며 이 양은 매년 증가하고 있습니다. 원시 상태 데이터는 연간 약 30GB씩 증가하며 단일 클라이언트는 트리플을 효율적으로 업데이트하기 위해 일부 추가 데이터를 여기에 저장해야 합니다.
이로 인해 Ethereum 노드를 완전히 검증할 수 있는 사용자 수가 줄어듭니다. 모든 Ethereum 상태와 수년간의 기록을 저장할 수 있을 만큼 큰 하드 드라이브를 널리 사용할 수 있지만 사람들은 기본적으로 수백 기가바이트의 저장 공간만 있는 컴퓨터를 구입하는 경향이 있습니다. 상태의 크기는 또한 처음으로 노드를 설정하는 프로세스에 상당한 마찰을 가져옵니다. 노드는 전체 상태를 다운로드해야 하며, 이는 몇 시간 또는 며칠이 걸릴 수 있습니다. 여기에는 온갖 종류의 연쇄 효과가 있습니다. 예를 들어, 노드 제작자가 노드 설정을 업그레이드하는 데 어려움이 크게 증가합니다. 기술적으로는 가동 중지 시간 없이 업그레이드를 완료하는 것이 가능합니다. 새 클라이언트를 시작하고 동기화될 때까지 기다린 다음 기존 클라이언트를 닫고 키를 전송합니다. 그러나 실제로 이는 기술적으로 매우 복잡합니다.
어떻게 작동하나요?
Stateless 검증은 노드가 전체 상태를 마스터하지 않고도 블록을 검증할 수 있도록 하는 기술입니다. 대신, 각 블록에는 다음을 포함하는 증인이 제공됩니다. (i) 블록이 액세스할 상태의 특정 위치에 있는 값, 코드, 잔액, 저장 공간, (ii) 이러한 값이 정확하다는 암호화 증거.
실제로 무상태 검증을 구현하려면 이더리움의 상태 트리 구조를 변경해야 합니다. 이는 현재 Merkle Patricia 트리가 특히 최악의 시나리오에서 암호화 증명 체계를 구현하는 데 매우 비우호적이기 때문입니다. 이는 원래 Merblk 포크이든 STARK로 포장될 가능성이든 마찬가지입니다. 주요 어려움은 MPT의 일부 약점에서 발생합니다.
1. 이것은 헥사트리입니다(즉, 각 노드에는 16개의 하위 노드가 있습니다). 이는 N 크기의 트리에서 증명에 평균 32*(16-1)*log 16(N) = 120* log 2(N) 바이트 또는 대략 3840바이트가 필요함을 의미합니다. 이진 트리의 경우 32*(2-1)*log 2(N) = 32* log 2(N) 바이트, 즉 약 1024바이트만 필요합니다.
2. 코드는 Merkleized되지 않습니다. 즉, 계정 코드에 대한 액세스를 증명하려면 전체 코드(최대 24,000바이트)를 제공해야 합니다.
최악의 시나리오는 다음과 같이 계산할 수 있습니다.
30000000 가스 / 2400 (콜드 계정 읽기 비용) * (5 * 488 + 24000) = 330000000바이트
가지가 많아지면 윗부분이 반복되기 때문에 가지 비용이 약간 감소되었습니다(8*480에서 5*480). 하지만 그렇다고 해도 한 번에 다운로드할 수 있는 데이터의 양은 전혀 현실적이지 않습니다. STARK로 래핑하려고 하면 두 가지 문제에 직면하게 됩니다. (i) KECCAK은 상대적으로 STARK에 적합하지 않습니다. (ii) 330MB의 데이터는 KECCAK의 라운드 함수에 대한 5백만 호출을 정당화해야 함을 의미합니다. STARK를 통해 KECCAK이 더 효율적이라는 것을 증명할 수 있더라도 가장 강력한 소비자 하드웨어를 제외한 모든 하드웨어에서 입증되었습니다.
16진수 트리를 이진 트리로 직접 교체하고 코드의 추가 Merkleization을 수행하면 최악의 시나리오는 대략 30000000/2400* 32*(32-14+ 8) = 10400000바이트가 됩니다(14는 중복 비트를 뺀 값입니다). 2^14 분기의 경우 8은 코드 블록의 리프로 들어가는 증명의 길이입니다. 이를 위해서는 EIP-4762 의 각 개별 블록에 액세스하기 위해 가스 비용을 변경해야 합니다. 10.4MB 용량이 훨씬 낫지만, 많은 노드에 대해 하나의 시간 슬롯에 다운로드하기에는 여전히 너무 많은 데이터입니다. 그러므로 우리는 더욱 강력한 기술을 도입해야 합니다. 이와 관련하여 Verkle 트리와 STARKed 바이너리 해시 트리라는 두 가지 주요 솔루션이 있습니다.
버클 트리
Verkle 트리는 더 짧은 증명을 위해 타원 곡선 기반 벡터 약속을 사용합니다. 이를 잠금 해제하는 열쇠는 각 부모-자식 관계에 대한 증명 부분이 트리 너비에 관계없이 32바이트에 불과하다는 것입니다. 증명 트리 너비에 대한 유일한 제한은 증명 트리가 너무 넓으면 증명의 계산 효율성이 떨어진다는 것입니다. 제안된 이더리움 구현의 너비는 256입니다.
따라서 증명에서 단일 분기의 크기는 32 - 1 og 256(N) = 4* log 2(N) 바이트가 됩니다. 따라서 이론적 최대 증명 크기는 대략 30000000 / 2400 * 32* ( 32 -14 + 8) / 8 = 130000바이트입니다. (실제 계산 결과는 상태 블록의 고르지 못한 분포로 인해 약간 다르지만 첫 번째 근사치는 다음과 같습니다. 좋아요).
주목해야 할 또 다른 점은 위의 모든 예에서 이 최악의 경우가 최악의 시나리오가 아니라는 것입니다. 더 나쁜 경우는 공격자가 의도적으로 두 개의 주소를 마이닝하여 트리 접두사에서 더 긴 공통 위치를 갖도록 하고 주소 중 하나에서 데이터를 읽으면 최악의 분기 길이가 2배 더 늘어날 수 있습니다. 하지만 그렇다고 하더라도 Verkle 트리의 최악 사례 증명 길이는 2.6MB로 현재 최악 사례 검증 데이터와 기본적으로 일치합니다.
우리는 또한 이 경고에 대해 다른 조치를 취했습니다. 즉, 인접 저장소(동일한 계약의 많은 코드 블록 또는 인접한 저장소 슬롯)에 액세스하는 것을 매우 저렴하게 만들었습니다. 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 Circle은 글을 쓰는 시점에 소비자 노트북에서 초당 10-30,000개의 해시만 증명할 수 있습니다. 그러나 STARK 기술은 빠르게 발전하고 있습니다. 오늘날에도 GKR 기반 기술은 이 속도를 100-2 O 0 k 범위로 증가시키는 것으로 나타났습니다.
블록 검증 이상의 사용 사례 목격
블록 검증 외에도 보다 효율적인 무상태 검증이 필요한 세 가지 주요 사용 사례가 있습니다.
Mempool: 트랜잭션이 브로드캐스트되면 P2P 네트워크의 노드는 트랜잭션을 다시 브로드캐스트하기 전에 트랜잭션이 유효한지 확인해야 합니다. 오늘의 확인에는 서명 확인뿐만 아니라 잔액이 충분하고 접두어가 올바른지 확인하는 것도 포함됩니다. 미래에는(예: EIP-7701과 같은 기본 계정 추상화 사용) 일부 상태 액세스를 수행하는 일부 EVM 코드를 실행해야 할 수 있습니다. 노드가 상태 비저장인 경우 트랜잭션에는 상태 개체 증명이 수반되어야 합니다.
포함 목록: 이는 (아마도 더 작고 덜 복잡한) 지분 증명 검증자가 (아마도 더 크고 더 복잡한) 블록 작성자의 희망에 관계없이 다음 블록에 트랜잭션을 포함하도록 허용하는 제안된 기능입니다. 이는 거래를 지연시켜 블록체인을 조작하는 강력한 사람들의 능력을 약화시킬 것입니다. 그러나 이를 위해서는 유효성 검사기가 목록에 포함된 거래의 유효성을 확인할 수 있는 방법이 필요합니다.
라이트 클라이언트: 사용자가 지갑을 통해 체인(예: Metamask, Rainbow, Rabby 등)에 액세스할 수 있도록 하려면 Helios 코어 모듈은 사용자에게 검증된 인증서를 제공하는 라이트 클라이언트를 실행해야 합니다. 상태 루트 . 완전히 무신뢰 환경을 구현하려면 사용자는 자신이 하는 모든 RPC 호출에 대해 증거를 제공해야 합니다(예: 이더넷 호출 요청의 경우(사용자는 호출 중에 액세스된 모든 상태를 증명해야 함).
이러한 모든 사용 사례의 공통점은 꽤 많은 증명이 필요하지만 각 증명의 크기가 작다는 것입니다. 따라서 STARK 증명은 실질적인 의미가 없으며 대신 가장 현실적인 접근 방식은 Merkle 분기를 직접 사용하는 것입니다. Merkle 브랜치의 또 다른 장점은 업데이트가 가능하다는 것입니다. 상태 객체에 대한 증명이 주어지면 2가 루트입니다. Verkle 증명은 기본적으로 업데이트도 가능합니다.
기존 연구와의 연관성은 무엇입니까?
또 무엇을 할 수 있나요?
남은 주요 작업은
1. EIP-4762의 결과에 대한 추가 분석(상태 비저장 가스 비용 변경)
2. 상태 비저장 환경에 대한 구현 계획의 복잡성의 주요 부분인 전환 절차를 완료하고 테스트하기 위한 추가 작업
3. Poseidon, Ajtai 및 기타 STARK 친화적인 해시 함수에 대한 추가 보안 분석
4. 예를 들어 Binius 또는 GKR 관점을 기반으로 하는 보수적(또는 전통적인) 해싱을 위한 매우 효율적인 STARK 프로토콜 기능의 추가 개발.
또한 우리는 곧 다음 세 가지 옵션 중 하나를 선택하기로 결정할 것입니다: (i) Verkle 트리, (ii) STARK 친화적 해시 함수 및 (iii) 보수적 해시 함수. 그 특징은 대략 다음 표에 요약되어 있습니다.
이러한 제목 번호 외에도 몇 가지 중요한 고려 사항이 있습니다.
오늘날 Verkle 트리 코드는 상당히 성숙해졌습니다. Verkle 이외의 코드를 사용하면 배포가 지연되고 하드 포크가 발생할 가능성이 높습니다. 그것도 괜찮습니다. 특히 해시 함수 분석이나 유효성 검사기 구현을 위해 추가 시간이 필요하거나 더 일찍 이더리움에 통합하고 싶은 다른 중요한 기능이 있는 경우에는 더욱 그렇습니다.
해시를 사용하여 상태 루트를 업데이트하는 것이 Verkle 트리를 사용하는 것보다 빠릅니다. 이는 해시 기반 접근 방식이 전체 노드의 동기화 시간을 줄일 수 있음을 의미합니다.
Verkle 트리에는 흥미로운 증인 업데이트 속성이 있습니다. Verkle 트리 증인은 업데이트 가능합니다. 이 속성은 멤풀, 포함 목록 및 기타 사용 사례에 유용하며 구현을 보다 효율적으로 만드는 데 도움이 될 수도 있습니다. 상태 객체가 업데이트되면 마지막 레이어의 콘텐츠를 읽지 않고도 두 번째 레이어의 감시가 업데이트될 수 있습니다.
Verkle 나무는 SNARK 증명이 더 어렵습니다. Verkle 증명은 증명 크기를 몇 킬로바이트까지 줄이려는 경우 몇 가지 어려움을 야기합니다. 이는 Verkle 증명 검증에 다수의 256비트 작업이 도입되므로 증명 시스템에 큰 오버헤드가 있거나 자체적으로 256비트 Verkle 증명 부분을 포함하는 사용자 정의 내부 구조가 있어야 하기 때문입니다. 이는 무국적 자체의 문제는 아니지만 더 많은 어려움을 야기합니다.
양자 안전하고 합리적으로 효율적인 방식으로 Verkle 증인 업데이트 가능성을 얻으려면 격자 기반 Merkle 트리가 가능한 또 다른 접근 방식입니다.
최악의 경우 시스템이 충분히 효율적이지 않은 것으로 밝혀지면 예상치 못한 다차원 가스 도구를 사용하여 이러한 단점을 보완할 수도 있습니다. (i) 호출 데이터 (iii); ) 상태 액세스 및 기타 다른 리소스는 별도의 가스 제한을 설정합니다. 다차원 가스는 복잡성을 추가하지만 그 대신 평균 사례와 최악 사례 간의 비율을 더욱 엄격하게 제한합니다. 다차원 가스를 사용하면 입증해야 하는 최대 분기 수는 이론적으로 12500에서 예를 들어 3000으로 줄어들 수 있습니다. 이것은 오늘날에도 BLAKE 3를 (거의) 적절하게 만들 것입니다.
다차원 가스를 사용하면 블록의 리소스 제한이 기본 하드웨어의 리소스 제한과 더 밀접하게 일치할 수 있습니다.
또 다른 예상치 못한 도구는 블록 다음의 시간 슬롯까지 상태 루트 계산을 지연시키는 것입니다. 이는 상태 루트를 계산하는 데 12초를 제공합니다. 이는 가장 극단적인 경우에도 초당 60,000개의 해시만으로 충분한 증명 시간이며, 이는 다시 BLAKE 3가 요구 사항을 간신히 충족할 수 있다고 생각하게 만듭니다.
이 접근 방식의 단점은 라이트 클라이언트 대기 시간 슬롯 하나를 추가한다는 점이지만, 생성 대기 시간을 증명하기 위해 이 대기 시간을 줄일 수 있는 더 영리한 기술이 있습니다. 예를 들어, 다음 블록을 기다리지 않고 노드가 생성하는 즉시 증명을 네트워크에 브로드캐스팅할 수 있습니다.
로드맵의 다른 부분과 어떻게 상호 작용합니까?
무국적 문제를 해결하면 1인 고정점의 난이도가 크게 높아집니다. Orbit SSF와 같은 싱글 플레이어 타겟팅에 대한 최소 밸런스나 스쿼드 타겟팅과 같은 애플리케이션 레이어 전략을 낮추는 기술이 있다면 이는 더 실현 가능해질 것입니다.
EOF도 도입하면 다차원 가스 분석이 더 쉬워집니다. 이는 다차원 가스의 주요 실행 복잡성이 상위 호출의 모든 가스를 전달하지 않는 하위 호출을 처리하는 데서 발생하고 EOF는 단순히 이러한 하위 호출을 불법으로 만듦으로써 이 문제를 사소하고 고유하게 만들 수 있기 때문입니다. 현재 가스의 주요 사용 사례 중 일부에 대한 프로토콜 내 대안입니다.
상태 비저장 검증과 기록 만료 사이에는 중요한 시너지 효과도 있습니다. 오늘날 클라이언트는 거의 테라바이트에 달하는 기록 데이터를 저장해야 합니다. 이 데이터는 상태 데이터보다 몇 배 더 큽니다. 클라이언트가 무국적이라 하더라도, 클라이언트의 기록 데이터 저장 책임을 덜어주지 않으면 거의 스토리지가 없는 클라이언트의 꿈은 실현되지 않을 것입니다. 이와 관련하여 첫 번째 단계는 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는 Q가 R로 표현되는 상태의 일부를 포함한다는 유효한 증거입니다.
주장 2: Q에서 STF를 실행하는 경우 (i) 실행은 Q 내부의 개체에만 액세스하고, (ii) 데이터 블록은 유효하며, (iii) 결과는 Q입니다.
주장 3: Q와 P의 정보를 사용하여 새로운 상태 루트를 다시 계산하면 R을 얻게 됩니다.
만약 그렇다면 이더리움 EVM 실행을 완전히 인증하는 라이트 클라이언트를 갖는 것이 가능할 것입니다. 이로 인해 클라이언트의 리소스가 이미 상당히 부족해졌습니다. 완전히 검증된 이더리움 클라이언트를 달성하려면 합의 측면에서도 동일한 작업을 수행해야 합니다.
EVM 계산에 대한 유효성 증명 구현은 이미 존재하며 L2에서 많이 사용됩니다. L1에서 EVM 유효성 증명을 실현하려면 아직 해야 할 일이 많습니다.
기존 연구와의 연관성은 무엇입니까?
또 무엇을 할 수 있나요?
오늘날 전자회계시스템의 효율성은 보안과 검증시간이라는 두 가지 측면에서 부족한 것으로 드러났습니다.
안전한 유효성 증명을 위해서는 SNARK가 실제로 EVM의 계산을 검증하고 취약점이 없는지 확인해야 합니다. 보안을 향상시키는 두 가지 주요 기술은 다중 유효성 검사기와 공식 검증입니다. 다중 유효성 검사기는 여러 클라이언트가 있는 것처럼 독립적으로 작성된 여러 유효성 증명 구현을 갖는 것을 의미하며, 블록이 이러한 구현의 충분히 큰 하위 집합에 의해 증명되면 클라이언트는 블록 조각을 수락합니다. 공식 검증에는 Lean 4와 같은 수학적 정리를 증명하는 데 일반적으로 사용되는 도구를 사용하여 유효성 증명이 기본 EVM 사양(예: EVM K 의미 체계 또는 Python으로 작성된 EELS(Ethereum Execution Layer Spec))의 올바른 실행만 허용한다는 것을 증명하는 것이 포함됩니다. .
검증 시간이 충분히 빠르다는 것은 모든 이더리움 블록을 4초 이내에 검증할 수 있다는 것을 의미합니다. 오늘날 우리는 2년 전 생각했던 것보다 훨씬 더 가까워졌지만 여전히 그 목표까지는 멀었습니다. 이를 달성하기 위해 우리는 세 가지 방향으로 진전을 이뤄야 합니다.
병렬화 – 현재 가장 빠른 EVM 검증자는 평균 15초 안에 이더리움 블록을 증명할 수 있습니다. 수백 개의 GPU를 병렬화하고 마지막에 작업을 함께 풀링하여 이를 수행합니다. 이론적으로 우리는 O(log(N)) 시간 내에 계산을 증명할 수 있는 EVM 검증기를 만드는 방법을 정확히 알고 있습니다. GPU가 각 단계를 완료하도록 하고 마지막으로 집계 트리를 만듭니다.
이를 달성하는 데에는 어려움이 있습니다. 매우 큰 트랜잭션이 전체 블록을 차지하는 최악의 시나리오에서도 계산 분할은 패스별로 수행될 수 없으며 opcode(EVM 또는 RISC-V와 같은 기본 가상 머신의 opcode)별로 이루어져야 합니다. 증명의 여러 부분 간에 가상 머신의 메모리가 일관되게 유지되는지 확인하는 것이 구현 중 핵심 과제입니다. 그러나 이러한 종류의 재귀 증명을 구현할 수 있다면 다른 측면에서는 개선이 없더라도 적어도 증명자의 지연 문제는 해결되었음을 알 수 있습니다.
증명 시스템 최적화 - Orion, Binius, GRK 등과 같은 새로운 증명 시스템은 범용 계산에 대한 검증 시간을 또 한 번 크게 줄여줄 것입니다.
EVM 가스 비용에 대한 기타 변경 사항 - 특히 최악의 시나리오에서 증명자에게 더 많은 이점을 제공하도록 EVM의 많은 항목을 최적화할 수 있습니다. 공격자가 10분 동안 증명자를 차단하는 블록을 구성할 수 있다면 4초 안에 일반적인 이더리움 블록을 증명하는 것만으로는 충분하지 않습니다. 필요한 EVM 변경 사항은 크게 다음 범주로 나눌 수 있습니다.
- 가스 비용의 변화 - 작업을 증명하는 데 오랜 시간이 걸리면 계산이 상대적으로 빠르더라도 가스 비용이 높아야 합니다. EIP-7667은 이와 관련하여 가장 심각한 문제를 해결하기 위해 제안된 EIP입니다. 이러한 기능의 opcode와 사전 컴파일이 상대적으로 저렴하기 때문에 (전통적인) 해시 기능의 가스 비용을 크게 증가시킵니다. 이러한 가스 비용 증가를 보상하기 위해 상대적으로 증거가 낮은 EVM opcode의 가스 비용을 줄여 평균 처리량을 일정하게 유지할 수 있습니다.
- 데이터 구조 교체 - 상태 트리를 보다 STARK 친화적인 접근 방식으로 교체하는 것 외에도 트랜잭션 목록, 영수증 트리 및 비용이 많이 드는 기타 구조도 교체해야 합니다. Etan Kissling의 EIP 거래 및 수령 구조를 SSZ로 이전하는 것은 이러한 방향으로 나아가는 단계입니다.
또한 이전 섹션에서 언급한 두 가지 도구(다차원 가스 및 지연 상태 루트)도 이와 관련하여 도움이 될 수 있습니다. 그러나 무상태 검증과 달리 이 두 도구를 사용한다는 것은 현재 필요한 작업을 수행할 수 있는 충분한 기술이 이미 있다는 것을 의미하며, 이러한 기술을 사용하더라도 전체 ZK-EVM 검증에는 더 많은 작업이 필요합니다. 일하다.
위에서 언급되지 않은 한 가지는 증명자 하드웨어입니다. GPU, FPGA 및 ASIC을 사용하여 증명을 더 빠르게 생성합니다. Fabric Cryptography, Cysic 및 Accseal은 이 분야에서 발전을 이루고 있는 세 회사입니다. 이는 L2에게는 매우 가치가 있지만 L1에 대한 결정적인 고려 사항은 아닐 것입니다. L1이 고도로 분산된 상태를 유지하려는 강한 바람이 있기 때문입니다. 이는 증명 생성이 이더리움 사용자의 합리적인 범위 내에 있어야 하며 다음의 대상이 되어서는 안 된다는 것을 의미합니다. 단일 회사 하드웨어의 병목 현상 제한. L2는 보다 긍정적인 균형을 이룰 수 있습니다.
이러한 영역에서는 더 많은 작업이 수행되어야 합니다.
병렬화를 증명하려면 시스템의 서로 다른 부분(예: 조회 테이블)이 메모리를 공유할 수 있음을 증명해야 합니다. 우리는 이를 수행하는 기술을 알고 있지만 구현해야 합니다.
최악의 경우 검증 시간을 최소화하는 이상적인 가스 비용 변동 세트를 찾으려면 더 많은 분석을 수행해야 합니다.
우리는 시스템 입증에 더 많은 노력을 기울여야 합니다.
가능한 비용은 다음과 같습니다:
보안 대 검증자 시간: 더 공격적인 해시 함수, 더 복잡한 증명 시스템, 더 공격적인 보안 가정 또는 기타 설계 솔루션을 선택하면 검증자 시간을 줄일 수 있습니다.
분산화 및 증명 시기: 커뮤니티는 대상 증명자 하드웨어의 사양에 동의해야 합니다. 인증자를 대규모 법인으로 요구해도 괜찮나요? 고급 소비자 노트북이 4초 안에 이더리움 블록을 증명할 것으로 기대합니까? 그 사이 어딘가?
이전 버전과의 호환성이 손상되는 정도: 다른 결함은 더 공격적인 가스 비용 변경으로 보완될 수 있지만 이로 인해 일부 응용 프로그램의 비용이 불균형적으로 증가할 가능성이 높아 개발자가 경제적으로 실행 가능한 상태를 유지하기 위해 코드를 다시 작성하고 재배포해야 합니다. 마찬가지로 두 도구 모두 고유한 복잡성과 단점을 가지고 있습니다.
로드맵의 다른 부분과 어떻게 상호 작용합니까?
L1 EVM 유효성 증명을 구현하는 데 필요한 핵심 기술은 주로 다른 두 영역과 공유됩니다.
L2의 유효성 증명(예: ZK 롤업)
상태 비저장 STARK 바이너리 해시 증명 방법
L1에서 유효성 증명이 성공적으로 구현되면 마침내 한 사람이 쉽게 스테이킹할 수 있게 됩니다. 심지어 가장 약한 컴퓨터(휴대폰이나 스마트 시계 포함)도 스테이킹할 수 있습니다. 이는 최소 32 ETH와 같은 단일 스테이킹의 다른 제한 사항을 해결하는 가치를 더욱 높입니다.
또한, L1의 EVM 유효성은 L1의 가스 한도가 크게 향상될 수 있음을 입증합니다.
합의의 타당성 증명
우리는 어떤 문제를 해결하려고 합니까?
SNARK를 사용하여 이더리움 블록을 완전히 검증하려면 EVM 실행만이 우리가 증명해야 하는 유일한 부분은 아닙니다. 또한 예금, 인출, 서명, 검증자 잔액 업데이트 및 이더리움 지분 증명 부분의 기타 요소를 처리하는 시스템의 일부인 합의 증명이 필요합니다.
합의는 EVM보다 훨씬 간단하지만 L2 EVM 컨볼루션이 없기 때문에 대부분의 작업을 어쨌든 완료해야 한다는 것이 문제입니다. 따라서 증명 시스템 자체는 구축할 수 있는 공유 노력이지만 이더리움 합의 증명 구현은 처음부터 시작되어야 합니다.
그것은 무엇이며 어떻게 작동합니까?
비콘 체인은 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 집계 작동 방식: 전체 서명을 확인하려면 ECMUL이 아닌 참가자당 하나의 ECADD만 필요합니다. 그러나 30,000개의 ECADD는 여전히 많은 증거입니다.
페어링 측면에서 현재 슬롯당 최대 128개의 증명이 가능하며, 이는 128개의 페어링을 확인해야 함을 의미합니다. ElP-7549 및 추가 수정을 통해 이는 슬롯당 16개로 줄어들 수 있습니다. 쌍 수는 적지만 비용은 매우 높습니다. 각 쌍을 실행(또는 증명)하는 데 ECADD보다 수천 배 더 오래 걸립니다.
BLS 12-381 작업을 증명하는 데 있어 주요 과제는 BLS 12-381 필드 크기와 동일한 곡선 차수를 갖는 편리한 곡선이 없다는 것입니다. 이는 모든 증명 시스템에 상당한 오버헤드를 추가합니다. 반면, 이더리움용으로 제안된 Verkle 트리는 Bandersnatch 곡선으로 구축되어 BLS 12-381 자체가 SNARK 시스템에서 Verkle 분기를 증명하는 데 사용되는 자체 곡선이 됩니다. 상대적으로 간단한 구현은 초당 100G 1 추가를 증명할 수 있습니다. 증명을 충분히 빠르게 하려면 거의 확실히 GKR과 같은 영리한 기술이 필요합니다.
현재 SHA 256 해시에 대한 최악의 시나리오는 전체 검증인 단기 잔액 트리와 다수의 검증인 잔고가 업데이트되는 시대 전환 블록입니다. 각 검증인의 짧은 균형 트리는 1바이트에 불과하므로 1MB의 데이터가 다시 해시됩니다. 이는 32768 SHA 256 호출과 동일합니다. 천 명의 검증인의 잔액이 임계값을 초과하거나 미만인 경우 검증인 레코드의 유효한 잔액을 업데이트해야 하며 이는 천 개의 Merkle 분기와 동일하므로 만 개의 해시가 필요할 수 있습니다. 셔플링 메커니즘에는 유효성 검사기당 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 친화적이라는 점을 염두에 두고 이러한 다른 문제를 해결하는 것입니다.
주요 절충점은 이더리움 합의 계층을 개혁하기 위한 보다 점진적인 접근 방식과 보다 급진적인 한 번에 많은 항목 변경 접근 방식 사이에서 운영 순서에 있을 가능성이 높습니다. EVM의 경우 이전 버전과의 호환성 중단을 최소화하기 때문에 점진적인 접근 방식이 적합합니다. 합의 계층에 대한 이전 버전과의 호환성 영향이 줄어들 것이며 SNARK 친화성을 가장 잘 최적화하기 위해 비콘 체인이 구축되는 방법에 대한 다양한 세부 사항을 보다 포괄적으로 다시 생각하는 이점도 있을 것입니다.
로드맵의 다른 부분과 어떻게 상호 작용합니까?
이더리움 PoS의 장기적인 재설계에서는 STARK 친화성이 주요 고려 사항이어야 하며, 특히 단일 슬롯 최종성, 궤도, 서명 체계 변경 및 서명 집계가 중요합니다.
