ノードを運用する意味
ブロックチェーンの特徴は、非中央集権の他に、データの共有、ゼロダウンタイム、対改ざん性です。ブロックチェーンの4つの特徴が重要であれば、何でもよいからブロックチェーンというわけではなく、結局のところブロックチェーンのシステム構成要素である多数のノードが、連載第3回で解説したようなそれぞれの役割を果たすように正しく運用されている場合に限ります。つまり、ブロックチェーンの4つの特徴はノードの運用により支える必要があります。
ブロックチェーンネットワークに参加するノードとしては、自分が責任をもって運用するノードと、自分ではコントロールが及ばない他者が運用するノードの混在状態となるケースが一般的になると考えられます（連載第3回のブロックチェーンネットワークの分類で紹介したようなパブリックやコンソーシアムの形態）。他者のノードの中には、悪意を持ってブロックチェーンネットワークの破壊工作を仕掛けてくるようなノードがある可能性もあります。そのような悪意のノードに対し、ブロックチェーンネットワークを守るのは善意のノードの責務です。ブロックチェーンネットワークを守るには善意のノードが多数派にならなければならず、その一端を担うのは自分のノードでもあると考えることができます。
また、連載第3回で解説した通り、ノードは自身でブロックチェーンネットワークが正しく機能しているか検証します。ノードは、盲目的にブロックチェーンネットワークを信頼するのではなく、自分で正しいと判断した結果としてブロックチェーンネットワークは正しく動いていると考えます。このような考え方を端的に表現すると、ノードはブロックチェーンネットワークに対して、Don't trust, verify（信頼せず検証）、またはTrust, but verify（信頼するが検証）といったことを実践しているのです。前者は不特定多数のノードが参加するパブリック型（Ethereumの公式ページでもこの考え方が言及されています）、後者は信頼された組織のみが参加できるコンソーシアム型でのverifyの実践です。
ブロックチェーンの耐改ざん性
耐改ざん性に対し、ブロックチェーンが話題になりはじめた頃によくあった誤解は、ノードのホストコンピューターに対する不正アクセス対策との混同です。特定のホストコンピューターへの不正アクセスによるデータ改ざん対策（例えば、ファイルの書き換え防止）は、ブロックチェーンの機能ではありません。そのようなことは、ホストのアクセス制限や監査ログの取得、IPS/IDSによる防御などによる対策で、従来のITシステムでの対策と同じです。
ブロックチェーンの対改ざん性とは、暗号学的に工夫されたデータ構造やスマートコントラクトの処理が決定的であることなどによる、正しさの検証可能性です。例えば、悪意のあるノードが暗号学的に整合性のない勝手な改ざんデータをブロックチェーン上で共有させようとしても、善意のノードは検証を通してそれを共有データとして認めず破棄するために改ざんは無効であり、したがってノードが持っているデータは実質的に改ざん不可能だということです。ノードが持っている検証済みのデータを保護することは、前述の通り、従来同様のホストコンピューターに対する防御のスコープです。
ノードを自分で運用しない場合、他人が運用するノードを信頼してブロックチェーンを使うことになりますが、その他人のノードに悪意があったらどうなるかは分かりません。悪意のノードは虚偽のデータを返してくるかもしれません。また、ノードはブロックを作ったり、ブロックのデータが正しいか検証したりするだけでなく、トランザクションをブロックチェーンネットワークに送信するためのゲートウェイでもあります。悪意のあるノードは、いつまでたってもトランザクションをブロックチェーンネットワークに送らなかったり、意図的にタイミングをずらして送ったりするかもしれません（例えば、暗号資産やNFTといった価値交換のブロックチェーンのユースケースでは、トランザクションの送信タイミングが金銭的な損害をもたらすかもしれません）。
自分のノードを使う場合と、他人のノードを信頼して使う場合をシステム的に比較検討すると、他人のノードを使う場合の方は、従来の集中型システムでクライアントがサーバーを全面的に信頼するような場合とほぼ同じになってしまうかもしれません（図3）。とはいえ、現時点のブロックチェーンの浸透度や状況の変化速度を鑑みると、ノードを扱える専門家が身近にいないケースや、ビジネスのリソースをノード運用ではない別のもっと優先度の高い作業に集中させたいかもしれません。そのようなさまざまな理由により、ノード運用を外部委託する場合でも、ブロックチェーンにアクセスするための多数の選択肢（これにより、ブロックチェーンが正しく動いているか必要に応じてチェックできる）があったり、将来的に自分でノードを持って運用する余地があったりというオプションがあれば、ブロックチェーンの必要性はだいぶ変わります。こうしたオプションがない場合、今本当にブロックチェーンで大丈夫かどうか検討の余地があるかもしれません。
まとめ
スマートコントラクトは、仮想マシンやコンテナといった実行環境の中でブロックチェーンの世界（オンチェーン）に閉じ込められており、決定的（deterministic）な処理しか行えないという制約があります。決定的という制約上、できないことが生まれます。例えば、処理内部でランダム値を使ったり、ノードの外側（オフチェーン）にあるWebサーバーと通信したりすることはできません。ただし、その制約に従っている限りにおいては、任意の処理を実装することができます。そして、この制約のおかげで、スマートコントラクトの処理内容はブロックチェーン上のどのノードでも検証できます。結果として、スマートコントラクトにも非中央集権や耐改ざん性の高さといった特徴がもたらされています。
一方で、現実的に価値あるシステムを作るには、ブロックチェーンの世界の外にあるさまざまなオフチェーンデータを必要とします。オフチェーンデータとしては、例えば、為替のレートや天候の情報などが該当します。オフチェーンのデータとオンチェーンのスマートコントラクトは、オラクル（Oracle）と呼ばれるシステムで連携します。重要な問題はオラクルにより提供されるデータが信頼できるのかです。どのようにオラクルに信頼をもたらすのかは、ブロックチェーンを活用する際の課題のひとつです。
ノードは、盲目的にブロックチェーンネットワークを信頼するのではなく、正しさを自分で暗号学的に検証します。ブロックチェーンネットワークに対するノードの姿勢は、Don't trust, verify（信頼せず検証）やTrust, but verify（信頼するが検証）と表せ、本来、このような検証は自分のノードで行うべきことです。また、ブロックチェーンネットワークには、自分のコントロールが及ばない他人が運用する多数のノードと、ネットワークの破壊を企むような悪意のノードも参加しているかもしれません。悪意のノードからブロックチェーンネットワークを守るためには、正しく運用されているノードが多数いなければならず、その一端を担うのは自分自身の責務でもあるのです。ブロックチェーンの4つの特徴である、非中央集権、データの共有、ゼロダウンタイム、対改ざん性は、このような善意のノードの運用により支えるものです。以上のような点が、ノードを運用する意味といえるのではないでしょうか。
とはいえ、他人のノードを使いたい場合もあります。その場合、参加したいと思っているブロックチェーンネットワークにアクセスする複数のオプションがあるかどうか、ネットワークが正常に機能しているかチェック可能かどうかを見極めてから、参加の是非を判断した方がよいかもしれません。
次回は、ブロックチェーンの代替の選択肢と、NFTを例にブロックチェーンのサービス構成について解説する予定です。
