By Bitcoin Magazine - 6개월 전 - 읽는 시간: 6분
차가워지기 전 : 생산 Nn Liquid의 언약
그 이후로 Bitcoin 커뮤니티가 성약의 최적화를 둘러싼 논의에 착수하면서, 그들의 장단점과 이미 배포된 성약에 대해 더 자세히 알아보려는 관심이 커지고 있습니다. 액체 네트워크.
이러한 새로운 관심에 비추어 더 많은 논의를 장려하기 위해 Liquid의 현재 계약 제안 중 일부를 검토하고 이를 다음과 같은 주요 제안과 비교해 보겠습니다. Bitcoin 각각의 사용 사례를 검토합니다.
액체 언약의 역사
Liquid의 Covenants는 첫 번째 Elements 사이드체인 배포까지 거슬러 올라갈 수 있습니다. 알파. 이 사이드체인은 Opcode OP_CHECKSIGFROMSTACK(CSFS) 및 OP_DETERMINISTICRANDOM을 Elements에 도입했습니다. Alpha는 초기에 비활성화된 opcode의 수정된 버전도 활성화했습니다. Bitcoin같은 OP_CAT—많은 사람들이 소셜 미디어 전반에 걸쳐 증가하는 대화에서 다시 방문하기로 선택하는 opcode입니다. 이러한 새로운 opcode는 버전의 표현성을 더욱 향상시켰습니다. Bitcoin Elements에서 사용 가능한 스크립트 및 개념 증명 뫼저-에얄-시러 금고 새로운 가능성을 보여주기 위해 CSFS를 활용하여 개발되었습니다.
CSFS 구현을 통해 얻은 교훈 중 하나는 약정 지출을 수행할 때 거래 데이터를 스택에 푸시하도록 요구함으로써 약정을 더욱 복잡하게 만든다는 것입니다. 또한 개발자 경험을 통해 CSFS 규약을 사용하면 서명 해시를 구성하는 트랜잭션 데이터가 스택에서 재구성되어야 하며 잠재적으로 개발자가 관심 있는 트랜잭션 입력/출력과 관련 없는 데이터를 푸시해야 한다는 사실이 관찰되었습니다.
언약 구성을 단순화하기 위해 30개 이상의 새로운 opcode가 호출되었습니다. 내성 opcode Liquid의 Taproot에 소개되었습니다. 업그레이드 보다 모듈화된 접근 방식을 원합니다. 예를 들어 CSFS를 사용한 자체 검사 opcode를 사용하면 트랜잭션을 스택에 배치하여 지출 중에 트랜잭션의 보다 세부적인 부분을 검사할 수 있습니다. 이렇게 하면 감시를 통해 부분 트랜잭션 데이터를 수집하고 이에 따라 스택의 서명 해시를 수집해야 하는 책임이 줄어듭니다.
주요 계약 제안
현재, Bitcoin 커뮤니티에서는 SIGHASH_ANYPREVOUT(APO), OP_TXHASH, CSFS, OP_CAT, OP_TLUV, MATT opcode OP_CHECKCONTRACTVERIFY(CCV), OP_VAULT 및 OP_CHECKTEMPLATEVERIFY(CTV)를 포함한 잠재적인 언약 제안의 세탁 목록을 논의하고 있습니다. 간단낮은 수준에서 많은 성약과 유사한 기능을 구현할 수 있는 차세대 스크립트 언어인 는 잠재적인 경로이기도 합니다. Bitcoin (나중에 이에 대해 다시 살펴보겠습니다).
더 쉬운 보안 방법에 대한 요구를 해결하기 위해 만들어진 VAULT opcode에 대해 많은 이야기가 있었습니다. bitcoin 사용자를 위해. 이 opcode를 사용하면 두 개의 주소(타임록 후 핫 지갑 또는 즉시 콜드 지갑)에만 사용할 수 있는 주소에 코인을 잠글 수 있습니다. 몇 가지 다른 변형 방식이 제안되었지만 CTV를 먼저 채택하는 것이 중요합니다.
CTV는 스택에서 해시를 읽고 이를 지출 거래 데이터의 지정된 하위 집합 해시와 비교하는 opcode입니다. 그 유연성은 혼잡 제어, 저장소 및 기초적인 지불 풀을 포함하되 이에 국한되지 않는 다양한 애플리케이션 세트를 활성화할 것을 약속합니다.
Opcode 외에도, 언약을 가능하게 하는 한숨에 대한 제안이 있었습니다. 이 목적을 위한 가장 인기 있는 두 가지 제안은 APO와 SIGHASH_GROUP입니다. APO는 구현을 위한 전제 조건으로 널리 인식되는 SIGHASH_NOINPUT opcode의 발전입니다. 엘투. Eltoo를 통해 가능해진 많은 개선 사항 중 하나는 오래된 채널 상태를 방송할 때 상대방이 자금을 몰수하도록 강요하는 페널티 메커니즘을 제거한 것입니다. 이를 통해 보다 사용자 친화적이고 효율적인 라이트닝 네트워크가 가능해졌습니다.
Liquid Opcode로 유사한 기능 달성
Liquid에는 CTV 및 VAULT opcode가 없지만 CSFS 및 VAULT opcode는 있습니다. CAT 성약을 위해. 앞서 언급한 자체 검사 opcode와 함께 더욱 좁게 정의된 opcode를 사용함으로써 개발자는 사이드체인을 강화하기 위해 CTV 및 VAULT와 유사한 기능으로 새로운 재정적 가능성을 열었습니다.
예를 들어, 숙련된 Liquid 개발자이자 레이어 2 프로토콜 Ark의 창시자인 Burak은 VAULT 에뮬레이션 James O'Beirne과의 한 토론에서 Liquid 계약 opcode 사용 X.
마찬가지로 APO 기능을 구현하는 방법은 CSFS를 통해 가능해졌습니다. 이것 데모 현재 Liquid에서 Eltoo와 같은 레이어 2 프로토콜을 활성화하는 다양한 opcode를 활용했지만 제안된 APO 유형 계약 사용에 비해 복잡성이 추가되고 트랜잭션 크기가 더 커졌습니다. 더욱이 이 구성은 Taproot 트랜잭션에는 적용되지 않으므로 자체적인 형태로 복잡성이 추가됩니다.
실제 작동 중인 Liquid Opcode
많은 애플리케이션이 이미 Liquid의 언약 opcode를 활용하고 있습니다. 최근 언약 제안자인 스티븐 루즈(Steven Roose)는 한정된 이전에 생각했던 OP_TXHASH에 대한 사양이 개발되었습니다. 신청 Liquid의 충실한 채권을 위해. 이 계약은 증인이 이중 지출의 증거를 제시할 경우 소각될 자금에 적용됩니다.
후지머니Vulpem Ventures가 개발한 알고리즘 스테이블 코인인 Fuji USD(FUSD)가 또 다른 주목할만한 예입니다. 이는 페그를 유지하기 위해 순전히 오라클 정보에 의존하며 분산 방식으로 발행될 수 있습니다. 그것은 결합 이를 달성하기 위한 서명 확인 및 자체 검사 opcode가 필요하며 가장 중요한 부분은 모두 체인에서 감사 가능하다는 것입니다.
Liquid에 대한 기타 약정 적용에는 옵션 계약 및 기밀 자산 기반 대출. 블록스트림 연구팀은 백서 지난해(첨부 참조) 블로그 게시물) 전자에 대해 새로운 내성 opcode 세트를 사용하여 이러한 옵션 계약을 구성할 수 있는 방법을 설명합니다. 이러한 새로운 opcode를 사용하면 사용자는 커버드 콜 옵션 계약의 양쪽을 나타내는 토큰을 신뢰할 수 없게 생성하고 원하는 반대 위치를 판매할 수 있습니다. 이러한 방식으로 체결된 계약은 부분 채우기도 지원합니다. 즉, 계약을 생성한 사용자는 '계약 규모'라고 하는 사용자가 지정한 최소 담보 자산 금액의 배수에 해당하는 포지션을 판매할 수 있습니다.
Liquid First를 사용하지 않는 이유는 무엇입니까?
으로 Bitcoin 생태계는 언약 opcode에 관해 건전한 논쟁을 계속하고 있으며, Liquid는 유사한 목표를 충족하지만 뚜렷한 구현을 갖춘 자체 도구 세트를 제공합니다. 대화가 발전함에 따라 두 사람 사이의 상호 작용을 관찰하는 것이 흥미로울 것입니다. Bitcoin의 기본 제안과 Liquid의 이미 구체적이고 살아있는 계약 관련 기능 및 에뮬레이션 Bitcoin Elements Script를 사용하여 구현된 언약 제안.
또 다른 새로운 기술은 다음과 같습니다. 간단, 검증 가능한 프로그래밍 언어 blockchain. 단순성 언어는 함께 구성될 때 표현적인 프로그램을 만들 수 있는 매우 좁은 의미 체계의 연산으로 정의됩니다. 언어는 또한 검증 가능합니다. 이는 단순성 프로그램에 대한 주장을 수학적으로 증명하기 위한 방법을 설정할 수 있음을 의미합니다.
단순성의 표현적 특성을 통해 스크립트의 언약 opcode를 원활하게 이식할 수 있으므로 안정성이 향상되고 예상치 못한 동작이 줄어듭니다. Bitcoin 연구원 산켓 칸잘카르 이미 CTV를 위해 이 작업을 수행했습니다. 사용 속어, 더 읽기 쉬운 Bitcoin그는 단순함으로 컴파일되는 중심 프로그래밍 언어를 사용하여 오늘날 누구나 시도해 볼 수 있는 실행 가능한 개념 증명으로 의미론을 복제할 수 있었습니다.
Bitcoin 개발자들은 2년 2024분기를 목표로 하는 Liquid의 Simplicity 통합 덕분에 실제 환경에서 s-lang을 사용할 수 있는 기회를 곧 갖게 될 것입니다. s-lang은 Vault 및 위임과 같은 보다 복잡한 애플리케이션 구축을 Liquid에 가져올 것입니다. PR 초안은 다음에서 검토할 수 있습니다. 링크.
와 오랜 역사 나중에 포팅된 아이디어의 얼리 어답터로서 Liquid의 Bitcoin, 자신의 제안의 실행 가능성을 보여주고자 하는 사람들을 위한 제안은 아이디어를 먼저 검증하기 위해 Liquid에서 라이브로 시도하는 것입니다. 기존 Liquid 약정 및 자체 검사 opcode를 사용하여 여러 약정 관련 opcode가 에뮬레이션 가능한 것으로 나타났기 때문입니다.
따라서 다음에 누군가가 새 언약을 제안할 때 물어볼 가치가 있습니다. 먼저 Liquid에서 사용해 보는 것은 어떨까요?
이로 손님 게시물입니다 랜디 나르. 표현 된 의견은 전적으로 자신의 것이며 BTC Inc 또는 Bitcoin 매거진.