ABCDE 리포트: 가속기 프로세서 및 각 사의 솔루션 심층 분석

2023.12.01

ABCDE 리포트: 가속기 프로세서 및 각 사의 솔루션 심층 분석

시장에 출시된 주요 코프로세서 분야의 기술 솔루션들을 체계적으로 정리하여, 시장과 사용자들에게 코프로세서 분야에 대해 더욱 명확한 이해를 제공하고자 한다.

2023.12.01 - 03:28:11

协处理器

Web3 심층 보도에 집중하고 흐름을 통찰

글: Kris & Laobai ABCDE / Mo Dong Celer Network

최근 몇 달 동안 코프로세서 개념이 뜨거워지면서 이 새로운 ZK 사용 사례에 대한 관심도 점점 커지고 있다.

하지만 우리는 여전히 많은 사람들이 코프로세서 개념 자체에 익숙하지 않다는 것을 알게 되었으며, 특히 코프로세서의 정확한 위치 설정 — 즉 코프로세서가 무엇인지, 그리고 무엇이 아닌지 — 에 대해서는 여전히 모호하다. 게다가 시장에서 제공되는 여러 코프로세서 기술 방안들 간의 비교를 체계적으로 정리한 사례는 아직 없었다. 본 글은 시장과 사용자들에게 코프로세서 분야에 대해 보다 명확한 이해를 제공하고자 한다.

1. 코프로세서(Co-Processor)란 무엇이며, 무엇이 아닐까?

비기술 전문가나 개발자가 아닌 사람에게 코프로세서를 한 문장으로 설명하라고 한다면 어떻게 말할 것인가?

董沫 박사의 다음 표현은 아마도 가장 적절한 답에 가깝다. "코프로세서란 결국 스마트 계약에 Dune Analytics의 능력을 부여하는 것이다."

이 말을 어떻게 해석해야 할까?

Dune를 사용하는 상황을 상상해보자. Uniswap V3에서 LP로 수수료를 벌고 싶어하는 당신은 Dune를 열어 최근 Uniswap의 다양한 거래쌍에 대한 거래량, 지난 7일간의 APR 수수료율, 주요 거래쌍의 변동 범위 등을 확인한다.

또는 StepN이 유행했을 당시 신발을 사고팔며 투자했는데 언제 처분해야 할지 감을 못 잡아 매일 Dune의 StepN 데이터 — 일일 거래량, 신규 사용자 수, 신발의 플로어 가격 등을 주시하며 성장 둔화 또는 하락 신호가 나타나면 바로 팔아치우려 했다.

물론 너뿐만 아니라 Uniswap과 StepN의 개발팀도 이러한 데이터를 주시하고 있을 것이다.

이러한 데이터들은 매우 중요한 의미를 지닌다. 단순히 추세 변화를 판단하는 데 그치지 않고, 인터넷 대기업들이 자주 활용하는 '빅데이터' 전략처럼 다양한 응용이 가능하기 때문이다.

예를 들어 사용자가 자주 거래하는 신발의 스타일과 가격대에 따라 유사한 신발을 추천할 수 있다.

또는 창시자 신발(제네시스 슈즈)을 소유한 기간에 따라 '고객 충성도 보상 프로그램'을 도입하여 충성 고객에게 더 많은 에어드랍이나 혜택을 제공할 수도 있다.

Uniswap에서 LP나 트레이더가 제공하는 TVL 혹은 거래량에 따라 CEX와 유사한 VIP 제도를 만들어 트레이더에게 수수료 할인을 제공하거나 LP에게 더 높은 수수료 배당률을 제공하는 것도 가능하다.

문제는 여기서 발생한다. 인터넷 대기업이 빅데이터 + AI를 활용하는 것은 기본적으로 '블랙박스' 구조이며, 어떻게 처리되는지는 사용자가 알 수 없고, 또 신경도 쓰지 않는다.

