Thread by @Hyunxukee

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

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

해당 트윗은 제 계정인 @0xgosu 의 트윗을 재 업로드한 것입니다. @Scroll_ZKP의 @LuozhuZhang이 작성한 zkEVM 아키텍처 설명을 번역하여 작성하였으며, 독자의 이해를 돕기위한 의역과 자료가 포함되어 있습니다.

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

https://twitter.com/LuozhuZhang/status/1538166119785111552

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을 처음부터 자체적으로 설계할 수 있어 EVM을 직접 지원하는 것 보다 오버헤드(overhead)가 적고 최적화할 수 있다는 장점이 있습니다.

1-4/
@gavofyork 는 EVM에 zkSNARK가 사용될 것이라 전혀 생각하지 못했을 겁니다. 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 @PrivacyScaling, @ConsenSys, @0xPolygonHermez

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

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

1-12/
이 단계에서 #Halo2 의 재귀적 증명을 사용하면, 전체 블록의 유효성을 증명하기 위해서 단 하나의 증명만 사용할 수 있습니다. 이렇게 되면, 동기화하는 노드들은 각 블록에 대한 증명을 하나씩 검증할 필요가 없고, 마지막 증명만 검증하면되어 효율성이 높아집니다.
medium.com/@hyun-jeong/%E…

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

1-14/
zkEVM의 궁극적인 목표는 L1에 실제로 적용되어 현재의 EVM을 대체하는 것입니다. 이는 EF(@PrivacyScaling)와 @Scroll_ZKP 그리고 ZK 영역에 기여하는 사람들 모두의 궁극적인 목표입니다.

@VitalikButerin의 이더리움 로드맵의 마지막 파트 참고

https://twitter.com/VitalikButerin/status/1466411377107558402

2. 영지식 증명

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

@Zac_Aztec의 스레드를 참고 (#Plonk 와 @aztecnetwork 의 창립자)

https://twitter.com/Zac_Aztec/status/1440295503938215947

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)의 오버헤드를 줄이는데 매우 중요합니다. 나중에 native zkEVM 아키텍처에서 이 두 가지 기능을 자주 사용한다는 것을 알게됩니다.

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

- 송금 트랜잭션의 제약(조건) : “잔액 > 송금액”
- 회로 : 잔액과 송금액을 찾아 그 값을 비교하는 코드

3. native zkEVM의 아키텍처

3-1/
앞서 언급했듯이, native zkEVM은 zkRollup에서 사용될 뿐만 아니라 지금의 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/
@Scroll_ZKP 팀은 여러가지 시도끝에, 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을 연구하는 동안, 그 이면에 있는 수학적 메커니즘에 깊은 인상을 느꼈고, 이 글을 읽은 모두가 이 혁신의 최전선에 함께하고 있다고 생각합니다.

유익하셨다면 종종 놀러오세요 :)

https://twitter.com/Hyunxukee/status/1604727330433208321