데이터를 들여다보는 대신, 증명을 검증한다: Midnight의 ZK 신뢰 모델

영지식 증명, 흔히 말하는 ZK proof는 보통 “프라이버시 분야 기술 중 하나”로 여겨집니다.

틀린 말은 아닙니다. ZK는 분명 데이터를 숨기는 데 강력한 도구입니다.

하지만 Midnight을 정확히 이해하기 위해서는 한 걸음 더 들어가야 합니다.

ZK의 진짜 힘은 단순히 데이터를 감추는 데 있지 않습니다. 어떤 사실이 참이라는 것을, 그 사실을 뒷받침하는 원본 데이터를 공개하지 않고도 증명할 수 있다는 점에 있습니다.

이 차이는 스마트 컨트랙트를 설계하는 방식까지 바꿉니다.

기존의 공개형 블록체인에서는 네트워크가 데이터를 직접 보고, 로직을 실행하고, 결과를 확인합니다. 반면 Midnight의 모델에서는 모든 데이터를 공개하지 않아도 됩니다. 필요한 것은 데이터 자체가 아니라, 그 데이터가 정해진 규칙을 만족했다는 증명입니다.

이 글에서는 Kachina가 이런 문제를 어떻게 구조화하는지, 그리고 Midnight에서 public transcript, ZK proof, verifier key가 어떤 역할을 하는지 살펴봅니다.

이 글은 ZKP를 처음부터 설명하지 않습니다. 본문에서 주로 다룰 내용은 ZK가 Midnight의 스마트컨트랙트 신뢰 모델을 어떻게 설계하는가입니다.

이 글은 이런 분들을 위한 가이드입니다

이 글은 영지식 증명의 기본 개념을 어느 정도 알고 있는 개발자를 대상으로 합니다.

예를 들어, ZK를 통해 증명자(prover)가 검증자(verifier)에게 어떤 명제가 참이라는 것을 납득시킬 수 있지만, 그 명제 뒤에 있는 비밀 정보는 공개하지 않는다는 정도의 직관적인 개념을 알고 있다면 충분합니다.

또한 이 글은 이더리움 같은 공개형 스마트컨트랙트 개념에 익숙한 개발자가 Midnight의 데이터 보호 모델을 이해하는 데 초점을 맞춥니다.

SDK 사용법, CLI 명령어, Compact 문법, 코드 구현은 다루지 않습니다. 대신 Midnight의 ZK 모델을 이해하는 데 오래 남는 설계 개념에 집중합니다.

ZK는 단순히 “숨기는 기술”이 아닙니다

ZK를 처음 접하면 보통 이렇게 이해합니다.

“데이터를 숨기면서 동시에 증명하는 기술.”

개념적으로는 위 설명으로 충분하지만, 실제 애플리케이션을 설계할 때는 ZK에 대한 이해가 조금 더 필요합니다.

ZK는 모든 정보를 무조건 숨기는 기술이라기보다, 무엇을 공개하고, 무엇을 숨기고, 무엇을 증명할지 결정하는 기술에 가깝습니다.

서비스가 사용자에게 성인 인증을 요구하는 간단한 예시로 이해해 보겠습니다.

ZK를 통한 증명 방식에서 사용자는 신분증 또는 여권의 모든 정보를 제공할 필요가 없습니다. 이름, 생년월일, 집 주소, 주민등록번호 같은 정보까지 모두 공개할 이유도 없습니다. 서비스가 확인해야 하는 것은 전체 신원이 아니라, 나이 기준을 충족한다는 사실입니다.

이것이 선택적 공개(selective disclosure)의 기본 아이디어입니다.

필요한 사실만 드러내고, 나머지는 감춥니다. 완전한 비밀 보장이라기보다, 상황에 맞춰 공개 범위를 조절하는 방식입니다.

Authlete, OpenID for Verifiable Credential Issuance

Midnight이 말하는 rational privacy도 같은 맥락으로 이해할 수 있습니다.

rational privacy는 모든 데이터를 철저히 숨기는 걸 요구하지 않습니다. 사용자가 보호해야 할 정보는 보호하면서도, 애플리케이션이 검증이나 규제 대응에 필요한 정보는 필요한 만큼 다룰 수 있게 하자는 접근 방식입니다.

그래서 ZK를 단순히 “암호화하여 감추는 기술”로 여긴다면 Midnight의 모델을 이해할 수 없습니다.

