ブロックチェーン/NEM/Symbolのこれまでとこれから(KASANE?)

アドベントカレンダーの季節が今年もやってきました。2024年のNEM/Symbolアドベントカレンダー1日目ということで、ブロックチェーンNEM/Symbolの過去と現在と将来を改めて整理してみようと思います。

前提として以下の点にはご注意ください。

1. `Don't trust, verify.` ... 情報の正確性については最善を尽くしますが間違った情報が含まれている可能性もあります。
1. `NFA: Not Financial Advice.` ... この記事は金融的な助言を意図したものではありません。
1. `DYOR: Do Your Own Responsibility.` ... この記事を参考にしたいかなる取り組みにも筆者は責任を負うことはできません。ご自身の責任のもと、判断、行動してください。

## 歴史的経緯

### ブロックチェーンの登場 ... Bitcoin

2008年、Satoshi Nakamotoによって発表されたBitcoinホワイトペーパーは、分散型台帳技術としてのブロックチェーンの技術的な可能性を世の中に示しました。

そして2009年1月3日、ビットコインの最初のブロック(=1ブロック目: ジェネシスブロックと呼ばれる)が刻まれ、ブロックチェーンの元祖が産声を上げました。

ビットコインは以下のような技術的特徴を持っています。

#### 電子署名による取引の検証

ビットコインの取引では、公開鍵暗号方式を用いた電子署名が必要です。取引を開始する際、送金者は自分の秘密鍵を使って取引データに電子署名を行います。この署名は送金者の公開鍵を使って誰でも検証できるため「確かにその取引は正当な所有者によってリクエストされた」ということを(送金者が自分の秘密鍵を公開する必要なく)確認できます。これにより、他人になりすまして不正な取引を行うことが(、送金者が自分の秘密鍵を適切に管理できている限り、)原理上不可能な安全な仕組みを実現できます。

```mermaid
sequenceDiagram
    participant S as 送金者
    participant T as トランザクション
    participant N as ネットワーク
    
    Note over S: 1. 秘密鍵を保持
    Note over S: 2. 公開鍵を生成
    S->>T: 3. 取引データを作成
    Note over S,T: (送金先アドレス、金額など)
    
    S->>T: 4. 秘密鍵で取引データに電子署名
    Note over T: 5. 署名付きトランザクションデータが生成される
    
    T->>N: 6. 署名付きトランザクションをブロードキャスト
    
    Note over N: 7. 検証プロセス
    Note over N: ・公開鍵で電子署名を検証
    
    alt 検証成功
        N->>N: 8a. ブロックチェーンを構成する他のコンピュータにも共有
    else 検証失敗
        N->>N: 8b. 却下＆他のコンピュータには共有しない
    end
```

#### PoW(Proof of Work)

PoWは新しいブロックを作成する際に必要な計算作業です。Bitcoinネットワークを構成するコンピュータ(≒マイナー)は、次のブロックを自分のコンピュータ上で決定して生成して報酬を得るために、前のブロックのハッシュ値や取引データなどを含むデータにランダムな値(ナンス)を加えて、特定の条件を満たすハッシュ値を見つけ出す必要があります。この作業は非常に計算コストが高く、単一の組織や人が、独占的かつ永続的に優位な状況を維持し続けることが困難にすることを意図した、競争的な仕組みです。そして、この競争を通じた仕組みによって、管理者不在の状況下でも、相互監視的なプロセスが自然と実現され、ブロックチェーンが一貫性のある仕様通りの状態に保たれています。

```mermaid
flowchart TD
    subgraph Input["次のブロック"]
        B1["前のブロックハッシュ"]
        T["未承認取引データ"]
        Time["タイムスタンプ"]
        N["ナンス値(可変): 定められた条件を満たす必要あり"]
    end

    subgraph Process["マイニングプロセス"]
        H["ハッシュ関数で計算"]
        C{"条件を満たすか?"}
        Retry["再試行: 新しいナンス値で再計算"]
        Success["成功: 新ブロック生成&報酬獲得"]
    end

    subgraph Miners["マイナー達による競争"]
        M1["マイナー1"]
        M2["マイナー2"]
        M3["マイナー3"]
        Mn["マイナーn"]
    end

    B1 --> H
    T --> H
    Time --> H
    H --> C

    M1 --> Process
    M2 --> Process
    M3 --> Process
    Mn --> Process

    C -->|Yes| Success
    C -->|No| Retry
    Retry --> H
    Success --> N
```

