[ZK-STARK series] #03 STARK-Rollup Schema

Published in

Decipher Media ｜디사이퍼 미디어

23 min readFeb 27, 2023

StarkNet Token Image (Source : StarkNet Medium)

서울대학교 블록체인 학회 디사이퍼(Decipher) ZK-STARK 팀에서 영지식 증명 및 그 활용에 대한 글을 시리즈로 연재합니다. 본 시리즈는 법률 및 투자에 대한 권유 내지 조언을 일체 포함하고 있지 않으며, 본 글을 바탕으로 유관 의사결정을 내리지 마십시오.

Author

Jaewook Lee(a.k.a woogieboogie)of Decipher Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)

Reviewed By Yohan Lim, Sunghwan Ha

[ZK-STARK] Series

# 01. The Birth of STARK

# 02. Cairo

# 03. STARK Rollup Schema

# 04. Application

# 05. Appendix

1. Intro

지금까지 zk-STARK의 학술적 기반과 STARK 구현 언어인 카이로(CAIRO)에 대해 알아보았습니다. 그렇다면 이제 스타크 증명이 어떻게 어디서 사용되는지 알아봅시다. 현재 스타크를 활용한 생태계는 스타크웨어(StarkWare)가 주축으로 개발중이며, CAIRO 기반의 튜링 완전한 General Purpose 네트워크, 스타크넷(StarkNet), 특정 트랜잭션 특화형 zk-rollup 솔루션 스타크엑스(StarkEx) 등 스타크(STARK) 증명에 기반한 다양한 확장 / 보안 솔루션이 존재합니다.

다만 이론적인 정보만으로는 이러한 일련의 파편들이 이더리움과 같은 레이어 1에 어떻게 데이터 무결성을 확보할 수 있는지 이해하기 어렵습니다. 따라서 본 글에서는 영지식 증명에서 통용되는 데이터의 증명(Proving), 트랜잭션의 순서 결정(Sequencing), 그리고 L1단의 검증 단계(Verifier)의 종합적인 순서를 통해 실제 온체인 기록 과정을 알아보고, 그 과정에서 효율성을 높이는 장치인 SHARP(Shared Prover)과 하드웨어에 부담되는 리소스를 감소시키기 위해 나타난 재귀증명(Recursive Proof)의 개념에 대해 살펴보도록 하겠습니다. 이때 좀 더 범용적인 사례를 이해하기 위해 스타크 생태계 중에서도 스타크넷(STARKNet)을 위주로 살펴보도록 하겠습니다.

2. From L2 to L1: Transactions

2–1. StarkNet의 영지식 증명 스키마

영지식 증명의 온체인 구현은 옵티미스틱 롤업의 온체인(레이어 1) 기록 과정과 유사합니다(디사이퍼의 “옵티미스틱 롤업 — Arbitrum과 Optimism의 비교분석 글 참조). 옵티미스틱 롤업에 시퀀서가 트랜잭션을 ‘돌돌 말아’ 제출하고 일정 기간 동안 제출된 트랜잭션 정보에 대한 감사(Inspection-Challange)기간을 두는 반면, 영지식 롤업에서는 비슷한 구조지만 오프체인 증명자(Prover)와 온체인 검증자(Verifier)의 두가지 요소를 활용한 실행-증명 생성 -제출 — 기록의 과정을 통해 데이터 기록이 이루어집니다.

zk-rollup, optimistic rollup, 데이터 검증 방식은 다르지만, 같은 롤업 기반의 확장성 개선 방식으로 유사한 구조를 가지고 있습니다.

자, 그렇다면 스타크넷은 어떨까요?

먼저 스타크넷을 구성하는 요소와 트랜잭션이 발생하여 레이어 1에 기록되는 일련의 과정을 아래의 그림을 통해 알아보도록 합시다.

스타크넷과 이더리움 큰그림을 잡기 위한 스타크넷 측의 L1-L2 메시징 구조도

위 그림에서의 L1은 이더리움으로 L2 스타크넷의 DA 레이어로 작동하여 데이터의 완결성(Finality)을 확보합니다. L2는 스타크넷으로 외부의 무거운 연산, 혹은 프라이버시가 보장된 트랜잭션을 수행하고 그 결과값만을 DA 레이어인 이더리움에 기록합니다. 데이터 완결성의 관점에서 필자는 L1인 이더리움을 온체인, 연산을 위한 외부 네트워크이자 L2인 스타크넷을 오프체인으로 명명하고, 각각의 요소를 설명하도록 하겠습니다.

