Midnight의 두 가지 state 이해하기: public state와 private state

이전 글에서는 NIGHT와 DUST가 서로 다른 방식으로 상태를 갖는다는 점을 살펴봤습니다. NIGHT는 비차폐(unshielded) 원장 UTXO로 존재하고, DUST는 차폐(shielded)된 수수료 리소스로 사용됩니다.

이 차이는 NIGHT와 DUST에만 해당하는 특수한 설정이 아닙니다.

이는 Midnight이 상태(state)를 공개 영역과 비공개 영역으로 나누어 다루는 방식을 보여주는 사례입니다.

이번 글에서는 Midnight에서 public state와 private state가 각각 어떤 역할을 하며, 이 구분이 애플리케이션 설계에서 왜 중요한지 살펴봅니다.

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

이 글은 Midnight의 프라이버시 모델에 대한 기본 개념을 어느 정도 알고 있는 개발자를 대상으로 합니다.

이전 글에서 public state, private state, proof의 기본 구조를 살펴봤다면 이해하기 쉽습니다. NIGHT와 DUST의 관계를 다룬 글을 읽었다면 더 자연스럽게 따라올 수 있습니다.

이 글에서는 지금까지 다룬 ZK proof 및 NIGHT의 수수료 모델 등을 반복해서 설명하지 않습니다. 대신 Midnight에서 state가 어디에 위치하는지에 집중합니다.

Midnight for Developers: Shielded and Unshielded Tokens — Privacy by Choice

전체 모델부터 이해하기

많은 퍼블릭 블록체인에서는 기본 모델이 비교적 단순합니다.

State는 하나의 공개된 영역에 존재하고, 누구나 이를 확인할 수 있습니다.

컨트랙트 상태, 트랜잭션 입력값, 잔액, 주소 간 이동 내역은 대부분 공개됩니다. 네트워크는 이렇게 공개된 데이터를 바탕으로 실행 결과를 검증합니다.

Midnight의 모델은 이와 다릅니다.

State는 public과 private 두 영역에 존재하고, 개발자는 어떤 state가 어느 쪽에 있어야 하는지 설계해야 합니다.

이전 글에서 살펴본 NIGHT와 DUST는 이 구조를 보여주는 구체적인 예시입니다. NIGHT는 공개된 비차폐(unshielded) 원장 UTXO로 존재합니다. 반면 DUST는 shielded이지만, 전송 가능한 자산 보유 상태가 아니라 트랜잭션 수수료에 사용되는 비전송성 리소스입니다.

이 둘은 Midnight이 public state와 private state를 설계적으로 분리한다는 더 큰 모델을 이해하는 출발점이 됩니다.

Midnight에서 state는 크게 두 가지로 나눌 수 있습니다.

• Public state: 온체인에 저장되고 네트워크 참여자가 확인할 수 있는 데이터
• Private state: 로컬 저장소나 차폐된 보유 구조를 통해 비공개로 유지되는 데이터

중요한 변화는 단순히 private state가 존재한다는 점이 아닙니다. 개발자가 공개와 비공개의 경계를 설계 대상으로 다루게 된다는 점입니다.

이 경계는 자산, 컨트랙트, disclosure, 애플리케이션 설계 방식 전반에 영향을 미칩니다.

Public side

public side에는 온체인에 기록되고 네트워크 참여자가 확인할 수 있는 상태가 포함됩니다.

대표적으로는 다음과 같은 요소가 있습니다.

• NIGHT와 같은 비차폐 UTXO
• 컨트랙트 코드
• 공개 컨트랙트 상태
• 명시적으로 공개하기로 선택한 정보
• 검증을 위해 제출된 transaction proof

공개된다는 것은 단순히 데이터가 노출된다는 뜻이 아닙니다. 해당 상태가 네트워크의 공통 검증과 조율을 위해 보이도록 설계되었다는 의미에 가깝습니다.

예를 들어 NIGHT는 비차폐 원장 토큰으로 존재합니다. 따라서 NIGHT의 이동과 원장 상의 형태는 Midnight의 공개 영역에 속합니다. 이런 상태는 다른 참여자가 확인할 수 있어야 하며, 경우에 따라 외부 시스템과 연결되는 기준점이 되기도 합니다.

public state가 필요한 경우는 비교적 명확합니다.

