Babylon | BABE가 만드는 ZK 검증 구조

Babylon | BABE가 만드는 ZK 검증 구조

비트코인을 담보로 스테이블코인을 빌린 뒤 대출금을 모두 상환했다고 가정해 보겠습니다.

Ethereum의 대출 스마트컨트랙트는 사용자가 빚을 모두 갚았다는 사실을 알고 있습니다. 하지만 담보로 설정된 BTC는 Ethereum이 아니라 Bitcoin 네트워크의 UTXO에 잠겨 있습니다. 그렇다면 Bitcoin은 Ethereum에서 발생한 상환을 어떻게 확인하고 BTC를 다시 사용자에게 돌려줄 수 있을까요?

Babylon의 Trustless Bitcoin Vaults, 즉 TBV가 해결해야 하는 핵심 문제도 여기에 있습니다. 사용자의 BTC를 브리지나 수탁기관에 넘기지 않으면서 다른 체인의 금융 상태에 따라 잠금과 상환, 청산을 처리하려면 서로 다른 두 블록체인 사이의 상태를 암호학적으로 연결해야 합니다. Babylon이 UC Berkeley 연구진과 함께 개발한 BABE는 이 연결을 가능하게 하는 증명 검증 프로토콜입니다.

Bitcoin은 Ethereum의 상태를 직접 읽을 수 없다

Ethereum은 스마트컨트랙트를 이용해 대출금과 담보 가치, 이자, 상환 여부, 청산 조건 등을 계산할 수 있습니다. 반면 Bitcoin Script는 의도적으로 제한된 프로그래밍 기능만 제공합니다.

이러한 구조는 Bitcoin을 단순하고 안정적으로 유지하는 데 도움이 되지만, Ethereum 스마트컨트랙트의 상태를 직접 조회하거나 복잡한 프로그램을 실행하기는 어렵게 만듭니다.

기존에는 이 문제를 해결하기 위해 사용자의 BTC를 수탁기관에 맡기고, Ethereum에서 해당 BTC를 나타내는 wrapped token을 발행하는 방식이 주로 사용됐습니다. 그러나 이 구조에서는 원본 BTC를 관리하는 기관이나 브리지의 보안과 지급 능력을 신뢰해야 합니다. Babylon의 TBV는 BTC를 Bitcoin 네트워크에 둔 상태에서 이러한 중간자를 암호학적 검증 구조로 대체하려 합니다.

TBV에서 사용자의 BTC는 Bitcoin의 Taproot Script에 잠기며, Ethereum의 프로토콜 컨트랙트에는 해당 Vault를 추적하는 기록이 생성됩니다. 이 기록은 DeFi 애플리케이션에서 BTC를 담보로 사용할 수 있게 하지만, 실제 BTC 자체가 Ethereum으로 이동하는 것은 아닙니다.

문제는 상환이나 청산이 발생했을 때입니다. Bitcoin이 어떤 주소로 BTC를 보내야 하는지 결정하려면 Ethereum에서 실제로 어떤 일이 일어났는지 확인할 수 있어야 합니다.

ZK 증명으로 다른 체인의 결과를 압축한다

Babylon은 Ethereum 스마트컨트랙트에서 발생한 상태 전환을 SNARK 증명으로 압축합니다.

SNARK는 복잡한 계산을 처음부터 모두 다시 실행하지 않고도, 특정 계산이 정해진 규칙에 따라 올바르게 수행됐다는 사실을 짧은 증명으로 확인할 수 있게 합니다. TBV에서는 Groth16이라는 SNARK 방식을 활용해 대출 상환이나 청산처럼 BTC의 최종 소유권에 영향을 주는 Ethereum 상태 변화를 증명합니다.

예를 들어 사용자가 대출금을 모두 갚았다면, Ethereum에서 상환 이벤트가 정상적으로 처리됐다는 증명을 생성할 수 있습니다. 문제는 증명을 만드는 것만으로 끝나지 않는다는 점입니다.

어딘가에서는 해당 증명이 정말 유효한지 검증해야 합니다. Ethereum에서는 스마트컨트랙트가 이를 처리할 수 있지만, 제한적인 Bitcoin Script에서 Groth16 검증을 그대로 실행하는 것은 어렵습니다.

따라서 핵심은 복잡한 ZK 검증을 Bitcoin이 이해할 수 있는 단순한 조건으로 변환하는 것입니다.

BitVM3는 온체인 비용을 낮췄지만 새로운 병목을 만들었다

Bitcoin에서 복잡한 계산을 검증하기 위한 대표적인 연구 흐름 중 하나가 BitVM 계열입니다.

