원저자 -Lisa Akselrod

컴파일 - Odaily 0xAyA

편집자 주: 저자는 이전에 Vitalik이 작성한 ZK-EVM 소개 기사를 기반으로 정리했으며, ZK-EVM의 다양한 유형과 차이점을 자세히 소개했습니다.

약 1년 전, ZK-EVM 그룹은 다가오는 테스트넷 출시를 발표했습니다. 이러한 움직임은 이더리움 커뮤니티의 호기심을 불러일으켰고 이더리움 동등성 및 EVM 동등성과 같은 용어 뒤에 숨은 뉘앙스에 대한 토론을 촉발시켰습니다.

명확히 하기 위해 Vitalik은 다음과 같은 중요한 기사를 썼습니다.다양한 유형의 ZK-EVM, 다양한 ZK-EVM을 4가지 유형으로 분류하고 차이점을 설명합니다.

핵심 아이디어는 다음과 같습니다. 유형 1(예: Taiko)은 Ethereum과 완전히 동일하지만 유형 4(예: zkSync)는 효율적인 증명 생성에 탁월합니다. 다른 모든 유형, 유형 2, 유형 2.5 및 유형 3은 그 사이에 있습니다(예: Polygon zkEVM, Scroll, Linea).

대부분의 ZK-EVM은 초기에 Type 2.5 및 Type 3이며, Type 1 또는 Type 2로 전환하려는 의도가 일부 밝혀졌습니다. 그러나 이러한 프로젝트는 이에 대한 구체적인 일정이나 약속을 제공하지 않았습니다.

이 기사는 유형 1과 유형 2/유형 2.5의 차이점에 초점을 맞추고 이더리움 동등성을 위반할 때 발생할 수 있는 결과를 설명합니다. 다른 유형에 대해서도 간략하게 살펴보겠습니다.

ZK-EVM의 주요 목표는 이더리움을 확장하는 것입니다. 즉, 이더리움의 다른 기능(보안, 개발자 경험 등)을 유지하면서 이더리움의 처리량을 늘리는 것입니다. 이상적으로 ZK-EVM은 다음을 수행할 수 있어야 합니다.

• Yellow Book의 Ethereum Virtual Machine 사양에 따라 수정되지 않은 기본 바이트코드(Ethereum opcode의 100% 포함) 실행이 입증되었습니다.

• 빠르고 저렴하게 증거를 생성하세요.

• Ethereum용으로 개발된 도구와 인프라를 100% 재사용할 수 있습니다.

• 모든 이더리움 dApp을 ZK-EVM에 있는 그대로 재배포할 수 있습니다(있는 그대로는 변경이 필요하지 않고 타협도 없음을 의미함).

ZK-EVM 유형 간의 차이점

ZK-EVM 공간에서 차이점은 주로 이더리움/EVM 동등성 수준, ZK에 비우호적인 요소가 증명 생성 비용 및 속도에 미치는 영향, 회로 구현의 복잡성(예: VM 구성 또는 상태 트리)에서 발생합니다. .

이러한 차이점을 분석하고 특히 유형 1과 유형 2/유형 2.5를 구별해 보겠습니다. 또한 각 유형과 가장 관련된 사용 사례도 살펴보겠습니다.

다양한 유형을 비교할 때 다음 차트가 자주 사용됩니다.

ZK-EVM 분야에서 풀타임으로 일하지 않는 사람들에게는 이 표가 혼란스러워 보일 수 있으므로 이 용어를 일반인의 용어로 번역하여 살펴보겠습니다.

이 다이어그램은 각 유형이 실제로 어떻게 보이는지에 대한 더 명확한 그림을 제공하지만 여전히 약간 모호할 수 있으므로 각 유형을 개별적으로 설명하여 ZK-EVM의 세계를 완전히 탐색해 보겠습니다.

유형 1: 이더리움과 동일

Vitalik Buterin：

“Type 1 ZK-EVM은 궁극적으로 Ethereum Layer 1 자체를 더욱 확장 가능하게 만드는 데 필요한 것입니다.”

유형 1은 증명을 더 쉽게 생성할 수 있도록 이더리움 시스템의 어떤 부분도 변경하지 않음을 의미합니다. 대부분의 암호화 기본 요소(예: 해시 함수), 개발자 인프라(예: 디버거) 또는 체인 인프라(예: 실행 클라이언트)가 이미 9년간의 현장 테스트를 거쳤기 때문에 이더리움에 대한 변경 사항이 없다는 것은 보안에 대한 타협이 없음을 의미합니다.

유형 1 ZK-EVM은 해시, 상태 트리, 트랜잭션 트리, 사전 컴파일 또는 기타 합의 논리 등 아무것도 대체하지 않으며 모든 것이 메인넷의 EVM과 동일합니다.

• 유형 1은 전체 블록부터 거래 실행, 스마트 계약 및 계정 논리까지 이더리움 체인 자체를 확인할 수 있는 유일한 유형입니다.

