영지식 증명: Solana에서의 활용

소개

이 글은 영지식 증명 입문 시리즈의 두 번째 글입니다. 먼저 영지식 증명: 기초 개념 소개를 읽어보시기를 강력히 권합니다. 이 글의 분석에 필요한 이론, 수학, 암호학적 맥락을 다루고 있기 때문입니다. 이 글은 해당 내용을 알고 있다고 가정합니다. 영지식 증명이 익숙하지 않다면 앞선 글을 먼저 읽어보세요. 이 글의 목표는 독자가 Solana의 영지식 증명에 관한 논의에 참여하고, 더 나아가 새롭고 혁신적인 영지식 프리미티브를 개발하는 데 필요한 지식을 갖추도록 돕는 것입니다.

이제 새롭게 얻은 지식을 바탕으로 마침내 질문할 수 있습니다. 영지식 증명이란 무엇일까요? Solana에서는 어떻게 사용될까요?

영지식 증명이란?

이제 필요한 이론과 수학, 암호학을 배웠으니 다음 질문을 던져야 합니다. 영지식 증명이란 정확히 무엇일까요?

영지식 증명은 어떤 명제가 참이라는 사실 외에 어떠한 추가 정보도 공개하지 않고, 한 당사자가 다른 당사자에게 그 명제가 참임을 입증하는 암호학적 과정입니다. 이러한 증명은 통계적으로 건전하고 완전해야 하며, 정보 유출로부터 안전해야 합니다.

영지식으로 증명하려는 명제에는 두 가지 유형이 있습니다. 개괄적으로 보면 다음과 같습니다.

• 사실에 관한 명제(예: 이 특정 그래프는 3색으로 색칠할 수 있음)
• 지식에 관한 명제(예: 나는 N의 인수분해를 알고 있음)

첫 번째 명제는 궁극적으로 우주의 내재적 속성, 즉 1 + 1 = 2처럼 근본적으로 참인 사실을 다룹니다. 두 번째는 지식 증명이라고 합니다. 단순히 무언가가 참임을 증명하는 데 그치지 않고 증명자가 무엇을 아는지에 의존합니다.

앞서 언급했듯 이러한 명제를 증명하는 방식은 대화형일 수도 있고 비대화형일 수도 있습니다. 대화형 영지식 증명에서는 검증자가 합리적인 의심의 여지 없이 확신할 때까지 증명자와 검증자가 여러 라운드에 걸쳐 상호작용합니다. Zcash는 비대화형 영지식 증명을 사용해 사용자가 익명 트랜잭션을 수행할 수 있게 합니다. 

반면 비대화형 영지식 증명에서는 증명자와 검증자가 직접 소통하지 않으며 증명이 오프라인으로 전달됩니다. 증명자는 필요한 모든 정보를 포함하는 증명을 생성하고, 검증자는 추가 상호작용 없이 이를 독립적으로 검증할 수 있습니다. Filecoin은 비대화형 영지식 증명을 사용해 데이터 자체를 공개하지 않고도 사용자가 데이터를 저장했음을 증명합니다. 

 zk-SNARK와 회로

zk-SNARK는 간결한 비대화형 지식 논증(Succinct Non-interactive ARgument of Knowledge)입니다. 이러한 영지식 증명은 특히 효율적이고 작습니다. 즉, 간결합니다. 증명의 크기와 검증에 필요한 시간이 모두 검증할 연산보다 느리게 증가하면 간결한 증명으로 간주합니다. 따라서 간결한 증명을 원한다면 검증자가 해싱의 매 라운드마다 작업을 수행하게 해서는 안 됩니다. 그렇게 하면 검증 시간이 연산량에 비례하기 때문입니다. 다항식과 Fiat-Shamir 휴리스틱 덕분에 간결한 증명이 가능합니다.

증명하려는 명제가 아무리 복잡하더라도 zk-SNARK는 증명 크기를 작게 유지하며 비교적 빠르게 검증할 수 있습니다. 이것이 zk-SNARK가 롤업에 매력적인 이유입니다. 특정 L2의 모든 트랜잭션이 유효함을 증명하면서도 그 증명이 L1에서 검증할 만큼 작기 때문입니다. Mina 같은 프로토콜은 한 단계 더 나아가 재귀 증명을 사용합니다. 이를 통해 크기가 일정한 증명 하나로 체인의 전체 기록을 검증할 수 있습니다. Pickles는 Mina의 새로운 증명 시스템이자 관련 툴킷입니다. 신뢰 설정 없이 재귀 합성이 가능한 최초의 실제 배포된 zk-SNARK입니다. 여기서 재귀 합성이란 회로를 의미합니다.

회로는 증명하려는 연산을 기술합니다. 일부 입력을 받아 출력을 생성하는 일련의 수학 연산입니다. 영지식 증명에서 회로는 연산 입력을 공개하지 않으면서 연산이 올바르게 수행되었음을 표현하는 데 사용됩니다. 일반적인 워크플로는 다음과 같습니다.

