IOSG Ventures：ZK 협처리기 0에서 1까지, 그것은 도대체 무엇을 할 수 있을까?

作者： IOSG Ventures

Celer Network와 Brevis의 Mo Dong 선생님께 ZK 협처리기 핵심 개념과 사례에 대한 심도 있는 논의에 감사드립니다. 이러한 생각은 본 시리즈 기사의 창작 영감을 주었습니다.

ZK 협처리기는 블록체인 분야의 흥미로운 혁신입니다. Brevis, Axiom, Lagrange, Herodotus와 같은 프로젝트에 의해 처음 도입되었으며, 블록체인에서 애플리케이션을 개발하는 방식을 혁신할 것으로 기대됩니다. ZK 협처리기를 통해 개발자는 데이터 기반의 dApp을 생성할 수 있으며, 복잡한 계산을 수행하기 위해 omnichain 데이터의 이력을 활용할 수 있습니다. 이는 추가적인 신뢰 가정에 의존할 필요가 없습니다. 더 중요한 것은, 이는 새로운 개발 모델인 비동기 애플리케이션 아키텍처를 이끌어내어 Web 3.0 소프트웨어 프레임워크에 전례 없는 효율성과 확장성을 제공합니다.

본 시리즈 기사에서는 ZK 협처리기의 신비로운 면모를 밝혀낼 것입니다. 이론, 실제 응용, 기본 메커니즘, 직면한 도전 과제, 시장 전략에 관심이 있든지, 다양한 프로젝트를 비교하고 싶든지, 이 기사들이 새로운 영감을 주기를 바랍니다.

DEX에서 VIP 거래자 프로그램이 부족한 사례

ZK 협처리기의 기본 아이디어를 이해하기 위해서는 현실 세계의 인센티브 사례에서 시작해야 합니다.

중앙화 거래소(CEX)와 탈중앙화 거래소(DEX) 간의 명백한 차이점 중 하나는 거래량 기반의 요금 기준이 존재한다는 것입니다. 일반적으로 "VIP 거래자 충성도 프로그램"이라고 불리는 이러한 프로그램은 거래자를 유지하고 유동성을 높이며 궁극적으로 거래소의 수익을 증가시키는 강력한 도구입니다.

흥미롭게도, 모든 CEX는 최소한 하나의 이러한 프로그램을 보유하고 있지만, DEX는 전혀 없습니다. 왜 그럴까요?

DEX에서 이 기능을 구현하는 것은 CEX보다 더 도전적이며 비용이 더 많이 들기 때문입니다.

CEX에서 충성도 프로그램을 구현하려면:

• 중앙화된 데이터베이스에 모든 사용자의 거래 이력을 기록해야 합니다. 이는 향후 쿼리 비용을 줄이는 데 용이한 작업입니다.

• 매월 고성능 중앙화 데이터베이스에서 직접 쿼리를 실행하여, 역사적 데이터를 기반으로 각 사용자의 거래량과 수수료 등급을 결정해야 합니다.

그러나 DEX는 동일한 단계를 따르려 할 때 중대한 도전에 직면합니다:

• 블록체인의 저장 비용이 너무 높기 때문에 스마트 계약 내에서 각 사용자의 거래 이력을 직접 저장하는 것은 불가능합니다. 이러한 논리를 구현하면 사용자의 각 거래 수수료가 4배 높아집니다.

• 거래 기록 데이터 저장을 하더라도, 이러한 데이터에 대한 통계 쿼리와 계산의 비용이 더 높습니다. 예를 들어, 단일 사용자의 10K 거래의 거래량 데이터를 계산하는 데 156M Gas가 소요됩니다(맞습니다! 우리는 계산해 보았습니다).

당신은 "잠깐, 당신은 도대체 무슨 말을 하고 있는 건가요? 블록체인에서는 각 사용자의 각 거래가 자동으로 저장됩니다(블록체인이니까요!)."라고 말할 수 있습니다. 블록체인에서 태어난 스마트 계약은 언제든지 이러한 데이터에 접근할 수 있어야 하죠?

안타깝게도, 그렇지 않습니다!

블록체인에 저장된 데이터와 블록체인 가상 머신 내 스마트 계약이 접근할 수 있는 데이터는 완전히 다릅니다.