오프체인(스타크넷), 온체인(이더리움)의 요소로 나눠본 StarkNet의 증명-검증 요소

오프체인 네트워크, 즉 스타크넷에는 유저 계정(User Account), 시퀀서(Sequencer), 증명자(Prover), 풀노드(Full Node) 등이 포함됩니다. 또한 실제 검증 및 레이어 1단의 데이터 기록을 책임지는 온체인 요소는 모두 이더리움 위의 컨트랙트로, 스타크넷 코어(StarkNet Core) 검증자(Verifier) 컨트랙트가 포함됩니다. 이어서 오프체인, 온체인에 존재한 각각의 구성 요소들의 역할을 좀 더 자세히 알아보도록 하겠습니다.

2–2. 스타크넷의 오프체인 구성요소 알아보기

유저 계정(User Account):

스타크넷의 유저 계정은 스마트 컨트랙트의 형태로 구현됩니다. 이더리움의 경우 EOA(Externally Owned Accounts)와 이와 소통하는 스마트 컨트랙트 사이의 명확한 구분이 있는 반면, 스타크넷의 유저 계정은 스마트 컨트랙트의 형태로 존재하여 추후 Account Abstraction 과 같은 개념이 도입됐을 때 peer-social-recovery 방식 등으로 복구하는 방법을 넣는 등, 더 유연하게 이를 도입할 수 있도록 설계되었습니다. 이는 이더리움 로드맵에서 언급된 소울바운드 토큰(soul bound tokens)의 기반을 제공하기도 합니다.

시퀀서(Sequencer)

시퀀서는 스타크넷에서 유저가 트랜잭션을 보낸 후에 도달하는 첫번째 지점입니다. 시퀀서는 트랜잭션을 정렬하고 이에 맞춰 블록을 생성합니다. 생성된 블록이 컨센서스의 승인을 받으면 이후 증명자가 이를 맡아 온체인(L1, 이더리움)을 위한 증명을 생성합니다. 시퀀서는 Cairo OS를 사용하여 트랜잭션을 검증하며, 이는 이더리움 스마트 컨트랙트를 이더리움 가상머신(EVM)을 통해 실행하듯, 스타크넷에선 Cairo OS를 사용합니다. 현재 스타크넷에서 운영하는 시퀀서는 스타크웨어의 시퀀서 하나로, 최근 시퀀서 탈중앙화의 노력의 일환으로 이를 오픈소스화하는 노력을 보이기도 했습니다

증명자(Prover) — Shared Prover, SHARP

증명자는 앞서 시퀀서의 블록을 전달 받고 블록의 State값에 대한 올바른 연산이 수행되었음을 증빙하는 증명을 생성합니다. 그 중에서도 스타크넷은 증명 생성의 효율적인 처리를 위해 SHARP라는 공유 증명자(Shared Prover)를 사용합니다. SHARP의 목적은 간단합니다. 한개의 블록마다 생성되는 트랜잭션을 하나하나 증명을 생성하고 온체인(레이어 1)으로 전송하긴 비용이 너무 비싸니, 트랜잭션을 묶어서 증명하자는 것입니다. 다만 이 과정에서 SHARP는 스타크넷 내의 트랜잭션 뿐만 아니라 스타크엑스(StarkEX)와 같은 타 솔루션의 트랜잭션도 포함하여 증명하게 됩니다. 공유(Shared) 증명자(Prover)라는 이름이 붙게 된 경위기도 합니다.

여기서 증명의 대상이 되는 사항(Statements)이 특정 임계점, 혹은 한계점에 도달할 때까지 대기하고 있다가, 임계점을 넘으면 대규모 결합(Combined Statement)및 대기열(Train)이라고 부르기도 함)을 형성합니다. 다만 비용을 절감하기 위해 특정 임계점까지 사항들이 쌓여야 하기 때문에 이를 기다리는 시간이 더해져 증명 생성에서 온체인단의 검증을 통해 완결성을 지니기까지 상당한 시간이 걸립니다.

