[About zkEVM]#2: How&Which zkEVM?
zk 증명 방식이 실질적으로 이더리움과 같이 기능하기 위해 필요한 zkEVM에 대해 간단히 살펴봅니다.
이번 글은 zkEVM의 원리과, zkEVM 프로젝트에 대해서 다뤄보도록 하겠습니다. zkEVM의 개념 및 필요성은 이전 아티클을 참고해주세요:)
#2: How & Which zkEVM? (Future of zkEVM)
I. HOW zkEVM?
zkEVM은 앞선 실행 단계가 모두 규칙을 따랐으며, 연산의 결과값이 모두 정확하고, 유효하다는 증거를 생성하면서 프로그램을 실행합니다. 이를 위해서 영지식 증명(zero-knowledge Proof)이라는 메커니즘을 사용하죠.
따라서 기존의 EVM과는 작동 방식에서 다른 부분이 있습니다.
우선, EVM이 기본적으로 어떻게 작동하는 지에 대해서 설명하겠습니다. EVM은 일부 입력에 응답하여 이전 상태에서 새로운 상태로 이동하는 상태 머신입니다. 모든 스마트 컨트랙트의 실행은 이 상태 변화를 촉발하는 것이고요.
스마트 컨트랙트 거래가 발생하면, EVM에서는 다음과 같은 작업을 수행합니다.
- 바이트 코드 액세스: 컨트랙트 바이트 코드(소스 코드에서 컴파일 된)는 EVM의 스토리지에서 로드 되고 EVM의 노드들에 의해 실행됩니다. 이때, 노드는 동일한 트랜잭션 입력을 사용하여 각 노드가 동일한 결과에 도달하도록 보장합니다. 만약 그렇지 않다면 합의가 이루어질 수 없습니다.
- 읽기-쓰기 작업: EVM 작동 코드(바이트 코드에 포함된)는 EVM 상태의 메모리, 스토리지 및 스택과 상호작용하고, OPCODE는 읽기-쓰기 작업을 수행합니다. 즉, 상태 저장소(State storage)에서 값을 읽고 EVM 스토리지에 새로운 값을 기록합니다.
- 계산: EVM OPCODE는 상태 저장소에서 얻은 값에 대한 계산을 수행한 후, 계산된 새로운 값을 반환합니다. 이 업데이트로 인해 EVM은 새로운 “상태”로 전환되는데, 이 상태는 다른 노드에 의해 복제되며 다른 트랜잭션이 실행될 때까지 유지됩니다.
zkEVM에서도 이와 같은 작업을 하지만, EVM에서 이루어지는 연산 과정을 검증하기 위해 영지식 증명을 생성하는 것이 차이점입니다.
다음은 EVM과 동일한 작업을 할 때 영지식 증명을 수행하는 요소들입니다.
- 바이트 코드 액세스: 올바른 주소에서 적절한 프로그램 코드가 올바르게 로드 되었는지.
- 읽기-쓰기 작업:
- 프로그램이 계산 전에 스택/메모리/스토리지에서 올바른 값을 가져왔는지.
- 프로그램이 실행을 완료한 후 스택/메모리/스토리지에 올바른 출력 값을 썼는지.
3. 계산: OPCODE가 단계를 건너뛰지 않고 차례대로 올바르게 실행되었는지.
이렇듯 zkEVM은 검증 과정을 거치고, 이를 메인 체인에 있는 검증자(Verifier)에게 확인 받기 때문에 크게 프로그램을 실행하는 실행 환경, 영지식 증명을 생성하는 검증 회로, 그 증명을 검증하는 검증 계약의 세 부분으로 나눌 수 있습니다.
- 실행 환경(Execution environment): EVM과 매우 유사하게 기능. 새로운 상태를 출력하기 위해서는 초기 상태와 현재 트랜잭션이 필요.
- 증명 회로(Proving circuit): 실행 환경에서 계산된 트랜잭션의 유효성을 검증하는 영지식 증명을 생성. 사전 상태, 트랜잭션 입력, 사후 상태 정보를 사용하여 프로세스를 거치면, 각 상태 변경의 타당성에 대한 간결한 증명을 얻게 됨.
- 검증 계약(Verifier contract): ZK 롤업 방식에서는 메인 체인(이더리움)에 배치된 스마트 컨트랙트(검증 계약)에 입력(사전 상태 및 거래 정보)과 출력(최종 상태)과 함께 유효성 증명을 함께 제출. 검증자가 제공된 증명에 대한 계산을 실행하고, 제출된 출력이 입력으로부터 정확하게 계산되었는지 확인.
Q. OPCODE는 무엇이며 EVM에서 어떤 역할을 하나요?
A. 고급 언어(ex. 솔리디티)로 작성된 스마트 컨트랙트 코드는 컴파일 과정을 거쳐 EVM이 이해할 수 있는 기계어(바이트 코드) 형태가 됩니다. 이를 EVM이 해석하고 실행할 때 OPCODE 단위로 진행하게 됩니다. 즉, OPCODE란 바이트 코드에 의해 지정되어 VM에서 프로그램을 실행할 때 사용되는 명령어라고 할 수 있습니다.
일반적인 EVM OPCODE는 영지식 증명 회로에서 사용하기에 효율적이지 않기 때문에 zkEVM만의 OPCODE가 필요합니다. 활용 가능할 정도로 효과적인 zkEVM을 만들기 위해서는 OPCODE를 만드는 것이 중요하다고도 할 수 있겠죠. OPCODE를 만드는 데에는 일반적으로 두 가지 방법이 있습니다.
- zk EVM가 기본 EVM OPCODE를 수행할 수 있도록 회로 구축
- 모든 EVM 명령어 집합을 산술 회로에 구현하는 방식입니다. 당연하게도 복잡하고 시간이 많이 들지만, 개발자가 기존 EVM에서 작동되는 스마트 컨트랙트를 광범위한 수정 없이 zkEVM으로 실행할 수 있다는 장점이 있습니다.
2. zk 증명 계산을 위한 새로운 언어 생성
- 유효성 증명을 지원할 수 있는 새로운 언어를 구축하고 맞춤형 OPCODE를 개발하는 방식입니다. 첫번째 방식보다는 구현이 간단하지만, 개발자들이 새로 만들어진 언어로 스마트 컨트랙트를 작성하거나, zkEVM OPCODE를 위해 기존의 소스 코드를 다시 컴파일해야합니다. 또한, 기존 이더리움 인프라와 리소스에 접근하기 어려울 수도 있습니다.
II. WHICH zkEVM Project
zkEVM 프로젝트에 대해서 알아보기 전에, zkEVM과 EVM과의 동등성 레벨에 대해서 알아보겠습니다. 이더리움의 창시자 Vitalik Buterin과 zkEVM 개발 프로젝트 팀들은 zkEVM의 기존 EVM과의 동등성(Equivalence)을 다섯 가지 유형으로 구분했습니다.
TYPE 1 zkEVM (완전히 이더리움과 동등)
- 지금의 이더리움 시스템에서 어떠한 부분도 바꾸지 않는 zkEVM입니다. 검증 중인 트랜잭션, 블록 및 데이터를 검증하는 것이 주요 목표입니다.
- 롤업 블록을 생성하고 처리하기 위해 기존의 실행 클라이언트를 그대로 사용할 수 있습니다.
- 하지만, 이더리움 블록에 대한 증명을 생성하는 데에 많은 시간이 걸릴 가능성이 높습니다.
TYPE 2 zkEVM (완전히 EVM과 동등)
- 이더리움과 똑같아 보이지만, 데이터 구조나 상태 트리와 같이 방식의 차이가 있는 zkEVM입니다. 기존의 애플리케이션(dApp)과 호환되지만 개발을 용이하게 하고 증명 생성 속도를 높이기 위해 이더리움을 사소한 방법으로 수정하는 것이 주요 목표입니다.
- 하지만, 여전히 증명 생성 속도는 느립니다.
TYPE 2.5 zkEVM
- EVM에서 특정 운영에 대한 가스 비용을 증가시킨 zkEVM입니다.
- TYPE2 EVM에서 발생하는 증명 생성에 대한 최악의 시나리오를 해결하면서 증명 생성 속도를 향상시켰습니다.
- 하지만, 일부 응용 프로그램이나 작업 툴킷이 호환되지 않을 가능성이 있습니다.
TYPE 3 zkEVM (거의 EVM과 동등)
- 증명 시간을 개선하기 위해 EVM의 일부 특징을 희생시킨 zkEVM입니다.
- 보통, 이더리움 스마트 컨트랙트의 사전 컴파일(Precompile) 기능과 컨트랙 코드, VM 메모리와 스택을 다루는 방식에서 차이점이 있는 경우가 많습니다.
- 잘 알려진 EVM에 구축된 대부분의 애플리케이션은 작동하는 것으로 간주되지만, 차이점이 있는 기능들을 사용하는 경우에 대비하여 다시 작성해야합니다.
TYPE 4 zkEVM (고급 언어와 동등)
- 고급 언어(ex. Solidity)로 작성된 스마트 컨트랙트 코드를 영지식 증명 방식에 친화적인 언어로 컴파일하는 VM입니다.
- zkEVM 구축 비용을 크게 줄일 수 있지만, EVM 바이트 코드 디버깅과 같이 이미 개발된 대부분의 도구가 작동하지 않을 가능성이 큽니다. 예를 들어, 언어에서 언어로 확장될 때 바이트 코드가 변경될 수 있는 주소를 포함하고 있다면 작동하지 않겠죠.
아래의 표는 zkVM을 지원하는 프로젝트들을 EVM 호환성에 따라 분류한 표입니다.
오른쪽으로 갈수록, 더 나은 EVM 호환성을 보이고 있죠. 모두 언어(Solidity) 측면에서는 호환성을 가지지만, 바이트 코드 측면에서는 제각기 차이점을 가집니다.
StarkNet Startware
Solidity -> Readable Cairo -> [Bytecode] Cairo assembly -> [VM] Cairo zkVM
- 스마트 컨트랙트를 Solidity로 작성할 수 있지만, EVM의 OPCODE를 사용하지 않아 EVM과 호환된다고 말하기에는 차이점이 있습니다. 즉, 이더리움만의 개발 자원을 활용하기에는 한계가 있겠죠.
- 현재 자체적인 커뮤니티를 구성하고, dApp 개발을 지원하는 것으로 호환성에 대한 문제를 해결하고 있습니다.
zkSync zkEVM
Solidity -> LLVM-IR -> [Bytecode] Zinc instruction ->[VM] Zinc zkVM
- 스마트 컨트랙트를 Solidity로 작성한 뒤, LLVM 프레임 워크를 사용하여 IR로 변환하고, 이후 자체적으로 제작한 zkVM에 맞는 바이트 코드로 다시 컴파일 하는 방식을 사용했습니다.
- EVM이 아닌 자체 VM을 사용한다는 점에서 앞서 설명한 Starkware와 비슷하지만, 언어 측면에서는 이더리움 방식과 동일하게 작동합니다.
- 하지만, 현재는 더 완벽한 이더리움 호환성을 가지기 위해 자체 VM이 아닌 zkEVM으로 구현 방향을 바꾸었다고 합니다.
Polygon zkEVM
Solidity -> IR -> [Bytecode] OPCODE -> Micro OPCODE -> [VM] uVM
- 이더리움의 OPCODE를 Micro OPCODE로 컴파일하여 자체 제작한 가상머신인 uVM에서 실행합니다. Bytecode 단위까지 이더리움과 호환된다고 할 수 있죠.
- STARK(생성 속도가 빠르지만 비용이 많이 듦) 방식으로는 현재 상태 변경에 대한 유효성 증명을 생성하고, 이것을 SNARK(상대적으로 생성 속도는 느리지만 더 간단하고 저렴하게 검증 가능)으로 한 번 더 확인하여 검증하는 방식을 사용합니다.
Scroll zkEVM
Solidity -> IR -> [Bytecode] OPCODE -> [VM] zkEVM
- 아직 VM 개발 과정 중에 있는 프로젝트입니다. Scroll 프로젝트에서는 EVM OPCODE에 대한 영지식 회로를 설계하여 기존 EVM 바이트 코드를 수정할 필요 없이 이더리움-네이티브 스마트 컨트랙트 EVM을 그대로 배포할 수 있는 “zkEVM”을 구현하려고 합니다. 즉, zkVM이 아닌 zkEVM이라고 할 수 있죠.
- “암호화 축적기”(Cryptographic Accumulator)를 통해 스토리지 정확성을 확인하여 컨트랙트 바이트 코드가 지정된 주소에서 올바르게 로드 되었음을 증명하고, 바이트 코드를 실행된 VM 명령과 순서를 지정하는 시퀀스(실행 트레이스; Execution trace)와 연결하기 위한 회로를 제공할 계획이라고 합니다.
III. Future of zkEVM
II의 내용을 보면 눈치채셨겠지만, 현재까지는 Scroll이 구현하려고 하는 zkEVM이 가장 호환성 높은 zkEVM이라고 할 수 있습니다. 이는 다른 zkEVM 프로젝트에서 구현한 VM에 비해 기존 이더리움에서 사용되는 각종 툴을 큰 마찰 없이 자유롭게 사용할 수 있는 거죠.
Scroll은 얼마 전에(2023년 2월 27일) 알파 테스트넷이라는 테스트넷을 발표했습니다. 알파 테스트넷은 Goerli 테스트넷을 Layer 1 체인으로 둔 시범 목적의 체인으로, 누구나 Scroll의 zkEVM을 테스트해볼 수 있습니다. (물론, 아직 완벽한 zkEVM의 형태로 구축되지는 않았습니다.)
해결할 과제들이 많기에 아직까지 zkEVM을 자유롭게 사용하기에는 어려움이 있지만, 가까운 미래에 영지식 증명을 활용하여 기존 이더리움의 개발 방식은 유지하되 확장성을 개선한 zkEVM을 통해 더 많은 dApp들이 개발되길 기대해볼 수 있겠습니다.