BABE 논문에 따르면 BitVM2는 분쟁이 발생하는 이른바 ‘불행 경로’에서 Bitcoin 온체인 수수료가 매우 커질 수 있습니다. 논문이 언급한 최근 실험에서는 해당 비용이 1만4천 달러를 넘었습니다.

이후 제안된 BitVM3는 SNARK 검증기의 상당 부분을 오프체인으로 옮기고, garbled circuit을 활용해 Bitcoin 온체인 비용을 크게 낮췄습니다.

하지만 이번에는 오프체인 저장과 초기 설정이 병목이 됐습니다. BitVM3에서 사용되는 garbled SNARK verifier circuit 하나의 크기가 약 42GiB에 달했기 때문입니다. 참여자가 여러 검증 회로를 보관하고 준비해야 한다면 일반적인 사용자나 운영자가 감당하기 어려운 수준이 될 수 있습니다.

즉, BitVM3는 Bitcoin에 직접 기록되는 비용을 줄였지만 그 부담의 상당 부분을 오프체인 저장공간과 설정 과정으로 옮겼습니다.

BABE는 오프체인 저장과 설정 비용을 약 1,000배 줄인다

BABE는 BitVM3가 달성한 낮은 온체인 비용을 유지하면서, 오프체인 저장과 설정 비용을 세 자릿수 규모, 즉 약 1,000배 줄이는 것을 목표로 합니다.

Babylon은 분기별 Founders Call 자료에서 이를 약 1,000배 작은 저장공간과 약 1,000배 빠른 설정 과정으로 설명했습니다. 기존에 수 시간 걸릴 수 있던 준비 과정을 수분 또는 수초 단위로 줄여, 초대형 컴퓨팅 환경이 아닌 일반적인 참여자도 운영할 수 있는 수준으로 만드는 것이 목표입니다.

기술적으로 BABE는 Groth16 검증에 필요한 모든 연산을 하나의 거대한 garbled circuit에 넣는 대신, 선형 pairing 관계를 위한 witness encryption 구조를 활용합니다. Groth16 검증에 포함되는 비선형 연산은 효율적인 two-party computation과 타원곡선 스칼라 곱셈용 garbled circuit으로 보완합니다.

쉽게 말하면, ZK 검증 전체를 거대한 하나의 회로로 처리하지 않고 연산의 성격에 따라 더 효율적인 암호기술을 조합한 것입니다. 이를 통해 Bitcoin에 남기는 정보뿐 아니라 오프체인에서 준비해야 하는 데이터의 크기도 크게 줄입니다.

BABE라는 이름은 Babylon의 ‘BA’와 Berkeley의 ‘BE’를 결합한 표현으로 소개됐습니다.

증명은 Bitcoin이 이해할 수 있는 ‘비밀 값’으로 변환된다

TBV의 전체 구조를 이해하려면 garbled circuit의 역할을 살펴볼 필요가 있습니다.

Babylon은 Groth16 증명 검증 결과를 Bitcoin이 처리할 수 있는 단순한 비밀 값의 공개로 변환합니다. 증명이 유효하면 정해진 secret label이 공개되고, Bitcoin Script의 hash lock은 해당 값이 공개됐는지를 기준으로 특정 BTC 지출 경로를 허용합니다.

여기에는 Lamport 일회성 서명과 time lock, Taproot의 여러 지출 경로도 함께 사용됩니다.

Lamport 서명은 분쟁이 발생했을 때 검증 입력이 조작되지 않았는지 Bitcoin Script가 확인할 수 있게 합니다. Time lock은 다른 참여자가 잘못된 인출 요청에 이의를 제기할 시간을 제공하며, Taproot는 하나의 UTXO에 상환·청산·만료처럼 여러 지출 조건을 미리 설정할 수 있게 합니다.

결과적으로 Ethereum의 복잡한 스마트컨트랙트 실행은 ZK 증명으로 압축되고, BABE를 거쳐 Bitcoin Script가 확인할 수 있는 조건으로 번역됩니다.

상환이 발생하면 BTC는 어떻게 해제될까?

TBV를 이용한 대출 흐름은 다음과 같이 볼 수 있습니다.

먼저 사용자는 자신의 BTC를 Bitcoin의 Taproot Script에 잠급니다. 해당 Vault는 하나의 Bitcoin UTXO로 분리돼 있으며, Ethereum에는 이 Vault와 연결된 담보 기록이 생성됩니다. 사용자는 이 기록을 기반으로 Aave 같은 DeFi 애플리케이션에서 스테이블코인이나 다른 자산을 빌릴 수 있습니다.

이후 사용자가 대출금을 상환하면 Ethereum에서 상환 이벤트가 발생합니다. 해당 이벤트를 근거로 Groth16 증명이 생성되고, Vault에서 BTC를 인출하려는 참여자는 정해진 지출 경로에 따라 인출을 요청합니다.

