[번역글] zk EVM 가이드, EVM 호환성과 롤업

29 min readAug 31, 2022

이 글은 이뮤터블 X의 미디엄 블로그에 2022년 8월9일에 발간된 글을 번역 및 편집한 글입니다.

zk-rollups 은 오랬동안 이더리움 확장성의 끝판왕이라고 여겨졌다. 그러나 이더리움 확장성 로드맵에 있어서 중요함에 도 불구하고, 여전히 몇 가지 부분에 있어서 불확실성이 널리 존재하고 있다:

zk-rollup이란 정확히 무엇인가?
application-specific한 rollups과 general purpose rollups 의 차이점은 무엇인가?
zk-EVM이란 무엇인가? EVM-equivalent 와 EVM-compatible의 정확한 뜻은 무엇이며, 어떻게 rollups을 응용할 수 있는가?
zk-rollup 생태계의 현황은 어떠하며, 내 프로젝트에 어떤 영향을 미치는가?

ZK-Rollups

zk-rollups은 간단한 관찰에 의해서 만들어질 수 있다. STARKs나 SNARKs와 같은 증명 시스템은 선형적인 수의 상태들을 sub-linear한 프로세스에 의해서 검증이 가능하다. (1000개의 statements -> 10개의 verifier 체크, 10,000개의 statements ->11개의 verifier checks) . 이러한 프로퍼티를 활용하여 확장성 있는 블록체인 트랜잭션을 만드는 과정은 다음과 같다:

유저가 본인의 자산을 L1체인의 zk-rollup 스마트 컨트랙트에 잠근다.
해당 자산과 관련된 트랜잭션을 L2의 시퀀서에 제출한다. 해당 트랜잭션들 batches을 순서대로 정렬하고, STARK 또는 SNARK를 활용한 validity proof를 생성한 뒤 각각의 batch에 상태를 업데이트한다.
이 상태 업데이트와 proof는 L1 zk-rollup 스마트 컨트랙트에 제출되고 검되며, L1의 상태를 업데이트하는데 사용된다.
유저들은 해당 L1 상태를 사용하여 그들의 자산을 되찾을 수 있으며, 완전히 self-custody 된 이더리움 보안을 갖게 허용하게 된다.

proof 를 증명하는 가스비는 증명된 트랜잭션 수에 sublinear하며, 직접 L1을 사용하는 것보다 훨씬 더 scale하다.

Application-Specific Rollups

지금까지, 모든 production-grade 단의 zk-rollup은 “application-specific rollups” 이라고 불려왔다. appliciation spcific rollup에서 rollup은 고정된 수의 rollup 오퍼레이터에 의해서 정의된 “상태 전이” 를 지원한다. 이는 극도로 최적화된 유즈케이스에 유용하며, 그 예시는 다음과 같다:

Loopring — Payments & Swaps
Immutable — NFT Minting & Trading, Games
dydx — Perpetuals Trading

Application-specific rollups은 부분적이고, 이해도가 높은 문제의 확장성을 높이는데 효과적이다. 만약 당신의 프로젝트가 application-spcific rollup에 의해 충족된다면, 덜 일반화 되었기 때문에, 당신의 프로젝트는 아마 더 나은 퍼포먼스와 UX 그리고 가격을 경험할 수 있을 것이다. Immutable을 예로 들자면, 우리는 NFT 민팅과 전송에 대한 수수료를 무료화 함으로써 가스비를 제거할 수 있었다.

그러나, 많은 프로젝트들은 applicaition-specific rollup의 이러한 특성 때문에 rollup 오퍼레이터로부터 독립되어 그들만의 커스텀 된 로직과 스마트 컨트랙트를 생성하기를 원한다. 뿐만 아니라, 많은 Defi 프로젝트들은 “결합성(composability)”을 필요로 하거나 혹은 다른 프로젝트와 자동적으로 상호작용 하기를 원한다.( 많은 Defi 프로젝트들은 Uniswap을 가격 오라클로 사용한다.) 결합성(composability)은 rollup이 커스텀 코드만이 아닌 어떤 유저를 통해서도 배포될 수 있는 네이티브 스마트 컨트랙트를 지원할때에만 성립이 가능하다. 이를 도달하기 위해서, 우리는 우리의 zk-rollup 아키텍처를 각 컴포넌트별로 일반화할 필요가 있다.

높아진 유연성과 함께 tradeoffs 될 수 밖에 없는 몇 가지 요소들이 있는데 이는 다음과 같다: 부분적으로 나빠진 퍼포먼스, 덜 커스터마이징 된 롤업 파라미터와 높아진 가격이 그 대표이다. 그러나 가장 큰 tradeoff는 지금까지 general purpose zk-rollups에 대한 시행 자체가 없었고, 그래서 어떤 것도 production volume을 감당할 수 없었다는 것이다. 그러나 변화는 지금부터 시작된다.

