BTC 담보 금고: 수탁자 없이 에이전트가 의무 이행을 위해 네이티브 비트코인을 예치하는 방법

대부분의 "DeFi에서의 비트코인" 이야기는 수탁자(custodian)나 래핑된 표현(wrapped representation)을 통해 조용히 처리됩니다. 당신은 BTC를 어딘가로 보내고, 누군가(또는 어떤 브릿지 멀티시그(multisig))가 이를 보유하며, 당신은 다른 체인에서 IOU(채무 증서)를 받습니다. 이는 당신의 BTC를 보유하고 있는 주체가 실패하기 전까지는 작동합니다. 스스로 관리할 수 없는 의무(obligation)에 대해 담보를 제공해야 하는 자율 에이전트(autonomous agent)에게 "수탁자를 신뢰하라"는 것은 우리가 제거하려고 노력하는 바로 그 가정입니다.

이 포스트는 대안에 대해 다룹니다: 네이티브 비트코인이 다른 체인의 의무를 뒷받침하고, 해시락(hashlock)에 의해 해제가 제어되며, 최악의 경우 손실이 아닌 환불이 발생하는 **BTC 담보 금고(BTC collateral vault)**입니다. 이는 Hashlock의 결제 레이어(settlement layer) 아래에 있는 기본 요소(primitives) 중 하나입니다. 저는 이것을 안전하게 만드는 타임락(timelock) 순서, 이를 강제하는 비트코인 스크립트(Bitcoin script), 그리고 이를 바탕으로 설계해야 하는 실패 모드(failure modes)에 대해 설명하겠습니다. 솔직한 상태를 먼저 말씀드리자면, 이것은 BTC 메인넷이 아닌 시그넷(signet)에서 검증되었습니다.

한 문장으로 요약한 문제

에이전트가 이더리움(Ethereum) 상의 동작(선물 결제, 다각 거래의 한 축 고정, 지급 보장 등)을 뒷받침하는 담보로 BTC를 약정하고자 합니다. 이때 BTC는 이더리움 상의 해당 의무가 이행될 경우에만 상대방에게 해제되어야 하며, 이행되지 않을 경우 소유자에게 반환되어야 합니다. 그 과정에서 어떤 제3자도 BTC를 보유, 동결 또는 횡령할 수 없어야 합니다.

이것은 크로스체인 조건부(cross-chain conditional)입니다. 비트코인은 이더리움의 상태(state)를 읽을 수 없고, 이더리움은 비트코인의 상태를 읽을 수 없습니다. 두 체인이 독립적으로 검증할 수 있는 유일한 것은 해시 프리이미지(hash preimage)뿐입니다. 따라서 전체 구조는 하나의 공유된 비밀(shared secret)에 달려 있습니다.

공유된 비밀, 그리고 타임락(timelock) '순서'가 핵심인 이유

양쪽의 거래(legs)는 모두 동일한 해시 H = SHA256(s)에 잠깁니다. 프리이미지 s를 아는 사람은 누구든 청구할 수 있습니다. 한 체인에서 코인을 청구하기 위해 s가 공개되는 즉시 그것은 공개 정보가 되며, 상대방은 다른 코인을 청구하기 위해 이를 복사합니다. 이것이 원자적(atomic)인 부분입니다: 하나의 프리이미지가 양쪽 거래를 모두 해제하거나, 혹은 둘 다 해제하지 못하게 합니다.

위험 요소는 해시(hash)가 아닙니다. 바로 _시간(time)_입니다. 만약 양쪽 거래의 만료 시간이 동일하다면, 비밀(secret)을 알고 있는 당사자가 마지막 블록이 나올 때까지 기다렸다가 상대방의 자산을 가로채고, 상대방이 되찾아올 시간적 여유를 주지 않을 수 있습니다. 해결책은 비대칭 타임락(asymmetric timelocks)이며, 방향을 올바르게 설정하는 것이 전체 설계에서 가장 중요한 결정입니다.

규칙: 비밀을 알고 있는 당사자가 더 긴 타임락(timelock)을 가져갑니다.

Alice가 BTC 담보를 예치하고 Bob이 ETH를 잠그는 과정을 살펴보겠습니다:

