Aztec: Private Smart Contracts on Ethereum

Summary

Aztec은 Ethereum 위에서 동작하는 privacy-first Layer 2다. 기존 블록체인에 거래 은닉 기능을 덧붙이는 데 그치지 않고, 비공개 상태와 비공개 실행을 스마트컨트랙트의 기본 구성 요소로 다루는 Private Smart Contract L2를 지향한다.

핵심은 모든 데이터를 공개하지 않아도 상태 전이가 올바르게 일어났음을 검증하는 것이다. 이를 위해 Aztec은 다음 요소를 하나의 실행 모델로 결합한다.

이 구조를 통해 하나의 애플리케이션 안에서 public state와 private state, public function과 private function을 선택적으로 조합할 수 있다. Private payments, confidential DeFi, selective disclosure identity, private governance 같은 애플리케이션이 대표적인 설계 공간이다.

다만 이 선택에는 비용이 따른다. EVM 호환성을 포기한 별도의 개발 모델, client-side proving 비용, private state 관리, 디버깅과 관찰 가능성 저하를 함께 감수해야 한다.

Context

퍼블릭 블록체인은 누구나 상태와 트랜잭션을 검증할 수 있다는 투명성을 기반으로 성장했다. 계정 잔고, 컨트랙트의 상태 변화, 트랜잭션의 결과가 공개되기 때문에 특정 운영자를 신뢰하지 않고도 원장의 무결성을 확인할 수 있다.

하지만 모든 애플리케이션에 완전한 공개성이 적합한 것은 아니다.

• 개인의 결제 내역과 자산 규모가 항상 공개되어야 하는가?
• 기업의 재무 흐름과 내부 정산을 누구나 실시간으로 추적할 수 있어야 하는가?
• 트레이더의 주문, 포지션, 전략이 사전에 노출되는 시장은 효율적인가?
• 사용자의 전체 신원을 공개하지 않고도 자격 조건을 검증할 수 있는가?

이 질문들은 결국 하나로 모인다.

블록체인에서 검증 가능성과 완전한 공개성은 반드시 같은 것이어야 하는가?

초기 온체인 프라이버시는 거래의 연결성을 끊거나 자산 이동 경로를 흐리는 데 주로 집중했다. Aztec은 여기서 더 나아가 사용자의 상태, 컨트랙트 내부 데이터, 연산 입력값과 애플리케이션 로직이 처리하는 정보까지 private하게 다룰 수 있는 실행환경을 설계한다.

Problem and Questions

Aztec은 네트워크가 민감한 데이터를 직접 보지 않는데도 어떻게 트랜잭션과 상태 전이를 검증할까? Public execution과 private execution은 어디서 수행되며, Notes와 Nullifiers는 비공개 상태를 어떻게 표현할까? 또한 Aztec은 왜 EVM 호환성보다 programmable privacy를 선택했을까?

Programmable Privacy

Privacy as Expressiveness

Aztec에서 프라이버시는 특정 트랜잭션에 추가하는 옵션이 아니라 애플리케이션을 설계할 때 사용하는 기본 재료다. 개발자는 하나의 컨트랙트 안에서 다음을 결정할 수 있다.

• 어떤 상태를 공개하고 어떤 상태를 비공개로 유지할지
• 어떤 함수를 네트워크에서 실행하고 어떤 함수를 사용자 기기에서 실행할지
• 어떤 정보는 숨기되 어떤 결과는 공개적으로 검증할지
• private context에서 시작한 처리를 public state와 어떻게 연결할지

실제 애플리케이션은 모든 정보를 숨기거나 공개하는 양극단보다 그 사이의 조합을 필요로 한다. 결제 금액은 감추되 결제의 유효성은 검증해야 하고, 신원 전체는 숨기되 특정 자격을 충족한다는 사실은 증명해야 할 수 있다.

이 관점에서 Aztec의 프라이버시는 단순한 데이터 은닉보다 블록체인이 표현할 수 있는 애플리케이션 범위의 확장에 가깝다.

From Private Transactions to Private Applications

