이더리움 L1 궁극의 미래를 향해, Taiko의 다중 증명 로드맵

2024.01.23

이더리움 L1 궁극의 미래를 향해, Taiko의 다중 증명 로드맵

타이코(Taiko)는 ZK 내 다중 증명(multiple proofs)이 향후 이더리움 L1에서 SNARK 기반 노드의 다양성을 위한 기반을 마련할 수 있다고 생각한다.

2024.01.23 - 12:23:16

Web3 심층 보도에 집중하고 흐름을 통찰

타이코(Taiko)는 ZK 내 다중 증명(multiple proofs)이 향후 이더리움 L1에서 SNARK 기반 노드의 다양성을 위한 기반을 마련할 수 있다고 생각한다.

글: Taiko

번역: Frank, Foresight News

얼마 전 우리는 「왜 multi-prover가 중요한가」라는 제목의 상세한 글을 통해 다중 증명(multi-proof)의 중요성을 설명하였으며, 그 중 하나로 SGX를 소개했습니다.

이 글은 우리가 Vitalik과 진행한 X Space와 그가 이후 발표한블로그 포스트에서 영감을 받았습니다. 이 글에서는 Taiko의 다중 증명에 대한 전체 로드맵을 소개합니다. 즉, 그것이 이더리움 궁극적 상태(The Endgame)와 어떤 관계가 있는지, 우리의 비전은 무엇이며, 어떻게 이를 실현할 것인지 설명합니다.

우리는 ZK 환경에서의 다중 증명(multi-proof)을 multi-SNARKs + multi-client 형태로 이해할 수 있다고 봅니다. 즉 다양한 ZK-SNARK을 사용해 여러 종류의 이더리움 노드를 증명하는 방식입니다. 이는 향후 이더리움 L1 내 SNARK화된 노드의 다양성을 위한 기반을 마련합니다.

다중 증명의 필요성을 간단히 설명하기 위해 다음 두 가지를 언급해야 합니다:

다중 증명은 노드 구현 및 증명 시스템의 취약점과 리스크를 헤지할 수 있습니다. 따라서 어떤 결함이 발생하더라도 한 증명이 무너지더라도 다른 증명들이 동일한 취약점을 악용하는 것을 허용하지 않을 가능성이 높습니다;
이더리움 궁극적 상태란, L1 검증에 제로 낼 지식 증명(ZK)을 사용하는 것으로 가정합니다;

이더리움의 다중 노드 구현처럼, 이러한 접근법은 이미 여러 차례 네트워크 붕괴를 막아왔으며, L1 블록에는 다중 검증 방법이 필요하다는 점을 입증했습니다. ZK와 비-ZK 시나리오 모두에서, 여러 노드와 서로 다른 증명 시스템을 사용해야 한다는 의미입니다.

Multi-Client 시스템과 L1 궁극적 상태

Vitalik이 「What might an "enshrined ZK-EVM" look like?」이라는 글에서 설명했듯이, Multi-Client 시스템에는 두 가지 방식이 있습니다. 즉 「개방형(open)」과 「폐쇄형(closed)」입니다.

폐쇄형 Multi-Client 시스템에서는 프로토콜 내에서 고정된 증명 집합을 알고 있으며, 이를 「화이트리스트」에 등재하여 증명 생성을 허용합니다. Vitalik의 분류에 따르면 모든 ZK L2는 폐쇄형인데, 왜냐하면 자신들의 구현만 허용하기 때문입니다;
개방형 Multi-Client 시스템에서는 증명이 「블록 외부」에 위치하며, 각 노드가 개별적으로 이를 검증하고, 모든 사용자가 원하는 어떤 노드라도 사용해 블록을 검증할 수 있습니다;

사용자가 특정 블록을 검증해야 하는 경우, 가장 간단한 방법은 해당 블록을 다시 실행하기 위해 적절한 노드를 직접 실행하거나, 알려진 Prover에게 유효성 증명을 요청하는 것입니다. 일정 수 이상의 「화이트리스트」 기준에 부합하는 증명을 받으면 해당 블록을 합법적인 것으로 간주합니다. 그러나 만약 「화이트리스트」 기준에 맞는 제로 낼 지식 증명(ZKP)이 없고, 재실행을 피하고 싶다면 어떤 ZKP를 사용해야 할까요?

