MCCV: CTV(중앙 금고 모듈)만을 사용하여 모든 기능을 갖춘 금고.

저자: 아데만

출처: https://delvingbitcoin.org/t/ctv-only-vault-concept-v0-1-0-release/2539

저는 " 더 복잡한 CTV 금고 "에 대한 제 개념인 MCCV의 첫 번째 버전을 출시하게 되어 기쁩니다. MCCV는 BIP-119 OP_CHECKTEMPLATEVERIFY (OP_CTV)를 사용하여 개발되었습니다. MCCV는 더 복잡한 코버넌트 오퍼코드에 의존하지 않고 OP_CHECKTEMPLATEVERIFY 만으로 완벽하게 작동하는 금고 계약을 구축할 수 있음을 보여줍니다. 최종 설계는 계산 부담이 크고 사용 편의성이 다소 떨어지지만, 입금, 지연 출금, 복구, 출금 속도 제어 및 반복적인 금고 작업과 같은 기능을 성공적으로 제공합니다.

요약하자면, 자금은 일반 지갑에서 미리 정해진 단위로 금고에 입금되고, 출금 또한 미리 정해진 단위로 이루어지며, 출금할 때마다 시간 잠금 기간이 연장됩니다. 이러한 상대적 시간 잠금은 보류 중인 출금과 금고에 남아 있는 자금을 복구 키로 전환할 수 있는 보안 기간을 제공합니다. 이렇게 확보된 복구 키는 더욱 안전한 저장 장치에 연결하여 사용할 수 있습니다.

인출 금액에 비례하여 시간 제한이 선형적으로 연장되기 때문에, 이 안전 금고 계약은 합의 메커니즘을 통해 인출 속도 제한을 적용하여 잠재적 손실을 줄일 수 있습니다.

개요

참고 : 이 소프트웨어는 개념 증명을 위한 실험적인 버전으로, signet(또는 regtest)과 같은 테스트넷에서만 사용할 수 있습니다.

현재 구현은 Rust로 작성되었으며 BDK 및 rust-bitcoin 에 의존하는 작동 가능한 명령줄 인터페이스 소프트웨어(개념 증명)입니다. Bitcoin Inquisition v29를 사용하여 regtest 및 signet에서 실행됩니다. Bitcoin Inquisition은 OP_CHECKTEMPLATEVERIFY , TRUC(확인 전 토폴로지 제한 트랜잭션) 및 "임시 앵커"를 지원합니다.

이 구현은 다음을 지원합니다.

• 안전한 생성
• 핫월렛을 사용하여 돈을 받고 쓰세요.
• 일정 금액을 점진적으로 금고에 예치하십시오.
• 고정 크기 증분으로 지연 인출을 초기화합니다.
• 만기 인출금을 핫월렛으로 이체하세요.
• 금고 전체를 콜드 스토리지에 보관된 복구 키로 복원하십시오.
• GitHub 저장소 주소: GitHub - LNHANCE-Expedition/mccv: More Complicated CTV Vault · GitHub
• 사용자 가이드: mccv/docs/user-guide.md (master 브랜치) · LNHANCE-Expedition/mccv · GitHub
• 프로토콜 세부 정보(개발 중): mccv/docs/protocol.md (master 브랜치) · LNHANCE-Expedition/mccv · GitHub

특성

무단 인출 방지

모든 금고와 마찬가지로, 이 유형의 금고에서 인출된 자금은 복구 기간 동안 보관됩니다. 이 기간 동안 사용자는 인출된 자금과 금고에 남아 있는 모든 자금을 복구 키로 옮길 수 있습니다.

인출 속도 제어

이러한 유형의 금고는 무단 접근 시 자금을 복구할 수 있는 방법을 제공할 뿐만 아니라 합의 메커니즘을 통해 인출 속도 제한을 적용합니다.

여러 작업

이 계약은 동일한 금고에서 상당하지만 제한된 횟수의 입출금을 지원합니다. 따라서 이 금고 설계는 일회성 금고 설계보다 훨씬 더 유연합니다.

지원

이러한 유형의 금고는 데이터를 매우 작고 일정한 크기의 데이터 세트로 백업할 수 있습니다.

주요 단점

복잡성