거래 경로를 감추는 것과 스마트컨트랙트가 비공개 상태를 직접 다루는 것은 다른 문제다.

Aztec이 목표로 하는 것은 후자다. Private state와 private execution을 프로그래밍 모델에 포함해, 개발자가 프라이버시 요구사항을 컨트랙트 로직으로 표현할 수 있게 한다.

Architecture

Architecture at a Glance

Aztec의 실행 구조는 사용자 기기, Aztec 네트워크, Ethereum의 세 영역으로 나눠 이해할 수 있다.

User Device
└── PXE
    ├── Private state 조회
    ├── Private function 실행
    └── 실행 결과에 대한 증명 구성
             │
             │ proof + state updates
             ▼
Aztec Network
├── Sequencer
│   ├── Private proof 검증
│   ├── AVM에서 public function 실행
│   └── 상태 업데이트 반영과 블록 제안
├── Validator Committee
│   └── 제안된 블록 검증과 attestation
└── Prover Network
    └── 여러 블록을 집계한 epoch proof 생성
             │
             │ epoch proof
             ▼
Ethereum
└── Epoch proof 검증과 L1 정산

한 문장으로 정리하면 비공개 실행은 사용자 기기에서, 공개 실행은 Aztec 네트워크에서, 최종 정산은 Ethereum에서 수행된다.

PXE and Client-side Private Execution

PXE(Private Execution Environment)는 사용자 기기에서 private function을 실행하는 환경이다. 필요한 비공개 상태를 조회하고, 민감한 입력을 사용해 로직을 실행한 뒤, 그 실행이 컨트랙트 규칙을 따랐음을 증명할 데이터를 구성한다.

중요한 점은 민감한 입력값의 이동 경로다. 일반적인 public execution에서는 네트워크가 입력을 받아 연산을 수행하지만, Aztec에서는 민감한 정보가 네트워크에 직접 전달되지 않는다. 사용자가 로컬에서 private computation을 수행하고 네트워크에는 상태 전이를 검증하는 데 필요한 결과만 제출한다.

따라서 Aztec의 프라이버시는 네트워크가 데이터를 보고도 비밀을 지켜준다는 가정에 의존하지 않는다. 네트워크가 원본 데이터를 볼 필요가 없도록 실행 위치를 바꾸는 것이 핵심이다.

AVM and Public Execution

모든 상태와 연산을 private하게 만들 필요는 없다. 프로토콜 파라미터, 공개 레지스트리, 시스템 설정처럼 누구나 확인해야 하는 정보는 public state로 유지된다.

Public function은 Aztec 네트워크의 AVM(Aztec Virtual Machine)에서 실행된다. 하나의 트랜잭션은 private context에서 시작한 뒤 필요에 따라 public function을 호출할 수 있다. 이 구조 덕분에 사용자별 비공개 상태와 네트워크 공통의 공개 상태를 하나의 애플리케이션 안에서 연결할 수 있다.

Ethereum Settlement

Aztec은 Ethereum과 분리된 독립 정산 계층이 아니다. Sequencer가 제안한 블록은 Validator Committee의 검증과 attestation을 거치고, 여러 블록은 하나의 epoch로 묶인다. Prover Network는 해당 epoch에 포함된 트랜잭션과 상태 전이를 집계한 rollup proof를 생성한다.

이 epoch proof가 Ethereum에 제출되어 L1에서 검증되면 상태 전이가 최종화된다. 사용자는 그보다 앞선 committee attestation 시점에 블록 포함을 확인할 수 있지만, Ethereum settlement와 동일한 수준의 최종성은 L1 proof verification 이후에 얻는다.

따라서 Aztec은 Ethereum 위에 정산되지만 Ethereum의 공개 실행 모델과는 다른 privacy-first 실행환경을 가진 L2라고 볼 수 있다.

State Model

Public State

Public state는 일반적인 블록체인 상태와 비슷하다. 누구나 값을 읽을 수 있고 네트워크는 공개된 데이터를 기준으로 상태를 직접 갱신한다.