StarkNet은 현재 메인넷에서 구동된다.
3가지 각기 다른 프로젝트( zkSync, Polygon Hermez/zkEVM,Scroll)이 모두 ETH CC 2022에서 메인넷에 접근 가능한 “zkEVM”의 첫 번째가 될 것이라고 선언하였다.

이들의 선언이 주목할만한 이유는 이들이 그냥 general purpose rollups이 아닌 zkEVM을 개발하겠다고 선언했기 때문이다. 이 뒤 “EVM compatibility”, “EVM equivalency”, “true zkEVM” 중 어떤 접근이 더 우월한 지에 대해서 많은 트위터 논쟁이 일어나기도 했었다.

EVM 이해하기

이더리움 가상 머신은 이더리움 트랜잭션이 실행되는 런타임 환경이며, 초창기 이더리움 황서에서 정의되었으며, Ethereum Improvement Proposal을 통해서 수정되었다.

각 트랜잭션에 대한 휘발성 “memory” 와 트랜잭션을 작성할 수 있는 영구적인 “storage”그리고 오퍼레이팅 “stack”을 갖춘 프로그램 실행을 위한 표준 “machine”.
해당 “machine”에서 상태 전환을 수행하는 ~140개의 가격이 책정된 “opcode”.

https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

가상 머신 opcodes 몇 가지 예제

스택 오퍼레이션(Stack Operations) — PUSH1(스텍에 무언가를 adds함 )
연산 오퍼레이션(Arithmetic Operations) — ADD, SUBTRACT
상태 오퍼레이션 — SSTORE(데이터 저장), SLOAD(데이터 로드)
트랜잭션 오퍼레이션 — CALLDATA, BLOCKNUMBER(현재 실행된 트랜잭션에 대한 정보를 반환함)

하나의 EVM 프로그램은 이런 opcodes와 arguments의 시리즈이다. 이런 프로그램들이 하나의 지속적인 코드 블록을 대표할 때, 우리는 그 결과를 “bytecode”라 부른다.

큰 수의 opcodes들을 시퀀서에 실행하기 위해서 넣으면, 임의의 프로그램을 만들어 낼 수 있다. 이더리움은 다음과 같은 고유한 특성이 있기 때문에 기존의 가상 머신을 조정하는 대신에 커스텀 된 가상 머신을 사용한다:

모든 연산은 반드시 어뷰징 방지를 위해 “비용”이 발생해야 한다.
(모든 노드가 모든 트랜잭션을 실행할 때)
모든 연산은 반드시 결정적이어야 한다.
(모든 노드는 반드시 트랜잭션 실행 후의 상태에 동의해야함)
우리는 블록체인 특화된 개념이 필요하다.
( ex 스마트 컨트랙트, 트랜잭션)
일부 복잡한 연산들은 반드시 기본이 되야 한다.( ex 암호화)
트랜잭션은 I/O 또는 외부 상태 엑세스 없이 샌드박스화 되어야 한다.

EVM은 튜링 완전한 첫번재 블록체인 가상머신으로, 2015에 출시 되었다. 그것은 디자인적으로 한계가 있으나, 퍼스트 무버로써의 이점과 연속적이고 광범위한 적용은 이더리움에 큰 차별화를 가져다 주었다.

이더리움의 도미넌스로 인해서, 많은 후발 블록체인들은 이러한 런타임 환경을 직접적으로 채택하였다. 폴리곤과 BNB를 예를 들자면, 이더리움에서 포크되었으며, 그로 인해서 EVM을 런타임으로 사용할 수 있다. 그러나, EVM은 정착되어 있는 것이 아니라, EIP 1559와 같은 업그레이드를 통해서 자주 업그레이드 된다.

Ethereum Compatibility

그러나, 사람들이 말하는 ‘EVM chain’은 대부분 이런 런타임 환경을 단순히 미러링하는 것 이상으로 확장된다. 여기에는 이더리움이 실질적인 글로벌 표준으로 여겨질 수 밖에 없는 다음과 같은 몇 가지 주요 요소들이 있다:

솔리디티(EVM bytecode로 컴파일이 가능한 고급 언어)
이더리움 JSON-RPC 클라이언트 API( 이더리움과 인터랙팅 가능한 사양)
ERC20/ERC721(이더리움 토큰 스탠다드)
ether.js (이더리움과 인터페이싱하는 웹 라이브러리)
이더리움의 암호화(ex) keccak256 해시 함수, secp256k1을 통한 ECDSA 서명)

