서수 비문 프로토콜의 근거와 기술적 세부사항에 대한 논의

저자: CaptainZ, 전 게임타버스DAO 연구원 출처: X, @hiCaptainZ

지난 2주 동안 BTC 생태계와 다양한 인스크립션 프로젝트에 대해 연구했는데, 원리와 기술적 세부 사항을 명확하게 제시하는 기사를 거의 찾지 못했습니다. align: left;">지난 2주 동안 BTC 생태계와 다양한 인스크립션 프로젝트를 조사해왔는데, 인스크립션이 캐스팅될 때 트랜잭션이 어떻게 시작되는지, UTXO 내에서 실제로 시세가 어떻게 추적되는지, 스크립트에서 인스크립션이 정확히 어디에 배치되는지, BRC20이 자금을 이체할 때 두 번의 작업이 필요한 이유 등 원칙과 기술적 세부 사항을 명확히 설명하는 기사를 거의 찾지 못했습니다. 송금할 때 두 번 작업해야 하는 이유는 무엇인가요? 기술적 세부 사항을 이해하지 못하면 다양한 프로토콜인 BRC20, BRC420, 아토믹스, 스탬프, 룬의 차이점을 이해하기 어렵기 때문에 이 글에서는 위의 질문에 답하기 위해 BTC 블록체인의 기본에 대해 자세히 알아보고자 합니다.

BTC의 블록 구조

블록체인은 본질적으로 다중 사용자 부기 기술이며, 컴퓨터 과학 용어로 일정 기간 동안의 기록(원장)이 블록을 형성하는 분산 데이터베이스입니다. 그런 다음 원장은 시간 순서에 따라 확장됩니다.

블록체인의 작동 원리를 설명하기 위해 엑셀로 표를 만들었습니다. 엑셀 파일은 블록체인을 나타내는데, 각 테이블은 블록을 나타내며, 블록은 560331, 560332. 부터 가장 최근의 560336까지 시간순으로 표시됩니다. 560336은 블록 내 가장 최근의 트랜잭션을 담고 있습니다. 블록의 내부 본문은 회계에서 가장 일반적으로 사용되는 이중 입력 방식으로, 주소의 한쪽은 입력인 차변으로 기록되고 다른 한쪽은 출력인 대변으로 기록됩니다. 차이점은 사용자 수준의 이체 수수료와 채굴자(장부 관리인)에게 지불하는 수수료입니다. 블록 헤더는 이전 블록의 높이, 이전 블록의 해시, 현재 블록의 생성 시간(타임스탬프), 난수를 가져옵니다. 그렇다면 탈중앙화된 장부 기술에서 다음 블록을 추적할 수 있는 권한은 실제로 누가 가지게 될까요? 바로 난수와 이에 대응하는 해시값입니다. 컴퓨팅 파워를 가진 채굴자가 현재 블록의 난수에 대한 해시를 계산하고, 조건에 맞는 해시값을 가장 먼저 얻은 채굴자가 다음 블록의 장부 작성 권한을 가지며 블록 보상과 전송 수수료를 얻게 됩니다. 마지막으로 스크립트 영역이 있는데, 일부 확장 애플리케이션에 사용할 수 있습니다. 예를 들어 스크립트 op_return은 주석 필드로 사용할 수 있습니다. 실제 블록에서 스크립트 영역은 입력 및 출력 메시지에 첨부되며, 실제로는 별도의 영역이 아니라는 점에 유의해야 합니다. 예를 들어, 입력에 첨부된 스크립트는 지갑 주소가 송금을 승인하기 위해 개인 키에 서명해야 하는 잠금 해제 스크립트(ScriptSig)이고, 출력에 첨부된 스크립트는 받은 BTC의 잠금을 해제하기 위한 조건을 설정하는 데 사용되는 잠금 스크립트(ScriptPubKey)입니다(일반적인 조건은 "적절한 개인 키를 가진 사람만 돈을 쓸 수 있다. ").

위 두 다이어그램은 원시 입력 및 출력 데이터 구조 테이블이며, 실행 수준에서 보면 실행 수준에서 스크립트는 트랜잭션 정보에 첨부된 파라미터로 표시되며, 잠금 해제 스크립트(ScriptSig)는 개인 키 인증이 필요하기 때문에 "감시 데이터"라고도 합니다.

고립된 증인과 탭루트#

비트코인 네트워크는 10년 넘게 별다른 사고 없이 운영되어 왔지만, 거래 비용이 더 이상 감당할 수 없을 정도로 급등하는 경우가 여러 번 있었습니다. 이에 따라 비트코인 개발자들은 향후 증가하는 거래량을 처리하기 위해 네트워크를 확장하는 최선의 방법에 대해 논의해 왔습니다.

