トップへ戻る
公開日
2017年8月10日
筆者:Curvegrid
ウィリアム・メトカーフ

6日目:Gething RPCの作業

通常のウェブブラウザで DApp を読み込んで何かをしようとすると、JavaScript コンソールからのエラーメッセージが表示されます。

前回の記事「Test a DApp from First Principles」でも触れましたが、オリジナルのチュートリアルでも説明したように、クライアントにはmist(0.8.10) を、開発目的の「バックエンド」にはgeth(1.6.1) を使用しています。

通常のウェブブラウザで DApp を読み込んで何かをしようとすると、JavaScript コンソールからのエラーメッセージが表示されます。

Mistは通常、ディスク上のファイルを用いてプロセス間通信(IPC)を介してgethに接続します。

Mist <--(IPC)--> Geth

Webブラウザでは、Web3.jsライブラリとMistが促進するIPC geth接続がない状態です。

Browser <--(???)--> Geth

しかし、通常のWebブラウザでDAppを実行したい場合はどうすればいいのでしょうか?Web3.js と geth 接続が必要なようです。しかし、その前に、なぜ DApp を通常の Web ブラウザで動作させたいのでしょうか?また、逆に言えば、なぜ DApp ブラウザが存在するのでしょうか?

Mistブラウザの一部には、ブロックチェーンにアクセスするためのweb3.js機能があります。しかし、これは機能の核となる部分というよりは利便性の部分です。その機能を提供したい人は、ライブラリをロードするだけでいいのです。実際、Mistが提供するweb3に鎖でつながれていることは、最新バージョンを使いたいと考えている熱心なDApp開発者にとっては不利になる可能性があります。そして、Mistの開発者も同意ているようです。"このバージョンからは、Mistは独自のweb3.jsインスタンスを出荷しません。"

特別なウォレットブラウザが必要な主な理由は、Ethereumアカウントを管理するためです。これは便利なUIコンポーネントを提供しており、取引の承認やアカウントの作成などを自動的に促してくれます。デフォルトでは、起動時の標準的な場所にあるethにも接続します。

じゃあなんで普通のブラウザで開発するの?

  • 読み取りアクセスだけが必要で、ブロックチェーンに書き込みや変更をしたくない場合があります。
  • アプリケーションをできるだけ広く利用できるようにしたいと考えています。
  • セキュリティを嫌っている
  • セキュリティ周りのUIをコントロールしたい
  • geth とは異なるホスト上でブラウザを実行しています。
  • なぜなら、あなたは

Gethは、ネットワークを介してアクセスするためのリモートプロシージャコール(RPC)インターフェースを提供します。これを使って通常のWebブラウザを接続します。

Browser <--(RPC)--> Geth

物事を動かすためには、2つのことをする必要があります。

  1. web3.jsの読み込みと初期化
  2. クロスオリジンリソース共有(CORS)が正しく設定されている状態でRPCをオンにする

1.web3.jsの読み込み

そのままChromeでMistアプリを実行するとエラーが出ます。


捕まえられなかった ReferenceError: web3 が定義されていません。


web3はNode, Meteor, Bower, Componentでパッケージとしてインストールできます。libaryとドキュメントはこちらにあります。

https://github.com/ethereum/web3.js

ファイルをインクルードするか、お気に入りのローダーで読み込んでください。





また、以下のようにライブラリを初期化する必要があります。ポートは geth RPC を開始するポートと一致している必要があります。


var Web3 = require('web3').
web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"))。


2.RPCの起動

web3を正しく初期化しているのに、RPCが実行されていない場合や、アプリケーションからアクセスできない場合は、ブラウザに以下のようなエラーが表示されます。


検知されないエラー。CONNECTION ERROR.ノード http://localhost:8545 に接続できませんでした。


ドキュメントによると、RPCを起動して、gethコマンドラインでCORSドメインを指定することができます。しかし、どうやらRPCのコマンドラインフラグは、開発に使っているdevモードとは互換性がないようです。

便利な回避策は、JavaScriptを使ってRPCを起動することです。

まず、以下の内容を含むファイルstart-rpc.jsを作成します。


admin.startRPC('localhost', 8545, 'http://localhost:8080', 'web3,eth,personal')。


この場合、我々はポート8080でlocalhostからウェブサイト(htmlとJavaScript)を提供しています。

パラメータは


admin.startRPC('localhost', 8545, 'http://localhost:8080', 'web3,eth,personal')。

hostportNumberはそれぞれ geth RPC サーバを実行するホストとポートです。

corsheader の場合、上記の 'http://localhost:8080' のようにホストとポートを正確に指定しなければならないことに注意してください。つまり、以下のようになります。


admin.startRPC('localhost', 8545, '*', 'web3,eth,personal')。


セキュリティ上の理由から、必要なモジュールだけをロードします。この場合、web3、eth、personal(前述のチュートリアルでMistの処理の代わりにアカウント管理に使える)。

そして、gethを実行する際に、起動時に読み込むJavaScriptファイルをコマンドラインで指定します。


geth --dev js start-rpc.js


CORSを正しく設定できなかった場合、以下のようなエラーが表示されます。


XMLHttpRequest は http://localhost:8545/ をロードできません。プリフライト要求に対するレスポンスはアクセス制御チェックをパスしません。要求されたリソースには 'Access-Control-Allow-Origin' ヘッダーが存在しません。したがって、Origin 'http://localhost:8080' はアクセスを許可されていません。



そうでなければ、運が良ければ普通のWebページからWeb3を実行することになります。

セキュリティ補遺

2 番目の CORS の例では、ワイルドカードアクセスリストを提案しています。悪意のある Web サイトがユーザーのアカウントにアクセスする機会を与えてしまう可能性があるため、本番環境ではこれを行うべきではありません。しかし、動作に問題がある場合は、開発中にテストするのが妥当な構成です。

RPC 経由で geth を使用したセキュリティに関する他の点は、よりニュアンスのあるものです。権限のあるチェーンや特別に管理された環境を使用している場合、エンドユーザが自分のアイデンティティやトランザクションを直接管理する必要性はあまりないかもしれません。あるいは、それをシステムの別の部分に委任しているかもしれません。

公開されているEthereumブロックチェーンを利用している場合、特に個人のEtherを金融的に扱っている場合は、それらの個人のアカウントをどうするかについて非常に注意する必要があります。イーサの保管に関する推奨事項は、ユーザビリティの課題が残っており、現在進行形の議論となっています。

結論

ご参考になれば幸いです。RPCの回避策を行う原因となったコマンドラインの制約については、Mist 0.9.0の最新バージョンをチェックすると同時に調べています。それまでの間、コーディングを楽しんでください。