기술적으로 당신의 체인은 위의 일부 또는 모든 기능을 지원하지 않고도 EVM의 런타임을 재현할 수 있다. 그러나, 이러한 표준을 준수하는 이더리움의 툴을 쉽게 당신의 새 체인에서 사용할 수 있게 만든다. 이에 대한 완벽한 예제로는 폴리곤이 있다. 폴리곤은 위의 툴들을 다 사용할 수 있을 뿐만 아니라, 이더스캔 (Etherscan)의 포크 버전인 폴리곤스캔(Polygonscan)도 사용할 수 있으며, Hardhat과 같은 이더리움의 개발 툴 및 메타마스크와 같은 월렛에서 다른 이더리움 네트워크로서 지원된다. Nansen이나 Dune과 같은 도구들은 모두 초기에 이더리움을 타깃으로 했기 때문에 새로운 EVM 블록체인을 지원하는 것은 매우 간단하다. 새로운 월렛, 새로운 NFT 마켓플레이스 역시, 만약 이더리움의 인터페이스와 새 체인의 인터페이스의 차이가 단시 체인 ID 뿐이라면, 당신의 것은 아마 처음이자 가장 쉬운 옵션이 될 것이다. 즉 이러한 툴들은 모두 이더리움을 위해 제작되었으며, 당신이 당신의 블록체인을 블록의 크기를 늘린다거나, 블록 타임을 빠르게 하는 형식으로 수정한다면, 당신은 리스크를 감내해야 한다. 완벽한 호환성이란 존재하지 않기 때문이다.

그럼에도 불구하고, 이더리움을 타겟으로한 툴들과 어플리케이션은 새로운 블록체인이 이더리움 표준을 미러링 하게되는 큰 동기가 된다. 어떤 블록체인이던, 위의 사양들을 지원하지 않는다면, 자동적으로 개발자 도구에 있어서 뒤쳐지게 되며, 이는 곧 EVM 생태계가 커질 수록 리스크가 커지는 것을 의미하기 때문이다.

“EVM compatible” 이라는 단어는 실제 네트워크 효과를 설명하기에 부족하다고 생각한다. 우리가 실질적으로 생각하는 “Ethereum compatibility”는 스마트 컨트랙트 실행 환경부터 모든 이더리움 생태계 및 도구 이상으로 확장된다.

이와 맞서기 위해서, 솔라나와 같은 non-EVM 블록체인은 완전히 평행한 생태계를 새로 만들어야만 했다. 이는 그들의 속도를 저해하며, 기존 개발자 확보에 장애가 된다. 그러나, 표준과 다르지 않기 때문에 non-EVM 블록체인은 이더리움 도구 세트를 더 많이 근본적으로 변화할 수 있으며, 그로 인해더 공격적으로 이더리움과의 차별성을 추구할 수 있음을 의미한다. EVM 블록체인을 새로 만드는 것은 매우 간단하지만, 반면 다른 수백 가지의 “빠른 EVM 블록체인”들 중 왜 꼭 당신의 것을 사용해야하는지 의문이 생긴다. 만약 당신이 성공적으로 평행적인 체인과 생태계를 개발 해낸다면, 솔라나가 그랬듯이, 1) 당신은 판타스틱한 네이티브 어플리케이션(ex 메직 에덴, 팬텀) 을 유치할 수 있을 것이며, 2) 상업적인 유인만 충분하다면, EVM — origin 한 프로젝트들이 당신을 지원할 것이다( ex 오픈씨가 솔라나를 지원한 것처럼) .

ZK- EVM

Public general purpose rollups 은 모두 개발자 및 유저들이 최대한 빠르게 네트워크 효과를 생성하게 한다는 공통의 목표를 공유한다. 이를 위해서는 가장 성능이 좋은 rollup 기술을 개발해야 되고, 최고의 BD 팀을 갖춰야 하며, 동시에 가장 효과적인 마케팅을 진행해야 한다. 그러나 모든 rollup 팀들은 (위의 이유로 인해서) 다음과 같은 사항들을 깊게 고민하고 있다:

기존의 이더리움 컨트랙트와 개발자를 그들이 rollups 체인으로 이전하는 것
기존의 EVM 툴의 지원들 받는 것( ex 라이브러리, 월렛, 마켓 플레이스 등)

이러한 목표를 달성하는 가장 간단한 방법은 바로 ‘zkEVM’, 즉 EVM으로써 스마트 컨트랙트를 실행시키고 위에 서술한 이더리움 생태계의 인터페이스와 호환성을 갖는 범용 rollup(general purpose rollup)을 만들어내는 것이다.

