AIとIoTによる自動化技術の発展に伴い、インターネットセキュリティの重要性はさらに高まっている。一方で従来のクライアント・サーバモデルは参加者の善意を前提とした本質的に非セキュアな仕組みであり、多額のセキュリティコストを費やしてもなおハッキングの被害を防げずにいる。
本稿では、新たなインターネットの形として、クライアント・チェーンモデルによる Blockchain Based Internet (BBI) を提唱する。さらには、BBIが浸透した社会である The Blockchain Based World (BBW) への移行にあたって大規模な変革が予想されることを示し、BBW実現に向けてのステップを提案する。
（The English version will come shortly. ）
※補足
本稿では、ブロックチェーンやDAG、Radixなどの分散台帳技術（Distributed Ledger Technology, DLT, Ledgerとも言う）の総称として「ブロックチェーン」という言葉を用いている。したがって、本稿に出てくる「ブロックチェーン」という言葉は「分散台帳技術」という言葉に置き換えてなんら問題はない。むしろ、DAGやRadixの方が特性的に好ましいケースもあると考えている。
IoTによるビッグデータの収集と、AIによるその解析、そしてロボット技術の発展により、自動運転をはじめとした日常のさまざまなものが自動化されようとしている。また、個人のデータを収集・解析することで１人１人にパーソナライズドされた商品を提案することも可能となっている。特にDNAや生活習慣に基づいたパーソナライズド医療には大きな期待が寄せられている。これらが実現すればより利便性の高い社会となるだろう。
一方で、AIとプログラムが、デジタルの世界だけではなく物理世界に進出してくるということは、ハッキングによる被害が現実の肉体にまで及ぶようになるということでもある。たとえば、自動運転プログラムを改ざんすることで自動運転車に人をひき殺させることや、個人の医療情報を改ざんすることで本人にとって毒薬となるような薬を処方させることも原理的には可能となってしまう。
このことはデータとプログラムに対するセキュリティ、特に耐改ざん性がますます重要となることを意味する。ブロックチェーンは、高い耐改ざん性をプロトコルレベルで提供し、来たる自動化社会・パーソナライズド社会の基盤となる。
現在のブロックチェーンの利用方法は特定のサーバアプリケーションを経由してチェーンにアクセスする中央集権的な方式となっている。そのために大規模なハッキングの標的となっている現状をまず分析する。
クライアントサーバモデルでは、データとプログラムを一元管理している中央サーバがクラッカーからの攻撃対象となりやすい。そのため、各サービス事業者は高いセキュリティコストを継続的に負担しており、そのコストはサービス利用料の形で利用者の負担となっている。
中央サーバの課題
ブロックチェーン技術は、非中央集権型のネットワークを構築することにより、そのような中央集権型のモデルから脱却し、セキュアなインターネットを実現することが期待された。
ところが現実には、ブロックチェーン技術上に構築された暗号通貨（cryptocurrency、仮想通貨とも言う）においてハッキング被害が続出している。2018年の暗号通貨ハッキング被害総額は、6月時点ですでに1,200億円（日本円換算）を超えており、年内には2,500億円を超える見込みである。人類史上最大のハッキング被害であるcoincheck社の事件も記憶に新しい。また、EtherおよびERC20トークンのウォレットとして人気の高いMyEtherWalletのDNSサーバがハッキングを受け、1,600万円相当のEtherが盗難されたこともブロックチェーン関係者に衝撃を与えた。
「セキュリティの向上」を期待されたブロックチェーンが、（恐らくは世界で最もホットな）ハッキング対象となっているのは大変な皮肉である。ブロックチェーンは単なる「中央機関が不正をできないようにするためのデータベース」で終わってしまうのだろうか。いや、ブロックチェーンの可能性はそんな小さなものではない。現在のブロックチェーンおよびインターネットはまだ過渡期なのである。以下、ブロックチェーン周辺領域への攻撃の分析を行った上で、インターネットに真のセキュリティをもたらす Blockchain Based Internet の概要を説明する。
ブロックチェーン周辺領域への攻撃として、記憶にも残りやすくインパクトが大きいのは暗号通貨の盗難であろう。そこで、これまでの暗号通貨盗難事件を元に、攻撃手法の分類を行う。
一番多い攻撃手法は、従来通りにサーバのセキュリティホールを突かれたり、サービス運営会社の人間にウィルスを送るなどの手法である。暗号通貨盗難で一番多いのもこのケースであり、おそらく９９％以上を占める。それは、現在のブロックチェーンアプリケーションのほとんどが従来通りのサーバを経由してチェーンにアクセスしているためである。
攻撃手法は多岐に渡るため、本稿でそれを尽くすことはできないが、クラッカーの攻撃目標として次の２つに分類ができる。
暗号通貨取引所をはじめとするホットウォレットでは、暗号通貨の授受に必要な「秘密鍵」（の少なくとも一部）がサーバに置かれている。この秘密鍵を奪取されると、その秘密鍵で管理されている暗号通貨を自由に使われてしまう。
また、秘密鍵をネットワーク外に保持している場合であっても、秘密鍵管理者のコンピュータへのハッキングによって鍵の奪取を狙う攻撃が可能である。
秘密鍵をサーバに置かずに自己管理する場合でも、現状ではブロックチェーンのアクセスには何らかのアプリケーションやウェブサイトを介することが必要である。その際、ブロックチェーンアクセス用のウェブサイトを改ざんされてしまうと、ユーザが気づかないうちに攻撃者のアドレスに暗号通貨を送信する攻撃などが可能となる。
現在のブロックチェーンアプリケーションの課題
ブロックチェーンそのものに対する攻撃もないわけではない。
コンセンサスアルゴリズムとしてPoW（Proof of Work、計算量証明）を採用している場合には、悪意ある人間がマイニングパワーの５１％以上を持つことによって、二重支払いが可能となる。monacoin, ZenCash, Vergeなど、マイナーの少ないアルトコインで実際に攻撃が行われた。
ブロックチェーンを稼働させるプログラム自体にバグがあった場合、攻撃の対象となりうる。実績が少なく、検証が不十分なチェーンにおいては、注意が必要だろう。
スマートコントラクトは、ブロックチェーンノード上で動作し、チェーン上の情報の書き換えなどを行う。このスマートコントラクトにバグがあった場合にも、攻撃対象となりうる。
このケースでの特に大きな事件としては、The DAO事件がある。スマートコントラクトによる投資プログラム「The DAO」のバグを突かれたことで、当時にして５０億円分のEtherが盗まれた。結果として不正な取引をなかったことにしようとするイーサリアムと、恣意的な取り消しを認めないイーサリアムクラシックとの間でのハードフォーク（チェーンの分岐）を招いた。
BBIはウェブサーバが持つセキュリティ課題を本質的に解決する。まず、現在のウェブサーバの特性を確認しよう。
ウェブサーバには本質的にセキュリティという概念が不足している。その背景には、インターネットがそもそも研究者間のネットワークとして誕生したため、参加者の善意を前提としていたこともあるだろう。しかし、インターネット上での情報流通・価値流通が拡大してきた現代、その前提が成り立たないことは周知の通りである。ウェブサーバのセキュリティ課題は本質的に次の２通りに分類できる。
基本的にデータはインターネットアクセス可能な領域に平文で保存されている。暗号化されているデータもあるが、復号鍵も同一ネットワークに置かれているため、サーバへの侵入を許せば、ほぼ平文でデータが置かれているのと同じである。そのため、データの取得や改変が容易に行われてしまう。
ウェブサーバは基本的にLinuxやWindows Serverといった汎用OS上に動作している。このことは自由度の高いシステムの稼働を許す一方で、セキュリティホールを生じやすい。
このようにウェブサーバは一度侵入を許すともろい作りとなっている。そのため現代的なセキュリティ対策としては、サーバへの侵入を防ぐ防護壁を設けることが一般的である。また、侵入後もroot権限の奪取を行いにくくするために種々の障壁を設けている。そのほか、攻撃を感知して緊急の対策を取れるようにするための監視も行われている。しかし、いずれの対策もサーバ（およびそのroot権限）という本丸に脆弱性を抱えているからこそ、本丸にたどりつく前に障壁を設けているだけであり、サーバそのもののセキュリティを向上させているわけではない。
現在のサーバセキュリティ対策
いかに対策を施しても、このやり方で攻撃を防ぎきることは不可能であろう。たった１箇所の穴を見つければよい攻撃者に対して、すべての穴を攻撃者よりも事前に発見してふさぐことは不可能であるからだ。かといってセキュリティ対策を行わないわけにもいかず、各企業は多大なコストをかけている。だがその努力もむなしく、米国インターネット犯罪センター（IC3）によれば、2016年のサイバー犯罪による被害額は報告されているものだけでも13億ドル（前年比24％増）を超えている。報告件数も約30万件（同4％増）と増加傾向にある。
今後、IoTとAIによる自動化技術が発展するほど、ハッキングは人命をもおびやかす可能性が高くなる。インターネットに真のセキュリティが求められている。
取引所をはじめとするホットウォレットへのハッキング被害のおそらく全ては、この従来のウェブサーバのセキュリティを突かれている。特にホットウォレットにおいては、秘密鍵がサーバ内にほぼ平文の形で置かれているため、通常のデータ流出と比べてその被害が甚大となる。
また、MyEtherWalletのようにサーバ上に秘密鍵を保存しない場合であっても、ウェブサーバを経由してチェーンにアクセスする以上、従来型の攻撃の対象となりうる。
そのため、ブロックチェーンにアクセスするサーバには、これまで以上にセキュリティ対策が求められる状況になってしまっている。
この状況を根本的に改善するには、インターネットサービスにウェブサーバを使うことをやめ、すべてのデータとプログラムをブロックチェーン上に置き、クライアントがブロックチェーンに直接アクセスするようにすればよい。このクライアント・チェーンモデルによるインターネットを Blockchain Based Internet (BBI) と名付ける。
BBI においては、クライアント・サーバモデルには存在しないオブジェクトが多数存在する。それらの構成要素と役割を詳述する。
Blockchain Based Internetの概要
BBIでは、スマートフォンやPCにアドレスと秘密鍵を保存する機能がOSレベルで備わる。後述のチェーンブラウザは、デバイスから秘密鍵を読み取り、電子署名や暗号化データの複合を行う。通常使うデバイス自体がコールドウォレットとなる形である。秘密鍵はデバイス内に暗号化して保存され、ユーザによるパスコードや生体認証によって複合して使用される。鍵の盗難を防ぐためにマルチシグ型の秘密鍵にして、デバイス、SIMカード、パスコードのすべてが揃わないと秘密鍵を使えないようにするなどのセキュリティも求められるだろう。
アドレスと秘密鍵はチェーンごとに異なるため、その管理が必要となる。アドレスと秘密鍵のペアを複数保存し、状況に応じて使い分ける場合も考えられるだろう。
現在、SIRINというプロジェクトにおいて、デバイス内に秘密鍵を持ったデスクトップOSとスマートフォンが開発されている。やがては iOS や Android が標準で対応するようになるだろう。
チェーンブラウザ（Chain Browser）は、後述のチェーンネームサービス（Chain Name Service, CNS) を経由してブロックチェーンアドレスにアクセスしたり、スマートコントラクトに対してトランザクションを送信したりする機能を持つブラウザである。またアクセス先のチェーンごとにどの秘密鍵を用いるかの判別なども行う。ブロックチェーン上に暗号化して保存されたデータをローカルにダウンロードし、秘密鍵を用いて複合・表示する機能も有する。
通常のHTML、CSS、JavaScript等を解析して実行・表示する機能を有する点は既存のブラウザと変わらない。ただし現在のDomain Name Service（DNS）だけではなく、CNSに対してもアクセスできる点が異なる。
チェーンブラウザは完全にオープンソースであるべきであり、場合によってはインストール時や起動時にハッシュ値をチェーン上の情報と比較して改ざんがされていないことも確認すべきかもしれない。
やがてはChromeやEdgeの標準機能となるであろう。
Domain Name Service（DNS）がドメイン名とIPアドレスの紐付け・変換をしているのと同じように、ドメイン名とブロックチェーンアドレスの紐付け・変換を行うサービスである。
CNSはスマートコントラクトとして実装され動作し、耐改ざん性を有する。
すでにEthereum Name Service（名前は *****.eth ）やNeo Name Service（名前は *****.neo ） など、多数のCNSが存在している。
現在は各チェーンごとに別のCNSが存在しているが、将来的には「どのチェーンの、どのアドレスか」という名前解決を行う汎用的なCNSが存在することになるだろう。また、従来のURI（****.com など）が送られた際には、従来のDNSに問い合わせを行う機能を持ってもよい。
BBIにおいて、すべてのデータと静的ファイル（HTML、CSS、JS、画像など）はブロックチェーン上に置かれる。もちろん、ここでブロックチェーンと述べているのは分散型台帳の総称であって、DAGやRadixなども登場するだろう。
秘匿性の高いデータを保存する場合（たとえば特定ユーザ向けのメッセージ送信）は、閲覧権限のあるユーザの公開鍵で暗号化してチェーンに保存する。そのため、秘密鍵を持つユーザにしか閲覧はできない。従来のサーバが暗号化のために１つまたは少数の鍵しか用いていなかったのに対し、データごとに（正確には閲覧権限ごとに）鍵が異なる形となる。そのため、秘密鍵を持たない攻撃者がデータを読むことはできない。また前述の通り、秘密鍵は原則としてネットワーク外に保持され、チェーンブラウザによってローカルで複合される。
静的ファイルやスマートコントラクトもすべてチェーンに記録されるため、耐改ざん性を持つ。さらに万全を期すには、ファイルのハッシュ値を複数のチェーンに保存し、２つ以上のチェーンのハッシュ値を比較するようにしてもよいだろう。
このとき、実現したいことに応じて、複数のチェーンを使用することになる。たとえば静的データの保管に適したチェーンや、スマートコントラクトを高速に実行するチェーン、商品情報などのデータベース保存に適したチェーンなどを組み合わせることが考えられる。チェーンブラウザは、CNSによる名前解決を通じて、複数チェーンから情報を取得・統合して表示する。
パブリックチェーンは、誰もがトランザクション承認ノードとなれるチェーンである。各ノードは、トランザクション手数料やマイニング報酬を目的としてチェーンに参加する。
データが各ノードに冗長化して保存されるために、ハードディスク資源とネットワーク資源を大量に消費することから大規模なデータの保存には向かない。一方で、ノード数が増えるほど耐改ざん性や可用性が高くなるため、CNSのようにデータ量が少なく、かつ完全性・可用性が重要なチェーンに有用と考えられる。
プライベートチェーンは単一ノードで稼働するチェーンであり、コンソーシアムチェーンは特定の少数ノードで稼働するチェーンである。トランザクション承認に参加するノードが少ない分、ハードディスクやネットワークへの負荷は少ないため、大容量のデータ保存や高速なトランザクション処理に適する。中央集権的にもなるためにノードの信頼性が問題となるが、チェーンのハッシュ値を定期的にパブリックチェーンに書き込むことで、間接的に無改ざん性の証明が可能である。
たとえば、SteemitのブロックチェーンはdPoS型で大容量のメディアファイルの保存も可能としているし、Stellerのように秒間に数万トランザクションをさばくチェーンも存在する。
これらのチェーンを特性に合わせて使い分けることでアプリケーションの運用コストをおさえることが可能となる。
BBIにおいて、チェーンサイドのすべてのプログラムはスマートコントラクトである。スマートコントラクトは、チェーン上に記録されているため耐改ざん性を有する。代償として、容易な修正ができないため、スマートコントラクトにバグがないことのチェックは極めて重要となる。
チェーンサイドプログラムとしては、静的ファイルの更新や削除を行うファイル管理プログラムや、情報の検索や集計を行うデータベースプログラムなどが考えられる。現在のサーバサイドプログラムがサーバ上のアプリケーションとして稼働するのに対して、チェーンサイドプログラムはチェーン上のスマートコントラクトとして稼働する。場合によっては、汎用チェーン上のスマートコントラクトとして実装する代わりに、専用のチェーンを構築しても良いだろう。
表示を担当するプログラム（いわゆるView）については、チェーン側の負荷を下げる意味で可能な限りクライアント側で行うことが望ましい。クライアントの性能が上がっているため十分可能であろう。
HTML, CSS, JavaScript, 画像, 動画などといった静的ファイルは、１アドレスにつき１ファイルの形でチェーンに保存される。URIが（CNSによる名前解決を介して）チェーンのアドレスと紐づくイメージである。現在使われている「リンク」は、サーバ内のファイル位置を示すのではなく、チェーン上のアドレスを参照するようになる。このようにすることで、現在無数に存在する静的ファイルをほぼそのままでBBIに移行することが可能である。
ファイルの保存や更新は、専用のスマートコントラクトとして実装される。ファイルアドレスと中身を引数にとるコントラクトに対してトランザクションを送信することで、（権限チェックの後）指定したファイルアドレスの中身が書き換わる仕組みである。ファイルアドレスが指定されない場合は新規でファイルアドレスが生成される。ファイルの削除を行いたい場合には、中身を空にしたトランザクションを送信すれば良い。
BBIにおいて、各チェーンは独立に存在するのではなく、ハッシュ値の（相互）保存や、分散型取引所を介したトークンの交換などといった形で結合する。
これにより、まだノード数の少ないパブリックチェーンや、プライベートチェーン、コンソーシアムチェーンなどの信頼性も担保することができる。
また、複数のAPIを組み合わせたアプリケーションと同じように、複数のチェーン上のコントラクトを組み合わせたアプリケーションの登場も予想される。その際にはインターチェーントランザクションが必須となる。汎用的なプロトコルの策定が求められる。
BBIにおいても、トランザクションの承認に参加するノードは依然として必要である。このノードは旧来通りのLinuxサーバで良いだろう。したがってノード単体では従来のようなセキュリティリスクを抱えることとなる。BBIの肝の１つは、複数のノードを束ねて１つのチェーンとすることにより耐改ざん性を確保することにある。
コンセンサスアルゴリズムによっては、IoT機器の１つ１つがノードとなるかもしれない。
BBIにおいては、従来のサーバが存在しない。また現在のサーバサイドプログラムにあたるスマートコントラクトが実行できることには大きな制約があるために、従来のような攻撃手法は原理的に成り立たない。
しかし、BBIにおいても攻撃が不可能なわけではない。可能な攻撃手法としては次のようなものがある。
前述（2.2章）の通り、ブロックチェーンおよびスマートコントラクトの脆弱性に対する攻撃は依然として可能である。
このうちブロックチェーンの脆弱性は、プロトコルの脆弱性であるから、将来的には新規の攻撃手法はほぼゼロとなると予想される。（TCP/IPの脆弱性を突くような攻撃はほぼ出尽くしているのと同様）
そのため将来的にはプロトコルの修正または上位レイヤーでの対策がされるだろう。
一方でスマートコントラクトは各サービス主体が開発するものであるからバグが入り込む余地が多く存在する。Quantstampのようなスマートコントラクトの脆弱性検知サービスも出てきてはいるが、それよりもスマートコントラクト記述言語自体をバグが生じにくい仕様にしておくことや、スマートコントラクトを実行するバーチャルマシンに不正検知の仕組みを持たせるなどの低レイヤーでの対策が求められる。
各デバイスに保存されている秘密鍵の盗難は、依然として有効な攻撃手法である。対策としては、秘密鍵を平文で保存せずに、ユーザしか知らないパスワードで暗号化して保存したり、マルチシグ型の鍵にして複数の鍵の奪取を必要にしたりなどが考えられる。秘密鍵については後述する。
Blockchain Based Internetにより、すべてのウェブサーバとデータベースが置き換えられた世界を The Blockchain Based World（BBW） と呼ぶことにする。BBWにおいては、次のようなことが自然な形で可能となる。
BBIは、従来のサーバに代わり、セキュリティを本質として備えたチェーンを提供する。これによりハッキングの難易度を上げ、サービス運営者のセキュリティコストを低減させる。また、サービス運営者内部による改ざんも難しくなるため、内部統制にかかるコストも低減する。
銀行などが介在せずとも、暗号通貨の送金を用いて、ユーザ間の直接的な価値交換が可能となる。秘密鍵による署名・複合はOSレベルで行われているため、一般のユーザはチェーンを意識することもなく、自然な価値交換を行うことができるだろう。トランザクション手数料の安い送金用チェーンも登場してくると考えられる。
個人情報を提示することなく、アドレスと秘密鍵による署名により「同一人物」であることの証明が自然と可能になる。
個人情報を送る際には、情報共有したい相手（たとえばネットショップの販売者など）の公開鍵で暗号化して共有する形となるだろう。
BBWがもたらす変化は極めて破壊的である。その変化のすべてを予想しきることはできないが、現時点でも以下のようなことが予想される。
価値交換がネイティブに行われるようになった結果、資金移動や決済を専門とする業者の存在価値は消滅する。資金調達や信用担保の需要は残るだろうが、それすらもスマートコントラクト化されてクラウド型で行うのがメインになるかもしれない。
現在、ウェブサーバの運用管理やレンタルを行っている事業者は、ブロックチェーン運営事業者へと業態変化をせまられるであろう。その際、月額課金型のビジネスモデルから、ブロックチェーンへの書き込みやトランザクションに費用が発生する都度課金型のビジネスモデルに変化せざるを得ないであろう。
また、現在行われているサーバセキュリティ対策のほとんどが不要となることから、サーバセキュリティ事業者の仕事もスマートコントラクトのバグチェックサービスなどに変わることとなる。
サーバサイドプログラムがなくなるため、現在使われているサーバサイド言語の多くは消滅するだろう。スマートコントラクト記述言語として採用された言語やクライアント側の開発用言語は残るであろう。
またサーバインフラエンジニアは、サーバの運用を行うのではなく、適切なチェーンの選定や運用を行うブロックチェーンエンジニアとなるであろう。
BBWでの１つのモデルケースとして、ECでのショッピングを考えてみよう。
ECにおけるユースケース
(1) ユーザは自分のデバイスからチェーンブラウザを起動し、アドレスバーに sample-ec.file と入力する。チェーンブラウザは、CNSに問い合わせて、sample-ec.file が FILEチェーン（静的ファイルの保存に適した仮想のチェーン）のアドレスXXXXXX を指すことを把握し、XXXXXXにアクセスして index.html を取得する。
（やがて、チェーンベースの検索エンジンが出てきてアドレスバーへの入力は不要になるはずだ）
(2) チェーンブラウザがindex.html を解析したところ、その中に sample-ec.file/shop.js と sample-ec.file/main.css が含まれていることを把握した。チェーンブラウザはそれぞれのファイルを同様に取得し、レンダリングを行う。
(3) レンダリングの途中で、チェーンブラウザは shop.js がSHOPチェーン（在庫情報などの動的情報を保存する参照用のチェーン）の情報 sample-ec.shop/items.db を参照していることを把握する。チェーンブラウザはSHOPチェーンから情報を取得し、shop.js の実行を続ける。
(4) ユーザにECの画面が表示された！
ユーザは気になる商品のリンクをクリックし、sample-ec.file/item1.html に移動する。このときのチェーンブラウザの処理は(1)～(3)の処理と同じなので割愛する。
(5) 欲しい商品が見つかったユーザは、注文情報（商品番号・個数・個人情報など）を、そのECショップの公開鍵で暗号化して SHOPチェーンに保存するトランザクションを投げる。これによって注文情報は、秘密鍵を持つECショップ運営者にしか分からない。
この際、同時にECショップのアドレスに対して、購入代金を暗号通貨で送金する。この際はOS標準のダイアログが立ち上がり、パスコードを入力することで秘密鍵がアンロックされて送金が可能となる。
少し工夫すれば、この際にスマートコントラクトが実行されて、送金金額が足りているかのチェックを行ったり、SHOPチェーンの在庫情報が自動で変更されるようにすることも可能だろう。
(5-1) 個人情報を入力するのが面倒であれば、PRIVACYチェーン（個人情報の保護に適したチェーン）に暗号化して保存してある自分の情報を複合して自動添付するようにしてもよい。その際も、個人情報自体を暗号化して送るのではなく、ECショップの公開鍵で暗号化しなおした個人情報をPRIVACYチェーンに保存し、そのPRIVACYチェーンのアドレスを送ってもよい。
(5-2) さらに言えば、ECショップに対して個人情報を送る必要はないかもしれない。自分の住所や名前は運送業者にだけ伝わればよいのだから、運送業者の公開鍵で個人情報を保存してもよい。これにより、ECショップは個人情報を保有するリスクがなくなり、暗号化された個人情報を運送業者に渡せば良いだけとなる。
(6) ECショップの担当者は、チェーンに記録された注文情報を読み取り、秘密鍵で複合する。秘密鍵はネットワークとは切り離された場所にあるので、ハッキングの心配もゼロだ。（もちろん物理的にパソコンを盗まれたりすれば別だが）あとは従来通りに注文を処理すればよい。
(7) ユーザに対してメッセージ（たとえば発送手続き完了など）を送りたい時には、ユーザのアドレスに対してチェーン経由でメッセージを送ればよい。
このようにBBWにおいては、サーバへのアクセスは存在せず、すべてがクライアントとチェーンとのやりとりで完結する。決済代行業者も登場しない。さらには(5-2)で書いたようにECショップは個人情報を保持する必要さえもなく、セキュリティリスクを極小化することが可能となる。
BBWでは秘密鍵が何よりも重要となる。秘密鍵によって個人認証や暗号通貨の使用が自由にできることはもちろん、サービス主体者であればチェーン上のデータの書き換えも秘密鍵に依存する。
仮に盗難にあわなくても、デバイスの故障やパスワード忘れなどで紛失してしまった時のためにも防護策は何重にも考えておかねばならない。
秘密鍵の管理においては、鍵を複数に分割し、そのうち一定個数以上があれば鍵の使用が可能となる「マルチシグ」が一般的になりつつある。たとえば３個に分割した鍵のうち、２個があれば使えるものを 2 of 3 の鍵と呼んでいる。サービス主体者はマルチシグの使用は必須となるであろう。
チェーンごとに鍵が存在するため、複数のチェーンをまたぐことを前提とするBBWにおいては、手動での鍵の管理は現実的ではない。
１つの方法としては、マスターとなる秘密鍵によって、自分がもつすべての秘密鍵を暗号化して、秘密鍵管理用のチェーンに保存しておく。マスター鍵はマルチシグにして自分が保有する複数のデバイスに分散して保持しておくと共に、パスコードによる暗号化を行っておく。パスコードを忘れた時のために複数のパスコードで暗号化したものも保存しておくと良いだろう。このようにすることで、デバイスを紛失したり、パスコードを忘れたりした場合でも、マルチシグのいずれかを取り戻せる可能性が高くなる。
秘密鍵（の一部）を盗難・紛失した際には、可能な限り速やかに、上述の方法で秘密鍵の復旧を行うと共に、新しいアドレスと秘密鍵を作成して、古いものからのデータ移行および権限委譲を行う。データ移行完了後は古い秘密鍵は削除してしまって問題ない。
この際、データ移行および権限委譲のトランザクションもチェーン上に保存される。そのため、古いアドレスからの一貫性が保たれると共に、古いアドレスが現在は使われていないことを対外的に示すことが可能である。
BBIが広く社会に溶け込んだBBWの実現に向けてはいくつかの課題が存在する。現状で見えている課題を列記する。
秘密鍵の扱いは上述のように極めて重要である。社会への普及に向けてはこの点の研究がより深く必要である。
ブロックチェーンの耐改ざん性は、複数のノードがコンセンサスを取る点に依存する。そのためのコストとして、データを冗長保存することによるハードディスク資源の消費と、そのデータを送信するネットワーク負荷の問題が生じる。
そのため、何千、何万というノードが参加するパブリックチェーンに大容量のデータを保存することは好ましくない。データそのものはコンソーシアム型チェーンに保存をするようにし、ハッシュ値をパブリックチェーンに書き込むことでチェックする形が現実的だと思われる。
また、一定のタイミングでスナップショットを取り、古いトランザクションを消去することも必要になるかもしれない。
現在のチェーンの多くでは、クライアントサイドでも全トランザクションを保持せねばならない。その容量は時に数十GBにも達し、チェーンブラウザを実装するにあたって大きな問題となりうる。解決策として、自分に必要なデータだけを保存するようにする方法（EthereumのPlasma Cashなど）や、クライアントからのアクセスを受け付けるためのパブリックなノードを立てる方法（EthereumのINFURAなど）が考えられている。
しかし、前者ではチェーンが複数になった場合、全体の容量は大きくなってしまう可能性が高い。また後者の方法では、ノードの信頼性が重要となってくる。複数のパブリックノードの情報を統合して改ざんや不正がないことを確認する方法が考えられるが、いくつのノードを確認すれば良いのかなど検討が必要である。
Radixなどシャーディング機能を持った分散型台帳では、各ノードがトランザクションの一部のみを保存する。実用化すればスマートフォンなどのストレージの小さいデバイスもトランザクション承認者となれる可能性がある。
大規模なサーバサイドプログラムをスマートコントラクトに移行するには多大なコストが発生することが予想される。また、スマートコントラクトへの移行が不可能なプログラムももしかしたらあるかもしれない。（チューリング完全なスマートコントラクト言語であれば、原理的には移行可能なはずではあるが）
一方で大規模なプログラムを保持している企業ほど、多大なセキュリティコストも払っているはずであり、BBIへの移行は長期的にはコストメリットを有すると考えられる。
ブロックチェーンプロトコルに問題があった場合のアップデート方法も考えておかねばならない。たとえば、暗号方式として現在主流の楕円暗号は量子耐性を持つと知られているが、それでも１００年、２００年の単位で破られないとは言い切れない。暗号方式の変更に迫られた際に、旧式の暗号方式によるトランザクションをどう扱うべきかも課題となる。
いずれにせよ、まずはBBIのMVPを開発し、人々がイメージできる状態にすることが大切だと考えている。そのための実現ステップを示そう。
BBIのMinimally Viable Product はすぐにでも実現可能な領域に来ている。ここでは実現のためのステップの一案を紹介する。
Minimalなチェーンブラウザとしては、単一チェーンのアドレスにアクセスし、そこに書かれているメッセージを取得してレンダリングできればよい。
秘密鍵の保存もチェーンブラウザ内で行うことにすれば、既存のオープンソースブラウザに若干の修正を加えるだけで実現可能である。
チェーン側には、トランザクションのメッセージ部にHTMLなどを記述しておく。
現在の主要なチェーンは、容量の大きなデータを保存するためには作られていない。そのため大容量の書き込みに際しては高いトランザクション費用が発生してしまう。そこで容量の大きな静的ファイルの保存に適したFILEチェーンを開発する。FILEチェーンは、ウェブサーバに類似し、コンテンツ本体だけではなく、Content-typeやContent-lengthも返せると良いだろう。
ネットワーク負荷とハードディスクの容量をおさえるために、コンセンサスアルゴリズムとしては、dPosやPoAなど、少数のノードで行えるものが望ましい。この分野もすでに多くのプロジェクトが走っている。
チェーン内の名前解決だけではなく、どのチェーンのアドレスかも解決してくれるような汎用的なCNSが存在することが望ましい。チェーンの判別ができた後は、すでにCNSが存在するチェーン（EthereumやNEOなど）に関しては、そのチェーンのCNSに処理を委譲すれば良い。まだCNSが存在しないチェーンの場合には、そのチェーン独自のCNSを作り処理を委譲する方法と、汎用CNSの中で名前解決をすべて行ってしまう方法とがある。おそらくは汎用CNSで処理しきる方が全体的には低コストだろう。
また、従来のURIが渡されたときには、従来通りのDNSに処理を委譲することで、チェーンとウェブサーバが併存する過渡期においてもスムーズなブラウジングが可能である。
チェーンに関する情報は、古い情報や間違った情報も多く、技術者が十分に育っていない状況である。プログラミング初心者でも簡単にチェーンをさわれて実装ができるような教育プログラムの構築が求められる。
ここまで舞台を整えれば、あとは市場原理に任せればよいだろう。チェーン間の検索エンジンも出てくるであろうし、既存のサービスをチェーン上に構築し直すサービスも現れるだろう。やがてOSネイティブに秘密鍵を保存するようにもなるだろう。（そうなれば、チェーンブラウザからは秘密鍵を保存する機能を外して良い）
筆者は数多くのブロックチェーンプロジェクトを見る中で「なぜこのプロジェクトにブロックチェーンが必要なのか？」を常に問うてきた。しかし、その多くはブロックチェーンを使う必要のないものであったり、実現性やプロセスが考慮されていない机上の空論であったりした。
BBWの世界では「なぜブロックチェーンを使うのか？」という問いは意味をもたない。すでに見たように「ブロックチェーンしか存在しない」からである。
本稿では現実のセキュリティ課題をブロックチェーンだからこそ解決できることを示し、その実現のためのプロセスを提示した。アイデアは現実の形となって初めて価値を発揮する。よりよい社会の実現のために微力ながら邁進したい。
BBWでは、サービス主体者が存在することを前提としている。その意味でブロックチェーンが持つ「非・中央集権」を「非・中央サーバ」の意味にせばめている。
その理由としては、自己の利益を追うのは人間の本性であり、その欲求がなくなることなどありえないと考えているからである。（ここでいう利益、というのは金銭的な意味に限らず、名声や社会的承認なども含む）
中央が存在せず、したがって中間マージンがかからない世界は理想的ではあるが、貢献に対する報酬のない世界で努力する人間は現実には存在しないであろう。
ただし、BBWにおけるサービス主体者は、必ずしも企業などに限らない。BBWでのサービス主体者とは、秘密鍵の保有者である。
となると、株の代わりにマルチシグの秘密鍵を分配することで権限を分散するような組織も考えられる。たとえば秘密鍵を１００個に分配し、○○を実行するにはそのうち７０個の秘密鍵が必要、□□の実行には５０個の秘密鍵が必要、といった形にすれば国家権力によらずとも議決権と同様のことが可能となる。
BBIは既存のウェブの延長上にある。すなわち既存のインターネットに不足しているセキュリティ、個人認証、価値交換をプロトコルレベルで提供する。一方で、BBIでなければ原理的に不可能なサービスというのは存在しないと思われる。
今まではコスト的に不可能であったサービスが実現する余地は出てくる。また、AIを用いた自動化に際してはデータとプログラムの無改ざん性は必須の要件であることから、BBIは将来の前提であり基盤であると考える。
最初に述べた通り、ブロックチェーン以外の分散型台帳（Distributed Ledger、単に Ledgerとも言う）にも大きな可能性があり、将来は各種のLedgerが併用して使われるようになるだろう。
そのため、本稿で述べたような内容は、Ledger Based Internet、the Ledger Based World、Ledger Name Service、Ledgerブラウザ等々と呼ばれる形で実現することと思われる。
ただ現状ではブロックチェーンにすら正確な認知が少ない中で、より多くの方にこの世界観とメリットを理解していただくために、Blockchain の言葉を用いた。
以上
Inspired by Satoshi Nakamoto, Vitalik Buterin, Yoshitaka Kitao
Special Reviewers: I.Funahara, T.Ibaraki , S.Takagi, N.Takeuchi
