Compact을 시작하기 전 알아야 할 Midnight의 작동 방식

EVM 네트워크에서 개발해본 분이라면 익숙한 흐름이 있을 겁니다. 문법을 익히고, 스마트 컨트랙트를 작성하고, 온체인에 배포하고, 실행 비용은 가스로 지불하는 방식입니다.

하지만 Midnight은 단순히 문법만 다른 플랫폼이 아닙니다. Compact은 처음 보면 어느 정도 익숙해 보이지만, 실제로는 로컬 실행, ZK 증명, 그리고 명시적 공개(explicit disclosure)를 중심에 둔 다른 실행 모델 위에서 동작합니다.

이 글에서는 Midnight이 EVM과 어떻게 다른지, 왜 Compact을 단순히 “새로운 스마트 컨트랙트 언어”로만 보면 안 되는지, 그리고 환경 설정에 들어가기 전에 왜 이 차이를 먼저 이해해야 하는지 살펴봅니다.

익숙해 보이는 문법, 전혀 다른 실행 방식

Compact 예제를 처음 보면 크게 낯설지 않을 수 있습니다.

타입 선언이 있고, export가 보이며, 전체적인 문법도 저수준 암호학 언어라기보다는 TypeScript에 가까워 보입니다.

이 첫인상은 분명 진입 장벽을 낮춰줍니다. 다만 동시에 오해를 만들기도 합니다.

Compact은 일부 문법이 익숙할 뿐, 실행 방식까지 익숙한 것은 아닙니다. 겉으로는 코드를 읽을 수 있어 보여도, 실제로 그 코드가 어디에서 실행되는지, 어떤 값이 공개되는지, 네트워크가 정확히 무엇을 검증하는지는 놓치기 쉽습니다.

그래서 Compact을 “스마트 컨트랙트 언어가 하나 더 나왔구나” 정도로 받아들이면 곧 헷갈리게 됩니다. 문법은 읽히는데, 설계 방식은 기존 EVM 기반 개발과 다르기 때문입니다.

이 글은 바로 그 지점, 즉 문법은 익숙하지만 사고방식은 달라지는 간극을 먼저 짚기 위한 가이드입니다.

EVM과 Midnight의 가장 큰 차이: 실행 모델

EVM 네트워크의 실행 모델은 비교적 직관적입니다.

1. 사용자가 트랜잭션을 제출합니다.
2. 네트워크의 노드들이 같은 코드를 다시 실행합니다.
3. 실행 결과에 따라 상태가 바뀝니다.
4. 사용자는 실행 비용으로 가스를 지불합니다.

즉, 실행도 온체인에서 일어나고 상태 전이도 온체인에서 처리됩니다. 네트워크는 같은 계산을 반복하고, 그 결과를 기준으로 상태를 검증합니다. 이해하기 쉬운 구조지만, 실행 과정과 상태가 기본적으로 공개되는 모델에 가깝습니다.

Midnight은 다르게 동작합니다.

1. 사용자가 로컬에서 로직을 실행합니다.
2. 그 실행이 규칙에 맞았음을 보여주는 ZK proof를 생성합니다.
3. 공개해야 하는 결과와 transcript를 네트워크에 제출합니다.
4. 네트워크는 증명을 검증한 뒤, transcript에 포함된 공개 상태 전이만 온체인에서 실행합니다.

핵심은 여기에 있습니다.

EVM에서는 모든 노드가 전체 로직을 다시 실행합니다.

Midnight에서는 사용자가 로컬에서 프라이빗 연산을 수행하고, 네트워크는 그 결과가 규칙에 맞는지를 증명으로 검증한 뒤 공개 상태 전이만 반영합니다.

따라서 Midnight에서는 단순히 “함수를 호출한다”는 관점만으로는 부족합니다. 그 연산이 무엇을 증명하는지, 그리고 그 결과가 어떤 공개 상태 전이로 이어지는지까지 함께 봐야 합니다.

상태와 자산을 바라보는 방식

EVM 개발자에게 익숙한 모델은 보통 account 모델입니다. 글로벌 상태 안에 주소별 잔액과 값이 있고, 트랜잭션이 그 값을 직접 바꾸는 방식입니다.

Midnight은 출발점이 다릅니다. 핵심 자산 메커니즘은 UTXO 기반 구조를 사용하며, 이 구조는 프라이버시를 보존하는 설계와 잘 맞습니다. 잔액을 직접 수정하기보다, 기존 입력을 소비하고 새로운 출력을 만드는 방식으로 자산이 이동합니다.

EVM식으로 표현하면 “Alice의 잔액에서 40을 빼고 Bob의 잔액에 40을 더한다”에 가깝습니다.

반면 Midnight식으로 보면 “기존 입력 UTXO를 소비하고, Bob에게 보낼 출력 하나와 Alice의 잔돈에 해당하는 출력 하나를 새로 만든다”는 설명이 더 자연스럽습니다.

다만 Midnight을 단순한 UTXO 체인으로만 이해해도 오해가 생깁니다. Midnight은 순수 UTXO 체인이 아니라 하이브리드 구조를 사용합니다. ledger token 메커니즘은 UTXO 기반이지만, Compact으로 작성한 스마트 컨트랙트의 자산과 로직은 경우에 따라 account 스타일에 가까운 패턴으로 동작할 수도 있습니다.

그래서 Midnight을 이해할 때 더 적절한 표현은 “EVM의 반대”가 아닙니다.

Midnight은 UTXO 기반 자산 메커니즘과, 필요할 경우 account 스타일의 스마트 컨트랙트 동작을 함께 사용하는, 프라이버시와 증명 중심의 체인에 가깝습니다.

Compact을 기존 스마트 컨트랙트 언어처럼 보면 안 되는 이유