그러나, 그것은 새로운 L1 블록체인을 스크레치하거나, Geth를 포크하는 것처럼 그렇게 쉬운 일이 아니다. 우리의 목표는 EVM 바이트코드를 실행시키는 것이나, ZK-proofs는 그것이 증명하는 모든 계산 문장이 STARK 또는 SNARK로 컴파일 될 수 있는 “algebraic circuit” 라는 매우 특별한 형식으로 변환되어야 한다. “circuits”을 빠르고 직관적으로 이해하기 위한 예시가 있다. zkSNARK의 prover는 본인이 올바를 output을 만들어 낼 수 있는 input 값들(x1=1, x2=1, x3=0)을 가지고 있다는 것을 verifier에게 설득시켜야 한다. 아래는 제한된 수의 logic gates 로 이루어진 매우 간단한 circuit이다.

연산에 관해서는 제쳐두고, EVM 연산을 지원하기 위해서는 반드시 모든 EVM 프로그램을 circuit으로 전환시켜야지만 추후에 증명이 가능하며, 이를 위해서는 아래와 같은 방법이 있다:

EVM execution trace를 증명 가능한 circuit으로 변환하여 직접 증명
커스텀 VM을 생성하고, EVM opcode를 커스텀 VM의 opcode와 매핑시킨 뒤, 커스텀 환경에서 trace의 정확성을 증명
커스텀 VM을 생성하고, 솔리디티를 커스텀 VM의 바이트코드로 트랜스파일한 뒤, 커스텀 환경에서 증명

옵션1: EVM Execution Trace 증명하기

Scroll

EVM execution trace 그 자체를 증명하는 것은 현재 Scroll 팀에서 연구하고 있다.( 이더리움 재단의 Privacy Scaling Group도 있다) 이를 가능하게 하기 위해서는 다음과 같은 조건이 필요하다:

일부 암호화 계산기를 위한 circuit 디자인(스토리지와 바이트코드과 정확하게 리딩 및 로딩되어 있는지 증명할 수 있게 함)
바이트코드와 실제 executiion trace를 연결해줄 circuit 디자인
각 opcode에 대한 circuit 디자인 ( 모든 opcode에 대해서 읽기, 쓰기 및 계산이 정확한지 증명할 수 있게 함)

모든 EVM opcode를 circuit에서 바로 실행하기는 것은 무리가 있으나, 이러한 접근인 EVM을 정확히 미러링하기 때문에, 부분적으로 도구 지원의 혜택을 유지할 수 있다. 아래의 다이아 그램은 Scroll과 이더리움의 실제 런타임 환경의 이론적 차이를 보여준다. 그러나, 아직까지 Scroll은 해당 매커니즘에 따라서 EVM opcpode를 지원하고 있지 않으며, 추후 도달할 계획이다.

일전에 Optimism은 커스텀 Optimistic Virtual Machine(OVM)을 개발하였다. OVM은 수정된 솔리디티 코드를 실행이 가능한 ‘Ethereum-compatible’이었느나, 일부 부분에서 low-level의 불일치가 일어나 이더리움의 툴들과 복잡한 코드들은 자주 다시 작성해야 했다. 이러한 이유로 Optimism은 ‘EVM-equivalence’로 노선을 변경하였으며, 정확한 EVM 사양을 직접 사용하여, 최초의 EVM-euivalent 한 사기 증명 시스템을 개발하였다. Optimistic rollups은 circuit이나 prover의 효율성에 대해서 고민하지 않아도 되지만, Optimism에 있어 옳은 선택이 곧 rollup에 있어 옳은 선택은 아니다.

불행히도, EVM 핵심 인프라는 zk-rollup에 적절하지가 않다. rollup 성능의 핵심은 우리가 특정 계산을 circuit으로 인코드하는데 필요한 ‘contraints’의 수이다. 많은 경우, EVM을 미러링 하면 막대한 오버헤드가 직접 발생한다. 예를 들면, EVM은 256-bit 정수를 사용하는 반면, zk proofs는 대부분 소수 필드(prime fields)에서 가장 자연스럽게 작동한다. 일치하지 않은 필드 연산을 방지하기 위해 범위 검사를 도입하면 EVM 단계당 ~100개의 contraints가 추가 된다. 이더리움 스토리지 레이아웃은 STARK 친화적인 해시 함수(ex Poseidon, Pedersen) 보다 circuit이 큰 keccak256에 매우 의지한다. 그러나, keccak을 대체해버리면 기존의 이더리움 인프라와 호환하는데 큰 문제가 생긴다. 뿐만 아니라, 표준 이더리움 타원 곡선 서명은 SNARK/STARK 친화적인 타원 곡선과 비교하여 증명하고 검증하는 것이 훨씬 더 비싸다. 간단히 말하면, EVM을 직접 증명하는 것은 엄청난 계산적 오버헤드를 수반한다. 최근 몇 가지 발전(polynomial commitments, recursive proofs, hardware acceleration)이 있었지만, EVM trace를 증명하는 것은 적어도 EVM 자체를 SNARK 친화적으로 바뀔 때까지, 언제나 부분적으로 커스텀 디자인 된 VM에서 증명하는 것보다 덜 효율적이다.