#### UTXO(Unspent TX(Transaction) Output)

UTXOは、ビットコインのトランザクションを管理するためのデータ構造です。各取引は「入力」と「出力」で構成され、未使用の出力がUTXOとなります。

例えば、Aさんが1BTCをBさんに送金する場合：

* 入力として、Aさんが保有する未使用の出力（UTXO）を指定
* 出力として、Bさんのアドレスに送金額を指定
* お釣りが発生する場合は、自分宛ての出力も作成

このモデルにより、二重支払いの防止や取引の整合性確保が実現されています。

```mermaid
flowchart LR
    subgraph Before["取引前"]
        subgraph Aさん
            A1[/"UTXO: 2BTC"/]
        end
        subgraph Bさん
            B1[/"UTXO: 0.5BTC"/]
        end
    end

    subgraph Process["取引プロセス"]
        subgraph 入力
        Input["入力 2BTC (AさんのUTXOを使用)"]
        end
        subgraph 出力
            Output1["出力1 Bさんへ: 1BTC"]
            Output2["出力2 Aさんへ: 1BTC(お釣り)"]
        end
    end

    subgraph After["取引後"]
        subgraph Aさん取引後
            A2[/"Aさん UTXO: 1BTC"/]
        end

        subgraph Bさん取引後
            B2[/"Bさん UTXO: 1BTC(新規受取)"/]
            B3[/"Bさん UTXO: 0.5BTC(既存)"/]
        end
    end

    A1 --> Input
    Input --> Output1
    Input --> Output2
    Output1 --> B2
    Output2 --> A2
    B1 --> B3

```

#### ビットコインによって実現されたこと

ビットコインは、中央管理者不在でも価値の移転を可能にするシステムを実現しました。電子署名による取引の正当性の担保、PoWによる改ざん耐性の確保、UTXOモデルによる二重支払いの防止など、技術的な課題を解決しただけでなく、マイニング報酬というインセンティブ設計により、システムの自律的な維持を可能にしました。また、誰でも参加可能なオープンな仕組みとすることで、国境を越えた価値移転を実現し、プログラマブルな電子マネーの基盤を確立しました。

#### ビットコインの課題

一方で、ビットコインにはいくつかの限界もあります。まず、ブロックサイズの制限により処理速度に制約があり、混雑時には取引手数料が高騰するスケーラビリティの問題があります。また、PoWによる大量の電力消費は環境負荷の観点から課題となっています。さらに、取引の確定に時間がかかるという利用面での制約もあります。

さらに、最も本質的な課題として、ビットコインのUTXOのデータ構造は、電子通貨システムとしての機能には十分ですが、それ以外のデータ構造を表現することを想定するとシンプル過ぎて、スマートコントラクトなどの複雑な機能の実装が困難です。ビットコインのスクリプト言語は意図的に制限されており、極めて限定的な処理しか実行することができません。これは、システムの安全性と安定性を優先した設計選択ですが、結果として、分散型アプリケーションプラットフォームとしての発展には大きな制約となっています。

こうした限界に対して、現在では、LN(Lightning Network)ソリューションの開発など、様々な取り組みが進められています。スケーラビリティの問題の解決については、LNが一定の成果をあげていると感じますが、根本的にその他の技術的課題を解決することは難しそうに見えます。(そして、そのような技術的課題については、「それはそれでよし」として、あるがままに受け入れられているように感じます。)

### 多数のブロックチェーンが誕生

ビットコインが示したブロックチェーンの可能性に触発されたり、ビットコインの技術的課題を解決することを意図して、様々なブロックチェーンが生まれ、それらブロックチェーン上で様々なトークンが発行されました。これらはビットコインの名前をもじってオルトコインと呼ばれました。

### NEM(New Economy Movement)のメインネットローンチ

NEMもオルトコインの一つとして誕生しました。当初はnxtというオルトコインのクローンとしての計画が進んでいたようですが、技術的に、より野心的な課題解決を目指して、フルスクラッチで開発する方針に切り替わり、2015年3月29日にメインネットがローンチされました。

NEMのメインネットの最初のブロック(≒Genesis BlockをもじってNemesis Blockと呼ばれる)
https://explorer.nemtool.com/#/s_block?height=1

