OP 스택 + 제로 지식 증명 = L2의 종말 게임?

撰文：Bill Qian、Yongxin Song、Bonan Yuan，Cypher Capital

Layer2의 종말 게임

현재 Layer2 경기는 매우 치열하게 진행되고 있으며, 앞에는 Arbitrum, Optimism, Base 등 optimistic 기반의 rollup이 있고, 뒤에는 Scroll, zkSync, Starkenet, Scroll, Polygon zkEVM, Taiko, Linea 등 Zero Knowledge Proof 기반의 ZKP rollup이 있습니다. 겉으로 보기에는 Layer2의 경쟁이 다양하게 펼쳐지고 있지만, 실제로는 모두 공학 원리에서 체인 외 계산과 체인 내 증명의 사고 방식을 사용하고 있습니다. optimistic의 fraud Proof든 ZKP의 회로 증명이든, 공학 실천에서의 핵심 차이는 체인 내 증명 방식의 차이에 있으며, 다른 원리는 사실상 유사합니다. 따라서 Optimism은 특별한 경로를 선택했습니다. 즉, 모듈화된 Layer2로, 논리적으로 Layer2의 여러 구성 요소를 분리합니다. OPstack이 Layer2의 각 모듈을 결합한 후, 매우 창의적으로 보이는 사고 방식이 열렸습니다. 즉, ZKP on OP Stack으로, OP Stack의 challenger를 Optimistic Proof에서 Zero Knowledge Proof로 변경하여 OpStack이 다양한 증명을 지원하는 범용 Layer2 아키텍처가 될 것입니다!

ZKP on OP Stack

모든 논의의 시작은 Optimism의 RFP에서 비롯되었습니다, https://github.com/ethereum-optimism/ecosystem-contributions/issues/61.

이제 이 RFP가 제기한 문제와 발전 방향에 대해 소개하겠습니다.

의도: Optimism의 오류 증명 프로그램(Golang 컴파일러가 지원하는 명령어 집합을 통해)을 증명하기 위해 제로 지식 증명을 구현합니다.

어떻게 구현할 것인가: OP 체인에 제로 지식 증명(ZKP)을 구현하는 것은 L2와 L1 간의 안전하고 저지연 통신을 실현하는 전제 조건입니다. 명령어 집합을 지원하는 제로 지식 증명은 Optimism의 오류 증명 프로그램을 증명할 수 있으며, 임의의 OP Stack 블록체인을 포함합니다. ISA의 표준 실행 추적을 기반으로, 오류 증명 프로그램은 추가 요구 사항을 도입합니다.

구체적으로, 오류 증명 프로그램은 "프리 이미지 오라클"의 개념을 도입하여, 특별한 시스템 호출을 사용하여 외부 데이터를 프로그램에 로드합니다. 각 오류 증명 가상 머신은 특정 메커니즘을 구현하여, 특정 위치에 데이터의 해시를 메모리에 배치하고, 시스템 호출을 실행한 후 해당 해시의 원형을 메모리에 로드하여 프로그램에서 사용할 수 있도록 합니다. 프리 이미지 오라클은 초기 입력으로 프로그램을 부팅하는 데에도 사용됩니다. 자세한 내용은 오류 증명 프로그램 문서의 "프리 이미지 오라클" 섹션을 참조하십시오.

간단히 말해, 이 제안은 OP Stack의 높은 모듈화 특성을 활용하여 원래의 낙관적 증명(Opstimisic Proof) 기반의 오류 증명 방식을 제로 지식 증명을 활용하여 전환하려는 것입니다. 더 나아가, 현재 OP는 GETH를 MIPS로 컴파일하여 Mini Geth로 만들고 있으므로, OP Stack의 제로 지식 증명은 Mips 가상 머신 기반의 제로 지식 증명으로 이해할 수 있습니다.

왜 ZKP인가?