이 논쟁은 2017년 비트코인 개발 커뮤니티가 세그윗이라는 기능을 구현하기 위해 소프트 포크를 사용하는 것을 지지하는 진영과 직접 블록 확장을 지원하는 "빅 블록" 진영으로 나뉘면서 절정에 달했습니다.

위에서 스크립트를 잠금 해제하려면 '위트니스 데이터' 생성을 승인하는 개인 키가 필요하다고 언급했는데, 이 위트니스 데이터를 블록에서 분리하여 블록당 수용할 수 있는 트랜잭션 수가 증가하는 것을 위장할 수 있지 않을까요? 분리된 위트니스(분리된 위트니스)는 2017년 8월에 공식적으로 활성화되었습니다. 구현 방식은 모든 트랜잭션 데이터를 트랜잭션의 기본 정보(트랜잭션 데이터)와 트랜잭션의 서명 정보(위트니스 데이터) 두 부분으로 나누고, 서명 정보를 새로운 데이터 구조에 저장하는 것을 '분리된 위트니스(Witness)'라고 합니다. "라고 하며, 새로운 블록을 생성하여 원본 트랜잭션과 별도로 전송합니다.

기술적으로 세그윗을 구현하면 거래에 더 이상 증인 데이터를 포함할 필요가 없습니다(비트코인이 원래 블록에 배치했던 1MB의 공간을 차지하지 않음). 대신, 블록의 마지막에 증인 데이터를 위한 별도의 공간이 추가로 생성됩니다. 이는 임의의 데이터 전송을 지원하며, 하드포크의 필요성을 피하기 위해 대량의 데이터를 비트코인의 블록 크기 제한 내에서 영리하게 유지하는 '블록 무게'를 할인합니다. 이는 비트코인 거래의 거래 데이터 크기 상한을 높이는 동시에 서명된 데이터의 거래 수수료를 낮춥니다. 세그윗 업그레이드 전 비트코인의 용량 상한은 1MB였으며, 세그윗 업그레이드 후에는 단순 거래의 용량 상한은 1M으로 유지되지만 격리된 증인 공간의 크기는 4MB에 달합니다.

탭루트는 2021년 11월에 구현되었으며 탭루트, 탭스크립트, 슈노르 서명이라는 새로운 디지털 서명 체계를 포함한 세 가지 비트코인 개선 제안(BIP)으로 구성되어 비트코인 사용자에게 다음과 같은 여러 가지 이점을 제공하도록 설계되었습니다. 거래 프라이버시 강화 및 거래 수수료 절감. 또한 비트코인이 더 복잡한 거래를 수행할 수 있게 되어 (새로운 옵코드 추가를 통해) 응용 범위가 넓어질 것입니다.

이번 업데이트는 탭루트 스크립트 경로(감시 데이터 공간)의 사용된 스크립트에 NFT 데이터를 저장하는 오디널스 NFT의 핵심 기능입니다. 이 업데이트를 통해 임의의 증인 데이터를 더 쉽게 구조화하고 저장할 수 있게 되어 "ord" 표준의 토대가 마련되었습니다. 데이터 요건이 완화됨에 따라 트랜잭션이 블록 크기(증인 데이터 공간) 제한인 4MB까지 전체 블록을 트랜잭션과 증인 데이터로 채울 수 있다고 가정하면 체인에 배치할 수 있는 미디어 유형이 크게 확장됩니다.

스크립트에 문자열을 넣는 것이기 때문에 문자열에 대한 제한이 있지 않냐고 질문할 수 있습니다. 스크립트가 실제로 실행되면 어떻게 될까요? 임의의 콘텐츠를 넣으면 블록을 거부하는 오류 코드가 나오지 않을까요? 그래서 OP_FALSE 지시어를 사용하게 됩니다. OP_FALSE(비트코인 스크립트에서는 "0"으로도 표시됨)는 스크립트 언어의 실행 경로가 OP_IF 브랜치에 들어가지 않고 실행되지 않은 상태로 유지되도록 합니다. 이는 고급 언어의 "주석"과 유사하게 스크립트에서 플레이스홀더 또는 작업 없음으로 작용하여 후속 코드가 실행되지 않도록 합니다.

UTXO 전송 모델

위는 BTC의 기본 원리를 공부하기 위한 컴퓨터 데이터 구조 측면에서 살펴본 것입니다. 금융 모델 측면에서 UTXO 모델에 대해 설명하겠습니다.

UTXO는 '미사용 거래 산출물'의 약자로, 실제로는 송금 시 이체되지 않고 남은 돈으로 해석할 수 있습니다. 그렇다면 비트코인은 왜 이러한 개념을 사용할까요? 이는 부기 방식의 계정 거래 모델과 계정 잔액 모델에서 시작됩니다.

