Vitalik: 다양한 유형의 ZK-EVM의 미래
원래 제목: "The different types of ZK-EVMs》
원작자: Vitalik
원본 편집: 블록 유니콘
원래 제목: "
원작자: Vitalik
원본 편집: 블록 유니콘
최근 "ZK-EVM" 프로젝트에서 많은 주목할만한 발표가 있었습니다. Polygon은 ZK-EVM 프로젝트를 공개했고 ZKSync는 ZKSync 2.0 계획을 발표했으며 비교적 새로운 Scroll은 최근에 ZK-EVM을 발표했습니다. 또한 Privacy 및 Extended Exploration 팀, Nicolas Liochon 등의 팀, EVM에서 Starkware의 zk 친화적인 언어 Cairo용 알파 컴파일러에 이르기까지 지속적인 노력이 있으며 물론 제가 놓칠 프로젝트도 있습니다.
이 모든 프로젝트의 핵심 목표는 동일합니다. ZK-SNARK 기술을 사용하여 이더리움과 같은 트랜잭션 실행을 암호학적으로 증명하거나, 이더리움 체인 자체를 더 쉽게 확인하거나, 이더리움이 제공하는 것과 유사한(더 가깝지만) 콘텐츠를 구축합니다. 확장 가능한 zk 롤업. 그러나 이러한 프로젝트에는 미묘한 차이가 있으며 유틸리티와 속도 사이의 장단점도 있습니다. 이 게시물에서는 EVM 등가의 다양한 "유형"에 대한 분류와 각 구현을 시도할 때의 이점 및 비용에 대해 설명하려고 합니다.
개요(다이어그램 형식)
유형 1(Ethereum과 완전히 동일)
ZK-EVM의 첫 번째 유형은 이더리움과 완전하고 타협하지 않도록 노력합니다. 증명 생성을 더 쉽게 하기 위해 이더리움 시스템의 어떤 부분도 변경하지 않습니다. 해시, 상태 트리, 트랜잭션 트리, 사전 컴파일 또는 기타 합의 논리가 아무리 주변적일지라도 이를 대체하지 않습니다.
장점: 완벽한 호환성
우리의 목표는 지금처럼 이더리움 블록을 검증하거나 적어도 실행 계층(따라서 비콘 체인 합의 논리는 포함되지 않지만 모든 트랜잭션 실행과 스마트 계약 및 계정 논리가 포함됨)을 검증할 수 있는 것입니다.
유형 1: ZK-EVM은 궁극적으로 이더넷 레이어 1 자체의 확장성을 높이는 데 필요한 것입니다. 장기적으로, 유형 2 또는 유형 3 ZK-EVM에서 테스트된 에테르에 대한 수정이 에테르 자체에 도입될 수 있지만 이러한 재설계에는 고유한 복잡성이 따릅니다.
유형 1: ZK-EVM은 롤업에서 많은 인프라를 재사용할 수 있으므로 롤업에도 이상적입니다. 예를 들어 Etherum Execution 클라이언트를 그대로 사용하여 ROLLUP 블록을 생성하고 처리할 수 있습니다(또는 적어도 가져오기가 구현되면 재사용할 수 있으며 해당 기능을 재사용하여 ETH 입금을 ROLLUP에 지원할 수 있음). 관리자, 블록 생산 등과 같은 도구는 재사용하기가 매우 쉽습니다.
단점: 확인 시간
이더리움은 원래 zk 친화적으로 설계되지 않았기 때문에 이더리움 프로토콜의 많은 부분에서 zk를 확인하기 위해 많은 계산이 필요합니다. 유형 1은 이더리움을 정확하게 복제하는 것을 목표로 하므로 이러한 비효율성을 완화할 방법이 없습니다. 현재 Ethereum 블록의 증명은 생성하는 데 많은 시간이 걸립니다. 이 상황은 영리한 엔지니어링을 통해 검증기를 대규모로 병렬화하거나 장기적으로 ZK-SNARK ASIC로 완화할 수 있습니다.
빌더는 누구입니까?
Privacy and Scaling Exploration Team ZK-EVM은 Type 1 ZK-EVM을 구축하고 있습니다.
유형 2(완전히 동등한 EVM)
ZK의 두 번째 유형인 EVM은 EVM과 완전히 동등해지려고 노력하지만 Ethereum과 완전히 동등하지는 않습니다. 즉, 그들은 "내부에서" 이더리움과 똑같이 보이지만 외부에서는 특히 블록 구조 및 상태 트리와 같은 데이터 구조에서 약간의 차이가 있습니다.
목표는 기존 애플리케이션과 완벽하게 호환되는 것이지만 개발을 더 쉽게 만들고 증명을 더 빠르게 생성하기 위해 Ethereum을 약간 수정하는 것입니다.
장점: 가상 머신 수준에서 완전한 P2P
Type 2 ZK-EVM은 에테르 상태와 같은 것을 보유하는 데이터 구조를 변경합니다. 다행히 이러한 구조는 EVM 자체에서 직접 액세스할 수 없으므로 Ethereum에서 작동하는 애플리케이션은 거의 항상 Type 2 ZK-EVM 롤업에서 작동합니다. Etherum Execution 클라이언트를 있는 그대로 사용할 수는 없지만 약간 수정하여 사용할 수 있으며 여전히 EVM 디버깅 도구 및 대부분의 다른 개발자 인프라에 액세스할 수 있습니다.
그러나 몇 가지 예외가 있습니다. 과거 거래, 영수증 또는 상태에 대한 주장을 확인하기 위해 과거 이더 블록의 Merkle 증명을 확인하는 애플리케이션의 경우 비호환성이 발생합니다(예: 브리지가 때때로 이를 수행함). Keccak의 ZK-EVM을 다른 해시 함수로 교체하면 이러한 증명이 깨집니다. 그러나 향후 이더 변경(예: Verkle Trees)이 이더 자체에서도 그러한 애플리케이션을 손상시킬 수 있으므로 일반적으로 이러한 방식으로 애플리케이션을 구축하지 말라고 조언합니다. Ethereum 자체에 대한 더 나은 대안은 미래의 신뢰할 수 있는 기록 액세스 사전 컴파일을 추가하는 것입니다.
단점: 검증 시간이 개선되었지만 여전히 느림
유형 2 ZK-EVM은 주로 불필요하게 복잡하고 친숙하지 않은 ZK 암호화에 의존하는 이더리움 스택의 일부를 제거하여 유형 1보다 더 빠른 검증 시간을 제공합니다. 특히 Ethereum의 Keccak 및 RLP 기반 Merkle Patricia 트리를 변경하고 구조를 차단 및 수신할 수 있습니다. 유형 2 ZK-EVM은 예를 들어 Poseidon과 같은 다른 해시 함수를 사용할 수 있습니다. 또 다른 자연스러운 수정은 코드 해시와 keccak을 저장하도록 상태 트리를 수정하여 EXTCODEHASH 및 EXTCODECOPY opcode를 처리하는 데 확인 해시가 더 이상 필요하지 않도록 하는 것입니다.
이러한 수정은 검증 시간을 크게 개선하지만 모든 문제를 해결하지는 않습니다. EVM의 고유한 비효율성과 zk 비친화성으로 인해 EVM을 있는 그대로 증명하는 프로세스는 여전히 느립니다. 간단한 예는 메모리입니다. MLOAD는 "정렬되지 않은" 블록(시작과 끝이 32의 배수가 아님)을 포함하여 모든 32바이트 블록을 읽을 수 있기 때문에 MLOAD는 단순히 블록을 읽는 것으로 해석할 수 없습니다. 두 개의 연속 블록을 읽고 비트 연산을 수행하여 결과를 결합합니다.
빌더는 누구입니까?
Scroll의 ZK-EVM 프로젝트는 Polygon Hermez와 마찬가지로 Type 2 ZK-EVM으로 이동하고 있습니다. 즉, 어느 프로젝트도 아직 완료되지 않았으며(ZKEVM 작업이 완료되지 않음) 특히 더 복잡한 많은 사전 컴파일이 아직 구현되지 않았습니다. 따라서 현재 두 프로젝트 모두에 대해 유형 3이 가장 적합합니다.
유형 2.5(EVM과 유사, 가스비 제외)
최악의 경우 검증 시간을 크게 개선하는 한 가지 방법은 EVM에서 증명하기 어려운 특정 작업의 오버헤드 비용을 크게 늘리는 것입니다. 여기에는 사전 컴파일, KECCAK opcode가 포함될 수 있지만 호출 규칙 또는 메모리 액세스, 저장 또는 복원의 특정 모드도 포함될 수 있습니다.
가스 비용을 변경하면 개발자 도구 호환성이 감소하고 일부 응용 프로그램이 중단될 수 있지만 일반적으로 "더 깊은" EVM 변경보다 덜 위험한 것으로 간주됩니다. 개발자는 트랜잭션에서 블록의 용량보다 더 많은 가스를 요구하지 않도록 주의해야 하며, 하드코딩된 가스 수수료 금액으로 호출하지 않도록 주의해야 합니다(이는 오랫동안 개발자에게 일반적인 조언이었습니다).
유형 3(EVM과 거의 동일)
Type 3 ZK-EVM은 EVM과 거의 동일하지만 동일한 결과를 얻으려면 검증 시간을 더욱 개선하고 EVM을 더 쉽게 개발할 수 있도록 약간의 희생이 필요합니다.
장점: 구축하기 쉽고 확인 시간이 빠름
Type 3 ZK-EVM은 ZK-EVM 구현에서 특히 구현하기 어려운 일부 기능을 제거할 수 있습니다. 여기에서 사전 컴파일은 일반적으로 목록의 맨 위에 있으며, 유형 3 ZK-EVM은 때때로 계약 코드, 메모리 또는 스택을 처리하는 방법에 미묘한 차이가 있습니다.
단점: 더 많은 비호환성
Type 3 ZK-EVM은 대부분의 애플리케이션과 호환되는 것을 목표로 하며 나머지는 최소한으로 다시 작성해야 합니다. 즉, Type 3 ZK-EVM이 제거하는 사전 컴파일을 사용하거나 EVM에서 다르게 처리하는 에지 케이스에 대한 미묘한 종속성 때문에 일부 애플리케이션을 다시 작성해야 합니다.
빌더는 누구입니까?
Scroll과 Polygon은 둘 다 현재 형식에서 유형 3이지만 시간이 지남에 따라 호환성이 향상될 것으로 예상됩니다. Polygon은 고유한 디자인을 가지고 있으며 ZK를 사용하여 자체 내부 언어 zkASM을 확인하고 zkASM 구현을 사용하여 ZK-EVM 코드를 해석합니다. 이러한 구현 세부 사항에도 불구하고 저는 여전히 이를 진정한 Type3ZK-EVM이라고 부르며 여전히 EVM 코드를 검증할 수 있고 그렇게 하기 위해 몇 가지 다른 내부 로직을 사용할 뿐입니다.
오늘날 ZK-EVM 팀은 Type 3이 되고 싶어하지 않습니다. 그러나 앞으로는 유형 1 또는 유형 2 ZK-EVM이 개발자에게 낮은 검증 시간 및 가스 비용 기능을 제공하는 새로운 ZK-SNARK 친화적 사전 컴파일러를 추가하여 자발적으로 유형 3 ZK-EVM이 될 수 있습니다.
유형 4(고급 언어와 동일)
유형 4 시스템은 고급 언어(예: SOLIDITY, VYPER 또는 둘 다 컴파일되는 일부 중간 언어)로 작성된 스마트 계약 소스 코드를 ZK-snark 친화적인 언어로 명시적으로 설계된 일종의 언어로 컴파일하여 작동합니다.
장점: 확인 시간이 매우 빠름
ZK를 사용하여 각 EVM 실행 단계의 모든 다른 부분을 증명하지 않고 더 높은 수준의 코드에서 직접 시작함으로써 많은 오버헤드를 피할 수 있습니다.
이 게시물에서 이 장점을 한 문장으로 설명했지만(아래의 호환성 관련 단점에 대한 큰 글머리 기호 목록과 비교하여) 이것이 가치 판단으로 해석되어서는 안 됩니다! 고급 언어에서 직접 컴파일하면 실제로 비용을 크게 절감하고 쉽게 증명할 수 있으므로 탈중앙화에 도움이 됩니다.
단점: 더 많은 비호환성
Vyper 또는 Solidity로 작성된 "정상적인" 애플리케이션은 컴파일할 수 있으며 "정상적으로 작동"하지만 많은 애플리케이션에서 "정상적으로 작동"하지 않는 몇 가지 중요한 측면이 있습니다.
유형 4 시스템의 계약 주소는 EVM의 주소와 다를 수 있습니다. CREATE2 계약 주소는 정확한 바이트코드에 의존하기 때문입니다. 이로 인해 "대리 사실 계약", ERC-4337 지갑, EIP-2470 싱글톤 및 아직 배포되지 않은 기타 많은 응용 프로그램에 의존하는 응용 프로그램이 중단됩니다.
손으로 쓴 EVM 바이트코드는 작업하기가 더 어렵습니다. 효율성을 위해 많은 애플리케이션은 일부 부분에 손으로 쓴 EVM 바이트코드를 사용합니다. Type 4 시스템은 이를 지원하지 않을 수 있지만 완전한 Type3 ZK-EVM이 되기 위해 노력하지 않고도 이러한 사용 사례를 충족하기 위해 제한된 EVM 바이트코드 지원을 구현하는 방법이 있습니다.
디버깅 인프라의 대부분은 EVM 바이트코드에서 실행되기 때문에 계속할 수 없습니다. 즉, 이 단점은 "전통적인" 고급 또는 중간 언어(예: LLVM)에서 디버깅 인프라에 더 많이 액세스함으로써 완화됩니다.
개발자는 이러한 문제를 알고 있어야 합니다.
빌더는 누구입니까?
ZKSync는 유형 4 시스템이지만 시간이 지남에 따라 EVM 바이트코드와의 호환성이 향상될 수 있습니다. NetherMind의 Warp 프로젝트는 Solidity에서 Starkware까지 Cairo 컴파일러를 구축하고 있으며, 이는 StarkNet을 사실상 Type 4 시스템으로 전환할 것입니다.
여러 유형의 ZK-EVM의 미래
이러한 유형은 명시적으로 다른 유형보다 "좋거나" "나쁘지" 않습니다. 오히려 그들은 트레이드 오프 공간의 차이점입니다: 코딩하기가 덜 어려운 유형은 기존 인프라와 더 호환되지만 더 느립니다. 코딩하기 더 어려운 유형은 기존 인프라와 덜 호환되지만 더 빠릅니다. 전반적으로 이러한 모든 유형의 사람들이 탐구하고 있으며 이는 현장에 건강합니다.
ZK-EVM은 ZK-증명하기 특히 어려운 일부 기능을 포함하지 않기로 결정하면서 유형 3으로 시작할 수 있습니다. 나중에 시간이 지남에 따라 이러한 기능을 추가하고 유형 2로 이동할 수 있습니다.
ZK-EVM은 유형 2로 시작한 다음 전체 이더넷 호환 모드에서 실행하거나 더 빠르게 입증될 수 있는 수정된 상태 트리를 사용할 수 있는 가능성을 제공하여 하이브리드 유형 2/유형 1 ZK-EVM이 될 수 있습니다. Sroll은 이 방향으로 움직이는 것을 고려하고 있습니다.
Type 4로 시작하는 시스템은 나중에 EVM 코드를 처리하는 기능이 추가됨에 따라 시간이 지남에 따라 Type 3이 될 수 있습니다(개발자는 여전히 비용 및 검증 시간을 줄이기 위해 고급 언어에서 직접 컴파일하도록 권장됨).
개인적으로 ZK-EVM을 개선하고 Ethereum 자체를 개선하여 ZK-Snark에 더 적합하도록 시간이 지남에 따라 모든 것이 Type 1이 되기를 바랍니다. 그러한 미래에 우리는 ZK 롤업과 이더리움 자체 검증을 위해 여러 ZK-EVM 구현을 갖게 될 것입니다. 이론적으로 이더리움은 L1에서 사용하는 단일 ZK-EVM 구현으로 표준화할 필요가 없습니다. 클라이언트마다 서로 다른 증명을 사용할 수 있으므로 코드 중복의 이점을 계속 누릴 수 있습니다.