Alice는 비밀 s를 선택하고 H를 계산합니다. 그녀는 BTC 금고(vault) 출력을 자금화하며, 이는 Bob이 s를 제시하면 사용할 수 있고, T_A = 48h 이후에는 Alice에게 환불됩니다.
Bob은 온체인(on-chain) 상에서 H에 잠겨 있는 BTC 금고를 확인하고, ETH 측 HTLC(Hashed Timelock Contract)에 자금을 공급합니다. 이는 Alice가 s를 제시하면 청구할 수 있고, T_B = 24h 이후에는 Bob에게 환불됩니다. 여기서 T_B < T_A임에 유의하세요.
Alice는 Ethereum 상에서 s를 공개함으로써 ETH를 청구합니다. 그녀는 반드시 24시간이 지나기 전에 이를 수행해야 합니다.
Alice의 청구가 완료되는 순간, s는 공개된 Ethereum 트랜잭션에 포함됩니다. Bob은 이를 읽고 이를 사용하여 BTC를 청구하며, 자신의 트랜잭션이 채굴될 수 있도록 최대 48시간까지의 충분한 시간적 여유를 가집니다.

만약 Alice가 비밀을 공개하지 않는다면, 양쪽 거래 모두 환불됩니다. Bob은 24시간 후에, Alice는 48시간 후에 환불받습니다. 아무도 자산이 묶이지 않습니다. 24시간의 격차는 Alice가 비밀 공개를 강제한 후 Bob이 항상 대응할 수 있는 여유(slack)를 갖도록 하기 위해 정확히 존재합니다. 타임락을 뒤집으면 비밀 소유자에게 공짜 옵션(free option)을 주는 셈이 됩니다. 즉, 그들은 당신의 자산을 청구하고 당신의 자산은 만료되도록 내버려 둘 수 있습니다. 이것이 전형적인 아토믹 스왑(atomic-swap)의 안전성 논거이며, 담보 금고(collateral vault) 또한 BTC 측을 즉시 스왑하는 대신 포지션 증거금(posted margin)으로서 더 길게 열어두는 동일한 논리를 따릅니다.

Bitcoin 측의 실제 모습

Bitcoin에는 스마트 컨트랙트 VM(Virtual Machine)이 없지만, 여기서는 필요하지 않습니다. HTLC는 Script에서 직접 표현할 수 있습니다. 상환 조건(redeem condition)은 단순한 if/else 구조입니다: 프리이미지(preimage)를 공개함과 동시에 청구자의 서명을 통해 지출하거나, 절대적 잠금 시간(absolute locktime) 이후 환불자의 서명을 통해 지출하는 방식입니다.

OP_IF
    OP_SHA256 <H> OP_EQUALVERIFY
    <Bob_pubkey> OP_CHECKSIG
...

환불 분기(refund branch)는 절대적인 블록 높이/시간 잠금을 위해 OP_CHECKLOCKTIMEVERIFY (CLTV, BIP-65)를 사용합니다. 만약 타임락(timelock)이 고정된 시계 시간(wall-clock point) 기준이 아니라 금고(vault)에 자금이 입금된 시점부터 계산되기를 원한다면, 대신 OP_CHECKSEQUENCEVERIFY (CSV, BIP-112)를 사용할 수 있습니다. 청구 분기(claim branch)는 SHA256(s) == H를 만족하는 s와 Bob의 서명을 요구하므로, 단순히 s를 보는 것만 가능한 감시자(watcher)가 자금을 자신에게 가로챌 수 없도록 합니다.

실무에서 중요한 두 가지 구현 참고 사항은 다음과 같습니다:

P2WSH로 감싸거나, 더 나아가 Taproot (P2TR) 출력으로 구성하십시오. Taproot를 사용하면 환불 경로를 탭리프(tapleaf)에 넣고 협력적 경로(cooperative path)를 키 지출(key-spend)로 설정할 수 있습니다. 이렇게 하면 성공적으로 종료된 금고는 온체인상에서 일반적인 단일 서명(single-sig) 지출처럼 보이게 되어, 더 작고 저렴하며 프라이버시가 강화됩니다. HTLC 스크립트는 스크립트 경로(script-path)를 선택할 때만 나타납니다.
환불 트랜잭션은 반드시 채굴 가능(mineable)한 상태를 유지해야 합니다. 만료 시점에도 여전히 신뢰할 수 있는 수수료를 책정하여 환불 트랜잭션에 미리 서명해 두거나, CPFP/앵커(anchor) 출력을 사용할 수 있도록 준비해야 합니다. 블록에 포함시킬 수 없는 환불은 환불이 아니기 때문입니다. 비트코인에서는 촉박한 타임락(timelock) 윈도우 내에서 단순히 "나중에 수수료를 높이면 되겠지"라고 가정할 수 없습니다.