우리는 오랫동안 중앙집중식 시스템을 사용해왔기 때문에 부기 방식의 계정 잔액 모델에 매우 익숙해져 있습니다. 사용자 A가 사용자 B에게 100달러를 송금하면 은행은 먼저 A의 은행 계좌에 100달러가 있는지 확인하고, 100달러가 있으면 A의 계좌에서 100달러를 차감한 다음 B의 계좌에 100달러를 더하면 이체가 완료됩니다.

그러나 비트코인의 장부 알고리즘에는 잔액이 존재하지 않습니다. 블록체인의 분산 원장에 기록되는 것은 단일 거래뿐이며, 계좌의 현재 잔액을 직접 기록하지 않습니다(잔액을 기록하려면 일반적으로 중앙화된 전용 서버 노드가 필요합니다). 예를 들어 사용자 A의 잔액이 1000달러이고 사용자 A가 사용자 B에게 100달러를 이체하면 다음과 같이 기록됩니다.

거래 1 사용자 A가 사용자 B에게 100달러를 이체

거래 2 사용자 A가 사용자 A에게 900달러를 이체(UTX)함. 사용자 A에게 $900 송금(UTXO)

거래 2는 거래이지만 기능적으로는 계정 잔액으로 작동하여 100달러 이체가 완료된 후에도 A의 계좌에 900달러가 남아 있음을 나타냅니다. 즉, 100달러를 이체한 후에도 A의 계좌에는 여전히 900달러가 남아 있습니다.

그렇다면 왜 이런 UTXO를 구축해야 할까요? BTC 블록체인에서는 계정 잔액이 아닌 트랜잭션만 기록할 수 있기 때문입니다. UTXO가 없는 경우 잔액을 계산하려면 계정의 모든 입출금 트랜잭션을 합산해야 하는데, 이는 시간과 리소스를 많이 소모하는 작업입니다. UTXO를 사용하면 잔액을 계산하기 위해 모든 거래를 역추적해야 하는 번거로움을 피할 수 있습니다.

UTXO는 코인과 동일한 기능을 가지고 있고, 부술 수 없는데, 그렇다면 금액 입력을 위한 거래 프로세스를 어떻게 구성하고 거스름돈은 어떻게 만들까요? 우리는 동전을 사용하여 비유를 할 수 있습니다 (사실, UTXO라는 단어를 볼 때마다 자동으로 "동전"으로 더 잘 번역하십시오).

밍이 콩에게 1비트코인을 송금합니다. 전체 프로세스는 다음과 같습니다. 예를 들어 Ming의 주소에 해당하는 이전 거래에서 액면가가 0.9 인 UTXO가 발견되어 1 비트 코인에 충분하지 않은 경우, 거래에서 여러 입력이 허용되므로 Ming은 액면가가 0.2 인 다른 UTXO를 발견하여이 전송 거래에서 두 개의 입력이있을 것입니다. 또한 두 개의 출력이 있는데, 그 중 하나는 액면가 1비트코인으로 샤오강의 주소로 전송됩니다. 다른 하나는 액면가 0.1비트코인인 밍의 주소로 전송되며, 이 출력이 바로 변경 사항입니다(이 예시에서 가스는 무시됨).

즉, 밍의 주머니에는 액면가 0.9와 0.2의 두 개의 코인이 있는데, 밍이 액면가 1의 코인을 지불해야 할 경우 두 개의 코인을 동시에 콩에게 건네고 콩은 이를 받아 거스름돈 0.1을 밍에게 건네는 것입니다. 따라서 이 부기 모델의 핵심은 '거스름돈 만들기' 작업을 통해 '잔액 계산'을 피하는 것입니다.

오디날 프로토콜 분류 시스템

오디날 프로토콜은 현재 BTC 생태 발생의 원천이라고 할 수 있으며, BTC를 가장 작은 단위인 sat로 균일하게 분해한 다음 각 sat에 sat으로 분해한 다음 각 sat에 일련번호를 표시하는 것입니다. 어떻게 작동할까요?

우리는 BTC의 총 개수가 2,100만 개이고, 최소 BTC를 1억 개의 sat으로 나눌 수 있다는 것을 알고 있으므로 BTC의 가장 작은 단위가 sat이고, 이 BTC가 좋고, 가장 작은 단위의 sat도 좋으며, 모두 전형적인 동질 토큰인 FT입니다. 이제 이 샛에 서수를 할당해 보겠습니다.