• 회로 작성 및 컴파일 — 회로를 작성하고 컴파일해야 합니다. 소수 p = 7로 정의된 유한체 위에서 x * y = z 연산을 수행하는 산술 회로를 만드는 것처럼 간단할 수도 있습니다. 핵심은 증명할 연산을 변수 사이의 제약 조건 집합으로 표현하고, 이 제약 조건을 다항 방정식으로 축약한 다음, 모든 값을 새로운 대수 구조로 매핑하는 코드, 즉 준동형을 작성하는 것입니다. 컴파일 과정에서는 회로가 정의한 제약 조건 집합과 이후 단계에서 사용할 스크립트 또는 바이너리 등 여러 산출물이 생성됩니다
• 신뢰 설정 행사 — 증명 키와 검증 키를 생성하는 데 사용되는 zk-SNARK 유형에 따라 행사를 진행해야 할 수 있습니다
• 회로 실행 — 컴파일 중 생성된 스크립트나 바이너리를 일종의 프로그램처럼 사용해 회로를 실행해야 합니다. 사용자가 공개 및 비공개 입력을 제공하면 모든 중간 변수와 출력 변수의 값이 계산됩니다. 트레이스라고도 하는 증인은 모든 연산 단계를 기록한 것입니다
• 증명 생성 — 두 번째 단계의 증명 키와 세 번째 단계의 증인을 사용해, 증명자는 출력값만 공개하면서 회로에 정의된 모든 제약 조건이 성립한다는 영지식 증명을 생성할 수 있습니다. 이 증명은 검증자에게 전송됩니다
• 증명 검증 — 검증자는 제출된 증명과 검증 키를 사용해 해당 공개 출력에 대한 증명이 올바른지 확인합니다

Groth16과 같은 일부 zk-SNARK 유형은 회로마다 신뢰 설정이 필요합니다. 새 프로그램을 만들 때마다 새 행사를 진행해야 하므로 제약이 될 수 있습니다. PlonK와 같은 다른 zk-SNARK는 범용 신뢰 설정을 한 번만 요구하므로 전체 과정이 단순해집니다. zk-STARK와 같은 또 다른 영지식 증명 유형은 신뢰 설정 자체가 전혀 필요하지 않습니다.

zk-STARK

zk-STARK는 확장 가능하고 투명한 지식 논증(Scalable Transparent ARgument of Knowledge)입니다. zk-STARK는 StarkWare가 발명했으며, zk-SNARK의 대안으로 2018년 이 논문에서 처음 제안되었습니다. 본질적으로 블록체인이 연산을 단일 오프체인 STARK 증명자로 옮기고, 온체인 STARK 검증자를 사용해 해당 연산의 무결성을 검증할 수 있게 합니다. 

오프체인 증명자가 사용하는 입력이 블록체인에 노출되지 않아 사용자의 개인정보가 보호되므로 zk-STARK는 영지식으로 간주됩니다. 연산을 오프체인으로 옮기면 L1 검증 비용이 크게 줄어들기 때문에 확장성도 높습니다. 또한 zk-SNARK가 준선형으로 확장되는 반면, zk-STARK의 증명은 선형으로 확장됩니다. 더불어 zk-STARK는 복잡한 신뢰 설정 행사에 의존하지 않습니다. 이러한 행사를 올바르게 진행하지 않으면 검증자가 유효하지 않은 증명을 받아들이는 유해 폐기물 문제가 생길 수 있다고 보기 때문입니다. 대신 공개적으로 검증 가능한 무작위성을 사용해 증명자와 검증자 사이의 상호작용을 설정합니다. 또한 이러한 증명은 필요한 보조 입력과 함께 연산을 실제로 실행한 오프체인 증명자만 생성할 수 있습니다.

zk-STARK는 확장 가능하고 투명한 지식 논증을 제공해 zk-SNARK의 한계를 해결합니다. 암호학적 가정도 훨씬 단순하며 타원 곡선 같은 요소가 전혀 필요하지 않습니다. 오직 해시와 정보 이론에만 의존하므로 양자 내성을 갖습니다. 그러나 증명 크기가 수백 킬로바이트에 달해 블록체인처럼 대역폭이나 저장 공간이 제한된 환경에서는 활용 가능성이 낮아질 수 있습니다. 일부 더 복잡한 증명 설정과 zkVM은 최종 검증 단계에서만 zk-STARK를 zk-SNARK로 재귀 증명하는 방식을 함께 사용합니다.

ZK Compression

상태 증가 문제

Solana가 직면한 가장 시급한 문제 중 하나는 상태 증가 문제입니다. 맥락을 설명하면 Solana의 상태는 풀 노드 디스크의 Accounts DB에 저장됩니다. 이는 키-값 저장소이며 데이터베이스의 각 항목을 계정이라고 합니다. 각 계정 주소는 32바이트이며, 계정이 저장할 수 있는 데이터는 0~10MB입니다. 현재 10MB의 데이터를 저장하는 비용은 약 70 SOL입니다. 하나의 10MB 계정에 저장하든 1,000개의 10KB 계정에 나눠 저장하든 같습니다. 상태 증가 문제에 관한 Toly의 게시물에 따르면 매일 약 100만 개의 새 계정이 체인에 추가되며, 전체 상태는 5억 개가 넘는 계정에 이릅니다. Solana가 계속 성장하면 무제한으로 커지는 스냅샷 크기, PCI 대역폭 제한, 계정 인덱싱, 높은 메모리 및 디스크 관리 비용 등 여러 문제가 발생합니다. 