이 프로토콜은 수백만 건의 거래를 생성할 수 있으므로 기본적인 신뢰성을 확보하기 위해서는 엄격한 코드 품질 검사 및 감사 필요합니다. 더욱이, 프로토콜 자체의 복잡성이 리스크 로 작용하여, 목표 사용 사례인 거액의 자금 이체에는 적합하지 않을 수 있습니다. 하지만 이러한 가장 큰 리스크 콜드 스토리지/복구 키 탈출 포드를 구축함으로써 어느 정도 완화할 수 있습니다.

계산은 힘들다

입금 증분 단위의 세분성, 동시 출금/입금 허용 증분 횟수, 그리고 볼트에서 지원하는 총 작업 횟수가 증가함에 따라 계산 부담도 증가합니다. 사용자 경험을 개선하는 모든 방식은 계산 부담 증가와 온체인 거래 수수료 증가로 이어집니다.

신뢰 금고를 만드는 과정

이 접근 방식의 계산 복잡성으로 인해 신뢰 구축이 필수적입니다. 금고를 생성하는 장치는 사용자가 원하는 작업을 열거할 수 있을 만큼 강력해야 하며, 동시에 신뢰할 수 있어야 합니다. 현재 실용적인 매개변수를 사용하여 금고 인스턴스를 생성하려면 최신 상용 PC나 모바일 기기와 유사한 성능의 하드웨어가 필요하지만, 이러한 시스템은 신뢰하기 어렵습니다. 오프라인 PC가 이러한 요구 사항을 가장 잘 충족하지만, 오프라인 PC 자체도 복잡한 금고 없이도 사용자의 보안 요구 사항을 상당 부분 충족할 수 있습니다. STARK는 하드웨어 서명기 내에서 금고를 실질적으로 검증할 수 있을 것으로 예상되며, 이는 향후 연구의 중요한 방향이라고 생각합니다.

돈을 인출하려면 두 단계를 거쳐야 합니다.

각 금고는 미리 계산되기 때문에 자금을 수신자에게 직접 인출할 수 없습니다. 대신, 만기된 인출금은 핫월렛을 통해 사용된 후 수신자에게 전달됩니다. 이는 핫월렛이 해킹당할 경우 만기된 인출금 또한 도난당할 수 있음을 의미합니다. 또한, 자금의 최종 목적지가 인출 거래에 포함되지 않기 때문에 단일 인출 승인이 복잡해집니다. OP_VAULT 와 OP_CCV 모두 이 문제를 해결합니다(실제로 이 두 프로토콜은 이러한 설계를 완전히 불필요하게 만듭니다).

은둔

엄격한 출금 속도 제어로 인해 자금이 단일 UTXO에 모여야 합니다. 이는 온체인 개인정보 보호에 상당한 손실을 의미합니다.

처리 수수료

이 결함은 프로토콜 자체의 문제가 아니라, 개념 증명 구현의 설계 방식에서 비롯됩니다. 핫 키가 핫 월렛 키와 연결되어 있기 때문에 공격자가 먼저 핫 월렛의 잔액을 모두 소진시켜 복구/회수 거래 확인에 필요한 수수료를 지불하지 못하게 할 수 있습니다.

이 문제는 감시탑이 다른 키를 사용하도록 하고, 감시탑 서비스가 사용자 또는 제3자에 의해 운영되는지 여부와 관계없이 복구 거래 수수료를 지불하기 위한 전용 자금을 할당함으로써 완화할 수 있습니다.

계약 개요

협정의 세부 사항은 아직 작성 중입니다.

볼트는 미리 계산된 트랜잭션으로 구성된 대규모 DAG(방향 비순환 그래프)입니다. 이러한 트랜잭션 간의 전환은 OP_CHECKTEMPLATEVERIFY 사용하여 검증됩니다. 볼트는 다음 매개변수로 구성됩니다.

• scale : 기본 인출 및 인출 증액. 금고에서의 각 작업은 이 금액의 배수입니다.
• delay : 각 추가 증분을 가져오기 위해 기다려야 하는 추가 블록의 수입니다.
• max-withdrawal : 한 번에 인출할 수 있는 최대 품목 수입니다.
• max-deposit : 한 번에 입금할 수 있는 최대 금액입니다.
• max-depth : 금고가 지원할 수 있는 작업 수(DAG의 깊이).

이러한 매개변수는 보안, 편의성 및 사전 계산된 비용 간의 균형을 제어합니다.

역사