Aztec이 모든 상태를 private하게 만들지 않는 이유는 공개 상태가 필요한 애플리케이션도 많기 때문이다. 프로토콜의 공통 규칙, 공개 레지스트리, 네트워크 전체가 합의해야 하는 파라미터는 public state에 적합하다.

Notes

Private state는 Note라는 단위로 표현된다. Note는 사용자가 소유하거나 접근할 수 있는 비공개 상태 조각이다.

예를 들면 다음과 같은 정보를 Note로 나타낼 수 있다.

• 비공개 잔액
• 공개하지 않은 자격 정보
• 개인별 권한이나 조건 값
• 컨트랙트가 관리하는 사용자별 private data

네트워크는 Note의 평문 내용을 알지 못하더라도 commitment와 증명을 통해 해당 상태가 올바른 규칙으로 생성되었는지 검증할 수 있다.

Nullifiers

비공개 상태를 감추는 것만으로는 충분하지 않다. 같은 Note를 여러 번 사용해 이중 지출이나 중복 상태 전이를 만드는 것을 막아야 한다.

이를 위해 사용하는 것이 Nullifier다.

사용자가 기존 Note를 소비하면 네트워크에는 그 Note에 대응하는 Nullifier가 공개된다. 네트워크는 Note의 실제 내용을 보지 않고도 동일한 Nullifier가 이미 존재하는지 확인해 재사용을 차단한다. 상태 전이가 성공하면 다음 상태를 나타내는 새로운 Note가 만들어진다.

Old Private Note
      │ consume
      ├── Nullifier 공개 → 재사용 방지
      └── New Note 생성  → 다음 private state

Aztec은 이 방식으로 상태를 감추는 데 그치지 않고, 감춰진 상태가 올바르게 소비되고 갱신되었는지 공개적으로 검증 가능하게 만든다.

Transaction Lifecycle

1. Create an Intent

사용자는 지갑이나 애플리케이션에서 private action을 시작한다. 비공개 잔액을 전송하거나 자신만 접근할 수 있는 상태를 기반으로 private function을 호출하는 경우가 이에 해당한다.

2. Execute Locally in the PXE

PXE는 필요한 private state를 불러오고 사용자 기기에서 private function을 실행한다. 이 단계에서 민감한 입력과 private state의 평문은 네트워크에 전달되지 않는다.

3. Build Proofs and State Updates

PXE는 실행이 컨트랙트 규칙을 따랐음을 보이는 증명과 상태 업데이트를 구성한다. 새 Note의 commitment, 소비된 Note의 Nullifier 등 네트워크가 상태 전이를 반영하는 데 필요한 정보가 포함된다.

4. Verify and Execute Public Logic

Sequencer는 제출된 private proof와 트랜잭션의 유효성을 확인한다. Public function 호출이 있다면 AVM에서 이를 실행하고, public state와 검증된 private state update를 반영한다.

5. Propose and Attest the Block

Sequencer는 트랜잭션을 모아 블록을 제안한다. Validator Committee는 제안된 블록을 검증하고 유효한 블록에 attest한다.

6. Generate the Epoch Proof

여러 블록으로 구성된 epoch가 끝나면 Prover Network가 해당 epoch 전체의 상태 전이를 집계한 rollup proof를 생성한다. 이 단계는 사용자가 만든 private proof와 AVM의 public execution 결과를 L1에서 검증할 수 있는 하나의 증명으로 압축한다.

7. Settle on Ethereum

Epoch proof는 Ethereum에 제출된다. Ethereum이 proof를 검증하면 해당 epoch의 상태 전이가 L1에서 최종화된다.

이 흐름은 퍼블릭 블록체인의 일반적인 실행 방식과 책임의 위치가 다르다.

Why Not EVM Compatibility?

EVM은 공개 상태와 공개 실행을 전제로 발전했다. 익숙한 개발 경험과 높은 컴포저빌리티를 제공하지만 private state와 private execution을 스마트컨트랙트의 기본 기능으로 만들기에는 구조적인 제약이 있다.

Aztec은 EVM 호환성을 유지하는 대신 다음 요소로 구성된 별도의 프로그래밍 모델을 선택했다.

