비트코인 위의 계약: DLCs와 키리스 커스터디 대출

호기심

1. 오라클이 누가 베팅하는지 모르는 상태에서 어떻게 비트코인 위에서 계약이 실행될 수 있을까요?
2. DLC에는 왜 블록체인상의 가격 피드가 전혀 필요 없을까요?
3. 오라클이 오프라인 상태가 되거나 거짓 정보를 제공하면 파생상품 포지션에는 어떤 일이 일어나나요?

탐구

파트 I디스크리트 로그 컨트랙트: 비트코인 방식의 오라클

1. 타데우스 드리자는 2017년 6월 디스크리트 로그 컨트랙트(DLC)를 제안했고, 같은 해 11월 Scaling Bitcoin 컨퍼런스에서 이를 발표했습니다. 핵심 혁신은 다자간 커밋먼트 방식으로, 참여자들은 자금을 멀티시그 아웃풋에 잠그는 동시에 가능한 모든 결과에 대한 트랜잭션을 미리 서명합니다. 코인을 지출하는 데 필요한 서명 전체를 어느 한 참여자도 갖고 있지 않으므로, 누구도 일방적으로 전액을 가져갈 수 없습니다.
2. 오라클은 미래의 이벤트에 대한 공개 논스를 미리 발표합니다. 이 논스와 오라클의 공개 키로부터 누구나 가능한 각 결과에 대해 오라클의 최종 서명이 대응하게 될 포인트를 계산할 수 있습니다. 당사자들은 이 포인트들로 사전 서명된 각 계약 실행 트랜잭션을 잠그므로, 각 트랜잭션은 해당 결과에 대한 오라클의 서명이 있어야만 완성될 수 있습니다. 오라클은 결과에만 서명할 뿐 계약을 보지 않으며, 계약의 존재를 알 필요도 없습니다.
3. 오라클이 실제 결과에 대한 서명을 공개하면 그에 맞는 트랜잭션을 완성해 브로드캐스트할 수 있고, 합의한 대로 지급이 이루어집니다. 다른 결과에 대한 트랜잭션은 잠긴 상태로 남는데, 오라클이 그 결과들에는 서명하지 않기 때문입니다. 하나의 이벤트에 대해 두 가지 결과에 서명하면 오라클의 개인 키가 드러납니다. 오라클이 끝내 서명하지 않으면 타임락이 걸린 환불 트랜잭션이 자금을 돌려줍니다.
4. 반면 이더리움의 DeFi 오라클은 대개 가격 데이터를 체인에 올리고, 컨트랙트가 이를 읽습니다. 사용자는 피드 운영자에게 의존하게 되며, 오래되었거나 조작된 피드는 잘못된 데이터로 컨트랙트를 실행시킵니다. DLC는 서명을 통해 결과를 오프체인에서 정산함으로써 이 문제를 피하고, 블록체인 자체에는 조작 가능한 가격 피드를 남기지 않습니다.
5. DLC는 수탁 중개자 없이 비트코인 위에서 직접 파생상품이나 담보 대출 같은 복잡한 금융 상품을 가능하게 합니다. 담보는 참여자들이 통제하고 오라클 서명으로 검증되는 멀티시그 에스크로에 남아 있으므로, 중앙화 거래소에 비해 거래상대방 위험이 크게 줄어듭니다. 이 프로토콜은 조건을 집행하거나 자금을 내주는 데 중앙 기관에 의존하지 않고 암호학적 커밋먼트로 정산 로직을 처리합니다.
6. 핵심 트레이드오프는 오라클의 가용성과 데이터 자체에 대한 정직성에 의존한다는 점입니다. 오라클은 자금을 훔치거나 계약 세부 내용을 알아낼 수는 없지만, 잘못된 데이터에 서명해 결과를 거짓으로 알릴 수는 있습니다. 다만 이러한 거짓은 다른 출처와 대조해 공개적으로 검증할 수 있으므로, 악의적인 오라클은 평판 손상을 입게 됩니다. 이 모델은 신뢰를 수탁 주체에서 외부 사건에 대한 암호학적 검증으로 옮깁니다.

파트 II키를 넘기지 않는 비트코인 담보 대출