이 볼트 프로젝트는 하나의 실험에서 시작되었습니다. CTV만을 사용하여 사용자 친화적인 볼트를 만드는 것이 얼마나 가능할까요? 일반적으로 CTV만으로는 이상적인 반응형 볼트를 구축하기에 불충분하다고 여겨지지만, CTV는 사전 계산된 상태 머신을 개발하는 데 활용될 수 있습니다. 이러한 구조는 다양한 온체인 계약을 생성할 수 있으며, 유일한 제약 조건은 사전 계산입니다. 순전히 이론적인 관점에서, CTV와 탭루트를 함께 사용하면 매우 복잡하지만 궁극적으로 열거 가능한 트랜잭션 전환 그래프를 표현할 수 있습니다. 하지만 이는 모든 가능한 상태와 상태 전환을 철저하게 열거해야만 가능합니다. 현실적으로, 매개변수 집합이 엄격하게 제한된 크기를 초과하면 계산적으로 불가능해집니다.

제 연구 결과에 따르면 이 접근 방식은 매개변수 개수가 적을 때는 실용적이지만, 매개변수 개수가 늘어날수록 사전 계산 속도가 사용자 경험을 빠르게 저하시킵니다. 캐싱은 가능하며 후속 실행 시 지연 시간을 줄이기 위해 구현되어야 하지만, 그럼에도 불구하고 금고 초기화 계산은 상당히 오래 걸릴 수 있습니다. 따라서 실제 사용 사례보다 훨씬 많은 매개변수를 가진 "사실상 무제한" 금고에 대한 기대는 무산된 것으로 보입니다. 그러나 몇 가지 실질적인 제약 조건(사용자에게 명시적으로 알릴 수 있음)을 받아들인다면 MCCV는 유용한 기능을 제공합니다.

비교하다

이 솔루션은 최초의 안전한 설계도 아니고 OP_CHECKTEMPLATEVERIFY 활용한 최초의 솔루션도 아닙니다. 하지만 제가 아는 한, OP_CHECKTEMPLATEVERIFY 와 taproot를 이러한 방식으로 결합한 최초의 공개된 안전한 설계입니다.

심플-ctv-볼트

이름에서 알 수 있듯이 " simple-ctv-vault "는 최대한 간단하게 설계되었습니다. 이는 제가 MCCV를 개발하게 된 계기가 되었는데, 더 복잡한 구조가 얼마나 실용적일 수 있는지 직접 경험해 보고 싶었기 때문입니다. simple-ctv-vault는 UTXO를 통해 핫 주소로 출금(지연 시간 발생)하거나 콜드 주소로 이체할 수 있습니다. 이는 MCCV의 기본 원리와 동일하지만, simple-ctv-vault는 일회성 입금 및 출금만 지원한다는 점이 다릅니다.

브라이언 비숍의 "비트코인 금고"

브라이언 비숍의 " 비트코인 볼트(Bitcoin Vaults )"를 더 일찍 알았더라면 좋았을 텐데 하는 생각이 듭니다. 이 디자인은 개념적으로나 방향적으로 MCCV와 유사합니다. MCCV처럼, 이 디자인 역시 볼트를 가치에 따라 "샤드"라고 불리는 여러 부분으로 나눕니다. 또한, 개인 키를 파괴하는 사전 서명된 트랜잭션을 사용하거나 OP_CHECKTEMPLATEVERIFY 통해 제약된 볼트 작업을 지원합니다. 다만, 이 디자인은 탭루트(Taproot)가 활성화되기 전에 설계되었습니다. 탭루트가 없다면, 지출 경로 수를 늘리려면 더 큰 규모의 witnessScript 스크립트(지출 트랜잭션용)를 사용해야 할 것입니다. 브라이언은 볼트가 콜드 스토리지로 자금을 이동시키거나, 볼트를 여러 부분으로 나누거나, 한 부분에서 자금을 인출하고 나머지는 볼트에 남겨둘 수 있도록 지출 경로를 신중하게 선택했습니다. 마지막 부분은 특히 MCCV와 유사합니다. 제 생각에는 탭루트가 다양한 지출 조건을 효율적으로 표현할 수 있게 되면서 볼트를 여러 부분으로 나눌 필요성이 크게 줄어들 것 같습니다. MCCV를 사용하면 사용자는 필요한 만큼의 금액을 인출할 수 있고, 나머지 볼트는 남은 잔액 보호합니다. Taproot의 효율성 덕분에 MCCV는 기존 금고에 자금을 예치할 수 있는데, 이는 브라이언의 프로토콜에서는 불가능한 기능입니다. 다만, 이 경우 여러 상태를 미리 계산해야 하는 단점이 있습니다. MCCV 프로토콜 설계는 제가 브라이언의 연구에 대해 알기 전에 완료되었지만, 금고를 여러 부분으로 나누고 인출 시 금액을 차감하는 등의 유사한 설계 요소들을 발견했을 때 마치 동지를 찾은 듯한 느낌을 받았습니다.