왜 "스왑(swap)"이 아니라 "금고(vault)"인가

일반적인 아토믹 스왑(atomic swap)은 비밀(secret)을 거의 즉시 공개합니다. 양측 모두 빠르게 종료하기를 원하기 때문입니다. 반면 _담보 금고(collateral vault)_는 더 오래 지속되는 의무 사항에 대한 담보로서 BTC 측을 의도적으로 열어둡니다. 예를 들어 다음 주에 결제되는 선도(forward) 계약, BTC 측이 다른 두 측과 발맞추어 정산되어야 하는 다자간 포지션, 또는 에이전트가 업무를 수행하기 전에 게시하는 지급 보증 등이 이에 해당합니다. 해시락(hashlock)은 여전히 해제 조건이지만, 타임락(timelock)은 이제 몇 번의 컨펌(confirmation)이 아니라 해당 의무의 수명에 맞춰 설정됩니다.

에이전트가 실제로 신경 쓰는 속성은 다음과 같습니다. 매 순간 BTC는 정확히 세 가지 상태 중 하나에 있습니다 — 잠금 (locked) (활성화된 의무를 뒷받침함), 해제 (released) (의무가 이행되었고 preimage가 공개됨)

Hashlock에서 에이전트는 Script를 직접 작성하지 않습니다. 대신 MCP 서버를 호출합니다. 즉, sealed-bid RFQ를 호출하여 상대방과 가격을 찾고, HTLC 생성을 호출하여 각 단계(legs)를 잠그며, 이 과정은 6개의 도구(tools)를 통해 하나의 작업으로 통합됩니다. BTC 담보 금고(BTC collateral vault)는 해당 HTLC의 비트코인 측 인스턴스화(instantiation)입니다. 동일한 preimage, 동일한 타임락 순서 규율(timelock-ordering discipline)을 따르되, Solidity 대신 Script로 표현됩니다. 자산은 전체 과정 동안 네이티브(native) 상태로 유지됩니다. 래핑(wrapping), 브릿지 멀티시그(bridge multisig), 수탁자(custodian)가 전혀 필요하지 않습니다.

솔직하게 밝히는 현황

BTC 측은 **signet 검증(signet-validated)**을 마쳤습니다. 즉, 스크립트(script), 타임락 순서, 환불 경로(refund paths)가 비트코인의 signet 테스트 네트워크에서 엔드 투 엔드(end-to-end)로 실행되었습니다. BTC 메인넷 연결(wiring)은 대기 중입니다. 아직 운영 환경에서 네이티브 BTC 결제가 활성화되지 않았는데, 활성화되었다고 거짓말하지 않겠습니다. 참고로, 프로토콜 전반에 걸친 현재의 정직한 체인 상태는 다음과 같습니다: ETH 메인넷 엔드 투 엔드 활성화; Sui 컨트랙트 배포 및 CLI 테스트 완료 (게이트웨이 연결 진행 중); BTC signet 검증 완료, 메인넷 대기 중. 우리는 매번 동일한 순서로 이를 언급하는데, 체인에 대한 주장은 결제 프로젝트가 결코 어긋나서는 안 되는 유일한 지점이기 때문입니다.

결제 프리미티브(settlement primitive)에 대한 공식 기술 문서를 원하신다면, 방법론 페이지에서 RFQ-plus-HTLC 구조를 설명하고 있습니다: hashlock.markets/methodology. 소스 코드는 GitHub의 github.com/Hashlock-Tech/hashlock-mcp에 있으며, 패키지 명칭은 hashlock-tech/mcp(scoped)이고, 학술 버전은 SSRN에서 확인할 수 있습니다.

제가 진심으로 답변을 듣고 싶은 질문이 하나 있습니다: BTC 담보 측(collateral leg)을 위해, 여러분이라면 타임락 간격(timelock gap)을 어디에 설정하시겠습니까? 그리고 어떤 멤풀(mempool) 가정을 바탕으로 그 크기를 산정하시겠습니까? 댓글에 숫자와 그 이유를 남겨주세요.