Vitalik의 비전에 따르면, 이 문제는 프로토콜 외부에서 사회적(또는 암호경제적) 합의를 통해 해결됩니다:

컨센서스 계층에서 다음과 같은 검증 규칙을 추가합니다. 노드가 블록 내 모든 상태 변화에 대해 유효한 증명을 확인했을 때만 해당 블록을 수락합니다. 이 증명은 transaction_and_witness_blobs의 연결이 (Block, Witness) 쌍의 직렬화임을 보여주는 ZK-SNARK 증명이어야 하며, pre_state_root와 Witness를 기반으로 (i) 블록 실행이 유효하고 (ii) 올바른 post_state_root를 출력함을 증명해야 합니다. 잠재적으로 노드는 M-of-N 형식의 여러 유형의 증명을 기다릴 수도 있습니다.

정직한 Builder가 type-1 블록을 가지고 있고, 이를 유효하게 만들고자 한다고 가정해 봅시다. L2 계층에서는 이미 Polygon, ZkSync, Scroll 등 몇 가지 선택지가 제공되고 있습니다.

그들의 ZK-EVM이 이미 type-1 수준에 도달했고, 신뢰할 수 있으며 실전 검증을 거쳤다고 가정하면, Builder는 이용 가능한 증명 시스템들 중 하나를 선택할 것이며, 블록을 검증하는 사람은 그에 대응하는 검증 소프트웨어를 실행할 것입니다. 가능하면 여러 유형의 증명을 생성하고, 다중 검증을 수행하는 것이 좋습니다. 동일한 L1 체인 사양 하에서, 검증자 중 하나라도 동의하지 않으면 블록 검증은 합의 문제로 바뀌며, 개방형 시스템은 합의를 통해 검증 결과의 일관성을 달성합니다.

증명 시스템은 프로토콜 거버넌스 과정을 설득하는 것이 아니라, 사용자를 설득해 신뢰를 얻음으로써 영향력을 갖게 됩니다.

Vitalik에 따르면, 이는 ZKP 생태계가 직접적인 시장화를 위해 열리고 있음을 의미합니다. 인센티브가 있다면 기존의 L2 구현들도 L1 증명 시장에 참여해 경쟁할 수 있습니다.

Taiko의 다중 증명 가능성

Taiko 프로토콜에서 Proposer는 블록을 제안하기 위해 Prover를 찾아야 하며, 지정된 Prover는 자신의 증명이 문제가 없도록 TKO를 담보금으로 예치해야 합니다. Taiko 프로토콜은 Proposer가 어떻게 Prover를 찾고 보상할지를 규정하지 않기 때문에, 직접 만나 현금으로 거래하는 것도 가능합니다.

따라서 우리의 공급망은 자유 시장처럼 작동하며, Proposer는 원하는 어떤 Prover라도 선택할 수 있습니다.

경제적 이점 외에도, Taiko는 Multi-Client 시스템에 이상적인 기술적 특징들을 갖고 있습니다:

Taiko는 type-1 ZK-EVM로서 두 가지 장점이 있습니다. 첫째, 실행 다양성 측면에서 기존 EVM 구현(Geth, Besu, Reth 등)을 L2에 직접 적용할 수 있습니다. 둘째, L1 설계의 실현 가능성을 테스트하기 위해서는, 검증자들이 동일한 변환을 기반으로 합의하고 결과를 검증할 수 있도록 표준화된 ZK-EVM이 필요한데, 개방형 Multi-Client 검증에 이상적인 선택이 됩니다. 이 경우 type-1 ZK-EVM이 가장 적합한 선택인데, 왜냐하면 이더리움 명세를 명확히 따르기 때문입니다. 롤업 특화 로직 측면에서도 Vitalik은 ZK-EVM을 수정하기 위한 프리컴파일을 통한 지원 방법을 언급했으며, 이러한 프리컴파일을 활용하면 Taiko의 BBR(Based Booster Rollup) 설계를 충분히 지원할 수 있습니다;
Taiko는 일부 L2들이 대체 데이터 가용성(DA) 옵션을 탐색하는 것과 달리, 데이터 가용성을 이더리움 위에 게시합니다. 데이터가 L1에 게시되는 한, Taiko는 ZKEVMClaimTransaction을 통해 상태 전이, 증명, 데이터 가용성을 포함하는 Vitalik의 구현 제안에 쉽게 적응할 수 있습니다;