현재 OP Stack은 잘 작동하고 있지 않나요? 낙관적 증명 기반의 Optimism과 Arbitrum은 매우 좋은 커뮤니티 지원과 개발자 지원을 받고 있습니다. OP Stack은 왜 제로 지식 증명을 탐색해야 할까요? 필자는 여기 몇 가지 이유가 있다고 생각합니다.

• OP Stack은 Layer2의 모듈을 높은 수준으로 추상화하여 ZKP를 도입하는 것은 단지 다른 오류 증명 방식을 도입하는 것일 뿐, OP가 낙관적 증명을 포기한다는 것을 의미하지 않습니다. OP Stack을 사용하는 개발자는 다양한 증명 방식을 자유롭게 선택할 수 있습니다.

• 낙관적 증명(Optimistic Proof) 기반의 Optimism과 Arbitrum은 여전히 오류 증명을 지원하지 않으며, 본질적으로 OP와 ARB는 증명할 수 없는 단일 체인입니다.

• 낙관적 증명의 7일 최종 확인 속도는 너무 느립니다. ZKP Layer2가 시장을 차지하게 되면, ZKP의 30분 내 증명 속도가 상당한 이점을 형성할 것이며, 최종 사용자는 더 높은 안전성을 가진 ZKP Layer2를 선택할 것입니다.

따라서 Optimism이 ZKP를 지원하는 것은 시간 문제입니다. 대담한 추측으로, 미래의 OP Stack은 낙관적 증명과 제로 지식 증명 두 가지 오류 증명 시스템을 지원할 것입니다. OP Stack은 범용 Layer2 아키텍처이며 지속적으로 발전하고 있습니다. OP Stack이 다양한 증명 시스템의 전환을 어떻게 실현할 수 있는지 이해하는 데 도움이 되도록, 아래에서 OP Stack을 자세히 분석하겠습니다.

OP Stack의 핵심 모듈

(해당 이미지는 Optimism의 GitHub에서 캡처한 것입니다)

OP Stack에 중요한 몇 가지 모듈은 다음과 같습니다:

• op-node

• op-geth

• op-batcher

• op-proposer

• op-program

• Cannon

• op-challenger

이러한 모듈은 모두 독립적인 프로그램이며, HTTP의 표준 인터페이스를 통해 통신합니다. 이는 개발자가 OP Stack의 일부 특성을 수정하려면 특정 모듈만 수정하면 자신의 Layer2를 맞춤화할 수 있음을 의미합니다. 다음 장에서는 각 OP Stack 모듈과 OP Stack의 전체 아키텍처를 구체적으로 소개합니다.

op-node

op-node는 OP Stack에서 가장 중요한 모듈입니다. 한편으로는 Sequencer로서, op-node는 블록체인의 합의 클라이언트 구현을 포함하며, 이더리움의 Lighthouse, Prysm과 유사하게 사용자가 제출한 거래를 정렬합니다. 다른 한편으로는 rollup 드라이버로서, op-node는 L1 블록의 데이터에서 Layer2 체인을 파생하는 역할을 합니다.

Sequencer는 사용자 거래를 수집하고 정렬한 후, op-batcher가 배치를 생성합니다. 배치가 L1에 제출되기 전에 Rollup 네트워크의 지연을 줄이기 위해, Sequencer는 Layer2 블록을 미리 생성하여 P2P를 통해 Rollup 네트워크에서 전파할 수 있습니다. L2에서 직접 생성된 블록은 안전하지 않은 것으로 간주되며, 배치가 L1에 제출된 후 유도되어야 안전한 것으로 간주됩니다. 그러나 정상적인 경우(블록 재구성, 사기 등 없음) L2에서 직접 생성된 블록과 L1에서 유도된 블록은 동일합니다. Binance와 같은 거래소는 일정 수의 Layer2 블록이 생성된 후 거래가 확정된 것으로 간주하며, 배치가 L1에 제출되기를 기다릴 필요가 없으며, 이는 오류 발생 확률이 극히 낮다는 것을 어느 정도 설명합니다.

