V-신들은 미래의 진화 트리를 곧바로 그려냈습니다.
리사 악셀로드 작성
0xAyA 편집
편집자 주: 이 글은 Vitalik의 이전 ZK-EVM 소개를 바탕으로 작성되었으며, 다양한 유형의 ZK-EVM과 이들 간의 차이점에 대해 자세히 설명했습니다.
약 1년 전, 한 ZK-EVM 그룹이 곧 테스트 네트워크를 출시할 예정이라고 발표했습니다. 이러한 움직임은 이더리움 커뮤니티의 호기심을 자극했고, 이더리움 동등성과 EVM 동등성이라는 용어 뒤에 숨겨진 뉘앙스에 대한 토론을 촉발시켰습니다.
명확성을 위해 비탈릭은 다양한 ZK-EVM을 네 가지 유형으로 분류하고 그 차이점을 설명하는 ' 다양한 유형의 ZK-EVM '이라는 제목의 중요한 글을 저술했습니다.
핵심 아이디어는 유형 1(예: Taiko)은 이더넷과 완전히 동등한 반면, 유형 4(예: zkSync)는 효율적인 증명 생성에 탁월하다는 것입니다. 다른 모든 유형인 유형 2, 유형 2.5, 유형 3은 그 중간 정도에 속합니다(예: Polygon zkEVM, Scroll, Linea).
대부분의 ZK-EVM은 처음에는 유형 2.5와 유형 3이며, 유형 1 또는 유형 2로 전환하려는 의사를 밝히지만, 이러한 프로젝트는 구체적인 일정이나 약속을 제공하지는 않습니다.
이 글에서는 타입 1과 타입 2/타입 2.5의 차이점에 초점을 맞추고, 이더넷 동등성을 깨뜨렸을 때 발생할 수 있는 결과에 대해 설명합니다. 다른 유형에 대해서도 간략하게 설명합니다.
ZK-EVM의 주요 목표는 이더의 확장, 즉 이더의 다른 기능(보안, 개발자 경험 등)을 유지하면서 이더의 처리량을 늘리는 것입니다. 이상적으로 ZK-EVM은 다음을 수행할 수 있어야 합니다:
옐로우북의 이더넷 가상 머신 사양에 따라 수정되지 않은 네이티브 바이트코드의 실행을 증명합니다(이더넷 옵코드를 100% 커버).
저렴한 비용으로 신속하게 증명을 생성할 수 있습니다.
이더넷용으로 개발된 도구와 인프라를 100% 재사용할 수 있습니다.
모든 이더넷 dApp을 "있는 그대로"("있는 그대로"는 변경 없이, 성능 저하 없이) ZK-EVM에 재배포할 수 있습니다.
ZK-EVM 유형 간의 차이점
ZK-EVM 공간에서 차이점은 주로 이더넷/EVM 동등성 수준, 증명 생성 비용과 속도에 대한 ZK 비우호적 요소의 영향, 회로 구현의 복잡성(예: VM 구성 또는 상태 트리)에서 비롯됩니다.
특히 유형 1과 유형 2/Type 2.5를 구분하여 이러한 차이점을 분석해 보겠습니다. 또한 각 유형과 가장 관련성이 높은 사용 사례도 다뤄보겠습니다.
다양한 유형을 비교할 때는 아래 차트를 사용하는 것이 일반적입니다:
ZK-EVM 분야에서 풀타임으로 일하지 않는 분들에게는 이 차트가 혼란스러워 보일 수 있으므로 용어를 일반인이 이해하기 쉬운 용어로 번역하여 다시 한 번 살펴봅시다:
이 차트는 각 유형이 실제로 무엇인지에 대한 명확한 그림을 제공하지만, 여전히 약간 모호할 수 있으므로 각 유형을 개별적으로 설명하여 ZK-EVM 공간을 전체적으로 살펴 보겠습니다.
유형 1: 이더 등가성
비탈릭 부테린:
"타입 1 ZK-EVM은 궁극적으로 Ether 레이어 1 자체의 확장성을 높이기 위해 필요한 것입니다."
타입 1은 증명을 더 쉽게 생성할 수 있도록 Ether 시스템의 어떤 부분도 변경하지 않는 것을 의미합니다. 대부분의 암호화 기본 요소(예: 해시 함수), 개발자 인프라(예: 디버거), 체인 인프라(예: 실행 클라이언트)는 9년 동안 전투 테스트를 거쳤기 때문에 이더를 변경하지 않는다는 것은 보안에 대한 타협이 없다는 것을 의미합니다.
타입 1 ZK-EVM은 해시, 상태 트리, 트랜잭션 트리, 사전 컴파일 또는 기타 합의 로직 등 그 어떤 것도 대체하지 않으며, 모든 것이 메인넷의 EVM과 동일합니다.
유형 1은 전체 블록부터 트랜잭션 실행, 스마트 컨트랙트 및 계정 로직에 이르기까지 이더리움 체인 자체를 검증하는 유일한 유형입니다.
유형 2: EVM과 동일
유형 2는 ZK에 해로운 일부 부분을 제거하여 더 빠르게 증명을 생성하고 회로를 더 쉽게 개발할 수 있습니다. 그러나 그 결과 ZK 롤업의 다른 부분(예: 노드 소프트웨어)의 개발이 더 복잡해질 수 있습니다. 이러한 복잡성은 기존 모범 사례 및 테스트 도구와 구현된 변경 사항(예: 변경된 상태 트리)의 비호환성으로 인해 발생할 수 있습니다.
참고: 이더넷과 동등하다는 것은 EVM과 동등하다는 것과 동일하지 않습니다. 이더넷과 동등하다는 것은 이더넷의 어떤 부분도 변경되지 않아 모든 이더넷 dApp과 완벽하게 호환된다는 것을 의미하지만, EVM과 동등하다는 것은 데이터 구조(예: 블록 구조 또는 상태 트리)를 변경할 수 있다는 것을 의미합니다.
이러한 조정은 사소해 보일 수 있지만 이더리움 호환성에 영향을 미칠 수 있습니다. 데이터 구조를 변경하면 특히 과거 트랜잭션, 영수증 또는 상태(예: 크로스체인 브리지 )에 대한 머클 증명을 검증할 때 이더 dApp이 유형 2 ZK-EVM과 호환되지 않을 수 있습니다.
ZK 비우호적인 요소 제거
이더리움의 변경은 개발을 간소화하고 증명 생성 속도를 높이기 위한 것입니다. 목표는 이더리움에서 비우호적인 영지식 암호에 의존하는 부분을 제거하는 것입니다. 좀 더 기술적으로 설명하자면, 비로컬 도메인(예: 해시 함수)으로 인해 많은 게이트 회로(덧셈 및 곱셈 연산)가 필요한 부분, 많은 다중 스칼라 곱셈 및/또는 고속 푸리에 변환(FFT)이 필요한 부분, 또는 많은 연산이 필요한 부분 등이 이에 해당합니다.
유형 2 ZK-EVM이 수정할 수 있는 비우호적인 영지식 요소의 구체적인 예는 다음과 같습니다:
해시 함수: 이더넷은 Keccak 해시 함수를 사용하는 반면, 많은 ZK-EVM은 훨씬 적은 수의 게이트를 필요로 하는 포세이돈 해시 함수를 사용합니다. 예를 들어, 각 유형의 해시 함수가 초당 몇 개를 계산할 수 있는지 추정해 보겠습니다(즉, 증명 생성 속도 비교).
포세이돈 해시 함수는 증명 생성 속도에서 상당한 이점을 가지고 있습니다.
그러나 새로운 암호화 프리미티브가 더 넓은 커뮤니티에서 인정받는 기존 암호화 프리미티브보다 선호되는 것은 아니라는 점에 유의해야 합니다. 포세이돈은 속도를 제공할 수 있지만, 실전에서 검증된 케칵의 특성은 널리 채택된 만큼 더 견고하고 안전합니다.
그렇기 때문에 보안 시스템이나 스마트 기기의 센서와 같은 다른 산업에서 더 오래되고 더 넓은 커뮤니티에서 채택되었음에도 불구하고, 결국 ZK 커뮤니티 내에서 만들어지고 사용되는 새로운 해시 함수인 포세이돈보다 더 많은 전투 테스트를 거친 것으로 간주할 수 있습니다.
데이터 저장을 위한 상태 트리: 예를 들어, 이더넷은 머클 패트리샤 트리(Keccak 해시 사용)를 사용하는 반면, 일부 타입 2 ZK-EVM은 스파스 머클 트리(포세이돈 해시 사용)를 선택합니다. 상태 트리를 변경하면 일부 비호환성이 발생할 수 있습니다. 예를 들어, 이더넷의 머클 트리는 노드 유형이 다르며 데이터를 인코딩하는 데 RLP를 사용하는데, 이는 ZK에서는 어렵습니다.
블록 구조: 블록에는 많은 정보가 포함되어 있습니다. 그러나 L2를 탐색할 때는 실행_페이로드_헤더(즉, 블록 해시)에만 관심을 갖습니다. 아래 그림에는 execution_payload_header에 포함된 모든 데이터의 구조(블록 해시)가 나와 있습니다.
참고: 이러한 구성 요소 중 하나를 변경하면 이더넷 등가성이 깨집니다.
유형 2.5: 가스 비용을 고려한 EVM과 동등함
유형 2.5 ZK-EVM은 EVM에서 ZK 기술을 사용하는 것을 정당화하기 어려운 특정 작업의 가스 비용을 증가시킵니다.
이더넷의 블록당 가스 제한(30M 가스)을 고려할 때, 옵코드당 가스 비용이 증가하면 블록당 옵코드 수가 줄어듭니다. 결과적으로 한 블록에 더 적은 수의 복잡한 옵코드를 포함할 수 있습니다. 더 단순한 옵코드는 회로를 더 작게 만들고 증명을 더 빠르게 생성합니다.
가스는 워크로드를 측정하는 단위입니다.
옵코드의 가격은 가스 단위로 측정됩니다.
연산 코드는 기계어 명령어로 연산을 지정합니다.
프로그램은 옵코드의 정적 목록입니다. 프로그램 실행은 실행 추적입니다.
실행 추적은 프로그램 실행을 위한 특정 순서로 정렬된 옵코드 목록입니다.
ZK를 증명하기 어려운 부분은 다음과 같습니다:
케칵 연산자와 케칵에 의존하는 일부 다른 연산자.
사전 컴파일된 함수: EVM에서 액세스할 수 있는 함수. 이 중 일부는 암호화 함수(예: blake 2 f 또는 sha 256)와 같이 복잡하거나 수학적으로 정교한 작업을 제공합니다. 이러한 함수는 EVM 내에서 실행되는 것이 아니라 실행 중인 클라이언트에서 하드코딩된 함수로 특수 주소에 대한 호출을 사용하여 EVM에 노출됩니다.
메모리 액세스: 예를 들어 메모리 슬롯 크기 증가(예: 이더넷은 바이트 정렬 메모리를 사용하는 반면 Polygon zkEVM은 32바이트 메모리 슬롯 사용). 이러한 변경을 가능하게 하려면 특정 옵코드(예: MLOAD)의 내부 로직을 변경해야 합니다.
저장소(즉, 위에서 설명한 대로 해시 함수 또는 상태 트리 변경)를 변경해야 합니다.
가스 비용을 변경하면 개발자 도구의 호환성이 떨어지고 일부 디앱이 중단될 수 있습니다. 예를 들어, 가스 비용이 증가한 코드를 일상적으로 실행하는 스마트 콘트랙트는 블록 가스 한도를 초과하여 실행에 실패할 수 있습니다.
유형 3: EVM과 거의 동일
유형 3 ZK-EVM은 ZK에 적용되지 않는 사전 컴파일을 생략하고 메모리와 스토리지 액세스를 조정할 수 있습니다.
삭제된 사전 컴파일에 의존하는 dApp은 다시 작성해야 합니다. 드문 경우지만, 타입 3 ZK-EVM과 기존 EVM이 에지 케이스를 처리하는 방식에 차이가 있어 dApp을 조정해야 할 수도 있습니다.
유형 4(고수준 언어와 동등한 수준)
유형 4는 EVM과는 거리가 먼 방식입니다.
하이레벨 언어(예: 솔리디티, 징크)로 작성된 스마트 컨트랙트 소스 코드를 중간 표현으로 컴파일하여 ZK 친화적인 가상 머신을 위한 연산 코드를 생성합니다.
이 접근 방식은 각 EVM 실행 단계마다 ZK 증명을 생성할 필요가 없으므로 증명 노력을 크게 줄일 수 있습니다.
컨트랙트를 컴파일할 수 있더라도, 디앱이 EVM 수기 바이트코드를 사용하는 경우 추가 작업이 필요합니다.
또한 타입 4 ZK-EVM은 디버거와 트레이서와 같은 자체 개발자 도구(옵코드 수준에서만)가 필요합니다.
실행 추적을 증명하는 ZK 회로에서는 각 단계에서 제약 조건이 구현되며, 각 단계의 비용은 모든 옵코드의 합입니다. 따라서 타입 4 ZK-EVM은 가능한 한 적은 수의 복잡한 옵코드를 사용하여 효율성을 최적화하는 것을 목표로 합니다.
사용자 지정 옵코드(Ether에서 다루지 않는 옵코드)를 사용하면 기본적으로 Ether에서는 불가능한 새로운 기능을 전달할 수 있다는 점을 언급할 가치가 있습니다. 예를 들어, 계정 추상화 기능을 통한 다중 호출 실행이나 Argent와 같은 즉시 사용 가능한 솔루션을 사용해 스마트 콘트랙트 지갑을 실행할 수 있습니다.
요약
유형에 따라 목표와 기능의 우선순위가 다릅니다. 유형 1은 이더리움 동등성에 초점을 맞추고, 유형 4는 효율적인 증명 생성을 우선시합니다. 다른 유형은 이 두 가지 극단 사이에 속하며, 많은 유형 2와 3 ZK-EVM 프로토콜이 이더리움 동등성으로 전환할 의사를 밝혔습니다.
이 네 가지 유형의 분류는 ZK 통합의 최종 상태가 아닐 수 있으며, 향후 추가 수정이 이루어질 수 있습니다. 예를 들어, 일부 ZK-EVM은 하이브리드가 될 수 있고, 1/2 유형은 유형 4 솔루션을 개발하여 (최대한 효율성이 높은) dApp을 위한 두 가지 옵션을 제공할 수 있으며, 유형 3과 4 ZK-EVM은 이더넷과 동등한 옵션을 추가할 수 있습니다.