현재 전체 스냅샷 크기는 약 70GB로, 현행 하드웨어로 관리할 수 있는 수준입니다. 그러나 계속 성장하면 상태 관리의 비효율과 잠재적 병목이 불가피합니다. 스냅샷 크기가 늘어날수록 하드웨어 장애 후 새 시스템을 콜드 부팅하는 데 훨씬 더 오랜 시간이 걸립니다. 네트워크를 재시작해야 할 때 특히 치명적일 수 있습니다. 

PCI(Peripheral Component Interconnect) 대역폭은 CPU와 그래픽 카드, 네트워크 카드, 저장 장치 같은 주변 기기 사이의 데이터 전송률을 의미합니다. PCI Express(PCIe)는 기존 PCI 표준을 대체하고 더 높은 데이터 전송률을 제공하도록 설계된 고속 인터페이스 표준입니다. 최신 PCI 대역폭은 1TB, 즉 128GB/s에 달합니다. 매우 커 보이지만 Solana의 맥락에서는 그렇지 않습니다. 트랜잭션 하나가 128MB를 읽거나 쓴다면 128GB/s의 PCI 대역폭으로 Solana는 초당 1,000개 트랜잭션(TPS)만 처리할 수 있습니다. 다만 대부분의 트랜잭션은 이미 검증인의 RAM에 로드되고 캐시된 최근 메모리에 접근합니다. 그럼에도 Solana가 확장되는 동안 높은 처리량을 유지하려면 효율적인 상태 메모리가 필수입니다. 그렇지 않으면 이 대역폭이 빠르게 제약 요인이 될 수 있습니다.

각 검증인은 기존의 모든 계정에 대한 인덱스를 유지해야 합니다. 새 계정을 생성하려면 해당 계정이 아직 존재하지 않는다는 증명이 필요하기 때문입니다. 전체 상태가 5억 개 이상의 계정으로 구성된 상황에서는 최소 인덱스, 즉 항목당 32바이트 키와 32바이트 데이터 해시만 사용해도 약 32GB의 RAM이 필요합니다. 이러한 상태 저장에는 많은 비용이 들며 성능 저하를 방지하려면 신중하게 관리해야 합니다. Solana의 상태가 계속 증가할수록 특정 작업에는 빠르고 비싼 메모리인 RAM을 사용하고, 다른 작업에는 느리지만 저렴한 디스크를 사용하는 구분이 중요해집니다.

트랜잭션과 상태 증가

모든 Solana 트랜잭션은 읽고 쓰는 계정을 모두 지정해야 합니다. 현재 트랜잭션 크기는 1232바이트로 제한되며 다음을 포함해야 합니다.

• 헤더(3바이트)
• 서명(각 64바이트)
• 계정 주소(각 32바이트)
• 명령 데이터(임의 크기)
• 최근 블록해시(32바이트)

트랜잭션을 실행하면 다음 과정이 진행됩니다.

• 정상성 검사 — 최근 트랜잭션만 유효하며 트랜잭션에 대해 중복 제거, 구조 검증, 수수료 및 서명 검사를 수행합니다
• 프로그램 로딩 — 프로그램 주소에 따라 프로그램 바이트코드를 로드하고 Solana Virtual Machine(SVM)을 인스턴스화합니다
• 계정 로딩 — 트랜잭션이 참조하는 모든 계정을 확인해 저장소에서 메모리로 로드한 뒤 SVM에 전달합니다
• 실행 — 프로그램 바이트코드를 실행합니다
• 동기화 — 수정된 계정을 저장소에 다시 동기화합니다

상태가 계속 증가하면 이 수명 주기에서 여러 문제가 발생합니다. 특히 온체인 상태는 비싸고, 디스크에 저장된 계정이 많을수록 스냅샷과 인덱스가 커집니다. 또한 모든 계정에 자주 접근하는 것은 아니므로 지속적인 리소스 비용을 부담하는 것은 비효율적입니다.

ZK Compression으로 상태 관리 간소화

모든 계정을 디스크에 저장했다가 필요할 때 읽는 대신, 트랜잭션 페이로드의 일부로 계정 데이터를 전달할 수 있습니다. Merkle 트리를 사용하면 트랜잭션을 제출하는 사용자가 올바른 상태를 제공했는지 확인할 수 있습니다. Merkle 증명은 일부 데이터를 커밋하는 방법입니다. 커밋을 기준으로 증명을 검증해 올바른 상태가 전달되었고 사용자가 제공한 상태에 관해 거짓말하지 않았는지 확인할 수 있습니다. 

