OlaVM에 대해 자세히 설명

Sin7y

特邀专栏作者

2022-12-19 10:50

이 기사는 약 3179자로, 전체를 읽는 데 약 5분이 소요됩니다

OlaVM의 현재 진행 상황과 향후 계획

TL;DR

첫 번째 레벨 제목

1. 우리는 PE-VM 기반의 첫 번째 ZKVM을 구축하기 위해 열심히 노력하고 있습니다. ZK 친화적인 설계와 ZK 알고리즘의 개선을 통해 더 높은 처리율을 가지며 기술적 특징은 다음과 같습니다.

a. 빠른 증명:

i. ZK 친화적: 더 작은 회로 규모와 단순화된 기본 제약 단위를 얻습니다.

ii. 더 빠른 ZK 구현: plonky 2에 대한 추가 최적화 개선;

b. 빠른 실행:

병렬 실행 VM을 채택합니다(병렬 증명 기술의 맥락에서 증명 생성 시간이 짧을수록 효과가 더 분명해집니다).

2. 우리가 한 일:

a. 2022년 7월 OlaVM의 백서가 공개되었습니다.

c. 현재 실행 효율성이 가장 빠른 ZK 알고리즘의 경우 plonky 2의 회로 설계 및 알고리즘 연구를 완료했으며 다음 링크를 열 수 있습니다. https://github.com/Sin 7 Y/plonky 2/tree/ main/plonky 2/ 디자인 plonky 2의 디자인에 대해 자세히 알아보려면 다음 단계에서 최적화하고 개선할 것입니다. 계속해서 관심을 가져주세요. . .

첫 번째 레벨 제목

우리 뭐해

OlaVM은 병렬 실행 VM을 도입한 최초의 레이어 2 ZKVM으로, 두 체계의 기술 포인트를 통합하여 더 빠른 실행 속도와 더 빠른 증명 속도를 얻어 향후 더 높은 시스템 처리량을 달성합니다.

현재 이더리움 시스템에서 느린 처리량에는 두 가지 주요 이유가 있습니다.

1. 합의 프로세스: 각 노드는 트랜잭션의 유효성을 검증하기 위해 트랜잭션을 반복적으로 실행합니다.

2. 트랜잭션 실행: 트랜잭션 실행은 단일 스레드입니다.문제의 첫 번째 포인트를 해결하고 동시에 프로그래밍 가능해야 하기 위해 많은 프로젝트에서 ZK(E)VM에 대한 연구를 수행했습니다. 즉, 트랜잭션이 체인에서 완료되고 상태만 확인됩니다. 체인에서(물론 여기에서 논의하지 않을 다른 확장 솔루션이 있습니다. 세부 정보가 너무 많음) 실제로 시스템 처리량을 개선하려면 다음이 필요합니다.가능한 한 빨리 증명을 생성하십시오

이 단계에서 ZK(E)VM의 경우 전체 시스템의 처리량에 영향을 미치는 병목 현상은 증명 생성에 있지만 병렬 증명을 사용하여 전체 시스템의 처리량을 가속화하면 블록이 더 빨라집니다. 생성된 해당 증명이 생성됩니다. 시작 시간이 빠를수록(ZK 알고리즘의 진화와 가속 방법의 개선으로 증명 생성 시간이 짧을수록 이 모듈의 개선 효과가 더 분명해집니다).

높은 처리량을 달성하는 방법은 무엇입니까?

보조 제목

가능한 한 빨리 증명 생성(현재 최우선 순위)

증명 생성을 가속화하기 위해 대략 두 부분으로 나눌 수 있습니다: 가능한 가장 작은 회로 크기와 가능한 가장 빠른 알고리즘 실행; 가능한 가장 빠른 알고리즘 실행은 다음으로 나눌 수 있습니다. 소규모 도메인 선택 등) 및 외부 실행 환경 개선(예: 하드웨어 가속).

1. 가능한 한 작은 제약 크기

a. Prophet

예, 증명 생성의 소비는 제약 조건의 전체 규모 n과 밀접한 관련이 있습니다. 제약 조건의 전체 규모를 크게 줄일 수 있다면 증명 생성 시간이 크게 단축될 것입니다. 이를 위해서는 VM 설계에서 전체 제약 조건 크기를 줄이기 위해 가능한 한 많은 설계를 사용해야 합니다.

b. Zk-friendly

Prophet은 "예언자", 먼저 "예측", 그 다음 "검증"을 의미하며 주요 목적은 다음과 같습니다. 일부 복잡한 계산의 경우 이러한 복잡한 계산을 구현하기 위해 VM 명령어를 사용할 필요가 없습니다(많은 명령어를 소비할 수 있으므로 (VM의 실행 궤적 및 최종 제약 스케일을 증가시키기 위해) 대신 내장된 Prophet을 사용하여 계산을 완료하고 결과를 VM으로 전송한 다음 VM은 결과에 대한 적법성 검사만 수행합니다. . Prophet은 나눗셈 계산, 제곱근 계산, 세제곱근 계산 등과 같은 특정 계산 기능이 있는 일부 내장 함수입니다. 실제 시나리오에 따라 Prophets 라이브러리를 점진적으로 풍부하게 하여 가장 복잡한 계산 시나리오의 경우 전체 제약 조건이 감소 효과가 극대화됩니다.

계산이 복잡할 때 Prophet은 VM이 실행하는 궤적의 크기를 줄이는 데 도움을 줄 수 있지만 그 전에 계산 자체가 Zk 친화적인 것을 선호합니다. 따라서 설계에서 일반적인 해시 알고리즘, 서명 확인 알고리즘 등과 같은 일부 Zk 친화적인 작업을 사용할 것입니다. 이러한 최적화는 다른 ZK(E)VM 솔루션에도 종종 존재합니다. Zk 친화적인 복잡한 계산을 선택하고 더 작은 제약 조건으로 이 복잡한 계산을 제한하는 방법은 무엇입니까?

컴퓨팅 논리를 실행하는 것 외에도 VM 자체에는 RAM 작업과 같이 입증해야 하는 다른 작업도 있습니다. 스택 기반 VM은 액세스할 때마다 POP 및 PUSH 작업을 수행해야 합니다. 확인 수준에서 이 작업의 유효성을 확인해야 합니다. 이러한 작업은 독립적인 테이블을 형성한 다음 제약 조건을 사용하여 이러한 작업을 확인합니다. 스택 작업의 효율성: 레지스터 기반 VM이 동일한 논리를 수행하는 동안 결과 실행 추적이 더 작아서 제약 조건 규모도 더 작습니다.

Plonky 2의 놀라운 성능으로 인해 일시적으로 Plonky 2를 OlaVM의 ZK 백엔드로 사용합니다. 우리는 Plonky 2의 Gate 디자인, Gadget 디자인 및 프로토콜 원리를 깊이 분석하고 몇 가지 최적화 방향을 찾았습니다.Plonky 2 디자인에 대해 자세히 알아보려면 Github Repo: Plonky 2 디자인을 따르십시오.

보조 제목

더 빠른 트랜잭션 실행(이 단계에서는 병목 현상이 아님)

증명 생성이 몇 시간과 같이 오랜 시간이 걸리면 병렬 실행으로 인한 개선이 명확하지 않습니다. 이 병렬 처리로 인한 효과를 개선할 수 있는 두 가지 시나리오가 있습니다. 양적 변화 질적 변화를 일으키며 다른 하나는 증명 시간이 크게 단축된다는 것입니다. 물론 두 프로모션 효과가 중첩된다면 더 좋겠죠.