증명을 생성하는 과정 또한 메모리 자원을 많이 소요하는 작업이기 때문에 현재 구현 가능한 컴퓨팅 자원에 의해 묶음으로 처리할 수 있는 한도가 제한됩니다. 이는 결국 하드웨어 중앙화로 이어지고, 네트워크의 불안정성의 원인이 됩니다. 이를 극복하기 위해 스타크웨어측은 증명자 또한 오픈소스화를 진행해 분산화된 운영 방향을 가져갈 것임을 밝혔습니다 . 또한 추후 이러한 한계를 극복하기 위해 이후 재귀 증명(Recursive Proof)을 구현 중인데 이는 트랜잭션 및 전체적인 증명의 흐름을 설명한 후에 기술하도록 하겠습니다.

풀 노드(Full Node)

풀 노드는 Pathfinder라는 클라이언트를 실행하여 롤업에서 수행된 모든 거래를 기록하고 시스템의 현재 전역 상태를 추적하며, 이를 위해 새로운 블록이 생성될 때마다 해당 글로벌 상태의 변경 및 유효성 증명과 함께 p2p 네트워크를 통해 이 정보를 수신합니다. 새로운 풀 노드가 설정될 때, 해당 롤업과 관련된 모든 L1 거래를 처리하기 위해 이더리움 노드에 연결하여 스타크넷 코어(StarkNet Core) 컨트랙트를 통해 롤업의 동기화에 필요한 히스토리를 재구성할 수 있습니다.

최근에는 앞서 시퀀서의 오픈소스 전환에 이어 파피루스(Papyrus)라는 오픈소스(Apache 2.0 라이센스) 풀노드를 공개했습니다. Papyrus 풀 노드는 StarkNet의 상태가 시간이 지남에 따라 발전함에 따라 이를 추적하고, 사용자 및 개발자가 StarkNet의 JSON-RPC를 통해 상태에 대한 쿼리를 가능케 합니다. 기존 Pathfinder, Juno 풀 노드에 이어 노드 클라이언트 탈중앙화를 도울 세번째 클라이언트이기도 합니다.

2–3. 스타크넷의 온체인 구성요소 알아보기

앞서 언급한 것처럼, 온체인 구성요소엔 이더리움 내에 존재하는 두가지의 스마트 컨트랙트, 검증자(Verifier), 스타크넷 코어(StarkNet Core)가 포함됩니다.

검증자(Verifier) 컨트랙트

Ethereum위의 컨트랙트로, 새롭게 생성된 증명을 Prover로부터 L1 트랜잭션 형태로 전달받아 이를 체인 상에서 검증합니다. 검증 결과는 기록을 위해 StarkNet의 Core 스마트 계약으로 전송되고, 체인 상의 전역 상태를 업데이트하기 위해 StarkNet으로부터 새로운 L1 트랜잭션 세트가 요청됩니다.

StarkNet Core 컨트랙트

Verifier가 체인 상에서 L2 블록의 암호학적 증명을 성공적으로 검증한 경우, 새로운 L2 블록이 생성될 때마다 StarkNet의 L2 전역 상태 변경 사항을 수신하는 스마트 컨트랙트입니다. 이때 개별 블록의 공간 제한 때문에 여러 L1 트랜잭션으로 나누지 않고 “콜 데이터(Calldata)”로 상태 전이를 보내 가스를 절약합니다. 앞서 풀 노드 섹션에서 설명드렸지만, 이러한 StarkNet의 “메타데이터”는 StarkNet의 풀 노드에서 디코딩되어 네트워크 연결 후 신규 노드의 최초 동기화 시 네트워크의 이력을 재구성하는 데 사용됩니다.

3. From L2 to L1: Transactions

앞서 온체인 / 오프체인 구성요소들에 대해 알아봤습니다. 지금부터는 각 구성요소가 서로 어떻게 통신하여 온체인에 성공적으로 데이터 완결성을 보존하는지 알아봅시다.

3–1. 트랜잭션 발생 및 전달 과정

전형적인 ZK 롤업, 그 중에서도 Non-Interactive 기반의 영지식 롤업의 경우, 오프체인 연산 후에 해당 연산을 검증하는 공통적인 과정이 존재합니다. 이 경우 프로그램 또는 계약 자체가 레이어2에 배치되고, 컴파일, 매개 변수 및 증명 생성은 레이어2 노드에서 오프체인으로 실행되며, 증명은 이더리움 메인넷에 게시되어 검증됩니다. ZK-STARK 또한 이와 마찬가지로, 중간 요소만 살짝 다를 뿐 같은 구조를 따르고 있습니다.

