비트코인 커뮤니티가 계약 최적화에 대한 논의를 시작한 이후로, Liquid Network에 이미 배포된 계약과 그 거래 비용에 대해 더 배우고자 하는 관심이 커지고 있습니다.
이러한 새로운 관심을 바탕으로 추가 논의를 촉진하기 위해, Liquid의 현재 계약 제공을 검토하고 이를 비트코인의 주요 제안들과 비교하며 각각의 사용 사례를 살펴보겠습니다.
Liquid의 계약 역사
Liquid의 계약은 첫 번째 Elements 사이드체인인 Alpha의 배포로 거슬러 올라갑니다. 이 사이드체인은 OP_CHECKSIGFROMSTACK (CSFS)와 OP_DETERMINISTICRANDOM을 비롯한 여러 opcodes를 Elements에 도입했습니다. Alpha는 또한 초기 비트코인에서 비활성화된 opcodes의 고정 버전을 가능하게 했으며, 많은 사람들이 소셜 미디어에서 다시 논의하고 있는 OP_CAT과 같은 opcode도 포함되어 있습니다. 이러한 새로운 opcodes는 Elements에서 사용 가능한 비트코인 스크립트 버전의 표현력을 더욱 향상시켰으며, 새로운 가능성을 보여주기 위해 CSFS를 활용한 개념 증명 Möser-Eyal-Sirer 금고가 개발되었습니다.
CSFS를 구현하면서 얻은 교훈 중 하나는 계약 지출을 수행할 때 거래 데이터를 스택에 푸시해야 하므로 계약이 더 복잡해진다는 것입니다. 개발자 경험에 따르면, CSFS 계약의 경우 서명 해시를 구성하는 거래 데이터가 스택에서 재구성되어야 하며, 이는 개발자들이 관심 있는 거래 입력/출력과 관련 없는 데이터를 푸시해야 할 수도 있음을 나타냅니다.
계약 구성을 단순화하기 위해 Liquid의 Taproot 업그레이드에서 30개 이상의 새로운 introspection opcodes가 도입되어 보다 모듈화된 접근 방식을 제공합니다. 예를 들어, CSFS와 함께 사용하는 introspection opcodes는 지출 중 거래의 더 세분화된 부분을 스택에 배치하여 검사할 수 있게 합니다. 이는 증인을 통해 부분 거래 데이터를 조립하는 책임을 덜어주며, 따라서 스택에서 서명 해시를 처리하는 데 도움을 줍니다.
주요 계약 제안
현재 비트코인 커뮤니티는 SIGHASH_ANYPREVOUT (APO), OP_TXHASH, CSFS, OP_CAT, OP_TLUV, MATT opcode OP_CHECKCONTRACTVERIFY (CCV), OP_VAULT 및 OP_CHECKTEMPLATEVERIFY (CTV)를 포함한 잠재적인 계약 제안 목록에 대해 논의하고 있습니다. Simplicity는 많은 계약과 유사한 기능을 낮은 수준에서 구현할 수 있는 차세대 스크립팅 언어로, 비트코인에 대한 잠재적인 경로이기도 합니다.
VAULT opcode에 대한 논의가 많았으며, 이는 사용자에게 비트코인을 보다 쉽게 안전하게 보관할 수 있는 방법을 제공하기 위해 만들어졌습니다. 이 opcode는 동결 후 핫 월렛이나 즉시 콜드 월렛으로만 지출할 수 있는 주소에 코인을 잠글 수 있게 합니다. 여러 다른 변형 계획이 제안되었지만, 이는 먼저 CTV를 도입해야 합니다.
CTV는 스택에서 해시를 읽고 이를 지출 거래 데이터의 지정된 하위 집합의 해시와 비교하는 opcode입니다. 그 유연성은 혼잡 제어, 금고 및 기본적인 결제 풀을 포함하되 이에 국한되지 않는 다양한 응용 프로그램을 가능하게 할 것으로 기대됩니다.
opcode 외에도 계약을 가능하게 하는 sighash에 대한 제안이 있었습니다. 이 목적을 위한 두 가지 가장 인기 있는 제안은 APO와 SIGHASH_GROUP입니다. APO는 eltoo 구현을 위한 전제 조건으로 널리 인식되는 SIGHASH_NOINPUT opcode의 발전입니다. eltoo로 가능해진 많은 개선 중 하나는 구식 채널 상태를 방송할 때 다른 당사자가 자금을 포기하도록 강요하는 패널티 메커니즘을 제거하는 것입니다. 이는 더 사용자 친화적이고 효율적인 라이트닝 네트워크를 가능하게 합니다.
Liquid opcode로 유사한 기능 달성하기
Liquid는 CTV와 VAULT opcode는 없지만, 계약을 위한 CSFS와 CAT는 있습니다. 이러한 보다 좁게 정의된 opcode를 앞서 언급한 introspection opcodes와 함께 사용함으로써, 개발자들은 CTV와 VAULT와 유사한 기능을 통해 사이드체인을 보강할 수 있는 새로운 재정적 가능성을 열었습니다.
예를 들어, 경험이 풍부한 Liquid 개발자이자 레이어-2 프로토콜 Ark의 창시자인 Burak은 X에서 James O’Beirne와의 논의에서 Liquid 계약 opcode를 사용한 VAULT의 에뮬레이션을 시연했습니다.
유사하게, CSFS를 사용하여 APO 기능을 달성하는 방법도 가능해졌습니다. 이 데모는 오늘날 Liquid에서 eltoo와 같은 레이어-2 프로토콜을 가능하게 하는 다양한 opcode를 활용했지만, 제안된 APO 유형 계약의 사용에 비해 복잡성이 증가하고 거래 크기가 커지는 단점이 있습니다. 또한, 이 구성은 Taproot 거래에 적용되지 않아 자체적으로 추가 복잡성을 초래합니다.
Liquid opcode의 실제 적용
많은 응용 프로그램이 이미 Liquid의 계약 opcode를 활용하고 있습니다. 최근 OP_TXHASH에 대한 사양을 정의한 계약 지지자인 Steven Roose는 Liquid에서 충성 채권을 위한 응용 프로그램을 개발했습니다. 이 계약은 증인에서 이중 지출의 증거가 제시될 경우 소각될 자금에 적용됩니다.
Vulpem Ventures에서 개발한 알고리즘 스테이블코인 Fuji Money의 Fuji USD (FUSD)도 주목할 만한 예입니다. 이는 순수하게 오라클 정보를 기반으로 페그를 유지하며, 분산된 방식으로 발행될 수 있습니다. 이를 달성하기 위해 서명 검증 및 introspection opcodes의 조합을 사용하며, 가장 중요한 점은 모든 것이 체인에서 감사 가능하다는 것입니다.
Liquid에서의 계약의 다른 응용 프로그램으로는 옵션 계약 및 기밀 자산 기반 대출이 있습니다. Blockstream Research 팀은 작년에 이러한 옵션 계약을 새로운 introspective opcodes를 사용하여 어떻게 구성할 수 있는지 설명하는 백서를 발표했습니다. 이러한 새로운 opcodes는 사용자가 신뢰할 수 없는 방식으로 커버드 콜 옵션 계약의 양측을 나타내는 토큰을 생성하고, 원하는 반대 포지션을 판매할 수 있도록 합니다. 이러한 방식으로 만들어진 계약은 부분 채우기를 지원하므로, 계약을 생성한 사용자는 ‘계약 크기’라고 불리는 담보 자산의 최소 금액의 배수를 나타내는 포지션을 판매할 수 있습니다.
왜 Liquid에서 먼저 시도하지 않을까?
비트코인 생태계가 계약 opcode에 대한 건강한 논의를 계속하는 가운데, Liquid는 유사한 목표를 충족하지만 독특한 구현을 제공하는 도구 세트를 제공합니다. 대화가 발전함에 따라, 비트코인의 원주율 제안과 Liquid의 이미 구체적이고 실시간으로 운영되는 계약 관련 기능 및 Elements Script를 사용하여 구현된 비트코인 계약 제안 간의 상호 작용을 지켜보는 것이 흥미로울 것입니다.
또한, 블록체인을 위한 검증 가능한 프로그래밍 언어인 Simplicity라는 새로운 기술이 다가오고 있습니다. Simplicity 언어는 함께 구성될 때 표현력이 풍부한 프로그램을 만들 수 있는 매우 좁은 의미의 연산으로 정의됩니다. 이 언어는 또한 검증 가능하므로, Simplicity 프로그램에서 제기된 주장을 수학적으로 증명할 수 있는 방법이 확립될 수 있습니다.
Simplicity의 표현력 있는 특성은 Script의 계약 opcode를 원활하게 이식할 수 있게 하여 더 큰 신뢰성과 예기치 않은 행동을 줄입니다. 비트코인 연구원 Sanket Kanjalkar는 이미 CTV에 대한 이 작업을 수행했습니다. 그는 Simplicity로 컴파일되는 보다 읽기 쉬운 비트코인 중심 프로그래밍 언어인 s-lang를 사용하여 작동 가능한 개념 증명을 위해 의미를 복제할 수 있었습니다.
비트코인 개발자들은 Liquid의 Simplicity 통합 덕분에 곧 실제 환경에서 s-lang를 사용할 기회를 갖게 될 것입니다. 이는 2024년 2분기를 목표로 하고 있습니다. s-lang는 Liquid에서 금고 및 위임과 같은 더 복잡한 응용 프로그램의 구성을 가져올 것입니다. 초안 PR은 다음 링크에서 검토할 수 있습니다.
Liquid가 비트코인으로 나중에 이식된 아이디어의 초기 채택자로서 긴 역사를 가지고 있는 만큼, 제안의 실행 가능성을 보여주고자 하는 사람들에게는 아이디어를 먼저 Liquid에서 실시간으로 검증해보는 것이 좋습니다. 여러 계약 관련 opcode가 기존 Liquid 계약 및 introspection opcode를 사용하여 에뮬레이션될 수 있음이 입증되었습니다.
따라서 누군가 새로운 계약을 제안할 때, Liquid에서 먼저 시도해보는 것이 좋지 않을까요?
이 글은 Randy Naar의 게스트 포스트입니다. 표현된 의견은 전적으로 그들의 것이며 BTC Inc 또는 Bitcoin Magazine의 의견을 반드시 반영하지는 않습니다.
