BTC 확장 개념 증명: OP_CAT 지원 BTC에서 브리지 컨트랙트 구현하기

출처: 스타크넷 중국 커뮤니티

선택한 퀵 테이크

• 비트코인에서 데모 브릿지 계약 구축에 대한 심층 분석, 기반을 마련합니다. 스타크넷의 프로덕션 등급 브리지

• 입출금 애그리게이터, 브리지, 출금 익스텐더를 위한 4개의 스마트 콘트랙트 구현

• 재귀 콘트랙트와 머클 트리를 사용하여 사용자 계정의 무결성과 보안을 유지하면서 입출금 요청을 효율적으로 일괄 처리

소개

이 백서에서는 sCrypt가 비트코인에서 데모 브리지 콘트랙트를 구축하는 방법을 자세히 살펴봅니다. 이 개념 증명 구현은 스타크넷 레이어 2(L2) 네트워크를 위한 프로덕션 등급 브릿지의 토대를 마련하는 것을 목표로 합니다. 브릿지는 여러 입출금 요청 트랜잭션을 하나의 루트 트랜잭션으로 병합할 수 있도록 설계되었으며, 이는 메인 브릿지 콘트랙트에 통합되어 메르켈 트리로 구성된 계정 집합으로 구성된 상태를 업데이트합니다.

브릿지 컨트랙트 스크립트의 복잡성 때문에 저희는 sCrypt 전용 도메인 언어(DSL)를 활용하여 구현을 작성했습니다.

개요

브릿지는 재귀적 컨트랙트 비트코인 스크립트로 구성됩니다. 여기서 '컨트랙트'는 잠금 스크립트가 지출 거래에 조건을 부과할 수 있음을 의미하며, '재귀적'은 위의 규칙이 온체인에서 지속적인 로직과 상태를 허용할 만큼 강력하다는 것을 의미합니다(모든 온체인 스마트 콘트랙트의 기본 요건).

스크립트는 일련의 트랜잭션으로 존재하며, 각 트랜잭션은 후속 트랜잭션의 구조에 제약 조건을 부과하여 현재 트랜잭션의 출력을 잠금 해제합니다. 이 체인에 새 트랜잭션이 추가될 때마다 이는 브리지 상태의 업데이트를 나타냅니다. 따라서 이 체인의 끝은 현재 브리지 상태를 유지합니다.

이미지 src="https://img.jinse.cn/7329054_image3.png">

컨트랙트 상태, 특히 해시값은 소모되지 않는 OP_RETURN 출력에 저장됩니다. 이 UTXO를 사용하지는 않겠지만 컨트랙트 스크립트를 실행할 때 해당 데이터를 검사할 수 있습니다. 구체적으로 스테이트는 다음과 같이 계정 데이터가 포함된 머클 트리의 루트 해시를 보유합니다.

머클 트리는 고정된 계정 슬롯 세트에 대한 데이터를 보유합니다. 리프 노드에는 주소와 잔액을 포함한 각 계정 데이터의 해시가 포함됩니다. 빈 계정 슬롯을 나타내기 위해 이러한 슬롯은 0바이트로 표시됩니다.

브릿지 업데이트가 있을 때마다 계정 트리가 변경됩니다. 이 업데이트를 용이하게 하기 위해 저희는 비트코인 스크립트에서 매우 효율적인 검증을 수행하는 머클 증명을 사용합니다. 업데이트는 두 가지 주요 단계로 구성됩니다. 먼저 머클 증명을 검증하여 증명 머클 트리에 특정 계정의 현재 상태가 포함되어 있는지 확인합니다. 그런 다음, 해당 계정의 새로운 상태를 계산한 후 앞서 언급한 머클 증명에서 동일한 보조 노드를 사용해 새로운 루트 해시를 도출합니다.

이미지 src="https://img.jinse.cn/7329056_image3.png">

업데이트는 입금 또는 출금이 될 수 있습니다. 브리지는 단일 트랜잭션에서 이러한 업데이트의 일괄 작업을 수행할 수 있습니다.