이러한 증명은 안전하지만 상당히 클 수 있습니다. 예를 들어 트리에 계정 10만 개가 들어 있다면 증명 크기는 544바이트입니다. 여러 계정의 증명을 제공하면 트랜잭션 크기 제한인 1232바이트를 빠르게 초과할 수 있습니다. 다행히 더 효율적인 증명 시스템을 사용해 이를 피할 수 있습니다. KZG 또는 Pedersen 커밋먼트처럼 증명 크기가 일정한 커밋먼트를 사용하면 증명 크기를 줄여 트랜잭션 크기 제한 안에 포함하기가 쉬워집니다.

ZK Compression은 Merkle 증명 크기 문제를 해결하는 메커니즘입니다. Solana의 원장을 활용해 온체인 저장 비용을 부담하지 않고 특정 연산이 올바르게 수행되었음을 증명하는 방법입니다.

ZK Compression이란?

ZK Compression은 보안, 성능, 결합 가능성을 유지하면서 온체인 상태를 압축해 상태 비용을 수십에서 수천 배 줄일 수 있는 새로운 프리미티브입니다. 예를 들어 토큰 계정 100개를 생성하는 현재 비용은 ~0.2 SOL이지만, ZK Compression을 사용하면 5,000분의 1인 ~0.00004로 줄어듭니다. 

ZK Compression은 영지식 증명을 활용해 기반 데이터를 노출하지 않고 상태 전환을 검증합니다. 여러 계정을 하나의 검증 가능한 Merkle 루트로 묶어 온체인에 저장하고, 기반 데이터는 원장에 저장하는 방식입니다. 유효성 증명은 m개의 상태 트리에 리프로 포함된 n개 계정의 존재를 증명하는 간결한 영지식 증명입니다. 증명 크기는 항상 128바이트로 유지됩니다. 이러한 증명은 오프체인에서 생성되고 온체인에서 검증되므로 Solana의 전체 연산 부담이 줄어듭니다. ZK Compression의 증명자 시스템은 잘 알려진 페어링 기반 zk-SNARK인 Groth16을 사용합니다.

그러나 이러한 계정은 일반 Solana 계정이 아닙니다. 대신 압축 계정입니다.

압축 계정 모델

ZK 압축 상태는 압축 계정에 저장됩니다. 이러한 계정은 일반 Solana 계정과 비슷하지만 효율성과 확장성을 높이는 몇 가지 주요 차이점이 있습니다.

• 해시 식별 — 각 압축 계정은 해시로 식별할 수 있습니다
• 쓰기 시 해시 변경 — 압축 계정에 쓰기 작업을 수행하면 해시가 변경됩니다
• 선택적 주소 — 주소를 압축 계정의 영구 고유 ID로 선택적으로 설정할 수 있습니다. NFT 같은 특정 사용 사례에 유용합니다. 압축 계정은 해시로 참조할 수 있으므로 연산 오버헤드를 피하기 위해 이 필드는 선택 사항입니다
• 희소 상태 트리 — 모든 압축 계정은 Merkle 트리에 저장되며 트리의 상태 루트, 즉 Merkle 루트만 온체인 계정 공간에 저장됩니다. 더 구체적으로 상태 트리는 Poseidon 해시 기반의 동시성 Merkle 트리입니다

압축된 프로그램 파생 주소(PDA)는 고유하고 영구적인 주소로 식별할 수 있습니다. Data, Lamports, Owner, Address 필드로 구성되며 일반 PDA 계정과 유사한 레이아웃을 따릅니다. 다만 일반 PDA와 달리 Data 필드에는 Discriminator, Data, DataHash 필드로 구성된 AccountData 구조가 포함됩니다.

노드

여러 유형의 노드가 ZK Compression 지원에 중요한 역할을 합니다. 누구나 Devnet 및 Mainnet-Beta 연결을 위한 Photon RPC 노드, Prover 노드 또는 Light Forester 노드를 실행할 수 있습니다. 로컬 개발에서는 ZK Compression CLI의 test-validator 명령으로 관련 노드, 즉 Photon RPC와 Prover는 물론 시스템 프로그램, 계정, 런타임 기능까지 갖춘 단일 노드 Solana 클러스터를 시작할 수 있습니다.

Photon RPC 노드는 압축 프로그램을 인덱싱합니다. 이를 통해 클라이언트는 압축 상태와 상호작용하는 트랜잭션을 읽고 구성할 수 있습니다. 표준 압축 인덱서는 Photon이며 Helius가 제공합니다. 이 유형의 노드는 최소한의 설정만으로 로컬에서 실행할 수 있으며 기존 RPC를 가리키도록 설정해야 합니다. 

Prover 노드는 상태 포함 여부에 대한 유효성 증명을 생성하는 데 사용됩니다. ZK Compression RPC API 사양의 getValidityProof 엔드포인트를 사용해 증명을 가져올 수 있습니다. Prover 노드는 독립형 노드로 운영하거나 다른 RPC와 함께 번들로 구성할 수 있습니다. 표준 Photon RPC 구현에는 Prover 노드가 포함됩니다.

Light Forester 노드는 공유 상태 트리와 프로그램 소유 상태 트리의 생성, 롤오버, 업데이트를 관리합니다. 자체 프로그램 소유 상태 트리를 Light Forester 노드 네트워크로 관리하려는 개발자를 위한 기능입니다.

신뢰 가정