NEMでは以下のような機能が実現され今もブロックを刻み続けています。

1. ブロックチェーンネットワークを通じてブロックを新たに生成していくプロセスだけでなく、REST APIやWebSocketを通じてユーザーからのリクエストを処理するプロセスも統合的に扱えるノードを動作させるためのツール群としてのNIS(NEM Infrastructure Server)
1. プロトコルレベルでブロックチェーンにあらかじめ組み込み済の各種機能
    1. NEMブロックチェーン上で唯一の名前を保持できる機能 ... 「ネームスペース」という機能名
    1. 名前付きの独自トークンを容易に発行できる機能 ... 「モザイク」という機能名
    1. 複数アカウントのうち、事前に定めた数の電子署名がそろわないと、トランザクションが実行できないアカウントを設定できる機能 ... 「マルチシグ」
    1. トークンだけでなく平文データ・暗号化データも送受信可能 ... 「メッセージ」という機能名

1の特徴によって、NEMを用いたDapps(分散型アプリケーション)開発では、以下のように、あらかじめブロックチェーン上にビルトイン済＆入念なテスト済の堅牢な機能を、従来のWeb開発の延長線上で状態を参照したり、何らかのアクションを実行したりして活用することができます。開発者目線では、開発プロセスが非常に楽というメリットがある反面、あらかじめブロックチェーン上にビルトイン済でない機能を実現するためには、ブロックチェーンの外で、別途機能を実装する必要があるというデメリットもあります。

```mermaid
flowchart LR
    Developer
    subgraph NEM
        subgraph Buit in Feature
            subgraph State
            end
            subgraph Action
            end
        end
    end
    Developer -->|Deploy| Dapps
    Dapps -->|Read| State
    Dapps -->|Execute| Action
```

2-1のネームスペースはブロックチェーン上のアカウント(≒アドレス)にヒューマンリーダブルな名前を付けることができる機能です。Webの世界で、IPアドレスにドメイン名が紐づけられているような機能を、ブロックチェーン上のアドレスに対して実現できると捉えてもらうとイメージしやすいでしょう。

```mermaid
flowchart TB
    subgraph NEM
        subgraph Address
            PersonalAddress[NA...A]
            OrganizationAddress[NB...B]
        end
        subgraph Namespace
            personal-name
            organization-name
        end
    end
    personal-name --> PersonalAddress
    organization-name --> OrganizationAddress
```

2-2のモザイクはブロックチェーン上に共通の規格に基づいたトークンを発行できる機能です。

```mermaid
flowchart LR
    subgraph NEM
        subgraph Address["Address: Token Owner"]
            OrganizationAddress[NB...B]
        end
        subgraph Namespace
            organization-name
        end
        subgraph NewMosaic["New Mosaic ≒ New Token"]
            TokenParameters["Name=token-name
            FullName=organization-name:token-name
            Descripiton=このトークンは～です。
            Divisibility=6
            InitialSupply=10000000000"]
        end
    end
    organization-name --> OrganizationAddress
    OrganizationAddress -->|MosaicDefinitionTx| NewMosaic
```

発行されたモザイク(≒トークン)は、以下のように転送することができます。

```mermaid
flowchart LR
    subgraph AccountA[Account A]
        MosaicOwnedByA[Mosaic]
    end
    subgraph AccountB[Account B]
        MosaicOwnedByB[Mosaic]
    end
    MosaicOwnedByA -->|100 Mosaic| MosaicOwnedByB

```

トークンを初期発行する際に譲渡不可の設定をしておくことで転送できないようにすることもできます。(SBT(Soulband Token)的なイメージです。)

```mermaid
flowchart LR
    subgraph AccountA[Account A]
        MosaicOwnedByA["Mosaic(譲渡不可設定)"]
    end
    subgraph AccountB[Account B]
        MosaicOwnedByB[Mosaic]
    end
    MosaicOwnedByA -->|"転送試行(100 モザイク)"| X{{"❌"}}
    X -.->|"譲渡不可設定によってブロック"| AccountB
```

トークン発行時にLevyという自動徴収設定をしておくことで、あるトークンが転送されたときに自動的に別のトークンが定められた量だけ自動的に徴収されるようにすることもできます。(源泉徴収や消費税徴収の自動化やトークンの2次流通時のトークンオーナーへの自動インセンティブ支払いのようなユースケースに活用できそうですが、残念ながらこの機能は悪用されたことがあり、NEMの次期ブロックチェーンSymbolでは削除されました。)