블록체인의 전체/아카이브 노드에 대해, 이들은 블록체인 역사에서 방대한 데이터를 저장합니다. 이러한 노드를 통해, 당신은 쉽게 접근할 수 있습니다:

• 역사적으로 주어진 시간에 전체 블록체인의 상태(예: Cryptopunk의 첫 번째 소유자가 누구인지).

• 역사적으로 주어진 시간에 거래와 거래로 인해 발생한 사건(예: Charlie가 $1,000를 0.5 ETH로 교환한 경우).

사실, Nansen 및 Dune Analytics와 같은 인기 있는 체인 외 데이터 인덱스 또는 분석 도구는 이 방대한 데이터 세트를 활용하여 심층 분석을 수행할 수 있습니다.

그러나 블록체인 가상 머신에 내장된 스마트 계약의 경우, 데이터 접근의 제한이 훨씬 큽니다. 이들은 체인 외 인덱스 솔루션이 생성한 데이터를 사용할 수 없으며, 이는 이러한 외부적이고 일반적으로 중앙화된 인덱스 솔루션에 추가적인 신뢰 문제를 야기합니다.

사실, 스마트 계약은 다음 데이터에 쉽게 접근할 수 있습니다:

• 가상 머신 상태에 저장된 데이터(거래 또는 사건 데이터 제외).

• 최신 블록의 데이터(역사적 데이터 접근은 제한적임).

• "보기" 기능을 통해 공개된 다른 스마트 계약의 데이터(비공식 또는 내부 계약 데이터 제외).

위의 설명에서 "쉽게"라는 단어의 중요한 미세한 차이가 있습니다.

스마트 계약은 블록체인 상의 모든 데이터를 완전히 모르는 것은 아닙니다. EVM에서는 스마트 계약이 최신 256개의 블록의 블록 헤더 해시 값을 접근할 수 있습니다. 이러한 블록 헤더는 블록체인에서 현재 블록까지의 모든 활동을 포함하며, 머클 트리와 Keccak 해시를 통해 32바이트 해시로 압축됩니다.

압축된 것은 압축 해제할 수 있습니다… 단, 쉽지는 않습니다 ?

최근 블록 헤더를 활용하여 신뢰 없이 이전 블록의 특정 데이터에 접근하고자 한다고 상상해 보세요. 이 방법은 아카이브 노드에서 체인 외 데이터를 가져온 다음, 머클 트리와 블록 유효성 증명을 구축하여 데이터가 블록체인에서 진실임을 확인하는 것을 포함합니다. 그런 다음 EVM은 유효성 증명을 처리하여 검증하고 해석합니다. 이러한 작업은 번거롭고 힘든 작업이며, 과거 몇 개의 토큰 잔액을 검색하기 위해 수천만 Gas를 소모할 수 있습니다.

이러한 도전의 근본 원인은 블록체인 가상 머신 자체가 대량의 데이터와 집약적인 계산(위의 압축 해제 작업과 같은)을 처리할 수 있는 능력이 없기 때문입니다.

ZK 협처리기 아키텍처(출처: Brevis의 ETHSG 발표 슬라이드)

만약 블록체인이 이러한 데이터 집약적인 번거로운 계산을 위임하고, 낮은 비용으로 신속하게 결과를 얻을 수 있으며, 추가적인 신뢰 가정이 필요 없다면, 그것은 더할 나위 없이 이상적일 것입니다.

친구들, 이것이 바로 ZK 협처리기의 용도입니다.

"협처리기"라는 이름은 컴퓨터 아키텍처의 발전 역사에서 영감을 받았습니다. 예를 들어, GPU는 CPU의 협처리기로 도입되었습니다. 이는 CPU가 특정 비싼 계산 작업(예: 그래픽 계산 또는 인공지능 훈련)을 "보조 처리기"인 GPU에 위임해야 했기 때문입니다.

하지만 ZK 협처리기에서 "ZK"는 무엇을 의미할까요? 복잡한 기술 세부 사항을 깊이 탐구하기 전에, 이 혁신 기술의 광범위한 의미와 잠재력을 먼저 이해해 봅시다.

Web 3.0에서 데이터 기반의 dApps 필요

거래 수수료 환급은 좋은 예입니다. 이러한 사고방식에 따라, ZK 협처리기를 통해 다양한 DeFi 프로토콜에서 충성도 프로그램을 원활하게 도입할 수 있습니다.

