符文協議技術詳解

符文協議（Runes Protocol）由比特幣核心開發者 Casey Rodarmor 於 2023 年底推出，是比特幣區塊鏈上的一種新型代幣協議。作為 Ordinals 協議的演進版本，符文協議旨在解決 BRC-20 標準帶來的 UTXO 膨脹問題，同時提供更高效、更簡潔的代幣創建與轉移機制。本文深入探討符文協議的技術架構、協議設計、數據結構、共識機制、以及與其他比特幣代幣標準的比較。

一、符文協議的設計背景與動機

1.1 比特幣代幣標準的演進

比特幣區塊鏈上的代幣發行經歷了多個階段的演進：

彩色比特幣（Colored Coins）：2012-2013 年提出的概念，通過在比特幣交易的特定 UTXO 上附加元數據來表示其他資產。這種方法雖然創新，但實現複雜，且容易與其他比特幣交易混淆。

Counterparty：2014 年推出的協議，使用 OP_RETURN 存儲代幣數據。Counterparty 允許用戶創建代幣和執行簡單的智能合約，但需要修改比特幣客戶端才能完整支持。

OMNI Layer：原名 Mastercoin，與 Counterparty 类似，使用 OP_RETURN 存儲協議數據。USDT 早期版本曾基於 OMNI Layer 發行。

RGB：2017 年提出的客户端验证协议，将代币数据存储在比特币链下，只在链上存储所有权证明。RGB 提供了更强的隐私保护，但实现复杂度较高。

Ordinals 與 BRC-20：2023 年初，Casey Rodarmor 推出 Ordinals 协议，允许将任意数据刻录到比特币的 satoshi 上。随后，社区创建了 BRC-20 代币标准，利用 Ordinals 的刻录功能创建可替代代币。

1.2 BRC-20 的問題與符文的誕生

BRC-20 標準雖然簡單易用，但存在顯著的技術問題：

UTXO 膨脹：BRC-20 代幣餘額存儲在大量的 UTXO 中。每次代幣轉移都會創建新的 UTXO，導致比特幣節點的 UTXO 集合快速增長。截至 2024 年中期，僅 BRC-20 代幣就佔用了數百萬個 UTXO，嚴重影響比特幣網路的運行效率。

效率低下：BRC-20 的餘額驗證需要完整掃描所有相關的刻錄交易，這對於輕節點和錢包來說是沉重的負擔。

設計複雜性：BRC-20 使用 JSON 格式存儲代幣數據，這在比特幣區塊鏈的語境下顯得不够優雅，增加了解析的複雜性。

基於這些問題，Casey Rodarmor 設計了符文協議，採用完全不同的方法來存儲和管理代幣餘額。

二、符文協議的核心設計原則

2.1 資源效率優先

符文協議的核心理念是最小化比特幣網路資源消耗，這體現在多個方面：

OPRETURN 存儲：符文協議使用比特幣交易的 OPRETURN 輸出空間來存儲代幣轉移指令，而非像 BRC-20 那樣在每個 satoshi 上刻錄。這大大減少了區塊鏈數據的存儲負擔。

UTXO 優化：符文協議採用「帳戶代幣」（Account-Like）模型，每個地址的代幣餘額可以存儲在單一 UTXO 中，而非像 BRC-20 那樣需要多個 UTXO。這顯著減少了 UTXO 集合的增長。

簡化驗證：符文協議的設計使得驗證代幣餘額更加高效，輕節點可以快速同步和驗證代幣狀態。

2.2 向後兼容性

符文協議在設計時充分考慮了與現有比特幣基礎設施的兼容性：

無需分叉：符文協議不需要對比特幣進行任何軟分叉或硬分叉，直接利用現有的 OP_RETURN 功能。

現有錢包支持：符文轉移可以通過標準的比特幣交易完成，現有的比特幣錢包理論上可以支持（儘管需要軟件升級）。

Ordinals 兼容性：符文協議與 Ordinals 協議共存，可以在同一筆比特幣交易中包含 Ordinals 刻錄和符文轉移。

三、符文協議的數據結構

3.1 OP_RETURN 輸出結構

符文協議使用比特幣交易的 OP_RETURN 輸出來存儲代幣操作指令。其數據結構如下：

