Symbol上で誰もが検証できるERC1155相当を実現するアプリケーションレベルプロトコル

Symbol1155

Symbol上でERC1155相当を実現するアプリケーションレベルプロトコル

Symbolにはスマートコントラクトや自動実行はありません。
しかしその代わりに、

• トランザクション履歴
• Aggregate Transaction（複数署名）
• メタデータ
• 高可用API

という強力な要素があります。

Symbol1155 は、それらを組み合わせることで
**Mosaicを使わずに誰もが検証可能な ERC1155 相当（複数保有者・数量・batch）を表現するための「ルール仕様」**です。

---

基本コンセプト

概念	Symbol1155
tokenId	Symbolアドレス
台帳	トランザクション履歴
状態	履歴から復元
所有権	明示的署名
Batch	1txに複数操作
制御	オフチェーンルール

---

全体アーキテクチャ

ROOT（プロトコルルート）
 ├─ POLICY_CHANNEL    // ルール・権限
 ├─ STATE_CHANNEL     // 統合コミット
 ├─ MINT_CHANNEL      // Mint履歴
 ├─ TRANSFER_CHANNEL  // Transfer履歴
 └─ BURN_CHANNEL      // Burn履歴

• 各チャネルは 用途別のSymbolアドレス
• 履歴は混在させず、意味ごとに分離します

---

tokenId とは

• tokenId は Symbolアドレス
• 秘密鍵を持たないアドレスを推奨
• アドレス空間を使うことでID衝突を防止

tokenId メタデータ（Account Metadata）

nd:1155:ver        = "1"
nd:1155:root       = ROOT_ADDRESS
nd:1155:creator    = CREATOR_ADDRESS
nd:1155:maxSupply  = optional
nd:1155:uri        = optional

---

Policy（ルール定義）

SymbolはネットワークレベルでTXを拒否しません。
そのため 「どのTXを正史として採用するか」 を
ウォレットやインデクサ側のルールとして定義します。

Policy例

{
  "protocol": "symbol1155",
  "version": 1,
  "root": "ROOT_ADDRESS",
  "roles": {
    "controller": "ADDR",
    "mintAdmin": "ADDR",
    "upgradeAdmin": "ADDR"
  },
  "channels": {
    "MINT": {
      "address": "MINT_CHANNEL",
      "writer": "mintAdmin",
      "requireCosign": []
    },
    "TRANSFER": {
      "address": "TRANSFER_CHANNEL",
      "writer": "controller",
      "requireCosign": ["FROM"]
    },
    "BURN": {
      "address": "BURN_CHANNEL",
      "writer": "controller",
      "requireCosign": ["FROM"]
    }
  }
}

---

イベント形式（論理ブロック）

すべての操作は トランザクションメッセージとして記録されます。

{
  "p": "symbol1155",
  "v": 1,
  "root": "ROOT_ADDRESS",
  "tokenId": "TOKEN_ID",
  "seq": 42,
  "prev": "PREVIOUS_EVENT_HASH",
  "body": {}
}

• seq は +1 で増加
• prev は直前イベントのハッシュ
• 各チャネルは 独立したハッシュチェーンを形成

---

操作定義

Mint（発行）

MINT_CHANNEL に記録

{
  "m": [
    ["ADDRESS", 10],
    ["ADDRESS", 5]
  ]
}

• 署名者：mintAdmin
• ユーザー署名不要

---

Transfer（移転）

TRANSFER_CHANNEL に記録

{
  "t": [
    ["FROM", "TO", 3]
  ]
}

• 署名者：controller
• FROM の cosign（Aggregate）が必須

---

Burn（焼却）

BURN_CHANNEL に記録

{
  "b": [
    ["FROM", 2]
  ]
}

• 署名者：controller
• FROM の cosign 必須

---

検証ルール（最重要）

以下を すべて満たす場合のみ有効：

1. signer が policy の writer
2. 必要な cosign が存在
3. seq == head.seq + 1
4. prev == head.eventHash
5. 残高が負にならない
6. maxSupply を超えない

👉 それ以外のTXは すべて無視

---

実際の利用フロー（デプロイ → Mint → Transfer）

ここでは Symbol1155 を実際に使い始めるまでの一連の流れを、
「プロトコルのデプロイ → トークン発行 → ユーザー間送信」
という視点で解説します。

---

1. プロトコルのデプロイ（初期セットアップ）

1-1. ルート（ROOT）アドレスの用意

まず Symbol1155 プロトコルの 信頼起点となる ROOT アドレスを用意します。

• 通常は マルチシグアカウントを推奨
• このアドレスが「Symbol1155 インスタンス」を代表します

ROOT は以下を管理します：

• 現在有効な Policy
• 各チャネルのアドレス

---

1-2. チャネル用アドレスの作成

用途ごとに Symbol アドレスを作成します。

• POLICY_CHANNEL
• STATE_CHANNEL
• MINT_CHANNEL
• TRANSFER_CHANNEL
• BURN_CHANNEL

これらは 単なる通常の Symbol アドレスであり、
ネットワーク的な特別扱いはありません。

重要なのは「このアドレス宛の履歴を、どう解釈するか」というルールです。

---

1-3. Policy の定義と登録

次に、どのチャネルに誰が書き込めるかを定義する Policy を作成します。

• controller
• mintAdmin
• upgradeAdmin

などのロールを定義し、
POLICY_CHANNEL に 最初の Policy イベントを書き込みます。

同時に ROOT アドレスの Account Metadata に、
現在有効な policyHash を記録します。

これで Symbol1155 プロトコルの初期化は完了です。

---

2. tokenId（トークン）の作成

2-1. tokenId アドレスの生成

各トークン（ERC1155 の tokenId 相当）は、
1つの Symbol アドレスとして表現されます。

• 秘密鍵を持たないアドレスを推奨
• ランダム生成 or ハッシュ由来でOK

---

2-2. tokenId メタデータの登録

tokenId アドレスに対して、以下の Account Metadata を付与します。

• nd:1155:ver = "1"
• nd:1155:root = ROOT_ADDRESS
• nd:1155:creator = CREATOR_ADDRESS
• nd:1155:maxSupply（任意）
• nd:1155:uri（任意）

これにより、このアドレスが
Symbol1155 トークンであることが宣言されます。

---

シーケンス図（Mermaid）

以下は、Symbol1155 の実運用フローを Mermaid で可視化したシーケンス図です。

目的：署名者・cosign・チャネル書き込み・検証（採用/無視）の流れを一目で理解する

---

A. デプロイ（ROOT / チャネル / Policy 初期化）

---

B. tokenId 作成（tokenId metadata 登録）

---

C. Mint（mintAdmin が batch 発行）

---

D. Transfer（ユーザー発火：FROM cosign 必須）

---

E. 無効TXが大量に来る（public前提の無視戦略）

---

F. 参照（balanceOf / totalSupply）

---

3. Mint（トークン発行）

3-1. Mint トランザクションの作成

Mint は MINT_CHANNEL 宛に行います。

• signer：mintAdmin
• ユーザー署名：不要

トランザクションメッセージには以下を含めます：

• tokenId
• seq（前回 +1）
• prev（前回イベントハッシュ）
• Mint 操作内容（配布先と数量）

1 トランザクションで 複数アドレスへの batch Mint が可能です。

---

3-2. ウォレット / インデクサでの解釈

ウォレットやインデクサは、

• signer が mintAdmin であること
• seq / prev が正しいこと
• maxSupply を超えていないこと

を確認し、問題なければ 正史として採用します。

これにより、各アドレスがトークンを保有した状態になります。

---

4. Transfer（ユーザー間送信）

4-1. Transfer の基本原則

Transfer は 必ずユーザーの意思で発火します。

Symbol には自動実行がないため、
所有者（FROM）の署名が不可欠です。

---

4-2. Aggregate Transaction の構成

Transfer は以下の形で行われます。

• Aggregate Transaction
  • signer：controller
  • cosign：FROM（トークン保有者）

メッセージは TRANSFER_CHANNEL 宛に書き込まれ、

• tokenId
• seq / prev
• 転送内容（FROM, TO, 数量）

を含みます。

1 回の cosign で 複数 Transfer（batch） も可能です。

---

4-3. 正史としての確定

インデクサは以下を確認します。

• controller 署名が存在する
• FROM の cosign が存在する
• 残高が負にならない
• seq / prev が一致する

条件を満たした場合のみ、
Transfer は 正史として採用されます。

---

5. 状態の参照（balanceOf 相当）

Symbol1155 では状態はオンチェーンに直接保存されません。

• MINT / TRANSFER / BURN の履歴を順に適用
• 必要に応じて STATE_CHANNEL のコミットを利用

することで、

• balanceOf
• totalSupply

を復元します。

---

まとめ

• デプロイ：ROOT + チャネル + Policy を用意
• 発行：mintAdmin が batch Mint
• 送信：ユーザー cosign による Transfer
• 参照：履歴から常に検証可能

Symbol1155 は
**コントラクトではなく「秩序の取り決め」**として動作します。

そのため、

• public チェーンに強く
• 監査性が高く
• Symbol の設計思想に自然に適合します。

---