안녕하세요, BQ개발자입니다.
📱 내가 ZK를 공부하는 이유 #2: 같은 칼, 다른 용도
지난 편들에서 ZK가 불가능을 가능하게 만들고, 설계에 따라 전혀 다른 결과를 낸다는 걸 이야기했습니다.
이번엔 ZK 프로그래밍의 독특한 사고방식에 대해서입니다.
🤯 ZK는 거꾸로 생각한다
ZK 코드의 구조는 일반 프로그래밍과 다릅니다.
일반 프로그래밍: "이렇게 해서 저렇게 하면 결과가 나온다"
ZK 프로그래밍: "이 조건들이 참이어야 한다"
송금을 예로 들면:
- 일반: A에서 100원 빼기 → B에 100원 더하기 → 완료
- ZK: 전체 금액 합 = 변경전 합 AND 모든_잔액 ≥ 0
절차가 아닌 조건으로 표현됩니다.
💡 숨겨야 하니까 조건만 남는다
이런 차이가 생기는 이유는 ZK의 작동 원리 때문입니다.
ZK는 "과정은 비밀, 결과만 공개"라는 특성을 가집니다.
검증자는 어떤 순서로 계산했는지 알 수 없습니다.
따라서 최종 상태가 올바른 조건을 만족하는지만 확인합니다.
송금 예시의 경우:
- 검증자는 "누가 누구에게 얼마를 보냈는지" 과정을 모름
- "전체 돈의 합이 그대로인지"만 확인
- "음수 잔액이 없는지"만 체크
과정을 검증할 수 없으므로, 결과가 만족해야 할 조건으로 정의합니다.
🎯 이게 왜 더 나을까?
조건 기반 접근의 실질적 장점이 있습니다.
순서대로 하면 생기는 문제:
1. A에서 100원 차감 ✓
2. [여기서 시스템 다운!]
3. B에 100원 추가 ✗
→ 결과: 100원이 사라짐
조건으로 정의하면:
조건: 전체_금액_합 = 일정
→ 이 조건이 깨지면 거래 자체가 무효
중간 실패 시에도 일관성이 유지됩니다.
또한 순서가 없으므로 병렬 처리가 가능합니다.
여러 거래를 동시에 처리해도 최종 조건만 만족하면 됩니다.
✏️ 프로그래밍을 넘어선 사고법
이런 접근은 시스템 설계 관점을 바꿉니다.
"어떻게 구현할 것인가" 대신
"무엇이 항상 참이어야 하는가"를 먼저 정의합니다.
각 시스템의 불변식(invariant):
- 은행: 전체 돈의 합은 일정하다
- 투표: 투표수 = 투표자수
- 재고관리: 입고 - 출고 = 현재재고
이 불변식들이 시스템의 핵심 속성을 정의하는거죠.
💭 ZK가 가르쳐준 것
ZK 프로그래밍은 "무엇이 불변인가"를 먼저 정의해야 합니다.
이는 단순한 구현 기법이 아닌 설계 철학의 차이입니다.
복잡한 절차를 단순한 조건들로 표현하는 방법.
순서가 아닌 본질적 속성으로 시스템을 정의하는 방법.
이런 사고의 전환이 ZK를 공부하는 또 다른 이유입니다.
다음 마지막 편에서는 왜 지금이 ZK를 시작하기 좋은 시점인지 이야기하겠습니다.
---
여러분의 좋아요와 공유는 사랑입니다 🥰