유형 2: EVM과 동일

유형 2는 ZK에 도움이 되지 않는 일부 부품을 제거하여 증명 생성을 더 빠르게 하고 회로 개발을 더 쉽게 만듭니다. 그러나 이로 인해 ZK 롤업의 다른 부분(예: 노드 소프트웨어)의 개발이 더욱 복잡해질 수 있습니다. 이러한 복잡성은 확립된 모범 사례와 테스트 도구 및 구현 중인 변경 사항(예: 변경된 상태 트리) 간의 비호환성으로 인해 발생할 수 있습니다.

참고: Ethereum과 동등한 것과 EVM과 동등한 것은 동일하지 않습니다. 이더리움과 동등하다는 것은 이더리움의 어떤 부분도 변경되지 않았음을 의미하지만, 즉 모든 이더리움 dApp과 완벽하게 호환된다는 의미이지만, EVM과 동등하다는 것은 데이터 구조(예: 블록 구조 또는 상태 트리)의 변경을 허용한다는 것을 의미합니다.

이러한 조정은 사소해 보일 수 있지만 Ethereum의 호환성에 영향을 미칩니다. 데이터 구조를 변경하면 이더리움 dApp이 유형 2 ZK-EVM과 호환되지 않을 수 있습니다. 특히 과거 거래, 영수증 또는 상태(예: 크로스체인 브리지)에 대한 Merkle 증명을 검증할 때 더욱 그렇습니다.

ZK 비우호적 요소 제거

이더리움에 대한 수정은 개발을 단순화하고 증명 생성 속도를 높이기 위한 것입니다. 목표는 비우호적인 영지식 암호화에 의존하는 이더리움의 일부를 잘라내는 것입니다. 보다 기술적인 용어로 말하면, 비로컬 도메인(예: 해시 함수)으로 인해 많은 수의 게이트(덧셈 및 곱셈 연산)가 필요한 부분, 다수의 다중 스칼라 곱셈 및/또는 고속 푸리에 변환(FFT), 또는 조작이 많이 필요한 부분.

유형 2 ZK-EVM이 수정할 수 있는 비우호적 영지식 요소의 구체적인 예는 다음과 같습니다.

• 해시 함수: Ethereum은 Keccak 해시 함수를 사용하는 반면, 많은 ZK-EVM은 훨씬 적은 수의 게이트가 필요한 Poseidon 해시 함수를 사용합니다. 예를 들어 각 유형의 해시 함수가 초당 몇 개나 계산될 수 있는지 추정해 보겠습니다(즉, 생성 속도를 보여주는 비교).

포세이돈 해시 함수는 증명 생성에서 상당한 속도 이점을 제공합니다.

그러나 최신 암호화 기본 요소는 커뮤니티에서 널리 인식되는 기존 암호화 기본 요소에 비해 인기가 없다는 점에 유의하는 것이 중요합니다. 포세이돈은 속도를 제공할 수 있지만 Keccak의 전투 테스트를 거친 속성은 더 널리 채택될수록 더욱 강력하고 안전해집니다.

이것이 바로 Keccak이 더 오래되고 더 넓은 커뮤니티(스마트 장치의 보안 시스템 또는 센서와 같은 다른 산업)에서 채택되었음에도 불구하고 결국 ZK 커뮤니티 내에 있는 Poseidon보다 더 시도되고 테스트된 것으로 간주될 수 있는 이유입니다. 생성하고 사용하는 기능입니다.

• 데이터 저장을 위한 상태 트리: 예를 들어 Ethereum은머클 패트리샤 나무(Keccak 해시 사용), 일부 유형 2 ZK-EVM 옵션희소 머클 트리(포세이돈 해싱 사용). 상태 트리를 변경하면 일부 비호환성이 발생할 수 있습니다. 예를 들어 이더리움의 머클 트리는 노드 유형이 다르며 RLP를 사용하여 데이터를 인코딩하는데 이는 ZK에서는 어려운 일입니다.

• 블록 구조: 블록에는 많은 양의 정보가 포함되어 있습니다. 그러나 L2를 탐색할 때 우리는 Execution_payload_header(즉, 블록 해시)에만 관심을 갖습니다. 아래 이미지에는 Execution_payload_header에 포함된 모든 데이터의 구조(블록 해시)가 있습니다.

참고: 이러한 구성 요소를 변경하면 Ethereum 동등성이 손상됩니다.

유형 2.5: 가스 비용을 고려하면 EVM과 동일합니다.

Type 2.5 ZK-EVM은 EVM에서 ZK 기술을 사용하여 입증하기 어려운 특정 작업의 가스 비용을 증가시킵니다.

이더리움의 블록당 가스 한도(30M 가스)를 고려하면 opcode당 가스 비용을 늘리면 블록당 opcode 수가 줄어듭니다. 따라서 덜 복잡한 opcode가 블록에 포함될 수 있습니다. 더 간단한 opcode를 사용하면 회로가 더 작아지고 증명이 더 빠르게 생성될 수 있습니다.