(1) 유저 계정에서 네트워크 내 활동을 통해 트랜잭션을 발생시킵니다.
(2) 시퀀서가 트랜잭션을 담아 실행 및 블록을 생성하고 이에 대한 증명 생성을 위해 execution trace와 함께 이를 증명자에 전달합니다.
(3) 증명과 최종 State의 변화값(state difference)을 담은 값을 풀 노드에 전달합니다. (아카이브 목적)
(4) 증명을 L1의 검증자(Verifier) 스마트 컨트랙트로 전달합니다
(5) 검증자(Verifier) 컨트랙트는 이를 검증하는 isValid() 함수를 실행 후 True / False 값에 따라 이를 스타크넷 코어(StarkNet Core) 컨트랙트에 기록합니다. 만약 isValid()의 결과값이 False로 판명될 경우 트랜잭션은 Rejected 됩니다.
(6) State의 변화값만을 스타크넷의 시퀀서에서 전달받아 업데이트합니다

3–2. 스타크넷의 트랜잭션 상태 업데이트 과정

위 트랜잭션 전달 과정을 트랜잭션의 입장에서 고민해 봅시다. 아래는 스타크넷(오프체인, L2)에서 발생한 트랜잭션의 상태 업데이트 과정을 나타낸 도식입니다.

(1) 사용자가 사용자 계정에서 거래를 시작하면 L2 네트워크로 전송되며, 전체 노드 및 시퀀서는 이를 메모리 풀에 추가합니다. 시퀀서의 메모리 풀에 아직 도착하지 않은 거래는 NOT_RECEIVED(수신되지 않음) 상태로 남게 됩니다.
(2) 거래가 시퀀서의 메모리 풀에 도착하면 RECEIVED(수신됨)로 표시됩니다.
(3) 메모리 풀에서 거래는 “보류 중인 블록”에 추가되며, 충분한 거래가 도착할 때까지 미완료된 블록으로 유지됩니다. 보류 중인 블록에 추가된 거래는 PENDING(대기 중) 상태입니다.
(4) 보류 중인 블록에 들어가는 모든 거래는 시퀀서에 의해 실행되고 검증됩니다. 거래가 유효성 검사를 통과하면 ACCEPTED_ON_L2(L2에서 수락됨) 상태가 되지만, 그렇지 않으면 REJECTED(거부됨) 되며 폐기됩니다.
(5) 다음 1시간 내에 L1 체크포인트가 이루어지면, 체인 상에서 해당 거래의 일괄 처리 증명이 검증되고 Ethereum에 관련 데이터가 저장되면 거래는 ACCEPTED_ON_L1(L1에서 수락됨) 상태로 표시됩니다. 하지만, 체인 상의 검증자가 암호학적 증명을 거부하면 해당 거래는 REJECTED(거부됨) 상태로 표시되어 폐기됩니다.

3–3. Problem: Hardware Limits & Finality

이렇게 Trusted Setup 없이 실행-증명 생성 — 제출 — 기록의 단계를 거쳐 기록되는 zk-STARK, 자세하게는 스타크넷을 이용한 확장 솔루션에는 크게 두가지 정도의 문제가 발생합니다. 첫째는 하드웨어의 한계로 인한 탈중앙화의 어려움, 둘째는 실제 레이어 1단에서 트랜잭션이 전파된 후, 완결성(Finality)을 확보하기까지 걸리는 시간이 너무 길다는 것입니다.

StarkNet Core Contract까지 State가 업데이트 되어야 완결성이 확보됩니다.

문제 1. 중앙화를 낳는 하드웨어 스펙
패러다임(Paradigm)의 Georgios Konstantopoulos가 발간한 레포트에 의하면, 영지식 증명에서 요구되는 대부분의 연산 작업은 MSM(Multi-Scalar Multiplications)와, FFT(Fast Fourier Transforms)의 두가지 연산으로 나뉩니다. STARK 증명이 사용하는 PCS(Polynomial Commitment Scheme)의 경우 FRI(Fast Reed-Solomon Interactive Oracle Proofs of Proximity)라는 RS-code 기반을 사용하고 있어 MSM이 거의 사용되지 않는다고 봐도 무방합니다. FFT 연산의 효율화가 연산 성능에 지대한 영향을 미친다는 것이죠.

