Thread by @0xgosu

[zkEVM이 블록체인 산업의 궁극적인 목표인 이유]

급변하는 산업의 참여자들은 언제나 각자 다른 산업의 형태를 꿈꾸고 있다. 무엇이 옳은지, 혹은 무엇이 살아남을지 지금의 우리는 알 수 없겠지만, 적어도 나는 #zkEVM 이 블록체인 산업에서 바라봐야 할 궁극적인 형태이자 목표 중 하나라 믿는다.

해당 트윗은 @Scroll_ZKP 의 @LuozhuZhang 이 작성한 zkEVM 아키텍처 설명을 번역한 것이며, 독자의 이해를 돕기위한 의역도 많고, 원본에는 없는 자료도 있습니다.

번역을 허락해준 @LuozhuZhang에게 감사의 말씀을 드립니다.

https://twitter.com/LuozhuZhang/status/1538166119785111552?s=20&t=IgPeycZxV1ysk2nl04VXDw

1. zkEVM을 구별하는 세 가지 단계

1-1/ 모든 zkVM이 zkEVM과 동일한 것은 아니며, zkEVM 자체도 세 가지 단계로 나뉜다.

@drakefjustin 의 아래 자료를 참고하길 바란다.

1-2/ 언어 단계(language-level)
이는 EVM 친화적 언어(Solidity, Yul 등)를 영지식 친화적 언어(@zksync 의 Zinc, @StarkWareLtd의 Cairo 등)로 바꾸는 단계이다.

이 단계에서 만들어진 Zinc 및 Cario 코드들은 자체 VM에서 실행되며, 이는 이더리움의 VM(EVM)과 전혀 다를 수 있다.

1-3/
이렇게 언어를 바꾸는 솔루션의 장점은 EVM의 설계 방식에 제한 받지 않고 영지식 친화적인 VM을 처음부터 자체적을오 설계할 수 있다는 것이다.

1-4/
사실, @gavofyork는 zk-SNARK가 EVM에 사용될 것이라 전혀 생각하지 못했을 것이다. 영지식 회로가 EVM에 효과적으로 적용되도록 설계되지 않았기 때문에 직접 적용할 경우 엄청난 오버헤드가 발생할 것이다.
자세한 내용은 @yezhang1998의 아티클을 참고하길 바란다.
hackmd.io/@yezhang/S1_KM…

1-5/
이 솔루션의 단점은 좋은 개발자 경험(Dex)를 얻기 어렵다는 것이다. 이러한 zkVM은 하위에 있는 자체 언어의 명령어 집합(instruction set)을 사용하며, 중요한 EVM 옵코드(opcode)를 많이 지원하지 않는다.

1-6/
따라서 개발자는 좋은 Dex를 얻기위해 zkVM의 고유 언어(Zinc, Cairo)를 따로 배워야한다. 이로 인해, zkRollup이 L1 생태계를 직접 상속받지 못할 수 있으며, L2 개발자와 언어가 분리될 수 있다 (언어를 새로 배우는 것은 언제가 추가적인 진입장벽을 만든다..)

1-7/ 바이트코드 단계(bytecode-level)
이 단계는 EVM과 동등하게, 솔리디티 언어 단계와의 호환성을 달성할 수 있을 뿐만 아니라 EVM의 옵코드 단계와도 완전한 호환성을 달성할 수 있는 단계이다.

1-8/
사실 바이트코드 단계에 도달해야 zkEVM이라 부를 수 있다(언어 단계는 zkVM이라고 부르는게 맞다). zkEVM에서 개발자는 좋은 Dex를 얻을 수 있으며, L1의 Dapp과 개발 도구는 기본적으로 수정 없이 L2로 마이그레이션될 수 있다.

1-9/
현재 바이트코드 단계의 zkEVM을 목표로하고 있는 프로젝트는 다음과 같다: @Scroll_ZKP, Ethereum Foundation, @ConsenSys, @0xPolygonHermez

1-10/ 컨센서스 단계(consensus-level)
이 단계는 최종적인 zkEVM으로, 언어와 바이트코드 뿐만 아니라 컨센서스 단계에서도 호환성을 달성하는 단계이다.

1-11/
zkEVM이 컨센서스 단계의 호환성을 달성하게 된다면, L1의 마이너가 블록 생성시 해당 블록에 대한 증명을 생성하고 모든 노드가 이를 동기화할 때, 트랜잭션의 재연산 없이 마이너가 만든 블록에 대한 증명의 유효성만 검증하면 된다.