입금

우리의 목표는 사용자가 독립적으로 입금 또는 출금 요청을 제출할 수 있도록 하는 것입니다. 이를 위해 사용자는 입금 또는 출금 집계 컨트랙트에 개별적으로 지급되는 별도의 트랜잭션을 생성합니다. 컨트랙트는 이러한 요청을 머클 트리로 집계합니다. 이 트리의 루트 해시는 메인 브리지 컨트랙트에 병합되어 각 입금 또는 출금을 처리할 수 있습니다.

이미지 src="https://img.jinse.cn/7329057_image3.png">

예금 데이터를 해싱하고 예금 트랜잭션에서 머클 트리를 구성하는 것 외에도, 컨트랙트는 계약 출력에 잠긴 예금 사토시가 올바르게 트리의 루트 노드에 누적되도록 보장합니다. 집계 콘트랙트는 올바른 온체인 스마트 콘트랙트만이 이 자금을 사용할 수 있도록 보장합니다. (물론 프로덕션 환경에서는 사용자가 예치 거래를 취소할 수도 있습니다).

이 트리 구조의 설계는 너무 많은 입력과 출력을 포함하는 트랜잭션을 허용하지 않는 콘트랙트 스크립트 구성의 제약에서 비롯되었습니다. 트리 구조는 잠재적으로 임의의 처리량으로 확장할 수 있게 해줍니다.

출금 요청

출금 요청은 입금과 비슷하게 집계되지만, 몇 가지 차이점이 있습니다. 먼저, 사용자가 계좌에서 돈을 인출할 수 있도록 인증 방법이 필요합니다. 이는 누구나 모든 계좌에 입금할 수 있는 예금과는 다르며, 비트코인 주소가 사용되는 방식과 유사합니다. 인증은 집계 트리의 리프 노드 수준에서 이루어집니다. 출금 요청 집계 컨트랙트는 출금 주소가 리프 트랜잭션에 입력된 첫 번째 P2WPKH 주소와 일치하는지 확인합니다.

이미지 src="https://img.jinse.cn/7329058_image3.png">

이것은 주소 소유자가 출금을 요청하는 트랜잭션에 서명했으므로 출금을 승인한다는 것을 보장합니다. 입금 집계와 또 다른 미묘한 차이점은 중간 누적 금액도 해시 처리하여 트리 구조로 전달한다는 점입니다. 이는 출금을 연장할 때 이 데이터가 필요하기 때문이며, 나중에 더 자세히 설명하겠습니다.

눈치 빠른 독자라면 이 출금 요청 인증 모델에서 잠재적인 문제를 발견할 수 있습니다. 운영자가 속임수를 써서 루트 트랜잭션의 집계 트리를 생성하고 집계 트리의 데이터가 인증되지 않은 가짜 출금 요청을 통해 로컬에서 위조되는 경우 어떻게 해야 할까요? 루트 트랜잭션이 유효한 리프 트랜잭션에서 나온 것인지 확인할 수 있는 효율적인 방법이 필요합니다.

이 문제를 해결하기 위해 저희는 '제네시스 검사'라고 하는 작업을 수행합니다. 기본적으로 집계 컨트랙트는 이전 트랜잭션과 처음 두 트랜잭션, 즉 '조상 트랜잭션'을 확인합니다. 컨트랙트는 이러한 트랜잭션에 동일한 컨트랙트 스크립트가 포함되어 있는지 확인하고 동일한 검사를 수행합니다. 이러한 방식으로 귀납적 거래 내역 검사를 구현합니다. 처음 두 트랜잭션이 현재 컨트랙트와 동일한 검사를 수행하므로, 이러한 트랜잭션의 '조상'도 리프 노드(즉, 생성 트랜잭션)까지 동일한 검사를 수행한다는 것을 확인할 수 있습니다.

물론 트리의 두 가지 브랜치 모두에서 유효성 검사를 수행합니다. 따라서 각 집계 노드 트랜잭션은 총 6개의 트랜잭션을 확인합니다.

