ZK-EVM의 5가지 유형(아키텍처, 장점, 단점, 솔루션)을 자세히 설명하세요.
원저자:cookies
원문 편집: Deep Tide TechFlow
원저자:
원문 편집: Deep Tide TechFlow
이 기사에서는 ZK-EVM의 5가지 유형을 자세히 살펴보고 각 유형에는 고유한 아키텍처, 장점과 단점, 가능한 솔루션이 있습니다.
또한 이 기사에서는 독자가 실제 애플리케이션에서 이러한 유형의 성능을 더 잘 이해할 수 있도록 몇 가지 실제 프로젝트 예도 나열합니다. 당신이 블록체인 개발자이거나 블록체인 기술에 관심이 있는 독자라면, 이 기사는 당신에게 심층적이고 간결한 통찰력을 제공할 것입니다.
ZK-EVM의 유형과 장단점을 살펴보겠습니다.
1. 유형 1: 이더리움과 완전히 동일합니다.
2. 유형 2: EVM과 완전히 동일합니다.
3. 유형 2.5: EVM과 부분적으로 동일합니다.
4. 유형 3: EVM과 거의 동일합니다.
5. 4를 입력하십시오. 여기서 고급 언어는 동일합니다.
유형 1: 이더리움과 완전히 동일함
아키텍처: 이더리움과 정확히 동일하며 이더리움 시스템의 어떤 부분도 변경하지 않습니다.
이점
완벽한 호환성:
이더리움 블록을 검증하는 능력
Ethereum L1의 확장성을 높이도록 도와주세요.
많은 인프라를 재사용하므로 롤업에 적합합니다.
결점
완벽한 호환성:
Ethereum은 원래 ZK 기능을 위해 설계되지 않았습니다.
이더리움의 많은 구성 요소는 ZK 증명(ZKP)을 생성하기 위해 많은 계산을 필요로 합니다.
Ethereum 블록에 대한 증명을 생성하는 데는 많은 시간이 걸립니다.
ZK-SNARK ASIC.
문제 해결 방법:
대규모 병렬화된 증명자
유형 2: EVM과 완전히 동일함
건축학:
데이터 구조(블록 구조 및 상태 트리)는 Ethereum과 크게 다릅니다.
기존 애플리케이션과 완벽하게 호환됩니다.
더 쉬운 개발과 더 빠른 증명 생성을 위해 Ethereum이 약간 수정되었습니다.
이점
유형 1보다 더 빠른 교정 시간을 제공합니다.
데이터 구조는 EVM에서 직접 액세스되지 않습니다.
Ethereum에서 실행되는 애플리케이션: 유형 2에서 실행될 가능성이 높습니다.
기존 EVM 디버깅 도구 및 기타 개발 인프라를 지원합니다.
결점
단점을 이해하기 전에 먼저 Keccak이 무엇인지 이해하십시오.
이더리움 블록체인의 해싱 알고리즘
Ethereum의 데이터를 보호하는 데 사용됩니다.
정보가 해시로 변환되었는지 확인하세요.
Keccak을 Merkle 증명(알파벳)을 사용하는 언어로 생각할 수 있습니다. ZK-EVM이 Keccak을 다른 해싱 알고리즘(예: Poseidon)으로 대체하면 Merkle 증명이 낯설어지고 애플리케이션이 이를 읽고 주장을 검증할 수 없게 됩니다.
프로젝트
Scroll;
Polygon Hermez.
단점에 대한 잠재적인 해결책: 이더리움은 미래에 확장 가능한 기록 액세스 사전 컴파일을 추가할 수 있습니다.
프로젝트
그러나 이러한 프로젝트는 아직 더 정교한 사전 컴파일을 구현하지 않았으므로 불완전한 Type 2로 간주될 수 있습니다.
유형 2.5: EVM과 부분적으로 동일함
건축학:
ZK를 증명하기 어려운 특정 EVM 작업의 가스 비용을 늘립니다.
사전 컴파일됨;
케착 연산코드;
계약을 호출하는 방식입니다.
액세스 메모리;
저장.
이점
최악의 경우 증명 시간이 크게 향상되었습니다.
EVM 스택을 더 깊게 변경하는 것보다 안전합니다.
결점
개발 도구의 호환성 감소
일부 응용 프로그램은 작동하지 않습니다.
유형 3: EVM과 거의 동일
건축학:
ZK-EVM 구현에서는 구현하기 매우 어려운 일부 기능이 삭제되며 일반적으로 사전 컴파일됩니다.
ZK-EVM은 계약 코드, 메모리 또는 스택을 처리하는 방법에 약간의 차이가 있습니다.
이점
검증 시간을 줄입니다.
EVM 개발을 더 쉽게 만듭니다.
목표는 규정을 덜 준수하는 애플리케이션에 대해 최소한의 재작성을 요구하는 것입니다.
더 많은 비호환성;
프로젝트
유형 3에서 제거된 사전 컴파일을 사용하는 애플리케이션은 다시 작성해야 합니다.
프로젝트
현재 Scroll 및 Polygon은 Type 3으로 간주되지만 ZK-EVM 팀은 Type 3에 만족해서는 안 됩니다. Type 3은 ZK-EVM이 호환성을 개선하기 위해 사전 컴파일을 추가하고 Type 2.5로 이동하는 전환 단계입니다.
유형 4: 고급 언어에 해당
건축학:
고급 언어(예: Solidity, Vyper)로 작성된 스마트 계약 코드를 수락합니다.
ZK-SNARK 친화적으로 설계된 언어로 컴파일됩니다.
이점
매우 빠른 교정 시간;
오버헤드 감소(비용, 시간 및 계산 노력)
증명자가 되기 위한 장벽을 낮추는 것: 분산화를 증가시키는 것입니다.
결점
유형 4 시스템에서는 주소가 정확한 바이트코드에 따라 다르기 때문에 계약의 주소가 EVM의 주소와 다를 수 있습니다.
위의 경우 유형 4는 반대실적 계약에 의존하는 애플리케이션과 호환되지 않습니다.
프로젝트
zkSync
많은 디버깅 인프라는 EVM 바이트코드에서 실행되기 때문에 이식성이 없습니다.