```mermaid
flowchart TB
    subgraph AccountA[Account A]
        MosaicOwnedByA["Mosaic1(自動徴収をトリガーするトークン)"]
        LeviedMosaicOwnedByA["Mosaic2(自動徴収されるトークン)"]
    end
    subgraph AccountB[Account B]
        MosaicOwnedByB[Mosaic1]
        LeviedMosaicOwnedByB[Mosaic2]
    end
    MosaicOwnedByA --> transfer{{"転送"}}
    transfer --> MosaicOwnedByB
    transfer --> |Trigger Levy| levy
    LeviedMosaicOwnedByA <--> levy{{"自動徴収"}}
    levy --> LeviedMosaicOwnedByB
LeviedMosaicOwnedByB

```

2-3のマルチシグは、アカウントの管理権限を、別の複数のアカウントに移譲し、その複数のアカウントのうち定められたアカウントの承認(≒電子署名)がそろった場合のみ、取引が実行できる機能です。

あるアカウントをマルチシグ化する際には、そのアカウントの電子署名によってそのアカウントの操作を行うことは以降一切不可能となる不可逆的な設定変更が行われるとともに、そのアカウントの管理を代わりに行うことになる連署アカウントが設定されます。

```mermaid
flowchart LR
    subgraph マルチシグ化前
        MultisigAccountBefore["マルチシグアカウント"]
        CosignatureAccount1Before["連署アカウント1"]
        CosignatureAccount2Before["連署アカウント2"]
        CosignatureAccount3Before["連署アカウント3"]
    end
    subgraph マルチシグ化後
        MultisigAccountAfter["マルチシグアカウント"]
        CosignatureAccount1After["連署アカウント1"]
        CosignatureAccount2After["連署アカウント2"]
        CosignatureAccount3After["連署アカウント3"]
    end

    MultisigAccountBefore -->|マルチシグ化=不可逆的な設定変更=このアカウント自体の署名によって取引を実行することはできなくなり倉庫のような役割に| MultisigAccountAfter
    CosignatureAccount1Before -->|マルチシグアカウントの共同管理権限が付与される| CosignatureAccount1After
    CosignatureAccount2Before -->|マルチシグアカウントの共同管理権限が付与される| CosignatureAccount2After
    CosignatureAccount3Before -->|マルチシグアカウントの共同管理権限が付与される| CosignatureAccount3After
    CosignatureAccount1After -->|共同管理| MultisigAccountAfter
    CosignatureAccount2After -->|共同管理| MultisigAccountAfter
    CosignatureAccount3After -->|共同管理| MultisigAccountAfter
```

連署アカウントn個のうち、m個のアカウントの署名がそろったら、マルチシグアカウントの取引が実行されます。このようなマルチシグ構成を`m of n`のように表現します。例えば連署アカウント3個のうち、2個のアカウントの署名がそろったらトランザクションが実行可能なマルチシグ構成にしていた場合、`2 of 3`のマルチシグ構成と呼び、以下の図のように、マルチシグアカウントからのトランザクションを実行できるわけです。

```mermaid
flowchart TB
    subgraph MultisigRelatedAccounts[マルチシグ関連アカウント]
        MultisigAccount[マルチシグアカウント]
        CosignatureAccount1[連署アカウント1]
        CosignatureAccount2[連署アカウント2]
        CosignatureAccount3[連署アカウント3]
    end

    CosignatureAccount1 -->|共同管理| MultisigAccount
    CosignatureAccount2 -->|共同管理| MultisigAccount
    CosignatureAccount3 -->|共同管理| MultisigAccount

    RecipientAccount[受取アカウント]

    MultisigAccount -.->|マルチシグアカウントの署名で直接実行することは不可能| TransferTransactionFromMultisigAccount[マルチシグアカウントからの送信]
    TransferTransactionFromMultisigAccount -->|2 of 3の署名＆連署がそろったら実行される| RecipientAccount
    CosignatureAccount1 -->|マルチシグアカウントの代わりに署名＆ネットワークにアナウンス| TransferTransactionFromMultisigAccount
    CosignatureAccount2 -->|マルチシグアカウントの代わりに連署| TransferTransactionFromMultisigAccount
```

