ERC721トークンがエンジニアに与える巨大なインパクト１
お久しぶりです。極度消耗https://twitter.com/leo_hioです。
前まではイーサリアムのインパクトを新しいエコノミー的な側面で捉えて色々考えていましたが、最近エンジニアへのインパクトはどれほど強いか考えてみました。
結論から言えば、同期を扱うシステム全般に関して大きな仕様の変化を起こしうるのではないかということです。
エンジニアというのは、基本的に周りから「このライブラリ使うといいよ♥」とか「このプラットフォームをみんな使ってるから君も使ってね☆」みたいな話に振り回されながら生きていると思います。
つまり、プラットフォームの仕様がこれから大きく変われば、エンジニアにとって巨大なインパクトがあるのです。
ERC20トークンはイーサリアムと仮想通貨取引所の都合で作られた規格ですが、知っての通り、Bancor、AugerやGolemを始め、大量の有名仮想通貨をイーサリアム上に展開することを可能にした、経済インパクトの大きなシステムでした。
ここにきて、半年ほど前から新しいシステムが流行り始めます。
ERC７２１トークン規格です。
これは代替不可能なトークンと定義され、最小単位は１（小数点は許されない）。
一つ一つが区別できて、人に渡したら、自分の分はなくなるトークン。
つまり、ヌイグルミや絵から人間まで、分割不可能で個性のあるものへの権利を表現できるトークンと言まっしゃろ。ある意味イーサリアム上の”実物”と考えても良いです。
ERC20は通貨、ERC721は権利書と考えると分かりやすいです。
当然、このERC721は不動産取引などに明らか使えそうなので、色々な人が注目していますが、実はさらに近いところにインパクトがありそうです。
７２１トークンはありとあらゆる物への権限を管理するシステムを構築するコスト・労力を大幅に下げることができる可能性があります。
さらに言えば、同期を必要とする分散システム全般の構築のコストに関しても同様の効果があるかもしれません。
例としては、
①ソフトウェアのシリアルナンバー、AWSのPolicy、SNSのアカウント、ファイルの実行権限や特定メモリ領域へのアクセスといったシステムへのアクセス権限関係
②クラウドサービスと端末の同期問題（iTunesなど）、Wifiのハブ選出問題(FreeWifiに勝手につかまるアレ)、DNSサーバーの更新のラグ問題、航空管制の分散処理エラー問題等
が挙げられます。
どちらもスコープと同期の問題であり、
「変数が知らないうちに変わっててバグが起きた」
「あるノードからのリクエストの処理中に他のノードにも対応するとバグが生まれた」
「ネット上ではどちらが”上”なのか分からないので競合した」
といったことが原因となるものです。
このスコープと同期を解決しうるのがERC７２１だと考えています。なぜなら
①Ethereumに接続するノードの間では、コントラクトに書かれた変数（７２１トークン）は全ノードに共有され、事実上の最高スコープである。
②代替不可能であり、同期に必要な代表ノードは保持者と決まっている。
ここが多少説明が必要そうですので下記「※同期の難しさ」を参照下さい。
なぜERC721限定？？？
ここで正統な疑問が生まれます。
②を満たすようなSolidityコードを書けばよい話では？というものです。
ここで面白いのは、７２１トークンは共通規格でウォレット間で送信可能・売買可能というものです。
つまり、ERC７２１であれば、取引所等で売買が広く行われる可能性があるわけで、それはソフトのシリアルナンバーや各種権限の売買に直結します。つまりはソフトウェアやAPI,クラウドをシェアリング的に使う経済を意味します。
ちなみにERC721トークンの取引所は仮想通貨交換事業者の資格が要らない可能性がありますので、もしかしたら第２のコインチェックが今どこかで生まれているのかもしれません。
同期の難しさ
なぜ同期は難しいのか。僕は自分の環境でプログラムを動かす時は支配者は僕であり、プログラムの実行順序が僕の時間での実行順序となります。
しかし、他のノードが別の環境でプログラムを動かして、僕のプログラムの中の変数を変える時、相手の実行時間に依存し、時間軸は２つとなります。この数が多くなる時、僕は大量の相手の時間軸（都合）を考えて適切な処理を施す、サーバー（奉仕者）になります。
列に並ばない客がレストランに同時に沢山来て、何人かは「相席でもいいから座らせろ！」何人かは「相席は絶対やだ」と言い、空き席が複雑な配置をしている時、受付だったらどうします？
この問題は管理者が複数人必要な場合、管理者を決めることから始まります。レストランの問題で言えば、「だれがあの客たちの対応する？」といった具合です。
ネットワークや並列プログラムの実行の場合、リーダー選出という分散合意を行うことが多いです。
①権限の階層が決まっていないことによる優先順位が決まっていない状態
②どのデータをどの時に見るべきかというスコープが明確でない状態
は同期の問題を悪化させます。
また、多くの学習者がプログラミングでつまづく３つのステップ(ループ→再帰→並列)のうち、並列をやらずにプログラマーになるので、同期処理に難しさを感じる頻度が多いのは初見であることも影響すると考えられます。
このように、同期とスコープが大幅に簡略化される可能性が生まれたわけですが、どんな影響が生まれるか下で見ていきましょう。
脱、奉仕的サーバー！！
たまに乱暴なんだけど有能な管理者をみることがあります。
「ここに書いといて！」とか「登録しといて！」とかが口癖のイメージですが、本人も含め全員のやることが少なくて全員満足そうな結果に終わるカンジです。
彼/彼女らの真似をプログラマーはできないでしょうか？特徴を考えてみましょう。
①声がでかい
管理者の声が通らないことは問題です。管理者の発言のほうが全体にとっての情報量がクライアント・クレーマーのそれより大きいためでしょう。
②差別する
優先順位が決まっていることが重要であれば、それによって対応が変わることが保証されることも重要でしょう。
③自己責任を使う
参加者がまともな行動をするインセンティブが必要です。自己責任を果たせない時のペナルティは排除ではなく「②差別する」で優先順位を落とされることでしょう。
僕は基本的にこれらの要件を満たす管理者を代替するシステムを作れる自信がありませんでした。その上、AWSのIAMやGithubのように上手くできているシステムもほとんど知りません。
理由は簡単で、タダでさえ難しい同期処理を行いながら、①②③の要件を満たすのは至難の技なんではないでしょうか？同期処理にバグがある可能性があるなら偉そうなことするの怖いですし^^;
しかし、①②③だけでいいというなら話は別です。
これがこれからのERC７２１で構築される新しいインフラであるという仮説です。
次はコードを使ってこの仮説をトレースしていきます（続く）
