【第6回】Ethereumの全体像を理解する - Dapps作成とは
こんにちは、えたろうです。
「少しだけ易しいMastering Bitcoin」を一通り読んだ方は、Bitcoinの仕組みはだいたい理解できたかと思います。
Bitcoinでブロックチェーンの基本を理解した後、次のステップはやはりEthereumの理解ですよね。
- 「Bitcoinの仕組みはだいたい分かった！ブロックチェーンすげぇ！」という方
- 「Ethereumでスマートコントラクトが実現する云々」「Ethereum上で Dappsを作る云々」というのはよく聞くけど、実際Ethereumってどう動いてるの？という方
を対象にして懇切丁寧に書いて行きます。
第6回では「Ethereum上でDappsを作るとはどういうことかを理解する」のを目標にします。
「そもそもブロックチェーン上にアプリ作る必要あるの？」「ブロックチェーン使うと何が嬉しいの？」という点については、一旦棚にあげて、ここでは仕組みだけを解説します。
Ethereum上でアプリを作るとは
【第1回】Bitcoinを通じて理解するEthereum で「Ethereum上にアプリを作る」仕組みについて
ブロックチェーンアプリを開発したい開発者は、自分の外部アカウントを作り、コントラクトアカウント = アプリ用のプログラム を生成します。
一方で、ブロックチェーンアプリを使いたい利用者も自分の外部アカウントを作り、そこに存在する利用したいアプリのプログラムにリクエスト(トランザクション)を送り、コードを実行させて使用します。
このとき、利用者の外部アカウントの存在から、ここで作られたアプリのプログラムコード、アプリのデータ、履歴まであらゆる情報がイーサリアムのブロックチェーンに保存されるのです。
このことから、開発者は「自分たちのサービス独自のノードを世界中に用意しなくても、イーサリアム上にプログラムを作成すれば、データ全てがイーサリアムのブロックチェーンに保存される」ブロックチェーンアプリケーション(ブロックチェーンを使ってデータが分散的かつ非中央集権的に管理されるアプリケーション)を作ることができるのです。
のように説明しました。
この節ではより詳しい解説をしていきます。
Ethereumは「世界の状態」を常に記録して行くブロックチェーンであり、そのEthereum世界を構築するEthereumのアカウントには、「人間」と「プログラム」に当たる「外部アカウント」と「コントラクトアカウント」の二種類があるのでした。
これらのアカウントの構造を振り返ると、以下の通りです。
Contractアカウントは、CodeHashとStorage Rootを持つことを思い出して下さい。
Ethereum上にアプリ(Dapps)を作るとはどういうことかを以下で見ていきます。
(1)開発者がDappsプログラムを作成する
開発者は以下の手順でプログラムをEthereumブロックチェーンにデプロイします。
①
Ethereum上にDappsを作りたい開発者は、まずEthereum上で処理を実行するノードの集まりであったEVM(Ethereum Virtual Machine)で実行可能なプログラムコードを書きます。
EVM上で実行可能なのはEthereum Byte Codeなのですが、これを人間が理解して記述するのは大変なため、EVM向けに開発されている Solidity (JavaScriptに似たプログラミング言語)やVyper(Pythonに似たプログラミング言語)などの高級言語でプログラムを作成します。
②
開発者はアプリのプログラムを作成したら、自分の外部アカウントから「プログラムコードをInputに入れて」コントラクト生成トランザクションを作成します。
③
そのトランザクションを伝搬し、トランザクションがブロックに刻まれることで Ethereumブロックチェーン上にプログラムがデプロイされたことになります。
(もちろんコントラクト生成トランザクションを実行するのにGasがかかります)
このような手順でDappsプログラムがデプロイされた結果、
図のようにEthereumブロックチェーンの中に開発されたDapps用のプログラムがコントラクトアカウントとして存在することになります。
コントラクトアカウントは、CodeHashの部分にプログラムコードのハッシュを持ち、Storage Rootにアプリのデータを保持できます。(正確には保持したデータのマークルパトリシアツリーのRootを保持します)
我々が普段PCやスマホで使用するアプリケーションは、
・「データを保存しておくデータベース」
Twitterでいうと誰がどんなツイートをしたか過去全部のデータ等
・「そのデータを変更するプログラム」
ツイートをするプログラム、ツイートを削除するプログラム等
・「そのデータを読み取るプログラム」
プロフィール情報を表示するために読み出してくるプログラム等
・「そのデータをデザインに入れ込み、画面に表示するプログラム」
タイムラインの画面を表示するプログラム
・「画面に表示する画像や動画」
タイムラインに表示する画像、動画
といった様々な要素で成り立っています。
Dapps において、Ethereumブロックチェーン上に作られるContractアカウントは、このうち「データを保存しておくデータベース」と「そのデータを変更するプログラム」「データを読み取るプログラム」の役割を担います。
(2)ユーザーがDappsプログラムを使用する
デプロイされたDappsを利用するユーザーは、自身のEthereum外部アカウントを使って、Dappsコントラクトアカウントにトランザクションを送ることでそのプログラムを実行します。その結果として、アプリのデータに何らかの変化が起こってその新しい状態がEthereumブロックチェーン上に反映され、保存されるのです。
この「ユーザーが外部アカウントを使って」というのは、専用のブラウザなどのソフトウェアを使うことで行われます。
最もpopularなものはGoogle ChromeにExtension(拡張機能)として'Metamask'というウォレットを組み込む方法です。
Metamaskと自分のEthereum外部アカウントが紐づいている(正確にはMetamaskによって外部アカウントが新しく作られる)ことで、通常のWebアプリと同じようにブラウザでアプリケーションを操作する中で、GUIで外部アカウント(EOA)を使うことができます。
このように利用されるDappsには課題点もあります。
まず、もちろんユーザーがアプリ上で何らかの(ブロックチェーンに刻まれる)データの変更を行うたびにGasがかかります。
これは、プログラムの実行とそれによるデータの変更をトランザクションで行わなければならないためです。
これが「Dappsではユーザーが利用料Gasを払うのか？そんなんじゃ利用しなくね？」「Gasは運営持ちにする？そこまでしてDappsにする？」「これまでは利用者は無料だったけど、運営がそのコストを払っていた！利用者がコストを払えるようになるのが革命なんだ！」というような様々な議論を呼んでいます。
また、前述した通りアプリには、「データをデザインに入れ込み、画面に表示するプログラム」も「画面に表示する画像や動画」も必要です。
それらをユーザーのスマホアプリやブラウザが受け取って実行し、ユーザーの端末の画面を表示しなくてはユーザーはアプリを使用できませんね。
これらはブロックチェーン上に保存するべきではないとされています。
なぜなら、画面を表示するプログラムがブロックチェーン上に存在する場合、ユーザーが画面をロードする度にトランザクションを実行しなければならないので非効率すぎる(一つの画面を表示するのに死ぬほど時間がかかってしまう)ことになるからです。
そのため、「データをデザインに入れ込み、画面に表示するプログラム」や「画面に表示する画像や動画」はブロックチェーンの外で管理してユーザーに届ける必要があります。
(3)実際のDapps運営の仕組み
上述したような問題があるため、実際に現在あるDappsの大半は、以下の図のような「通常のWebサーバーでホスティングする方法」で運営されています。(CryptoKittiesやEtheremonなどの主要なDappsの大半は一つ目の図の仕組みで運用されていますが、Dappsの中には可能性としては2つ目の方法で運営されているものもあり得ます。)
「むやみやたらにブロックチェーンからトランザクションによってデータの読み込みをすると非効率になる・遅くなる」という問題を解決するために、
①
通常のWebサーバーに「データをデザインに入れ込み、画面に表示するプログラム」や「画面に表示する画像や動画」を置いておき、そこからユーザーのブラウザにResponseを返して表示
②
アプリデータを読み取るだけの処理は、必要なときにその都度トランザクションで読み取るのではなく、できるだけキャッシュ(Webサーバーに保持すること)しておくことで読み取りトランザクションの回数を減らす
③
アプリデータの変更(書き込み)処理のみ、Metamaskなどの専用ソフトウェアを通じてユーザーのEOAアカウントから行う
or
アプリデータの変更(書き込み)に関わる処理を、Gasの手数料を送金してもらい、それが確認できた時点でWebサーバー側でデータの変更を伴うトランザクションを発行する。
といった仕組みになっています。
(4)現状のDappsの問題点と対策
しかし、これではDBにあたるブロックチェーンはオープンであるものの、「ユーザーが見ている画面」や「このボタンを押したらどんな処理が実行されるのか」などが管理者単独で決定されているため、完全に分散化されたアプリケーションではないです。(Dapps[Decentralized application]というよりはCapps[Centralized application]ではないかと言われています)
(例えばユーザーごとに別々の画面を見せて.........などが可能になってしまっています)
このような現状の対策として以下の2つが考えられています。
1. ユーザー自身がプログラムを保持してアプリを使用する方法
運営者がGithubなどのサイトからアプリのプログラムをDLできるようにしておき、ユーザーはそれをDLして自身のPCの中でプログラムを実行し、アプリを使用する方法です。
2. ホスティング自体を分散化する方法(分散化ホスティング)
ホスティングをするWebサーバー自体を分散化し、検証プロセスを挟むことで、各ホスティングサーバーが正しいデータをユーザーに対して返していることを保証する方法です。
これも完全に分散化したパブリックなチェーンとして検証作業をするならば、Ethereum上にホスティング用のプログラムコードも載せてしまった方が良いことになります。
そのため、単独の管理者がホスティングを管理するのではなく、「複数の管理者がホスティングを管理する」ように分散化できるようなイメージだと思います。
※ちなみに従来のWebサービスは以下の図のような仕組みです。これと比較すると、Capps、Dappsではそれぞれ「どの部分が分散化されているのか」が良く分かると思います。
第6回では「Ethereum上でDappsを作るとはどういうことか」について詳しく見ていきました。
分散型アプリケーションといっても、「アプリのどの部分を分散化するのか」「どこまで分散化するのか」がアプリケーションの用途によって違ってくることがお分かり頂けたかと思います。
次回は「Ethereum上でトークンを発行するとは。ERC20, ERC721はどういう規格か」について、書きたいと思います。
続き↓