하지만 Web3 세계에서는 투명성과 비신뢰성(trustless)이 우리의 자연스러운 정치적 정의이며, 블랙박스는 거부된다!

따라서 위 예시와 같은 시나리오를 실현하고자 할 때 두 가지 난관에 직면하게 된다. 하나는 중심화된 방법으로 구현하는 것으로, '백엔드 수동 작업'을 통해 Dune에서 인덱스 데이터를 통계 내고 이를 기반으로 실행하는 방식이다. 다른 하나는 스마트 계약을 작성하여 체인 외부에서 자동으로 데이터를 수집하고 계산한 후 자동으로 실행하는 방식이다.

전자의 경우 '정치적으로 올바르지 못한' 신뢰 문제에 빠진다.

후자의 경우 체인 상에서 발생하는 가스 비용이 천문학적인 수준이 되며, (프로젝트 팀의) 지갑으로 감당할 수 없다.

이때 등장하는 것이 바로 코프로세서다. 위 두 가지 방법을 결합하면서 동시에 '백엔드 수동 작업'이라는 단계를 기술적으로 '자기 스스로 무결함을 입증(self-proving)'하는 것이다. 즉, ZK 기술을 이용해 체인 외부의 '인덱싱 + 계산' 과정을 '무결함임을 입증'한 후 이를 스마트 계약에 공급하는 것이다. 이렇게 되면 신뢰 문제는 해결되며 막대한 가스 비용도 사라진다. 완벽하다!

왜 '코프로세서(co-processor)'라고 부를까? 사실 이것은 Web2.0 발전 역사 속에서 등장한 'GPU'에서 유래된 개념이다. GPU가 CPU와 별개의 독립된 컴퓨팅 하드웨어로 도입된 이유는 대규모 병렬 반복 계산, 그래픽 처리 등 CPU가 근본적으로 처리하기 어려운 작업들을 효과적으로 수행할 수 있는 설계 구조를 갖추고 있었기 때문이다. 이러한 '코프로세서' 아키텍처 덕분에 오늘날 우리는 멋진 CG 영화, 게임, AI 모델 등을 즐길 수 있게 되었다. 이는 컴퓨터 시스템 아키텍처의 한 차원 높은 도약이었다고 볼 수 있다. 현재 각 코프로세서 팀들도 이러한 아키텍처를 Web3.0에 도입하려 하고 있으며, 여기서 블록체인은 마치 Web3.0의 CPU와 같다고 볼 수 있다. L1이든 L2든 간에 모두 '대량 데이터' 및 '복잡한 계산 로직' 작업에는 본질적으로 부적합하다. 따라서 이러한 계산을 처리할 수 있도록 블록체인 코프로세서를 도입함으로써 블록체인 애플리케이션의 가능성을 극대화하려는 것이다.

요약하면 코프로세서가 하는 일은 크게 두 가지다:

블록체인에서 데이터를 가져오고, 내가 가져온 데이터가 조작되지 않았음을 ZK 증명으로 입증한다.
앞서 가져온 데이터를 기반으로 계산을 수행하고, 그 결과 역시 조작되지 않았음을 다시 한번 ZK 증명으로 입증한다. 이후 이 계산 결과는 스마트 계약에서 '낮은 비용 + 비신뢰(trustless)' 방식으로 호출될 수 있다.

최근 Starkware 측에서 화제가 된 'Storage Proof'(저장 증명), 또는 State Proof(상태 증명)라는 개념이 있는데, 이는 위 과정 중 1단계에 해당한다. Herodotus, Lagrange 등이 대표적이며, 많은 ZK 기반 크로스체인 브릿지 기술들도 1단계에 초점을 맞추고 있다.

코프로세서는 단지 1단계 이후에 2단계를 추가한 것으로, 신뢰 없는 방식으로 데이터를 추출한 후 신뢰 없는 방식으로 계산을 수행하는 것뿐이다.