L2 블록을 유도하는 과정은 드라이버가 담당하며, 드라이버는 L1 헤드 블록과 L2 체인의 동기화 과정을 지속적으로 추적하여 L1에서 입금 거래, L2 거래 데이터 및 해당 영수증을 가져와 페이로드 속성을 생성하고, 페이로드 속성을 실행 엔진에 전달하여 L2 블록을 계산합니다. L2 블록은 완전히 L1 체인의 블록에 의존하며, L2 배치가 포함된 L1 블록이 생성될 때마다 L2 체인이 연장됩니다. 또한 L1 블록이 재구성될 때 L2 블록도 재구성됩니다.

op-geth

op-geth는 OP Stack의 실행 클라이언트 구현으로, go-ethereum에 약간의 수정을 가하여 OP Stack의 요구에 맞게 조정되었습니다. 합의 클라이언트인 op-node는 Engine API를 통해 실행 클라이언트인 op-geth를 구동하며, 페이로드 속성을 활용하여 op-geth는 출력 정보를 계산하고 L2 블록을 생성합니다.

op-batcher

배치 제출자 역할을 하는 batcher는 두 가지 주요 작업을 포함합니다. 하나는 L2 시퀀서 데이터를 배치로 압축하는 것이고, 다른 하나는 배치를 L1에 제출하여 검증자가 데이터를 사용하여 검증할 수 있도록 하는 것입니다.

배치는 DA 레이어에 배치 거래를 제출하며, 거래는 하나 이상의 채널 프레임을 포함합니다. 채널은 더 높은 압축률을 얻기 위해 일련의 시퀀서 배치로 구성됩니다. 구체적으로, 배치는 현재 zlib를 사용하여 데이터 압축을 수행합니다. 채널의 크기가 배치 거래가 수용할 수 있는 한계를 초과할 수 있으므로, 채널은 하나 이상의 채널 프레임으로 나뉘며, 하나의 배치 거래는 하나 이상의 채널 프레임(다른 채널에서 올 수 있음)을 포함할 수 있습니다.

source: Optimism

이 설계는 배치 제출자에게 매우 높은 유연성을 제공하며, 미래의 OP Stack은 배치 제출자가 여러 서명자를 사용하여 여러 채널을 병렬로 제출할 수 있도록 지원할 것입니다.

op-proposer

op-proposer는 op-geth가 실행한 L2 블록 후 생성된 새로운 상태 약속(현재 Output Merkle Root 형태)을 L1에 제출하는 역할을 합니다. Output Root는 즉시 유효하지 않으며, 논쟁 기간이 끝난 후에야 최종화된 것으로 간주됩니다.

위의 내용은 OP Stack이 이미 구현한 일부이며, 아래의 Fault Proof 관련 모듈 내용은 아직 완료되지 않았으며, 문서 규격에 따라 논의됩니다.

OP Fraud Proof는 세 가지 구성 요소로 구성됩니다:

• 프로그램: 주어진 Rollup Inputs(L1 배치 tx 데이터)의 약속과 논쟁을 무상태로 검증합니다(PreImageOracle이 제공하는 Inputs를 통해 동일한 계산 과정을 재현).

• VM: 주어진 무상태 프로그램과 Inputs를 기반으로, 모든 명령어를 추적합니다(따라서 상태를 유지합니다), L1에서 증명합니다.

• 인터랙티브 논쟁 게임: 논쟁을 단일 명령어로 이분화하여, VM이 이 기본 사례를 해결합니다.

op-program

op-program은 Program의 참조 구현으로, op-node와 op-geth를 기반으로 개발되었으며, L2 상태 전이에 대한 Claim을 검증하는 무상태 중간 미들웨어 역할을 합니다.

L2 상태의 주장을 검증하기 위해, 프로그램은 먼저 L1 데이터를 최종화된 L2 상태에 적용하여 최신 L2 상태를 재구성합니다. 이 과정은 op-node의 작업과 유사합니다. 차이점은 op-node가 RPC에서 데이터를 가져와 상태 변화를 디스크에 적용하는 반면, Program은 Pre Image Oracle에서 데이터를 가져와 상태 변화를 메모리에 적용한다는 것입니다. Program은 오라클에서 데이터를 스트리밍으로 읽고 상태 변화를 스트리밍으로 수행하며, EOF 또는 조기 종료 조건에 도달할 때까지 진행합니다. L2 상태를 재구성한 후, 상태와 주장 여부에 따라 검증 결과를 반환합니다.