OP_RETURN <protocol-tag> <rune-id> <amount> <flags>

協議標籤（Protocol Tag）：用於識別這是符文協議的交易。具體為 ASCII 字元串 "ORDP" 的前綴。

符文 ID（Rune ID）：標識特定符文代幣的唯一 identifier。符文 ID 是一個 128 位整數，通常表示為十進制數字。

數量（Amount）：要轉移的符文數量。符文協議支持高精度的數量表示。

標誌（Flags）：用於指示特殊操作，如鑄造（Mint）、刻錄（Etch）等。

符文轉移示例：

交易輸入：
- 地址 A：10 RUNES

OP_RETURN 數據：
- OP_RETURN
- 0x4f5250 50（"ORP" 前綴）
- 123456789（符文 ID）
- 5（轉移數量）
- 0（標準轉移標誌）

交易輸出：
- 地址 B：5 RUNES
- 地址 A：5 RUNES（找零）
- （比特幣輸出）

3.2 符文 ID 的分配機制

符文 ID 是識別每種符文代幣的唯一標識符。其分配機制如下：

基於區塊高度：符文 ID 按照「刻錄」（Etch）交易發生的順序分配。第一個刻錄的符文獲得 ID 1，第二個獲得 ID 2，以此類推。

搶佔机制：如果多個刻錄交易在同一區塊中，符文 ID 的分配順序取決於交易在區塊中的位置（由 coinbase 參數決定）。

# 符文 ID 分配概念
class RuneIdAllocation:
    """
    符文 ID 分配機制
    """

    def __init__(self):
        self.next_rune_id = 1
        self.block_heights = {}

    def allocate_rune_id(self, transaction, block_height, tx_position):
        """
        分配符文 ID
        基於區塊高度和交易位置
        """
        if block_height not in self.block_heights:
            # 新區塊，從當前 ID 開始
            self.block_heights[block_height] = self.next_rune_id
        else:
            # 同一區塊，遞增
            self.block_heights[block_height] += 1

        # 同一區塊內的交易，按 tx_position 排序
        rune_id = self.block_heights[block_height] + tx_position

        return {
            'rune_id': rune_id,
            'block_height': block_height,
            'tx_position': tx_position,
            'decimal_id': self.to_decimal(rune_id, block_height)
        }

    def to_decimal(self, rune_id, block_height):
        """
        將符文 ID 轉換為可讀格式
        """
        # 符文 ID 使用 64:64 位編碼
        # 高 64 位：區塊高度
        # 低 64 位：區塊內位置
        return (block_height << 64) | rune_id

3.3 符文刻錄（Etching）

刻錄是創建新符文代幣的操作，相當於以太坊智能合約中的代幣部署。刻錄操作包含以下參數：

代幣名稱（Name）：符文的名称，必須是唯一的。名稱長度最多 28 個字元，可以使用 UTF-8 字符。

代幣符號（Symbol）：代幣的符號，通常為 1-8 個字符。

可分割性（Divisibility）：代幣可分割的小數位數，範圍為 0-18。預設為 0（不可分割）。

最大供應量（Cap）：代幣的最大供應量。如果不設置，則為無限供應。

基礎費用（Base Fee Rate）：代幣轉移的基礎費用率。

里程碑（Terms）：可選的代幣發放條款，如最大鑄造數量、開放時間等。

# 符文刻錄示例
class RuneEtching:
    """
    符文刻錄操作
    """

    def __init__(self):
        self.rune_id = None

    def create_rune(self, name, symbol, divisibility=0, cap=None, terms=None):
        """
        創建新符文
        """
        # 構建刻錄 OP_RETURN
        etching_data = {
            'op': 'etching',
            'name': name,
            'symbol': symbol,
            'divisibility': divisibility,
            'cap': cap,  # 最大供應量，None 表示無限
            'terms': terms,  # 可选的發放條款
            'timestamp': self.get_current_timestamp()
        }

        # 編碼為符文協議格式
        encoded = self._encode_etching(etching_data)

        # 創建比特幣交易
        tx = self._build_etching_transaction(encoded)

        return {
            'transaction': tx,
            'rune_id': self._calculate_rune_id(tx),
            'etching_data': etching_data
        }

    def _encode_etching(self, data):
        """
        將刻錄數據編碼為 OP_RETURN 格式
        """
        # 符文協議使用二進制編碼
        # 這裡是簡化的概念表示

        encoded = b''

        # 協議標籤
        encoded += b'ORDP'

        # 操作碼
        encoded += self._encode_varint(0x01)  # 刻錄操作碼

        # 名稱
        name_bytes = data['name'].encode('utf-8')
        encoded += self._encode_varint(len(name_bytes))
        encoded += name_bytes

        # 符號
        symbol_bytes = data['symbol'].encode('utf-8')
        encoded += self._encode_varint(len(symbol_bytes))
        encoded += symbol_bytes

        # 可分割性
        encoded += self._encode_varint(data['divisibility'])

        # 最大供應量
        if data['cap'] is not None:
            encoded += self._encode_varint(0x01)  # 有上限標誌
            encoded += self._encode_amount(data['cap'])
        else:
            encoded += self._encode_varint(0x00)  # 無上限

        return encoded

3.4 符文轉移

符文轉移是將符文從一個地址轉移到另一個地址的操作。轉移過程如下：

1. 創建交易：發送方創建包含符文轉移指令的比特幣交易
2. 解析 OPRETURN：網路中的符文節點解析 OPRETURN 數據
3. 驗證餘額：確認發送方地址有足夠的符文餘額
4. 更新狀態：更新雙方的符文餘額

# 符文轉移流程
class RuneTransfer:
    """
    符文轉移操作
    """

    def __init__(self, rune_id):
        self.rune_id = rune_id

    def transfer(self, from_address, to_address, amount, utxo_set):
        """
        執行符文轉移
        """
        # 1. 驗證發送方餘額
        sender_balance = self._get_balance(from_address, self.rune_id, utxo_set)

        if sender_balance < amount:
            raise ValueError("餘額不足")

        # 2. 獲取發送方的符文 UTXO
        sender_utxos = self._get_rune_utxos(from_address, self.rune_id, utxo_set)

        # 3. 選擇要使用的 UTXO
        selected_utxos, change = self._select_utxos(sender_utxos, amount)

        # 4. 構建轉移 OP_RETURN
        transfer_data = {
            'op': 'transfer',
            'rune_id': self.rune_id,
            'amount': amount,
            'output_index': 1  # 輸出索引
        }

        encoded = self._encode_transfer(transfer_data)

        # 5. 構建比特幣交易
        tx = self._build_transaction(
            inputs=selected_utxos,
            outputs=[
                {'address': to_address, 'amount': amount, 'rune': True},
                {'address': from_address, 'amount': change, 'rune': True},
                {'address': 'change', 'amount': 'miner_fee', 'rune': False}
            ],
            op_return=encoded
        )

        return {
            'transaction': tx,
            'amount_transferred': amount,
            'change_returned': change,
            'fee': self._estimate_fee(tx)
        }

    def _select_utxos(self, available_utxos, amount):
        """
        選擇要使用的 UTXO
        目標：最小化找零輸出數量
        """
        selected = []
        total_value = 0

        # 選擇足夠的 UTXO
        for utxo in sorted(available_utxos, key=lambda x: x['amount']):
            selected.append(utxo)
            total_value += utxo['amount']

            if total_value >= amount:
                break

        change = total_value - amount

        return selected, change

3.5 可分割性與數量表示

符文協議支持代幣的可分割性，這是通過在小數點後添加額外位來實現的：

可分割性參數（Divisibility）：決定代幣可分割的小數位數。例如：

• divisibility = 0：不可分割，整數數量
• divisibility = 2：最多 2 位小數（如 100.50）
• divisibility = 8：最多 8 位小數，類似比特幣的 satoshi

內部表示：在區塊鏈上，符文數量以整數存儲。顯示時，協議會根據 divisibility 參數自動進行小數點調整。

可分割性示例：

Divisibility = 0（不可分割）：
- 內部存儲：100
- 顯示：100

Divisibility = 2：
- 內部存儲：10050
- 顯示：100.50

Divisibility = 8（類似比特幣）：
- 內部存儲：100000000
- 顯示：1.00000000

四、符文協議的共識與驗證機制

4.1 協議層共識

符文協議運行在比特幣區塊鏈之上，這意味著：

不修改比特幣共識：符文協議不對比特幣的共識規則進行任何修改。它只是在比特幣交易的 OP_RETURN 輸出中添加額外數據。

比特幣提供結算保證：所有符文轉移最終都依賴比特幣區塊鏈的確認。當一個符文交易被包含在比特幣區塊中時，符文轉移即被視為最終確定。

選擇性驗證：符文節點可以選擇驗證符文轉移的正確性，但不驗證也不會影響比特幣交易的有效性。

4.2 符文節點驗證邏輯

符文節點（如 runic、Ordinalsbot 等）需要執行以下驗證步驟：

# 符文驗證邏輯
class RuneValidation:
    """
    符文協議驗證器
    """

    def __init__(self):
        self.rune_state = {}  # 符文狀態數據庫

    def validate_block(self, block):
        """
        驗證區塊中的所有符文交易
        """
        results = []

        for tx in block.transactions:
            result = self._validate_transaction(tx)
            results.append(result)

            # 更新狀態
            if result['valid']:
                self._update_state(result)

        return results

    def _validate_transaction(self, tx):
        """
        驗證單筆符文交易
        """
        # 1. 檢查是否有 OP_RETURN 輸出
        op_return = self._find_op_return(tx)

        if op_return is None:
            return {'valid': False, 'reason': 'no_op_return'}

        # 2. 解析 OP_RETURN 數據
        decoded = self._decode_op_return(op_return)

        if decoded is None:
            return {'valid': False, 'reason': 'invalid_encoding'}

        # 3. 驗證協議標籤
        if not self._verify_protocol_tag(decoded):
            return {'valid': False, 'reason': 'invalid_protocol_tag'}

        # 4. 根據操作類型進行驗證
        if decoded['op'] == 'etching':
            return self._validate_etching(decoded, tx)
        elif decoded['op'] == 'transfer':
            return self._validate_transfer(decoded, tx)
        elif decoded['op'] == 'mint':
            return self._validate_mint(decoded, tx)
        else:
            return {'valid': False, 'reason': 'unknown_op'}

    def _validate_transfer(self, decoded, tx):
        """
        驗證轉移交易
        """
        rune_id = decoded['rune_id']
        amount = decoded['amount']

        # 1. 檢查符文是否存在
        if rune_id not in self.rune_state:
            return {'valid': False, 'reason': 'rune_not_found'}

        rune = self.rune_state[rune_id]

        # 2. 驗證發送方餘額
        inputs = self._get_rune_inputs(tx)
        sender = inputs[0]['address']
        sender_balance = self._get_balance(sender, rune_id)

        if sender_balance < amount:
            return {'valid': False, 'reason': 'insufficient_balance'}

        # 3. 驗證輸出數量
        outputs = self._get_rune_outputs(tx)
        total_output = sum(o['amount'] for o in outputs)

        if total_output != amount:
            return {'valid': False, 'reason': 'amount_mismatch'}

        return {
            'valid': True,
            'rune_id': rune_id,
            'from': sender,
            'to': [o['address'] for o in outputs],
            'amount': amount
        }

    def _update_state(self, validation_result):
        """
        更新符文狀態
        """
        if validation_result['op'] == 'etching':
            # 添加新符文
            self.rune_state[validation_result['rune_id']] = {
                'name': validation_result['name'],
                'symbol': validation_result['symbol'],
                'divisibility': validation_result['divisibility'],
                'cap': validation_result['cap'],
                'supply': 0
            }

        elif validation_result['op'] == 'transfer':
            # 更新餘額
            rune_id = validation_result['rune_id']
            sender = validation_result['from']
            transfers = validation_result['to']

            # 扣減發送方餘額
            self._decrease_balance(sender, rune_id, validation_result['amount'])

            # 增加接收方餘額
            for receiver, amount in transfers:
                self._increase_balance(receiver, rune_id, amount)

4.3 UTXO 管理策略

符文協議的一個重要設計目標是減少 UTXO 膨脹。為此，協議採用了多種策略：

餘額整合：當用戶多次接收同一符文時，餘額可以存儲在同一個 UTXO 中，而非創建多個 UTXO。

找零優化：轉移時產生的找零金額會返回發送方，形成新的 UTXO，但這是可預期的正常行為。

