자세히 알아보는 Kakarot zkEVM: Starknet의 EVM 호환 경로

작성자：Cynic

출처：이더리움 애호가

TL;DR

• 가상 머신은 프로그램에 실행 환경을 제공하는 소프트웨어 시뮬레이션 컴퓨터 시스템입니다. 다양한 하드웨어 장치를 시뮬레이션하여 프로그램이 통제되고 호환 가능한 환경에서 실행되도록 합니다. 이더리움 가상 머신(EVM)은 이더리움 스마트 계약을 실행하기 위해 사용되는 스택 기반 가상 머신입니다.
• zkEVM은 제로 지식 증명/유효성 증명 기술이 통합된 EVM입니다. 모든 검증자가 EVM을 다시 실행하지 않고도 제로 지식 증명을 사용하여 EVM의 실행 과정을 검증할 수 있게 합니다. 시장에는 다양한 zkEVM 제품이 있으며, 각 제품마다 고유한 방법과 설계가 있습니다.
• zkEVM이 필요한 이유는 Layer 2에서 스마트 계약 실행을 지원하는 가상 머신에 대한 수요 때문입니다. 또한 일부 프로젝트는 EVM의 광범위한 사용자 생태계를 활용하고 제로 지식 증명에 더 친숙한 명령어 집합을 설계하기 위해 zkEVM을 선택합니다.
• 카카롯(Kakarot)은 카이로(Cairo) 언어를 사용하여 스타크넷(Starknet)에서 구현된 zkEVM입니다. 카이로 스마트 계약의 형태로 EVM의 스택, 메모리, 실행 및 기타 측면을 시뮬레이션합니다. 카카롯은 카이로 언어가 아직 실험 단계에 있기 때문에 스타크넷 계정 시스템과의 호환성, 비용 최적화 및 안정성 등의 도전에 직면해 있습니다.
• 워프(Warp)는 솔리디티(Solidity) 코드를 카이로 코드로 변환하는 변환기로, 고급 언어 수준에서 호환성을 제공합니다. 반면 카카롯은 EVM의 작업 코드와 사전 컴파일을 구현하여 EVM 수준의 호환성을 제공합니다.

가상 머신이란 무엇인가?

가상 머신이 무엇인지 명확히 설명하기 위해서는 현재 주류인 폰 노이만 아키텍처 하의 컴퓨터 실행 프로세스를 먼저 설명해야 합니다. 컴퓨터에서 실행되는 다양한 프로그램은 일반적으로 고급 언어로 작성된 후 여러 단계를 거쳐 최종적으로 기계가 이해할 수 있는 기계어 코드로 변환되어 실행됩니다. 기계어로 변환되는 방식에 따라 고급 언어는 대체로 컴파일 언어와 인터프리터 언어로 나눌 수 있습니다.

컴파일 언어는 코드 작성이 완료된 후 컴파일러의 처리를 거쳐 고급 언어 코드를 기계어로 변환하여 실행 파일을 생성해야 합니다. 한 번의 컴파일로 여러 번 높은 효율로 실행할 수 있습니다. 컴파일 언어의 장점은 컴파일 시 이미 코드가 기계어로 변환되기 때문에 실행 속도가 빠르고, 컴파일러가 없는 환경에서도 프로그램을 실행할 수 있어 사용자에게 편리하며 추가 소프트웨어 설치가 필요하지 않습니다. 일반적인 컴파일 언어로는 C, C++, Go 등이 있습니다.

컴파일 언어에 대응되는 것이 인터프리터 언어입니다. 인터프리터 언어는 코드가 인터프리터에 의해 한 줄씩 해석되어 실행되며, 컴퓨터에서 직접 실행되므로 매번 실행할 때마다 번역 과정을 다시 거쳐야 합니다. 인터프리터 언어의 장점은 개발 효율이 높고 코드 디버깅이 용이하지만 실행 속도는 상대적으로 느립니다. 일반적인 인터프리터 언어로는 파이썬, 자바스크립트, 루비 등이 있습니다.

언어는 본질적으로 컴파일 언어와 인터프리터 언어를 구분하지 않으며, 초기 설계 시에 약간의 경향이 있을 뿐입니다. C/C++는 대부분의 경우 컴파일 실행되지만, 인터프리터 실행도 가능합니다(Cint, Cling). 많은 전통적인 의미의 인터프리터 언어는 현재 중간 코드로 컴파일되어 가상 머신에서 실행됩니다(파이썬, 루아).