https://cdn-images-1.medium.com/max/1000/0*4xqRWY1g_8EX4wBu.png — 타원곡선 기반의 SNARK 증명의 경우 MSM 연산이 많아 GPU 처리가 용이하나, FFT의 연산을 위한 하드웨어는 상대적으로 부족합니다.

MSM의 경우 GPU의 멀티코어 구조 하에서 병렬 처리 연산이 상대적으로 쉬운 반면, 스타크나 폴리곤 헤르메즈(Hermez)에서 주로 사용되는 FFT 연산의 경우 FPGA(Field Programmable Gate Arrays) 아키텍쳐가 더 적합합니다. 혹은 이를 FFT 연산 용도에 따라서 더 최적화 시킨 ASIC(Application-Specific Integrated Circuit — FFT 연산에 특화된 하드웨어를 지칭)을 사용할 수도 있지만, 양쪽 모두 개발이 더딘 상황입니다. STARK 증명을 뒷받침할만한 하드웨어 인프라는 많이 미비한 상황인 것이죠.

특히 증명자 연산은 많은 메모리(Random Access Memory)를 요구하는데, 적게는 몇백 GB의 메모리 많게는 TB 단위의 메모리를 요구하여 사양이 대중적이지 못합니다. 하드웨어 인프라가 부족하니 재단이 제공하는 증명자에 네트워크 부하가 몰리고, 결국 하드웨어 중앙화 문제에 직면하여, 위험 상황에서의 네트워크의 안정성은 떨어지게 됩니다.

문제 2. 생각보다 너무 느린 L1 완결성 획득시간
필자는 이전에 스타크넷 테스트넷에서 Starknet.ID를 획득하기 위해 각종 퀘스트를 클리어를 목적으로 스타크넷 테스트 환경을 잠시나마 경험해본 바 있습니다. 당시 느린 속도, 두시간이 넘는 레이어 2 완결성(시퀀서단의 체크포인트) 그리고 6시간이 지나서야 완결성을 보장받는 검증 속도까지, 실제 구현을 통해 접해본 스타크넷은 대중이 납득할 수 없는 정도의 사용성을 갖추고 있었습니다.

당시 테스트 네트워크에서 부여되는 퀘스트를 모두 깨면 디스코드 롤을 부여해주는 이벤트를 참여중에 있었습니다.

심지어 당시 시퀀서 중앙화로 인해 위에서 언급드린 상태 전이 과정에서 Received ⇒ Accepted_on_L2 조차 제대로 실행되지 않았고, 실제로 완결성 획득까지 걸리는 시간은 당시 2시간을 훌쩍 넘은 6시간 내외로, Relayer를 사용할 경우, 트랜잭션의 완결성이 몇분 내로 확보되는 옵티미스틱 롤업 기반의 두 체인과 비교했을 때 사용성이 현저히 떨어졌습니다.

완결성 확보까지 6시간 정도 소요, 현재는 2시간 정도로 약간의 개선이 있었습니다.

물론 모든 영지식 증명 기반 확장성 솔루션이 같은 불편함을 겪고 있진 않습니다. SNARK 기반의 zkSync는 20분 내의 완결성을 보유하고 있어 어느 정도의 사용성은 갖춘 상황입니다. 하지만 StarkNet의 사용성과 완결성 확보에 걸리는 시간적 딜레이는 명확히 개선이 필요해 보입니다.

4. Solution: Recursive Proofs

사실 위의 문제는 1) SHARP에서 증명 생성을 실행하는 임계점(Threshold)을 더 낮게 설정하여 L1으로 전송하는 증명을 만드는 주기를 짧게 하거나 2) 증명자를 여러개로 늘려 네트워크의 부하를 분산시키는 방식으로 개선이 가능합니다. 하지만 주기를 짧게 할수록 들어가는 증명 생성 비용 대비 효용은 오히려 줄기 때문에 이는 근본적인 해결방안이 될 수 없습니다. 오히려 확장성을 목표로 한 영지식 증명의 성공 기준은 임계점을 높게 유지시키고 동시에 증명과정의 병렬처리를 통해 처리량을 늘려야만 이를 근본적인 해결방법이라 할 수 있을 것입니다. 개발사인 스타크웨어는 이러한 문제를 어떻게 해결하려 할까요?