批量轉移：支持在單筆交易中進行多個符文轉移，這可以減少總體 UTXO 增長。

# UTXO 管理策略
class RuneUTXOManagement:
    """
    符文 UTXO 管理
    """

    def __init__(self):
        self.utxo_cache = {}

    def optimize_utxos(self, address, rune_id, current_utxos):
        """
        優化 UTXO 集合
        目標：減少 UTXO 數量
        """
        if len(current_utxos) <= 1:
            # 已經是最優化狀態
            return current_utxos

        # 檢查是否需要整合
        if self._should_consolidate(current_utxos):
            # 創建整合交易
            return selfolidation_tx(address, rune_id, current_._create_consutxos)

        return current_utxos

    def _should_consolidate(self, utxos):
        """
        判斷是否應該整合 UTXO
        """
        # 如果 UTXO 數量超過閾值，考慮整合
        threshold = 5

        if len(utxos) > threshold:
            # 檢查網路費用是否足夠低
            current_fee_rate = self._get_current_fee_rate()

            if current_fee_rate < 10:  # sat/vbyte
                return True

        return False

    def _create_consolidation_tx(self, address, rune_id, utxos):
        """
        創建 UTXO 整合交易
        將多個小額 UTXO 合併為一個
        """
        total_amount = sum(u['amount'] for u in utxos)

        # 構建整合交易
        consolidation = {
            'inputs': utxos,
            'output': {
                'address': address,
                'rune_id': rune_id,
                'amount': total_amount
            },
            'purpose': 'consolidation'
        }

        return [consolidation['output']]

五、費用計算與經濟模型

5.1 費用結構

符文轉移的費用由兩部分組成：

比特幣網路費用：這是支付給比特幣礦工的费用，用于确认交易。费用根据交易大小（vbytes）和当前网络费率（sat/vbyte）计算。

符文協議費用（可選）：某些符文代币可以设置基础费用率（Base Fee Rate），每次转移时需要支付额外费用。这些费用归符文创建者所有。

# 費用計算
class RuneFeeCalculation:
    """
    符文費用計算
    """

    def __init__(self):
        self.minimum_fee_rate = 1  # sat/vbyte

    def calculate_transfer_fee(self, tx_size, network_rate, rune=None):
        """
        計算轉移費用
        """
        # 比特幣網路費用
        network_fee = tx_size * network_rate

        # 符文協議費用
        protocol_fee = 0
        if rune and rune.get('base_fee_rate'):
            protocol_fee = rune['base_fee_rate']

        return {
            'network_fee': network_fee,
            'protocol_fee': protocol_fee,
            'total_fee': network_fee + protocol_fee,
            'rate_sat_vbyte': network_rate
        }

    def estimate_transaction_size(self, num_inputs, num_outputs, has_op_return=True):
        """
        估算交易大小
        """
        # 比特幣交易基礎大小
        base_size = 10  # 版本號 + 輸入輸出計數器

        # 輸入大小（每個輸入約 148 vbytes）
        input_size = num_inputs * 148

        # 輸出大小（每個輸出約 34 vbytes）
        output_size = num_outputs * 34

        # OP_RETURN 大小（包含數據）
        op_return_size = 0
        if has_op_return:
            # OP_RETURN 開銷 + 符文數據
            op_return_size = 11 + 80  # 估算

        total_size = base_size + input_size + output_size + op_return_size

        return total_size

5.2 經濟效率比較

與 BRC-20 相比，符文協議在經濟效率方面有顯著優勢：

六、符文協議與其他比特幣代幣標準的比較

6.1 符文 vs BRC-20

BRC-20 是第一個在比特幣上創建可替代代幣的簡單標準，利用 Ordinals 協議的刻錄功能。兩者的主要區別：

6.2 符文 vs RGB

RGB 是另一種比特幣上的代幣協議，採用客戶端驗證範式：

6.3 符文 vs Counterparty

Counterparty 是比特幣上最早的代幣協議之一：

七、實際應用與使用場景

7.1 代幣發行

符文協議可以用於創建各種類型的代幣：

治理代幣：項目可以通過符文代幣進行去中心化治理決策。

會員代幣：作為某種會員資格或訪問權限的證明。

遊戲資產：遊戲內的物品或貨幣可以通過符文表示。