rational privacy 관점에서 더 적절한 질문은 다음과 같습니다.

이 플로우에서 온체인에 공개되어야 하는 데이터는 무엇인가? 로컬에 비공개로 남아도 되는 데이터는 무엇인가? 그리고 공개된 데이터와 비공개된 데이터를 연결하는 증명은 무엇인가?

이 질문이 Midnight의 ZK 모델을 이해하기 위한 시작점이 됩니다.

ZKP는 공개 범위를 설계할 수 있도록 돕습니다

영지식 증명은 하나의 명제(statement)를 중심으로 작동합니다. 증명자(prover)와 검증자(verifier)를 넣어 설명해 보겠습니다.

• 증명자는 어떤 명제가 참이라는 것을 증명하려고 합니다.
• 동시에 검증자는 그 명제가 참이라는 사실을 확인하려고 하지만, 그 명제를 성립시키는 비공개 정보까지 알 필요는 없습니다.

ZKP의 기본 속성은 보통 세 가지로 설명됩니다.

• 완전성(completeness)은 참인 명제라면 정직한 증명자가 검증자를 설득할 수 있다는 뜻입니다.
• 건전성(soundness)은 거짓인 명제를 부정직한 증명자가 참인 것처럼 속이기 어려워야 한다는 뜻입니다.
• 영지식성(zero-knowledge)은 검증자가 명제의 참 여부 외에는 추가 정보를 알 수 없어야 한다는 뜻입니다.

이 세 가지 속성은 단순히 “데이터를 숨긴다”는 개념보다 훨씬 더 많은 것을 시사합니다.

개발자 입장에서는 하나의 플로우를 두 부분으로 나눌 수 있게 됩니다.

• 시스템이 반드시 검증해야 하는 부분
• 시스템이 굳이 볼 필요가 없는 부분

기존의 퍼블릭 블록체인에서는 데이터가 공개되어 있으므로, 네트워크가 직접 확인합니다. 입력값과 상태가 보이고, 노드들은 그 위에서 로직을 다시 실행합니다.

ZK 기반 모델에서는 접근이 달라집니다.

네트워크가 모든 데이터를 직접 볼 필요가 없습니다. 대신 규칙이 지켜졌다는 proof를 검증합니다. 숨겨진 데이터가 조건을 만족했다는 사실만 증명되면, 원본 데이터는 계속 비공개로 남을 수 있습니다.

Midnight의 proving system은 Kachina 프레임워크를 기반으로 한 zk-SNARK를 사용합니다.

Kachina: public state와 private state를 구분한다

Kachina는 이 아이디어를 스마트컨트랙트 모델로 구체화합니다.

Midnight 문서에서는 Kachina를 데이터 보호형 스마트컨트랙트 모델로 서술합니다. 핵심은 state를 두 종류로 나누는 것입니다.

• 블록체인에 올라가는 public state
• 각 사용자 기기에 로컬로 남는 private state

이 구분이 다루는 지점은 단순히 “데이터를 어디에 저장하느냐”에 대한 선택지가 아닙니다.

이 구분이 다루는 지점은, ‘스마트 컨트랙트가 어떤 데이터를 직접 다루고, 어떤 데이터를 사용자의 로컬 환경에 남겨둘지’에 대한 설계 방식입니다.

Kachina에서는 ZK proof를 통해 private state의 변화와 public state의 변화를연결합니다. 사용자의 로컬 환경에서 어떠한 private state 변경이 일어났고, 그 결과 public state가 이렇게 변화한다는 것을 proof가 증명하는 구조입니다.

즉, Midnight에서 블록체인 노드는 모든 private input을 볼 필요가 없습니다.

하지만 public state가 마음대로 바뀌는 것도 아닙니다.

public update는 반드시 private side에서 일어난 유효한 변화를 근거로 정당성을 확보해야 합니다.

Midnight Docs, How Kachina smart contracts work

이 점이 Kachina가 단순히 기존 스마트 컨트랙트에 프라이버시 기능을 덧씌운 모델이 아닌 이유입니다.

또 하나 중요한 개념이 transcript입니다.

Kachina에서 transcript는 어떤 플로우가 public state에 어떤 영향을 미쳤는지 기록하는 공개 기록입니다. 다만 그 결과를 만들어낸 private input까지 그대로 공개하지는 않습니다.

