이 글은 개별 계약 제안에 대한 심층 분석을 다룬 시리즈의 네 번째 기사입니다.
James O’Beirne가 BIP 345에서 제안한 OP_VAULT(후에 Greg Sanders가 공동 저자로 추가됨)는 금고를 구현하기 위해 설계된 계약입니다. 이는 금고의 구축을 완료하기 위해 CTV(또는 TXHASH 또는 기타 유사한 연산 코드)에 추가적으로 의존합니다.
제안이 어떻게 작동하는지 살펴보기 전에 금고가 달성하고자 하는 목표를 살펴보겠습니다.
금고의 목적은 비트코인 저장의 보안을 향상시키는 것입니다. 이는 금고에서 지출을 시도할 때 지연 기간을 도입함으로써 이루어집니다. 금고에서 비트코인을 직접 보낼 수 있는 것이 아니라, 금고는 비트코인을 “중간 지점” 주소로만 보낼 수 있도록 제한합니다. 금고에서 인출된 동전이 이 중간 지점 상태에 있는 동안, 사용자는 이를 언제든지 자신의 통제 하에 있는 깊은 콜드 스토리지 지갑(이상적으로는 지리적으로 분산된 금고 다중 서명)으로 지출할 수 있으며, 오직 그 깊은 콜드 스토리지로만 가능합니다. 미리 정의된 타임락이 지나면 동전은 최종 목적지로 지출될 수 있습니다.
현재 미리 서명된 거래를 통해 이 작업을 수행할 수 있지만, 이는 상당한 복잡성, 비효율성, 유연성 부족 및 자금 손실 위험을 동반합니다.
미리 서명된 거래를 사용하려면 사전에 한 번에 인출할 금액, 금고에서 인출하는 거래의 수수료 비율, 완전히 인출하기 전의 중간 주소를 결정해야 하며, 그런 다음 이 모든 거래를 미리 서명하는 데 사용된 개인 키를 안전하게 삭제해야 합니다.
이 아키텍처의 큰 문제는 미리 결정된 금액, 수수료 등의 전반적인 제한 외에도 주소 재사용이 안전하지 않다는 점입니다. 미리 서명된 거래 금고 방식에서는 예치금이 초기 금고 거래를 미리 서명하는 데 사용된 주소로 전송되며, 이는 금고 거래에 서명한 후 모든 다른 키와 함께 삭제됩니다. 주소 재사용은 나쁜 관행이지만, 누군가가 이전에 사용한 주소로 자금을 보내는 것을 막을 수는 없습니다. 이후에 예치된 자금은 금고 키가 모두 삭제되었기 때문에 영원히 잃어버리게 됩니다.
또한, 금고에 대한 모든 예치는 새로운 키 세트를 새로 설정해야 하며, 새로운 거래 세트에 대해 미리 서명하는 의식을 다시 수행해야 하며, 새로운 키 세트를 안전하게 삭제하고 모든 정보를 적절하게 저장해야 합니다. 모든 예치는 금고 설정 중에 무언가 잘못될 기회를 생성하며, 마지막 예치 이후 시스템이나 장치가 손상된 경우 누군가가 자금을 훔치려 할 기회를 제공합니다.
미리 서명된 거래 금고는 번거롭고 복잡한 구조이며, 각 사용이 자금 손실로 이어질 수 있는 무시할 수 없는 위험을 초래할 만큼의 복잡성을 제공합니다.
CTV를 사용하면 키를 안전하게 삭제할 필요가 없게 하는 등의 개선이 가능하지만, 나머지 복잡성과 위험은 여전히 남아 있습니다. 금액과 수수료는 여전히 미리 정의되어야 합니다. 주소 재사용은 여전히 자금 손실로 이어질 수 있습니다.
OP_VAULT 작동 방식
OP_VAULT는 Taproot에 기반하여 설계되었으며, 전체 설계는 tapscript를 사용하고 taptrees 및 스크립트 지출 경로의 존재에 의존합니다. 또한 전체 금고를 구축하기 위해 CTV(또는 TXHASH/유사 기능)의 사용에 의존합니다.
이 제안은 실제로 두 개의 연산 코드, OP_VAULT와 OP_VAULT_RECOVER로 구성됩니다. OP_VAULT는 금고에서 인출을 트리거하는 데 사용되며, OP_VAULT_RECOVER는 트리거된 인출을 깊은 복구 지갑으로 스윕하는 데 사용됩니다. 이 아이디어는 인출을 위한 OP_VAULT 경로와 안전한 콜드 지갑으로 중간 인출된 자금을 스윕하기 위한 UP_VAULT_RECOVER 경로가 있는 taptree를 구성하는 것입니다. 이 taptree가 바로 당신의 금고입니다.
OP_VAULT는 OP_VAULT로 제한된 동전의 거래 출력이 어떻게 보여야 하는지를 제한함으로써 작동합니다. 이 연산 코드는 증인에서 다음을 기대합니다:
- 탭리프 스크립트 본문
- 스크립트 업데이트를 위한 데이터 조각 수
- 인출을 위한 출력 인덱스
- 금고로 돌아가는 자금을 위한 출력 인덱스
- 금고로 돌아가는 사토시의 양
OP_VAULT는 금고로 돌아가는 자금의 정확한 양이 맞는지 확인하고, 그 출력의 스크립트가 입력에서 지출되는 taptree와 동일한지 확인합니다. 또한 탭리프 스크립트 본문과 제공된 데이터 변수를 결합하여 전체 탭리프 스크립트를 만듭니다. 그런 다음 인출을 위해 지정된 출력이 입력에서 지출되는 taptree와 동일한 스크립트를 가지고 있는지 확인합니다. 단 지출되는 탭리프는 증인으로부터 제공된 데이터와 함께 조합된 탭리프 스크립트로 교체됩니다.
이 마지막 트릭은 탭리프가 처음에 taptree의 일부임을 확인하기 위해 머클 트리의 내부 노드가 존재해야 하기 때문에 가능합니다. 새로운 스크립트를 나머지 트리의 알려진 내부 잎과 해싱하면 오직 그 잎만 변경되었음을 보장합니다. 동적으로 채워질 스크립트의 템플릿은 금고 생성 시 정의됩니다. 일반적인 금고 사용 사례의 경우 스크립트 템플릿은 단순히 인출을 트리거할 때 제공된 해시와 함께 타임락된 CTV 지출 경로가 될 것입니다.
OP_VAULT_RECOVER는 훨씬 간단합니다. 복구 스크립트의 해시와 복구 거래를 위한 출력 인덱스를 가져옵니다. 그 출력은 미리 정의된 해시와 정확히 일치하는 스크립트를 포함해야 하며, 복구되는 입력의 모든 자금이 그 출력으로 가야 합니다.
이 두 스크립트는 “게이트”될 수 있으며, 즉 특정 키의 서명을 제공하여 인출을 트리거하거나 복구를 시작할 수 있습니다. 이는 몇 가지 트레이드오프가 있습니다. 복구 권한 키를 잃어버리면 인출 트리거 키가 도난당했을 때 더 이상 복구 거래를 트리거할 수 없습니다. 그러나 이를 통해 각 입력의 해당 출력을 수동으로 지정하여 동일한 거래에서 여러 금고 UTXO에서 복구를 시작할 수 있습니다.
OP_VAULT의 장점
명백히 금고입니다. OP_VAULT는 미리 서명된 거래 또는 CTV 기반 금고의 모든 주요 제한 사항을 깔끔하게 해결합니다. 제한된 미리 결정된 단위나 미리 결정된 수수료가 없으며, 주소 재사용의 위험이 없고, 매번 예치할 때마다 키 삭제와 같은 높은 보안 문제를 처리할 필요가 없습니다.
하지만 단순히 금고보다 훨씬 더 유연합니다. 이것이 설계될 때 의도된 사용 사례였지만, 이는 taptree가 원하는 경우 다음 UTXO로 실제로 전달되도록 보장하는 훨씬 더 일반적인 계약입니다. 미리 정의된 종료 조건이 어느 정도의 유연성을 가지고 있습니다.
OP_VAULT를 사용하여 드라이브체인과 매우 유사한 것을 만들 수 있습니다. 3-6개월의 매우 긴 타임락을 가진 금고 템플릿을 생성합니다(드라이브체인 인출과 유사). 어떤 스크립트에 대해서도 권한 게이트가 없고 템플릿을 공개합니다. 이제 사람들은 그 금고 스크립트로 자금을 보내 금고에 자금을 예치할 수 있습니다. 누구나 OP_VAULT 경로에서 지출하고 자신의 인출 거래에 대한 CTV 해시를 포함하여 인출을 제안할 수 있습니다. 채굴자는 단순히 유효하지 않은 인출 거래를 채굴하지 않음으로써 이를 시행할 수 있으며, 악의적인 채굴자가 악의적인 인출 트리거를 채굴한 경우 다음 정직한 채굴자는 자금을 다시 금고로 돌릴 수 있습니다.
이는 BIP에서 권장하는 동일한 스크립트 템플릿을 사용하여 수행할 수 있는 작업입니다. 인출을 위한 스크립트 템플릿은 임의적이며, 따라서 OP_VAULT가 가능하게 할 수 있는 자가 지속 계약의 유형에 대해 매우 일반적일 수 있습니다.
마무리 생각
OP_VAULT는 미리 서명된 거래 금고(또는 CTV와 같은 더 간단한 계약 금고)가 가지고 있는 제한, 복잡성 및 위험 없이 적절한 금고를 가능하게 하는 목표를 분명히 달성합니다. 그러나 그렇게 함으로써 원래 목표를 달성하기 위해 상당히 넓고 일반화된 기능 세트를 도입하게 되었습니다.
이 제안은 비교적 매끄럽고 안전한 금고 기능을 가능하게 할 것이지만, 또한 많은 다른 가능성을 열어줍니다. 드라이브체인은 채굴자 추출 가능 가치(MEV)와 관련된 상당한 위험을 동반합니다. 이러한 기능을 활성화하는 것의 단점과 인센티브 문제 및 결과는 잘 구성된 금고를 가능하게 하는 것의 장점과 비교해야 합니다.
OP_VAULT는 비교적 성숙한 제안이지만, 그것이 가능하게 하는 기능의 정도는 가볍게 접근해서는 안 됩니다.