물리적 머신의 실행 프로세스를 이해했으니 이제 가상 머신에 대해 설명하겠습니다.

가상 머신은 일반적으로 다양한 하드웨어 장치를 시뮬레이션하여 가상 컴퓨터 환경을 제공합니다. 서로 다른 가상 머신이 시뮬레이션할 수 있는 하드웨어 장치는 다르지만, 일반적으로 CPU, 메모리, 하드 드라이브, 네트워크 인터페이스 등을 포함합니다.

이더리움 가상 머신 EVM을 예로 들면, EVM은 이더리움 스마트 계약을 실행하는 데 사용되는 스택 기반 가상 머신입니다. EVM은 CPU, 메모리, 저장소 및 스택과 같은 하드웨어 장치를 시뮬레이션하여 가상 컴퓨터 환경을 제공합니다.

구체적으로 EVM은 스택 기반 가상 머신으로, 스택을 사용하여 데이터를 저장하고 명령을 실행합니다. EVM의 명령어 집합에는 산술 연산, 논리 연산, 저장 연산, 점프 연산 등 다양한 작업 코드가 포함되어 있으며, 이러한 명령은 EVM의 스택에서 실행되어 스마트 계약의 실행을 완료합니다.

EVM이 시뮬레이션하는 메모리와 저장소는 스마트 계약의 상태와 데이터를 저장하는 장치입니다. EVM은 메모리와 저장소를 두 개의 서로 다른 영역으로 간주하며, 메모리와 저장소를 읽고 쓰는 방식으로 스마트 계약의 상태와 데이터에 접근합니다.

EVM이 시뮬레이션하는 스택은 명령의 피연산자와 결과를 저장하는 데 사용됩니다. EVM의 명령어 집합에서 대부분의 명령은 스택 기반으로, 스택에서 피연산자를 읽고 결과를 다시 스택에 푸시합니다.

결론적으로 EVM은 CPU, 메모리, 저장소 및 스택과 같은 하드웨어 장치를 시뮬레이션하여 가상 컴퓨터 환경을 제공하며, 스마트 계약의 명령을 실행하고 스마트 계약의 상태와 데이터를 저장할 수 있습니다. 실제 실행 시 EVM은 스마트 계약의 바이트코드를 메모리에 로드하고 명령어 집합을 실행하여 스마트 계약의 논리를 수행합니다. EVM이 실제로 대체하는 것은 위 그림의 운영 체제 + 하드웨어 부분입니다.

EVM의 설계 과정은 분명히 아래에서 위로 진행되었으며, 먼저 시뮬레이션할 하드웨어 환경(스택, 메모리)을 확정한 후 해당 환경에 맞는 자체 어셈블리 명령어 집합(Opcode)과 바이트코드(Bytecode)를 설계했습니다. 어셈블리 명령어 집합은 사람이 보기 위한 것이지만, 많은 저수준 지식이 관련되어 있어 개발자에게 높은 요구 사항이 있으며, 개발하기도 복잡하므로 고급 언어가 필요하여 복잡하고 난해한 저수준 호출을 차단하고 개발자에게 더 나은 경험을 제공합니다. EVM은 어셈블리 명령어 집합의 맞춤형 설계로 인해 전통적인 고급 언어를 직접 활용하기 어려워, 이 가상 머신에 적합한 새로운 고급 언어를 새로 만들었습니다. 이더리움 커뮤니티는 EVM 실행 효율성을 위해 두 가지 컴파일형 고급 언어인 솔리디티(Solidity)와 바이퍼(Vyper)를 설계했습니다. 솔리디티는 말할 필요도 없고, 바이퍼는 비탈릭이 솔리디티의 일부 결함을 개선하기 위해 설계한 EVM 고급 언어이지만, 커뮤니티에서 높은 채택도를 얻지 못해 점차 역사에서 사라졌습니다.

zkEVM이란 무엇인가

간단히 말해, zkEVM은 제로 지식 증명/유효성 증명 기술을 활용한 EVM으로, EVM의 실행 과정을 제로 지식 증명/유효성 증명을 통해 더 효율적이고 저렴하게 검증할 수 있게 하여 모든 검증자가 EVM의 실행 과정을 다시 수행할 필요가 없습니다.