따라서 다소 기술적인 용어로 정확히 표현하자면, 코프로세서는 Storage Proof/State Proof의 상위 집합(super set)이며, Verifiable Computation(검증 가능한 계산)의 하위 집합(subset)이라고 볼 수 있다.

주의할 점은, 코프로세서는 롤업(Rollup)이 아니라는 것이다.

기술적으로 보면, 롤업의 ZK 증명은 위의 2단계와 유사하지만, 1단계인 '데이터 가져오기' 과정은 Sequencer가 직접 수행한다. 비록 탈중앙화된 Sequencer라 하더라도 어떤 경쟁 혹은 합의 메커니즘을 통해 데이터를 가져올 뿐, Storage Proof처럼 ZK 형태로 가져오는 것은 아니다. 더 중요한 점은, ZK 롤업은 계층 외에도 L1 블록체인과 유사한 저장 계층을 구현해야 하며, 이 저장소는 영구적으로 존재한다. 반면 ZK 코프로세서는 '무상태(stateless)'이며, 계산을 완료한 후 상태를 모두 유지할 필요가 없다.

응용 측면에서 보면, 코프로세서는 모든 L1/L2의 서비스형 플러그인으로 볼 수 있고, 롤업은 새로운 실행 계층을 새로 구축하여 정산 계층의 확장을 돕는다.

2. 반드시 ZK를 써야 하나? OP는 안 되나?

위 내용을 읽고 나면 의문이 생길 수 있다. 코프로세서는 반드시 ZK를 써야만 하는가? 듣기에 뭔가 'ZK를 붙인 The Graph'처럼 들린다. 그런데 우리는 일반적으로 The Graph의 결과에 대해 큰 의심을 하지 않는 것 같다.

그렇게 말하는 이유는 우리가 평소 The Graph를 사용할 때 거의 실제 자금과 연결되지 않기 때문이다. 이러한 인덱스들은 대부분 오프체인 서비스를 위한 것이며, 프론트엔드 UI에서 보는 거래량, 거래 기록 등의 데이터는 Graph, Alchemy, Zettablock 등 여러 데이터 인덱스 제공업체를 통해 제공받는다. 하지만 이런 데이터를 스마트 계약 안으로 다시 넣을 수는 없다. 왜냐하면 그렇게 되면 해당 인덱스 서비스에 대한 추가적인 신뢰를 요구하게 되기 때문이다. 데이터가 실제 자금, 특히 큰 규모의 TVL과 연동될 때 이러한 추가적인 신뢰는 중요해진다. 친구가 100원을 빌려달라고 하면 눈 깜짝 안 하고 줄 수 있지만, 1만 원, 혹은 100만 원을 빌려달라고 하면 이야기가 달라진다.

다만 그렇다고 해서 코프로세서의 모든 시나리오에 정말 반드시 ZK가 필요한가? 롤업에서도 OP와 ZK라는 두 가지 기술 경로가 있듯이, 최근 유행하는 ZKML에도 OPML이라는 대안 개념이 등장했다. 그렇다면 코프로세서에도 OP 기반의 경로, 예를 들어 OP-Coprocessor라는 것이 존재할 수 있지 않을까?

사실 그런 것도 존재한다 — 다만 여기서는 구체적인 세부 정보를 비공개로 남겨두겠다. 곧 더 자세한 정보를 발표할 예정이다.

3. 코프로세서 어디가 제일 강한가? — 주요 코프로세서 기술 방안 비교

Brevis

Brevis 아키텍처는 세 가지 구성 요소로 이루어져 있다: zkFabric, zkQueryNet, zkAggregatorRollup.

다음은 Brevis의 아키텍처도다:

zkFabric: 연결된 모든 블록체인에서 블록헤더를 수집하고, 이 블록헤더들의 유효성을 증명하는 ZK 합의 증명을 생성한다. zkFabric을 통해 Brevis는 멀티체인 상호운용성이 가능한 코프로세서를 실현하였으며, 이를 통해 하나의 블록체인이 다른 블록체인의 임의의 과거 데이터에 접근할 수 있게 된다.

