はじめに
いよいよ始まりました。nem アドベントカレンダー2021。こちらはスレッド#3 です。
Symbolはブロックチェーンに詳しくない他分野のスペシャリストでもローコード/ノーコードでセキュアかつデプロイレスなスマートコントラクトを記述できるブロックチェーンとして日本のエンジニアや研究者からも非常に注目される存在となり、いまでは元イーサリアムのプロトコルの改善提案者がコアチームに無報酬で参入するなどプラットフォームとしてその可能性を期待されています。
NIS1(NEM)の進化版として開発されたSymbolは、他のブロックチェーンと比べても素晴らしい機能を持っていますが、まだ多くの人に熟知されていません。今日はその中でも、私が感じる特に優れた機能を3つご紹介します。
- 誰もが使える1300台のREST APIノード
- 組織で運用可能なマルチシグ
- トランザクションベースのスマートコントラクト
これのどこが衝撃なのか？不思議に思われる方がいるかもしれません。ブロックチェーンの社会実装が期待される中、私たちは今どこで立ち止まっているのでしょうか？今回の投稿を読んで、それを解決するためのヒントとして何か気付いていただければ幸いです。
2019年にも以下のような記事で投稿しているので合わせてお読みください。
１.誰もが使える1300台のREST APIノード
一般的にブロックチェーンのノードに対し、不特定多数からのAPI接続を許可する設定は推奨されません。ノードは常にP2P同期に安定したセキュリティのためにリソースを費やす必要があり、ネットワーク外部からのアクセスにはファイアウォールなどで最大限の防御で守っておく必要があります。しかしながら、Symbolは現在全1400台のノードのうち、不特定多数のユーザからAPIアクセスを受け付ける設定のノードが1300を超えています(うち、HTTPS対応が500程度)。
これはすごいことです。ログインIDも月額利用料も発生しない、誰もがアクセス可能で同じデータを持っていることが保証されているWebサーバが世界中の1300か所に分散されているとお考え下さい。他のブロックチェーンは外部に公開されているエンドポイントが1つだけだったり、オンチェーンデータの検証方法がサードパーティがキャッシュしたエクスプローラだけだったりします。
ブローカー
なぜこのようなことが可能かというと、ノード内部にブローカーと呼ばれる橋渡しの仕組みによって、REST API部分とチェーン（P2P通信部分）の同期にかかわるセキュリティや負荷対策が完全に分離されているのです。このしくみにより、たとえ外部からのDoS攻撃でREST APIがダウンしたといても、コア部分のブロック生成はおろかハーベスト（マイニング・ステーキング）を阻止することもできません。なお、ブローカーの安定性向上には日本のNEMコミュニティによるテストも大きく貢献しました。
さらに、ノードの運用は高度にインセンティブ設計された報酬制度によって、かなり攻めた設定値の試行錯誤が議論されており、より安全に安定したノード運営のためのメンテナンスノウハウが蓄積されています。私も最初はいろいろ試してはいたものの、ノードを建ててはぶち壊す猛者達の議論にはついていけなくなりました。もはや断言できます。Symbolアプリケーション開発者はノード運用に関する知識は不要です。世界を興奮させるアプリケーション開発に専念してください。
特定ノードへの依存
サービスプロバイダの運用するノードにしか接続できないことには疑問が残ります。確かに、ブロックチェーンに記録された署名済みトランザクションを改ざんすることはできません。しかしながら、そのトランザクションが利益を確保できるタイミングで間違いなくアナウンスされるかどうかは分かりません。より徹底した分散化社会では複雑なスマートコントラクトであったとしても、ネットワークへのアナウンスはサービスプロバイダではなく、どのノードにどのタイミングでアナウンスするかを、ユーザが自分の意思で決定する必要があると考えます。
この考え方は、実社会がオンチェーンデータを「参照」する段階になれば、ますます重要になってきます。データの参照はプラットフォームを経由する過程でいくらでも改ざん可能なため、プラットフォームが特定のノードにしか接続できないという状況は「大企業が構築した信頼できるプラットフォームしか利用できない」という状況から何も進展はありません。これらのデータを何階層ものプラットフォームを経て複雑に積み上げていくためには、ユーザ自身がサービスプロバイダの息のかからないノードを選択してセカンドオピニオンのように検証できるような仕組みが必要です。
上図を見てもわかるように、REST APIで不特定多数のユーザがノードに自由に接続できるSymbolは、プラットフォームから独立した検証系をユーザが自由に選択できるようになります。
こちらも合わせてお読みください。
2.組織で運用可能なマルチシグ
一般的に電子署名は第三者認証局無しでは組織で運用することができません。デジタルデータはコピー可能なため、人事異動などで秘密鍵を手放す必要のある人が手元にコピーを残していないことを証明できないためです。そのため電子署名は鍵に紐づけられた個人が組織に所属していることを第三者認証局から期限つきで認証を受ける、といった手法を取ります。
ブロックチェーンに置き換えたときも同様の問題点が発生します。ブロックチェーン上に記録された資産を組織が署名することで送金するなどの設計した場合、組織は鍵の漏洩や紛失などへの対策を打てないばかりか、人事異動などの世代を超えてその鍵の所有者となることができません。
（取引所等は金庫やハードウェアウォレットなど物理的なものを組み合わせて厳格に運用しているものと思われます）
秘密鍵の管理について世代をまたぐことが容易でなければ、一般的な組織でブロックチェーンを導入するのは夢物語となります。ここではSymbolが提供する譲渡可能なマルチシグを活用することで「所有」や「所属」を表現し、組織でブロックチェーンを簡単に活用する方法を考えてみます。
所有
まずは、所有の表現について考えます。
昨年のアドベントカレンダーで、マルチシグによるアカウントの所有について説明しました。
以下の図はAliceをBobとSecurityが所有している状態です。Aliceの資産はBobとSecurityしか動かすことはできません。ここでは「所有」の状態を「手放すことができる状態」と定義します。
なおマルチシグ化されたAliceの秘密鍵はSymbolのビルトインスマートコントラクトとしてプロトコル上その効力を失っているので無視して大丈夫です。
以下の図はAliceアカウントのマルチシグからBob自身を削除、Carolを追加します。
Bobが鍵を紛失した場合は、Security鍵によって、BobからCarolへ強制的に譲渡します。Security鍵は金融機関の運用で言えば、物理的な二重金庫、封印シールなどを用いて厳密に管理されているようです。
所属
次に所属を考えます。
Aliceがインターネットや印刷物として周知されたアドレスの場合（例えばこれを登記と表現します）、Carolは世間からどう認知されるでしょうか？Carol(Security)はAliceアドレスを送信者と明示してトランザクションを発行できる唯一のアカウントとなります。つまり、公に周知されたアドレスのリソースを動かせる存在であるため、CarolはAliceに所属していると表現することができます。そしてもっとも重要なことはSymbolのマルチシグは、このインターネットや印刷上に登記した企業アカウントの窓口アドレスを一切変えることなく、その連署者の構成を自由に変えることができる点です。
以下の図はユーザーアカウントが、現在の企業アカウントの組織構成を意識することなく窓口アドレスに送金することで、その時の担当者が適切に管理できる構成を表現しています。また、企業アカウントがユーザに対して認証のためのトークン発行やのメタデータの付与を行った場合、検証アカウントはインターネットあるいは印刷上の周知のアドレス情報を用いて、ユーザーの認証状態を検証するスキームの説明です。
今後DIDなどの分散型アイデンティティでよく見かける構図になると思いますが、DIDではユーザ(Holder)が複数のID所有を前提としている一方で企業アカウント(Issuer)がDIDを持ち変えると検証(Verifier)や送金に支障が出てしまう問題もあり、リカバリのしやすさなどが議論対象にもなっています。Symbolはブロックチェーンの社会実装が進んだ先に生まれつつある課題にも既存技術で適切に対応できるような設計になっています。
窓口アドレスを変えずに連署アカウントを紛失した場合の回復方法については、以下の記事もご参考ください。
3.トランザクションベースのスマートコントラクト
一般的にスマートコントラクトはをオンチェーン上に記述され、外部からの入力をトリガーとして実行されます。この挙動はブロックチェーンをDBと見立てると、DB上にプログラムをデプロイするストアドプロシージャによく似ています。
ストアド・プロシージャ
テストしづらい。gitで管理しづらい。ある程度複雑なことをするなら、プログラミング言語でやった方が楽。スクリプト言語からDBにアクセスできなかった頃は、PL/SQLで書く気持ちもわかるが、今はストアド・プロシージャ（ファンクション）は、単にデバッグしにくいなんちゃってプログラミング言語になっちゃった。
オンチェーン上のコントラクトアカウントに記述されたプログラムは、そのアカウントへの利害関係者のトランザクション送信が揃うと処理が実施されます。これを「アカウントベースのスマートコントラクト（下図左）」とします。一方でSymbolはオフチェーンでトランザクションのリストとしてスマートコントラクトを定義してノード(API Node)上に仮置きし、署名が揃った段階で処理を実施します。アカウントに記述するコントラクトに対して、トランザクションの並びと署名を条件として実施されるコントラクトなので「トランザクションベースのスマートコントラクト（下図右）」と呼べるかもしれません。
さて、何がどう違ってくるかを解説しましょう。
一般的なブロックチェーンの場合、1つのブロック内でのトランザクションの並びは保証されません。出金と入金が複雑に絡むような資金の流れを実現しようとする場合、署名されたTxをチェーン内部で一度預かり、順序を整理してコントラクトを実行する必要があります。これが、アカウントベースのコントラクトが必要な理由です。
しかし、Symbolが採用するアグリゲートトランザクションの登場により、複数署名が必要なトランザクションを1ブロック内に順序を指定して発行できるようになりました。複数署名をトランザクションリスト実行のための条件群(If)とみなすと、これはもうスマートコントラクトです。
さらにアカウントベースのスマコンはonchainでの処理を定義する必要があるため、専用言語で記述する必要がありますが、トランザクションベースのスマコンはあらかじめオフチェーンでトランザクションを組み合わせて並べるだけなので任意の言語で構築することができます。
どの時点でコントラクトが決定されるのかは興味深い点です。
たとえば、スマートコントラクトの実行にAlice(出金)、Bob(入金)、Oracle(価格決定)の3つの署名が必要だった場合、
アカウントベースのコントラクトはAlice、Bob、OracleのTX(Approve含む)送信が完了した時点でコントラクトが決定します。トランザクションベースのコントラクトはAliceがコントラクトを決定し、Bob、Oracleが追認します。アカウントベースのコントラクトへの署名が「処理の委任」といったイメージに対し、トランザクションベースのコントラクトへの署名は「処理の承認」といったイメージがあります。
これについてはメリット・デメリットがあり、一概にどちらが優れているということはできません。すべての処理に対して、スマートコントラクトに一存できるのであれば、アカウントベースのコントラクトは半永久的に処理を自動化することができます。対して、トランザクションベースのスマートコントラクトはすべての処理一つ一つに承認を求める形になります。テンプレート化しやすい単純な処理はアカウントベースのコントラクトで自動化し、契約のたびに署名構成が変わったり最終的に人の署名が必要な重要な案件についてはトランザクションベースのコントラクトで迅速に処理してしまうなどの用途に分かれるかもしれません。
さらに、Symbolは現在のMainchainの決済レイヤーとして位置づけ「処理の承認」に特化させ、「処理の委任」などが重要となるビジネスロジックをL2でロールアップさせるSubchain構想を進めようとしています。今後の展開にも期待ですね。
さいごに
今回ご紹介した機能がSymbolで実現したのは決してガラパゴスな進化ではなく、他のブロックチェーンがあえて避けてきたテーマに対してSymbolのコアデベロッパーが真摯に向き合って解決を試みた結果でもあります。
どのブロックチェーンにも得意・苦手な部分があり、得意な部分を洗練させて社会に実装されていきます。今、トレンドを作るプラットフォームが不得意な部分を避けた規格化により、勝手に未来の限界を作ってしまうのは非常に残念なことです。
まずはSymbolが実現する未来をより正確にイメージできる技術者が増えること。Symbolの言葉でも語れる人が増えれば、インターネットもう少し先へ進めることができるはずです。過度に誇張されたブロックチェーンへの期待から、それに続く幻滅期を脱するためには、着実に進化を続けるFushicho Symbolの衝撃が必要です。