누구나 앞서 언급한 노드 중 하나를 실행하고, 증명 생성과 트랜잭션 제출에 필요한 원시 데이터를 저장할 수 있습니다. 이는 압축 상태의 활성성에 영향을 주는 신뢰 가정을 도입합니다. 데이터가 손실되거나 지연되면 직접 데이터를 저장하지 않은 경우 트랜잭션을 제출할 수 없습니다. 데이터를 제공하는 정직한 노드 하나만 있으면 되고 증명은 자체 검증이 가능하므로, 문제의 핵심은 안전성이 아니라 활성성과 잠재적 검열입니다.

또한 압축 계정을 검증하는 프로그램을 현재 업그레이드할 수 있다는 점도 또 다른 신뢰 가정을 도입합니다. 문제를 해결하거나 새로운 요구 사항에 맞게 프로그램을 수정하기 위해서입니다. 다만 안정적이고 안전한 상태에 도달하면 향후 변경 불가능하게 만들거나 동결할 수 있습니다.

또 다른 활성성 신뢰 가정은 Forester 노드 사용입니다. 이 노드는 상태 루트의 진행을 유지하고, 무효화 큐를 비우며 상태 루트를 비동기적으로 진행해 큐를 관리합니다. 이때 계정 해시를 0으로 바꿔 무효화합니다. 진행과 무효화를 분리하면 트랜잭션을 Solana의 크기 제한 안에 유지하면서 압축 상태 전환에 즉각적인 최종성을 제공할 수 있습니다. 무효화 큐의 크기는 일정하므로 Forester 노드는 프로토콜 활성성에 필수입니다. 큐가 가득 차면 관련 상태 트리의 활성성에 장애가 발생합니다. 다행히 Forester 노드가 큐를 비워 이를 방지합니다. 그러나 프로토콜의 무결성과 활성성을 유지하려면 누군가 계속 이 노드를 실행해야 합니다. 이 노드가 없다면 ZK Compression은 약 2,000개의 계정 또는 주소만 지원할 수 있습니다.

한계 

무언가를 숨길 필요가 없더라도 영지식 증명은 여러 연산 단계가 필요한 문제를, 연산이 올바르게 수행되었는지 알아보기 위해 증명 하나만 검증하면 되는 문제로 바꿉니다. 이러한 연산은 특정 리프가 주어진 트리에 속하는지 확인하는 데 국한되지 않습니다. 어떤 임의의 연산도 가능합니다. 하지만 여기에는 비용이 따릅니다.

ZK Compression을 사용하기 전에 다음 사항을 고려하세요.

• 더 큰 트랜잭션 크기 — ZK Compression에는 유효성 증명을 위한 128바이트와 온체인에서 읽거나 쓸 데이터 전송 공간이 필요합니다
• 더 높은 컴퓨트 유닛 사용량 — ZK Compression은 유효성 증명 검증에 ~100k CU, 시스템 사용에 ~100k CU, 압축 계정 읽기 또는 쓰기마다 ~6k CU가 필요하므로 컴퓨트 유닛(CU) 사용량이 크게 늘어납니다
• 트랜잭션별 상태 비용 — 쓰기 작업마다 이전 압축 계정 상태를 무효화하고 새 압축 상태를 상태 트리에 추가해야 하므로 소액의 네트워크 비용이 발생합니다. 따라서 상태 업데이트가 매우 많다면 압축 계정 하나의 전체 수명 비용이 비압축 계정보다 커질 수 있습니다

다음과 같은 경우에는 일반 계정을 사용하는 편이 나을 수 있습니다.

• 계정이 자주 업데이트되는 경우
• 계정의 전체 수명 동안 쓰기 횟수가 많은 경우(예: >1000x)
• 계정이 온체인 트랜잭션에서 접근해야 하는 대량의 데이터를 저장하는 경우

이점

ZK Compression은 Solana의 상태 증가 문제를 직접 해결하고 다양한 애플리케이션과 사용 사례를 지원하는 확장 가능하고 안전하며 효율적이고 유연한 프리미티브입니다. 가장 두드러지는 장점은 단연 상태 비용 절감입니다. ZK Compression은 저렴한 원장 공간에 상태를 안전하게 저장하고 상태 핑거프린팅으로 온체인 저장 공간을 최소화해 앱이 수백만 사용자 규모로 쉽게 확장되도록 합니다. SOL 가격을 $130 USD로 가정했을 때 토큰 계정 10,000개를 민팅하는 비용은 약 $2,600입니다. ZK Compression은 이를 50센트 미만으로 낮춥니다.