• 가스는 일의 측정 단위입니다.

• Opcode 가격은 가스로 계산됩니다.

• Opcode는 기계어 명령어 내의 작업을 지정합니다.

• 프로그램은 opcode의 정적 목록입니다. 프로그램 실행은 실행 추적입니다.

• 실행 추적은 프로그램에 의해 실행되는 특정 순서의 opcode 목록입니다.

ZK를 증명하기 어려운 부분은 다음과 같습니다.

• Keccak opcode 및 Keccak에 의존하는 기타 opcode.

• 사전 컴파일됨: EVM에 액세스할 수 있는 함수입니다. 그 중 일부는 암호화 기능(예: blake 2 f 또는 sha 256)과 같은 복잡하거나 수학적으로 복잡한 작업을 제공합니다. EVM 내에서 실행되는 것이 아니라 실행 클라이언트에 하드 코딩된 함수로 실행되고 특수 주소에 대한 CALL을 사용하여 EVM에 노출됩니다.

• 메모리 액세스: 예: 메모리 슬롯 크기 증가(예: Ethereum은바이트 정렬반면 Polygon zkEVM은 32바이트 메모리 슬롯을 사용합니다. 이러한 변경을 가능하게 하려면 특정 opcode(예: MLOAD)의 내부 논리를 변경해야 했습니다.

• 저장(즉, 위에서 설명한 대로 해시 함수 또는 상태 트리 변경)

가스 비용을 변경하면 개발자 도구의 호환성이 저하되고 일부 dApp이 중단될 수 있습니다. 예를 들어, 가스 비용이 증가하면서 opcode를 자주 실행하는 스마트 계약은 블록 가스 한도를 초과하여 실행에 실패할 수 있습니다.

유형 3: EVM과 거의 동일

유형 3 ZK-EVM은 ZK에 적용되지 않는 사전 컴파일을 생략하고 메모리 및 스토리지 액세스를 조정할 수 있습니다.

제거된 사전 컴파일된 앱에 의존하는 dApp은 다시 작성해야 합니다. 특이한 경우, Type 3 ZK-EVM과 원래 EVM이 엣지 케이스를 처리하는 방식의 차이로 인해 dApp에 대한 조정이 필요할 수 있습니다.

유형 4(고급 언어와 동일)

유형 4는 이미 EVM과 거리가 멀습니다.

고급 언어(예: Solidity, Zinc)로 작성된 스마트 계약 소스 코드는 중간 표현으로 컴파일되어 ZK 친화적인 가상 머신에 적합한 opcode를 생성합니다.

• 이 접근 방식은 각 EVM 실행 단계에 대해 ZK 증명 생성을 방지하므로 증명 노력이 크게 줄어듭니다.

• 계약을 컴파일할 수 있더라도 dApp이 EVM 손으로 작성한 바이트코드를 사용하는 경우 추가 작업이 필요합니다.

• 유형 4 ZK-EVM에는 디버거 및 추적기와 같은 자체 개발자 도구(opcode 수준만 해당)도 필요합니다.

실행 궤적을 증명하는 ZK 회로에서 각 단계는 제약 조건을 구현하며 각 단계의 비용은 모든 opcode의 합계입니다. 따라서 Type 4 ZK-EVM은 효율성을 최적화하기 위해 복잡한 opcode를 최대한 적게 사용하도록 설계되었습니다.

사용자 정의 opcode(Ethereum에서 다루지 않는 opcode)를 사용하면 기본적으로 Ethereum에서는 불가능한 새로운 기능을 전달할 수 있다는 점을 언급할 가치가 있습니다. 예를 들어, 계정 추상화 기능을 통해 실행을 여러 번 호출하거나 Argent와 같은 기본 솔루션을 사용하여 스마트 계약 지갑을 시작하세요.

요약하다

다양한 ZK-EVM 유형은 다양한 목표와 특성의 우선순위를 정합니다. 유형 1은 이더리움 동등성에 중점을 두고, 유형 4는 효율적인 증명 생성을 우선시합니다. 다른 유형은 이러한 극단 사이에 속하며 많은 유형 2 및 3 ZK-EVM 프로토콜은 Ethereum과 동등한 것으로 전환하려는 의도를 발표했습니다.

이 네 가지 유형의 분류는 ZK 롤업의 최종 상태가 아닐 수 있으며 향후 추가 수정이 적용될 수 있습니다. 예를 들어, 일부 ZK-EVM은 하이브리드가 될 수 있고, 유형 1/2는 유형 4 솔루션(가능한 최고 효율성)을 개발하고 dApp에 두 가지 옵션을 모두 제공할 수 있으며, 유형 3 및 4 ZK-EVM은 이더리움에 상응하는 옵션을 추가할 수 있습니다.