OP_VAULT 및 OP_CHECKCONTRACTVERIFY 디자인

이로 인해 제한적인 오퍼레이션 코드 용어에 대한 논란이 발생하지 않기를 바랍니다. 단지 이러한 오퍼레이션 코드가 제 설계를 상당 부분 대체할 것이라는 점을 말씀드리고 싶습니다. 이러한 오퍼레이션 코드를 사용하면 안전한 설계를 어렵게 만드는 모든 사전 계산을 피할 수 있습니다. 또한, 단일 단계 인출이 가능하므로 수신자가 인출 거래에서 이를 지정할 수 있습니다. 이는 감시탑에서 철저한 승인을 수행하는 데 도움이 되며, 수신자가 직접 자금을 수령하다 할 수 있도록 합니다(단, 수신자는 이러한 출력을 삭제하기 위한 추가 정보가 필요합니다). 그렇지만 OP_VAULT 와 OP_CHECKCONTRACTVERIFY OP_CHECKTEMPLATEVERIFY 보다 활성화될 가능성이 훨씬 낮다고 생각하므로 CTV만 사용하는 설계를 검토해 볼 가치가 있다고 봅니다.

피드백을 요청합니다

다음 사항에 대한 의견을 주시면 대단히 감사하겠습니다.

• 전체 프로토콜 설계
• 이러한 디자인 선택은 더 단순한 디자인과 비교했을 때 어떤 차이가 있을까요?
• 금고에 대한 전반적인 생각
• 사용자 경험: 본 프로젝트는 개념 증명 단계이며 , 몇 가지 알려진 사용자 경험상의 문제점이 있지만, 모든 가능한 사용자 동작은 테스트 준비가 완료되었습니다. 사용자 가이드 작성에 참여해 주시기 바랍니다.
• 성능 및 사전 계산된 비용

결론적으로

이 접근 방식에는 대량 단점이 있지만, 운용 펀드의 보안 측면에서 여전히 흥미로운 개선점을 제공합니다. 특히 다음과 같은 방향으로 개선이 이루어진다면, OP_VAULT 및 OP_CCV 에 의존하지 않고도 유사한 사용자 경험을 제공할 수 있습니다.

미래의 직업

다른 여러 프로젝트들도 제 관심을 끌고 있어서, 당분간 그 분야에 전념하겠다는 약속은 아닙니다. 하지만 특히 흥미롭고 가능한 한 빨리 살펴볼 가치가 있다고 생각하는 프로젝트들이 몇 가지 있습니다.

향후 가능한 직업은 다음과 같습니다:

• 감시탑 소프트웨어: 감시탑에 필요한 모든 기능은 이 명령줄 인터페이스 도구에서 사용할 수 있지만, 아직 유용한 자동화 기능으로 통합되어 있지는 않습니다.
• 위임된 복구: 준신뢰 감시탑 금고가 복구 작업을 시작할 수 있도록, 복구 권한만 위임하는 기능을 제공합니다.
• 캐시 저장소 계산: 저장소가 프로덕션 환경에 초기화된 후 소프트웨어 응답성을 크게 향상시킵니다.
• CPU 최적화: 다양한 최적화 방법이 있으며, 그중 상당수는 쉽게 구현할 수 있습니다.
• 일반화: 다른 CTV 상태 머신 프로토콜을 지원하도록 소프트웨어 스택에 맞게 조정합니다.
• GPU 가속: 이 금고는 병렬 처리에 최적화된 설계 덕분에 GPU를 사용한 가속에도 적합합니다.
• 이를 통해 하드웨어 서명자를 위한 STARK 기반 검증이 가능해질 것으로 예상됩니다.

STARK 검증 방식은 매우 흥미로운 아이디어입니다. 이 방식을 사용하면 강력한 소비자용 하드웨어가 금고와 그 형식적 정확성에 대한 증거를 생성할 수 있고, 더 안전한 하드웨어 서명자는 간결한 증거를 사용하여 형식적 정확성을 검증할 수 있습니다.

(위에)