옵션2: Custom VM + Opcode 지원

이와 같은 깨달음으로 인해서 다른 팀들은 위에서 살펴 본 “EVM-compatible” 접근 방식을 채택하게 되었다. 최적화 된 성능의 커스텀 VM을 만들고, EVM 바이트 코드를 직접적으로 커스텀 VM으로 전환한다.

Polygon

이러한 접근법을 채택한 팀 중 하나는 바로 Polygon Hermez (최근 Polygon zkEVM으로 변경하였다) 이다. 폴리곤의 접근은 ‘opcode-level equivalency’ 한 zkEVM을 만드는 것이다. 이는 처음에는 Scroll의 접근법과 유사하게 들리나, 폴리곤의 대체 런타임(zkExecutor)은 EVM의 opcode를 EVM 번역기에 최적화하는 대신 맞춤 ‘zkASM’ opcode를 사용한다. Hermez 팀은 이를 ‘opcode based approach’라고 부르는데, 핵심 과제가 모든 EVM opcode를 그들의 커스텀 VM으로 재창조하여, EVM 바이트 코드로부터 검증 가능한 형식으로 전환하기 위해서 이기 때문이다.

이러한 중간 과정들은 유지 관리 및 잠재적 버그를 증가시키지만, proof의 성능을 향상시키는데 필수적이다. 궁극적으로, 당신의 프로그램 circuit에서 미러링한 EVM인 zkEVM에서 실행되지 않고, zkExecutor에서 대신 실행되는지는 비슷해 보이지만 EVM 그 자체로는 다르다는 것을 명확히 하는 것은 중요하다. 혼란스럽게도 이 팀은 ‘zkEVM’과 ‘EVM Equivalent’를 모두 명시해 놨다. 하지만, 커스텀 zkASM interpreter 때문에 이 rollup은 사실상 위의 Optimism이 정의해 놓은 것처럼 ‘EVM Compatible’하다.

이것으로 인해 L1에 존재하는 일부 앱과 툴들은 이 시스템에서 잘 호환되지 않으나, 대부분의 솔리디티 코드는 실행이 가능하다. 폴리곤은 그들의 문서에서 현존하는 이더리움 툴과 100% 호환 가능하게 하겠다고 선언하고, JSON-RPC 준수를 약속하였다. 이러한 발언은 아마 포부일 뿐이고, 실제로는 이더리움 그 자체가 SNARK 친화적으로 되는 것에 의존할 가능성이 높다.

폴리곤의 접근은 중단기적으로 Scroll보다 성능이 좋을 것이지만 다음의 조건이 필요하다:

부분적인 커스텀 코드, zkASM을 만들어야 되기 때문
개발자들의 L1 코드 수정 및 툴링 프레임워크 수정이
시간이 지남에 따라 이더리움에서 잠재적으로 증가되는 드리프트

옵션 3: Custom VM + Transpiler

위의 솔루션들은 ‘EVM을 zk-rollup을 구동 가능하게 만드는 것’에 시간을 투자하였고, 호환성을 장기적인 퍼포먼스와 확장성보다 우선시하였다. 그러나 여기에 또 다른 옵션이 있다. 바로, 완전히 새로운 것을 만드는 것, VM을 만들고 이더리움 툴 지원을 또 다를 레이어 위에 추가하는 것이다.

StarkNet

그것은 바로, 스타크웨어가 스타크넷 개발에 취한 방식으로, 현재 가장 많이 진행된 general purpose rollup이다. 스타크넷은 커스텀 스마트 컨트랙트 VM(Cairo VM)을 자체 low-level 언어(Cairo)로 실행시키며, 스마트 컨트랙트 rollup을 만드는 것을 목표로 한다. 그 의미는 스타크넷은 이더리움과 호환되지 않는 것을 의미한다. 앞서 본 것처럼, opcode-levle VM-level 호환성조차도 잠재적인 rollup 퍼포먼스에 브레이크가 되기 때문이다.

이에 Nethermind 팀(스타크웨어와 파트너십 관계) 는 Warp transpiler를 개발하여 임의의 솔리디티 코드를 Cairo VM 바이트코드로 변환시킬 수 있게 하였다. Warp의 목표는 일반 솔리디티 컨트랙트를 스타크넷에 이동시키는 것이다. 그러나, 사실 일부 솔리디티 특징은 Warp을 포함한 low-level calls을 지원하지 않는다.

이런 접근으로 스마트 컨트랙트 rollup을 빌딩하는 것은 ‘Solidity compatibility’를 유지하는 것이다. EVM 내에서 프로그램을 실행하지도 않고, 다른 이더리움 인터페이스와 호환성을 유지하지도 않지만, 솔리디티 개발자들은 이 rollup을 사용하여 코드를 작성할 수 있다. 따라서, rollup의 펀더맨탈 레이어와 절충하지 않고도 이더리움과 비슷한 개발자 경험을 제공할 수 있게 된다.