zkQueryNet: dApp로부터 데이터 조회 요청을 받아 처리하는 개방형 ZK 쿼리 엔진 마켓플레이스다. 이 엔진들은 zkFabric에서 검증된 블록헤더를 사용해 쿼리를 처리하고, ZK 쿼리 증명을 생성한다. 고도로 특화된 기능부터 일반적인 쿼리 언어까지 다양한 애플리케이션 요구에 대응할 수 있다.

zkAggregatorRollup: zkFabric과 zkQueryNet의 증명을 검증하고, 검증된 데이터를 저장하며, 이들의 ZK 검증된 상태 루트를 모든 연결된 블록체인에 제출하는 ZK 롤업 블록체인이다. 즉, 두 구성 요소의 집계 및 저장 계층 역할을 한다.

zkFabric은 블록헤더에 대한 증명을 생성하는 핵심 구성 요소로서, 이 부분의 보안은 매우 중요하다. 아래는 zkFabric의 아키텍처도다:

zkFabric은 제로지식 증명(ZKP) 기반의 경량 클라이언트(light client)로서, 외부 검증 실체에 전혀 의존하지 않기 때문에 완전히 신뢰 불필요(trustless)하다. 그 보안성은 오직 기반 블록체인과 수학적으로 신뢰할 수 있는 증명에 기반한다.

zkFabric Prover 네트워크는 각 블록체인의 lightclient 프로토콜을 회로(circuit) 형태로 구현하며, 블록헤더에 대한 유효성 증명을 생성한다. 증명자는 GPU, FPGA, ASIC 등의 가속기를 활용해 증명 시간과 비용을 최소화할 수 있다.

zkFabric은 기반 블록체인과 기반 암호화 프로토콜의 보안 가정에 의존한다. 그러나 zkFabric의 유효성을 보장하기 위해서는 적어도 하나의 정직한 리레이어(relayer)가 올바른 포크를 동기화하고 있어야 한다. 따라서 Brevis는 단일 리레이어 대신 탈중앙화된 리레이어 네트워크를 사용하여 zkFabric의 유효성을 최적화한다. 이 리레이어 네트워크는 기존 구조(예: Celer 네트워크의 상태 감시 네트워크)를 활용할 수 있다.

현재 배포 현황:

현재 이더리움 PoS, Cosmos Tendermint, BNB 체인 등 다양한 블록체인에 대해 경량 클라이언트 프로토콜을 구현하여 샘플 및 개념 검증용으로 제공하고 있다.

Brevis는 현재 Uniswap hook과 협력하고 있다. hook은 사용자가 Uniswap 풀을 자유롭게 커스터마이징할 수 있게 해주지만, CEX에 비해 거래량 기반의 충성도 프로그램 등 대규모 사용자 거래 데이터를 활용한 기능을 만들기 위한 데이터 처리 기능이 부족하다.

Brevis의 도움으로 hook은 이 문제를 해결하였다. 이제 hook은 사용자나 LP의 전체 과거 체인 데이터를 읽어들이고, 완전히 신뢰 불필요한 방식으로 사용자 정의 계산을 실행할 수 있게 되었다.

Herodotus

Herodotus는 강력한 데이터 접근 미들웨어로서, 스마트 계약이 이더리움 계층 간에 현재 및 과거 체인 데이터에 동기적으로 접근할 수 있도록 지원한다:

L2에서 L1 상태
L1 및 다른 L2에서 L2 상태
L3/앱체인에서 L2 및 L1 상태

Herodotus는 '스토리지 프루프(Storage Proof)'라는 개념을 제안한다. 이는 포함 증명(데이터 존재 확인)과 계산 증명(다단계 워크플로 실행 검증)을 결합하여, 전체 이더리움 블록체인 또는 롤업과 같은 대규모 데이터셋 내 하나 이상의 요소의 유효성을 증명한다.