Taiko는 여러 증명 시스템에서 작동하며, 기존 테스트넷은 PSE의 ZK-EVM, SGX, Reth를 이미 지원하고 있습니다. 인프라는 다수의 실행 노드와 증명 시스템에 적응하도록 구성되어 있으며, 이는 마지막 섹션에서 논의될 것입니다. 이러한 인프라 위에서 Taiko는 제로 낼 지식 증명 측면에서 모듈화된 컴파일을 중심으로 발전할 것입니다.

모듈화 및 개방성 로드맵

모듈화

제로 낼 지식 증명(ZKP) 맥락에서, Multi-Client를 고려할 때 Taiko는 Risc-V 또는 WASM과 같은 현대 컴파일러로부터 범용 컴포넌트를 활용합니다. 그런 다음 이러한 명령어를 다양한 증명 시스템(AIR 또는 PIL)의 산술 표현으로 변환하고, 최종적으로 서로 다른 SNARK를 사용해 산술화된 실행 트레이스를 인코딩합니다.

간단히 말해, 이 프로세스는 양측의 이점을 극대화하는 multi-proof 시스템에서 가장 실현 가능한 방법입니다. 노드 컴파일 과정에서 현대 컴파일러는 다음과 같은 이점을 제공합니다:

노드 업그레이는 증명과 무관합니다. 최신 EIP나 하드포크를 위해 회로를 구현할 필요 없이 소스 코드만 업데이트하면 됩니다;
LLVM과 같은 도구 체인에서 무료로 코드 최적화를 얻을 수 있습니다;
교차 컴파일을 통해 더 많은 다양성을 창출합니다. 위 예시처럼 Taiko는 Geth 또는 Reth를 RISC-V 또는 WASM 명령어 세트로 컴파일해 이미 네 가지 증명 시스템을 갖추고 있습니다;

SNARK 컴파일은 Taiko의 미래 발전 핵심입니다. PLONK, R1CS 등의 산술화 방법과 Halo2, eSTARK, Supernova 등의 백엔드 간 인코딩은 단일 ZK 프로토콜에 국한되지 않습니다. 반면 일체형 ZK-VM/EVM은 특정 ZKP에 맞춰 백엔드를 구현합니다. 점점 더 많은 프로젝트들이 성능 향상을 위해 서로의 컴포넌트를 채택하면서, 전체 기술 스택은 모듈화될 가능성이 있습니다.

ZKP 연구 분야는 급속도로 발전하고 있으므로, 유연성을 유지하는 것이 최신 결과를 직접 구현하는 것보다 중요합니다. 유연성을 확보하기 위해 Powdr Labs, Risc Zero 등의 프로젝트와 협력해 교차 컴파일 파이프라인을 개발하고, 가능한 한 모듈화를 추진합니다.

기술 전문 독자들을 위해 다음과 같은 구체적 이점들을 참고하시기 바랍니다:

다양한 백엔드 목표에 따라 최적화된 컴파일러를 개발할 수 있습니다. 예를 들어 「고차 게이트(high-degree gates)」를 선호하거나 더 많은 조회 매개변수를 사용하는 경우;
Keccak 및 Poseidon 해시 함수와 같은 가속 회로를 라이브러리 형태로 구현할 수 있습니다;
LogUp과 같은 ZK 기능을 언어에 점진적으로 추가하고, 해당 백엔드 지원을 활성화할 수 있습니다;
새로운 ZK 백엔드 프레임워크를 통합해 더욱 빠르게 진화할 수 있습니다. 일부 연구 중심 ZK 프로젝트들은 개념 검증(PoC)만 코드 형태로 개발되어 있어 실제 운영 환경에서 사용하기 어렵습니다. 하지만 컴파일러가 주요 작업을 담당함으로써 초기 단계의 프레임워크도 쉽게 적용할 수 있습니다;
Halo2로 작성된 PSE ZK-EVM 구성 요소와 같은 기존 백엔드 회로도 직접 호출을 통해 재사용할 수 있습니다;