Compact을 처음 접할 때 흔히 하는 실수는, 이를 단순히 새로운 스마트 컨트랙트 문법으로만 보는 것입니다. 하지만 Compact은 문법만 새로 익힌다고 충분히 이해되는 언어가 아닙니다. 서로 다른 세 가지 맥락을 동시에 구분해야 합니다.

• ledger: 온체인에 남는 공개 상태
• circuit: 증명 시스템의 일부가 되는 로직
• witness: 로컬에서 제공되는 프라이빗 데이터. 일회성 입력일 수도 있고, 로컬에서 유지되는 프라이빗 상태나 기록의 일부일 수도 있음

이 구분이 중요합니다.

EVM에서는 상태 변수와 함수 호출을 중심으로 생각해도 대부분의 설계가 가능합니다. 하지만 Compact에서는 질문 자체가 달라집니다.

• 이 값은 어디에서 왔는가?
• 이 로직은 정확히 무엇을 증명하는가?
• 이 값은 끝까지 프라이빗하게 남는가, 아니면 공개되는가?

즉, 핵심은 새로운 문법이 아니라 공개 상태, 증명 로직, 프라이빗 데이터 사이의 경계가 새롭게 정의되어 있다는 점입니다.

이 경계를 이해하지 못하면 코드는 읽을 수 있어도, 그 언어로 실제 설계를 하기는 어렵습니다.

disclose()는 왜 필요할까

EVM 네트워크에서는 상태와 실행 결과가 기본적으로 공개됩니다. 별도로 “이 값은 공개하겠습니다”라고 선언하지 않아도, 온체인에 올라간 정보는 자연스럽게 공개됩니다.

Midnight은 반대 방향에서 출발합니다.

Midnight에서는 프라이버시가 기본값이고, 공개는 명시적인 선택입니다.

그래서 Compact에서는 witness나 프라이빗 연산에서 나온 값을 ledger로 넘길 때 disclose()를 사용합니다. 이는 단순한 헬퍼 함수가 아닙니다. 개발자가 “이 값은 공개하겠다”는 의도를 코드 안에서 명확히 드러내게 하는 장치입니다.

이 설계는 다음과 같은 의미를 갖습니다.

• 민감한 데이터가 실수로 노출될 가능성을 줄입니다.
• 어떤 값이 공개되는지 개발자가 더 신중하게 판단하게 합니다.
• Midnight의 프라이버시 중심 모델을 언어 차원에서 드러냅니다.

따라서 disclose()를 어색한 문법 요소 정도로 보면 안 됩니다. 오히려 이 함수는 Midnight이 EVM의 “기본 공개” 모델과 얼마나 다르게 설계되어 있는지를 가장 직접적으로 보여주는 요소 중 하나입니다.

Midnight은 문법보다 사고방식이 먼저입니다

여기까지 보면 핵심이 분명해집니다. Midnight을 또 하나의 EVM 계열 스택처럼 접근하면, 처음에는 익숙해 보여도 실제 개발에 들어갔을 때 금방 한계를 느낄 수 있습니다.

EVM에서는 보통 다음과 같은 전제를 깔고 개발합니다.

• 함수는 온체인에서 실행된다.
• 상태는 기본적으로 공개된다.
• 노드들은 같은 로직을 반복 실행한다.
• 가스는 거래 가능한 토큰에서 나온다.

Midnight에서는 이 전제가 바뀝니다.

• 사용자는 로컬에서 프라이빗 연산을 수행하고 증명을 생성합니다.
• 공개는 자동이 아니라 명시적입니다.
• 네트워크는 전체 로직을 다시 실행하지 않고, 증명을 검증한 뒤 transcript에 담긴 공개 상태 전이만 반영합니다.
• 경제·운영 모델 역시 NIGHT와 DUST를 중심으로 다르게 설계되어 있습니다.

결국 Midnight을 배운다는 것은 Compact 문법을 외우는 일이 아닙니다.

더 정확히는, 프라이버시와 증명 생성이 기본 전제로 들어간 환경에서 스마트 컨트랙트를 어떻게 설계해야 하는지 다시 배우는 과정에 가깝습니다.

이 시리즈가 DUST부터 다루는 이유도 여기에 있습니다. Midnight은 단순히 “어떻게 작성하는가”만 바꾸는 플랫폼이 아니라, “어떻게 실행되고 운영되는가”까지 함께 바꾸는 플랫폼이기 때문입니다.

Next Step: 환경 설정

이 글이 의도한 대로 전달되었다면, Compact이 왜 처음에는 익숙해 보여도 실제로는 전혀 다른 방식으로 동작하는지 어느 정도 감이 잡혔을 것입니다.

이제 다음 단계는 문법 비교가 아니라 실제 실행입니다.

다음 가이드에서는 환경 설정과 첫 실행을 통해, 지금까지 설명한 모델 차이가 실제 개발 워크플로에서 어떻게 드러나는지 확인해보겠습니다.

핵심 정리

이 글의 핵심은 다음과 같습니다.

• Compact은 문법만 보면 익숙할 수 있지만, 실행 모델은 전혀 다릅니다.
• Midnight에서는 사용자가 로컬에서 프라이빗 연산을 수행하고 ZK proof를 생성합니다.
• 네트워크는 전체 로직을 재실행하지 않고, 증명을 검증한 뒤 transcript에 담긴 공개 상태 전이만 실행합니다.
• Midnight은 UTXO 기반 자산 메커니즘과 account 스타일의 스마트 컨트랙트 동작을 함께 쓰는 하이브리드 구조입니다.
• ledger, circuit, witness의 구분은 Compact을 이해하는 핵심입니다.
• disclose()는 사소한 문법 요소가 아니라, 공개가 자동이 아니라는 Midnight의 원칙을 코드로 드러내는 장치입니다.