블록체인의 핵심은 Merkle 트리, Merkle Patricia 트리 등의 데이터 구조로 암호화 보호된 데이터베이스다. 이러한 구조의 특징은 일단 데이터가 안전하게 기록되면, 해당 데이터가 구조 내에 포함되어 있다는 증거를 생성할 수 있다는 점이다.

Merkle 트리와 Merkle Patricia 트리는 이더리움 블록체인의 보안을 강화한다. 트리의 각 레벨에서 데이터를 암호학적 해시로 처리함으로써, 데이터를 조작하는 것이 거의 불가능해진다. 데이터 포인트의 변경은 해당 트리의 해시값에서 루트 해시값까지 모두 변경해야 하며, 이는 블록체인 헤더에서 공개적으로 확인할 수 있다. 이러한 기본 특성은 높은 수준의 데이터 무결성과 불변성을 제공한다.

또한 이러한 트리는 포함 증명을 통해 효율적으로 데이터를 검증할 수 있다. 예를 들어 거래 포함 여부나 계약 상태를 검증할 때 전체 이더리움 블록체인을 검색할 필요 없이 관련 Merkle 트리 내 경로만 검증하면 된다.

Herodotus가 정의한 스토리지 프루프는 다음과 같은 요소를 통합한 것이다:

포함 증명: Merkle 트리나 Merkle Patricia 트리와 같은 암호화된 데이터 구조 내 특정 데이터의 존재를 확인하여, 관련 데이터가 실제로 데이터셋에 존재함을 보장한다.
계산 증명: 다단계 워크플로의 실행을 검증하며, 전체 이더리움 블록체인 또는 롤업과 같은 광범위한 데이터셋 내 하나 이상의 요소의 유효성을 증명한다. 단순히 데이터 존재 여부뿐 아니라, 해당 데이터에 적용된 변환 또는 연산도 검증한다.
제로지식 증명: 스마트 계약이 상호작용해야 하는 데이터 양을 줄여준다. 제로지식 증명을 통해 스마트 계약은 기초 데이터 전체를 처리하지 않고도 주장의 유효성을 확인할 수 있다.

워크플로우(Workflow):

1. 블록 해시 획득

블록체인의 모든 데이터는 특정 블록에 속한다. 블록 해시는 해당 블록의 고유 식별자로서, 블록헤더를 통해 모든 내용을 요약한다. 스토리지 프루프 워크플로에서 먼저 관심 있는 데이터가 포함된 블록의 블록 해시를 결정하고 검증하는 것이 첫 번째 단계다.

2. 블록헤더 획득

관련 블록 해시를 획득한 후, 다음 단계는 블록헤더에 접근하는 것이다. 이를 위해 이전 단계에서 얻은 블록 해시와 연관된 블록헤더를 해싱한 후, 제공된 블록헤더의 해시값과 산출된 블록 해시값을 비교한다:

블록 해시를 얻는 방법은 두 가지다:

(1) BLOCKHASH opcode를 사용하여 검색

(2) Block Hash Accumulator에서 이미 검증된 과거 블록의 해시를 조회

이 단계를 통해 처리 중인 블록헤더가 진짜임을 보장한다. 이 단계가 완료되면 스마트 계약은 블록헤더 내 임의의 값을 접근할 수 있다.

3. 필요한 루트 결정 (선택사항)

블록헤더를 확보하면 그 내용을 더 깊이 파고들 수 있다. 특히 다음 항목들에 주목한다:

stateRoot: 블록 생성 시점의 전체 블록체인 상태의 암호학적 요약.

receiptsRoot: 블록 내 모든 거래 결과(영수증)의 암호학적 요약.

transactionsRoot: 블록 내 발생한 모든 거래의 암호학적 요약.

이 루트들은 디코딩이 가능하여, 블록 내 특정 계정, 영수증 또는 거래가 포함되었는지 확인할 수 있다.

4. 선택한 루트 기반 데이터 검증 (선택사항)