이 구조 덕분에 Midnight은 로컬에서 처리된 비공개 연산과 온체인에 남는 공개 상태 변화를 분리해서 다룰 수 있습니다.

Midnight 트랜잭션 이해하기: transcript와 proof

일반적인 퍼블릭 스마트컨트랙트 모델을 먼저 떠올려 보겠습니다.

컨트랙트 코드와 상태가 온체인에 있고, 사용자가 트랜잭션을 보냅니다. 노드들은 공개된 입력값과 상태를 바탕으로 컨트랙트를 실행합니다. 실행이 성공하면 새로운 상태가 원장에 기록됩니다.

이 모델은 직관적입니다. 트랜잭션 로그와 해시, 주소를 통해 누구나 데이터를 확인하고, 누구나 실행 결과를 확인할 수 있습니다.

문제는 모든 것이 공개된다는 점입니다.

프라이버시가 필요한 애플리케이션에서는 이 특성이 설계 상의 한계가 됩니다. 사용자 데이터, 비즈니스 로직 등의 민감한 정보가 필요 이상으로 공개될 수 있기 때문입니다.

Midnight의 구조는 다릅니다.

컨트랙트 상호작용은 크게 로컬 연산, Ledger와의 상호작용, 그리고 둘을 연결하는 로직으로 나뉩니다. private data는 로컬에서 다룰 수 있고, public state는 원장에 남습니다. 이 둘을 연결하는 로직은 ZK proof로 표현됩니다.

그래서 Midnight의 트랜잭션을 이해할 때는 다음 두 가지를 기억하면 됩니다.

• public transcript
• 그 transcript가 유효하다는 ZK proof

Midnight 트랜잭션은 단순히 “함수를 호출하고 노드가 전부 다시 실행하는” 방식이 아닙니다.

트랜잭션은 public transcript를 포함하고, 이 transcript가 해당 컨트랙트 로직에 비추어 올바르다는 proof를 함께 제공합니다.

Midnight Dev Diaries, Learning Web3 from the ground up — what are zero-knowledge proofs?

여기서 verifier key가 등장합니다.

Midnight은 온체인에 모든 circuit 프로그램 코드를 일반적인 공개 스마트 컨트랙트처럼 그대로 올리는 대신, 해당 circuit에 대한 proof를 검증하는 데 필요한 암호학적 키를 사용합니다. 이 키가 바로 verifier key입니다.

신뢰의 초점은 데이터 검증에서 증명 검증으로 이동합니다

이와 같은 Midnight의 모델은 블록체인에서 신뢰가 보장되는 방식을 바꿉니다.

공개형 실행 모델에서는 신뢰가 가시성에서 나옵니다. 모두가 데이터를 볼 수 있고, 모두가 같은 로직을 실행할 수 있으며, 그 결과를 직접 확인할 수 있다는 점입니다.

Midnight의 ZK 모델에서는 모든 데이터를 보여주지 않습니다.

대신 숨겨진 데이터가 정해진 규칙을 만족했다는 proof를 검증합니다. 신뢰의 근거가 “데이터를 봤다”에서 “증명이 유효하다”라는 지점으로 이동하는 것입니다.

1. 사용자는 private state를 자신의 로컬 환경에 유지한 채로 컨트랙트와 상호작용할 수 있게 됩니다. 모든 상태를 네트워크에 공개하지 않아도 됩니다.

2. 그렇다고 해서 public state가 임의로 바뀌는 것은 아닙니다. privacy가 보장하는 범위는 무제한이 아닙니다. public state 변화는 proof로 정당화되어야 합니다.

3. transcript는 공개된 부분을 체계적으로 기록합니다. 어떤 public state 작업이 있었는지, 어떤 쿼리가 관련되었는지 구조화할 수 있습니다. 이는 독립적인 작업을 안전하게 재정렬하거나 병렬로 처리하는 데 핵심이 됩니다.

4. Rational privacy가 필요한 사례에 적합합니다. 해당 모델을 적용한다면, 필요한 정보는 필요한 시점에 필요한 범위로만 공개하고, 나머지는 보호합니다.

현실적인 애플리케이션에서는 이 균형이 중요합니다.

예를 들어, 규제의 영향을 받는 서비스라면 어떤 조건이 충족되었다는 증명이 필요할 수 있습니다. 경우에 따라 감사 기관이나 당사자에게 특정 정보를 공개해야 할 수도 있습니다. 하지만 그렇다고 모든 사용자 데이터를 공개 네트워크 전체에 노출해야 하는 것은 아닙니다.