1-12/
이 단계에서 #Halo2 의 재귀적 증명(recursive proof)을 사용한다면, 전체 블록의 유효성을 증명하기 위해서 단 하나의 증명만 사용할 수도 있다. 이렇게 되면, 동기화하는 노드들은 각 블록에 대한 증명들을 하나씩 검증할 필요가 없고, 마지막 증명만 검증하면되어 효율성이 높아진다.

1-13/
컨센서스 단계의 zkEVM이 이루어진다면, 이더리움 노드의 동기화가 이루어지는 몇 초에서 몇 분 정도 뒤에 누구나 쉽게 이더리움 네트워크에 합류할 수 있고, 결과적으로 이더리움은 더 분산화되고 강건해질 것이다.

1-14/
zkEVM의 궁극적인 목표는 L1에 실제로 적용되어 현재의 EVM을 대체하는 것이다. 이는 EF(@PrivacyScaling)와 @Scroll_ZKP 그리고 우리와 함께 일하는 모두의 궁극적인 목표이다.

자세한 내용은 @VitalikButerin의 이더리움 로드맵의 마지막 파트를 참고하길 바란다.

https://twitter.com/VitalikButerin/status/1466411377107558402?s=20&t=8Jh0ZBpHEQ-OHkd-FUxIWTrHm__xpf30shuUxRJUGKE

2. 영지식 증명

2-1/ zkEVM을 실현하기 위한 방안들
zkEVM을 현실로 만들 수 있는 몇 가지 암호학 혁신들이 있는데, 그 중 가장 중요한 것은 #Plonk 와 #Halo2 이다.

자세한 내용은 #Plonk와 @aztecnetwork 의 창립자인 @Zac_Aztec의 스레드를 참고하길 바란다.

https://twitter.com/Zac_Aztec/status/1440295503938215947?s=20&t=T7RJD93CBFoasvwJ7QiyVg

2-2/
Plonk는 Sonic과 다항식 commitment를 기반으로하는 혁신이다.

(한 가지 양해를 구하자면, commitment가 한국어로 확약, 약속 등으로 번역되는데, 대한수학회에서 제공하는 용어 사전을 뒤져봐도 이를 대체할만한 좋은 단어를 찾을 수 없어서 commitment는 영어 단어 그대로 사용하고자합니다.)

2-3/
Sonic을 기반으로한 Plonk는 "보편적이고 업데이트 가능한(universal and updateable)" 신뢰할 수 있는 셋업(trusted setup)을 가지고 있다. 즉, Plonk는 단 하나의 셋업만 필요하고 이는 언제든 재사용 될 수 있다는 것을 의미한다.

2-4/
다항식 commitment를 기반으로 하면, groth16 및 다른 zk-SNARK 증명 스킴에서 널리 사용되고 있는 R1CS보다 더 표현력이 뛰어난 PLONKish 산술화(Arithmetization)를 사용할 수 있다.

2-5/
또한, zkEVM은 Plonkish의 매우 중요한 기능인 "custom gate"와 "lookup table argument"를 사용한다.

github.com/fluidex/awesom…

2-6/
Plonk의 이 두 가지 기능을 통해 고도화된 맞춤형 제약(constraints)를 작성할 수 있으며, 이는 회로(circuit)의 오버헤드(overhead)를 줄이는데 매우 중요하다. 나중에 native zkEVM 아키텍처에서 이 두 가지 기능을 자주 사용한다는 것을 알게될 것이다.

2-7/
영지식 증명에서 제약(constraints)은 각 항목이 만족해야하는 조건들의 나열이고, 회로(circuit)는 조건을 만족하는 값을 찾기 위한 표현방식(코드)라고 이해하면 쉽다.

예를 들어, 송금 트랜잭션의 제약(조건)은 “잔액 > 송금액”이고, 회로는 잔액과 송금액을 찾아 그 값을 비교하는 코드다.

3. native zkEVM의 아키텍처

3-1/
앞서 언급했듯이, native zkEVM은 zkroolup에서 사용될 뿐만 아니라 지금의 L1의 EVM을 대체할 것이므로, 디자인/코드 및 아키텍처를 익히는 것은 아주 큰 의미가 있을 것이다(이걸 아는 당신은 혁신의 최전선에 있는 것!)

3-2/
zkEVM은 native EVM과 custom EVM으로 나눠진다. 간단히 말해서 zk proof로 구현하는 opcode의 종류가 native인지 custom인지에 따라 다르다.

자세한 내용은 @Sin7Y_Labs 의 아티클을 참고하길 바란다.
hackernoon.com/exploring-popu…