그러나, 이 접근 방식에는 몇 가지 추가적인 절충안이 있다. 첫 번째는 자신만의 VM을 구축하는 것이 어렵다는 것이다. 이더리움 팀은 EVM의 결함을 해결하기 위해서 오랜시간을 보냈고, 지금도 여전히 업그레이드 및 수정을 거치고 있다. 더 커스텀된 rollup은 더 좋은 성능을 보장하지만, 다른 모든 체인 및 rollup에 의해 EVM에 적용된 여러 이점을 잃게 된다.

다음으로, 트랜스파일러를 통해서 솔리디티를 지원하면, 결합성을 잃을 가능성이 있다. 만약 개발자들이 카이로와 솔리디티 모두 사용하여 컨트랙트를 작성하면, 둘 사이를 지원하는 인터페이스 툴이 불안정할 가능성이 있다. 지금까지, 거의 대부분의 스타크넷 프로젝트들은 카이로로 직접 작성되어, 아마도 향후 솔리디티 프로젝트들과 쉽게 결합하지 않을 가능성이 있다. 마지막으로, 아마도 가장 중요한 점은 스타크넷 팀은 현재 다른 이더리움 커포넌트와 호환하는 것을 목적으로 하지 않는다. 그들은 자체 클라이언트 API, 자바스크립트 라이브러리 그리고 월렛을 사용한다. 이는 이더리움 compaitble한 툴들이 스타크넷을 지원하는데 부담이 된다. 이는 매우 큰 어려움이지만 불가능하지는 않다. 위에 서술한 것처럼, 솔라나도 충분히 성공적으로 자체 표준을 개발하여 몇몇 이더리움 툴에 지지를 받았으니 말이다.

성공적으로 수행할 수만 있다면 스타크웨어 팀은 zk-rollup에 최적화된 최초의 스마트 컨트택트 VM으로 EVM이 퍼스트 무버로써 갔던 길을 가게 될 것이다.

zkSync

이 전략을 채택한 또 다른 팀은 바로 zkSync이다. zkSync는 레지스터 기반이며 자체 AIR(Algebraic Intermediate Representation)을 정의하는 VM(SyncVM)을 개발했다. 그런 다음 Yul(다른 EVM 버전에 대한 바이트 코드로 컴파일 할 수 있는 중간 언어, 낮은 수준의 솔리디티라고 볼 수 있음)을 LLVM-IR로 컴파일하는 특수 컴파일러를 구축한 다음 그들의 커스텀 VM에 대해 명령들을 컴파일 하였다. 이는 스타크웨어의 접근법과 유사하며, 이론적으로 베이스 언어들(비록 지금은 솔리디티 0.8.x 버전만 지원하지만) 에 대하여 유연하다. zkSync 팀은 원래 카이로와 같은 자체 언어를 개발했었으나, 지금은 L1 개발자들이 쉽게 이주할 수 있게 솔리디티 컴파일러를 개발하는 쪽으로 노선을 변경하였다. 일반적으로 그들의 전략은 스타크넷보다 이더리움 툴셋을 더 많이 재사용 한다. 나는 그들의 클라이언트 API 와 같은 것들이 더 ‘Ethereum compatible’하기를 기대한다.

zkSync는 커스텀 VM을 활용하여 오랫동안 이더리움 프로토콜의 핵심 목표였던, Account Abstraction과 같은 EVM과 호환되지 않은 기능을 제공한다. 이는 커스텀 VM이 제공하는 이점의 좋은 예시로, 이더리움이 새로운 기능을 구축할 때까지 기다릴 필요가 없다.

모든 것을 종합하였을 때 각 팀의 전략은 다음과 같다.

비탈릭 부테린의 zkEVM 타입 분류

비탈릭 부테린의 zkEVM 블로그는 현재 rollup 팀이 직면하고 있는 근본적인 딜레마를 강조하였다. EVM은 ‘검증 가능한 프로그램을 위해 빌딩 되지 않는다. 사실 우리는 위의 분석을 통해서 이더리움과 더 호환될 수록 ‘검증 가능 형식(verifiable format)’의 성능이 낮아진다는 것을 확인하였다. 비탈릭은 기존 EVM 인프라와 호환하는 정도에 따른 general purpose rollups 을 몇 가지 보드 카테고리로 나타냈다.

그의 이론을 확장할 수 있는 유일한 방법은 각 유형 내에서도 상당한 정도의 변동성이 있다는 점이다. 우리는 완전히 세분화 된 카테고리가 아닌 스펙트럼을 다루고 있다. 어플리케이션 레이어를 약간만 변경하는 Type 3 rollup은 어플리케이션 레이어를 전체적으로 변경했지만 기술적으로 새 VM을 도입하지 않은 Type 3 rollup 보다는 Type 2 rollup이 개발자 경험 관점에서 더 공통점이 있다. 그러나 새로운 VM을 기술적으로 도입하지 않으면 Type4 가 될 수 도 있다.