선택한 루트와 함께 이더리움이 Merkle-Patricia Trie 구조를 사용한다는 점을 고려하면, Merkle 포함 증명을 활용해 트리 내 데이터 존재 여부를 검증할 수 있다. 검증 단계는 데이터 종류와 블록 내 데이터의 깊이에 따라 달라진다.

현재 지원하는 네트워크:

이더리움 → 스타크넷
이더리움 Goerli* → 스타크넷 Goerli*
이더리움 Goerli* → zkSync Era Goerli*

Axiom

Axiom은 개발자가 이더리움의 전체 역사에서 블록헤더, 계정 또는 저장값을 조회할 수 있는 방법을 제공한다. Axiom은 암호학적 연결 기반의 새로운 접근법을 도입하였으며, Axiom이 반환하는 모든 결과는 체인 상에서 제로지식 증명을 통해 검증되므로, 스마트 계약은 추가적인 신뢰 가정 없이도 이를 사용할 수 있다.

Axiom은 최근 Halo2-repl을 출시했다. 이는 브라우저 기반의 JavaScript로 작성된 halo2 REPL로, 개발자가 Rust와 같은 새로운 언어를 배우거나, 증명 라이브러리를 설치하거나, 의존성 문제를 처리하지 않고도 표준 JavaScript만으로 ZK 회로를 작성할 수 있게 해준다.

Axiom은 두 가지 주요 기술 구성 요소로 이루어져 있다:

AxiomV1 — 창세 블록부터 시작하는 이더리움 블록체인 캐시.
AxiomV1Query — AxiomV1에 대한 쿼리를 실행하는 스마트 계약.

(1) AxiomV1에서 블록 해시 캐싱:

AxiomV1 스마트 계약은 창세 블록 이후의 이더리움 블록 해시를 두 가지 형태로 캐싱한다:

첫째, 연속된 1024개 블록 해시의 Keccak Merkle 루트를 캐싱한다. 이러한 Merkle 루트는 ZK 증명을 통해 업데이트되며, 블록헤더 해시가 EVM에서 직접 접근 가능한 최근 256개 블록 중 하나이거나 AxiomV1 캐시에 이미 존재하는 블록 해시로 끝나는 커밋 체인을 형성하는지를 검증한다.

둘째, Axiom은 창세 블록부터 시작하여 이러한 Merkle 루트들의 Merkle Mountain Range(MMR)를 저장한다. 이 MMR은 체인 상에서 구축되며, 캐시의 첫 번째 부분인 Keccak Merkle 루트를 업데이트함으로써 형성된다.

(2) AxiomV1Query에서 쿼리 처리:

AxiomV1Query 스마트 계약은 일괄 쿼리를 통해 과거 이더리움 블록헤더, 계정 및 계정 저장소에 대한 임의의 데이터에 신뢰 없이 접근할 수 있도록 한다. 쿼리는 체인 상에서 수행되며, AxiomV1 캐시의 블록 해시에 대한 ZK 증명을 통해 체인 상에서 완료된다.

이러한 ZK 증명은 관련 체인 상 데이터가 블록헤더에 직접 위치하는지, 혹은 블록의 계정 또는 저장 Trie 내에 위치하는지를 확인하며, Merkle-Patricia Trie의 포함(또는 불포함) 증명을 검증함으로써 이를 수행한다.

Nexus

Nexus는 제로지식 증명을 활용해 검증 가능한 클라우드 컴퓨팅을 위한 일반 플랫폼을 구축하고자 한다. 현재는 machine architecture에 독립적이며, RISC-V, WebAssembly, EVM을 모두 지원한다. Nexus는 Supernova 증명 시스템을 활용하며, 팀의 테스트 결과 증명 생성에 필요한 메모리는 6GB이며, 향후 일반 사용자 장비에서도 증명을 생성할 수 있도록 최적화할 예정이다.

정확히 말하면, 아키텍처는 두 부분으로 나뉜다: