Gametaverse
왜 블록체인 게임을 검증 가능하게 해야 할까?
대규모 MMORPG 게임을 블록체인 상에서 실행할 수 있을까?
서수 명각 프로토콜의 원리와 기술적 세부 사항에 대한 논의
UTXO 내의 사토시(sats)는 어떻게 추적되며, 인스크립션 데이터는 스크립트의 어디에 저장되는지, 그리고 BRC-20을 전송할 때 왜 두 번의 작업이 필요한지에 대해 설명하겠습니다. --- ### 1. **UTXO 내 사토시(sats)의 추적 방식** 비트코인은 계좌 기반 모델이 아닌 **UTXO(Unspent Transaction Output)** 모델을 사용합니다. 각 UTXO는 특정한 양의 비트코인(사토시 단위)을 보유하며, 이는 트랜잭션 입력(input)으로 사용될 수 있습니다. - 사토시 자체는 개별적으로 주소를 가지거나 식별되지는 않습니다. - 다만, **Ordinal Theory**(서수 이론)에 따르면, 각 사토시는 채굴 순서에 따라 고유한 번호(서수 번호)를 부여받습니다. 예: 첫 번째로 채굴된 사토시는 #1, 다음은 #2 등. - 이 서수 번호를 기반으로 특정 사토시를 추적할 수 있으며, 이를 통해 어떤 사토시가 인스크립션(铭刻)되었는지를 확인합니다. - 따라서 인스크립션은 특정 서수 번호를 가진 사토시에 "첨부"되며, 해당 사토시가 포함된 UTXO를 소비할 때 그 연결성이 유지됩니다. 즉, **sats는 UTXO와 연결되어 있고, Ordinal 번호를 통해 추적**됩니다. --- ### 2. **인스크립션(铭刻) 데이터의 위치 — 스크립트 어디에 저장되나?** 인스크립션은 비트코인 트랜잭션의 **Witness**(증인) 데이터 영역 내에 삽입됩니다. 구체적으로는 `OP_RETURN`과 함께 특수한 형태의 스크립트를 사용하여, 데이터를 임베드(embed)하는 방식입니다. - 인스크립션은 일반적으로 다음과 같은 구조로 저장됩니다: ```bitcoin script OP_IF OP_PUSH <content-type> OP_PUSH <data> OP_ENDIF ``` - 이는 `OP_RETURN` 출력(output) 안에 넣어져, 노드들이 이를 처리하지 않으면서도 데이터를 블록체인에 영구 저장할 수 있게 합니다. - 데이터는 Base64 인코딩되거나, 직접 바이너리 형식으로 저장되며, 최대 4MB까지 가능(실제론 몇 KB 이하가 일반적). - 이 데이터는 **Taproot**(SegWit v1) 주소를 사용하는 트랜잭션에서 주로 활용되며, Witness 내에 포함됩니다. 요약하면, **인스크립션은 SegWit 트랜잭션의 Witness 영역 내 `OP_RETURN` 스크립트에 저장**됩니다. --- ### 3. **BRC-20 전송 시 왜 두 번의 작업이 필요한가?** BRC-20은 비트코인 ordinal 위에 구축된 토큰 표준으로, ERC-20과 유사한 기능을 제공하지만, 스마트 컨트랙트 없이 구현됩니다. 이로 인해 전송 과정이 복잡해지고, **두 단계의 트랜잭션**(Two-step transaction)이 필요합니다. #### 두 단계의 이유: 1. **배포(Deploy)** 또는 **민팅(Mint)**: - 최초에 토큰을 생성하거나, 특정 양을 민트하기 위해 인스크립션을 사용합니다. - 예: `"{"p":"brc-20","op":"deploy","tick":"ordi","max":"21000000","lim":"1000"}"` → 새로운 토큰 배포 2. **전송(Transfer)**: - 실제 토큰을 다른 사용자에게 보내기 위해서는 두 번의 트랜잭션이 필요합니다: - **Step 1: 나열(Listing)** – 사용자가 자신의 UTXO에 있는 BRC-20 토큰을 "전송 준비" 상태로 만듭니다. - 예: `{"p":"brc-20","op":"transfer","tick":"ordi","amt":"100"}` - 이 트랜잭션은 해당 토큰이 전송 가능함을 선언하지만, 실제로 받는 사람은 지정되지 않음. - **Step 2: 인용(Inscribe the transfer)** – 누군가 이 "나열된(listed)" UTXO를 참조하여, 자신을 수신자로 지정하는 새 인스크립션을 작성. - 즉, "내 주소로 보내라"는 인스크립션을 새로 만들어야 함. #### 왜 이렇게 복잡한가? - 비트코인은 스마트 컨트랙트 기능이 없으므로, **상태(state)를 직접 관리할 수 없습니다**. - 대신, 모든 동작이 **인스크립션 + Ordinal 추적**에 의존합니다. - 따라서 중앙화된 로직 없이 "누가 얼마나 가지고 있는가"를 추적하려면, 사용자가 스스로 행동을 기록해야 하며, 이 과정에서 충돌을 피하기 위해 **명시적인 두 단계 절차**가 필요합니다. 또한, 이 방식은 **메모리풀(spam) 공격이나 오해 전송을 방지**하고, 토큰 이동의 명확한 증거를 남기기 위한 설계입니다. --- ### 요약 | 항목 | 설명 | |------|------| | **Sats 추적** | Ordinal Theory 기반, 채굴 순서의 서수 번호로 각 사토시 추적 | | **인스크립션 위치** | Taproot 트랜잭션의 Witness 내 `OP_RETURN` 스크립트에 저장 | | **BRC-20 전송 2단계** | (1) 전송 준비(Listing), (2) 수신자 인용(Inscription by receiver) — 상태 관리 불가로 인한 설계 | 이러한 메커니즘은 비트코인의 단순성과 보안성을 유지하면서도 확장성을 탐색하려는 실험적 접근의 결과입니다.
P2Pool 모델을 활용한 전사슬 게임 매칭 메커니즘
DeFi의 성공은 '금융 규칙을 블록체인에 올리는 것'이라는 기술 혁신 외에도 운영과 토큰 이코노미 측면에서 맞춤형 혁신을 함께 이루어냈다.
Substack 지금 구독