Cannon

Cannon은 VM의 구현으로, 두 가지 주요 구성 요소를 포함합니다:

• 온체인 MIPS.sol: 단일 MIPS 명령어의 실행을 검증하기 위한 EVM 구현입니다.

• 오프체인 mipsevm: 온체인에서 검증하기 위해 모든 MIPS 명령어에 대한 증명을 생성하는 Go 구현입니다.

온체인 부분인 MIPS.sol은 big-endian 32-bit MIPS 명령어 집합을 구현하여, Linux 커널의 최소 하위 집합을 시뮬레이션하며, Go 프로그램을 지원하지만, 동시성 관련 시스템 호출은 포함하지 않습니다.

오프체인 부분인 mipsevm은 Go 언어로 MIPS.sol의 실행 과정을 시뮬레이션합니다.

• It's Go code

• …that runs an EVM

• …emulating a MIPS machine

• …running compiled Go code

• …that runs an EVM

간단히 말해, Cannon은 온체인에서 EVM을 사용하여 MIPS로 MINI Geth(GETH의 MIPS 컴파일)를 실행하는 것입니다. 즉 ETH의 Golang 버전입니다.

op-challenger

op-challenger는 논쟁 게임과 관련된 프로세스를 처리합니다.

도전은 먼저 tx 실행 후의 상태 루트를 선택하여 의문을 제기하고, 이후 tx는 여러 명령어로 분해되며, 각 명령어 실행 후 새로운 상태를 생성하여 S1, S2, … Sn의 상태 시퀀스를 형성합니다.

효율성을 높이기 위해, 도전 양측은 단계별로 번갈아 실행해야 하며, 공격과 방어 두 가지로 나뉩니다.

• 공격: 논쟁의 이전 상태를 입력으로 사용하고, 기대하는 논쟁 상태를 출력으로 사용합니다. DAG에는 이전 상태에 대한 약속이 필요합니다.

• 방어: 논쟁 상태를 입력으로 사용하고, 논쟁 후의 상태를 출력으로 사용합니다. DAG에는 이후 상태에 대한 약속이 필요합니다.

예를 들어, 1-9999개의 명령어가 있어 S1-S10000 상태 시퀀스를 생성한다고 가정하면, 먼저 5000번째 상태를 검증하고, 동일하면 공격 단계로 왼쪽으로 이분화합니다. 다르면 방어 단계로 오른쪽으로 이분화합니다.

결국 이분법을 통해 논쟁을 단일 명령어의 전후 상태로 고정한 후, VM에 의해 단일 명령어의 상태 검증이 처리됩니다.

모듈의 작업 흐름

정상 흐름(도전 포함하지 않음)

source: Cypher Capital

1. 사용자가 거래를 제출하며, L2 RPC를 통해 L2에 제출하거나 L1에서 직접 제출할 수 있습니다(이는 op-batcher를 우회할 수 있으며, 더 강한 검열 저항력을 가지며, 긴급 탈출 장치로도 사용될 수 있습니다).

2. op-node가 시작한 RPC 서버는 거래를 수신한 후, 정렬하여 op-batcher와 op-geth에 전송합니다.

3. op-batcher는 시퀀스된 tx를 압축하여 배치를 생성하고, DA 레이어(L1)에 제출합니다.

4. op-geth는 시퀀스된 tx를 실행하고, 실행 후의 새로운 상태를 op-proposer에 전달합니다.

5. op-proposer는 L2의 출력 루트를 L2 상태에 대한 약속으로 L1에 전송하여 저장하며, 논쟁 기간이 끝나면 상태가 최종화된 것으로 간주됩니다.