시장에서 다양한 zkEVM 제품이 있으며, 경쟁이 치열합니다. 주요 플레이어로는 스타크넷, zkSync, 스크롤, 타이코, 리네아, 폴리곤 zkEVM(구 폴리곤 헤르메즈) 등이 있으며, 비탈릭은 이를 5가지 유형(1, 2, 2.5, 3, 4)으로 분류했습니다. 구체적인 내용은 비탈릭의 블로그를 참조할 수 있습니다.

왜 zkEVM이 필요한가

이 질문은 두 가지 측면에서 살펴봐야 합니다.

초기 zk 롤업 시도는 비교적 간단한 송금 및 거래 기능만 구현할 수 있었습니다. 예를 들어 zkSync Lite, 루프링 등이 있습니다. 하지만 한 번 경험한 이더리움의 튜링 완전한 EVM에서 프로그래밍을 통해 다양한 응용 프로그램을 만들 수 없게 되자, 사람들은 L2에서의 가상 머신을 요구하기 시작했습니다. 스마트 계약 작성의 필요성이 그 중 하나입니다.

EVM의 일부 설계가 제로 지식 증명/유효성 증명 생성에 불리하기 때문에 일부 플레이어는 저수준에서 제로 지식 증명/유효성 증명에 친화적인 명령어 집합을 사용하기로 선택했습니다. 예를 들어 스타크넷의 카이로 어셈블리와 zkSync의 Zinc Instruction 등이 있습니다. 그러나 모두 EVM의 방대한 사용자 생태계를 포기하고 싶지 않기 때문에 EVM과의 호환성을 선택했습니다. 이는 3, 4 유형의 zkEVM입니다. 일부 플레이어는 여전히 EVM의 전통적인 명령어 집합 Opcode를 고수하며, Opcode에 대해 더 효율적인 증명을 생성하는 데 집중하고 있습니다. 이는 1, 2 유형의 zkEVM입니다. EVM의 방대한 생태계가 두 번째 이유입니다.

카카롯: 가상 머신 위의 가상 머신?

왜 가상 머신 위에 또 다른 가상 머신을 만들 수 있을까요? 이는 컴퓨터 종사자에게는 흔한 일이지만, 컴퓨터를 잘 모르는 사용자에게는 그렇게 명확하지 않을 수 있습니다. 사실 이해하기 쉽습니다. 이는 블록 쌓기와 비슷한데, 하층이 충분히 견고하다면(튜링 완전한 실행 환경이 있다면) 무한히 상층에 블록을 쌓을 수 있습니다. 하지만 몇 층을 쌓든 마지막 실행은 가장 하층의 물리적 하드웨어가 처리해야 하므로 층수가 높아질수록 효율이 떨어질 수 있습니다. 또한 서로 다른 블록의 설계가 다르기 때문에(가상 머신 설계가 다르기 때문에) 블록이 높아질수록 블록이 무너질 가능성이 커지며(실행 오류가 발생할 수 있으며), 이는 더 높은 기술 수준을 요구합니다.

카카롯은 스타크넷에서 카이로 언어를 사용하여 구현된 EVM으로, 카이로 스마트 계약 형태로 EVM의 스택, 메모리, 실행 등을 시뮬레이션합니다. 상대적으로 EVM을 구현하는 것은 어렵지 않으며, 가장 많이 사용되는 Go-Ethereum에서 Go 언어로 작성된 EVM 외에도 현재 파이썬, 자바, 자바스크립트, 러스트로 작성된 EVM이 존재합니다.

카카롯 zkEVM의 기술적 난점은 프로토콜이 스타크넷 체인上的 계약으로 존재한다는 점에서 두 가지 주요 문제를 가져옵니다.

1. 호환성 스타크넷은 이더리움과 완전히 다른 계정 체계를 사용합니다. 이더리움에서는 계정이 EOA(외부 소유 계정)와 CA(계약 계정)로 나뉘지만, 스타크넷에서는 네이티브 계정 추상화를 지원하며 모든 계정이 계약 계정입니다. 또한 사용되는 암호 알고리즘이 다르기 때문에 사용자는 동일한 엔트로피를 사용하여 스타크넷에서 이더리움과 동일한 주소를 생성할 수 없습니다.
2. 비용 카카롯 zkEVM은 체인上的 계약으로 존재하기 때문에 코드 구현에 대한 높은 요구 사항이 있으며, 가능한 한 가스를 최적화하여 상호작용 비용을 줄여야 합니다.
3. 안정성 고급 언어인 Go, Rust, Python과는 달리 카이로 언어는 여전히 실험 단계에 있으며, 카이로 0에서 카이로 1, 다시 카이로 2(또는 당신이 좋아한다면 카이로 1 버전 2)로 공식 팀은 계속해서 언어 특성을 수정하고 있습니다. 동시에 카이로 VM은 충분한 테스트를 받지 못했으며, 향후 대규모 재작성 가능성을 배제할 수 없습니다.

