ジオマーリン

geomerlin.com に関することを中心に。難しいことをもっと難しく書くブログ。

ERC721トークンがエンジニアに与える巨大なインパクト2 〜会社をイーサリアム化した話〜

前回はERC721トークンがイーサリアム上の「実物」の役割を果たし、あらゆる同期処理を簡略化することで、インフラシステムを構築する労力・コストを格段に下げる可能性について、抽象的に説明しました。

 

geomerlin-com.hatenablog.com

 

[ERC721 in 30秒]

f:id:geomerlin-com:20180530123600j:plain

 

では今回実際の実装ではどのようにコードすればよいのか見ていきたいと思います。

作ったものはこちらになります。 

 

会社をイーサリアム化した話<-click

 

ここにもあらかた説明はありますが、詳しく下で補足します。

 

まず設計。

 

一般的なブロックチェーン(仮想通貨)をもつ企業における、参加者の権限を4種類に分けることとします。

まず①株主②社員③ブロックチェーン参加者④その他

 

これら4つの権限について別々の資料をサーバーから返せるようにします。

つまり、株主にしか見せない資料があったり、全員に公開するデータも存在するというわけです。

これをトークンの保持してるかどうかによってサーバーの応答を変えるのです。

 

ではどう実装しましょう?

①1種類のERC721トークンに4種類の権限を表す属性を与えることにします。

これはERC721トークンをそもそも4種類にすることと本質的にちがいます。

そもそもERC721トークン規格に固執するのは、前回でも書いたとおり、トークンがウォレットと取引所で扱えるようにしておきたいからです。つまり、4種類の721トークンにしてしまうことで、取引所・Metamask等のウォレットのUI上で、構造的には同じコインが全く別のものとして表示されてしまうという不都合が将来的に生じます。

 

②さて、ここでサーバー側の都合を考えてみましょう。

あるクライアントからEthereumのアドレスあるいは公開鍵の情報をつけて、サーバーにリクエストが送られます。サーバー側からは、このクライアントが本当にそのEthereumアドレスの秘密鍵の持ち主かどうかは分かりません。

よって、権限に対応する送りたい情報を公開鍵で暗号化して送ります。すると秘密鍵の持ち主のみが暗号を解読できるので、とりあえず暗号化して返せばよいのです。

f:id:geomerlin-com:20180530123400j:plain

 

ここまで簡単であれば良かったのですが・・・。

Metamaskのようなブラウザウォレットからは公開鍵は取れませんし、秘密鍵JavaScriptで操作することを許してくれるわけもありません。つまり、暗号化も復号化もMetamaskでは難しいでしょう。そもそも僕がクライアントサイドのセキュリティを万全にする自信もありません。

 

ここでひと工夫入れます。

f:id:geomerlin-com:20180530123758j:plain

ERC721トークンの属性の一つに、持ち主のみが設定できる公開鍵を入れておくのです。これによりトークンの持ち主が好きにパスワードを変更できるようにもなります。構造は以下のように変化します。

 

f:id:geomerlin-com:20180530123909j:plain

 

これは非常に面白い結果です。なぜなら、イーサリアムのアドレス生成時の生まれた1組の公開鍵・秘密鍵のペアを用いて、多くの鍵を追加し、ほかのサービスに認証を行えるようになるのです。
当然、パスワード(公開鍵)は持ち主が好きに変えられるので、トークンの送信で権利を委譲する際に、設定した公開鍵とペアの秘密鍵を送らなくても、何の問題もありません。

 

SolidityのコードとJSクライアントによるスマートコントラクトの実装例を示しましょう。

github.com

 

ここの本質的な部分はPolicyトークンの属性部分と鍵生成Keygen部分になります。

 

 

イーサリアムのセキュリティ・プライバシー

 

今日イーサリアムを使うユーザーには隠し事は許されません。これが先ほど、僕たちがわざわざERC721トークンに公開鍵を設定し、サーバー・クライアントのウェブプログラミングを使って、データを隠した理由の半分です。(残りの半分はコストの都合です)

 

もし、イーサリアムに変数を権限のない人は絶対に見れないシステムを作れたとしたら、僕たちはデーターやデータへのリンクをそこに入れておいて、正しい権限を持った人だけがデータを引き出せる関数をつけるだけで済んだのですが・・・。

 

現在の仕様だと、本質的にはイーサリアムのマイナーが変数の中の値が正しいかを検証してブロックを作る時点で、どんか粋な隠し方をしても、マイナーにはバレてしまうものです。ちなみにイーサリアムのデータは次のように全て読むことができます。

medium.com

 

結局、プライバシーに関わる部分はチェーン外での暗号処理を行う方針が筋のよいインフラ構築になりそうです。

 

今回我々が提案した方法はAWSとEthereumのHALF&ハーフです。 既存のクラウドとのすり合わせをすることが思わぬほど大きい利益がある印象でした。

 

これらの方法は

Create Account | Slack

で議論しています。

 

僕たちの主な着眼点は「既存クラウドのレガシーコードをいかに有効活用して全員の手間を減らすか」という部分にあります。トークンエコノミーの到来には、ブロックチェーンが嫌いな人にも使ってもらえる形が存在する必要があると考えています。

雑感

 

というのが技術的な雑感です。

 

そして見えてきたのは逆にクラウドの「聖域」ですね。

S3,Dynamoといったデータベース、そしてEC2とLambdaといったコンピューティング、Route53などのDNS・ネームサーバー関係はまだまだチェーン外のみで動くケースが多く、StorjIexecなどのプロジェクトがクラウドの分散化を攻略しようとしていますが、少なくとも日本の保守的なクラウドインフラ側はしばらくはドキュメントが豊富で動作が安定、補償もばっちりなAWS、Azureを使うでしょう。

 

最初にクラウドでEthereum移行できるのはどの分野なのか、どうやって既存の仕様を壊さずに導入するかを議論していきたいと考えています。