출금 확장

이제 솔루션의 마지막 부분인 출금 확장으로 넘어가 보겠습니다. 일괄 출금 요청을 처리한 후, 메인 브릿지 컨트랙트는 연장 컨트랙트에 총 출금 금액을 지급하는 출력을 강제로 생성합니다. 이 컨트랙트는 인출 요청 집계 컨트랙트가 수행한 작업을 역으로 수행하는 과정으로 생각할 수 있습니다. 이는 인출 트리의 루트 노드에서 시작하여 두 개의 분기로 확장하며, 각 분기에는 해당 분기에 지불해야 하는 해당 인출 금액이 포함됩니다. 이 과정은 페치 트리의 리프 노드까지 이어집니다. 리프 트랜잭션은 출금을 요청한 금액에 대해 계좌 소유자의 주소로 간편 결제를 실행합니다.

구현

브릿지 컨트랙트를 구현하기 위해 저희는 각각 시스템의 다양한 측면을 처리하는 각각 시스템의 다른 측면을 처리합니다. 이 섹션에서는 각 컨트랙트의 기능에 대한 간략한 개요를 제공합니다.

예금 어그리게이터 콘트랙트

예금 어그리게이터 콘트랙트는 개별 예금을 메르켈 트리로 집계한 다음 메인 브리지 콘트랙트로 병합합니다. 이러한 통합을 통해 대량 예금 처리가 가능해져 브리지에서 개별적으로 처리해야 하는 트랜잭션 수가 줄어듭니다. 또한 사용자가 독립적으로 예치금을 제출하면 나중에 운영자가 처리할 수 있습니다.

계약 빌더 기능에는 다음이 있습니다. 두 개의 매개변수:

• 운영자: 예치금을 집계할 권한을 가진 브리지 오퍼레이터의 공개 키.

운영자: 예치금을 집계할 권한을 가진 브리지 오퍼레이터의 공개 키입니다.

• bridgeSPK: 집계된 예금이 올바르게 병합되었는지 확인하는 마스터 브리지 컨트랙트의 스크립트 공개키(SPK)입니다.

예치금 집계기의 핵심 기능은 '집계' 메서드에 캡슐화되어 있습니다. 이 메서드는 다음 단계를 수행합니다.

Sighash 원본 및 운영자 서명 확인: 트랜잭션이 브리지 운영자에 의해 승인되었는지, sighash 원본이 올바른 형식이고 실행 중인 트랜잭션에 속하는지 확인합니다. 이 문서에서 sighash 원본 유효성 검사에 대해 자세히 알아보세요.

선행 트랜잭션 ID 구성 및 유효성 검사: 집계된 선행 트랜잭션이 유효하고 올바르게 참조되었는지 확인합니다.

머클 트리 집계: 증인 해시로 전달된 입금 데이터가 선행 트랜잭션에 저장된 상태와 일치하는지 확인합니다.

금액 유효성 검사: 사전 출력의 금액이 지정된 입금 금액과 일치하는지 확인하여 집계에서 자금이 올바르게 계산되는지 확인합니다.

상태 업데이트: 이전 트랜잭션의 해시값을 연결하여 새로운 해시값을 계산하고 OP_RETURN 출력에 상태를 업데이트합니다.

재진입 공격 방지: 무단 수정이나 이중 지출을 방지하기 위해 엄격한 출력 스크립트 및 금액을 적용합니다.

예금이 집계되면 메인 브릿지 증서에 병합해야 합니다. 이 프로세스는 '최종화' 방법으로 처리되며, 다음 단계가 포함됩니다.

이전 거래 검증: '집계' 방법과 마찬가지로 병합된 데이터의 무결성을 보장하기 위해 이전 거래의 유효성을 검사합니다.

스트롱>브릿지 컨트랙트와의 통합: 브릿지의 트랜잭션 ID와 스크립트 공개 키를 참조하여 집계된 예금이 메인 브릿지 컨트랙트에 올바르게 병합되었는지 확인합니다.

