Day 6：Gething RPC Working

前回の投稿で言及したように、ファーストプリンシプルからのDAppのテストの通り、元のチュートリアルに記載されているように、私たちはクライアントとしてmist（0.8.10）を使用し、開発目的のためにバックエンドとしてgeth（1.6.1）を使用しています。

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

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

Mist <--(IPC)--> Geth

ウェブブラウザでは、あなたはweb3.jsライブラリと、Mistが提供するIPC geth接続がありません。

ブラウザ <--(???)--> Geth

しかし、私たちが通常のウェブブラウザでDAppを実行したい場合、私たちを止めているものはweb3.jsとgeth接続だけのようです。しかし、そのような偉業を試みる前に、なぜ私たちが通常のウェブブラウザでDAppを実行したいのでしょうか？逆に、なぜDAppブラウザが存在するのでしょうか？

Mistブラウザの一部は、ブロックチェーンにアクセスするためのweb3.js機能です。しかし、これはコア機能というよりも便利さの一部です。その機能を提供したい誰でも簡単にライブラリを読み込むことができます。実際、Mistが提供するweb3に縛られることは、最新のバージョンを使用したい熱心なDApp開発者にとって不利になる可能性があります。そして、Mistの開発者たちは同意しているようです：「このバージョン以降、Mistは独自のweb3.jsインスタンスを出荷しなくなります。」

特別なウォレットブラウザがある主な理由は、あなたのEthereumアカウントを管理するためです。それは、トランザクションを承認したり、アカウントを作成したりするために自動的に促す便利なUIコンポーネントを提供します。デフォルトでは、起動時に標準の場所でgethに接続します。

では、なぜ通常のブラウザで開発するのでしょうか？

• 読み取りアクセスのみが必要で、ブロックチェーンを書き込んだり変更したりしたくない

• アプリケーションをできるだけ広くアクセス可能にしたい

• セキュリティが嫌い

• セキュリティに関するUIを制御したい

• gethとは異なるホストでブラウザを実行している

• できるから

Gethは、ネットワーク経由でアクセスするためのリモートプロシージャコール（RPC）インターフェースを提供します。これが、私たちが通常のウェブブラウザに接続するために使用するものです。

ブラウザ <--(RPC)--> Geth

物事を運転させるためには、私たちが二つのことをする必要があります：

1. web3.jsを読み込んで初期化する

2. クロスオリジンリソースシェアリング（CORS）を正しく設定してRPCをオンにする

1. web3.jsの読み込み

Mistアプリケーションを変更なしでChromeで実行すると、次のエラーが表示されます：

Uncaught ReferenceError: web3 is not defined

Node、Meteor、Bower、またはComponentでweb3をパッケージとしてインストールすることができます。ライブラリとドキュメントは次の場所にあります：

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

ファイルを含めるか、好きなローダーでロードします。

<script src="js/web3.js"></script>

また、ライブラリを次のように初期化する必要があります。ポートは、geth RPCを起動するポートと一致する必要があります。デフォルトでは8545です。

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

2. RPCの起動

web3を正しく初期化したがRPCが動作していない場合、またはアプリケーションからアクセスできない場合は、ブラウザで次のようなエラーが表示されます：

Uncaught Error: CONNECTION ERROR: Couldn't connect to node http://localhost:8545.

ドキュメントによれば、gethのコマンドラインを通じてRPCを開始し、CORSドメインを指定することができます。ただし、RPCコマンドラインフラグは、開発のために使用している開発モードとは互換性がないようです。

便利な回避策はJavaScriptを使用してRPCを開始することです。

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

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

この場合、私たちはlocalhostのポート8080からウェブサイト（HTMLとJavaScript）を提供しています。

パラメータは:‍

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

hostとportNumberは、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 cannot load http://localhost:8545/. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8080' is therefore not allowed access.

さもなければ幸運なことに、普通のウェブページからweb3を実行していることになります。

セキュリティ補足

二番目のCORSの例は、ワイルドカードのアクセスリストを提案しました。これは、悪意のあるウェブサイトがあなたのユーザーのアカウントにアクセスできる機会を与える可能性があるため、本番環境では行うべきではありません。しかし、問題を解決するために必要な間は、開発中に試すには合理的な構成です。

RPCを介してgethを使用する場合の他のセキュリティ上のポイントは、よりニュアンスが必要です。パーミッションチェーン上または特別に制御された環境で使用する場合、ユーザーが直接自分のアイデンティティまたはトランザクションを管理する必要はないかもしれません。また、別のシステムの一部にそれを委任しているかもしれません。

パブリックEthereumブロックチェーンを使用している場合、特に個人のEtherを金融的に取り扱う場合、これらの個人のアカウントに対して何をするかについては非常に注意する必要があります。Etherの保存に関する推奨事項は、残された使いやすさの課題とともに、進行中の議論です。

結論

これが役立ったことを願っています。私たちは、RPCの回避策を実行する原因となったコマンドラインの制約を調査しながら、最新のMist 0.9.0のバージョンをチェックしています。その間に、楽しいコーディングをして、次回お会いしましょう。