マルチシグの共同管理者として新しいアカウントを追加で招待したいようなユースケースにも以下のように対応可能です。

```mermaid
flowchart LR
    subgraph MultisigRelatedAccountsBefore[連署アカウント追加前]
        MultisigAccountBefore[マルチシグアカウント]
        CosignatureAccount1Before[連署アカウント1]
        CosignatureAccount2Before[連署アカウント2]
        CosignatureAccount3Before[連署アカウント3]
    end
    
    subgraph MultisigRelatedAccountsAfter[連署アカウント追加後]
        MultisigAccountAfter[マルチシグアカウント]
        CosignatureAccount1After[連署アカウント1]
        CosignatureAccount2After[連署アカウント2]
        CosignatureAccount3After[連署アカウント3]
        CosignatureAccount4After[連署アカウント4]
    end

    MultisigAccountBefore --> MultisigAccountAfter
    CosignatureAccount1Before --> CosignatureAccount1After
    CosignatureAccount2Before --> CosignatureAccount2After
    CosignatureAccount3Before --> CosignatureAccount3After

    AddCosignatureAccount[連署アカウント追加]

    CosignatureAccount1Before -->|署名＆アナウンス| AddCosignatureAccount
    CosignatureAccount2Before -->|連署| AddCosignatureAccount
    AddCosignatureAccount -->|追加| CosignatureAccount4After

```

マルチシグアカウントの共同管理者から、既存の共同管理者を追い出すように削除するようなユースケースにも対応可能です。

```mermaid
flowchart LR
    subgraph Before[連署アカウント削除前]
        subgraph MultisigRelatedAccountsBefore[マルチシグ関連アカウント]
            MultisigAccountBefore[マルチシグアカウント]
            CosignatureAccount1Before[連署アカウント1]
            CosignatureAccount2Before[連署アカウント2]
            CosignatureAccount3Before[連署アカウント3]
        end
    end
    
    subgraph After[連署アカウント削除後]
        subgraph MultisigRelatedAccountAfter[マルチシグ関連アカウント]
            MultisigAccountAfter[マルチシグアカウント]
            CosignatureAccount1After[連署アカウント1]
            CosignatureAccount2After[連署アカウント2]
        end
        subgraph NoMultisigRelatedAccountsAfter[マルチシグ無関係]
            CosignatureAccount3After[連署アカウント3]
        end
    end

    MultisigAccountBefore --> MultisigAccountAfter
    CosignatureAccount1Before --> CosignatureAccount1After
    CosignatureAccount2Before --> CosignatureAccount2After
    
    RemoveCosignatureAccount[連署アカウント3を追出]

    CosignatureAccount1Before -->|署名＆アナウンス| RemoveCosignatureAccount
    CosignatureAccount2Before -->|連署| RemoveCosignatureAccount
    CosignatureAccount3Before --> RemoveCosignatureAccount
    RemoveCosignatureAccount -->|実行| CosignatureAccount3After

```

2-4のメッセージ送信は、ブロックチェーン上に書き換え不可能なメッセージを平文・暗号化メッセージどちらでも刻んでおくことができる機能です。

```mermaid
flowchart LR
    AccountA[アカウントA]
    AccountB[アカウントB]
    
    AccountA -->|平文メッセージ| AccountB
```

暗号化メッセージの場合は、送受信者双方とも、自分の秘密鍵と相手の公開鍵から導出できる共通鍵を用いて暗号化・復号して扱うことができる機能です。

```mermaid
flowchart LR
    AccountA[アカウントA]
    AccountB[アカウントB]
    Encrypt[アカウントAの秘密鍵とアカウントBの公開鍵で暗号化]
    Decrypt[アカウントAの公開鍵とアカウントBの秘密鍵で復号]
    AccountA -->|平文メッセージ| Encrypt
    Encrypt -->|暗号化メッセージ| Decrypt
    Decrypt -->|平文メッセージ| AccountB
```