앞서 블록 데이터 구조에 대해 이야기할 때 트랜잭션 정보에는 입력의 주소와 금액, 출력의 주소와 금액이 명시되어야 한다고 언급했습니다. 각 블록에는 트랜잭션의 두 부분, 즉 블록 보상 중 BTC와 전송 수수료가 포함됩니다. 수수료 트랜잭션은 입력과 출력이 모두 있어야 하지만, 블록 보상은 무에서 생성된 BTC이고 입력 주소가 없으므로 "입력 출처" 필드가 비어 있으며 "코인베이스 트랜잭션"이라고도 합니다. "이 코인베이스 트랜잭션은 전체 BTC 중 2,100만 개의 출처이며, 모든 블록의 트랜잭션 목록에서 첫 번째입니다.

오디날 프로토콜은 다음과 같이 설명합니다:

1. 넘버링: 각 시총은 채굴된 순서대로 번호가 매겨집니다

   1. 넘버링: 각 시총은 채굴된 순서대로 번호가 매겨집니다

   2. 전송: FIFO 규칙에 따라 거래의 입력에서 출력으로 전송
      첫 번째 규칙은 비교적 간단하며, 채굴 보상에서 코인베이스 거래에 의해서만 번호 매기기가 생성될 수 있다는 것을 명시합니다. 예를 들어, 첫 번째 블록의 채굴 보상이 50 BTC인 경우 첫 번째 블록은 [0;1;2;... 4,999,999,999] 범위가 할당되며, 두 번째 블록의 보상도 50 BTC인 경우 두 번째 블록은 [5,000,000,000;5,000,000,001;... 9,999,999,999;...]의 범위로 할당됩니다.

   

   여기서 이해하기 어려운 부분은 UTXO에 실제로 많은 사토시가 포함되어 있는데 어떻게 이 UTXO의 모든 사토시가 동일하게 보일 수 있느냐는 점입니다. 실제로 많은 사토시가 포함되어 있는데, 어떻게 이 UTXO의 모든 사토시가 동일하게 보일 수 있을까요? 이는 실제로 두 번째 규칙에 의해 결정되므로 간단한 예를 들어보겠습니다.

   BTC의 최소 분할이 1이고 총 10개의 블록이 있으며 각 블록의 보상이 10 BTC이므로 총 블록 수가 100이라고 가정해 보겠습니다. 이 100개의 BTC에 (0~99)의 일련번호를 직접 할당할 수 있습니다. 만약 전송이 없었다면 첫 번째 블록의 10 BTC는 (0-9), 두 번째 블록의 10 BTC는 (10-19), 열 번째 블록의 10 BTC는 (90-99)라는 번호만 알 수 있을 것입니다. 지출이 없으므로 출력이 없으며, 10개의 BTC 각각에 숫자 범위만 할당할 수 있습니다.

   두 번째 블록에 두 개의 지출(출력)을 추가한다고 가정할 때, 하나는 3 BTC, 다른 하나는 7 BTC로 "잔돈"에 해당하며, 이는 다른 사람에게 3 BTC를 전송한 다음 자신에게 7 BTC의 잔돈을 지급하는 것에 해당합니다. 블록의 트랜잭션 목록에서 자신을 위한 잔돈 7 BTC가 첫 번째(숫자 10-16에 해당)이고, 다른 사람을 위한 3 BTC가 두 번째(숫자 17-19에 해당)라고 가정합니다. 이렇게 하면 출력을 전송하여 주어진 UTXO에 포함된 집합의 순서를 확인할 수 있습니다.

   각 'sat'는 'UTXO'가 아니라는 점에 유의하세요! 'UTXO'는 분할 불가능한 최소 거래 단위이므로 'sat'는 'UTXO'에만 존재할 수 있고, 'UTXO'는 가장 작은 거래 단위입니다. 그리고 는 특정 범위의 새트를 포함하며, 분할할 새트 수에 대한 새로운 출력을 생성하기 위해 특정 이후에만 사용할 수 있습니다.

   이러한 '숫자'를 표현하는 방식은 위에서 언급한 '정수 메서드'를 비롯해 10진법과 같은 다양한 형태를 지원합니다. 십진법, 차수법, 백분율법, 순수 알파벳으로만 명명하는 방법 등을 지원합니다.

   

   일련번호가 통일되면 이제 비문에 대해 생각해볼 차례입니다. 위에서 언급했듯이 텍스트, 이미지, 동영상 등 모든 데이터 유형의 파일을 4M 크기의 감시 데이터 영역에 업로드할 수 있으며, 업로드 후 파일은 자동으로 16진수로 변환되어 탭루트 스크립트 영역에 저장됩니다. 따라서 1 UTXO는 1 탭루트 스크립트 영역에 해당하며, 이 1 UTXO는 동시에 많은 사토시를 포함하게 됩니다(전체는 사토시 시퀀스의 모음이며, 더스트 공격을 방지하기 위해 단일 UTXO의 비트코인 수는 546 사토시 이상으로 제한됩니다). 오디날 프로토콜은 문서화를 쉽게 하기 위해 "바인딩 관계를 나타내기 위해 이 시퀀스 컬렉션의 첫 번째 위성 번호를 사용"(원래 백서 언어에서는 첫 번째 출력의 첫 번째 위성 번호)하도록 인위적으로 지정합니다(예: 17-19번의 위성 번호가 포함된 UTXO는 17번 대신 17번을 사용합니다). 이 컬렉션은 새겨진 콘텐츠에 바인딩됩니다.

   오디날 자산 발행 및 전송#

   오디날 NFT는 다양한 파일을 분리된 증인 영역에 업로드하고 이를 일련의 샛 시퀀스에 바인딩하는 스크립트로 보입니다. 이를 통해 BTC 체인에서 NFT 자산을 발행할 수 있습니다. 하지만 여전히 한 가지 의문이 남습니다. QWZ의 스크립트에는 입력 잠금 해제 스크립트와 출력 잠금 스크립트가 모두 포함되어 있는데, 콘텐츠를 어느 스크립트에 넣어야 할까요? 정답은 둘 다입니다. 여기서 우리는 블록체인 기술의 커밋 공개 메커니즘에 대해 언급해야 합니다.

   블록체인의 커밋-공개 메커니즘은 공정하고 투명한 정보 처리를 보장하는 프로토콜입니다. 이는 투표나 입찰과 같이 숨겨진 정보를 제출한 후 나중에 공개해야 하는 시나리오에서 자주 사용되며, 커밋-공개 메커니즘은 커밋 단계와 공개 단계의 두 가지 단계로 구성됩니다.

   1. 커밋 단계: 이 단계에서는 사용자가 자신의 정보(예: 투표 선택 사항 또는 입찰 가격)를 제출하지만 이 정보는 암호화됩니다. 일반적으로 사용자는 이 정보의 해시(즉, 암호화된 정보 요약본)를 생성한 다음 이 해시를 블록체인으로 전송합니다. 해시 함수의 특성상, 해시 함수는 원본 메시지와 관련하여 되돌릴 수 없는 고유한 출력(해시 값)을 생성할 수 있습니다. 즉, 해시 값에서 원본 메시지를 유추할 수 없다는 뜻입니다. 이 프로세스는 제출 시 메시지의 기밀성을 보장합니다.

   2. 공개 단계: 나중에 미리 정해진 시간에 사용자는 자신의 원본 메시지를 공개하고 이전에 제출한 해시와 일치한다는 것을 증명해야 합니다. 이는 일반적으로 원본 메시지와 해시 생성에 사용된 추가 데이터(예: 난수 또는 '솔트')를 함께 제출하는 방식으로 이루어집니다. 그러면 네트워크는 이 원본 메시지의 해시값이 이전에 제출된 해시값과 동일한지 확인합니다. 일치하면 원본 메시지가 유효한 것으로 받아들여집니다.

   앞서 말했듯이, 비문은 UTXO에 포함된 sats 시퀀스 세트와 함께 바인딩되어야 하며, UTXO는 블록의 출력물이므로 출력물의 잠금 스크립트에 첨부되어야 합니다. 그러나 BTC의 전체 노드는 네트워크 전체에서 모든 UTXO 컬렉션을 로컬로 유지 관리하고 전송해야 합니다. 만약 10,000개의 UTXO 잠금 스크립트에 직접 업로드된 4M 동영상 파일이 10,000개라면, 모든 풀 노드는 엄청난 저장 공간과 초고속 인터넷 속도를 갖춰야 하며, 전체 체인이 바로 무너진다고 할 수 있습니다. 따라서 유일한 해결책은 입력에 있는 잠금 해제 스크립트에 콘텐츠를 넣은 다음 해당 콘텐츠가 다른 출력을 "가리키도록" 하는 것입니다.

   따라서 서수 자산의 캐스팅은 두 단계로 이루어집니다. 월렛은 이 두 단계를 결합하여 트랜잭션을 구성하는 동시에 부모-자식 트랜잭션인 커밋-리베일을 구성하므로 한 단계만 있는 것처럼 느껴지고 가스 비용을 절약할 수 있습니다).

   캐스팅 단계에서 사용자는 먼저 파일의 해시를 커밋 트랜잭션(A 주소에서 B 주소로 송금)의 UTXO에 있는 잠금 스크립트에 업로드하는데, 이는 해시이기 때문에 노드 전체 UTXO 데이터베이스 공간을 많이 차지하지 않습니다. 다음으로, 사용자는 공개 트랜잭션이라고 하는 새로운 트랜잭션(B 주소에서 A 주소로 송금)을 생성하는데, 이때 입력값은 이전 커밋 트랜잭션의 파일 해시가 포함된 것과 동일한 UTXO를 사용해야 하며, 해당 입력값에 대한 잠금 해제 스크립트에는 원본 비문 파일이 포함되어야 합니다. 백서의 원문을 그대로 옮기면 "첫째, 커밋에서 비문 내용이 포함된 스크립트에 커밋하는 탭루트 출력을 생성합니다. 둘째, 공개 트랜잭션에서 커밋 트랜잭션에서 생성된 출력을 사용하여 체인에 비문 내용을 표시합니다."

   오디날 NFT와 BRC20은 전송 단계에서 약간의 차이가 있는데, 오디날 NFT는 전체 전송이기 때문에 일반적인 BTC 전송과 유사하게 UTXO에 묶여 있는 NFT만 수취인에게 직접 전송하면 됩니다. 그러나 BRC20은 사용자 지정 금액 전송을 포함하기 때문에 두 단계로 나뉘며, 첫 번째 단계는 "TRANSFER" 인스크라이브, 두 번째 단계는 "" TRANSFER"), 인스크라이브 트랜잭션의 첫 번째 단계는 실제로 암시된 커밋-리버럴 부모-자식 쌍을 가진 오르디날 NFT의 캐스팅 프로세스와 유사하며, 전송 트랜잭션의 두 번째 단계는 특정 UTXO에 묶인 BRC20 자산을 수신자에게 직접 전송하는 일반 오르디날 NFT의 전송과 유사합니다. 일부 지갑은 시간과 가스를 절약하기 위해 세 가지 트랜잭션(부모-자식-손자 트랜잭션)을 동시에 구축합니다.

   

   요약하면, 커밋 트랜잭션은 새겨진 콘텐츠(원본 콘텐츠의 해시)를 시리얼 번호가 있는 sats에 바인딩하는 데 사용됩니다. (UTXO) 바인딩으로 바인딩하고, 공개 트랜잭션은 콘텐츠(원본 콘텐츠)를 표시하는 데 사용됩니다. 이 부모-자식 트랜잭션 쌍이 함께 NFT의 캐스팅을 완료합니다.

   예제 포함 P2TR#

   캐스팅에 대한 위의 기술적 논의가 끝나지 않은 이유는 공개 트랜잭션이 커밋 트랜잭션의 비문 정보를 실제로 어떻게 검증할 수 있는지 궁금하기 때문입니다. 트랜잭션을 구성할 때 서로에게 돈을 이체할 때 왜 자신의 AB 주소가 필요할까요? 저는 비문을 입력할 때 두 개의 지갑이 필요하다고 생각하지 않았습니다. 탭루트의 주요 업그레이드 중 하나인 P2TR을 소개합니다.

   P2TR(Pay-to-Taproot)은 탭루트의 업그레이드로 도입된 새로운 유형의 비트코인 거래로, 사용자가 하나의 공개 키 또는 다중 서명 지갑이나 스마트 계약과 같은 더 복잡한 스크립트를 사용하여 비트코인을 사용할 수 있게 함으로써 개인정보 보호와 유연성을 향상시킵니다. 개인정보 보호 및 유연성. 이는 단일 트랜잭션에서 여러 지출 조건을 효율적으로 인코딩할 수 있는 머클라이즈드 추상 구문 트리(MAST)와 슈노르 서명을 사용하여 달성할 수 있습니다.

   • 지출 조건 만들기
     P2TR 트랜잭션을 생성하려면 사용자는 먼저 단일 공개 키 또는 비트코인 지출 요건을 지정하는 더 복잡한 스크립트와 같은 지출 조건을 정의합니다(예. 다중 서명 지갑 또는 스마트 콘트랙트).

   • 탭루트 출력 생성
     그런 다음 사용자는 단일 공개 키(공개 키는 지출 조건을 나타냄)가 포함된 탭루트 출력을 생성합니다. 이 공개 키는 "조정"이라는 프로세스를 사용하여 사용자의 공개 키와 스크립트의 해시의 조합에서 파생됩니다. 이를 통해 출력값이 표준 공개키처럼 보이도록 하여 블록체인의 다른 트랜잭션과 구별할 수 없게 합니다.

   • 비트코인 사용하기
     사용자가 비트코인을 사용하려면 단일 공개 키를 사용하거나(사용 조건이 충족되는 경우) 원본 스크립트를 공개하고 사용 조건을 충족하는 데 필요한 서명 또는 데이터를 제공할 수 있습니다. 탭스크립트를 사용하면 보다 효율적이고 유연하게 지출 조건을 이행할 수 있습니다.

   • 트랜잭션 검증하기
     채굴자와 노드는 제공된 슈노르 서명과 데이터를 지출 조건과 비교하여 트랜잭션을 검증합니다. 조건이 충족되면 트랜잭션이 유효한 것으로 간주되며 비트코인을 사용할 수 있습니다.

   • 개인정보 보호 및 유연성 향상
     P2TR 거래는 비트코인을 사용할 때 필요한 지출 조건만 공개하기 때문에 높은 수준의 개인 정보 보호가 유지됩니다. 또한 MAST와 슈노르 서명을 사용하면 여러 지출 조건을 효율적으로 인코딩할 수 있어 전체 트랜잭션 크기를 늘리지 않고도 더 복잡하고 유연한 트랜잭션을 처리할 수 있습니다.

   위는 P2TR에서 커밋 공개 메커니즘이 사용되는 방식이며, 실제 예시를 통해 설명합니다.

   블록체인 브라우저 https://www.blockchain.com/  를 사용하여 앞선 두 단계의 커밋 공개를 포함한 서수 이미지 NFT의 캐스팅 프로세스를 살펴봅니다.

   먼저, 커밋 트랜잭션의 해시 ID가 (2ddd90ddf7c929c8038888fc2b7591fb999c3ba3c3c7b49d54d01f8db4af585c)임을 확인할 수 있습니다. 이 트랜잭션의 출력에는 비문 데이터가 포함되어 있지 않으며(실제로는 16-메커니즘 이미지 파일의 해시), 웹 페이지에 관련 비문 정보가 없다는 것을 알 수 있습니다. 이 출력의 (bc1p4mtc.....) 주소는 실제로는 "조정" 프로세스에 의해 생성된 임시 주소(스크립트의 잠금 해제 조건에 대한 공개 키를 나타냄)이며, 탭루트 메인 주소(bc1pg2mp...) 는 개인 키를 공유합니다. 이 트랜잭션의 두 번째 UTXO는 반환 "변경" 작업입니다. 이러한 방식으로 첫 번째 UTXO에 포함된 sats에 비문 콘텐츠가 바인딩됩니다.

   

   다음으로, 해시 ID가( e7454db518ca3910d2f17f41c7b215d6cba00f29bd186ae77d4fcd7f0ba7c0e1). 여기에서 조례 비문에 대한 정보를 볼 수 있습니다. 이 트랜잭션의 입력 주소는 이전 트랜잭션에서 생성된 임시 출력 주소와 정확히 일치합니다(bc1p4mtc.....). 입력의 잠금 해제 스크립트에는 원본 이미지의 헥스 파일이 포함되어 있으며, 0.00000546BTC(546 사토시)의 출력은 이 NFT를 자체 탭루트 홈 주소(bc1pg2mp...)로 전송합니다. 선입선출 원칙과 "바인딩은 첫 번째 출력의 첫 번째 사토시 수"라는 사실에 따라, 전후의 두 UTXO에 포함된 사토시 수는 변경되더라도 바인딩의 사토시 수는 동일하게 유지됩니다. 따라서 이 비문이 위치한 사토시를 찾을 수 있습니다(1893640468329373).

   (https://ordinals.com/sat/1893640468329373)

   

   이 두 트랜잭션(부모-자식 트랜잭션)은 발행과 동시에 지갑에 의해 메모리 풀에 제출되므로 가스가 하나만 필요하며, 채굴자가 기록 및 브로드캐스트할 동일한 블록에 있을 가능성이 높습니다(위 예시의 두 트랜잭션은 790468 블록에서 정확히 같은 시간에 존재합니다). 그런 다음 채굴자와 노드는 공개를 확인하여 트랜잭션이 같은 블록에 있는지 확인합니다. 그런 다음 채굴자와 노드는 공개 트랜잭션의 입력으로 제공된 16진수 이미지의 슈노르 서명과 해시를 커밋 트랜잭션의 출력 잠금 스크립트에 있는 16진수 이미지의 해시와 비교하여 검증합니다. 두 해시가 같으면 해당 트랜잭션은 유효한 것으로 간주되어 비트코인 UTXO를 사용할 수 있으며, 두 트랜잭션은 자연스럽게 BTC의 블록체인 데이터베이스에 영구적으로 기록되고 NFT 이미지도 자연스럽게 저장되어 표시됩니다. 두 해시가 다르면 두 트랜잭션은 취소되고 비문은 실패합니다.

   BRC20 프로토콜과 인덱서

   오디날 프로토콜의 경우, 텍스트인 NFT(이더의 전리품에 해당)와 이미지인 이미지를 새겨 넣습니다. NFT(이더의 PFP에 해당), 음악 조각을 새기면 오디오 NFT가 됩니다. 코드 조각을 새기고 그 코드가 "FT 동종 토큰을 발행"하는 코드 조각이라면 어떨까요?

   BRC20은 오디날 프로토콜을 활용하여 토큰의 공급량, 최대 발행 단위, 고유 코드 등 토큰의 다양한 속성을 설명하는 코드 조각이 포함된 JSON 데이터 형식으로 비문을 설정함으로써 토큰을 정확하게 배포, 채굴 및 전송합니다. 발행 단위 및 고유 코드. 이전 기사에서 언급했듯이 BRC20 토큰은 본질적으로 반동형 토큰인 SFT이며, 이는 어떤 경우에는 NFT로, 다른 경우에는 FT로 거래될 수 있다는 것을 의미하는데, 어떻게 "다른 경우"에 대한 이러한 제어가 가능할까요? 답은 바로 인덱서입니다.

   인덱서는 실제로는 장부이며, 데이터베이스에 들어오는 정보를 다양한 카테고리로 기록하는 데 사용됩니다. 서수 프로토콜에서 인덱서는 입력과 출력을 추적하여 주소에서 주소로 정렬된 좌표가 어떻게 바뀌는지 결정합니다. BRC-20 프로토콜에서 인덱서는 주소 간 비문의 토큰 잔액 변화를 기록하는 추가 기능을 가지고 있습니다.

   장부 관리자의 관점에서 토큰이 존재하는 다양한 형태를 볼 수 있습니다. BRC20 프로토콜 토큰은 실제로 3중 데이터베이스에 존재합니다. 첫 번째 레이어1에서 장부는 BTC 채굴자이고, 데이터베이스 유형은 "체인 데이터베이스"이며, 생성된 BTC는 FT 자산입니다. 두 번째 레이어2에서 장부는 서수 인덱서이고, 데이터베이스 유형은 "관계형 데이터베이스"이며, 일련 번호가 있는 생성된 샛은 NFT 자산입니다. 세 번째 레이어3에서 부키퍼는 BRC20 인덱서이고, 데이터베이스 유형은 "관계형 데이터베이스"이며, 생성된 BRC20 자산은 FT 자산입니다. BRC20을 "시트"의 관점에서 생각하면 (기록되는) 서수 인덱서의 관점에 서게 되고, 이는 당연히 NFT이며, 분할된 "조각"의 관점에서 생각하면 (특히 중앙화된 거래소에 충전된 후) BRC20이 FT 자산임을 알 수 있습니다. BRC20을 분할된 "하나"로 생각할 때(특히 중앙화된 거래소에 충전한 후), (해당 인덱서에 의해 또는 중앙화된 거래소의 서버에 의해 기록된) BRC20 인덱서의 관점에서는 당연히 FT입니다. 이를 통해 우리는 다른 계층의 장부가 존재하기 때문에 반동질성 토큰 SFT가 존재한다는 결론을 내릴 수 있습니다.

   블록체인은 분산화된 데이터베이스이며, 그렇기 때문에 "체인화된 데이터베이스"를 유지하기 위해 함께 일하는 장부 관리자 그룹인 마이너가 존재합니다(체인화된 데이터베이스만이 진정한 탈중앙화가 될 수 있기 때문입니다). 그러나 우리는 여전히 중앙화된 "관계형 데이터베이스"로 돌아가고 있습니다. 이것이 얼마 전 서수 프로토콜 이니시에이터인 BRC20 프로토콜 이니시에이터들이 인덱서를 위한 유니샛 지갑을 업그레이드할지 여부에 대해 의견이 일치하지 않는 이유입니다.

   그러나 10 년 이상의 개발 끝에 업계는 많은 "탈 중앙화"경험을 축적했으며 인덱서는 관계형 대신 "체인 데이터베이스"가 될 수 없습니다. 데이터베이스? 인덱서가 관계형 데이터베이스 대신 "체인 데이터베이스"를 사용할 수 있나요? 보안과 탈중앙화를 위해 사기 증명이나 ZKP를 사용할 수 있나요? 비트코인 생태계에서 DA에 대한 수요가 다른 DA로 확산되어 멀티체인 생태계가 번성할 수 있을까요? 저는 더 많은 가능성을 보는 것 같습니다.

   참고자료

   https://www.aixinzhijie.com/books/261/master_bitcoin/_book/

   < p style="text-align: 왼쪽;">https://learnblockchain.cn/article/5717

   https://zhuanlan.zhihu.com/p/ 361854961

   https://www.odaily.news/post/5187233

   https://learnblockchain .cn/article/5376

   https://www.panewslab.com/zh/articledetails/1301r1ibp79c.html

   https://docs.ordinals.com/inscriptions.html

   https://thebitcoinmanual.com/articles/pay- to-taproot-p2tr/