예금 집계 컨트랙트의 전체 소스 코드는 깃허브에서 확인할 수 있습니다.

출금 집계 컨트랙트

출금 집계 컨트랙트는 개별 출금 요청을 머클 트리로 집계하도록 설계되었습니다. 트리로 집계하도록 설계되었으며, 이는 예금 어그리게이터가 예금을 처리하는 방식과 유사합니다. 그러나 출금 작업에는 합법적인 계좌 소유자만 계좌에서 자금을 인출할 수 있도록 추가 인증이 필요합니다.

출금 애그리게이터의 핵심 기능은 다음 단계를 수행하는 "집계" 메서드에 캡슐화되어 있습니다:

선행 거래 ID 구성 및 검증: 이 프로세스는 집계된 선행 거래가 유효하고 정확하게 참조되는지 확인합니다.

소유권 증명 확인: 소유권 증명 거래를 확인하면 정당한 소유자만 계좌에서 자금을 인출할 수 있습니다.

• 소유권 증명 거래: 출금 주소의 통제권을 증명하는 거래입니다. 컨트랙트는 출금 요청의 주소가 소유권 증명 트랜잭션의 주소와 일치하는지 확인합니다.

'조상 거래'를 통한 제네시스 확인: 예금 어그리게이터와 마찬가지로, 컨트랙트는 조상 거래를 검증하여 유도 확인을 수행합니다. 이를 통해 거래 내역의 무결성을 보장하고 운영자가 무단 출금 요청을 삽입하는 것을 방지합니다.

금액 확인 및 총액 계산: 출금 요청 금액 또는 이전 집계 금액을 합산하여 출금할 총 금액을 계산하는 방법입니다.

상태 업데이트: 이전 거래의 해시와 출금 금액의 합이 포함된 새 해시를 계산합니다. 이 해시는 OP_RETURN 출력에 저장되어 상태를 업데이트합니다.

재진입 공격 방지 및 출력 강제: 무단 수정 또는 재진입 공격을 방지하기 위해 출력을 엄격하게 정의해야 합니다.

출금 집계 컨트랙트의 전체 소스 코드는 GitHub에서 확인할 수 있습니다.

브릿지 컨트랙트

브릿지 컨트랙트는 당사 시스템의 핵심 구성 요소이며 메르켈 트리에 정리된 계정과 잔액 등 브릿지 상태를 유지하는 주요 컨트랙트입니다. 앞서 설명한 어그리게이터 컨트랙트와 통합하여 입출금 작업을 처리합니다.

계약 빌더 함수에는 두 개의 매개변수가 있습니다. br>

• 운영자: 브리지 상태를 업데이트할 권한이 있는 브리지 오퍼레이터의 공개 키입니다.

• expanderSPK: 출금 프로세스 중에 사용되는 WithdrawalExpander 컨트랙트의 스크립트 공개 키(SPK)입니다.

입금 방식은 집계된 입금 거래를 처리하고 그에 따라 계정 잔액을 업데이트하는 역할을 담당합니다.

이미지 src="https://img.jinse.cn/7329084_image3.png" title="7329084" alt="QXyFh7Urp1WwUWl9Xd0j1tnloErVLHhIFU7t8wLC.jpeg">

입금 방식은 단계는 다음과 같습니다:

입금 처리 및 계정 업데이트 :

• 입금을 반복하고 "applyDeposit" 메서드를 사용하여 각 입금을 적절한 계좌에 적용합니다.

브리지 상태 및 출력 업데이트:

• 입금을 처리한 후 새 계정 Merkel Root를 계산합니다.

• 업데이트된 브리지 상태를 나타내는 새 상태 해시를 생성합니다.

• 브릿지 잔액에 총 입금액을 더하기 위해 컨트랙트 출력을 구성합니다.

• 데이터 무결성을 유지하기 위해 출력이 예상되는 형식인지 확인합니다.

