작성: cookies

번역: TechFlow

당신은 ZK-EVM을 정말로 알고 있는가?

본문은 ZK-EVM의 5가지 유형에 대해 자세히 다루며, 각각 고유한 아키텍처와 장점, 단점 및 가능한 해결책을 제시한다.

또한 실제 프로젝트 사례를 들어 독자들이 이러한 유형들이 실제 적용에서 어떻게 작동하는지를 더 잘 이해할 수 있도록 한다. 블록체인 개발자이든, 블록체인 기술에 관심 있는 독자이든, 이 글은 깊이 있고 간결한 통찰을 제공할 것이다.

그러면 ZK-EVM의 유형과 그 장단점을 살펴보자.

1. 유형 1: 완전히 이더리움과 동일;

2. 유형 2: 완전히 EVM과 동일;

3. 유형 2.5: 부분적으로 EVM과 동일;

4. 유형 3: 거의 EVM과 동일;

5. 유형 4: 고급 언어 수준에서 동일.

유형 1 | 완전히 이더리움과 동일

아키텍처: 이더리움과 완전히 동일하며, 시스템의 어떤 부분도 변경하지 않음.

유형 1 | 장점

완벽한 호환성:

· 이더리움 블록을 검증할 수 있음;

· 이더리움 L1의 확장성을 높이는 데 기여함;

· 인프라를 많이 재사용할 수 있으므로 롤업(Rollups)에 적합함.

유형 1 | 단점

완벽한 호환성:

· 이더리움은 처음부터 ZK 기능을 위해 설계된 것이 아님;

· 이더리움의 많은 구성 요소는 ZK 증명(ZKP) 생성을 위해 상당한 계산량이 필요함;

· 이더리움 블록의 증명 생성에는 몇 시간이 소요됨.

문제 해결 방안:

· 증명자(prover)의 대규모 병렬화;

· ZK-SNARK 전용 하드웨어(ASIC).

유형 2 | 완전히 EVM과 동일

아키텍처:

· 데이터 구조(블록 구조 및 상태 트리)가 이더리움과 현저히 다름;

· 기존 애플리케이션과 완전한 호환성 유지;

· 증명 생성을 더 쉽게 하고 더 빠르게 만들기 위해 이더리움에 미세한 수정을 가함.

유형 2 | 장점

· 유형 1보다 더 빠른 증명 시간 제공;

· EVM이 직접 접근하지 않는 데이터 구조;

· 이더리움에서 실행되는 애플리케이션: 대부분 유형 2에서도 실행 가능;

· 기존 EVM 디버깅 도구 및 기타 개발 인프라 지원.

유형 2 | 단점

단점을 이해하기 전에 먼저 'Keccak'이 무엇인지 알아야 함:

· 이더리움 블록체인의 해시 알고리즘;

· 이더리움 상의 데이터 보호에 사용됨;

· 정보가 해시로 변환되도록 보장함.

유형 2는 과거 거래, 영수증/상태와 관련된 과거 블록의 Merkle 증명을 검증하는 애플리케이션과 호환되지 않음. 해시 알고리즘이 변경되면(Keccak이 아니게 되면) 증명이 무효화되기 때문임.

Keccak을 Merkle 증명(문자)을 사용하는 일종의 언어로 생각할 수 있음. 만약 ZK-EVM이 Keccak을 다른 해시 알고리즘(예: Poseidon)으로 교체하면, Merkle 증명은 낯설게 되고 애플리케이션은 이를 읽고 검증할 수 없게 됨.

단점에 대한 잠재적 해결책: 이더리움이 미래 확장을 위한 과거 기록 접근 전처리 기능(precompiles)을 추가할 수 있음.

유형 2 프로젝트

· Scroll;

· Polygon Hermez.

그러나 이 프로젝트들은 아직 더 복잡한 전처리 기능을 구현하지 못했으므로, 불완전한 유형 2라고 간주될 수 있음.

유형 2.5 | 부분적으로 EVM과 동일

아키텍처:

· ZK 증명이 어려운 특정 EVM 작업의 가스 비용을 증가시킴;

· 전처리 기능;

· Keccak 오퍼코드;

· 스마트 계약 호출 패턴;

· 메모리 접근;

· 스토리지.

유형 2.5 | 장점

· 최악의 경우 증명 시간을 크게 단축시킴;

· EVM 스택에 더 깊은 수준의 변경을 가하는 것보다 더 안전함.

유형 2.5 | 단점

· 개발 도구와의 호환성 감소;

· 일부 애플리케이션이 작동하지 않을 수 있음.

유형 3 | 거의 EVM과 동일

아키텍처:

· ZK-EVM 구현에서 구현하기 매우 어려운 일부 기능(대개 전처리 기능)을 삭제함;

· ZK-EVM이 스마트 계약 코드, 메모리 또는 스택 처리 방식에 약간의 차이를 가짐.

유형 3 | 장점

· 검증 시간 단축;

· EVM 개발을 더 쉽게 만듦;

· 비교적 호환되지 않는 애플리케이션에 대해 최소한의 재작성이 필요하도록 목표 설정.

유형 3 | 단점

· 더 많은 호환성 문제 발생;

· 유형 3에서 제거된 전처리 기능을 사용하는 애플리케이션은 재작성이 필요함.

유형 3 | 프로젝트

현재 Scroll과 Polygon은 유형 3으로 간주되지만, ZK-EVM 팀은 유형 3에 머무르는 것으로 만족해서는 안 된다. 유형 3은 ZK-EVM이 호환성을 높이기 위해 전처리 기능을 추가하고 유형 2.5로 전환하는 과도기적 단계이다.

유형 4 | 고급 언어 수준에서 동일

아키텍처:

· Solidity, Vyper 등의 고급 언어로 작성된 스마트 계약 코드를 수용함;

· ZK-SNARK에 친화적인 언어로 컴파일함.

유형 4 | 장점

· 매우 빠른 증명 시간;

· 오버헤드(비용, 시간, 계산량) 감소;

· 증명자가 되는 진입 장벽 감소: 탈중앙화 수준 향상.

유형 4 | 단점

· 유형 4 시스템에서는 정확한 바이트코드에 따라 주소가 결정되므로, 계약 주소가 EVM과 다를 수 있음;

· 위와 같은 이유로, 유형 4 ZK-EVM이 바이트코드를 가지고 있지 않으면 주소를 생성할 수 없음;

· 따라서 유형 4는 반사실적(foreseeable) 계약에 의존하는 애플리케이션과 호환되지 않음;

· 많은 디버깅 인프라는 EVM 바이트코드에서 동작하므로 포팅이 불가능함.

유형 4 | 프로젝트

· zkSync

마지막으로 위의 여러 유형들을 함께 비교하여, 다양한 ZK-EVM을 한눈에 이해할 수 있도록 정리해 본다.