• 감사 가능성이 필요한 경우
• 여러 참여자가 같은 기록을 공유해야 하는 경우
• 거래소, 브릿지, 외부 시스템이 확인 가능한 데이터를 요구하는 경우
• treasury asset이나 public registry처럼 투명성이 설계 요건에 포함되는 경우

이처럼 public side는 네트워크가 함께 검증하고 조율할 수 있는 공통 표면을 제공합니다. Midnight이 private state를 지원한다고 해서 모든 상태가 숨겨지는 것은 아니며, 공개되어야 하는 정보는 여전히 public side에 남습니다.

Private side

private side에는 네트워크 전체에 노출될 필요가 없는 상태가 포함됩니다.

Midnight에서 private state는 크게 두 가지 형태로 이해할 수 있습니다.

• Local encrypted state: 사용자가 로컬에서 보유하고, 네트워크에 공개하지 않는 비공개 데이터
• Shielded token holdings: 차폐된 토큰 메커니즘을 통해 다뤄지는 토큰 관련 상태

local encrypted state에는 개인정보, 비즈니스 데이터, credential, 애플리케이션별 secret 등이 포함될 수 있습니다. 애플리케이션은 로컬 연산 과정에서 이 데이터를 사용할 수 있지만, 네트워크가 원본 데이터를 직접 확인할 필요는 없습니다.

shielded token holdings는 자산 측면에서 이해할 수 있는 개념입니다. 이는 토큰 활동의 metadata를 비공개로 유지할 수 있게 하는 구조이며, 특히 자산이 Midnight의 shielded ledger-token mechanism인 Zswap을 사용하는 경우 이 모델을 이해하는 것이 중요합니다.

DUST는 이 시리즈에서 이미 다룬 예시지만, 정확히 구분해서 이해해야 합니다. DUST는 shielded이지만 전송 가능한 자산 보유 상태는 아닙니다. DUST는 비전송성 수수료 리소스입니다.

따라서 DUST는 Midnight이 가시성과 유틸리티를 분리하는 방식을 이해하는 데에는 유용하지만, private asset holding이나 confidential value transfer를 설명하는 더 직접적인 예시는 shielded ledger token입니다.

private state를 선택하는 이유는 다음과 같이 정리할 수 있습니다.

• sensitive user data를 보호해야 하는 경우
• business confidentiality가 필요한 경우
• private asset activity를 다뤄야 하는 경우
• controlled disclosure를 설계해야 하는 경우

공통점은 원본 데이터나 metadata를 public ledger에 그대로 노출하지 않고, 필요한 상호작용에서만 제한적으로 가시성을 부여한다는 점입니다.

private side는 검증을 없애는 구조가 아닙니다. 오히려 네트워크가 직접 확인해야 하는 정보와 proof를 통해 확인할 수 있는 정보를 나누는 구조입니다. 원본 데이터를 공개하지 않더라도, proof와 selective disclosure를 통해 규칙이 지켜졌다는 사실은 검증될 수 있습니다.

이 경계는 자산의 단위로도 나눌 수 있습니다

public과 private의 구분은 체인 전체에 일괄 적용되는 설정이 아닙니다. Midnight에서는 이 경계를 asset 수준에서도 다룰 수 있습니다.

이 지점에서 UTXO 모델이 중요해집니다. UTXO는 개별 coin을 나타내며, 상태가 coin 단위로 추적될 수 있다는 점은 가시성을 더 세밀하게 설계할 수 있다는 뜻이기도 합니다. 어떤 자산이 공개적으로 추적되어야 하는지, 어떤 자산이 차폐된 상태로 다뤄져야 하는지를 개별적으로 판단할 수 있습니다.

따라서 개발자는 완전히 공개된 체인과 완전히 비공개인 체인 중 하나를 선택하는 것이 아닙니다. 각 자산, 상호작용, 상태 요소가 어느 영역에 위치해야 하는지를 설계합니다.

ledger token 일반의 관점에서 보면, Midnight의 UTXO 기반 아키텍처는 가시성을 개별 coin 수준에서 다룰 수 있게 합니다. ledger-token UTXO는 token type과 해당 자산의 설계 방식에 따라 transparent side 또는 shielded side에 속할 수 있습니다.