모든 인출 요청은 도전받을 수 있습니다. 누군가 잘못된 상환이나 청산 결과를 주장한다면 Challenger가 이의를 제기할 수 있으며, 분쟁이 발생했을 때 유효한 ZK 증명을 제시할 수 있는지가 BTC 인출 여부를 결정합니다.

Babylon의 현재 문서는 이 과정을 BABE 기반 challenge procedure로 설명합니다. Bitcoin은 기존 Bitcoin Script 기능만으로 Ethereum의 상환 이벤트에 대한 증명을 확인하며, 이를 위해 Bitcoin 네트워크를 포크하거나 새로운 opcode를 추가할 필요가 없습니다.

모든 계산이 Bitcoin 위에서 실행되는 것은 아니다

BABE가 Bitcoin을 Ethereum과 같은 범용 스마트컨트랙트 플랫폼으로 바꾸는 것은 아닙니다.

SNARK 생성과 garbled circuit 설정·평가처럼 복잡한 계산과 통신 대부분은 오프체인에서 이뤄집니다. Bitcoin에는 데이터와 서명에 대한 commitment, 분쟁 시 필요한 입력, 최종적인 secret revelation 등 핵심 정보만 기록됩니다.

또한 Vault를 만든 뒤 누구나 임의로 BTC를 가져갈 수 있는 구조도 아닙니다. 정당하게 인출을 요청할 수 있는 주소와 Challenger는 Vault 생성 시 미리 정해져야 하며, 설정된 지출 경로는 이후 자유롭게 변경되지 않습니다.

분쟁 가능성을 열어두기 때문에 인출도 즉시 완료되지는 않습니다. Babylon의 기술 설명에 따르면 Challenger가 잘못된 요청을 발견할 수 있도록 수 시간에서 1~2일가량의 configurable challenge period가 필요할 수 있습니다.

따라서 BABE는 무제한적인 크로스체인 실행을 제공하는 기술이라기보다, 미리 정의된 Bitcoin 지출 조건을 다른 체인의 검증 가능한 이벤트와 연결하는 기술에 가깝습니다.

신뢰가 사라지는 것이 아니라 신뢰의 대상이 바뀐다

TBV는 “아무것도 믿지 않아도 되는 시스템”은 아닙니다.

사용자는 Bitcoin과 Ethereum 네트워크, TBV에 통합된 DeFi 애플리케이션의 스마트컨트랙트, 그리고 BABE를 포함한 암호학적 검증 구조가 올바르게 작동한다고 가정해야 합니다. 다만 원본 BTC를 보유한 수탁기관이나 브리지 운영자의 지급 능력과 재무 상태를 신뢰할 필요는 줄어듭니다.

Babylon은 이를 신뢰가 수탁기관의 건전성에서 계산과 암호기술로 이동하는 구조라고 설명합니다.

BTC는 사용자의 Vault별로 분리된 UTXO에 남고, 다른 사용자와 하나의 담보 풀로 합쳐지지 않습니다. 또한 미리 설정된 Script가 허용하지 않는 방식으로 담보를 다른 곳에 빌려주거나 재담보화할 수 없습니다.

BABE가 만드는 것은 ‘증명 가능한 Bitcoin 담보’다

Babylon은 TBV의 첫 번째 활용 분야로 Bitcoin 담보 대출을 추진하고 있습니다. 이후 같은 담보 인프라를 바탕으로 BTC 담보 스테이블코인과 보험, 옵션·파생상품 등으로 확장하는 방향도 제시했습니다.

하지만 이러한 금융상품이 가능하려면 먼저 Bitcoin이 다른 체인의 결과에 따라 담보를 안전하게 이동시킬 수 있어야 합니다.

BABE의 의미도 여기에 있습니다. 더 복잡한 DeFi 기능을 Bitcoin 안에 직접 구현하는 것이 아니라, 다른 체인에서 실행된 결과가 올바르다는 사실을 Bitcoin이 확인할 수 있는 형태로 바꿉니다.

Bitcoin은 Ethereum의 스마트컨트랙트를 직접 읽지 않습니다. 대신 BABE를 통해 상환과 청산의 결과가 올바르다는 암호학적 증명을 확인하고, 미리 정해진 Script에 따라 BTC의 다음 소유자를 결정합니다.

42GiB에 달하던 기존 검증 회로의 오프체인 부담을 약 1,000배 줄인 BABE는, 연구 단계의 ZK 검증을 실제 Bitcoin 담보 제품에 적용하기 위한 Babylon의 핵심 기술적 연결고리입니다.