6. op-node의 드라이버는 L1에서 거래 데이터 및 기타 정보를 가져와 정식 L2 블록을 유도합니다. L1에서 최종화된 블록에서 배치 tx로 유도된 L2 블록은 최종화된 것으로 간주되며, L1에서 확인되었지만 최종화되지 않은 배치 tx로 유도된 L2 블록은 안전한 것으로 간주됩니다. 지연을 줄이기 위해 L2에서 직접 생성된 L2 블록은 P2P를 통해 미리 전파될 수 있으며, 안전하지 않은 것으로 간주됩니다.

Challenge 흐름

source: optimism

1. 사용자가 인터랙티브 논쟁 게임을 시작합니다.

2. Cannon (VM)은 MIPS 가상 머신에서 op-program(Go로 작성됨)을 실행하여 각 단계의 실행 상태 변화를 추적합니다.

3. op-program은 PreImageOracle이 제공하는 Rollup Inputs의 약속을 통해 L2 상태의 계산 과정을 재현하고, 실행 추적을 기록하며, 무상태로 논쟁을 검증합니다.

4. op-challenger는 이분법을 사용하여 논쟁을 단일 명령어로 위치시킵니다.

5. Cannon은 해당 명령어 전후의 상태 변화를 증명하기 위해 증명을 생성하고, L1의 스마트 계약 MIPS.sol에서 검증합니다.

OP Stack+ZKP

위의 흐름 소개에 따르면, Challenge 모듈은 다른 모듈과의 결합도가 매우 낮고, 기본 거래 흐름에 미치는 영향이 적으며, 사기 행위가 발생하는 경우에만(2021년 12월 OP 메인넷 출시 이후 현재까지 발생하지 않았습니다) Challenge 모듈의 개입이 필요합니다.

현재 Optimism의 7일 퇴출 확인 시간을 단축하고 OP Stack에 더 많은 모듈화 선택을 제공하기 위해, Optimism은 ZKP 기술을 적극적으로 수용하고 있으며, OP Stack에 Optimism의 오류 증명 프로그램을 증명하고 유명한 ISA를 지원하는 ZKP를 가져오기를 희망하고 있습니다. O(1) Labs와 Risc-0 팀의 제안이 Foundation Mission (RFP) 신청을 통과했습니다.

O(1) Labs 제안

source: O(1) Labs

O(1) Labs는 Mina Protocol의 개발 팀으로, MIPS VM의 증명 시스템으로 Kimchi를 채택할 계획이며, 일부 소규모 변경만 수행할 것입니다.

Kimchi는 현재 내부 곱셈 인수 스타일 다항식 약속 체계를 구성하는 Halo2 유사 PLONKish 시스템입니다. 이는 전통적인 튜링 머신 기반 명령어 집합을 사용하여 검증 가능한 계산을 지원합니다.

Kimchi의 백엔드는 교환 가능하며, 현재 구현은 Pasta 곡선을 사용하여 내부 곱셈 인수 기반 다항식 약속 체계(Pasta-IPA)에서 정의되어 있으며, EVM에서 사용하는 암호학적 시스템과 호환되지 않아 EVM에서 검증 비용이 높습니다. 따라서 O(1) Labs는 Pasta-IPA를 bn128 곡선을 사용하는 KZG 약속 체계(bn128-KZG)로 변경할 계획이며, EVM의 기존 프리컴파일을 사용할 수 있어 효율성이 더 높습니다.

원래 입력 오류 증명 MIPS 시스템의 입력이 이제 bn128-kzg Kimchi 시스템으로 입력되며, ZK-Prove 실행 경로가 됩니다. 프리 이미지 시스템 호출은 OP Stack의 Cannon을 따르며, 최종 증명은 L1의 스마트 계약으로 전송되어 검증이 통과하면 L1 상태가 업데이트됩니다.

RISC Zero 제안

RISC Zero 팀은 현재 구현된 Groth16 백엔드를 기반으로 RISC-V ISA의 zkVM(일반적인 암호 작업을 위한 가속화된 공동 프로세서가 포함됨)을 채택할 계획이며, Optimism에 더 잘 적응하기 위해 Reth 기반의 Ethereum ZK 클라이언트를 수정하여 L1-L2 유도 논리를 구현하여 거래 시퀀스가 Optimism 시퀀서에 의해 생성되었음을 증명합니다.

ZK 클라이언트는 zkVM 게스트 프로그램과 호스트 라이브러리 두 부분으로 구성되며, OP Labs 제안의 op-program과 Cannon에 비유할 수 있습니다. zkVM 게스트 프로그램은 상태 전이를 계산하고, 호스트 라이브러리는 계산 데이터 전이에 필요한 데이터를 가져오고, zkVM 게스트 프로그램의 실행을 조정하며, 거래 실행 상태 전이의 zkp를 생성합니다.

|------------------------|------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------| | | O(1) Labs | RISC Zero | | 성능 | Optimism 블록에 대해 44B MIPS 명령어 단계 | Optimism 블록에 대해 \<2B zkVM 사이클 | | 지연 | 병렬화 없이 Optimism 블록에 대해 2일 | 병렬화로 Optimism 블록에 대해 10-20분 | | 복잡성 | Kimchi: 35kloc 변경 5-10kloc | ZKP 프레임워크: 10kloc의 Rust zkVM: 54kloc의 Rust | | 견고성 | Mina는 Kimchi로 2년 동안 보안되었습니다. | 광범위한 자동화 테스트 | | 보안 | kzg-bn128 기반 EVM 친화적인 snark 시스템은 신뢰할 수 있는 설정이 필요합니다. | zkVM은 신뢰할 수 있는 설정이 필요 없는 STARK 기반 증명을 생성합니다. 온체인 검증은 STARK->SNARK 변환을 기반으로 합니다. | | OP Stack 호환성 | 근본적인 변화 없음 | 변화 없음 |

OP Stack의 ZKP 가능성 탐구

현재 ZKM이라는 팀이 ZKMIPs의 EVM을 구현하여 EVM을 MIPs 명령어 집합으로 변환하고 제로 지식 증명을 수행하고 있습니다. 현재 피드백은 매우 느리지만 사용할 수 있습니다. https://ethresear.ch/t/zkmips-a-zero-knowledge-zk-vm-based-on-mips-architecture/16156

Mina와 Risc0가 상대적으로 성숙한 개발 경험을 가지고 있다는 점을 고려할 때, OP Stack이 ZKP를 지원하는 것은 시간 문제일 뿐입니다. 그러나 동시에 OP Stack의 ZKP 개발이 늦게 시작되었고 원래 지원되지 않기 때문에, 미래의 성능은 여전히 예측할 수 없습니다.

OP Stack, Layer2의 범용 아키텍처

OP Stack은 뛰어난 코드 구현, 관대한 오픈 소스 프로토콜 및 모듈화된 아키텍처 설계로 많은 유명 팀의 채택을 받았으며, 유일하게 비판받는 점은 채택된 낙관적 롤업 기술의 결정 시간이 너무 길어 ZK 롤업보다 기술적 진보성이 떨어진다는 것입니다. 현재, 제3자 전문 팀의 힘을 빌려 OP Stack은 ZKP 미래로 나아가는 시도를 시작했습니다. 현재 OP Stack이 아직 Fault Proof를 지원하지 않기 때문에, OP Stack은 Fault Proof 단계를 건너뛰고 직접 ZK Proof를 사용하여 더 빠른 결정성과 더 높은 보안을 얻을 수 있습니다.

미래의 Layer2 개발자에게 OP Stack은 범용 Layer2 아키텍처가 될 것이며, 개발자는 자신의 Layer2를 시작할 때 응용 프로그램이 요구하는 안전성과 실효성에 따라 낙관적 증명 또는 제로 지식 증명을 유연하게 선택할 수 있습니다. 낙관적 증명의 Layer2는 더 저렴할 것이고, 제로 지식 증명의 Layer2는 더 안전할 것이라는 점은 예견할 수 있습니다.

reference: https://blog.oplabs.co/building-a-fault-proof-system/