ZK Compression은 현재 Solana 사양과도 잘 맞습니다. 예를 들어 압축 계정의 구조는 일반 Solana 계정과 거의 동일합니다. 병렬 처리와 같은 Solana 고유의 혁신도 지원합니다. 동일한 상태 트리, 즉 커밋먼트 아래에서 서로 다른 압축 계정에 접근하는 두 트랜잭션은 병렬로 실행할 수 있습니다. 또한 ZK Compression은 동기식 원자적 결합 가능성을 강화합니다. 예를 들어 n개의 압축 계정과 m개의 일반 계정을 나열하는 트랜잭션은 완전히 유효한 구성입니다. 압축 계정을 참조하는 명령은 일반 계정을 참조하는 다른 명령이나 프로그램을 호출할 수 있습니다. 계정이 서로 다른 상태 트리에서 압축된 경우에도 마찬가지입니다. 명령 하나가 실패하면 전체 트랜잭션이 롤백되며, 한 명령의 변경 사항은 다음 명령에서 확인할 수 있습니다. 이는 롤업끼리 잠금을 설정하지 않으면 동기식 또는 원자적으로 서로 호출할 수 없는 ZK 롤업과 다릅니다. 따라서 ZK Compression과 롤업을 비교해 볼 필요가 있습니다.

ZK Compression은 롤업이 아닙니다

ZK Compression은 롤업이 아닙니다. 두 기술은 같은 기술에 의존하지만 구현 방식이 다릅니다. 롤업에는 두 가지 유형이 있습니다.

• 옵티미스틱 롤업 — 일정 기간 동안 모든 트랜잭션이 유효하다고 가정하며, 이 기간 내에 사기 증명을 사용해 잘못된 트랜잭션을 입증합니다
• 영지식 롤업 — 유효성 증명을 사용해 트랜잭션의 유효 여부를 즉시 증명합니다

영지식 롤업의 전체 상태는 기반 레이어, 즉 Ethereum에서 단일 루트로 표현됩니다. 이 때문에 ZK Compression이 사실상 롤업이라는 주장이 여러 차례 제기되었습니다. 하지만 몇 가지 중요한 차이가 있습니다.

ZK 롤업에서 트랜잭션 500개를 처리하는 상황을 생각해 보겠습니다. 이 경우 전체 롤업을 단일 회로로 취급합니다. 트랜잭션 500개를 함께 검증해 상태 루트가 A에서 B로 변경되었음을 확인하는 단일 증명을 생성합니다. 이 증명이 검증되면 L1과 L2 사이의 상호작용을 관리하는 스마트 계약이 상태 루트를 업데이트합니다. 반면 ZK Compression에서는 500개 트랜잭션이 각각 계정 데이터의 정확성을 검증하는 자체 증명을 생성합니다. 이러한 트랜잭션은 SVM 자체에서 실행되며, 각 증명이 검증되면 계정을 “일반” 계정처럼 취급합니다.

ZK Compression을 롤업으로 분류한다면 Solana에 저장된 모든 Merkle 루트를 유효성 기반 롤업으로 볼 수 있다는 뜻입니다. 현재 Solana에 있는 모든 압축 cNFT 루트를 살펴보면 민팅이 0인 Merkle 트리를 포함하는지에 따라 약 4,000~5,000개의 유효성 기반 롤업이 존재합니다.

따라서 ZK Compression은 Solana 아키텍처에 맞게 설계된 고유한 솔루션임이 분명합니다. ZK 롤업과는 다른 새로운 프리미티브로, 롤업의 복잡성과 분리 없이 확장성과 효율성을 높입니다.

Solana ZK의 미래와 상호운용성

Solana ZK의 현황

Helius에서 처음 맡은 글쓰기 업무 중 하나는 Solana v1.16 업데이트를 다루는 것이었습니다. 영지식 증명에 대한 런타임 지원이 개선된다는 소식에 매우 기대했고 글에서도 이를 다뤘습니다. 하지만 이러한 개선은 연기되었습니다. 이후 다시 연기되었는데도 v1.17 업데이트 글에서 더 자세히 다루는 실수를 했습니다. v1.18 업데이트 글에서는 아예 다루지 않았습니다. 당연히 실망스러웠고 다른 사람들도 답답함을 표했습니다. 

이러한 분위기에도 Solana에는 작지만 성장하기 시작한 ZK 개발자 커뮤니티가 있습니다. Light Protocol은 ZK Compression에 집중하기 전까지 처음에는 PSP(Private Solana Programs) 형태의 비공개 프로그램 실행에 주력했습니다. Dark protocol은 Solana 기반의 퓨타키 개인정보 보호 프로토콜이기도 합니다. 중앙 팀 없이 제안을 통해 기여가 이루어집니다. 이전에 Elusiv로 알려졌던 Arcium은 다자간 연산 실행 환경(MXE)을 사용해 자체적인 병렬 기밀 컴퓨팅 네트워크를 구동합니다. Bonsol은 개발자가 어떤 risc0 이미지든 실행하고 Solana에서 검증할 수 있게 하는 영지식 "코프로세서"입니다. 즉, 검증 가능한 오프체인 연산을 제공합니다. 튜토리얼과 영지식 증명 관련 링크 모음도 공유되었습니다.