3-3/
잘 알려진 EVM의 기능은 트랜잭션을 통해 state1에서 state2로 이동시키는 상태 머신이므로, 가장 작은 상태 변화를 유도하는 연산을 트랜잭션이라고 이해할 수 있다(실제로는 트랜잭션이 아니라 트레이스(trace)라고 한다).

3-4/
즉, 트랜잭션을 가져와서 이를 제약 및 증명(constraint/prove)할 수 있다면, 실제로 상태 머신 전체를 제약 및 증명할 수 있게 된다.

3-5/
zkEVM의 기본 아이디어는 EVM을 제약하는 EVM 회로를 생성하여, EVM의 모든 실행 로직이 올바른지 증명하는 것이다.

3-6/
이 EVM 회로는 모든 트랜잭션과 해당 트랜잭션에 의해 호출된 특정 옵코드를 얻을 수 있다.

그런 다음 이 회로는 다음 사항들이 완전히 정확한지 증명한다: 상태 변경에 사용된 트랜잭션, 트랜잭션에 의해 호출된 옵코드, 옵코드들의 연산 논리, 연산 순서

3-7/
우리는 여러가지 시행끝에, EVM을 제약하기 위한 회로를 단 한개만 사용한다면, 그 회로는 너무 거대해져 불필요한 복잡성과 오버헤드가 증가하게 된다는 것을 알게되었다.

3-8/
그래서 우리는 EVM의 각기 다른 모듈을 위한 하위 회로 및 테이블(sub-circuits/table)을 설계했다. 이를 통해, 증명을 만들때는 관련된 테이블을 쿼리(query)하기만 하면 된다.

테이블에는 필요한 조건에 따라 다른 변수를 채울 수 있다.

3-9/
예를 들어, 메모리/스택/스토리지의 읽기 및 쓰기의 로직을 증명하는 경우 EVM 회로는 상태 테이블(State table)을 쿼리하면 된다(그럼 테이블 아래에 있는 하위 회로(State Circuit)를 사용할 수 있게된다).
옵코드와 관련된 연산의 경우, EVM 회로는 바이트코드 테이블을 쿼리하면 된다.

3-10/
하위 회로는 제약에 관련된 연산을 포함한 또 다른 하위 테이블을 쿼리한다. 상태 회로는 스토리지와 관련된 연산을 제약할 때 MPT 연산을 사용하기 때문에, MPT 테이블을 쿼리한다. 트랜잭션 회로(Tx Circuit)는 해시와 트랜잭션 서명을 검증할 때 Keccak와 서명 테이블(Sig table)을 쿼리한다.

3-11/
물론 이 테이블이 고정된 값은 아니고, 다른 연산이 필요하다면 이와 관련된 다른 값들로 채워질 수 있다. 이것이 zkEVM이 보편적인 도구가 될 수 있는 이유 중 하나이다.

한편, 테이블이 고정된 값이 아니기 때문에 악의적인 증명자가 유효하지 않은 테이블을 만들어 증명을 위조할 수 있다.

3-12/
따라서, 테이블 자체의 정확정을 보장하는 것도 중요하다. 우리는 이를 위해 각 테이블에 대한 회로를 설계하고, 각 회로에서는 테이블이 완전히 올바른지 보장하기 위한 특정 다항식 제약을 포함한다.

3-13/
트랜잭션(trace)가 EVM 회로에 포함될 때, 모든 연산(옵코드, 스택/스토리지 등)은 재정렬된 다음 하위 회로에 할당된다. 이러한 하위 회로는 연산의 정확성을 증명하고 증거를 생성한다.

3-14/
마지막으로, 이 하위 회로에 의해 생성된 증명은 공개 입력값으로 aggregation 회로에 입력되고, aggregation 회로는 이러한 각각의 단일 증명을 모아 aggregate 증명으로 만든다.

3-15/
이후, aggregate 증명은 L1의 컨트랙트로 전송되어 유효성을 검증받는다. 아래 그림은 @Scroll_ZKP 만들고 있는 #zkEVM의 하이레벨 워크플로우이다.

4. 끝 그리고 시작
#zkEVM 은 “zk everything”의 마일스톤이자, 실용적인 영지식 증명 시스템이 성숙한 후에나 나타날 수 있는 혁신이다.
#zkEVM 을 연구하는 동안, 그 이면에 있는 수학적 메커니즘에 깊은 인상을 느꼈다. 저는 zk가 엄청난 혁신이며, 우리가 이 혁신의 최전선에 있다고 믿는다.