ZK 코프로세서의 0에서 1까지: 데이터 주도 패러다임을 넘어, Web 3.0 비동기 모드 개척
ZK 코프로세서는 블록체인 분야에서 흥미로운 혁신 기술이다. Brevis, Axiom, Lagrange, Herodotus 등의 프로젝트들이 앞장서 도입한 이 기술은 블록체인 상에서 애플리케이션을 개발하는 방식에 혁명을 일으킬 가능성을 지니고 있다. ZK 코프로세서를 통해 개발자들은 복잡한 계산을 수행할 수 있는 데이터 기반 dApp을 만들 수 있으며, 이를 위해 추가적인 신뢰 가정 없이도 옴니체인(omnichain) 데이터의 과거 기록을 활용할 수 있다. 더욱 중요한 것은, 이 기술이 비동기 애플리케이션 아키텍처라는 새로운 개발 패러다임을 이끌어내고 있다는 점으로, Web 3.0 소프트웨어 프레임워크에 전례 없는 효율성과 확장성을 제공한다.
본 시리즈에서는 ZK 코프로세서의 개념을 하나씩 밝혀나갈 것이다. 해당 기술의 원리, 실제 적용 사례, 기초 메커니즘, 직면한 과제, 시장 전략에 관심이 있든, 혹은 다양한 프로젝트들을 비교하고 싶든, 독자들에게 새로운 통찰을 제공하고자 한다.
DEX에 VIP 트레이더 프로그램이 부족한 사례
ZK 코프로세서의 핵심 아이디어를 이해하기 위해선 현실 세계의 인센티브 사례부터 살펴볼 필요가 있다.
중앙화 거래소(CEX)와 탈중앙화 거래소(DEX) 사이의 명백한 차이점 중 하나는 거래량 기반 요금 체계, 즉 일반적으로 말하는 'VIP 트레이더 로열티 프로그램'의 존재 여부이다. 이러한 프로그램은 트레이더 유지를 위한 강력한 도구이며, 유동성을 높이고 궁극적으로 거래소 수익을 증대시키는 데 기여한다.
흥미롭게도 모든 CEX는 적어도 하나 이상의 그러한 프로그램을 운영하고 있지만, DEX는 전무하다. 그 이유는 무엇일까?
이는 DEX에서 이러한 기능을 구현하는 것이 CEX보다 훨씬 더 어렵고 비용이 많이 들기 때문이다.
CEX의 경우, 로열티 프로그램을 도입하려면 다음 두 가지만 필요하다:
-
모든 사용자의 거래 내역을 중앙 집중형 데이터베이스에 기록한다—이는 향후 조회 비용을 줄이기 위한 간단한 작업이다.
-
매월 고성능 중앙 집중형 DB에서 직접 쿼리를 실행하여 각 사용자의 누적 거래량과 요금 등급을 산정한다.
그러나 DEX가 동일한 절차를 따르려 할 때는 중대한 장애물에 부딪힌다:
-
블록체인의 저장 비용이 너무 높아 스마트 컨트랙트 내에 각 사용자의 거래 기록을 직접 저장하는 것은 실현 불가능하다. 이러한 논리를 구현하면 사용자 거래당 수수료가 4배 이상 증가하게 된다.
-
거래 기록 데이터를 저장한다고 해도, 이를 통계적으로 조회하고 계산하는 비용은 훨씬 더 크다. 예를 들어, 단일 사용자의 1만 건 거래량을 계산하는 데 1억 5600만 가스(Gas)가 소요된다. (맞다, 실제로 계산해 보았다.)
잠깐만, 이렇게 말할 수도 있겠다. "어떻게 그런 말을 하는가? 블록체인에서는 모든 사용자의 모든 거래가 이미 자동으로 저장되어 있지 않나? 블록체인 상에서 작동하는 스마트 컨트랙트라면 당연히 언제든지 이런 데이터에 접근할 수 있어야 하지 않나?"
안타깝지만 그렇지 않다!
블록체인에 저장된 데이터와 블록체인 가상 머신(Virtual Machine) 내 스마트 컨트랙트가 접근 가능한 데이터는 완전히 별개의 문제이다.
완전 노드(full node) 또는 아카이브 노드(archive node)는 블록체인 역사 전체에 걸친 방대한 데이터를 저장한다. 이러한 노드를 통해 다음 정보를 쉽게 접근할 수 있다:
-
역사상 특정 시점에서의 블록체인 전체 상태 (예: 최초 Cryptopunk 소유자가 누구였는지).
-
역사상 특정 시점의 거래 및 그에 따른 이벤트 (예: Charlie가 $1,000을 0.5 ETH로 교환함).
사실, Nansen이나 Dune Analytics 같은 인기 있는 오프체인(off-chain) 데이터 인덱싱 및 분석 도구는 이러한 광범위한 데이터 세트를 활용해 심층 분석을 수행한다.
그러나 블록체인 가상 머신에 내장된 스마트 컨트랙트의 경우, 데이터 접근이 훨씬 더 제한적이다. 스마트 컨트랙트는 오프체인 인덱싱 솔루션이 생성한 데이터를 사용할 수 없다. 왜냐하면 외부적이며 대부분 중심화된 이러한 인덱싱 솔루션은 추가적인 신뢰 문제를 야기하기 때문이다.
사실상 스마트 컨트랙트는 다음 데이터들만 쉽고 신뢰 없이(trustlessly) 접근할 수 있다:
-
가상 머신 상태에 저장된 데이터 (거래 또는 이벤트 데이터 제외).
-
최근 블록의 데이터 (과거 데이터 접근은 제한됨).
-
"view" 함수를 통해 공개된 다른 스마트 컨트랙트의 데이터 (비공개 또는 내부 컨트랙트 데이터 제외).
여기서 핵심적인 미묘함은 바로 "쉽게"라는 표현에 있다.
스마트 컨트랙트가 블록체인의 모든 데이터를 전혀 모른다는 것은 아니다. EVM의 경우, 스마트 컨트랙트는 최근 256개 블록의 블록 헤더 해시에 접근할 수 있다. 이러한 블록 헤더에는 현재 블록까지의 모든 활동이 포함되어 있으며, 머클 트리(Merkle tree)와 Keccak 해시를 통해 32바이트의 해시 값으로 압축된다.
압축된 것은 해제할 수 있다... 다만 쉽지는 않다 😂
최근 블록 헤더를 활용해, 신뢰 없이도 이전 블록의 특정 데이터에 접근하고자 한다고 생각해보자. 이 방법은 아카이브 노드로부터 오프체인 데이터를 가져온 후, 머클 트리와 블록 유효성 증명을 구성하여 해당 데이터가 블록체인에 실제로 존재했음을 확인하는 것이다. 이후 EVM이 이 유효성 증명을 검증하고 해석한다. 그러나 이러한 작업은 번거롭고 어려우며, 단지 몇 개의 과거 토큰 잔액을 조회하는 데도 수천만 가스가 소요될 수 있다.
이러한 과제의 근본 원인은 블록체인 가상 머신 자체가 대용량 데이터 및 고밀도 연산(예: 위의 압축 해제 작업)을 처리할 능력을 갖추지 못했다는 점이다.
ZK 코프로세서 아키텍처
(출처: Brevis의 ETHSG 발표 슬라이드)
블록체인이 이러한 데이터 집약적인 번거로운 계산을 위임하고, 추가적인 신뢰 가정 없이도 저비용으로 신속하게 결과를 얻을 수 있는 마법 같은 방법이 있다면 얼마나 좋겠는가?
친구여, 그것이 바로 ZK 코프로세서가 존재하는 이유다.
"코프로세서(co-processor)"라는 이름은 컴퓨터 아키텍처의 역사에서 영감을 얻었다. 예를 들어, GPU는 CPU의 코프로세서로서 도입되었는데, 이는 CPU가 그래픽 계산이나 AI 훈련과 같이 고비용이면서도 스스로 처리하기 어려운 중요한 연산을 "보조 프로세서"인 GPU에게 위임해야 했기 때문이다.
그렇다면 ZK 코프로세서의 "ZK"는 무엇을 의미할까? 복잡한 기술적 디테일을 파고들기 전에, 우선 이 혁신 기술이 지닌 광범위한 의미와 잠재력을 살펴보자.
Web 3.0에서 데이터 기반 dApp이 필요한 이유
거래 수수료 환급(Rewards)이 좋은 예시다. 이 관점에서 보면, ZK 코프로세서를 활용하면 다양한 DeFi 프로토콜에 로열티 프로그램을 매끄럽게 도입할 수 있다.
하지만 이는 단순히 DeFi 로열티 프로그램에 국한되지 않는다. 이제 눈치챘을지도 모르지만, Web 3.0의 다른 영역에서도 동일한 문제가 존재한다. 생각해보라. 현대의 모든 Web 2.0 애플리케이션은 데이터 기반이지만, Web 3.0 앱은 예외 없이 그렇지 않다. 전통 인터넷 앱과 견줄 만한 사용자 경험을 제공하는 '킬러 앱(killer app)'을 만들려면, 이러한 데이터 기반 접근법은 필수적이다.
DeFi 분야에서 또 다른 사례를 살펴보자. 유동성 마이닝 보상 메커니즘을 재설계해 유동성 효율성을 높이는 경우다.
현재 AMM DEX의 유동성 인센티브는 '선불제(pay-as-you-go)' 모델을 따른다. 즉, LP가 유동성을 제공하면 즉시 파밍 보상이 지급된다. 하지만 이 모델은 결코 최적이라 할 수 없다. 전문 파머들은 시장 변동성이 감지되면 유동성을 급히 철수하여 impermanent loss(무상 손실)를 피할 수 있다. 이로 인해 프로토콜에 거의 가치를 제공하지 않으면서도 상당한 보상을 받는다.
이상적인 AMM 유동성 인센티브는 특히 시장이 크게 요동칠 때 LP들의 지속성을 추적 평가해야 한다. 그런 상황에서도 계속해서 풀을 지원하는 사람들에게 가장 높은 보상을 주어야 한다. 하지만 오늘날 이 모델에 필수적인 LP의 과거 행동 데이터를 확보하는 것은 여전히 불가능하다.
이를 위해서는 반드시 ZK 코프로세서가 필요하다.
DeFi 분야에서는 예약된 알고리즘과 규칙을 이용한 능동적 LP 포지션 관리, 토큰이 아닌 유동성 포지션을 기반으로 한 신용 한도 설정, 과거 상환 이력을 바탕으로 한 대출의 동적 정산 우선순위 결정 등과 같은 유사한 사례를 무수히 제시할 수 있다.
그러나 ZK 코프로세서의 잠재력은 DeFi에만 국한되지 않는다.
ZK 코프로세서로 탁월한 사용자 경험을 제공하는 완전 체인상 게임 구축
Web 2.0 게임의 실시간 운영 기능 예시
새로 설치한 Web 2.0 게임에 접속하면, 당신의 모든 행동이 상세히 기록된다. 이러한 데이터는 방치되지 않고, 당신의 게임 여정에 상당한 영향을 미친다. 언제 인앱 구매 옵션을 제공할지, 언제 보상 게임을 출시할지, 어떤 문구로 푸시 알림을 보낼지, 어떤 상대와 매칭할지 등을 결정하는 데 사용된다. 모두 게임 업계에서 말하는 실시간 운영(LiveOps)의 일부이며, 플레이어 참여도와 수익 창출의 핵심 요소다.
완전 체인상 게임의 사용자 경험을 Web 2.0 클래식 게임 수준으로 끌어올리기 위해서는 이러한 LiveOps 기능이 필요하다. 그리고 이러한 기능은 플레이어가 게임 스마트 컨트랙트와 과거에 상호작용한 기록과 거래 기반으로 이루어져야 한다.
안타깝게도 블록체인 게임에서는 이러한 기능이 아예 없거나, 아직 중심화된 솔루션에 의해 구동되고 있다. 그 이유는 DEX 사례와 동일하다. 블록체인 상에서 과거 게임 데이터를 캐내고 계산하는 것이 어렵기 때문이다.
맞다. 역시 ZK 코프로세서가 필요하다.
Web 3.0 소셜 및 정체성(ID) 애플리케이션 또한 ZK 코프로세서 없이는 제대로 작동할 수 없는 영역이다.
블록체인 세계에서 당신의 디지털 정체성은 과거의 행동들이 짜 맞춰진 일종의 네트워크이다.
-
NFT OG임을 증명하고 싶은가? 그러면 당신이 Cryptopunk의 초기 채굴자 중 한 명임을 입증하라.
-
큰 트레이더라고 자랑하고 싶은가? DEX에서 100만 달러 이상의 거래 수수료를 지불했음을 입증해 보여라.
-
Vitalik과 친분이 있다고? 그의 주소가 당신의 주소로 자금을 보낸 것을 입증하라.
오프체인 시스템—사람이든 Web 2.0 앱이든—은 이러한 증명을 쉽게 생성할 수 있다. 왜냐하면 거래량의 예시처럼, 모든 데이터를 포함하는 아카이브 노드에 접근할 수 있기 때문이다.
이러한 직접적인 데이터 접근을 기반으로 한 정체성 증명은 강력한 지갑 주소 연결이 필요하며, 따라서 개인정보 노출이라는 단점도 감수해야 한다. 하지만 분명히 가능은 하다.
그러나 거래량의 사례와 마찬가지로, 만약 당신이 스마트 컨트랙트로 하여금 당신의 OG 정체성을 믿게 하고, 추가적인 신뢰 증명 없이도 새 서비스를 조기에 체험하고 싶다면, 지금까지는 사실상 방법이 없었다.
ZK 코프로세서를 통해 당신은 자신의 과거 행동을 증명하는, 신뢰할 수 있는 정체성 증명을 만들어낼 수 있다. 어떤 스마트 컨트랙트라도 망설임 없이 받아들일 수 있는 증명이다. 서로 다른 애플리케이션은 물론이고 다른 블록체인 간의 상호작용까지도 정교하게 통합하여 이 증명을 구성할 수 있다.
더욱 매력적인 것은 ZK가 본질적으로 지닌 프라이버시 특성이다. 당신의 지갑 주소를 정체성과 공개적으로 연결할 필요가 없다. 예를 들어, 특정 지갑 주소를 밝히지 않고도 Cryptopunk NFT를 소유하고 있음을 증명할 수 있다. 혹은 Uniswap에서 1만 회의 거래를 실행했음을 증명하면서도 정확한 횟수는 공개하지 않을 수 있다.
ZK 코프로세서는 데이터 기반 dApp 개발을 위한 완전히 새로운 영역을 열어준다. 하지만 그것의 의미는 이보다 훨씬 깊다.
데이터 기반 패러다임을 넘어서: ZK 코프로세서로 개척하는 Web 3.0 비동기 모델
데이터 기반 dApp 패턴은 매우 매력적이지만, 이는 빙산의 일각에 불과하다.
ZK 코프로세서의 등장은 블록체인 컴퓨팅에 대한 우리의 인식을 근본적으로 변화시키며, 비동기 처리가 Web 3.0의 표준이 되는 시대를 열 것이다. 이 전환은 작업 처리 방식을 재정의하며, 전문화된 프로세서가 독립적으로 작동함으로써 효율성을 극대화한다.
먼저 비동기 처리란 무엇인지 알아보자.
동기식 레스토랑을 상상해보자. 한 사람이 동시에 요리사와 웨이터 역할을 한다. 당신이 주문하면 그는 바로 요리를 시작하고, 당신은 기다려야 한다. 그는 당신에게 음식을 서빙한 후에야 비로소 다른 손님을 받을 수 있다. 이런 구조가 당신에게는 맞을지 몰라도, 다른 사람들에게는 효율을 높이기 어렵다.
반면 비동기식 레스토랑에서는 여러 요리사와 여러 웨이터가 협업한다. 웨이터는 주문을 받은 후 즉시 요리사에게 전달하고, 그 사이에 다른 손님을 돌본다. 요리가 완성되면 요리사가 웨이터에게 신호를 보내고, 웨이터는 그때 음식을 서빙한다.
컴퓨터 시스템에서는 다음과 같다:
동기식 아키텍처는 첫 번째 레스토랑과 같으며, 한 작업이 완료될 때까지 다음 작업을 기다린다. 이 구조는 간단하고 명확하지만 느릴 수 있으며, 한 번에 하나의 작업만 처리한다. 게다가 그 사람은 훌륭한 웨이터일지 몰라도 요리는 서툴 수도 있다.
비동기식 아키텍처는 두 번째 레스토랑과 같으며, 해체(de-coupled)되고 전문화된 시스템 컴포넌트들이 메시지와 작업을 주고받으며 조율한다. 이를 통해 각 컴포넌트가 동시에 자신의 작업을 관리할 수 있다. 관리가 더 복잡할 수 있지만, 훨씬 빠르고 효율적이다.
모든 현대 인터넷 애플리케이션은 효율성과 확장성을 위해 비동기 아키텍처를 기반으로 구축된다. 우리는 Web 3.0 역시 마찬가지여야 한다고 생각한다.
ZK 코프로세서는 이러한 변화의 선두주자가 될 것이다. dApp 개발자에게 있어 블록체인은 우리가 상상한 비동기 레스토랑의 웨이터와 같다. 블록체인은 주로 자산 소유권 변경과 같은 블록체인 상태를 직접 변경하는 계산을 처리한다. 나머지 모든 계산은 견고한 ZK 코프로세서에 맡겨야 하며, 이들은 숙련된 요리사처럼 비동기 처리의 힘을 발휘해 결과물을 효율적으로 만들어 웨이터에게 전달한다.
구체적으로 말해, 블록체인 애플리케이션의 계산이 아래 두 가지 '적격 조건' 중 하나에 해당한다면, ZK 코프로세서의 사용을 고려해야 한다.
ZK 코프로세서 적용 가능 조건:
-
체인상 계산 비용 > (오프체인 ZK 코프로세서 계산 + 증명 생성 비용 + 체인상 검증 비용)
-
체인상 계산 지연 시간 > (오프체인 ZK 코프로세서 계산 + 증명 생성 시간 + 체인상 검증 지연 시간)
둘 중 하나만 만족해도 고려할 가치가 있다!
이제 알았을 것이다. 이것이 단순히 데이터 기반 dApp을 넘어선다는 점을 말이다! 이는 ML과 같은 고난도 범용 컴퓨팅을 블록체인으로 가져오는 완전히 새로운 방식일 뿐 아니라, 이전까지 불가능했던 dApp 구축을 위한 패러다임 전환적 비동기 아키텍처를 도입한다는 점에서 중요하다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
IOSG Ventures