다만 이것이 모든 특정 토큰을 public과 private 사이에서 임의로 전환할 수 있다는 뜻은 아닙니다. NIGHT는 unshielded ledger-token 예시입니다. NIGHT는 Midnight 시스템의 transparent side에 속합니다. 반면 shielded ledger token은 ledger-token 모델의 private side를 보여주는 예시입니다.

이 구분은 애플리케이션 아키텍처에서 중요합니다. visibility는 단순한 설정값이 아니라 설계 판단의 대상입니다.

• public traceability가 필요한 자산은 unshielded 상태로 둘 수 있습니다.
• metadata를 숨겨야 하는 자산은 shielded holdings를 사용할 수 있습니다.
• 특정 당사자가 일부 정보를 확인해야 하는 경우에는 selective disclosure를 사용할 수 있습니다.
• 관련 없는 정보는 계속 private하게 유지할 수 있습니다.

이 모델은 두 극단 사이에 있습니다. 모든 세부 정보가 온체인에 공개되는 모델도 아니고, 모든 활동이 모두에게 완전히 불투명해지는 모델도 아닙니다. Midnight은 애플리케이션이 필요로 하는 위치에 state boundary를 둘 수 있게 합니다.

따라서 Midnight에서 DApp을 설계할 때는 어떤 데이터를 저장할지뿐 아니라, 그 상태가 어느 영역에 속해야 하는지도 함께 고려해야 합니다. 이 지점에서 state model은 단순한 저장 구조가 아니라 애플리케이션 설계 기준이 됩니다.

Private하다는 것은 책임이 없다는 뜻이 아닙니다

private state는 검증에서 벗어난 상태를 의미하지 않습니다. Midnight의 privacy model은 필요한 정보만 특정 당사자에게 공개하고, 다른 상태는 계속 private하게 유지할 수 있는 selective disclosure를 전제로 합니다.

Compact에서는 privacy가 기본값이고, disclosure는 명시적인 예외로 다뤄져야 합니다. disclose() 키워드는 public visibility가 필요한 경우 선택된 private data를 의도적으로 공개할 수 있게 합니다.

ZK proof도 같은 방향에서 작동합니다. 사용자는 비공개 조건이 충족되었다는 사실을 증명할 수 있지만, 그 조건 뒤에 있는 모든 원본 데이터를 공개할 필요는 없습니다. 이 구조는 privacy와 verification을 서로 배타적인 것으로 보지 않습니다.

현실적인 애플리케이션에서는 controlled visibility가 필요합니다.

예를 들어 다음과 같은 경우가 있습니다.

• 사용자가 전체 신원을 공개하지 않고 자격 요건을 증명하는 경우
• 기업이 감사자에게 선택된 기록만 공유하는 경우
• 규제 대상 서비스가 권한 있는 당사자에게 필요한 정보만 제공하는 경우
• 지갑이 전체 활동 내역이 아니라 선택된 기록만 보여주는 경우

이것이 상태 관점에서 본 rational privacy입니다. 목표는 모든 것을 숨기는 것이 아니라, 무엇을 private하게 유지하고, 무엇을 public하게 만들며, 특정 당사자가 무엇을 볼 수 있게 할지 구분하는 것입니다.

이 구조 덕분에 privacy는 audit, compliance, application-specific rule과 함께 설계될 수 있습니다. selective disclosure는 private state 중 관련된 부분만 공개해야 하며, 관련 없는 데이터까지 public side로 이동시키지 않아야 합니다.

상태가 어디에 위치하는지 이해해야 누가 무엇을 볼 수 있어야 하는지도 판단할 수 있습니다. 그래서 public/private state model은 단순한 개념 구분이 아니라, disclosure scope를 정하는 기준이 됩니다.

두 영역은 분리되어 있지만, 고립되어 있지는 않습니다

public state와 private state는 분리되어 있지만 서로 완전히 고립된 것은 아닙니다.

비공개 영역에서 일어난 동작이 아무 검증 없이 공개 상태를 바꿀 수 있다면, public ledger는 숨겨진 영역에서 규칙이 지켜졌는지 확인하지 못한 채 claim을 받아들이게 됩니다.

Midnight에서는 이 두 영역이 proof를 통해 연결됩니다. 검증이 끝나면 public state는 온체인에서 업데이트되고, private state는 상호작용 방식에 따라 로컬 또는 shielded 상태로 유지됩니다. 이 부분은 이전 trust model 글에서 다룬 proof 중심 구조와 이어집니다.

