제레미 루빈은 2주 전에 ‘Un’FE’d Covenants’라는 제목의 제안을 발표했습니다 (FE = 기능적 암호화). 지난 1, 2년 동안 비트코인에 대한 계약 제안에 대한 지속적인 논의가 있었던 가운데, 그의 제안은 새로운 실용적인 옵션을 제시합니다. 지금까지 모든 계약 제안은 소프트 포크(실제 opcodes), 검증되지 않은 암호화 기술(기능적 암호화)의 개발 및 구현, 또는 사용하기 위한 터무니없이 높은 금전적 비용(콜라이더스크립트)을 요구했습니다.
제레미의 제안은 소프트 포크를 요구하지 않으며, 사용자가 이를 활용하기 위해 부담스럽고 비현실적인 비용을 부과하지 않습니다. 이러한 기능을 위한 대가는 근본적으로 다른 보안 모델입니다. 오라클 시스템과 슬래싱이 가능한 BitVM 기반 채권을 사용함으로써, 현재 비트코인에서 계약을 에뮬레이트할 수 있습니다.
오라클
이 계획의 첫 번째 부분은 다양한 계약 조건을 시행하는 오라클입니다. 이는 비교적 간단한 설정이며, 제레미의 제안에 필요한 첫 번째 구성 요소입니다. 이 계획에서 오라클은 자금의 관리 책임을 지며, 계약 조건의 시행을 맡고 있습니다. 오라클이 각 코인에 대해 시행되는 계약 조건을 로컬에서 추적할 필요가 없도록 하는 것이 중요합니다. 이는 오라클의 데이터베이스가 손상되거나 분실될 경우, 모든 사람의 코인에 대한 정직한 시행을 처리하는 방법을 모르는 상태 위험을 초래합니다. 이 문제를 해결하기 위해 제레미는 Taproot를 활용합니다.
Schnorr 기반 키는 데이터를 해시하여 공개 키를 수정함으로써 “조정”될 수 있습니다. 이는 수정된 키에 서명할 수 있도록 해당 개인 키의 조정을 가능하게 하며, 공개 키를 조정하는 데 사용된 데이터가 해당 키에 의해 커밋되었음을 증명할 수 있게 합니다. 오라클이 키를 생성하고, 사용자가 자신의 계약 프로그램으로 그 키를 조정함으로써 오라클이 시행해야 할 내용을 커밋하면서 그 정보를 저장하는 부담을 사용자에게 유지할 수 있습니다.
오라클은 단일 당사자에게 신뢰를 최소화하기 위해 연합될 수도 있습니다. 여기서 사용자는 결과 주소를 간단히 로드하고, 조건을 시행하고 싶을 때마다 지출 거래, 오라클 프로그램 및 거래가 계약 조건을 충족함을 증명하는 데 필요한 증인 데이터를 가지고 오라클에 접근합니다. 거래가 계약 규칙에 따라 유효하면 오라클이 서명합니다.
결과가 사전에 알려진 간단한 계약의 경우, 예를 들어 CHECKTEMPLATEVERIFY (CTV)와 같은 경우, 사용자는 즉시 오라클이 계약을 시행하는 거래에 대해 사전 서명하도록 할 수 있으며, 필요할 때까지 이를 지연시킬 수 있습니다.
추가 기능이 필요한 중요한 시나리오는 롤업과 같은 상태 기반 계약으로, 정기적으로 진행되며 실제 상태(사용자의 현재 잔액)를 추적해야 합니다. 이러한 계약의 경우, 오라클이 서명하는 거래는 OP_RETURN을 사용하여 계약의 현재 상태에 커밋해야 하며, 이를 통해 오라클은 전체 이력을 위한 증인 데이터를 다운로드하지 않고도 롤업 또는 다른 시스템을 업데이트하는 각 거래를 효율적으로 검증할 수 있습니다. 이는 오라클이 상태를 로컬에 저장해야 하는 것을 방지하기 위한 것으로, 위에서 언급한 바와 같이 위험을 초래합니다.
장기적으로 오라클의 데이터 요구 사항은 제로 지식 증명을 사용하여 최적화할 수 있으며, 이를 통해 오라클은 서명 요청을 받은 거래가 계약 규칙을 따르는지를 원시 증인 데이터를 검증하지 않고도 단순히 증명을 검증할 수 있습니다. 그러나 롤업과 같은 시스템의 경우, 시스템에서 나가기 위해 필요한 데이터가 사용자에게 제공되어야 하므로 오라클에 직접 연락하여 자금을 회수할 필요가 있을 때 이를 소지하고 있어야 합니다.
BitVM 채권
지금까지 이 계획은 전적으로 신뢰 기반입니다. 본질적으로 다른 사람에게 돈을 주고 그들이 임의의 계약 조건을 시행할 수 있다고 믿는 것입니다. 위의 계획을 약간 수정함으로써, 이는 순수한 신뢰 대신 암호 경제적 인센티브로 보안될 수 있습니다.
위에서 설명한 바와 같이 OP_RETURN은 상태 기반 계약을 추적하는 데 사용되어야 합니다. OP_RETURN은 계약 거래의 증인 데이터를 게시하여 조건이 올바르게 충족되었음을 증명하는 데에도 사용될 수 있습니다.
BitVM 회로를 구성하여 오라클이 서명한 거래가 시행하고 있는 계약의 조건과 성공적으로 일치하는지를 검증할 수 있습니다. 생성된 키와 자금이 계약 조건에 커밋된다는 점을 기억하세요. 즉, 데이터와 주소에서 지출되는 거래가 BitVM 인스턴스에 입력될 수 있습니다.
그런 다음 오라클은 BitVM 운영자에게 담보 채권을 게시해야 할 수 있으며(운영자도 오라클이 잘못 고소당할 경우 청구할 수 있는 채권을 게시해야 합니다). 이렇게 하면 채권의 가치가 오라클에 의해 보장된 계약의 가치보다 크기만 하면 시스템을 안전하게 사용할 수 있습니다. 오라클이 시행하는 계약의 조건을 위반할 방법이 없으며, 그렇지 않으면 총체적으로 손실을 입게 됩니다.
트레이드 오프
여기에는 합의 규칙에서 계약을 단순히 구현하는 것보다 물질적으로 더 나쁜 명확한 트레이드 오프가 있습니다. 첫째, 오라클은 오라클이 시행하는 계약을 사용하기 위해 온라인 상태여야 하고 접근 가능해야 합니다. CTV와 같은 사전 서명된 계약을 제외하고, 사용자가 계약을 시행해야 할 때 오라클이 오프라인 상태라면 시행할 수 없습니다. 오라클이 서명하기 위해 반드시 존재해야 합니다.
둘째, 오라클 채권에 대한 유동성 요구 사항은 시스템이 널리 채택될 경우 엄청나게 커질 수 있습니다. 이는 합의 수준에서 계약 opcodes의 원주율 구현과 비교할 때 믿을 수 없을 만큼 비효율적입니다.
마지막으로, BitVM 채권 계획이 작동하기 위해 온체인에 게시해야 하는 추가 데이터는 원주율 계약 구현보다 블록 공간 사용 측면에서 훨씬 비효율적입니다.
전반적으로 이 제안은 원주율 계약만큼 효율적이고 안전하지 않습니다. 반면에, 만약 우리가 조기 경직화의 최악의 시나리오에 처하게 된다면, 이는 검증되지 않은 암호화 기술이나 최종 사용자에게 부과되는 완전히 비현실적인 비용에 의존하지 않고 비트코인에 계약을 끼워 넣을 수 있는 매우 실용적인 방법입니다.
제레미는 우리가 비트코인에서 구축할 수 있는 디자인 공간을 확장할 수 있는 최악의 경우 옵션을 제공했습니다.
