머리말

머리말

이더리움 가상머신은 이더리움 블록체인에 구축된 코드 운영 환경으로 계약 코드는 외부와 완전히 분리되어 EVM 내부에서 실행될 수 있으며 주요 기능은 이더리움 시스템에서 스마트 계약을 처리하는 것입니다. Ethereum이 Turing complete인 이유는 개발자가 Solidity 언어를 사용하여 EVM에서 실행되는 응용 프로그램을 만들 수 있고 계산 가능한 모든 문제를 계산할 수 있기 때문입니다. 하지만 튜링 완전성만으로는 부족하고 사람들도 EVM을 ZK 증명 방식으로 캡슐화하려고 하는데 문제는 캡슐화할 때 중복이 많이 된다는 점입니다. Fox가 발명한 "작은 테이블 모드" zkEVM은 기본 Solidity Ethereum 개발자가 zkEVM으로 원활하게 마이그레이션할 수 있도록 할 뿐만 아니라 EVM을 ZK 증명 시스템으로 캡슐화하는 중복 비용을 크게 줄입니다.

EVM은 2015년에 시작된 이래 엄청난 ZK 변환을 겪고 있습니다. 이 주요 변환에는 두 가지 주요 방향이 있습니다.

첫 번째 방향은 소위 zkVM 트랙입니다.이 트랙 프로젝트는 응용 프로그램의 성능을 최적으로 향상시키는 데 전념하며 Ethereum 가상 머신과의 호환성은 주요 고려 사항이 아닙니다. 여기에는 두 가지 하위 방향이 있는데 하나는 자신만의 DSL(Domain Specific Language)을 만드는 것입니다. 두 번째는 RISC Zero가 C++/Rust와 호환되는 zkVM을 만들기 위해 노력하는 것과 같이 비교적 성숙한 기존 언어와 목표가 호환된다는 것입니다. 이 트랙의 어려움은 명령어 세트 ISA의 도입으로 인해 최종 출력에 대한 제약 조건이 더 복잡해진다는 것입니다.

두 번째 방향은 이른바 zkEVM 트랙입니다.이 트랙 프로젝트는 EVM 바이트코드의 호환성, 즉 바이트코드 수준의 EVM 코드와 무엇보다도 ZkEVM을 통해 해당 영지식 증명을 생성하므로 네이티브 솔리디티 이더리움 개발자가 무료로 zkEVM으로 마이그레이션할 수 있습니다. 이 트랙의 플레이어는 주로 Polygon zkEVM, Scroll, Taiko 및 Fox를 포함합니다. 이 트랙의 어려움은 ZK 증명 시스템에서 캡슐화에 적합하지 않은 EVM의 중복 비용과 호환된다는 것입니다. 오랜 시간의 생각과 논쟁 끝에 Fox는 마침내 1세대 zkEVM의 엄청난 중복성을 근본적으로 줄이는 열쇠인 "소형 테이블 모드" zkEVM을 찾았습니다.

데이터 및 증명 회로는 증명을 생성하는 zkEVM의 두 가지 핵심 요소입니다. 한편으로 zkEVM에서 증명자는 트랜잭션에 의해 발생한 상태 전송이 정확하다는 것을 증명하기 위해 트랜잭션에 관련된 모든 데이터가 필요하지만 EVM의 데이터는 크고 복잡합니다. 따라서 증명에 필요한 데이터를 어떻게 정리하고 정리하느냐는 효율적인 zkEVM 구축을 위해 신중하게 고민해야 할 문제입니다. 한편, 일련의 회로 제약을 통해 계산 실행의 유효성과 정확성을 효율적으로 증명(또는 검증)하는 방법은 zkEVM의 보안을 보장하는 기반입니다.

이미지 설명

그림 1: 대형 테이블과 소형 테이블을 위한 2세대 zkEVM 솔루션

예를 들어, 우리는 각 요소의 변경 사항을 스택에 모으고, 특별히 스택 회로 증명을 작성하고, 순수 산술 연산을 위한 산술 회로 세트를 작성하는 등의 작업을 수행합니다. 이렇게 하면 각 회로에서 고려해야 할 상황이 상대적으로 단순해집니다. 서로 다른 기능을 가진 이러한 회로는 서로 다른 zkEVM에서 서로 다른 이름을 가지고 있습니다.어떤 사람들은 직접 회로라고 부르고 다른 사람들은 (하위)상태 기계라고 부르지만 아이디어의 본질은 같습니다.

이 작업을 수행하는 의미를 더 명확하게 설명하기 위해 덧셈 연산을 증명하려는 경우(스택의 상위 2개 요소를 꺼내고 합계를 스택의 맨 위에 다시 배치)를 가정하여 예를 들어 보겠습니다.