아래 그림은 private data, proof, shielded ledger state가 어떻게 연결되는지 개념적으로 보여줍니다.

A conceptual view of how private data, proofs, and shielded ledger state interact.

proof는 private data를 public하게 만드는 장치가 아닙니다. proof는 상태 전이가 정해진 규칙을 따랐다는 사실을 보여주는 장치입니다.

이 연결이 Midnight의 모델을 hybrid하게 만듭니다. public side는 네트워크가 공유하는 ledger를 제공하고, private side는 민감한 상태를 그 공유된 view 밖에 둘 수 있게 합니다.

따라서 public state와 private state를 서로 관계없는 두 개의 데이터베이스처럼 보면 안 됩니다. 둘은 하나의 상호작용 모델을 이루는 두 면입니다.

이 모델이 의미하는 것

public state와 private state 모델은 이전 글들에서 다룬 개념을 하나로 묶어 줍니다.

trust model 글에서는 proof가 왜 중요한지 살펴봤고, Compact 글에서는 privacy-aware boundary를 스마트 컨트랙트 언어에서 어떻게 표현하는지 다뤘습니다. NIGHT와 DUST 글에서는 token과 resource 예시를 통해 Midnight의 수수료 모델을 설명했습니다.

이번 글은 그 뒤에 있는 구조를 state 관점에서 정리한 글입니다.

NIGHT와 DUST는 token과 resource 형태에서 이 분리를 보여줍니다. NIGHT는 비차폐 원장 UTXO로 public하게 존재합니다. DUST는 shielded된 비전송성 수수료 리소스입니다. 둘 다 같은 네트워크 모델에 참여하지만, 가시성과 사용 방식은 설계상 다릅니다.

같은 패턴은 token을 넘어 DApp 설계 전반에도 적용됩니다. Midnight에서 개발할 때는 어떤 상태가 다른 참여자의 검증이나 조율을 위해 공개되어야 하는지, 어떤 상태가 sensitive data나 metadata를 포함하기 때문에 비공개로 유지되어야 하는지 결정해야 합니다.

다음 글에서는 이 구조를 바탕으로 application design 관점으로 더 들어갈 수 있습니다. 상태가 어디에 존재하는지 이해하면, contract, asset, proof, disclosure가 어떻게 맞물리는지 더 명확하게 판단할 수 있습니다.

주의

토큰 상태와 사용 가능 여부는 launch stage와 network environment에 따라 달라질 수 있습니다. NIGHT availability를 확인할 때는 반드시 Midnight 공식 채널을 기준으로 삼아야 합니다. DUST는 전송 가능한 토큰이 아닙니다. tNIGHT, tDUST 같은 testnet resource는 실제 경제적 가치가 없습니다. DUST 또는 testnet token 판매를 주장하는 비공식 링크, 개인 제안, 판매 주장은 사기로 간주해야 합니다.

핵심 요약

• Midnight에서 state는 public과 private 두 영역으로 나뉘며, 각 state가 어디에 위치해야 하는지는 애플리케이션 설계의 일부입니다.
• public state는 온체인에서 공유되고 검증되는 상태이고, private state는 로컬 저장소나 shielded holdings를 통해 비공개로 유지되는 상태입니다.
• NIGHT는 unshielded ledger-token 예시이고, DUST는 shielded된 비전송성 수수료 리소스로, 둘은 Midnight의 state 분리 구조를 보여줍니다.
• private state는 검증이 없다는 뜻이 아니며, proof와 selective disclosure를 통해 필요한 검증과 공개 범위를 조절할 수 있습니다.

참고 자료

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

• **What is Midnight?**: Midnight의 public state와 private state 모델, 그리고 검증된 transaction이 두 side를 어떻게 업데이트하는지 설명합니다.
• **Ledgers**: Midnight의 UTXO 기반 구조, ledger token, coin-level shielded/unshielded 선택지를 설명합니다.
• **Midnight’s hybrid architecture**: shielded ledger token과 unshielded ledger token의 구분, 그리고 NIGHT와 DUST가 이 모델에서 맡는 역할을 설명합니다.
• **Zswap**: shielded token mechanism을 개념적으로 소개합니다.
• **Glossary**: DUST, NIGHT, shielded, unshielded, ledger, tNIGHT, tDUST 등 주요 용어를 정의합니다.