카카롯 프로토콜은 다섯 개의 주요 구성 요소로 구성되어 있습니다(깃허브 문서에서는 네 개로 작성되어 있으며 EOA가 포함되지 않았습니다. 본 문서에서는 독자의 이해를 돕기 위해 조정했습니다):

• 카카롯(Kakarot)(코어): 이더리움 형식의 거래를 실행하며, 이더리움 사용자에게 해당 스타크넷 계정을 제공합니다.
• 계약 계정: 이더리움 의미의 CA로, 계약의 바이트코드와 계약 내 변수 상태를 저장합니다.
• 외부 소유 계정: 이더리움 의미의 EOA로, 이더리움 거래를 카카롯 코어에 전달합니다.
• 계정 레지스트리: 이더리움 계정과 스타크넷 계정의 대응 관계를 저장합니다.
• 블록 해시 레지스트리: 블록 해시는 특별한 Opcode로, 과거 블록 데이터가 필요하지만 카카롯은 체인上에서 직접 데이터를 가져올 수 없습니다. 이 구성 요소는 block_number -> block_hash의 매핑 관계를 저장하며, 관리자가 작성하여 카카롯 코어에 제공합니다.

카카롯 CEO Elias Tazartes의 피드백에 따르면, 팀의 최신 버전에서는 계정 레지스터 설계를 포기하고 31바이트의 스타크넷 주소를 20바이트 EVM 주소로 매핑하여 대응 관계를 저장합니다. 향후 상호 운용성을 높이고 스타크넷 계약이 자신의 EVM 주소를 등록할 수 있도록 하기 위해 계정 레지스터 설계를 다시 사용할 가능성이 있습니다.

스타크넷에서 EVM과의 호환성: 워프와 카카롯의 차이점

비탈릭이 정의한 zkEVM 유형에 따르면, 워프는 Type-4에 해당하며, 카카롯은 현재 Type-2.5에 해당합니다.

워프는 솔리디티 코드를 카이로 코드로 변환하는 변환기로, 컴파일러라고 하지 않는 이유는 출력된 카이로가 여전히 고급 언어이기 때문입니다. 워프를 통해 솔리디티 개발자는 원래의 개발 상태를 유지할 수 있으며, 새로운 카이로 언어를 배울 필요가 없습니다. 많은 프로젝트 측면에서 워프는 스타크넷 생태계에 진입하는 장벽을 낮추어 카이로를 사용하여 대량의 엔지니어링 코드를 다시 작성할 필요가 없습니다.

변환의 아이디어는 간단하지만 호환성은 가장 나쁩니다. 일부 솔리디티 코드는 카이로로 잘 변환되지 않으며, 계정 체계, 암호 알고리즘 등 코드 논리를 수정해야만 마이그레이션을 완료할 수 있습니다. 구체적인 지원되지 않는 특성은 워프 문서에서 확인할 수 있습니다. 예를 들어 많은 프로젝트는 EOA 계정과 계약 계정의 실행 논리를 구분하지만, 스타크넷에서는 모든 계정이 계약 계정이므로 이 부분의 코드는 수정 후에야 변환할 수 있습니다.

워프는 고급 언어 수준의 호환성이고, 카카롯은 EVM 수준의 호환성입니다.

EVM의 전체 재작성과 Opcode 및 사전 컴파일의 개별 구현으로 인해 카카롯은 더 높은 원주율 호환성을 갖게 되었습니다. 결국 동일한 가상 머신(EVM)에서 실행하는 것이 서로 다른 가상 머신(Cairo VM)에서 실행하는 것보다 항상 더 호환성이 좋습니다. 계정 레지스트리와 블록 해시 레지스트리는 서로 다른 시스템 간의 차이를 교묘하게 차단하여 사용자 마이그레이션 마찰을 최소화합니다.

카카롯 팀

카카롯 팀이 본문에 대해 제시한 귀중한 의견에 감사드립니다. 특히 Elias Tazartes에게 감사드립니다. Thank you, sir!