원래 스택이 [ 1, 3, 5, 4, 2 ]라고 가정합니다.

그런 다음 분류 및 분할을 수행하지 않으면 위 작업 후 스택이 [ 1, 3, 5, 6 ]이 됨을 증명해야 합니다.

그리고 분류가 분할된 경우 다음 항목만 별도로 증명하면 됩니다.

스택 회로:

C 1 : [ 1, 3, 5, 4, 2 ]가 2와 4를 팝하고 [ 1, 3, 5 ]가 됨을 증명하십시오.

C 2 : 푸시( 6) 후 [ ​​1, 3, 5 ]가 [ 1, 3, 5, 6 ]이 됨을 증명하시오.

산술 회로:

C 3 ：a= 2, b= 4,c= 6 , a+b=c임을 증명

이미지 설명

그림 2: 1세대 zkEVM이 채택한 대형 테이블 모델

일단 분류를 나누면 각 부분의 상황이 상대적으로 단순해지기 때문에 증명의 어려움이 많이 줄어들 것이다.

그러나 분류 및 분할은 다른 문제, 즉 다른 유형의 회로의 데이터 일관성 문제를 야기합니다.예를 들어 위의 예에서 실제로 다음 두 가지를 증명해야 합니다.

C 4 : "C 1에서 터진 숫자" = "C 3에서 a와 b"

C 5 : "C 2에서 누르는 횟수" = "C 3에서 c"

이 문제를 해결하기 위해 첫 번째 질문, 즉 트랜잭션과 관련된 데이터를 어떻게 구성할 것인가로 돌아가서 이 주제에 대해 다음에 논의할 것입니다.

직관적인 방법은 다음과 같습니다. 추적을 통해 모든 트랜잭션에 관련된 각 단계를 분해하고 관련된 데이터를 알고 추적에 없는 데이터 부분을 얻기 위해 노드에 요청을 보낼 수 있습니다. 다음과 같이 큰 테이블 T로 배열됩니다.

"첫 단계 작업" "첫 단계 작업에 관련된 데이터"

"두 번째 단계 작업" "두 번째 단계 작업에 관련된 데이터"

..."n번째 작업" "n번째 작업에 관련된 데이터"

따라서 위의 예에서 다음을 기록하는 행이 있습니다.

"단계 k: 덧셈" "a= 2, b= 4, c= 6 "

그리고 위의 C 4는 다음과 같이 증명할 수 있습니다.

C 4(a): C 1이 팝한 숫자는 큰 테이블 T의 k번째 단계와 일치합니다.

C 4(a): C 3의 a와 b는 큰 테이블 T의 단계 k와 일치합니다.

이미지 설명

그림 3: Fox가 발명한 "작은 테이블 모드" zkEVM

다음과 같은 일련의 테이블 구성을 고려합니다.

형식 타:

"a 유형의 첫 번째 작업" "a 유형의 첫 번째 작업과 관련된 데이터"

"a 유형의 두 번째 작업" "a 유형의 두 번째 작업에 관련된 데이터"

..."유형 a의 m번째 작업" "유형 a의 m번째 작업과 관련된 데이터"

형식 Tb:

"유형 b의 첫 번째 작업" "유형 b의 첫 번째 작업과 관련된 데이터"

"유형 b의 두 번째 작업" "유형 b의 두 번째 작업과 관련된 데이터"

..."유형 b의 m번째 연산" "유형 b의 n번째 연산과 관련된 데이터"

…이러한 방법으로 여러 개의 작은 테이블을 구성하는 것의 장점은 필요한 데이터에 관련된 작업 유형에 따라 해당하는 작은 테이블에서 직접 조회를 수행할 수 있다는 것입니다.이렇게 하면 효율성이 크게 향상될 수 있습니다.

간단한 예(한 번에 하나의 요소만 조회할 수 있다고 가정)는 8개의 문자 a~h가 [a, b, c, d, e, f, g, h]에 존재한다는 것을 증명하려는 경우 크기가 8인 테이블에 대해 8번의 조회를 수행해야 하지만 테이블을 [a, b, c, d]와 [e, f, g, h]로 나누면 4번의 조회만 수행하면 됩니다. 각각의 테이블!

결론적으로

결론적으로

Fox가 발명한 "작은 테이블 모드" zkEVM은 기본 Solidity Ethereum 개발자가 무료로 zkEVM으로 마이그레이션할 수 있도록 보장할 뿐만 아니라 EVM을 ZK 증명 시스템으로 캡슐화하는 중복 비용을 크게 줄입니다. 이것은 zkEVM 구조의 주요 변화이며, 이더리움의 확장 계획에 지대한 영향을 미칠 것입니다.