스마트 컨트랙트 롤업의 현재 상태

위의 많은 정보들로 인해서 이더리움 호환성에 대한 많은 혼란이 생겼을 것이다. 사실 어떤 zk-rollup도 완벽하게 모든 상황에서 EVM의 행동을 미러링할 수는 없다. 모두 정도의 문제이며, 구체적인 선택은 각각의 팀들이 몫으로 호환성을 단독으로 논하기 보단 유지성과 퍼포먹스를 함께 고려해야한다. 나의 개인적인 의견은 다음의 정의가 혼란을 정의해 줄 수 있다고 생각한다:

위의 접근 방식 중 어는 것도 본질적으로 우월하지 않다는 것을 이해하는 것이 중요하다. 계층이 아닌 범주이며, 그들은 더 쉬운 개발 및 유지 보수, 더 나은 성능, 더 쉬운 기존 툴과의 호환 사이에서 각각의 절충안을 만들어 낸다. 궁극적으로 rollup을 리딩하는 것은 순수한 기술력이 아닌 더 나은 유통 및 마케팅에 의해 결정된다. 또한, 옳은 기반 기술을 결정하는 것에 상당한 이점이 있음은 의심의 여지가 없다. EVM 사양에 대한 Scroll 팀의 열성적인 노력으로 EVM의 업그레이드에 쉽게 대응할 수 있을까? 다른 팀 보다 실용적인 접근 방식이 더 빨리 시장에 출시하는데 도움이 될까? 스타크웨어의 커스텀 VM + 트랜스파일러 방식이 장기적 확장을 위해 보다 견고한 기반을 만들어 낼까? 다른 팀이 퍼스트 무버의 실수에서 교훈을 얻고 그들에게 펀치를 날릴까? 궁극적으로 현재 이더리움 개발의 아름다움은 서로 다른 팀들이 공통의 목표를 향해서 서로 다른 접근 방식으로 나아가고 있다는 점이다.

그러나, 우리는 스마트 컨트랙트 rollup의 현재 준비 상태에 대해 냉정한 판단을 하는 것도 필요하다. 모든 팀은 자신을 ‘이제 막 세계를 장악하려 한다’고 하는 마케팅 동기를 가지고 있다. 그러나 빠르면 2022년 말까지 이더리움 스마트 컨트랙트 rollup의 ‘production-grade’는 없을 것이며 이들 중 많은 팀들이 2023년까지도 준비가 되지 않을 것이다. 스타크넷의 여정에 따르면 rollup이 테스트넷에 도달한 시점부터 메인넷에서 일관된 프로덕션 등 볼륨을 지원할 준비가 되려면 최소 1년의 반복을 예상해야 한다.

이 미성숙한 상태로 인해 applicaiton-specific rollup은 아직 이더리움의 보안성을 지키면서 확장성이 필요한 개발자들에게 가장 강력한 옵션으로 남아있다. 사실 general purpose rollup이 가능하게 되어 널리 통합되더라도, 고성능의 커스텀 된 신뢰 가능한 application specific rollup은 미래에도 여러 유즈 케이스에서 우위를 차지할 것으로 예상한다.

추가적인 Rollup 요소들

비록 이 글이 호환성과 퍼포먼스에 집중하긴 했지만, 그것은 이더리움 생태계의 모든 것은 아니다! 수 많은 다른 요소들의 당신이 특정 general purpose rollup에 개발을 해야 할지 말아야 할지 영향을 미친다. 몇 가지 기준을 제시하겠다:

수수료: rollup이 수수료를 네이티브 토큰으로 받는지 아니면 ETH로 받는지 혹은 좀 복잡하게 둘 다 섞어서 받는지? rollup은 계산을 하기 위해 수수료 토큰의 소유권을 요구하기 때문에, 수수료 구조는 유저와 개발자 경험에 큰 영향을 미친다.
증명 및 시퀀싱: 모든 rollup은 트랜잭션 정렬 및 proofs 생성에 책임을 요구한다. 오늘날 대부분의 application-spcific rollup은 “단일 시퀀서(single-sequencer)”로 복원력을 사용하여 더 높은 처리량을 생산한다. 대부분의 general purpose rollup은 초기에는 단일 시퀀서 rollup으로 시작하지만, 대부분 시간이 지나면서 시퀀서를 분산화할 계획을 가지고 있다.
자가 수탁(Self-Custody): zk-rollup의 핵심 전망은 이더리움의 보안성을 유지하면서 확장성을 늘리는 것이다. 그러나 많은 general purpose rollups은 현재 악의적이거나 이용불가능한 시퀀서가 생겼을 때 유저의 자산을 복구하는 정확한 매커니즘이 존재하지 않는다.
데이터 가용성(Data Availability): 도입부에 언급한 것처럼, self-custody의 보장성은 실패 상황에서 상태 데이터의 가용성에 달려 있다. 그러나, full data avaiability는 유저에게 추가 비용을 부가하여 데이터 가용성 모드의 스펙트럼으로 유도한다. 이미 application spcific rollup 세계(ex Validiums, Volitions)에서 사용되고 있으나, 각 general purpose rollup은 이 기능을 개별적으로 추가해야 한다.