• Noir와 Aztec.nr 기반 컨트랙트 개발
• PXE 기반 client-side private execution
• AVM 기반 public execution
• Notes와 Nullifiers 기반 private state
• Ethereum 기반 settlement

이는 단순히 EVM 생태계를 포기한 결정이라기보다 문제 정의에 따른 trade-off다. Aztec이 포기하려는 전제는 특정 VM 자체보다 모든 애플리케이션이 공개 실행을 기반으로 해야 한다는 가정에 가깝다.

Application Design Space

Private Payments

결제 금액과 상대방 정보를 모두 공개하지 않으면서도 유효한 결제였다는 사실을 검증할 수 있다. 단순한 익명 송금보다 검증 가능한 비공개 결제 인프라에 가깝다.

Confidential DeFi

포지션 규모, 담보 수준, 주문 의도, 투자 전략이 공개되면 프런트러닝이나 정보 노출 문제가 생길 수 있다. Private state를 활용하면 민감한 금융 정보를 드러내지 않는 DeFi 로직을 설계할 수 있다.

Selective Disclosure Identity

사용자의 신원 전체를 공개하지 않고도 연령, 자격, 인증 여부 같은 특정 조건을 충족한다는 사실만 증명할 수 있다. 검증에 필요하지 않은 개인정보의 노출을 줄이는 방식이다.

Private Governance

투표권과 집계 결과의 정당성은 검증하면서 개별 참여자의 선택은 숨기는 거버넌스를 설계할 수 있다. 공개 투표가 만드는 압력이나 매표 가능성을 줄이는 데 활용할 수 있다.

Institutional Workflows

기업과 기관은 규제 대응에 필요한 정보를 선택적으로 공개하면서 거래 조건, 내부 정산, 상대방 정보의 불필요한 노출을 줄이는 워크플로를 만들 수 있다.

Trade-offs and Limitations

Developer Learning Cost

Solidity와 EVM에 익숙한 개발자는 Noir, Aztec.nr, private/public function 분리, Notes와 Nullifiers 같은 새로운 개념을 학습해야 한다. 이는 언어만 바꾸는 것이 아니라 상태와 실행을 설계하는 사고방식의 변화다.

Proving Cost and UX

Private execution과 증명 생성이 사용자 기기에서 일어나므로 proving latency와 기기 성능이 사용자 경험에 직접 영향을 줄 수 있다. 애플리케이션은 프라이버시뿐 아니라 증명 시간, 메모리 사용량, 실패 복구 흐름을 함께 설계해야 한다.

Private State Management

사용자는 자신이 접근할 수 있는 private state를 찾아 복호화하고 관리해야 한다. 지갑과 PXE가 이 복잡성을 얼마나 안정적으로 감추는지가 실제 사용성에 중요하다.

Metadata Leakage and Privacy Boundaries

Private input이 PXE 밖으로 나가지 않는다고 해서 트랜잭션의 모든 정보가 숨겨지는 것은 아니다. 네트워크에서는 트랜잭션이 발생했다는 사실, 수수료, public function 호출과 공개 인자, L2-to-L1 message 같은 정보가 관찰될 수 있다. Private function에서 public function으로 경계를 넘을 때는 호출 자체와 전달한 데이터가 공개될 수 있으므로 컨트랙트 설계 단계에서 노출 범위를 명시해야 한다.

트랜잭션 타이밍이나 서로 다른 형태의 transaction fingerprint도 사용 패턴을 추론하는 단서가 될 수 있다. 또한 PXE가 외부 Aztec node에 world state나 Note 관련 경로를 질의하면 해당 node 운영자가 사용자의 관심 데이터를 추론할 가능성이 있다. 자신의 node를 운영하면 이 질의 노출을 줄일 수 있지만, 일반 사용자에게는 추가 운영 비용이 된다.

따라서 Aztec은 프라이버시를 자동으로 보장하는 완성형 익명화 도구라기보다 개발자가 private application을 설계할 수 있는 암호학적 구성 요소와 실행환경으로 이해해야 한다.

Reduced Observability