穩定幣：理論上可以通過符文實現與法定貨幣掛鉤的穩定幣。

7.2 轉移與交易

符文轉移可以通過標準的比特幣交易完成，這意味著：

錢包兼容性：理論上任何比特幣錢包都可以處理符文轉移（需要軟件升級）。

交易所整合：交易所可以通過添加符文支持來提供符文交易對。

跨鏈橋接：可以構建將其他區塊鏈的代幣橋接到比特幣的解決方案。

# 符文錢包概念
class RuneWallet:
    """
    符文錢包實現概念
    """

    def __init__(self, seed_phrase):
        self.seed = self._derive_seed(seed_phrase)
        self.btc_wallet = self._init_btc_wallet()
        self.rune_balances = {}

    def get_rune_balance(self, rune_id):
        """
        獲取特定符文的餘額
        """
        if rune_id not in self.rune_balances:
            self.rune_balances[rune_id] = self._fetch_balance(rune_id)

        return self.rune_balances[rune_id]

    def send_rune(self, rune_id, to_address, amount):
        """
        發送符文
        """
        # 1. 獲取餘額
        balance = self.get_rune_balance(rune_id)

        if balance < amount:
            raise ValueError("餘額不足")

        # 2. 獲取可用 UTXO
        utxos = self._get_rune_utxos(rune_id)

        # 3. 選擇 UTXO
        selected, change = self._select_utxos(utxos, amount)

        # 4. 構建符文轉移
        transfer = RuneTransfer(rune_id)
        tx = transfer.build(
            inputs=selected,
            to_address=to_address,
            amount=amount,
            change_address=self.get_change_address()
        )

        # 5. 簽名並廣播
        signed = self.btc_wallet.sign(tx)
        txid = self.broadcast(signed)

        return txid

    def receive_rune(self, rune_id, from_txid):
        """
        接收符文
        """
        # 監控區塊鏈，自動更新餘額
        tx = self.fetch_transaction(from_txid)
        rune_output = self._extract_rune_output(tx, rune_id)

        if rune_output['address'] == self.get_address():
            self.rune_balances[rune_id] += rune_output['amount']

八、安全性考量

8.1 協議安全性

符文協議的安全性基於比特幣的底層安全模型：

共識安全：符文協議不修改比特幣共識，因此繼承了比特幣網路的安全性。一個成功的 51% 攻擊不僅需要控制比特幣算力，還需要干預符文狀態。

密碼學安全：符文協議依賴標準的比特幣密碼學（ECDSA、SHA-256），這些經過了時間檢驗。

智能合約漏洞：符文協議本身不包含智能合約，因此不存在智能合約漏洞的風險（這與以太坊上的代幣不同）。

8.2 實施安全性

錢包安全：使用符文錢包時，用戶需要確保錢包軟件的可靠性。惡意軟件可能會盜取用戶的比特幣私鑰。

交易所風險：將符文存放在交易所時，需要考慮交易所的安全性和可靠性。

備份與恢復：符文的備份與恢復與比特幣類似，用戶需要妥善保管助記詞。

8.3 隱私考量

交易可鏈接性：符文轉移與比特幣交易是綁定的，因此存在被區塊鏈分析的風險。

餘額可觀察性：雖然餘額存儲在比特幣 UTXO 中，但區塊鏈分析師可能通過模式識別來識別符文轉移。

建議：大額或敏感操作應考慮使用混幣服務。

九、結論

符文協議代表了比特幣代幣標準的重要演進，其設計充分體現了比特幣的核心價值觀：

簡單性：通過使用 OP_RETURN 而非複雜的鏈下協議，符文保持了較低的複雜度和較高的兼容性。

效率：相比 BRC-20，符文協議大幅減少了 UTXO 膨脹問題，降低了比特幣網路的資源消耗。

安全性：符文協議依賴比特幣的成熟安全模型，沒有引入額外的安全假設。

可擴展性：符文協議支持多種代幣類型和應用場景，為比特幣生態系統的創新提供了基礎。

隨著比特幣社區對更高效代幣解決方案的需求不斷增長，符文協議有望成為比特幣區塊鏈上代幣發行的事實標準。然而，其長期成功仍取決於錢包、交易所和應用開發者的廣泛採用。

更新日期：2026-02-27

版本：1.1