7. DeFi는 담보 대출을 정착시켰지만, 셀시우스(Celsius)와 블록파이(BlockFi) 같은 중앙화 플랫폼은 고객의 비트코인을 자사 지갑에 보관했습니다. 2022년 두 회사가 모두 파산을 신청하자 해당 자금은 파산 절차에 묶였습니다. 이 사태는 수탁형 대출의 핵심 위험을 드러냈습니다. 중개자가 키를 통제하면, 대출 상태와 관계없이 재무 구조 붕괴나 운영상 실수로 사용자 자산이 동결되거나 사라질 수 있다는 것입니다.
8. 비트코인 네이티브 설계는 담보를 온체인 멀티시그 에스크로에 보관합니다. 일부는 디스크리트 로그 컨트랙트(DLC)를, 다른 일부는 사전 서명된 트랜잭션을 결합한 멀티시그를 사용합니다. 이러한 구조에서 자금은 지출하려면 여러 당사자의 서명이 필요한 아웃풋에 잠깁니다. 차입자는 상환이 확인될 때까지 소유권을 유지하며, 청산은 가격 기준선 같은 사전 정의된 조건이 오라클 서명을 통해 충족될 때만 이루어집니다. 따라서 정상적인 운영 중에는 자산을 보관할 수탁자가 필요하지 않습니다.
9. 파이어피시는 사전 서명된 트랜잭션 5개를 갖춘 3-of-3 에스크로를 사용합니다. 담보는 상환, 청산, 환불 등 미리 합의된 경로로만 이동할 수 있으며, 가격 및 결제 오라클 역할을 하는 파이어피시가 최종 서명을 추가합니다. 차입자의 키는 한 번 서명한 뒤 폐기되며, 대여자는 키를 하나도 갖지 않습니다. MiCA 라이선스를 보유한 파이어피시는 2026년 1분기에 USDT 대출을 추가했습니다. 이 설계는 누구에게도 자유로운 통제권을 주지 않고 모든 당사자를 미리 합의된 결과로 제한합니다.
10. 모든 프로토콜이 이 구조를 유지한 것은 아닙니다. 2025년 11월, 라바는 DLC 기반 비수탁형 설계에서 전통적인 수탁 모델로 전환한다고 발표했습니다. 사용자들은 이제 누가 자신의 담보를 통제하는지 물었습니다. 이 전환은 운영상의 단순함과 셀프 커스터디 에스크로 메커니즘에 내재된 보안 보장 사이의 긴장을 보여 줍니다.
11. 모든 비트코인 담보 대출 구조의 안전성은 세 가지 구체적인 요소로 결정됩니다. 누가 담보를 옮길 수 있는가, 오라클이 청산을 어떻게 촉발하는가, 그리고 대출 기관이 사라지면 사용자 자금은 어떻게 되는가입니다. 견고한 3-of-3 설계에서는 어떤 단일 주체도 일방적인 통제권을 갖지 못합니다. 오라클은 담보를 직접 가져갈 수 없지만, 잘못된 가격으로 부당한 청산을 촉발할 수는 있습니다.
12. 블록 탐색기를 열고 멀티시그 아웃풋이 포함된 트랜잭션을 살펴보세요. 해당 UTXO를 지출하기 위한 스크립트 조건을 확인하세요. 서명이 몇 개 필요한지, 각 서명을 어느 당사자가 통제하는지 적어 두세요. 이렇게 직접 살펴보면 대출 프로토콜이 실제로 키 관리를 분산하는지, 아니면 단일 수탁 주체에 집중시키는지 드러나며, 담보의 보안 상태에 대한 직접적인 증거를 얻을 수 있습니다.

핵심 사실

연습 아홉, 여섯, 셋, 하나

팩트 체크

날짜, 수치 및 주장은 아래에 명시된 출처들을 통해 확인되었습니다.

• T. Dryja, 'Discreet Log Contracts' (June 2017)
• Scaling Bitcoin 2017 presentation by T. Dryja (November 2017)
• DLC specifications, github.com/discreetlogcontracts
• DLC specifications (github.com/discreetlogcontracts)
• Firefish Q1 2026 update
• Blockspace reporting on Lava (2025)
• Celsius bankruptcy reporting (2022)