見出し画像

ブロックチェーンを分かりづらくしているブロックチェーン脳のジレンマ

先のポストで「実装を試してみては?」と軽く書いたが、既存のウェブアプリケーションについては熟知している方々も実際にブロックチェーン上の分散型アプリケーション(dApp)と聞くと気後れすることが多いと思う。

例えば、Qiitaあたりを覗いても、ブロックチェーンのノードを立てるところからの説明が多い。

ちなみに、どのブロックチェーンでもDockerやdocker-composeを用いればノードを立てること自体は操作上は容易だが、いわゆるフルノードの場合、凄まじいマシンスペックを要求される上、同期にも時間がかかるため、気後れして当たり前だ。クラウド上で試すにしても、月数万円の出費は免れない。

結論から言えば、いわゆる(狭義の)dAppとは、何のことはない、公開のAPIエンドポイントとの通信を行う一般のウェブアプリそのものである。ブロックチェーン のノードを自分で立てる必要はない。

Ethereumにおいては、INFURAというサービスがポピュラーで、通常のウェブAPIサービスと同様にユーザ登録してユニークなエンドポイントURLを取得するだけで利用できる。

特殊な点としては、Chrome/Firefox + MetaMaskなどのウォレット機能拡張を用いてインジェクトされるweb3というAPIを用いること(これもよくある話といえば、よくある話であるが)、ブロックチェーンへのトランザクションの反映が非同期であること(これも特殊な話ではない)くらいである。

もちろん、Ethereum上のスマートコントラクトの実装には、Solidityという言語でのコーディングとデプロイにおいての多少の知識は必要となるが、まずはERC721などの基本的なコントラクトをそのまま転用してみて、フロントエンド側の実装を色々と試してみることから始めてみるとよいだろう。下記のリポジトリが分かりやすい。

もう一点、スマートコントラクトのデプロイや書き込み処理の実行にETHが必要ということで気後れしている人もいると思うが、まずはテストネットで試してみればよい。無料でテストネット用のETHを手に入れる方法は検索すれば分かると思う。

ちなみに、ノン・ファンジブル・トークン、ERC721を試してみたい場合は、OpenSeaのテストネットがRinkebyであるため、テストネットとしてRinkebyを利用したほうがよい。

ということで、正直、ウェブアプリが書ける人間であれば、誰でも書ける。

とはいえ、エンジニアの方でも、この事実を初めて知ったという方は多いのではないだろうか。こんなことなら、もっと早く始めていたし、もっと普及していたのでは?と思われて当然だと思う。

何故にことほど左様に分かりづらい事態を放置しているのか?
理由はよく分からないが、筆者は心理的なものと見ている。

要は、APIエンドポイントとの交信とは中央集権そのものであり、ブロックチェーンのドグマに反するのだ。だから、あまり大っぴらにしたくないのではないか。

もちろん、教義的な話だけではなく、INFURAに依存するウェブアプリという構造においてのブロックチェーンは単なる迂回したオーバーヘッドでしかないので、本当にバカげた話ではあり、実際、Ethereumのコア開発者であった Afri SchoedonもTwitterで以下のような発言を行っている。(その後、氏はEthereumを離れ、当該ツイートも削除されている)

If we don’t stop relying on infura, the vision of ethereum failed. If we don’t stop relying on infura, the vision of ethereum failed. Or build a strong network of thin and light clients. There is no point in having d-apps connecting through metamask to a blockchain hosted by someone else.

もちろん、単なるウェブアプリの状態を抜け出すために様々な技術革新が行われようとしていることも事実ではあるのだが、そういった技術革新が落ち着いたときに市場参入しようとしても手遅れになるかと思われるので、やはり、今すぐにでも試してみることをおすすめしたい。

実際のところ、単なるウェブアプリと思って実装していけば、パブリックデータベースや送金手段、公開鍵認証基盤としてのブロックチェーンの強みや凄みがどんどん浮き彫りになることに気づくはずだ。

この記事が気に入ったらサポートをしてみませんか?