차가워지기 전: 액체 생산의 언약
비트코인 커뮤니티가 약정 최적화를 둘러싼 논의에 착수한 이후로, Liquid Network에 이미 배포된 약정과 장단점에 대해 더 자세히 알아보려는 관심이 커졌습니다. 이러한 새로운 관심에 비추어 더 많은 논의를 장려하기 위해 Liquid의 현재 약정 제안 중 일부를 검토하고 이를 비트코인에 대한 주요 제안과 비교하고 각각의 사용 사례를 검토해 보겠습니다. 액체 언약의 역사 Liquid의 Covenants는 첫 번째 Elements 사이드체인인 Alpha의 배포로 거슬러 올라갑니다. 이 사이드체인은 Opcode OP_CHECKSIGFROMSTACK(CSFS) 및 OP_DETERMINISTICRANDOM을 Elements에 도입했습니다. Alpha는 또한 OP_CAT와 같이 초기 비트코인에서 비활성화된 opcode의 고정 버전을 활성화했습니다. 이 opcode는 소셜 미디어 전반에 걸쳐 증가하는 대화에서 많은 사람들이 다시 방문하기로 선택하고 있습니다. 이러한 새로운 opcode는 Elements에서 사용할 수 있는 비트코인 스크립트 버전의 표현성을 더욱 향상시켰으며 개념 증명 Möser-Eyal-Sirer 저장소는 새로운 가능성을 설명하기 위해 CSFS를 활용하여 개발되었습니다. CSFS 구현을 통해 얻은 교훈 중 하나는 약정 지출을 수행할 때 거래 데이터를 스택에 푸시하도록 요구함으로써 약정을 더욱 복잡하게 만든다는 것입니다. 또한 개발자 경험을 통해 CSFS 규약을 사용하면 서명 해시를 구성하는 트랜잭션 데이터가 스택에서 재구성되어야 하며 잠재적으로 개발자가 관심 있는 트랜잭션 입력/출력과 관련 없는 데이터를 푸시해야 한다는 사실이 관찰되었습니다. 언약 구성을 단순화하기 위해 보다 모듈화된 접근 방식을 위해 Liquid의 Taproot 업그레이드에 내부 검사 opcode라고 불리는 30개 이상의 새로운 opcode가 도입되었습니다. 예를 들어 CSFS를 사용한 자체 검사 opcode를 사용하면 트랜잭션을 스택에 배치하여 지출 중에 트랜잭션의 보다 세부적인 부분을 검사할