특히 ZK Token Proof Program은 curve25519 위의 Pedersen 커밋먼트 및 Twisted ElGamal 암호화와 함께 작동하도록 설계된 여러 영지식 증명을 검증합니다. 이를 통해 영지식 증명으로 SPL 토큰 잔액과 트랜잭션 금액을 암호화하는 Confidential Transfers를 지원합니다. 목표는 익명성이 아니라 기밀성입니다. 동형 암호화를 사용하면 암호화된 데이터를 복호화하지 않고도 연산할 수 있습니다. Confidential Transfers는 이를 위해 암호문에 대한 숨겨진 수학 연산에 Twisted ElGamal 암호화를 사용하고, 민감한 정보를 공개하지 않고 전송을 검증하는 데 Sigma Protocols를 사용합니다. 복호화 키를 가진 계정 소유자만 암호화된 잔액을 볼 수 있습니다. 하지만 Global Auditor System은 별도의 복호화 키를 통해 규정 준수와 감사를 위한 선택적 읽기 접근을 허용합니다.

Solana의 프로그래밍 가능한 비공개 잔액은 이제 Solana Privacy Rings로 제공됩니다. 

ZK Token Proof Program은 SIMD-0153: ZK ElGamal Proof Program이 통과됨에 따라 현재 차단된 기능입니다. 이 새로운 SIMD는 SPL Token 프로그램 전용으로 설계된 기존 ZK Token Proof program을 폐기하고, 특정 애플리케이션에 종속되지 않는 더 범용적인 영지식 증명 프로그램으로 대체하는 것을 목표로 합니다. 이 SIMD는 Anza와 Firedancer 팀의 지원을 받아 병합되었습니다.

하지만 상황이 바뀌기 시작했습니다. 이러한 개선 사항이 마침내 Devnet과 Mainnet-Beta에 도입되면서 Solana는 ZK 강자로 부상하고 있습니다. 현재 Solana에는 세 가지 ZK syscall이 가동 중입니다.

Poseidon Syscall

Poseidon은 영지식 증명용으로 특별히 설계된 해시 함수군으로, Zcash, Mina, Light Protocol 같은 프로젝트에서 사용됩니다. Poseidon은 SHA-256 같은 전통적인 범용 해시 함수보다 영지식 증명에서 연산 효율이 높습니다. 

Poseidon 해시 함수가 영지식에 적합한 이유는 다음과 같습니다.

• 산술 연산을 효율적으로 수행합니다
• 산술 친화적 설계, 최적화된 S-box, 적은 라운드 수 덕분에 증명 생성 단계가 적습니다. 즉, 회로 복잡도가 낮습니다
• 길이에 상관없이 비트 시퀀스를 처리하는 알고리즘을 사용하므로 활용도가 매우 높습니다

이전에는 한 트랜잭션에서 Poseidon 해시를 계산하는 비용이 지나치게 높았습니다. 하지만 에포크 644와 Poseidon syscall의 활성화로 상황이 달라졌습니다. 이 시스템 호출은 2D 바이트 슬라이스를 입력받아 해당 Poseidon 해시를 출력으로 계산합니다. ZK Compression이 상태 트리에 Poseidon 해싱을 사용한다는 점에서 기대되는 변화입니다.

Poseidon syscall은 다음 매개변수와 함께 BN254 곡선을 사용해 해시를 계산합니다.

• S-box — x5 치환 상자
• 입력 — 1 ≤ n ≤ 12
• 너비 — 2 ≤ t ≤ 13
• 라운드 — 전체 라운드 8회 및 t에 따른 부분 라운드: [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]

출력은 지정된 엔디언에 따라 32바이트로 인코딩된 Posiedon 해시 결과입니다.

여기서 syscall에 사용되는 구체적인 변형은 x5 S-box와 BN254 곡선에 맞춘 매개변수를 사용하는 Poseidon입니다. light-poseidon 크레이트를 사용하면 이러한 해시를 계산할 수 있습니다. 크레이트 자체는 감사를 받았으며 Circom과 호환됩니다.

alt_bn128 Syscall

alt_bn128은 효율적인 zk-SNARK 증명과 연산을 지원하는 페어링 친화적 곡선인 Barreto-Naehrig(BN-128) 타원 곡선의 구현을 뜻합니다. 이 곡선은 Groth16을 비롯한 다양한 영지식 증명 시스템에 필수적이며, ZK Compression도 상태 전환 검증에 이를 사용합니다. 이 syscall은 증명당 필요한 공간을 크게 줄여 효율적인 온체인 증명을 위한 핵심적인 공간 및 시간 최적화를 제공합니다. 

sol_alt_bn128_group_op syscall은 G1의 점 덧셈(G1은 주어진 타원 곡선 위 점들의 그룹을 의미합니다), G1의 스칼라 곱셈, 페어링을 포함한 alt_bn128 곡선 연산을 계산합니다.

• 입력 — 빅 엔디언 형식으로 직렬화된 점과 스칼라
• 연산 — G1의 점 덧셈, G1의 스칼라 곱셈, 페어링(G1의 점 1개와 G2의 점 1개)
• 출력 — G1의 점 또는 256비트 정수로 직렬화된 페어링 결과

sol_alt_bn128_compression syscall은 alt_bn128 곡선 위 G1 또는 G2 그룹의 점을 압축하거나 압축 해제하고, 표준 빅 엔디언 형식으로 점을 반환합니다.