4–1. Recursive Prooving & SHARP

스타크웨어는 최근 많은 영지식 증명 프로젝트가 연구하는 주제, 재귀증명(Recursive Proof)를 통해 이를 극복하려 합니다. 재귀증명이란 “영지식 증명의 생성 코드(relation) 안에 이전에 생성된 증명을 검증하는 코드를 포함하는 과정” 으로, 쉽게 말하면, “특정 증명이 증명됐다는 것을 증명하는 행위”라고 이해하면 좋습니다. 증명한 과정을 보여주지 않아도 결과물이 증명만을 검증자가 확인하고 “증명했다는 사실”을 기반으로 의 참과 거짓을 판단할 수 있는 것이죠 (학술적 개념은 정현님의 “재귀적 영지식 증명 이해하기” 글 참고)

STARK 증명에선 명제를 증명하는 데 걸리는 시간은 대략 명제를 실행하는데 걸리는 시간과 선형 비례한 T 시간이 걸리는 반면,증명을 검증하는 데는 대략 log(T) 시간이 걸립니다. SNARK 증명과 함께 로그 압축이 가능한 STARK 증명은 이러한 효율적인 검증(Verify) 과정의 재귀 증명을 통해 확장성을 더욱 개선할 수 있는 것입니다.

SNARK vs STARK vs Bulletproofs. Source: Matter Labs

STARK로 재귀(recursion)를 수행하는 방식은 간단합니다. 여러 개의 STARK 증명을 검증하는 Cairo 프로그램을 작성 후, 이를 통해 여러 “상위(up-stream)” 증명의 유효성을 증명하는 단일 증명인 ‘재귀 증명’을 생성하면 됩니다.

STARK 증명에서 선형 시간 T로 압축된 증명의 검증 시간은 log(T)에 불과하므로, 이를 여러번 겹겹히 연산하면 실제 검증에 소요되는 시간을 크게 단축할 수 있다고 합니다. 본 글에서는 이에 대한 개념적 아이디어를 앞서 살펴봤던 SHARP를 변형하여 확인해 보도록 하겠습니다.

Recursive Verifier Statement의 도입으로 재귀 증명이 가능해집니다.

4개의 다른 소스(디앱)에서 전송된 4개의 검증문(Statement)이 SHARP에 전송됐다고 생각해 봅시다. 재귀 증명에선 이들 명제를 각각 병렬로 증명합니다. 그런 다음 스타크 증명을 검증하는 카이로 프로그램인 재귀 검증문(Recursive Verifier Statement)에 의해 페어를 이룬 증명 쌍이 검증됩니다. 그런 다음 두 개의 증명이 다시 재귀 검증문에 의해 병합됩니다. 이로써 처음부터 4개의 원래 명제가 증명된 하나의 증명이 생성됩니다. 이 증명은 마지막으로 온체인의 검증자 컨트랙트에서 확인됩니다.

4–2. What For?

위의 재귀 증명 과정 도입은 기존 증명 방식 대비 1)온체인에서의 검증비용 감소, 2) 지연시간 감소, 3) 프랙탈 스케일링의 초석 놓기 등 세가지 정도의 개선점을 제안합니다.

온체인 비용 감소

초기 단계에서 여러 개의 증명을 하나로 압축하기 때문에 각 명제에 대한 온체인 검증 비용이 감소합니다. 1,000개의 트랜잭션의 증명을 온체인의 검증자 컨트랙트에서 1,000번 검증할 비용을 단일 증명으로 압축한다면 최종 변경된 State와 이에 대한 증명의 증명을 이용해 단일 검증으로 이를 온체인에 업데이트할 수 있습니다.

또한 재귀를 사용하면 이제까지 증명 크기를 제한한 컴퓨팅 리소스(예: 메모리)의 장벽을 개선할 수 있습니다. 재귀를 사용하면 전체 재귀를 처리하는데 들어가는 연산 하드웨어의 스펙을 낮추고 증명 횟수를 늘리는 방식으로 대처가 가능하기 때문입니다. 앞서 언급드린 FFT 기반에서 오는 부족한 하드웨어 스펙을 극복하고 보다 대중적인 사양에서도 증명을 생성할 수 있는 가능성이 열리는 것입니다.