프라이버시는 사용자에게 장점이지만 외부 분석과 운영 관점에서는 가시성을 줄인다. 공개 온체인 데이터만으로 사용 패턴이나 리스크를 분석하기 어려워질 수 있으므로, 프로토콜은 프라이버시를 해치지 않는 별도의 모니터링 방법을 고민해야 한다.

Ecosystem Maturity

새로운 실행 모델이 보급되려면 프로그래밍 언어뿐 아니라 툴링, 지갑, 인프라, 디버거, 교육 자료와 애플리케이션이 함께 성숙해야 한다. 좋은 실행환경이 자동으로 좋은 생태계를 만드는 것은 아니다.

이 글을 검증한 시점의 공식 개발 문서는 Alpha v4.3.1을 기준으로 하며, 프로토콜과 API가 계속 변경될 수 있다고 안내한다. 따라서 현재 구조를 production-ready 보안 모델로 단정하거나 실제 가치가 큰 비밀을 바로 맡길 단계로 해석해서는 안 된다.

Mental Model

Aztec을 이해할 때 다음 문장을 기준으로 삼으면 각 구성 요소의 역할을 구분하기 쉽다.

사용자는 private state를 입력으로 로컬에서 실행하고, Sequencer와 AVM은 증명 및 공개 실행을 처리하며, Committee와 Prover Network를 거친 epoch proof는 Ethereum에서 최종 정산된다.

Privacy      = 원본 데이터와 실행 입력을 공개하지 않음
Correctness  = 증명으로 상태 전이의 유효성을 확인
Consistency  = Notes와 Nullifiers로 private state의 생성과 소비를 관리
Finality     = Ethereum에서 결과를 정산

Key Takeaways

• Aztec은 거래 은닉 기능이 아니라 programmable privacy를 제공하는 Private Smart Contract L2를 지향한다.
• 개발자는 하나의 애플리케이션 안에서 public/private 상태와 실행을 선택적으로 조합할 수 있다.
• PXE는 사용자 기기에서 private function을 실행하고 민감한 데이터가 네트워크에 직접 노출되지 않도록 한다.
• AVM은 네트워크가 확인해야 하는 public function과 public state를 처리한다.
• Note는 비공개 상태를 표현하고 Nullifier는 소비된 Note의 재사용을 방지한다.
• 네트워크는 private data의 평문을 보지 않고도 증명을 통해 상태 전이의 정당성을 확인한다.
• Sequencer가 블록을 제안하고 Validator Committee가 attest한 뒤, Prover Network가 epoch proof를 생성한다.
• Aztec은 epoch proof를 검증하는 Ethereum을 최종 검증과 정산 계층으로 사용한다.
• Private input은 숨겨지지만 public call, 수수료, 타이밍, transaction fingerprint와 node query에서 메타데이터가 노출될 수 있다.
• EVM 호환성을 포기한 만큼 새로운 개발 모델, client-side proving 비용, 상태 관리와 관찰 가능성 문제를 해결해야 한다.
• 현재 공식 개발 문서는 Alpha 단계이므로 프로토콜 변경 가능성과 production 사용 위험을 함께 고려해야 한다.
• Aztec의 가치는 이 비용을 감수할 만큼 중요한 private application이 실제로 만들어지는지에 달려 있다.

Review Questions

1. Transaction privacy와 programmable privacy의 차이는 무엇인가?
2. Aztec에서 private function을 네트워크가 아닌 사용자 기기에서 실행하는 이유는 무엇인가?
3. Note와 Nullifier는 각각 어떤 문제를 해결하는가?
4. 하나의 Aztec 트랜잭션에서 private execution과 public execution은 어떻게 연결되는가?
5. Sequencer, Validator Committee, Prover Network는 각각 어떤 역할을 담당하는가?
6. Aztec이 EVM 호환성을 선택하지 않은 이유는 무엇인가?
7. Client-side proving이 사용자 경험과 애플리케이션 설계에 주는 부담은 무엇인가?
8. Private input이 숨겨져도 어떤 메타데이터가 외부에 노출될 수 있는가?

References

• Aztec Overview
• Private Execution Environment
• Public Execution (AVM)
• State Management
• Transactions on Aztec
• Privacy Considerations