ERC721トークンがエンジニアに与える巨大なインパクト2 〜会社をイーサリアム化した話〜
前回はERC721トークンがイーサリアム上の「実物」の役割を果たし、あらゆる同期処理を簡略化することで、インフラシステムを構築する労力・コストを格段に下げる可能性について、抽象的に説明しました。
[ERC721 in 30秒]
では今回実際の実装ではどのようにコードすればよいのか見ていきたいと思います。
作ったものはこちらになります。
ここにもあらかた説明はありますが、詳しく下で補足します。
まず設計。
一般的なブロックチェーン(仮想通貨)をもつ企業における、参加者の権限を4種類に分けることとします。
まず①株主②社員③ブロックチェーン参加者④その他
これら4つの権限について別々の資料をサーバーから返せるようにします。
つまり、株主にしか見せない資料があったり、全員に公開するデータも存在するというわけです。
これをトークンの保持してるかどうかによってサーバーの応答を変えるのです。
ではどう実装しましょう?
①1種類のERC721トークンに4種類の権限を表す属性を与えることにします。
これはERC721トークンをそもそも4種類にすることと本質的にちがいます。
そもそもERC721トークン規格に固執するのは、前回でも書いたとおり、トークンがウォレットと取引所で扱えるようにしておきたいからです。つまり、4種類の721トークンにしてしまうことで、取引所・Metamask等のウォレットのUI上で、構造的には同じコインが全く別のものとして表示されてしまうという不都合が将来的に生じます。
②さて、ここでサーバー側の都合を考えてみましょう。
あるクライアントからEthereumのアドレスあるいは公開鍵の情報をつけて、サーバーにリクエストが送られます。サーバー側からは、このクライアントが本当にそのEthereumアドレスの秘密鍵の持ち主かどうかは分かりません。
よって、権限に対応する送りたい情報を公開鍵で暗号化して送ります。すると秘密鍵の持ち主のみが暗号を解読できるので、とりあえず暗号化して返せばよいのです。
ここまで簡単であれば良かったのですが・・・。
Metamaskのようなブラウザウォレットからは公開鍵は取れませんし、秘密鍵をJavaScriptで操作することを許してくれるわけもありません。つまり、暗号化も復号化もMetamaskでは難しいでしょう。そもそも僕がクライアントサイドのセキュリティを万全にする自信もありません。
ここでひと工夫入れます。
ERC721トークンの属性の一つに、持ち主のみが設定できる公開鍵を入れておくのです。これによりトークンの持ち主が好きにパスワードを変更できるようにもなります。構造は以下のように変化します。
これは非常に面白い結果です。なぜなら、イーサリアムのアドレス生成時の生まれた1組の公開鍵・秘密鍵のペアを用いて、多くの鍵を追加し、ほかのサービスに認証を行えるようになるのです。
当然、パスワード(公開鍵)は持ち主が好きに変えられるので、トークンの送信で権利を委譲する際に、設定した公開鍵とペアの秘密鍵を送らなくても、何の問題もありません。
SolidityのコードとJSクライアントによるスマートコントラクトの実装例を示しましょう。
ここの本質的な部分はPolicyトークンの属性部分と鍵生成Keygen部分になります。
イーサリアムのセキュリティ・プライバシー
今日イーサリアムを使うユーザーには隠し事は許されません。これが先ほど、僕たちがわざわざERC721トークンに公開鍵を設定し、サーバー・クライアントのウェブプログラミングを使って、データを隠した理由の半分です。(残りの半分はコストの都合です)
もし、イーサリアムに変数を権限のない人は絶対に見れないシステムを作れたとしたら、僕たちはデーターやデータへのリンクをそこに入れておいて、正しい権限を持った人だけがデータを引き出せる関数をつけるだけで済んだのですが・・・。
現在の仕様だと、本質的にはイーサリアムのマイナーが変数の中の値が正しいかを検証してブロックを作る時点で、どんか粋な隠し方をしても、マイナーにはバレてしまうものです。ちなみにイーサリアムのデータは次のように全て読むことができます。
結局、プライバシーに関わる部分はチェーン外での暗号処理を行う方針が筋のよいインフラ構築になりそうです。
今回我々が提案した方法はAWSとEthereumのHALF&ハーフです。 既存のクラウドとのすり合わせをすることが思わぬほど大きい利益がある印象でした。
これらの方法は
で議論しています。
僕たちの主な着眼点は「既存クラウドのレガシーコードをいかに有効活用して全員の手間を減らすか」という部分にあります。トークンエコノミーの到来には、ブロックチェーンが嫌いな人にも使ってもらえる形が存在する必要があると考えています。
雑感
今回の「社内システムのイーサリアム化実験」で嬉しかったことは
— 極度消耗(しなさい) (@leo_hio) May 30, 2018
①ERC721は仮想通貨ではないので、スマコンがらみの規制からは自由であること
②チェーン内の暗号はチェーン外でも有効であること
この性質を利用するとかなり速くEthereumを実社会に導入できます。
というのが技術的な雑感です。
そして見えてきたのは逆にクラウドの「聖域」ですね。
S3,Dynamoといったデータベース、そしてEC2とLambdaといったコンピューティング、Route53などのDNS・ネームサーバー関係はまだまだチェーン外のみで動くケースが多く、StorjやIexecなどのプロジェクトがクラウドの分散化を攻略しようとしていますが、少なくとも日本の保守的なクラウドインフラ側はしばらくはドキュメントが豊富で動作が安定、補償もばっちりなAWS、Azureを使うでしょう。
最初にクラウドでEthereum移行できるのはどの分野なのか、どうやって既存の仕様を壊さずに導入するかを議論していきたいと考えています。
ERC721トークンがエンジニアに与える巨大なインパクト1
お久しぶりです。極度消耗https://twitter.com/leo_hioです。
前まではイーサリアムのインパクトを新しいエコノミー的な側面で捉えて色々考えていましたが、最近エンジニアへのインパクトはどれほど強いか考えてみました。
結論から言えば、同期を扱うシステム全般に関して大きな仕様の変化を起こしうるのではないかということです。
エンジニアというのは、基本的に周りから「このライブラリ使うといいよ♥」とか「このプラットフォームをみんな使ってるから君も使ってね☆」みたいな話に振り回されながら生きていると思います。
つまり、プラットフォームの仕様がこれから大きく変われば、エンジニアにとって巨大なインパクトがあるのです。
ERC20トークンはイーサリアムと仮想通貨取引所の都合で作られた規格ですが、知っての通り、Bancor、AugerやGolemを始め、大量の有名仮想通貨をイーサリアム上に展開することを可能にした、経済インパクトの大きなシステムでした。
ここにきて、半年ほど前から新しいシステムが流行り始めます。
ERC721トークン規格です。
これは代替不可能なトークンと定義され、最小単位は1(小数点は許されない)。
一つ一つが区別できて、人に渡したら、自分の分はなくなるトークン。
つまり、ヌイグルミや絵から人間まで、分割不可能で個性のあるものへの権利を表現できるトークンと言まっしゃろ。ある意味イーサリアム上の”実物”と考えても良いです。
ERC20は通貨、ERC721は権利書と考えると分かりやすいです。
当然、このERC721は不動産取引などに明らか使えそうなので、色々な人が注目していますが、実はさらに近いところにインパクトがありそうです。
721トークンはありとあらゆる物への権限を管理するシステムを構築するコスト・労力を大幅に下げることができる可能性があります。
さらに言えば、同期を必要とする分散システム全般の構築のコストに関しても同様の効果があるかもしれません。
例としては、
①ソフトウェアのシリアルナンバー、AWSのPolicy、SNSのアカウント、ファイルの実行権限や特定メモリ領域へのアクセスといったシステムへのアクセス権限関係
②クラウドサービスと端末の同期問題(iTunesなど)、Wifiのハブ選出問題(FreeWifiに勝手につかまるアレ)、DNSサーバーの更新のラグ問題、航空管制の分散処理エラー問題等
が挙げられます。
どちらもスコープと同期の問題であり、
「変数が知らないうちに変わっててバグが起きた」
「あるノードからのリクエストの処理中に他のノードにも対応するとバグが生まれた」
「ネット上ではどちらが”上”なのか分からないので競合した」
といったことが原因となるものです。
このスコープと同期を解決しうるのがERC721だと考えています。なぜなら
①Ethereumに接続するノードの間では、コントラクトに書かれた変数(721トークン)は全ノードに共有され、事実上の最高スコープである。
②代替不可能であり、同期に必要な代表ノードは保持者と決まっている。
ここが多少説明が必要そうですので下記「※同期の難しさ」を参照下さい。
なぜERC721限定???
ここで正統な疑問が生まれます。
②を満たすようなSolidityコードを書けばよい話では?というものです。
ここで面白いのは、721トークンは共通規格でウォレット間で送信可能・売買可能というものです。
つまり、ERC721であれば、取引所等で売買が広く行われる可能性があるわけで、それはソフトのシリアルナンバーや各種権限の売買に直結します。つまりはソフトウェアやAPI,クラウドをシェアリング的に使う経済を意味します。
ちなみにERC721トークンの取引所は仮想通貨交換事業者の資格が要らない可能性がありますので、もしかしたら第2のコインチェックが今どこかで生まれているのかもしれません。
同期の難しさ
なぜ同期は難しいのか。僕は自分の環境でプログラムを動かす時は支配者は僕であり、プログラムの実行順序が僕の時間での実行順序となります。
しかし、他のノードが別の環境でプログラムを動かして、僕のプログラムの中の変数を変える時、相手の実行時間に依存し、時間軸は2つとなります。この数が多くなる時、僕は大量の相手の時間軸(都合)を考えて適切な処理を施す、サーバー(奉仕者)になります。
列に並ばない客がレストランに同時に沢山来て、何人かは「相席でもいいから座らせろ!」何人かは「相席は絶対やだ」と言い、空き席が複雑な配置をしている時、受付だったらどうします?
この問題は管理者が複数人必要な場合、管理者を決めることから始まります。レストランの問題で言えば、「だれがあの客たちの対応する?」といった具合です。
ネットワークや並列プログラムの実行の場合、リーダー選出という分散合意を行うことが多いです。
①権限の階層が決まっていないことによる優先順位が決まっていない状態
②どのデータをどの時に見るべきかというスコープが明確でない状態
は同期の問題を悪化させます。
また、多くの学習者がプログラミングでつまづく3つのステップ(ループ→再帰→並列)のうち、並列をやらずにプログラマーになるので、同期処理に難しさを感じる頻度が多いのは初見であることも影響すると考えられます。
このように、同期とスコープが大幅に簡略化される可能性が生まれたわけですが、どんな影響が生まれるか下で見ていきましょう。
脱、奉仕的サーバー!!
たまに乱暴なんだけど有能な管理者をみることがあります。
「ここに書いといて!」とか「登録しといて!」とかが口癖のイメージですが、本人も含め全員のやることが少なくて全員満足そうな結果に終わるカンジです。
彼/彼女らの真似をプログラマーはできないでしょうか?特徴を考えてみましょう。
①声がでかい
管理者の声が通らないことは問題です。管理者の発言のほうが全体にとっての情報量がクライアント・クレーマーのそれより大きいためでしょう。
②差別する
優先順位が決まっていることが重要であれば、それによって対応が変わることが保証されることも重要でしょう。
③自己責任を使う
参加者がまともな行動をするインセンティブが必要です。自己責任を果たせない時のペナルティは排除ではなく「②差別する」で優先順位を落とされることでしょう。
僕は基本的にこれらの要件を満たす管理者を代替するシステムを作れる自信がありませんでした。その上、AWSのIAMやGithubのように上手くできているシステムもほとんど知りません。
理由は簡単で、タダでさえ難しい同期処理を行いながら、①②③の要件を満たすのは至難の技なんではないでしょうか?同期処理にバグがある可能性があるなら偉そうなことするの怖いですし^^;
しかし、①②③だけでいいというなら話は別です。
これがこれからのERC721で構築される新しいインフラであるという仮説です。
次はコードを使ってこの仮説をトレースしていきます(続く)
CAPの定理とライトニング・ネットワーク ~オフチェーンの本質~
こんにちは 極度消耗( @leo_hio ) です。最近、各々のブロックチェーンや仮想通貨がどんな方向に向かっているか、何に苦しんでいるのかを分析する方法を考えていたのでシェアします。
分散システムに対する限界を示すCAP定理を基本に考えると、オフチェーンをはじめとする仮想通貨技術が何を目指しているのか整理がつきやすいと思ったからです。
ブロックチェーンの限界?
分散システムとして有名なブロックチェーンはどこまでも改良できるわけではありません。
CAPの定理と呼ばれるシステム工学的な制限がついており、
(C)誰がやっても同じ反応をする ・整合性 C
(A)いつでも反応する ・可用性 A
(P)どっかにネット接続の問題があっても動く ・分散耐性 P
の3つを同時に満たすことはできない という夢もロマンもない展開が待っているそうなのです。
ビットコインの場合はCかAを満たしていません。
念の為3ブロック承認まで待つと数十分反映にかかるのでA可用性がダメになりますし、
承認されない状態では多くのノードが別々のブロックに好きなブロードキャストされたトランザクションを取り込んでいるので、資産データに保証がない状態でC整合性が明らかにダメになります。
つまり(A)可用性と(C)整合性のトレードオフ(シーソゲーム)です。
(詳しくは ブロックチェーンとCAP定理 )
ライトニングネットワーク構想はCAP定理を無視?
これだとビットコインって画期的じゃなくない?って話になりそうですね。実際、「ビットコインとかCAPからしてダメだから」みたいなブログも英語でよく見ました。しかしこれが間違いであることをこれから明らかにしていきます。
翻ってライトニング・ネットワークは非の打ちどころがないシステムに聞こえています。
(後で読んで下さい ビットコインにおけるライトニングネットワークの仕組みを分かりやすく解説 )
「ブロック承認を待たず、一瞬で安く送金」
CAPの定理からしたら何かを犠牲にしなければなりませんが、何を犠牲にしたのでしょう?
答えは「C整合性をさらに犠牲にした」
というものです。
これを知るためにはまず、僕が先ほど作ってしまったCAPの誤解を解く必要があります。
「C・A・Pの全ては成り立たない」と書きましたが、これらは 成り立つ/成り立たない の0・1ではなく、全部を最大化はできないという連続的な話であるということです。
(CAP定理を見直す。“CAPの3つから2つを選ぶ”という説明はミスリーディングだった - Publickey)
ライトニングネットなしのビットコインは中途半端に整合性がありました。
正直、世界中の何万のノード・コンピューターで同じデータを同期し、同じ計算をしているのに関わらず、送金のデータベースを秒単位で更新できない状態というのは、あまりコストパフォーマンスがいいとは言えません。「整合性のための凄まじい努力」が整合性に反映されず、行き場をなくしている部分があったのです。
ライトニング・ネットワークでは、ブロードキャストされない、つまり世界中で同期はされない送金データを一部のメンバーで大量に持つことで送金速度(システム更新頻度)を上げることをしています。全部メインのブロックチェーンに書き込んで更新することをやめる「オフチェーン」と言われる処理です。
当然、「一部のメンバー」に別々の大量のデータが最新状態としてあるわけなので、整合性は途中下がりますが、最終的にブロックチェーンを更新する際に保証されます。
結論としてはライトニング・ネットワークは、基本的にA可用性(送金の速さ)に全振りし、たまにC整合性を保証する システムと言えるでしょう。とてもテクニカルにCAP限界を回避している気がします。
ACIDというウザい校則とBASEという不良ファッション
データベースには
「区別されていて、一貫していて、更新が明確にされていて、ちょっとの障害じゃ壊れないべきだ」
というACIDと言われる校則のように守れと言われる基準があります。先ほどC・A・Pで満たせと言われていたものです。
しかし同時に成り立たないので、「このうち一つを犠牲にしろ」という分かりやすいクソマジメな職員会議のような議論がでます。
しかしBASEという合言葉が学園では流行り始めます。
だいたい可用(Basically Available)
整合性はめんどいけど(Soft-State)
最後には守る (Eventually Consisitent)
これで①②③から選べという話から、①②③のうちどれをどのくらい守るか
という話に変わりました。
こんな風潮で器用な奴がでてきて、このASID規則のグレーゾーンを攻め始め、全部守っているかのように振る舞い始めます。信用を守れるようにタイミングをみて規則を守り、他ではダラける。BASEの特徴はCAPの限界を見かけ上突破したように取り計らうことです。
今までのACID的だったビットコインがBASE的になる・・・。
これがライトニング・ネットワークです。(オフチェーンって不真面目そうなカンジしますね笑)
逆に先ほどの守れっていう要望を努力で受けようというのがBCHのビッグ・ブロック派と言えるでしょう。確かに努力でブロック生成を増やしますが、やはり真面目で元気な生徒(大手マイナー)しかついてこれないという問題点もあります。
一方イーサリアムはどうでしょう?
前述の通り、オフチェーンは広くエコシステムのスケーラビリティに貢献するものです。イーサリアム上のオフチェーンプロジェクトはライデンとiexecが知られています。
イーサリアムの場合、ビットコインより事情は少し複雑です。スマートコントラクトまでオフチェーンで行わなければなりませんから。
これを一般的にオラクライズ(Oraclize)と呼びます。
iexecは大量の計算を使うようなオラクライズを行うというものです。
ソースコードを見て頂けると分かりますが、Ethereumの拡張のようなカンジになっており、オフチェーンを使った分散アプリケーション(Dapps)を作ることができます。
これは、広くEthereumのメインのチェーンとの整合性を取らないことで、負担を減らすこととなる他、スマートコントラクトの承認速度も上がることでしょうし、Ethereumとその上のDappのウィンウィン関係を作る可能性が考えられます。
というのも、現状Ethereumと多くのDappは整合性のとりすぎによってルーズルーズの関係となっていることはCAP定理からも示唆されている通りです。全てのDappsの全てのスマートコントラクトが全世界で整合するべきでしょうか?
CAP vs BASE(オフチェーン) は続く
2018年は多くの主要通貨がオフチェーンによりスケーラビリティ・CAPの問題を打ち破ることでしょう。
一番注視する点はライトニング・ネットワークです。
情報科学科2年生であれば不可能だと教わるCAPのトレードオフを回避するわけなのですから、僕からすれば偉業にしか見えません。
BTCでの一瞬での支払いとBTCが500万円突破という2つの「最高の体験」は今年起こるのか楽しみです。
仮想通貨に投資するときに必要なCAPの視点
申し上げたとおり、原始的なブロックチェーンにはCAPの限界がつきまといます。
実はこの点はずっと前からアーリーアダプターたちが気にしていたらしく、
http://www.meti.go.jp/committee/kenkyukai/sansei/fintech/pdf/005_04_00.pdf
この経済産業省の資料にもCAP基準による設計方針が書かれています。
まず、CAP的限界についてプロジェクトがどう考えているかを確認することで、開発陣が
①そもそも問題を把握しているか
②トレードオフ問題をどう解決しようとしているか
を知ることができます。
トランザクション・コントラクトがリアルタイムで行われるか気にしていないプロジェクトがあったとしたら、長期投資には向かないと考えています。というのも、Ethereumが送金でさえあれほど支障をきたしていたのにスマートコントラクトをバンバン使うプロジェクトに将来的に問題が起こらないわけがないからです。
というわけで、githubのコミット進捗を確認する以外にも、開発陣への信頼度を確かめる方法が考えられたと言えます。
もし、何か他に思いついたら暇人アカウント @leo_hio に連絡下さい。よろしくお願いします。
2017 情報科学若手の会を振り返る
10月7〜9日、伊豆の近くの伊東市で開かれた情報科学若手の会に参加しました。
情報科学若手の会は、プログラマーや情報系の大学生が集まって、昼に各自のプレゼン、夜にゲームと飲みをする3日を過ごすというものです。軽いようで50年の伝統がある面白いコミュニティです。
泊まった山喜旅館はゆっくりと時間が流れてて、物静かそうなプログラマーたちがポツポツと眩しい木造りのエントランスに集まってくるのは、記憶に残るシーンになりました。
写真はこちらからお借りしました。 山喜旅館 伊豆伊東温泉 | 井伊部長の温泉グルメ探訪|
Geomerlinのコーダー、ヒルマ氏はギリギリにやってきました。
セキュリティキャンプや競プロのメンバーもちらほらいます。
1日目にヒルマ(@CoRe103)のスマートコントラクトに関する発表、3日目にヒオキ(@leo_hio)の地政学リスクの算出アルゴリズムに関する発表が控えており、ヒルマは割と深刻に緊張していたそうです笑。(本人談)
1日目のスマコンの発表はだいたいこれと同じコンセプトの発表ですが、この菅野積分のところを@CoRe103が改造し、わかりやすくまとめ上げたものです。
(ギハブに実験コードあがっているので、あとで貼り付けます。・・・というより、発表のリファレンスで実験コードあったので出した方が良かったですね。指摘してくれた方ありがとうございます)
ソーティングコンセンサスは、順位付けの合意システムであり、機械学習モデルをアップロード・共有しなくても、判断とその材料をソートして提出するだけで合意が生まれるという、簡潔さを重視したシステムです。
去年、ブロックチェーンに関するトピックは0だったらしいんですが、今年3つに増えたのは偶然なのかな・・?というのも、ビットコインの値段や話題度の話だけでなく、ありとあらゆるコンセプトのコインが市場を通して有名になったことで、ブロックチェーンの汎用性やインパクトがあまりにも鮮明になりました。これはプログラマーのコミュニティでは発信するほうだけでなく、聞く方も増えるのは想像に難くないです。
ちなみに僕も発表時間が5分余ったので、ブロックチェーンによる海外投資へのインパクトについて説明しました。
O久保さんのライトニングネットワークの解説は、とても丁寧で、特にチャンネルの開け閉めの部分は詳しい解説を求めていたので、かじりついて聞きました。メンバーからの質問も鋭く、「ブロックチェーンのフルノードが減って大丈夫なのか?」という点は、今でもビットコインコミュニティでは議論されています。
”ディセントライズ”、この抽象コンセプトと守るために何GBほどの議論がビットコイナーの間でされてきたでしょう?
個人的には、ライトニングネットワークのチャンネル中継ノードは、インターネットでのDNSサーバーみたいなもので、”ディセントライズ”を強く脅かすものではないと感じています。
この日の夜は、QRコード版スプラトゥーンという異様なゲームをしました。これ考えた人誰だろ・・・すごい。
クイズに答えたら、読み取れなくなるまでQRコードにフセンを貼っていけるというルールです。
このゲームのあとはひたすら夜遅くまで飲んでました。
とりあえず覚えていることは、みんな酒が入ってもプログラミングのことをずっと話すくらい没頭しているということ。慶應とお茶の水が若手の会ではメインストリームということ。みんな暮らした田舎をディスりつつ、すごく好きでプライドがあるということ。・・・・かな。
2日目も同じ調子でしたが、割と夢中になるトピックが多いので、過ぎるのが異様に速かった気がします。日経でのAIのプロジェクトの話、懐かしのCTFの昨今、Nixという新しい環境。夜のライトトークを含めると30ほどトピックがあり、本当に色々です。
3日目、井上さんの前というプレッシャーの中、発表しました。
市場ではよく聞く地政学リスクという概念。
なんとなく分かったような雰囲気、しかし改めて考えると、そして実際に市場で揉まれてると後付に感じる。
しかしながら、GPR-Indexの登場でその状況も変わろうとしているということをまず伝えようと話した。
詳しくは下記リンクで。
そして、GPR-Indexのリアルタイム化、局所化の方法について提案した。 これによって政治的な
「天気予報」ができると言うと、分かりやすいかもしれない。
ここで、僕があのプレゼンの時に伝えられなかったことをココに書いておきたい。それは、僕たち庶民にとっての地政学リスクの日常化だ。
多くの人にとって地政学リスクは一日どころか一年の間でも考えることなんてない。生活に関係ないからだ。しかし、これからは関係が出てくると考えて良いと思う。
少し前に、イギリスに行った時のこと。覚えているのが、列車のチケットの値段が分単位で変わっていたことだ。まるで為替みたいに。
細かい需給の情報が価格に反映されていたのだが、おそらく列車でテロでもあれば、チケットの値段は次の1分では激動するだろう。
社会の状況がますます正確でリアルタイムに価格に反映されるようになっている。これはインターネットによる社会変化の一種かもしれない。
これにさらに拍車をかけるのがブロックチェーンだろう。仲介をなくして、自動で権利や資産が移動するブロックチェーン社会で、社会の状況の変化はすぐに品物の売買へと結びつくようになる。つまり、それは地政学リスクや海外の情勢がすぐに品物の価格に反映する世界を表している。
そして、その社会では海外への投資はもちろん、海外を経由したお金のやりとりは当たり前になるだろう。中国に入港したワインが余ったらしいから、買って一週間後の誕生日プレゼントにするくらいは期待できそうだ。
もっと広い世界のことを当たり前に気にしながら毎日を生活できるなら、楽しみで仕方がない。もっとも、技術的な話ではないので、プレゼンでは話せなかったことだけれども、こんなことがすごく伝えたかった。
他にも、統計の方程式やモデルの意味さえ分かれば、ニューラルネットコードを実行することで、「数学」を置き換えることができる不思議な時代が来ていることとか、色々言いたかったかも。
帰りにヒルマ@CoRe103と一緒に海辺を歩いて帰った。
結構ずっと話してた気がする。ずっと数学やコンピューターへの集中を保ちつづけてきて、これからもそうだろうヒルマからすると、ボクの数学が苦手だからコンピューターで補おうとする考え方は面白いのかもしれない。ニューラルネットのコーディングで「数学をしたことにする」っていう方法について、二人で考えていた。
今日は寒くて晩秋みたいなカンジだ。一週間前に伊豆で夏みたいな日を送れたことが信じられない。また季節が分からなくなるような日に、ニューラルネットのことでも考えたいな。
機械学習の精度をスマートコントラクトで上げる
機械学習の精度をスマートコントラクトで上げるためにはどうすれば良いか?
これは漠然とした疑問ではなく、将来我々geomerlin.comや多くのモデル作成者にとっては切実な問題になると考えられる。
「AIとブロックチェーンの組み合わせ」というとバズワードが2つ並んだだけであるように思えるが、「分散合意で機械学習モデルの性能を相互補完できるか?」について次のポイントを少し考えて頂きたい。
①人事評価や顔の美しさ、地政学リスクなど曖昧な結果を出すための機械学習モデルをどうやって信頼性の高いものにするか?
②性能の高くない機械学習モデルを組み合わせて性能の高いものにできるか?
これはディープラーニングに関する割と重要な問題だと思う。なぜならデータ不足も過学習もどのモデルにも起こるからである。データにないようなパターンにモデルは対応できないが、他のモデルにそのパターンが学習されていれば、性能が低いものであっても、相互補完ができるはずだ。
では、沢山モデルが存在するとして、単純に出力の平均をとれば相互補完ができるか?*1多くのモデルが間違えていて、少数のモデルが正しいことも多いだろうと考えられるので、そう単純な話ではなさそうだ。
選択肢A,Bのうち、多くのモデルを合意させてAを選択することを考えよう。判断に際して、甲・乙どちらを選ぶかの割合(softmax)の平均を単純に取ると、上記*1の問題が発生する。
平均ではなく加算平均すべきであることは明らかであるが、加算するべき項目が2つ出てきてしまう。
(1)甲を選んだモデルの性能・信頼度
(2)甲を選ぶモデルの集合同士の合理性
これらがシンプルに加味される分散合意評価の方法として次のものを考案した。
sugeno_integral.pdf - Google ドライブ
簡単に説明すると、
ある判断を肯定するノードの共通点が多く、否定するノードの共通点がすくなければ、その判断の合理性が多いとするシステムである。
前提:各モデルは判断対象の優劣と判断材料の重要度をソートする
(判断対象と判断材料は全モデルが共有している)
つまり上の例で言えば、判断(甲)の評価は
D*Pos - d*Neg
D=甲のポジティブ判断の人気度を信頼性(ブロックチェーン上のstake)で加重平均したもの
Pos=甲のポジティブ判断を行うモデル同士が同じ判断材料を重要とソートしているか
d=甲のネガティブ判断の人気度を信頼性(ブロックチェーン上のstake)で加重平均したもの
Neg=甲のネガティブ判断を行うモデル同士が同じ判断材料を重要とソートしているか
ファジー測度にして菅野積分を取り入れたのはMin-Max演算を行うことでリスクを減らしたかったからである。
iEx.ec RLCのホワイトペーパー 徹底解説
iEx.ecの将来性について数週間前に記事を書きました。
その際、システムの目的や将来性を中心に書いたため、技術的なポイントをおさえることを怠ったように思います。何故そのポイントが重要かといいますと、iEx.ecに投資するにあたってはslackに入ることを強く勧めますが、技術的なニュースが分からないと投資のタイミングが分からないと思います。
iExecは一言で言えば、「ブロックチェーンでクラウドコンピューティングを安くする。そのためにはオフチェーン処理とデスクトップグリッドを使う」です。
iExecの技術におけるキーワードは
「オフチェーン」、「Proof of Contribution」、「Domain-Specific Blockchain」、「デスクトップグリッド」の4つです。
では一つずつ解説を書かせてもらいます。
①オフチェーン
最近のビットコイン分裂騒動でもお馴染みの単語です。「スモールブロック」とも近い話ですが、メインブロックチェーンに全てを記録すると、パフォーマンスがありとあらゆる点で低下すると考えられるのです。だから、ビットコインの時には、ブロック以外に記録しよう=Segwitが支持されました。オフチェーンというのは、iExecの場合、Ethereumにプロセスを記録しないで、結果のみを記録することを言います。
オフチェーンで重要なのは、メインブロックチェーンに記録していない=合意のないデータ・トランザクションに関する合意をどのようなプロトコルで行うかです。それがおそらく次の項目です。
ちなみに、オフチェーンの実証実験は2016年のソルトレークシティのイベントで発表したとおり、もう済んでいるそうです。
②Proof of Contribution
ホワイトペーパーで「PoCo、これはオフチェーンでのコンセンサスを可能にする」と書いてあります。ここでひとつ?がつきますね。オフチェーンでコンセンサスとは?
これを理解するために他のプロジェクトを参照しましょう。
http://businessblockchain.org/about-aeternity
Aeternityはオフチェーンでスマートコントラクト=コンセンサス生成を行うプロジェクトです。主なオフチェーン処理にOraclizeが挙げられています。
[Oraclizeとは]
例えば明日の天気で賭けをEthereumで行う際に,明日の天気のデータはブロックチェーン内から生まれないため、外部のAPIやURLを参照し天下り的に受け入れる必要があります。Oracle=神託です。
ここで重要なことですが、信用のあるAPIの元(天下り元)で複雑な処理が出来たらどうでしょう?これは、Ethereumへの負荷・手数料を減らす上、システム全体の速度を上げてくれます。これがオフチェーン処理の意義であり、オフチェーンへの移行=オラクル側ノードの増加と言えるでしょう。
さて、オフチェーンでのオラクル側の仕事にいくら報酬をあげましょうか?この決定方法がProof of Contributionらしいです。細かい仕様はおそらく11月にオープンソースが出るまで分かりませんが、ブロックチェーンをどのくらい正しく変更させたかで報酬が決まるようです。
ここで疑問として残るのは、この報酬がクライアント側が出したEthereumスマートコントラクトに記述されているかどうかですね。個人的な予想ですが、クライアント側のスマートコントラクトに適切に報酬を記述するガイドラインがなければ、iExecは機能しないでしょう。11月のドキュメントを注意深く見守る必要があります。
③Domain-Specific Blockchain
スマートコントラクトではセキュリティ問題が発生しやすいことから考案されたものらしいです。iExec特製のバーチャルマシンとセットとなるブロックチェーンです。さっきまでオフチェーンオフチェーンってたくさん言いましたが、iExecはたぶん、Ethereumに書かない処理をこのサイドチェーンに書くと思われます。
この項目を考慮すると、オフチェーンというより、どちらかというとクロスチェーンと考えてもよいのではと思います。正直最初読んだ時にはオフチェーンって書いておきながら、サイドチェーンのこの話が出てきて???ってなりました。Whitepaperはみんなが知ってる単語書かないといけないので大変ですねっていう感想です。
④デスクトップグリッド
これは分散コンピューティングの種類ですね。ブロックチェーンで分散コンピューティングする際にもタスクの割当は非常に重要なので、下のリンクのような既存の技術は必要です。
Berkeley Open Infrastructure for Network Computing - Wikipedia
iExecにおけるタスクの割当の仕様は以下のリンクに解説されている通り
総論
Ethereumの技術的な観点を中心に考えると、iExecは
「かなり凝ったOraclizeの手法」あるいは「Oracleのスマートコントラクト化」というのが適切かもしれません。
Proof of Contirbutionは、ライトニングネットワークやライデンネットワークのようなオフチェーンのコンセンサス案が暗号学的に有効だと考えられていることから、信じてもよいものだとも思えますが、本当にちゃんと報酬を計算できるのか少し心配です。
次のようなケースを考えて下さい。
僕が数学者らしきノードSATOSHIに難しい計算100+200を頼むとします。SATOSHIは怠け者なので101とかいうテキトーな答えを返してきます。そして僕に報酬を請求するのです。iExec側はそういった悪意のあるノードを排除できるのがPoCoだと言いますが、ではどうやって排除するのでしょう?他のノードVITALIK,ASAYAMAが100+200を計算し、間違いを指摘するのでしょうか?それでは、大量の二重計算を行ってしまうので、低コスト計算を行える気がしません。おそらく計算するのは1ノードでしょう。
ホワイトペーパーには、PoSやテスト期間を設けることでこの問題を解決すると書いてあります。つまりこのシステムはある程度看板を背負っている企業か、既に信用を築いたノードが、余った計算量を使うことを指向しているのです。信用をある程度もつIT企業同士の協業システムです。ただ、これはデスクトップグリッド自体がそういう性質を持つので許容されるものですが。
このケースを考えることで得られるのは、スマートコントラクトを最初に書く側が報酬を設定しない限り、モラルハザードは簡単に起こるということです。もし、計算過程をサイドチェーン上で追えるなら話は全く別になりますが。
地政学リスクとトークンエコノミー
今日伝えたいことは「地政学リスク」の将来性についてです。
地政学リスクは金融市場で使われている、軍事による市場・商品への危険性を表す言葉ですが。この「地政学リスク」には懐疑的な方が多いということです。極限までリスク同士が複雑に絡み合うであろうトークンエコノミー社会で地政学リスクは重要なのかどうかです。
1991年、金融市場で働いていた人たちはいきなりトレードが大きくマイナスに転じたり、積み上げてきた協業の交渉が全てまっさらに戻るという悪夢を経験しました。湾岸戦争の勃発は、複雑に絡み合った現代金融市場に初めてオイルショックのトラウマを投げかけ、大パニックが起こったのです。このとき、戦争への悲観で全てを投げ売った人と、戦局を楽観し買い戻した人の間ではさらに明暗が別れました。勝敗が数日で決まるという、異例の戦局になったからです。このとき、市場に隕石のように落ちる、「地政学リスク」を読めるかどうかが、最も重要な要素の一つだという認識が金融関係者に広がったのです。
月日は経ち、2017年では地政学リスクはまるで定期イベントのようになりました。地政学的に危ないことが明らかに増えたのです。
中東や東アジアでは、大きな戦争リスクが連日ニュースでほのめかされ、ヨーロッパでは2ヶ月に一度はテロのニュースが舞い込んできます。多すぎる地政学リスクにも市場は敏感に反応し、本当に全てをひっくり返すようなリスクでなければ価格はバネのように戻ることを繰り返します。
情報のリアルタイム化と市場の精緻化が、地政学リスクを日常にしているのです。
これに対して、懐疑派が当然生まれてきます。地政学リスクは売りポジションを入れるタイミングを伺うプレイヤーの都合の良いイベントに過ぎないと。
これが本当かはGPRの表を見れば、すぐに分かります。
①本当に危険な事態は少なく、極のように偏在していること
②近年では、極の数が増えていること。
さて、これからはグローバル投資が日常になるという話を前にさせて頂きました。
グローバル投資が日常になるということは地政学リスクが日常になるということです。そして増え続けていくGPRの極の数。まるで、沖縄の人が台風を気にして天気予報を見るように、地政学リスクは市場の予報で頻繁に見られ、家計を気にする人は皆気にするようになるのです。
地政学リスク=GPR-Indexの価値はこれから確実に上がっていきます。
これからのトークンエコノミーによる想像を絶する価値の相互作用で、どこまでも日常に波及していくことでしょう。