本連載（前半記事はこちら）では２本に分けてブロックチェーンに外部データを取り込むOraclizeについて解説します。前半ではブロックチェーン上に外部情報を取り込むOraclizeの基本的な面を解説しました。後半の本記事では、Oraclizeを実際に利用する部分に焦点を当て、特筆するべき機能などを解説します。
公開鍵: 044992e9473b7d90ca54d2886c7addd14a61109af202f1c95e218b0c99eb060c7134c4ae46345d0383ac996185762f04997d6fd6c393c86e4325c469741e64eca9
このツールと公開鍵を使用して前半の記事中で書いた以下のoraclize_query関数を暗号化してみましょう。
平文: oraclize_query(“URL”, “json(https://poloniex.com/public?command=returnTicker).BTC_ETH.last")
暗号化ツールをダウンロードして以下の様に実行すると暗号化された引数が得られます。
>python encrypted_queries_tools.py -e -p 044992e9473b7d90ca54d2886c7addd14a61109af202f1c95e218b0c99eb060c7134c4ae46345d0383ac996185762f04997d6fd6c393c86e4325c469741e64eca9 “json(https://poloniex.com/public command=returnTicker).BTC_ETH.last”
>AzK149Vj4z65WphbBPiuWQ2PStTINeVp5sS9PSwqZi8NsjQy6jJLH765qQu3U/bZPNeEB/bYZJYBivwmmREXTGjmKJk/62ikcO6mIMQfB5jBVVUOqzzZ/A8ecWR2nOLv0CKkkkFzBYp2sW1H31GI+SQzWV9q64WdqZsAa4gXqHb6jmLkVFjOGI0JvrA/Zh6T5lyeLPSmaslI
この暗号化された引数を使うことで、queryを暗号化できます。
oraclize_query(“URL”,”AzK149Vj4z65WphbBPiuWQ2PStTINeVp5sS9PSwqZi8NsjQy6jJLH765qQu3U/bZPNeEB/bYZJYBivwmmREXTGjmKJk/62ikcO6mIMQfB5jBVVUOqzzZ/A8ecWR2nOLv0CKkkkFzBYp2sW1H31GI+SQzWV9q64WdqZsAa4gXqHb6jmLkVFjOGI0JvrA/Zh6T5lyeLPSmaslI”);
またOracizeでのデータソース型（今回の場合は”URL”を選択している）も同様に暗号化することでさらに安全な実装にすることもできます。
※上記の暗号化ツールは現状Pythonのversion2.~~のみで動作し、Python3では実行できません。
この暗号化されたoraclize_queryの使用はメインネットのみで可能なので、testnetでの検証では平文で使用し、実装する際に必要に応じて暗号化を行うようにしましょう。
3. 検証結果はどこへゆく？
TLS_NotaryやAndroid_Proofなどの信頼性検証の結果データは数キロバイトとブロックチェーンに刻むには比較的大きいです。そのためOraclizeでは分散データベースIPFSにデータを保存し、そのデータの場所を示すポインタを__callback関数の引数として取得データと共に返します。
IPFSではmultihashと呼ばれるアルゴリズムでこのポインタを生成しています。miltihashのポインタはデータごとに固有の値を持ち、また内部のデータが万が一変更された場合にはポインタの値自体も変わるようなアルゴリズムです。
つまり、提供されたポインタを使って検証結果にアクセスする限り、その検証データは信頼できることになり、このデータを用いて検証結果を確認することができます。この検証データの保存機能もメインネット上でのみ提供されているサービスになります。
4. Proof Shield: オンチェーン信頼性検証
3. で書いた通り、Oraclizeで取得したデータはIPFSに保存され、ブロックチェーン上にはそのポインタのみが保存されています。ユーザはこのデータをOraclizeが提供している検証ツールや、webアプリ（http://app.oraclize.it/service/monitor）を用いてオフチェーンで検証することができます。しかし、裏を返せば、オンチェーンでの検証、つまりsmart contractを用いて検証結果が正しいかどうかを確認することはできませんでした。この問題を解決するのがProof Shieldです。
ここで注意しなくてはいけないのが、Oraclizeのサーバは取得したデータの信頼性検証の結果に関わらずデータを__callback関数で返し、検証結果のデータをIPFSに保存します。
つまり、もしOraclizeがデータを取得する経路で不正があった場合、改ざんされたデータが__callback関数で返されます。このとき、検証結果をオフチェーンで確認をすれば取得データが信頼できないと判断することができます。（ちなみにOraclizeが運用されてきた3年弱で、このようなデータ改ざんは一度もありません。）
しかし、この検証はオフチェーンで行わなけばいけないため、実装の手間が掛かります。
Proof Shieldは、Oraclizeでの検証結果のデータ量を減らすことによって、Ethereum上のマシンで信頼性検証を可能にします。つまり、smart contract自体に信頼性を検証する機能を実装し、その結果、データが信頼できるのであればそれを用い、信頼できないのであればデータを使用しないという判断をオンチェーンで行うことが可能になります。
これは多少実行時のgasが増えますが、セキュリティ面でもより安全であり、かつデータ取得から検証までの必要な操作をすべてsmart contract上で実現できるという大きなメリットをもたらします。
現状ではProof Shieldを使用する際に取得データサイズの制限など、幾つかの制限がありますが、ほとんどのケースで使用可能です。また本機能は開発中であり、testnet上でのみ使用可能ですが、mainnetで使用できる日も近いでしょう！
まとめ
前半の記事では、オラクルがなぜ必要なのか、代表的なオラクルとしてOraclizeの基本的な仕組みを解説し、後半の本記事では、実際に運用する際には、gaslimitを最適化することでOraclizeの利用コストを最適化できることや、引数の暗号化、検証データの保存の仕組み、そしてより安全かつ便利なオンチェーン検証: Proof Shieldについて概説しました。
本記事の中で不明な点、誤りなどありましたら、以下のメールやTwitterを経由してご連絡お願いします。
tut.it.mus1c+manekineko[あっと]じーめーるどっとこむ
