저자: Ye Zhang@Scroll
Vitalik Buterin, Barry Whitehat, Chih-Cheng Liang, Kobi Gurkan 및 Georgios Konstantopoulos의 검토 및 통찰력에 감사드립니다.
너무 오래
우리는 zk-Rollup이 "스위트 스팟"이 될 것이라고 믿습니다. 비용 이점과 극도로 높은 보안으로 인해 많은 레이어 2 확장성 솔루션이 비교할 수 없게 됩니다. 그러나 기존 zk-Rollup 구현은 모두 애플리케이션 특정적이므로 특정 zk-Rollup 내에서 구성 가능한 범용 dApp을 구축하기 어렵고 기존 애플리케이션을 마이그레이션하는 것이 불가능합니다. 일반 EVM 검증을 위한 영지식 증명을 생성하기 위해 zkEVM을 도입합니다. 이러한 방식으로 EVM과 완벽하게 호환되는 zk-Rollup을 구축할 수 있으므로 기존 Ethereum 애플리케이션을 이 zk-Rollup으로 쉽게 마이그레이션할 수 있습니다.
배경
배경
zk-Rollup은 최고의 이더리움 확장성 솔루션으로 인정받고 있습니다. 보안 측면에서 Ethereum Layer 1과 비교할 수 있을 뿐만 아니라 트랜잭션 완료 속도 측면에서도 Layer 2 솔루션의 리더입니다(자세한 비교 분석(원문, 번역)을 보려면 여기를 클릭).
중장기적으로 ZK-SNARK 기술의 지속적인 개발로 zk-rollup은 모든 애플리케이션 시나리오에서 선두를 차지할 것입니다. ——비탈릭 부테린
zk-Rollup의 기본 원칙은 많은 수의 트랜잭션을 롤업 블록으로 압축하고 블록 오프 체인에 대한 간결한 증명을 생성하는 것입니다. 그런 다음 레이어 1의 스마트 계약은 이러한 트랜잭션을 다시 실행할 필요 없이 새 상태를 직접 적용하기 위해 이 증명만 확인하면 됩니다. 이는 증명의 검증 비용이 재실행의 계산 비용보다 훨씬 낮기 때문에 가스를 크게 절약할 수 있습니다. 또 다른 이점은 데이터 압축을 통해 저장 공간을 절약할 수 있다는 것입니다(즉, 검증을 위해 최소한의 데이터만 온체인에 저장됨).
zk-Rollup은 안전하고 효율적이지만 그 적용은 여전히 지불 및 스왑으로 제한됩니다. 범용 dApp은 다음 두 가지 주요 이유로 구축하기 어렵습니다.
첫째, zk-Rollup 내에서 dApp을 개발하려면 모든 스마트 계약의 논리를 작성하기 위해 특수 언어(즉, R1CS)를 사용해야 합니다. 이 언어는 복잡한 구문을 가지고 있으며 사용자가 영지식 증명에 능숙해야 합니다.
둘째, 기존 zk-Rollup 구현은 구성 가능성1을 지원하지 않습니다. 따라서 레이어 2에서 서로 다른 zk-Rollup 애플리케이션은 서로 상호작용할 수 없으며, 이는 DeFi 애플리케이션의 결합성을 심각하게 손상시킵니다.
즉, zk-Rollup은 현재 개발자에게 친숙하지 않으며 기능이 제한되어 있습니다. 이것이 우리가 해결하고자 하는 가장 큰 문제입니다. 우리는 네이티브 EVM 검증을 직접 지원하여 최고의 개발자 경험을 제공하고 레이어 2에서 구성성을 지원하여 기존 이더리움 애플리케이션을 그대로 zk-Rollup으로 마이그레이션할 수 있기를 원합니다.
zk-Rollup에서 범용 dApp 구축
두 가지 방법으로 zk-Rollup 내에서 범용 dApp을 구축할 수 있습니다.
하나는 다양한 dApp을 위한 애플리케이션별 회로("ASIC")를 구축하는 것입니다.
다른 하나는 스마트 계약을 실행하기 위한 범용 "EVM" 회로를 구축하는 것입니다.
"회로"는 영지식 증명에 사용되는 프로그램 표현을 나타냅니다. 예를 들어 hash(x) = y임을 증명하려면 해시 함수를 회로 형태로 다시 작성해야 합니다. 회로 형식은 매우 제한된 표현만 지원합니다(즉, R1CS는 덧셈과 곱셈만 지원함). 따라서 회로 언어로 프로그램을 작성하는 것은 매우 어렵습니다. 덧셈과 곱셈만 사용하여 모든 프로그램 논리(if else, 루프 등 포함)를 구축할 수 있습니다.
첫 번째 방법은 개발자가 다양한 dApp을 위한 전용 "ASIC" 회로를 설계해야 합니다. 이것은 영지식 증명을 사용하는 가장 전통적인 방법입니다. 맞춤형 회로 설계는 개별 dApp의 비용을 줄이는 데 도움이 됩니다. 그러나 이것은 회로가 "정적"이고 회로 설계 지식에 대한 의존도가 높아 개발자 경험이 좋지 않기 때문에 구성 가능성 문제도 제기합니다2.
두 번째 방법은 특별한 설계가 필요하지 않으며 개발자에게 강력한 전문 지식이 필요하지도 않습니다. 이러한 유형의 기계 기반 증명의 기본 개념은 모든 프로그램이 결국 CPU에서 실행된다는 것입니다. 따라서 저수준 CPU 작동을 검증하기 위해 범용 CPU 회로만 구축하면 됩니다. 그런 다음 이 CPU 회로를 사용하여 프로그램 실행을 확인할 수 있습니다. 이 기사의 애플리케이션 시나리오에 관한 한 프로그램은 스마트 계약을 참조하고 CPU는 EVM을 참조합니다. 그러나 이 방법은 막대한 비용 때문에 지난 몇 년 동안 널리 채택되지 않았습니다. 예를 들어 특정 작업에서 추가한 결과가 올바른지 증명하려는 경우에도 전체 EVM 회로 비용을 여전히 부담해야 합니다. 실행 추적에 수천 개의 작업이 있는 경우 증명자는 EVM 회로3 비용의 1000배를 지불합니다.
최근에는 (i) 새로운 ZKP 친화적인 기본 포세이돈 해싱(포세이돈 해싱은 SHA256보다 회로에서 100배 더 효율적임)을 제안하고, (ii) TinyRAM과 같은 검증 가능한 범용 가상 머신의 효율성, (iii) Plookup 및 더 빠르게 실행되는 암호화 라이브러리와 같은 점점 더 많은 범용 최적화 기술.
이전 기사에서 우리는 각 dApp에 대해 "ASIC" 회로를 설계하고 암호화 약정을 통해 통신하도록 제안했습니다. 그러나 커뮤니티 피드백을 기반으로 연구 초점을 변경했으며 범용 EVM 회로(소위 "zkEVM")를 구축하기 위한 두 번째 접근 방식을 사용하는 데 집중할 것입니다. zkEVM은 레이어 1과 정확히 동일한 개발 경험을 제공합니다. 설계 복잡성을 개발자에게 맡기는 대신 맞춤형 EVM 회로 설계로 교체하여 효율성 문제를 해결합니다.
zkEVM의 설계 과제
zkEVM은 구축하기 어렵습니다. 이 직관은 수년 동안 명확했지만 아무도 네이티브 EVM 회로를 구축하는 데 아직 성공하지 못했습니다. TinyRAM과 달리 zkEVM은 다음과 같은 이유로 설계 및 구현이 더 어렵습니다.
첫째, EVM은 타원 곡선에 대한 지원이 제한적입니다. 현재 EVM은 BN254 페어링만 지원합니다. EVM은 순환 타원 곡선을 직접 지원하지 않기 때문에 재귀적으로 증명하기 어렵습니다. 이 설정에서는 다른 독점 프로토콜을 사용하는 것도 어렵습니다. 확인 알고리즘은 EVM 친화적이어야 합니다.
둘째, EVM의 워드 크기는 256비트입니다. EVM은 256비트 정수에서 실행되며(가장 일반적인 가상 머신이 32-64비트 정수에서 실행되는 것처럼) 영지식 증명은 "자연스럽게" 프라임 필드에서 실행됩니다. 회로에서 "불일치 도메인 산술"을 수행하려면 범위 증명이 필요하며, 이는 차례로 각 EVM 작업에 약 100개의 제약 조건을 추가합니다. 이렇게 하면 EVM 회로 크기가 2배 증가합니다.
셋째, EVM에는 많은 특수 opcode가 있습니다. 기존 가상 머신과 달리 EVM에는 CALL과 같은 많은 특수 opcode와 실행 환경 및 가스와 관련된 오류 유형이 있습니다. 이것은 회로 설계에 새로운 도전을 가져올 것입니다.
넷째, EVM은 스택 기반 가상 머신입니다. SyncVM(zksync) 및 Cario(starkware) 아키텍처는 레지스터 기반 모델에서 자체 IR/AIR를 정의합니다. 그들은 스마트 계약 코드를 새로운 영지식 증명 친화적인 IR로 컴파일하기 위해 특수 컴파일러를 구축했습니다. 이 방법은 언어와 호환되며 기본 EVM과 호환되지 않습니다. 스택 기반 모델을 증명하거나 기본 도구 체인을 직접 지원하는 것이 더 어려워집니다.
다섯째, Ethereum의 스토리지 레이아웃은 높은 비용을 초래합니다. Ethereum 스토리지 레이아웃은 Keccak 및 거대한 MPT4에 크게 의존합니다. 어느 쪽도 영지식 증명에 우호적이지 않으며 높은 증명 비용이 발생합니다. 예를 들어 Keccak 해시는 Poseidon 해시의 회로 크기의 1000배입니다. 그러나 Keccak 해시를 다른 해시로 대체하면 기존 Ethereum 인프라와의 일부 호환성 문제가 발생합니다.
여섯째, 기계 기반 증명은 비용이 많이 듭니다. 위의 모든 것을 처리할 수 있더라도 완전한 EVM 회로를 얻기 위해 이들을 결합하는 효율적인 방법을 찾아야 합니다. 이전 섹션에서 언급했듯이 추가와 같이 단순한 opcode도 전체 EVM 회로 비용을 초래할 수 있습니다.
오늘날 zkEVM이 가능한 이유
연구원들의 상당한 발전 덕분에 지난 2년 동안 점점 더 많은 효율성 문제가 해결되었으며 zkEVM의 증명 비용은 마침내 더 이상 장애물이 아닙니다! 주요 기술 진보는 다음 측면에 반영됩니다.
다항식 약정 사용. 지난 몇 년 동안 대부분의 간결한 영지식 증명 프로토콜은 응용 프로그램별 신뢰할 수 있는 설정으로 인코딩된 PCP 쿼리와 함께 R1CS를 사용했습니다. 이는 회로의 크기를 증가시키는 경향이 있어 각 제약 조건이 2차여야 하기 때문에 많은 맞춤형 최적화를 불가능하게 만듭니다(쌍선형 페어링은 하나의 지수 곱셈 계산만 허용함). 다항식 약정 체계를 사용하면 범용 설정 또는 투명 설정을 통해 모든 주문에 대한 제약을 증가시켜 백엔드 선택의 유연성을 크게 높일 수 있습니다.
조회 테이블 매개변수 및 사용자 정의 위젯의 모양입니다. 또 다른 중요한 최적화는 조회 테이블을 사용하는 것입니다. 이 최적화는 Arya에서 처음 제안된 후 Plookup에서 구현되었습니다. 영지식 증명(즉, AND 및 XOR과 같은 비트 연산)에 적합하지 않은 프리미티브의 경우 조회 테이블이 많은 작업을 절약할 수 있습니다. 사용자 지정 위젯은 높은 수준의 제약 조건을 효율적으로 구현할 수 있습니다. TurboPlonk 및 UltraPlonk는 룩업 테이블 사용 및 사용자 지정 위젯 정의의 어려움을 완화하는 우아한 프로그램 구문을 정의합니다. 이는 EVM 회로의 비용을 줄이는 데 많은 도움이 됩니다.
재귀 증명의 가능성은 점점 더 높아지고 있습니다. 과거에는 재귀 증명이 페어링에 적합한 특수 원형 타원 곡선(즉, MNT 곡선 기반 구조)에 의존했기 때문에 비용이 많이 들었습니다. 이로 인해 높은 계산 비용이 발생합니다. 그러나 점점 더 많은 기술이 효율성을 희생하지 않고 재귀 증명을 가능하게 합니다. 예를 들어, Halo는 쌍 친화적인 곡선이 필요하지 않으며 재귀 비용을 상각하기 위해 특별한 내적 매개변수를 사용할 수도 있습니다. Aztec은 기존 프로토콜에서 직접 집계할 수 있는 증명을 증명합니다(조회 테이블은 비네이티브 도메인 작업 비용을 줄여 검증 회로의 크기를 줄일 수 있음). 이제 동일한 회로 크기로 더 많은 기능을 수행할 수 있습니다.
하드웨어 가속은 증명 효율성을 개선하고 있습니다. 우리가 아는 한 증명 프로그램을 위한 가장 빠른 GPU 및 ASIC/FPGA 가속기를 구축했습니다. ASIC 증명 절차에 관한 우리의 논문은 올해 최고의 컴퓨터 학술 대회인 ISCA에서 채택되었습니다. 우리의 GPU 증명기는 Filecoin의 구현보다 약 5~10배 빠르므로 증명자의 계산 효율성을 크게 향상시킬 수 있습니다.
zkEVM은 어떻게 작동하고 구축됩니까?
강력한 직관력과 기술적 개선 외에도 더 구체적인 아키텍처를 증명하고 구상하기 위해 필요한 것이 무엇인지 파악해야 합니다. 더 많은 기술적 세부 사항과 비교 분석은 향후 기사를 위해 예약됩니다. 이 문서에서는 전체 워크플로와 몇 가지 핵심 개념을 소개합니다.
개발자와 사용자를 위한 워크플로우
개발자는 EVM 호환 언어를 사용하여 스마트 계약을 구현하고 컴파일된 바이트코드를 Scroll에 배포할 수 있습니다. 그 후 사용자는 배포된 스마트 계약과 상호 작용하기 위해 트랜잭션을 보낼 수 있습니다. 사용자와 개발자는 레이어 1과 동일한 경험을 하게 됩니다. 그러나 가스 수수료는 상당히 낮을 것이며 거래는 Scroll에서 즉시 사전 확인됩니다(출금은 완료하는 데 몇 분 밖에 걸리지 않습니다).
zkEVM의 워크플로우
외부 워크플로는 동일하게 유지되지만 레이어 1과 레이어 2의 기본 처리는 완전히 다릅니다.
- 레이어 1은 스마트 계약 재실행에 의존합니다.
- 레이어 2는 zkEVM 회로의 유효성 증명에 의존합니다.
레이어 1과 레이어 2의 트랜잭션이 어떻게 다른지 자세히 설명하겠습니다.
레이어 1에서 배포된 스마트 계약의 바이트코드는 이더리움 스토리지(스토리지 항목)에 저장됩니다. 트랜잭션은 P2P 네트워크에서 전파됩니다. 각 트랜잭션에 대해 각 풀 노드는 해당 바이트코드를 로드하고 동일한 상태를 얻기 위해 EVM에서 실행해야 합니다(트랜잭션은 입력 데이터로 사용됨).
Layer 2에서는 저장 항목에도 바이트 코드가 저장되며 사용자는 동일한 방식으로 작동합니다. 트랜잭션은 오프체인 중앙 집중식 zkEVM 노드로 전송됩니다. 그런 다음 바이트코드를 실행하는 대신 zkEVM은 트랜잭션 후 상태가 올바르게 업데이트되었다는 간결한 증거를 생성합니다. 마지막으로 레이어 1 계약은 트랜잭션을 다시 실행하지 않고 증명을 확인하고 상태를 업데이트합니다.
실행에 대해 자세히 살펴보고 zkEVM이 궁극적으로 무엇을 증명해야 하는지 살펴보겠습니다. 기본 실행에서 EVM은 바이트코드를 로드하고 처음부터 바이트코드의 opcode를 하나씩 실행합니다. 각 opcode는 다음 세 단계를 수행하는 것으로 볼 수 있습니다: (i) 스택(스택), 메모리 또는 스토리지 항목에서 요소 읽기, (ii) 이러한 요소를 기반으로 계산 수행, (iii) 결과를 스택에 쓰기, 메모리 또는 저장 항목5. 예를 들어 추가 opcode는 스택에서 두 개의 요소를 읽고 추가한 다음 결과를 스택에 써야 합니다.
따라서 zkEVM의 증명에는 다음과 같은 측면(실행 흐름에 해당)이 포함되어야 합니다.
- 영구 저장소에서 바이트코드가 올바르게 로드됨(주소에서 로드된 올바른 opcode를 실행 중임)
- 바이트코드의 opcode는 항상 하나씩 실행됩니다(바이트코드는 순차적으로 실행되며 opcode가 누락되거나 건너뛰지 않음)
- 모든 opcode가 올바르게 실행됩니다(각 opcode의 3개 하위 작업이 올바르게 실행됨, R/W + 계산).
zkEVM 설계 하이라이트
zkEVM에 대한 아키텍처를 설계할 때 위의 세 가지 요구 사항을 각각 충족하기 위한 조치를 취해야 합니다.
1. 암호화 누산기를 위한 회로를 설계해야 합니다.
이것은 "검증 가능한 메모리" 역할을 하기 위해 읽기 과정이 정확하다는 것을 증명하는 일종의 기술이 필요합니다. 암호화 누산기는 이를 보다 효율적으로 수행할 수 있습니다6. 머클 트리를 예로 들어보겠습니다. 배포된 바이트코드는 Merkle 트리에 리프 노드로 저장됩니다. 그런 다음 검증자는 간결한 증명을 사용하여 이 바이트코드가 주소에서 올바르게 로드되었는지 확인할 수 있습니다(즉, 회로의 Merkle 경로 확인). Ethereum 스토리지의 경우 Merkle-Patricia 트리 및 Keccak 해시 함수와 호환되는 이 회로가 필요합니다.
2. 바이트코드를 실제 실행 추적과 연결하는 회로를 설계해야 합니다.
바이트 코드를 정적 회로로 이동하면 문제가 발생합니다. 점프와 같은 조건부 opcode(루프와 달리 스마트 계약의 if else 문)는 어디로든 이동할 수 있습니다. 점프 대상은 누군가 특정 입력으로 해당 바이트코드를 실행할 때까지 정의되지 않습니다. 그렇기 때문에 실제 실행 추적을 확인해야 합니다. 실행 추적은 실제로 실행된 순서대로 opcode를 포함하는 "언롤링되지 않은 바이트코드"로 생각할 수 있습니다(즉, 다른 위치로 점프하면 해당 대상 opcode 및 위치가 추적에 포함됨).
증명자는 회로의 증인 데이터로 실행 추적을 직접 제공합니다. 실행 추적이 특정 입력이 있는 특정 바이트코드에 의해 실제로 "언롤링"된다는 것을 증명해야 합니다. 아이디어는 프로그램 카운터의 값을 일관되게 강제하는 것입니다. 목적지가 불확실한 문제의 경우 해결책은 증명자에게 모든 데이터를 제공하도록 요청하는 것입니다. 그런 다음 조회 매개변수를 사용하여 일관성을 효율적으로 확인할 수 있습니다(즉, 정확한 전역 카운터가 있는 opcode가 "버스"에 포함되어 있음을 증명).
3. 각 opcode에 대한 회로를 설계해야 합니다(각 opcode의 읽기, 쓰기 및 계산이 정확함을 증명하기 위해).
이것은 실행 추적의 각 opcode가 정확하고 일관성이 있음을 증명하는 가장 중요한 부분입니다. 모든 것을 합치면 비용이 많이 듭니다. 여기서 중요한 최적화 아이디어는 다음과 같습니다.
R/W와 계산을 두 가지 증명으로 분리할 수 있습니다. 증명은 opcode가 사용하는 모든 요소를 "버스"에 넣습니다. 또 다른 증명은 "버스"의 요소에 대한 계산이 올바르게 수행되었음을 증명합니다. 이는 부품당 비용을 크게 줄입니다(즉, 계산 증명을 생성할 때 전체 EVM 스토리지를 고려할 필요가 없습니다). 보다 상세한 사양에서는 전자를 "상태 증명"이라고 하고 후자를 "EVM 증명"이라고 합니다. 또 다른 발견은 조회 문이 "버스 매핑"을 효율적으로 처리할 수 있다는 것입니다.
각 opcode에 대해 더 높은 수준의 사용자 지정 제약 조건을 설계할 수 있습니다(즉, 보다 효율적인 처리를 위해 EVM 워드를 여러 데이터 블록으로 나눌 수 있음). 선택기 다항식을 통해 수요에 대한 제약 조건을 "켜"할지 여부를 선택할 수 있습니다. 이렇게 하면 각 작업에 대해 전체 EVM 회로를 소비하는 비용을 피할 수 있습니다.
원래 Ethereum Foundation에서 제안한 이 아키텍처는 아직 초기 단계에 있으며 활발히 개발 중입니다. 우리는 이 EVM 회로를 구현하는 가장 좋은 방법을 찾기 위해 이더리움 재단과 긴밀히 협력하고 있습니다. 지금까지 우리는 EVM 회로의 가장 중요한 기능을 정의하고 구현했습니다(Halo2 라이브러리의 UltraPlonk 구문 사용) 일부 opcode(보려면 여기를 클릭). 자세한 내용은 다음 기사에서 소개합니다. 관심 있는 독자가 이 문서를 읽을 것을 권장합니다. 개발 과정은 투명할 것입니다. 이것은 전체 커뮤니티가 함께 모은 완전한 오픈 소스 디자인이 될 것입니다. 더 많은 사람들이 참여하고 기여하기를 바랍니다.
zkEVM이 우리에게 또 무엇을 가져다 줄 수 있습니까?
zkEVM은 Layer 2 스케일링 그 이상입니다. 레이어 1 유효성 증명을 통해 이더리움 레이어 1을 확장하는 간단한 방법으로 이해할 수 있습니다. 이는 특별한 Layer 2 없이도 기존 Layer 1을 확장할 수 있음을 의미합니다.
결론적으로
결론적으로
회사 소개
회사 소개
메모:
메모:
구성 가능성은 Starkware의 2021년 9월 1일 발표에서 달성되었습니다(발표를 보려면 여기를 클릭).
회로는 고정되어 있고 정적입니다. 예를 들어 프로그램을 회로로 구현할 때 가변 상한 루프를 사용할 수 없습니다. 상한값은 최대값으로 고정해야 합니다. 회로는 동적 논리를 처리할 수 없습니다.
독자의 편의를 위해 여기에서 EVM 회로의 비용을 자세히 설명합니다. 앞에서 언급했듯이 회로는 고정되어 있고 정적입니다. 따라서 EVM 회로는 가능한 모든 논리를 포함해야 합니다(이 볼륨은 추가만 포함하는 회로보다 10000배 더 큽니다). 즉, 추가만 증명하려는 경우에도 이 EVM 회로에 포함될 수 있는 모든 로직의 비용을 여전히 부담해야 합니다. 즉, 비용이 10,000배 증가합니다. 실행 추적에서는 일련의 opcode를 증명해야 하며 각 opcode에는 높은 비용이 따릅니다.
EVM 자체는 MPT(Merkle-Patricia Trees)에 밀접하게 연결되어 있지 않습니다. 현재 MPT는 Ethereum 상태를 저장하는 데만 사용됩니다. 쉽게 교체할 수 있습니다(어떤 사람들은 MPT를 교체하기 위해 Verkle 트리를 사용할 것을 제안합니다).
이것은 매우 단순화된 추상화입니다. 기술적으로 "EVM 상태" 목록은 프로그램 카운터, 가스 헤드룸, 호출 스택(스택의 각 호출에 대한 위의 모든 플러스 주소 및 통계), 로그 및 트랜잭션 범위 변수 세트(핫 스토리지 슬롯)를 포함하여 더 깁니다. , 환불, 자폭). 구성 가능성을 직접 지원하기 위해 다양한 호출 환경에 대한 식별자를 추가로 도입할 수 있습니다.
저장 공간이 크기 때문에 저장을 위해 어큐뮬레이터를 사용합니다. 메모리와 스택은 Plookup을 사용하여 편집할 수 있습니다(이 방법으로 "RAM"을 효과적으로 구현할 수 있음).
원본 링크:
원본 링크:
https://hackmd.io/@yezhang/S1_KMMbGt
IOS
Android