협업 노력의 결과로, Taiko는 이미 Risc Zero의 zeth 및 ZK-VM을 개발 과정에 통합했으며, 별도의 SGX 백엔드도 개발했습니다. Taiko 엔지니어들은 또한 Powdr를 다중 증명 시스템에 통합하고, PIL 언어 및 라이브러리를 개발하며, 컴파일 최적화를 수행하고, 더 많은 백엔드를 추가하며, 일반적인 저수준 가속 처리를 진행할 예정입니다. 하드웨어 측면에서 Taiko의 제로 낼 지식 가속 레이어(ZAL)는 증명 시스템(Halo2, Arkworks, Risc Zero, Polygon 등)과 가속 라이브러리(CPU, GPU, FPGA 등) 사이의 협업 관계를 표준화하는 것을 목표로 합니다.

개방성

노드, 증명 시스템, 통합된 백엔드가 많을수록 개방성은 높아집니다. 따라서 Taiko는 커뮤니티 전체를 하나로 모으기 위해 노력하고 있으며, Taiko 팀은 PSE와 함께 ZK-EVM 및 Risc Zero 프로젝트에서 오랜 협력 역사를 갖고 있습니다.

이제 더 모듈화된 ZK 스택을 구축함으로써, Taiko는 API를 효과적으로 추상화하여 보다 쉬운 보급과 통합을 실현할 수 있습니다. Taiko는 플랫폼으로서, 실제 운영 환경에서 증명 시스템을 운용하고 체인 상에서 실전 테스트를 수행할 것입니다. Taiko는 모든 프로젝트가 함께 참여해 더 나은 제로 낼 지식 기술을 만들어가기를 진심으로 초대합니다.

Taiko 스택

Taiko의 multi-proof 패러다임에는 확장 가능하고 유연한 인프라가 필수적입니다.

ZK 유효성 증명의 출처는 노드의 실행 트레이스(Execution Trace)와 저장 증명(Storage Proofs)이며, 이는 witness 데이터와 공개 입력(public input)을 생성하는 데 사용됩니다. witness는 증명에 특화된 반면, 공개 입력은 프로토콜과 관련된다는 점에 유의해야 합니다. witness 생성을 처리할 강력한 인프라를 갖추는 것은 매우 중요합니다. 따라서 우리는 Multi-Client로부터 실행 트레이스를 수집하는 경량 호스트를 사용해 이를 여러 종류의 witness로 변환하고, 각각의 증명 시스템에 제공합니다.

증명 측면에서는, 이 설계는 모듈화된 스택과 일체형 스택 모두를 지원하며, 동시에 목표 노드(현재는 Geth)에서 동일한 공개 입력을 추출합니다.

미래에 상태 트레이스 형식이 호환된다면, Geth는 Taiko 노드로서 다른 노드로 대체될 수 있습니다. 또한 현재 Reth 위에서 실행되는 증명 시스템의 경량 노드 역시 어셈블리 언어를 처리할 수 있는 어떤 구현으로도 대체될 수 있습니다.

핵심 요점

Taiko는 다중 증명 = Multi-Client + 다수의 SNARKs(및 SGX와 같은 TEE)라고 믿습니다;
Taiko 프로토콜은 개방형 다중 증명 공급망, type-1 실행, L1 상의 데이터 가용성 게시 등을 통해 Multi-Client 시스템에 매우 적합합니다;
Taiko는 모듈화 및 개방성을 갖춘 다중 증명 아키텍처를 구상하고 있으며, Powdr Labs와 협력해 노드 및 ZKP의 교차 컴파일을 활용하고, Risc Zero와 협력해 그들의 ZK-VM 및 TEE 위에서 Taiko 실행을 구현하며, PSE와 함께 ZK-EVM 프로젝트를 계속 개선할 예정입니다;
Taiko의 유연한 인프라는 모듈화된 ZKP 스택과 일체형 ZKP 스택을 모두 포함합니다;