지연시간 감소

재귀 증명 패턴은 특히나 공유 증명자(SHARP)를 사용하는 스타크넷에 있어서 대규모 명제를 증명하는 지연시간을 획기적으로 줄일 수 있습니다. 기존에 증명을 직렬적으로 처리하던 대기열(Train)의 마지막 명제가 도착하기까지 기다리는 과정의 병렬처리가 가능해지기 때문입니다. 따라서 대기열에 등록된 명제가 이미 검증된 재귀 검증문 문을 증명하는 데 걸리는 시간 이상으로 대기열의 마지막 명제의 지연시간이 거의 동일해지며, 스타크웨어 측에서는 이 지연시간 개선 이후 증명 검증 시간이 기존 몇시간 대비 몇 분 정도의 수준으로 줄어들 것으로 예상하고 있습니다.

프랙탈 스케일링(Fractal Scaling)

재귀 증명의 구현에서 등장하는 재귀 검증문(Recursive Verifier Statement)개념은 스타크넷(L2) 위의 L3, L4, L5… 등 상위 레이어가 하위 레이어에게 복잡한 연산의 결과값만을 제출할 수 있는 재귀적 패턴(Recursive Pattern)을 가능케 합니다. 좀더 설명하면, L2 ⇒ L1에서 복잡한 연산을 처리하고, 검증 후에 State값만을 업데이트한 것처럼, Ln+1 레이어에서의 증명 생성, Ln 레이어에서의 검증(재귀 검증문 활용)을 통해 이론적으로는 무한한 확장성을 가질 수 있다는 것입니다.

https://cdn-images-1.medium.com/max/1000/0*_twHLX9BgpShjNJG.jpeg — L1 — L2 — L3 까지 이어지는 재귀적 증명 패턴을 나타낸 도식

위의 이미지는 스타크넷에서 제공하는 L3-L2(StarkNet)-L1(Ethereum) 아키텍쳐의 구조도로, 상위 레이어의 연산을 검증하는 검증 컨트랙트 및 이를 기록하는 컨트랙트가 하위 레이어에 존재하는 것을 확인할 수 있습니다.

스타크넷이 그리는 레이어 4 스키마: L1(이더리움)-L2(StarkNet)-L3(App Specific Solutions)-L4(Privacy)

물론 “이론상” 무한한 확장성을 가질 수 있다는 것이지, 스타크웨어가 프랙탈 스케일링의 개념을 설명하면서, 사용한 구조도로 비춰보아 현재 제시된 청사진은 L1(이더리움)-L2(StarkNet)-L3(App Specific Solutions)-L4(Privacy) 정도의 확장성을 고려하고 있음을 알 수 있습니다.

5. Conclusion: zk-STARK, the endgame

더딘 개발 현황, 부족한 하드웨어 인프라와 완결성 속도 등, zk-STARK는 아직도 갈 길이 멉니다. 엎친데 덮친 격으로 zkEVM(Polygon), Plonky, Halo 등, zk-SNARK 기반의 경쟁 솔루션들이 다수 출시되고 있어, 마냥 넋놓고 있다간 시장성을 잃을 상황입니다. 그럼에도 불구하고 스타크는 신뢰환경 설정(Trusted Setup)이 요구되지 않음에도 불구하고 log(T)의 빠른 검증 시간을 가진다는 너무나도 명확한 장점을 보유하고 있습니다. 스타크 증명이 영지식 증명 기술의 엔드게임(endgame)이라 불리는 이유기도 합니다.

또한 부족한 확장성, 속도, 탈중앙성에 대한 해답들도 재귀 증명, 오픈소스화, 체크포인트 형성* 등의 솔루션들이 제시되고 있으며, 종국에는 빠르게 발전하는 하드웨어 성능과 함께, 신뢰환경 설정 없이도 레이어 2의 확장성을 비신뢰성 방식으로 향상시킬 수 있는 빠르고 혁신적인 기술로 수렴해 갈 것이라고 판단하고 있습니다.

다음 읽어볼 시리즈물에선 실제 코드 레벨에서 스타크넷의 NFT와 각종 토큰 규격들을 살펴보고, 이를 실제로 구현해 보면서 카이로의 개발 원칙과 이를 스타크 생태계가 어떻게 담고 있는지 알아보도록 하겠습니다.