Summary

스마트 컨트랙트 rollup은 이더리움 확장성 로드맵에 엄청나게 흥미로운 부분이다. 기존 이더리움 툴셋과의 관계에서 이러한 rollup에 의해 만들어진 다양한 트레이드 오프는 이더리움 개발자 생태계 다양성의 놀라운 증거이다.

그러나 EVM 호환성에 대한 현재 논의는 대부분 요점을 놓치고 있다. 개발자의 관점에서 모든 rollup들은 솔리디티 코드를 지원한다. 진정한 이더리움 호환성은 훨씬더 어려움이 있으며, 한 가지 사실은 부분적인 트레이드 오프가 있다는 것으로 개발자들은 rollup을 실행하기 전에 명심해야 한다. 현재 대부분의 rollup 프로젝트들은 대규모 ‘사전 판매(forward selling)’ 중이다. 그들은 오늘날(또는 12개월 안에) 가능한 것이 아닌 그들 능력의 3년 이상의 비전을 팔고 있으며, 이는 상당히 물을 흐리게 한다.

투명성을 위해서 나는 각각의 주요 rollup 팀들이 다음의 물음에 명확한 답을 내려주기를 바란다:

L1과 L2 사이 런타임의 정확한 차이는 무엇인가? 어떤 opcode를 L2에서 수정 가능한가? 다른 어떤 VM의 특징(ex 수수료 구조) 이 L1과 차이점을 갖는가?
커스텀 VM의 공식 사양은 어디에 있으며 다른 옵션보다 성능이 높거나 낮은 곳은 어떤 부분인가?
이 rollup으로 인해 다른 이더리움 인터페이스(ex: 클라이언트 AP|, 라이브러리) 가 얼마나 많이 변경되어 이더리움 툴들을 중단 시킬 수 있는가?
이 rollup이 테스트넷에 언제 가동되나? 메인넷에 가동되나? 1000 이상의 커스텀 컨트랙트 tps의 지속적인 생산 처리량을 지원할 수 있는가?
사용자 자산에 대한 완전한 self-custody를 언제 지원할 것으로 예상하며 general purpose rollup에서 어떤 맥락으로 판단하는가?

한번 rollup들이 테스트넷에 배포되면, 이 질문들은 쉽게 답할 수 있을 것이다. 그 전까지, 나는 이 팀들이 그들의 솔루션이 만들어 낼 정확한 트레이드 오프에 대해 더 테크니컬한 디테일을 배포하고, 그것이 어떻게 스마트 컨트랙트와 툴 개발자들 모두에게 어떤 영향을 미치는지 보고 싶습니다.

바로 앞에 merge라는 코너가 있고 배틀 테스트를 거친 application-specific rollups 그리고 general purpose rollup이 내년에 메인넷을 강타할 것이다. 이더리움 확장성의 미래는 바로 지금이다.

개인적인 코멘트

이뮤터블 X의 CTO가 쓴 Ground Up Guide: zkEVM, EVM Compatibility & Rollups 을 번역하며, zk rollup과 zkEVM에 대해서 아주 많은 것을 배울 수 있었습니다. 확장성이라는 문제 하나로 이렇게 수 많은 전략과 접근 방법이 나올 수 있다는 것이 굉장히 흥미로울 따름입니다. 한국어로 번역할 때보다 영어 그대로 적는 것이 더 의미를 잘 전달할 때가 있다고 생각해서 원문의 표현을 많이 차용했습니다. 비록 CS 지식 부족으로 인해서 많은 부분이 미흡하게 번역이 되었지만, 부디 구글 번역기 보다는 의미가 잘 전달 되었기를 바라며 지금까지 이 긴 글을 읽어준 누군가 에게 감사의 인사를 올립니다. (오역에 대한 지적은 언제나 환영입니다!)

원본링크

Ground Up Guide: zkEVM, EVM compatibility & Rollups

https://immutablex.medium.com/ground-up-guide-zkevm-evm-compatibility-rollups-787b6e88108e

[번역글] zk EVM 가이드, EVM 호환성과 롤업

Written by Cryptotraveler