그러나 이는 DeFi 충성도 프로그램에 국한되지 않습니다. 현재 Web 3.0의 다른 분야에서도 동일한 문제가 존재하는 것을 볼 수 있습니다. 모든 현대 Web 2.0 애플리케이션은 데이터 기반이며, Web 3.0 애플리케이션도 예외가 아닙니다. "킬러 앱"을 만들고 사용자 경험을 전통적인 인터넷 애플리케이션과 동등하게 만들기 위해서는 이러한 데이터 기반 접근 방식이 필수적입니다.

DeFi 분야의 또 다른 예를 살펴보겠습니다: 유동성 효율성을 높이기 위해 유동성 채굴 보상 메커니즘을 재설계하는 것입니다.

현재 AMM DEX의 유동성 인센티브 메커니즘은 "현금 수령" 모델을 채택하고 있습니다. 이 모델에서는 LP가 유동성을 제공할 때, Farming 보상이 즉시 LP에게 분배됩니다. 그러나 이 모델은 최선이 아닙니다. 전문 농부는 시장 변동을 감지하면 유동 자금을 신속하게 철회하여 무상 손실을 피할 수 있습니다. 이로 인해 그들이 프로토콜에 제공하는 가치는 미미하지만 여전히 상당한 보상을 받을 수 있습니다.

이상적인 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의 소셜 및 신원 확인 애플리케이션은 ZK 협처리기 지원 없이는 작동할 수 없는 또 다른 분야입니다.

블록체인 세계에서 당신의 디지털 신원은 당신의 과거 행동으로 엮인 네트워크입니다.

• NFT OG임을 증명하고 싶나요? 당신이 Cryptopunk의 원래 채굴자 중 한 명임을 증명해야 합니다.

• 자신이 대형 거래자라고 자랑하고 싶나요? DEX에서 100만 달러 이상의 거래 수수료를 지불했음을 증명하세요.

• Vitalik과 가까운 관계인가요? 그의 주소가 당신의 주소로 자금을 보냈음을 증명하세요.

체인 외 시스템, 즉 인간이나 Web 2.0 애플리케이션은 이러한 증명을 쉽게 생성할 수 있습니다. 거래량의 예와 마찬가지로, 이들은 모든 데이터를 포함하는 아카이브 노드에 접근할 수 있기 때문입니다.

이러한 직접 데이터 접근을 기반으로 한 신원 증명은 강력한 지갑 주소 연관성을 필요로 하며, 따라서 개인 정보 보호를 희생해야 하는 단점도 있지만, 이는 실행 가능합니다.

그러나 거래량의 예와 마찬가지로, 스마트 계약이 당신의 OG 신원을 믿게 하고 추가적인 신뢰 증명을 도입하지 않고 새로운 것을 먼저 경험하게 하려면, 사실상 좋은 방법이 없습니다.

ZK 협처리기를 사용하면 신뢰할 수 있는 신원 증명을 엮어낼 수 있습니다. 이는 당신의 과거 행동을 증명하는 것이며, 모든 스마트 계약이 의심 없이 수용할 수 있는 증명입니다. 당신이 다양한 애플리케이션 및 심지어 다른 블록체인에서의 상호작용을巧妙하게 통합하여 이 증명을 형성할 수 있습니다.

더 매력적인 것은 ZK固有의 개인 정보 보호입니다. 당신의 지갑 주소는 당신의 신원과 공개적으로 연관될 필요가 없습니다. 예를 들어, 당신은 Cryptopunk NFT를 소유하고 있음을 증명할 수 있지만, 구체적인 지갑 주소를 공개할 필요는 없습니다. 또는 Uniswap에서 10,000번 거래를 수행했음을 증명할 수 있지만, 구체적인 숫자는 공개하지 않을 수 있습니다.

ZK 협처리기는 데이터 기반의 dApp 구축을 위한 새로운 영역을 열어주지만, 그 의미는 그 이상입니다.

데이터 기반 패러다임을 넘어: ZK 협처리기로 Web 3.0 비동기 모드 개척

데이터 기반 dApp 모델은 매력적이지만, 이는 빙산의 일각에 불과합니다.

ZK 협처리기의 출현은 블록체인 계산에 대한 우리의 관점을 완전히 변화시킬 것이며, 비동기 처리가 Web 3.0의 표준이 되는 시대를 열 것입니다. 이러한 전환은 작업 처리 방식을 재정의하며, 전용 처리기가 독립적으로 실행되어 효율성을 높입니다.