출금 메서드는 집계된 출금 거래를 처리하고, 계정 잔액을 업데이트하며, 출금 확장자를 통해 할당된 자금을 준비합니다.

이미지 src="https://img.jinse.cn/7329086_image3.png" title="7329086" alt="6fIIIIpi1GvwKUarjd94LKYEyBuhAaPML5yMGKH0.jpeg">

출금 방법에서 수행되는 단계는 다음과 같습니다. br>

출금 요청 처리 및 계좌 업데이트:

• 출금 요청을 검토하고 "applyDeposit" 메서드를 사용하여 각 출금을 해당 계좌에 적용합니다.

브릿지 상태 및 출력 업데이트:

• 출금 처리 후 새 계정 메르켈 루트를 계산합니다.

• 업데이트된 브리지 상태를 나타내는 새 상태 해시를 생성합니다.

• 브릿지 잔액에서 총 출금 금액을 차감하는 컨트랙트 출력을 구성합니다.

• 총 출금 금액이 포함된 출금 연장자 컨트랙트에 대한 확장 출력을 생성합니다.

• 데이터 무결성을 유지하기 위해 출력이 예상 형식인지 확인합니다.

전체 소스 코드는 깃허브에서 확인할 수 있습니다.

출금 확장자 컨트랙트

출금 확장자는 브리지 시스템의 최종 구성 요소로, 사용자의 출금 요청에 따라 집계된 출금액을 개별 사용자에게 분배하는 역할을 담당합니다. 개별 사용자에게 분배하는 역할을 합니다. 출금집계기가 수행한 집계 프로세스를 역전시키고 집계된 출금 데이터를 다시 개별 사용자 결제에 분배합니다.

이미지 src="https://img.jinse.cn/7329089_image3.png" title="7329089" alt="pygpFaaZ5Al3uS0oWTEuTI9iHUlWNGRM0C9diHbG.jpeg">

출금 확장기의 핵심 기능은 '확장' 메서드에 캡슐화되어 있습니다. 이 메서드는 집계된 출금 데이터를 받아 사용자에게 적절한 금액을 지급하는 개별 출금 트랜잭션으로 재귀적으로 확장합니다.

리프 노드로 확장: 이 메서드가 리프 노드(개별 인출)로 확장하면 인출 데이터의 유효성을 검사하고 사용자 주소로 직접 지불하는 출력을 구성합니다.

추가 확장: 메서드가 아직 리프 노드 수준에 도달하지 않은 경우, 집계된 데이터를 두 개의 분기로 분할하고 추가 확장 트랜잭션에서 사용할 출력을 생성하여 계속 확장합니다.

<>< strong>결론

이 개념 증명 구현에서는 sCrypt 임베디드 도메인별 언어(DSL)를 사용하여 OP_CAT 지원을 기반으로 비트코인용 브리지 컨트랙트를 개발했습니다. 이 브리지는 재귀적 컨트랙트와 머클 트리를 활용하여 사용자 계정의 무결성과 보안을 유지하면서 입출금 요청을 효율적으로 일괄 처리합니다. DepositAggregator, WithdrawalAggregator, Bridge, 그리고 WithdrawalExpander, 4개의 스마트 콘트랙트를 통해 비트코인에서 상태 저장 상호작용을 관리할 수 있는 방법을 제공하여 스타크넷과 같은 2계층 네트워크와의 상호 운용성을 촉진합니다. 이 작업은 비트코인 생태계의 확장성과 기능을 향상시킬 수 있는 프로덕션급 브리지를 구축하기 위한 기술적 토대를 제공합니다.

모든 코드 구현과 엔드투엔드 테스트는 깃허브에서 확인할 수 있습니다.

[전체 글 끝]

원본 링크: https://starkware.co/blog/implementing-a-bridge-covenant-on-op-cat-. bitcoin/

미러: https://mirror.xyz/starknet-zh.eth/ zFbhQB7gfmSTV4CcTv5MRqJBUnKuwMLTNOgZ6jUgDK8