2-1, 2-2, 2-3, 2-4で説明させてもらった機能について、NEMのこのような機能や設計哲学や技術的特徴は、後述するSymbol(≒NEMの次期バージョン)にもより便利にパワーアップした形で引き継がれています。2015～2017年頃に、これらの機能がブロックチェーン自体にビルトイン済で、開発者が容易に利用できる状態だったのは、改めて当時の状況を思い起こすと、極めて先進的だったのだろうなあと感じます。ただし、各種機能には、微妙に不便と感じられる暗黙の制約条件のような仕様があり、スケーラビリティに関しても課題感がありました。それらの課題解決を野心的に目指して2016年頃からCatapultというコードネームで新しいコアエンジンの開発が検討されはじめていたでしょうか。これが後述するSymbolというNEMの次期バージョンにつながりました。

なお、NEMの実装の基盤技術関連の特徴としては、Java, Spring系の技術基盤で実現されていることが挙げられると思います。オルトコイン黎明期で、他チェーンとの競争が現在とはまた別の意味合いで激しかったため、可能な限りスピーディーにメインネットをローンチできるような技術選択がされたという話を聞いたことがあります。NEM(のNIS1≒ブロックチェーンのノードを動かすツール)は比較的長期間クローズドソースでしたが、確か2021年頃にオープンソース化され、現在は以下リンクのGitHubのリポジトリからソースコードを確認できるので、もし興味ある方はぜひご覧になってみてください。

テクニカルリファレンス
https://nemproject.github.io/nem-docs/pages/Whitepapers/NEM_techRef.pdf

ドキュメント
https://github.com/NemProject

GitHub
https://nemproject.github.io/nem-docs/pages/

フォーラム
https://forum.nem.io/

### Ethereumのメインネットローンチ

NEMのメインネットローンチと同じ頃にEthereumもメインネットがローンチしています。(2015年7月)

Ethereumはスマートコントラクトという革新的な概念・機能をブロックチェーンの世界にもたらしました。開発者は(一定の制約はあるもののかなり自由に)ブロックチェーン上に自分のサービスで扱いたい状態やふるまいを定義したスマートコントラクトを開発＆デプロイし、分散的なアプリケーション(Dapps)から、そのスマートコントラクトの状態を参照したり、ふるまいを呼び出して実行したりすることができるというものです。

```mermaid
graph LR
    Developer
    subgraph Ethereum
        subgraph Contract["Smart Contract"]
            subgraph State
            end
            subgraph Action
            end
        end
    end
    Dapps

    Developer -->|Deploy| Contract
    Developer -->|Deploy| Dapps
    Dapps -->|Read| State
    Dapps -->|Call| Action

```

この仕組みは、NEMの「ブロックチェーン自体にビルトイン済の機能のみを組み合わせて使う」という設計思想と対照的な仕組みで、メリット・デメリットも対照的です。

柔軟さにおいては、Ethereumのスマートコントラクトの方がNEMのビルトイン済の機能よりも柔軟でメリットがあります。

しかし、開発の容易さという点では、ブロックチェーンに直接ロジックを刻むスマートコントラクトの開発・デプロイではセキュリティや変更容易性の観点で難しさがあり、NEMのビルトイン済の機能を用いた開発の方が容易と言える時代でした。

### 独自トークン(FT)とICOの熱狂の時代

こういった技術要素が整ってきたことで2017年頃から、EthereumのスマートコントラクトとしてのERC20という規格に則ったFungible Tokenを発行して販売するICO(Initial Coin Offering)が大流行する熱狂の時代が幕を開けました。

### 大規模なセキュリティインシデントの悲劇

そして、熱狂の時代に水を差すように、NEMの基軸トークンのXEMが某取引所から大量に盗まれるという大規模なセキュリティインシデントが発生してしまいました。このセキュリティインシデントの原因は、NEMブロックチェーンそれ自体やそれ自体のプロトコルではなく、対象の取引所で顧客の資産を預かっていたアカウントがマルチシグ化されていなかったり、コールドウォレットとしての安全管理が不徹底であったことによって、該当アカウントの秘密鍵が漏洩してしまったことによるものでした。

この時代は多くの関係者にとって、ブロックチェーン業界の「狂騒の時代」として記憶されているのではないかと思いますが、同時に現在のDeFiやWeb3の基盤となる重要なプロジェクトが生まれた時期でもあったと言えるかもしれません。多くの教訓を残しつつ、業界の成熟化につながった重要な転換期だったとも言えるかもしれません。

### スマートコントラクトによって到来したDeFi / NFTの時代

