ZK-EVM의 5가지 유형: 특성, 장단점 및 적용 사례 개요
작성: 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을 한눈에 이해할 수 있도록 정리해 본다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
cookies