먼저 비동기 처리란 무엇인지 이해해 봅시다.

상상해 보세요, 동기식 레스토랑에서 한 사람이 요리사와 웨이터의 역할을 동시에 수행합니다. 당신이 요리를 주문하면, 그는 요리를 준비하기 시작하고 당신을 기다리게 합니다. 그는 당신에게 요리를 서빙한 후에야 다른 손님을 응대할 수 있습니다. 이러한 설정은 당신의 요구를 충족할 수 있지만, 다른 사람들에게는 효율성을 높이기 어려울 수 있습니다.

반면 비동기 레스토랑에서는 서로 다른 요리사와 웨이터가 협력하여 작업합니다. 웨이터는 당신의 주문을 받은 후, 신속하게 주문을 요리사에게 전달하고 다른 고객에게 서비스를 제공합니다. 요리가 완료되면, 요리사는 웨이터에게 신호를 보내고, 웨이터는 즉시 당신에게 요리를 제공합니다.

컴퓨터 시스템에서:

동기 아키텍처는 첫 번째 레스토랑과 같으며, 한 사람이 각 작업이 완료된 후에야 다음 작업을 진행합니다. 이 아키텍처는 간단하고 명확하지만, 속도가 느릴 수 있습니다. 왜냐하면 한 번에 하나의 작업만 처리하기 때문입니다. 그리고 그 사람은 좋은 웨이터일 수 있지만, 좋은 요리사는 아닐 수 있습니다.

비동기 아키텍처는 두 번째 레스토랑과 같으며, 여기에는 일부 분리되고 전용 시스템 구성 요소가 있어 서로 정보를 주고받으며 작업을 조정합니다. 이는 각 구성 요소가 자신의 작업 라인을 동시에 관리할 수 있게 해줍니다. 더 복잡한 관리 방법이 필요할 수 있지만, 이 아키텍처는 더 빠르고 효율적입니다.

모든 현대 인터넷 애플리케이션은 효율성과 확장성을 높이기 위해 비동기 아키텍처를 기반으로 구축되며, 우리는 Web 3.0도 그래야 한다고 생각합니다.

ZK 협처리기는 이러한 혁신의 선구자가 될 것입니다. dApp 개발자에게 블록체인은 마치 비동기 레스토랑의 웨이터와 같습니다. 블록체인은 주로 블록체인 상태를 직접 변경하는 계산을 처리하며, 예를 들어 자산 소유권 변경과 같은 것입니다. 모든 다른 계산은 강력한 ZK 협처리기에 맡겨야 하며, 이는 요리 솜씨가 뛰어난 요리사처럼 비동기 처리의 강력한 기능을 통해 결과를 효율적으로 요리하여 웨이터에게 전달합니다.

구체적으로, 블록체인 애플리케이션 내의 계산이 다음 두 가지 "실행 조건" 중 하나를 충족하는 경우 ZK 협처리기를 사용하는 것을 고려해야 합니다.

ZK 협처리기가 실행할 수 있는 조건:

• 체인 상 계산 비용 > (체인 외 ZK 협처리기 계산(증명 생성 포함) + 체인 상 검증 비용)

• 체인 상 계산 지연 > (체인 외 ZK 협처리기 계산(증명 생성 포함) + 체인 상 검증 지연)

이 둘 중 하나라도 충족하면 고려할 가치가 있습니다!

이제 당신은 그것이 단순히 데이터 기반의 dApps가 아니라는 것을 알 수 있습니다! 그것은 ML과 같은 고수준의 범용 계산을 블록체인에 도입하는 새로운 방식이며, 더 중요한 것은 dApp을 구축하기 위해 패턴을 변화시키는 비동기 아키텍처를 도입한다는 것입니다. 이는 이전에는 전혀 가능하지 않았습니다.

다음 장….

우리가 ZK 협처리기가 깊은 영향을 미칠 아이디어라는 것을 성공적으로 설득했다면, 이제 그들이 어떻게 작동하는지에 대해 이야기할 때가 되었을 것입니다. 다음 블로그에서는 ZK 협처리기의 핵심 아키텍처를 탐구하고, 이 분야에서 여전히 존재하는 가장 큰 기술적 도전 과제에 대해 논의할 것입니다.