NEMの世界では、Catapultの開発～Symbolブロックチェーンのテストネットローンチ～メインネットローンチが5年という長い時間をかけて進みました。

その間、他のブロックチェーンの世界では、スマートコントラクトを活用した非中央的な金融サービスDeFi(Decentralized Financial Service)や、NFT(Non Fungible Token)を用いたサービスが大きな盛り上がりを見せてきたと思います。

この過程で、スマートコントラクトを活用した開発を取り巻くエコシステムは非常に広く・深く発展を遂げ、スマートコントラクトを用いた開発体験も非常に整ってきたと感じます。

ただし、セキュリティについてはやはり非常に難しく、DeFiサービスがハッキングされることはもはや日常茶飯事になったという感触があります。

私個人としては、そういったセキュリティの問題による被害でDeFi自体のエコシステム全体が連鎖的に崩壊してしまうような悲観的な状況に追いやられてしまうのではないか... と恐れていた気持ちが強かったのですが、DeFiユーザー・開発者は比較的冷静にリスクとリワードを天秤にかけて、現在でもDeFiの勢いは衰えるところを知らない状況に見えます。

### 単一チェーンの限界をインターオペラビリティで超えていこうとしていく試み

そういった状況下で、さらに、Cosmos SDKという独自ブロックチェーンを作るためのフレームワークを用いてIBC(Inter Blockchain Communication)プロトコル互換のブロックチェーンを作って連携していこうといった取組のような、異なるブロックチェーンをまたいだ連携の仕組みのエコシステムが大きく発展を遂げている状況もあります。

異なるブロックチェーン同士の連携箇所には、DeFiプラットフォームでの新しい収益機会が生まれ、そこにユーザーが集まったり、去って行ったりする、極めて大きなダイナミズムが生まれていると感じます。

### Symbolブロックチェーンのメインネットローンチ

そして、そのようなブロックチェーン界隈の空気の中、5年間という長い開発の時を経て、NEMブロックチェーンの次期バージョン、Symbolブロックチェーンのメインネットが2021年3月にローンチしました。そして今はそこから約3年8か月ほど経過した状態です。

Symbolブロックチェーンはローンチ時点できわめて完成度が高い状態で、ひとつのパブリックなブロックチェーンの改善に長い時間をかけて、真摯に向き合ってきたことが感じられます。

前バージョンのNEMの技術的課題を良い形で解決しており、開発者にとって極めて使いやすいL1パブリックチェーンとして今でも際立った存在であると個人的には思っています。

(このあたりの情報は、また後で、可能なら追記できれば...と思っています。)

しかし、ローンチ前もローンチ後も、Symbolブロックチェーンを取り巻く組織的な問題によって、コミュニティ以外の側面からの適切な情報発信や、エコシステムの整備がなかなか進んでいない現状もあり、その技術的ポテンシャルを活かしきれていない現状については悔しい気持ちも正直あります...

(このあたりの情報も、また後で、可能なら追記できれば...と思っています。)

### 単一チェーンの限界をLayer2、ZKPで超えていこうとしている現在

他チェーンでは、各種技術課題を、Layer2やZKPといった技術によって解決していこうとする試みが動き出しており、それら技術を生かした次世代プラットフォーム上での覇権争いが始まっているように見えます。

### KASANE？

そういったブロックチェーン界隈の動向に対して、Symbolの次期バージョンのコードネームとしてKASANEというコードネームがSymbolコア開発者のHatchet氏からカンファレンスイベントで公開され、SymbolでもLayer2やZKPの技術を活用して改善を目指すという情報公開がなされました。ただし、現時点で公開されている情報としては、まだ、抽象的な概念の紹介にとどまっており、今後の情報公開が待たれるという状況です。

## 今後のブロックチェーンとNEM / Symbolについて

今、NEM / Symbolについて、個人的に思うことは、技術だけではどんなプロジェクトも発展させていくことは難しいという限界を感じているということです。最低限、組織的な体制やマーケティング以前の情報発信状況を整えた上で、現状のSymbolブロックチェーンを取り巻くコミュニティメンバーやステークホルダーから広く意見を募りながら、次の施策の検討を進め、他ブロックチェーンエコシステムとの連携を深めつつ、ブロックチェーン業界全体とともにSymbolブロックチェーンもエコシステムを進化させていけるといいな... と願っている今日この頃です。