이 syscall은 현재 testnet에서 가동 중입니다. 로드된 프로그램의 재컴파일 단계에 있는 버그가 해결되면 Devnet에서도 사용할 수 있을 것으로 보입니다. 이는 SIMD-0075: Secp256r1 Precompile에 따른 것입니다. 이 제안은 alt_bn128 syscall과 Poseidon syscall의 오류 코드를 간소화해 일관성을 보장하고, 검증인마다 다른 오류 코드를 반환해 합의에 실패할 위험을 줄이는 것을 목표로 합니다.

alt_bn128 syscall은 KZG 커밋먼트처럼 증명 크기가 일정한 일반 벡터 커밋먼트에 사용할 수 있습니다. 따라서 페어링 친화적인 모든 곡선에서 작동하며 ZK 증명자 회로가 필요하지 않습니다. 

상호운용성

Solana는 ZK 체인입니다. 수수료가 낮고 타원 곡선 연산을 런타임에서 지원하는 고성능 Layer 1 블록체인입니다. 영지식 증명 관련 syscall을 구현하고 지원하면 혁신을 촉진해 ZK Compression 같은 새로운 프리미티브와 애플리케이션을 Solana 위에 구축할 수 있습니다.

alt_bn128 syscall 도입은 Solana와 EIP-196, EIP-197, EIP-198에 명시된 타원 곡선 연산용 사전 컴파일 계약에 의존하는 Solidity 기반 계약 사이의 결합 가능성 격차를 좁힙니다. 이러한 연산은 Ethereum의 가스 한도 내에서 zk-SNARK 증명을 검증할 수 있게 합니다. 따라서 이러한 타원 곡선 연산에 의존하는 Solidity 계약은 이제 Solana로 더 쉽게 이전하거나 Solana와 상호운용할 수 있습니다.

SIMD-0075는 상호운용성 솔루션에 매우 중요합니다. 이 SIMD가 완전히 구현되면 Celestia에서 Solana로 DA를 스트리밍하는 차기 blobsream-solana 같은 프로젝트가 Merkle 커밋먼트 저장을 위해 오프체인 증명 생성과 온체인 검증을 사용할 수 있습니다. 이 syscall이 없으면 Solana에서 Groth16 증명을 검증할 수 없습니다. 또한 이 syscall은 신뢰를 최소화한 브리징과 상호운용성을 강화해 다른 블록체인이 Solana와 원활하고 안전하게 상호작용할 수 있게 합니다.  

Toly의 말이 맞습니다. Solana 런타임이 이렇게 개선되면서 Solana는 Ethereum L2가 되었습니다. 곧 Solana의 모든 블록을 Ethereum의 데이터 검증 브리지 계약에 제출하는 데 아무런 장벽이 없어질 것입니다. 반대로 Ethereum의 모든 블록을 Solana의 데이터 검증 브리지 프로그램에 제출하는 것도 가능해집니다. 낡은 브리지 대신 영지식 증명으로 가속되는 양방향 상호운용성은 Solana의 밝고 성장하는 미래입니다.

결론

영지식 증명은 의심할 여지 없이 암호학자들이 개발한 가장 강력한 프리미티브 중 하나이며, 어쩌면 가장 강력한 프리미티브일 수도 있습니다. 첫 번째 글에서 이 개념의 기반이 되는 이론과 수학, 암호학을 제1원리부터 살펴보면 이는 자명해집니다. 온체인 게임에서 진정한 전장의 안개를 구현하는 것부터 L2의 트랜잭션 집합이 특정 상태 전환을 일으켰음을 증명하는 것까지 잠재적 활용 분야는 무궁무진합니다.

이 2부작 시리즈는 동형 암호화의 복잡한 원리, Circom을 사용한 회로 코딩, 다양한 커밋먼트 체계 분석까지 다루며 50페이지 이상으로 쉽게 늘어날 수 있었습니다. 하지만 이 글의 목표는 독자가 영지식 증명의 기초를 배우고 새롭게 얻은 지식을 Solana에 적용할 수 있도록 돕는 것입니다. 

Solana는 ZK 강자로 부상하고 있습니다. ZK Compression 출시부터 가까운 미래에 가동될 다양한 syscall까지, 그 중요성은 아무리 강조해도 지나치지 않습니다. ZK Compression 같은 프리미티브는 일반 개발자가 영지식 증명의 모든 복잡성을 신경 쓰지 않도록 추상화합니다. 하지만 Solana에서 관련 논의와 개발을 발전시키려면 기본 원리를 이해하는 것이 매우 중요합니다. 

여기까지 읽어주셔서 감사합니다, anon! 아래에 이메일 주소를 입력하면 Solana의 새로운 소식을 빠짐없이 받아볼 수 있습니다. 더 깊이 알아볼 준비가 되셨나요? 지금 Helius 블로그의 최신 글을 살펴보고 Solana 여정을 이어가세요.

추가 자료

• Vitalik의 zk-SNARK가 가능한 원리에 관한 대략적인 소개
• POSEIDON: 영지식 증명 시스템을 위한 새로운 해시 함수(개정판)
• SIMD-0075: Secp256r1 사전 컴파일
• zk-SNARK와 zk-STARK의 차이 이해하기
• ZK Compression 문서