Midnight의 접근은 프라이버시를 “아무것도 보여주지 않기”로 보지 않습니다.

대신 무엇을 공개하고, 무엇을 숨기며, 무엇을 증명할지 구분합니다.

ZK가 모든 문제를 해결해 주는 것은 아닙니다

ZK를 사용한다고 해서 모든 신뢰 문제가 자동으로 해결되는 것은 아닙니다.

ZK proof는 private witness를 숨긴 채 어떤 명제가 참이라는 점을 증명할 수 있습니다. 하지만 시스템 상에는 여전히 공개되는 부분이 존재하게 됩니다.

public transcript는 공개되고, public state도 공개됩니다. 애플리케이션에 따라 메타데이터 역시 중요한 정보가 될 수 있습니다.

그래서 ZK를 “프라이버시를 무조건 보장하게 해주는 장치”처럼 생각하면 위험합니다.

ZK 기반 애플리케이션을 설계할 때는 계속해서 질문해야 합니다.

• 어떤 명제를 증명할 것인가?
• public transcript에는 무엇이 남는가?
• 어떤 데이터가 로컬에 머무는가?
• 공개 여부를 누가 통제하는가?
• proving과 verification 과정에는 어떤 가정이 깔려 있는가?

이 질문들은 Midnight의 모델을 약하게 만드는 요소가 아닙니다. 오히려 신뢰의 경계를 더 명확하게 만듭니다.

“증명만 공개하면 되기 때문에, 신뢰가 필요없다”라고 주장하지 않습니다. 대신 신뢰해야 하는 대상을 상대방에서 증명 자체로 재정의합니다.

모든 데이터를 공개해서 확인하는 대신, 공개해야 할 것과 숨겨도 되는 것을 나누고, 그 둘 사이를 proof로 연결합니다.

ZK의 가치는 여기에 있습니다.

개발자가 프라이버시를 고려한 규칙을 더 명확하게 표현하고, 네트워크가 그 규칙을 검증할 수 있게 해줍니다.

핵심 정리

이번 글에서 가져갈 핵심은 다음과 같습니다.

• ZK는 단순히 데이터를 숨기는 기술이 아닙니다. 필요한 사실을 증명하면서 공개 범위를 줄이는 기술입니다.
• 선택적 공개와 rational privacy는 필요한 정보만 드러내는 방향을 가리킵니다.
• Kachina는 온체인의 public state와 사용자 로컬의 private state를 분리합니다.
• ZK proof는 private state 변화와 public state 변화를 연결합니다.
• Midnight의 스마트 컨트랙트 상호작용은 public transcript와 ZK proof를 중심으로 구성됩니다.
• verifier key는 proof가 올바른 규칙에 대해 검증되는지 판단하는 핵심 요소입니다.
• 신뢰 모델은 데이터를 직접 검사하는 방식에서 proof를 검증하는 방식으로 이동합니다.
• ZK가 모든 신뢰 문제를 해결하는 것은 아닙니다. 대신 무엇을 공개하고 무엇을 검증할지의 경계를 더 분명하게 만듭니다.

Midnight의 스마트 컨트랙트 모델이 public state, private state, transcript, proof를 중심으로 구성된다면, 개발자에게는 이 경계를 명확하게 표현할 수 있는 언어가 필요합니다.

다음 글에서는 Compact를 이 관점에서 살펴봅니다. Compact는 단순한 스마트 컨트랙트 언어가 아니라, Midnight의 public/private split과 proof 중심 실행 모델을 표현하기 위한 언어입니다.

참고 자료

더 자세한 내용은 Midnight 공식 문서와 관련 자료를 참고하세요.

• Kachina: public state와 private state를 분리하고, 이를 zero-knowledge proof로 연결하는 Kachina 모델을 설명합니다.
• Learning Web3 from the ground up — what are zero-knowledge proofs?: ZKP의 기본 속성과 Midnight의 ZKP 접근 방식을 설명합니다.
• Smart contracts on Midnight: transcript, zk-SNARKs, public/private transcript, verifier key의 역할을 설명합니다.
• Understanding Selective Disclosure: 선택적 공개와 rational privacy의 관계를 설명합니다.
• Kachina: Foundations of Private Smart Contracts: Kachina 모델의 기반이 되는 학술 논문입니다.