저자: 야누시
출처: https://insider.btcpp.dev/p/bitvm-based-bridges-and-emergency
원문은 2025년 8월에 발표되었습니다.
BitVM 기반 브리지 계약이 실제 운영 환경에 배포될 시점이 가까워짐에 따라, 저는 소위 "긴급 업데이트" 경로에 대해 생각해 보기 시작했습니다. Citrea 팀의 도움으로 BitVM 브리지 계약의 비용 경로를 검증하는 다양한 방법을 이해하고, 이를 통해 긴급 업데이트 메커니즘이 포함되어 있는지 여부를 판단할 수 있었습니다. 이 글에서는 향후 프로젝트에서 이러한 비용 경로를 어떻게 구현할 수 있을지 논의하고자 합니다. 긴급 업데이트 경로와 비용 계약에 대한 다중 서명 메커니즘은 "BitVM 고유 기능"이 아니라, 증명 시스템으로 보호되는 브리지 계약에서 널리 사용되는 메커니즘이며, BitVM 기반 브리지 계약 구축에도 활용될 것으로 예상됩니다. 이 글은 설명적인 목적이며, 이러한 비용 경로의 유형을 어떻게 공개해야 할지에 대한 논의를 촉발하기를 바랍니다.
은행에서 급하게 돈을 인출해야 하는 상황에 처해본 적이 있으신가요? 예를 들어, 차가 고장 나서 정비비를 바로 지불해야 하거나, 친구가 술집에서 과음해서 돈을 내줘야 하는 경우처럼요.
BitVM 브리징 계약도 비슷한 보장을 원할 가능성이 높습니다. 우리는 브리징 계약 운영자가 BitVM이 처음 설정한 특정 규칙을 준수하도록 해야 합니다. 하지만 문제가 발생하면 어떻게 될까요? 시스템에 취약점이 있어 공격자가 갑자기 모든 자금을 탈취하거나 자금이 영구적으로 동결 되는 상황이 발생한다면 어떻게 될까요?
설령 선의의 사람이 버그를 발견하더라도, 계약 위반을 막기 위해 브리징 계약에서 모든 자금을 선제적으로 인출하는 방법을 원할 수도 있습니다.
이 보장은 비상 다중 서명 장치를 통해 달성됩니다. 이는 BitVM 브리징 계약에 구현할 수 있는 추가 지출 경로로, 그룹(또는 단일) 서명자가 챌린지 게임과 낙관적 상환 메커니즘을 완전히 우회하고 브리징 계약에서 자금을 이체할 수 있도록 합니다.
BitVM은 새로운 기술이며, 이에 상응하는 브리징 메커니즘 또한 새롭습니다. 일부 팀은 안전장치 없이 이러한 새로운 브리징 계약 구조를 공개하는 것을 꺼립니다. 브리징 계약을 조기에 도입하는 사용자나 유동성 공급자는 버그가 발견될 경우 자금을 인출할 수 있도록 비상 전환 기능을 원할 수도 있습니다. 불변성이 항상 상업적 이익과 완벽하게 부합하는 것은 아닙니다.
기존 BitVM 브리지 계약 구현 중 일부는 이미 긴급 업데이트를 위한 다중 서명 장치를 포함하고 있을 수 있습니다. 더 많은 브리지 계약 구조가 곧 상장 이며, 이러한 구조에는 긴급 다중 서명 장치를 운영하는 라이선스 보유 서명자 그룹인 보안 위원회가 포함될 수 있습니다. 이러한 시스템의 보안 모델이 결국 라이선스가 필요한 M-of-N 다중 서명 장치(일회용 장치일지라도)로 되돌아가는 경우, 사용자는 이를 알 권리가 있습니다.
저는 2주 동안 그러한 보안 위원회를 설립하는 방법을 연구했고, (물론 BitVM 진영의 몇몇 구성원들의 도움을 받아) 위원회의 존재를 어떻게 검증할지 계속 고민했습니다.
이러한 연습은 흥미로운 "문제"를 제기합니다. 실제로 사용되기 전까지는 이러한 지출 경로(블록체인 내에서)를 검증할 수 없습니다. 즉, 내부자가 이를 전혀 공개하지 않으면 일부 사용자는 허가형 M-of-N 다중 서명 장치가 BitVM 기반 브리징 계약의 궁극적인 신뢰 가정에 기반한다는 사실조차 알지 못할 수 있습니다.
BitVM 브리지 계약 검토
로빈 리눅스가 제안한 " BitVM "은 비트코인 블록체인 내에서 임의의 연산을 수행할 수 있도록 하는 기술입니다. 이 기술은 비트코인 개발에 새로운 물결을 일으켰으며, 많은 팀들이 이 기술을 활용하여 레이어 2 브리징 컨트랙트를 개발하고 있습니다. 이러한 컨트랙트는 여러 운영자가 비트코인을 담보로 보유하여 레이어 2에 캡슐화된 비트코인 자산에 대한 보증인 역할을 할 수 있는 레이어 2 구조를 지원합니다. 더욱 중요한 것은, 이 기술을 통해 운영자의 악의적이거나 부적절한 인출 시도를 차단할 수 있는 추가적인 낙관적 탐지 메커니즘을 구현할 수 있다는 점입니다.
초기 단계에서 서명자 그룹은 N-of-N 다중 서명 장치를 구성하여 브리징 계약의 트랜잭션 그래프를 사전 서명합니다. 만약 서명자 중 한 명이라도 이 사전 서명에 사용된 개인 키를 파기하면, 브리징 계약에 잠긴 UTXO는 미리 정의된 지출 스크립트를 통해서만 사용할 수 있게 됩니다.
어떤 경우에는 운영자가 유동성 확보를 위해 자금을 선지급한 후 브리징 계약으로부터 상환을 요청해야 합니다. 운영자는 일정 기간이 지난 후에야 스스로 상환받을 수 있습니다. 또 다른 설계 방식은 사용자가 브리징 계약에서 자금을 이체하는 데 필요한 개인 키를 공개하는 정직한 운영자와 협력할 수 있도록 합니다.
설계 방식과 관계없이, 최소 한 명의 정직한 운영자가 출금을 처리해야 합니다. 만약 운영자가 부정직한 행동을 한다면, 예를 들어 시스템의 초기 상태와 상충되는 출금을 목격했을 경우, 감시자(감시탑 서비스)가 해당 운영자에게 이의를 제기할 수 있습니다.
여기서 언급된 감시탑은 BitVM 검증자 소프트웨어를 실행하고 BitVM 브리지 계약 운영자의 출금 요청에 이의를 제기하고 이를 중단시킬 수 있는 주체(또는 개인)입니다.
부적절한 출금의 경우, 예를 들어 운영자가 BitVM 인스턴스에서 인출해야 할 금액보다 잔액 자금을 인출하려고 시도할 수 있습니다. 이러한 이유로 브리징 계약의 지출에는 시간 잠금이 포함됩니다 . 이는 감시탑이 이의를 제기할 시간을 제공합니다. 출금 계약이 브로드캐스트되는 시점부터 시간 잠금이 해제되는 시점까지의 이 시간 범위를 " 이의 제기 기간 "이라고 합니다.
챌린지 기간이 종료되고 스카우트에게 알림이 전송된 후에야 운영자(또는 사용자)가 브리지 계약에서 자금을 인출할 수 있습니다. BitVM 기반 브리지 계약에서 자금 도난은 모든 운영자와 감시탑(브리지 계약을 완전히 탈취할 수도 있음) 간의 공모가 필요합니다. 자금은 운영자 중 한 명이라도 정직하고 정기적으로 블록체인을 확인하며, 검증자가 온라인 상태이고 챌린지를 제출할 의향이 있는 한 도난당하지 않습니다. 이러한 1/N 신뢰 가정은 일반적인 컨소시엄 보다 더 적은 수의 사람만 신뢰해도 된다는 것을 의미하기 때문에 유리합니다. 일반적인 컨소시엄에서는 다수의 부정직한 개인만으로도 자금을 훔칠 수 있기 때문입니다.
앞서 언급한 메커니즘은 비트코인 네트워크에서 이미 사용 중인 방식보다 신뢰도가 훨씬 낮은 연결 메커니즘을 생성합니다. 그러나 실제로는 이러한 핵심적인 신뢰 가정이 궁극적으로는 (비록 일시적일지라도) 허가형 다중 서명 메커니즘으로 되돌아갈 가능성이 있습니다. (역자 주: 이러한 되돌아감 이후의 상황은 현재 구현된 메커니즘(사이드체인용 다중 서명 컨소시엄)과 동일합니다.)
비상 다중 서명 도입
서론에서 언급했듯이 개발팀은 BitVM 인스턴스에 비상 지출 경로를 추가할 수 있으며, 실제로 추가하는 경우가 많습니다. 추가해야 하는지 여부는 중요하지 않습니다. 더 중요한 것은 거의 모든 BitVM 기반 브리징 계약이 완전히 성숙되기 전에 비상 지출 메커니즘을 포함하여 실제 운영 환경에 배포된다는 점입니다. 따라서 우리는 이러한 개발팀이 비상 지출 경로의 구체적인 내용을 제대로 공개할 것으로 기대해야 합니다.
BitVM에는 비상 다중 서명 메커니즘이 포함되어 있지 않습니다. 이는 버그가 발견되었을 때 시스템을 업데이트하기 위해 증명 시스템으로 보호되는 브리지 계약에서 널리 사용되는 메커니즘입니다. 다른 생태계의 롤업 인스턴스에서 이미 이와 관련하여 선례가 있습니다.
BitVM 브리지 컨트랙트는 Segregated Witness v1(Taproot) 스크립트를 사용하여 사전 서명된 브리지 컨트랙트의 지출 경로를 생성합니다. Taproot 스크립트는 MAST를 사용하는데, 이를 통해 단일 UTXO에 대량 지출 조건이 존재할 수 있습니다. 리프 스크립트가 이 UTXO를 지출하는 데 사용될 경우, 해당 리프 스크립트만 노출됩니다(동시에 존재하는 다른 리프 스크립트는 노출될 필요가 없습니다).
BitVM2 문서에서는 사전 서명된 거래가 운영자가 자금 인출 시 검증 가능한 방법만 사용하도록 제한할 수 있다는 점을 정확하게 지적합니다. 그러나 특정 BitVM 인스턴스 개발자가 Taproot 스크립트 트리에 브리지 계약에서 인출을 허용하는 추가 지출 경로를 포함하는 것을 막을 수는 없습니다.
Taproot 스크립트 트리에서 각 지출 경로는 "리프" 스크립트라고 합니다. 이 스크립트 트리에 의해 잠겨 있는 UTXO를 잠금 해제하고 사용하려면 유효한 리프 중 하나를 공개하고 해당 리프 스크립트를 만족하는 증인 데이터를 제공하기만 하면 됩니다.
예를 들어 보겠습니다. 첫 번째 경로(또는 첫 번째 안내 책자)는 이의 제기 기간이 있는 표준 인출 경로입니다. 다른 경로는 이의 제기 기간을 거치지 않는 긴급 지출 경로입니다.
A 부분: 1/N 사기 방지 기능으로 보호되는 지출 조건
OP_PUSHBYTES_2 <SomeDelay>OP_CSVOP_DROPOP_PUSHBYTES_32 <OperatorPubKey>OP_CHECKSIG리프 B: 2/3 긴급 해제 비용 조건
OP_PUSHBYTES_32 <pubkey1>OP_CHECKSIGOP_PUSHBYTES_32 <pubkey2>OP_CHECKSIGADDOP_PUSHBYTES_32 <pubkey3>OP_CHECKSIGADDOP_PUSHNUM_2OP_NUMEQUAL "리프 A"는 BitVM 인스턴스에서 표준 인출 상환 조건입니다. 일정 시간 지연( <SomeDelay> )이 지나면 미리 지정된 운영자가 브리지 계약에서 자금을 인출할 수 있습니다. 운영자가 브리지 계약에 잠긴 UTXO를 부정직하게 사용하는 경우, 감시탑은 부정직한 인출 요청을 방지하기 위해 해당 운영자의 UTXO를 일정 시간 지연 동안(즉, BitVM 계약을 사용한 시점부터 <SomeDelay> 시간 제한이 만료되는 시점까지) 이의를 제기할 수 있습니다.
리프 A는 N명 중 N명으로 구성된 사전 서명 위원회가 구성한 사전 서명 거래의 비용일 수 있습니다.
반면, "리프 B"는 즉시 사용 가능한 자금 이체 경로입니다. 3개 기기 중 2개 기기의 다중 서명만으로 BitVM 계약에 있는 모든 자금을 즉시 이체할 수 있습니다. 이는 개발팀이 계약에서 악용 가능한 버그를 발견했거나 자금을 횡령하기로 결정했을 때 사용할 수 있습니다.
제가 "계약"이라고 말할 때는 항상 비트코인 UTXO의 지출 조건을 제어하는 BitVM 계약을 의미합니다.
이 두 가지 비용 조건은 브리징 계약의 최상위 스크립트 트리에 공존할 수 있습니다. BitVM 챌린지-응답 게임을 우회할 수 있는 비용 조건을 추가하는 것이 항상 합리적인 것은 아니지만, 개발자가 그러한 비용 조건을 구현하는 것을 객관적으로 막는 것은 없습니다.
또한, 스크립트 트리의 지출 조건은 매우 유연하게 설정할 수 있습니다. 위 예시에서는 두 가지 지출 조건만 보여주었지만, 개발팀은 다양한 지출 조건을 포함하는 스크립트 트리를 만들 수 있습니다. 위 예시의 리프 노드 B는 긴급 업데이트 메커니즘의 한 예입니다. 이 긴급 업데이트 메커니즘은 지연 없이 3명 중 2명의 서명자로 실행될 수 있어 사용자 자금 도난으로 이어질 수 있습니다. 보다 광범위한 프로토콜 업그레이드는 12명 중 9명의 보안 위원회에서 시작할 수 있으며 시간 잠금을 포함할 수도 있습니다.
구체적인 설계는 구현 방식에 따라 다를 수 있지만, 중요한 것은 이러한 지출 조건을 검증할 수 있어야 한다는 점입니다. 최신 비트코인 스크립트의 한 가지 "문제"는 스크립트가 실제로 사용되기 전까지는 공개적으로 검증할 수 없다는 것입니다. 이는 BitVM 기반 브리징 계약과 밀접한 관련이 있으며, 특정 리프 스크립트가 UTXO를 사용하는 데 사용되기 전까지는 모든 지출 경로를 검증할 수 없다는 것을 의미합니다. 리프가 사용되면 해당 리프가 나타내는 지출 조건만 공개된다는 점을 기억하십시오. 따라서 일반적인 인출만 수행된 경우 긴급 지출 경로의 존재를 검증할 수 없으며, 그 반대의 경우도 마찬가지입니다.
이는 문제를 야기할 수 있습니다. 개발팀이 스크립트 트리에 비상 지출 메커니즘을 삽입했지만 이를 노출하지 않으면, 사용자는 라이선스를 보유한 다중 서명 장치(또는 라이선스를 보유한 개인)가 브리징 계약에 묶인 모든 자금을 사용할 수 없다는 것을 확신할 수 없게 됩니다.
일주일 동안 고민한 끝에 개발팀이 교량 건설 계약의 비용 추이를 공개할 수 있는 몇 가지 방법을 생각해냈습니다.
정보 공개 방법
지출 경로를 사용 설명서에 직접 명시하십시오.
개발팀에게 가장 간단한 접근 방식은 문서에 권한 있는 역할을 명시하는 것입니다. 개발팀은 브리징 계약을 운영하는 사람, 사전 서명식에 참여한 사람, 경량 클라이언트를 실행하는 사람, 그리고 감시탑이 누구인지 직접 공개할 수 있습니다.
어느 정도 정보 공개는 전혀 없는 것보다는 낫지만, 웹사이트에 나와 있는 정보만으로는 브리징 계약의 비용 추이를 확인할 수 없습니다. 스크립트를 직접 확인할 수 있다면 훨씬 더 좋을 것입니다.
입금하기 전에 테스트해 보세요.
개발팀은 다양한 지출 경로에 대한 테스트 거래를 보낼 수 있습니다. 특정 인스턴스에서 자금을 일부 사용하여 궁극적으로 모든 지출 경로를 공개할 수 있으며, 사용자도 직접 지출 경로를 검증할 수 있습니다.
이는 개발팀이 스크립트 트리의 모든 리프 노드를 사용해야 한다는 것을 의미합니다. 하지만 그렇다고 해서 개발팀이 공개되지 않은 추가 지출 조건을 삽입하지 않을 것이라고 확신할 수는 없습니다. 개발팀은 특정 리프 노드를 사용하지 않거나 지출 조건을 공개하지 않도록 선택적으로 결정할 수 있습니다. 이는 종종 Taproot MAST의 특징으로 여겨지지만, 브리징 계약의 맥락에서는 개발팀이 모든 지출 스크립트를 실제로 공개했는지에 대한 사용자 신뢰도를 떨어뜨립니다.
유감스럽게도 테스트 거래는 우리가 기대했던 투명성을 제공하지 못했습니다.
대규모 제한 조항을 사용하여 위원회를 시뮬레이션합니다.
또 다른 접근 방식은 개발팀이 충분히 큰 제약 조건을 사용하여 위원회를 시뮬레이션하고 독립적인 참여자들이 사전 서명된 브리징 계약 거래 그래프 내의 모든 거래에 참여할 수 있도록 하는 것입니다. 이를 통해 독립적인 참여자들은 비상 다중 서명의 존재 여부와 서명자 수를 확인할 수 있습니다.
하지만 이 방식은 사용자가 직접 스크립트를 검증하는 대신, 제한 조건 위원회 참여자들을 신뢰해야 한다는 제약이 있습니다. 제가 생각하는 해결책은 모든 사용자가 브리징 계약의 비용 경로를 검증할 수 있도록 하는 것입니다.
표준화된 정보 공개 방법을 만드세요
제 개인적인 생각으로는 개발팀이 BitVM 인스턴스용으로 만든 전체 스크립트 트리를 공개할 것으로 예상해야 합니다.
개발팀에서 탭스크립트 생성에 필요한 내부 키, 모든 리프 스크립트, 그리고 해당 브리지 컨트랙트 주소를 제공해 준다면 저희가 직접 처리할 수 있습니다.
이 정보, 즉 비용 경로를 생성하는 데 사용된 내부 공개 키와 탭루트 스크립트 트리에서 파생된 머클 루트를 사용하여 두 정보를 합산하면 조정된 공개 키를 얻을 수 있습니다. 이 조정된 공개 키가 BitVM 브리지 계약의 주소와 일치하면 해당 주소에 실제로 이러한 비용 스크립트만 포함되어 있음을 확인한 것입니다.
보세요! 검증 가능한 정보 공개 방식이 있습니다. 개발팀이 잘못된 탭루트 스크립트 트리를 노출하더라도, 수정된 공개 키는 브리지 계약의 주소와 일치하지 않습니다.
이 공개 방식을 통해 BitVM 브리지 계약 인스턴스와 관련된 핵심 신뢰 가정을 실제로 검증할 수 있습니다. 하지만 이 방식은 개발팀이 전체 스크립트 트리와 관련 내부 공개 키를 공개 해야 합니다 .
투명성의 중요성
서명자의 신원을 공개하지 않더라도, 진정한 신뢰 가정을 이해하기 위해서는 스크립트가 필요합니다. 이러한 시스템은 1/N의 정직한 참여자라는 신뢰 가정을 기반으로 설계되었습니다. 하지만 궁극적으로 신뢰 가정이 허가형 다중 서명 메커니즘으로 전환될 경우, 이러한 계약에 자금을 예치하는 사용자는 이를 알 권리가 있습니다.
저는 BitVM 기반 브리징 계약의 대다수에 이러한 긴급 업데이트 비용 경로가 포함될 것으로 예상합니다. 이러한 브리징 계약에 항상 이러한 비용 경로가 있는 것은 아니게 되어, 신뢰를 최소화한 설계로 업그레이드할 수 있기를 바랍니다. 하지만 이러한 비용 경로를 무시하거나, 이것이 유일한 신뢰 패턴이 아니라는 변명을 할 수는 없습니다.
긴급 지출 경로가 존재하는 한, 그것은 의심할 여지 없이 신뢰 모델 그 자체입니다.
(위에)
