ビットマップによる注文情報保持

前回の続きです。Gasを節約しつつ、オーダーブックをオンチェーンで保持する方法の解決編です。

アセンブラやC言語でプログラムを書いていた（る）人は、ビット操作というものに馴染みがあると思います。ブロックチェーンで、Gasを節約しながらできるだけ大きめのデータを扱おうとするとき、ビットマップで何とかできないかと考えると、けっこう解決できることがあります。大きめのデータを圧縮した形にしたり、複数回の操作を1回にまとめられたりします。

このやり方は、オーダーブックで扱う価格に制限をかけることで実現できます。

• 価格の範囲を 0.000001 ～ 1000000（10⁶～10^-6）に制限する
• 有効数字3桁とする

株のことはよく知らないんですが、こういう制限をしても問題にはならないようです。

この制限によって、とりえる価格が 10800 種類に制限されます。これを、10800ビットのビットマップで表現します。”1″のビットはその価格で注文があり、”0″のビットは注文がない価格です。

とりえる価格を制限したオーダーブックを、ビットマップで表現した図（出典：https://ubitok.io/2017-08-24-maintain-order-book-blockchain-bitmap/）

最小の価格が一番左の0.000000100、最大の価格が一番右の999000、中間付近に1.23があるということですね。有効数字3桁に制限されているので、997000、998000、999000という並びになるんだと思います。有効数字とか懐かしい・・・。最小価格も同じでしょう。

Solidityで実装するなら、uint256の43要素の配列を使えばよいわけです（10800 / 256 = 42.1875）

ヤック・デカルチャー・・・（最近マクロスFにハマっています）

ビットマップを使うことまでは、いつも最初に思い浮かびはしますが、株の価格をこんな形で保持する発想は、Web屋の脳のままでは難しいでしょう。作ろうとしているシステムで受け入れられる制限を考えて、ビットマップに落とし込む方法を考えるのは、なんだか楽しそうです。（雑誌のアセンブラコードを読んで悦に入っていただけの）昔を思い出します（笑）。

ビットマップオーダーブックから注文を検索するSolidityコードについては、次の上のURL下部にアイディア部分だけ示したものが、下のURLに全体が掲載されています。

https://ubitok.io/2017-08-24-maintain-order-book-blockchain-bitmap/

https://github.com/bonnag/ubitok-contracts/blob/master/contracts/BookERC20EthV1.sol

富豪的プログラミングがどうこうと、2000年代にいわれてました。ブロックチェーンプログラミングでは、けっこうチマチマと節約しながらプログラムするシーンが戻ってきたようです。

90年代以前のプログラミングを思い出させるDApps開発

パブリックチェーンに放流するDAppを書いていますと、ちょっとしたことに割りと多目のGasを必要とすることがわかり、驚いた次第です。これまで、Erisやなんかのプライベートチェーン向けの開発が中心だったので、実感として分かりませんでした。ちょっと大きめの2次元配列を作るだけで何百円（Gas PriceをGas Stdと同じとして）とかかり、PHPとRDBで適当に組んでいた間、データ量や計算量を軽視する悪癖を身に付けたような気がします（笑）

パブリックチェーン向けのDAppの開発は、計算量やデータ量を割りと細かく気にしながら書くという意味で、C言語全盛の90年代に活躍していたプログラマーは、懐かしい気持ちになるかもしれませんね。あるいはゲームを開発しているような方は、現在進行形でこの手の問題と格闘されているかも。

Web系しかやったことがない人は馴染みが薄い、純粋アルゴリズム系やデータ構造系の知識、ビット演算の知識などがあると、節約がしやすくなります。DBが気づかないところでいろいろやってくれていたことに、気づくかもしれません。

オンチェーンでオーダーブックマッチングを行う解説記事

オーダーブックをオンチェーンで保存・実行する方法の記事

ブロックチェーンへのうまいデータ格納方法を調べていて見つけたのが、この記事です。株などのオーダーブックを、Ethereumブロックチェーン上にすべて保持してマッチングを処理する方法について、解説しています。データの更新があるトランザクションの場合、Gasを必要としますので、その量をいかに少なく済ませる実装にするかというものです。この記事から、要点を解説します。

オーダーブックですので、買い注文と売り注文をマッチングさせることになります。Web+DB環境など非分散システム上で普通に組むと、データを次のように価格から注文数へのマップとして持たせることになります。

そして、プログラム言語がJavaならTreeMap（よく知らないですけど）、PHPなら配列を使って実装することになります（というかDBに入れますけどね、普通）。

このマッピングに使うデータ構造は、一般的にTree（木）、とりわけ順序木というものになります。木・・・どうなんすかね、こういう名前付けの世界。自然にあるものをこういう抽象的な世界に持ってきて使う文化は、私は好きですけど。

オーダーブックのデータをTreeに格納した状態（出典：https://ubitok.io/2017-08-24-maintain-order-book-blockchain-bitmap/）

各ノードの数字が価格です。マッチする売り注文を探すのは、木からある価格を持つノードを探す処理です。これは順序木といって、あるノードの左はそのノードの数より小さい数を持つノードだけ、右は逆に大きい数を持つノードだけを、子ノードとして持つ、そういう木構造です。

で、引用もとの記事のいうように、木構造がソリューションとして理想的なのは、平均的なケースでしかないと。オーダーブックの仕様に注文の削除があるので、そのとき最悪の場合木全体を書き換えないといけなくなってしまいます（木というのは、そういうデータ構造です。興味がある方は、データ構造の解説書などを見てみてください）。大量のWriteが発生するので、Gasも高額になってしまいます。

じゃあ、他にいい方法はないか？次に例として出ているのが、連結リストです。

オーダーブックのデータを連結リストに格納した状態（出典：https://ubitok.io/2017-08-24-maintain-order-book-blockchain-bitmap/）

連結リストなら、更新のとき書き換える箇所は一定です（挿入・削除する要素と、その前後の繋ぎ直しだけ）。

しかし、やっぱり連結リストにも問題があります。注文をたくさん出すユーザーがいると、その人が原因で、ほかのユーザーがGasを多く支払わないといけない状態になってしまうのです。これは、連結リストは走査するとき、リストの一方の端から順にたどるしかないことが理由です。上の図で ”1.23 ” の価格のところへ行くには、 “1.20” から2つ移動する必要があります。その分のコストが請求されるのです。

こういったGas消費量節約の問題を、ビットマップを用いてうまく解決する方法が紹介されているので、次回解説します。

Ethereum界隈で一時期話題になった、CryptoKitties。日本人特にネコ好きの人は、カワイクないと思う人が多いんじゃないでしょうか。まあ、すぐに思いつくのがポケモンとかDQのモンスターですね。昔からあちらさんのゲーム内キャラは、カワイイことを追求してないですんで。

かわいいCryptoKitties 嫌いじゃないです。キモカワ？

暗号じゃないPig

CryptoKittiesでは、2匹を交配させることで子供が生まれます（というか生成されるというべきか）。子猫は両親の特徴を引き継いだ外見になるのですが、その際どんなアルゴリズムが使われているのでしょうか。

CryptoKittiesのContractは

https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#code

ここで見ることができます。

次世代のネコの外見を決定する「遺伝アルゴリズム」は、どこでしょうか？

ここで、GeneScience Contractとしてネコを交配するルールのインターフェースを定義しています。

そして、実際の実装Contractの呼び出しポイントがこちら。”geneScience”が、実装Contractですね。実装Contractのアドレスは、CEOだけが指定できるようになっています。

現状、こちらがそのアドレスのようです（昨年12月の情報によります）。

https://etherscan.io/address/0xf97e0A5b616dfFC913e72455Fde9eA8bBe946a2B

さて、ここからはバイトコードしか見られないんですよね。すると、外見を決定しているアルゴリズムを知るには、リバースエンジニアリングするしかない。辛い。無理。しかし、海外勢にはそれをやった猛者が何人もいます。

The CryptoKitties Genome Project

CryptoKitties GeneScience algorithm

CryptoKitties mixGenes Function

いやあ、凄いですね。暇・・・いや、旺盛な探究心に頭が下がります。

ここに深入りする気はないんですが、外見を現すパーツがいくつか設定してあるようですね（body, pattern type, eye color, eye type, primary color, pattern color, secondary color, fancy type, mouth）それを何がしかの計算にかけて外見を作っているようです。突然変異というのも仕掛けてあるようです。

はたしてKittiesをカワイクするContractは作れるか？

持論ですが、アルゴリズムで「カワイイ・面白い」は出来ないと考えています。AIだろうとDeep Learningだろうと。どう凝ったものを作っても、コピペのお化けのようなものに近い感覚です。

AIが絵を描いた・作曲したという話題が一時期盛り上がりました。

Google AIの描いた絵

かなりマシなのを持ってきましたが、それでもうーん・・・惜しいところまで来てるんですが・・・なんとなく、CryptoKittiesのキモさと通ずるものがあります。Kittiesが「キモカワ」なのは、最初にネコのような外見ありきだからなんじゃないかと。

印象 日の出

たとえば、印象派のような絵をAIは生成できるでしょうか？印象派の絵を食わせてそれっぽいのを出力するのではなく、印象派が出たときと同じ気持ちを人に抱かせる新ジャンルの絵が生成できるか、疑問なわけですよ。

そして不思議なのがAIによる作曲です。

アレアレ？なんかいいよね？だけどこれも種は簡単で、シャレた動画と肉声が付いているぶんいい曲に聴こえてます。絵も何か人間が付け加えればマシになるかも。

音楽理論を少しかじったことがありますが、アルゴリズムでなんとなくよさげな感じの曲ができるのは、わかるんですよ。ただ、意外性のある曲はできません。いくつかAI作曲の曲を聴きましたが、だいたいこうなるよねというものばかり。BGMや環境音楽の大量生産には、AIはとても向いていそうです。環境音楽といえば、昔からシンセが活躍していますし親和性が高いのかと。

ITは人間のカワイイ生成を補助できる

CryptoKittiesを単純にカワイクするアルゴリズムはないと思うのです。私は、ITや人工知能の役割を人間の主観や直感を（正しく）強化するものと考えています。

かなり好みのKitties

Kittiesが最初にネコの形ありきにしたことで、単なるキモでなくキモカワになる。そして、不完全ながらアルゴリズムで増殖し、あまつさえ売買までされている。これを推し進めたい。ネットに大量にいる美少女絵描きを集めて、ブロックチェーン上にKAWAII圏が林立している、そんな状況を妄想しています。まあ、ポケモンでも別にいいけど。

Vitalik Buterinによるブロックチェーンのフォークについてのブログ解説、その2回目。毎回謎のタイトルが付いてますが気にしないでください。今回は、2つ目のHRタグまでの内容です。

if a change is non-contentious, then it can generally be done safely no matter what the format of the fork is.

前のパートでハードフォークが批判される理由が挙げられました。Vitalik先生はそれに異を唱えます。議論が巻き起こらないような変更内容なら、ハードフォークだろうとソフトフォークだろうと安全に行われるといってます。ハードフォークが常態化した現状を見れば、妥当とされるハードフォークというものの存在が分かると思います。

ハードフォークが批判されるとき、強制的だといわれることがある。だけど、ソフトでもハードでも、変更内容に100%のユーザーが同意しないなら、「それを望まないユーザーがいる変更」をすることになるのです。ネットワークやブロックチェーンのネットワーク効果の世界では、自分たちの好みや意見よりもマジョリティの参加しているネットワークに参加せざるを得なくなるわけです。ハードフォークかソフトフォークかで強制かどうかが決まるわけではないのです。あくまで

仕様変更の内容

次第ということになります。

However, there is an essential difference between hard forks and soft forks: hard forks are opt-in, whereas soft forks allow users no “opting” at all. In order for a user to join a hard forked chain, they must personally install the software package that implements the fork rules, and the set of users that disagrees with a rule change even more strongly than they value network effects can theoretically simply stay on the old chain – and, practically speaking, such an event has already happened.

ハードフォークとソフトフォークの違いは強制か非強制かではなく、「オプトイン型」か「選択の余地なし」かです。ハードフォークしたチェーンに同意するユーザーは、新しいソフトウェアをインストールする必要があります。ネットワーク効果よりも自分の意見や好みを重視したいユーザーは、古いチェーンにい続ければいいだけです。後者はEthereum Clasicとして実際に存在します。

 In the case of soft forks, however, if the fork succeeds the unforked chain does not exist. Hence, soft forks clearly institutionally favor coercion over secession, whereas hard forks have the opposite bias.

ソフトフォークした場合、分岐したチェーンなどないので、問答無用で新プロトコルのチェーン上にい続けなければなりません。もしくは完全に参加を止めるか。これこそが、字義通りの強制に他ならないわけです。ハードフォークには脱退して好きな道を歩く自由があります。最近流行った「好きなことをして稼ぐ」みたいなことを実現するフォークだということです。

ハードフォークが強制だといわれるのは、ソフトウェアのインストールしなおしが必須だからだと、Vitalikはいってます。ソフトフォークなら、そのまま同じツールを使い続けられますからね。だけど、ツールの使い方に目が行きがちな鉄器ーじゃなかったｗテッキーなあなた。大切なのはツールの使い方じゃない。受け入れたくないことを強制されるかどうかなのです。

これを書いていて、宇多田ヒカルのリスクが脳内に流れてきました。

懐かしいですね～。15年以上も昔ですか。

変えられないものを受け入れる力 そして受け入れられないものを変える力をちょうだいよ。

ニーバーの祈りから採ったといわれるこのフレーズ。ハードフォークこそ、この力を与えたもうフォークなのです。

日本人の判官びいきの源流、義経と弁慶をソフトフォークが殺す・・・。

妙な書き出しで始まりましたが、Ethereumのフォークについての話です。

最近はハードフォークが当たり前で、以前の大騒ぎは何だったのかという感じです。つい1年前までは、ハードフォークさせるなんて非国民、いや非ブロックチェーン民のような雰囲気が、日本国内ではありました。何故なら、非中央集権とはなんだったのか的な思想的な理由。

日本国内というのがミソで、海外の専門家はそう考える人ばかりではなさそうなんですよ。Ethereum開発者のVitalik Buterinも、ハードフォーク支持者です。今年の3月に、次のようなブログエントリを上げています。

この中でVitalikは、ソフトフォークが正義という考え方が誤解に基づいていると説いています。上の段落から順に解説してみます。今回は、最初の<hr>タグまで。

まず、ソフトフォークとハードフォークが端的にどういうことをするのか、分かりやすい言葉で説明があります。

ソフトフォーク

valid とみなす transaction を減らすやり方。アップグレードなしでも、チェーン上にい続けることができる

ハードフォーク

フォーク 前まで invalid だった トランザクション も valid とするかもしれないので、ユーザーは フォークしたチェーンの上にいたければ、クライアントアップグレードが必要。

ということです。とても分かりやすいと思います。そして、ハードフォークにも2種類あるということです。

Strictly Expanded Hard Fork

validとみなされるトランザクションを拡張するハードフォーク。フォーク前のルールは、フォーク後のルールのソフトフォークにあたる

Bilateral Hard Fork

互換性のない２つのルールに分岐するハードフォーク

THE DAO事件の例でいえば、次のようになるかと思います。

ソフトフォーク

アタッカーのアドレス対象のトランザクションが、validではなくなる。現実には採用されなかった

ハードフォーク

実際にBilateral Hard Forkとして採用された。ETH/ETCとして2つのルールに分裂した

次に、ハードフォーク・ソフトフォークそれぞれの利点といわれるものが列挙されます。

ハードフォーク

• 開発者が互換性の憂いなく存分に振るえる

ソフトフォーク

• ユーザーに優しい。だってアップグレードが必要ないから
• チェーンの分裂を起こしにくいから優れてる
• miner と validator の同意さえ得れば済む。ハードフォークはユーザーのオプトインが必要。

と、ソフトフォークの利点ばかりが取り上げられがちなのに加えて、ハードフォーク支持者は”乗っ取りを企てている”と批判されたりすると、Vitalikはいいます。あるいは、チェーンの分岐を招くから悪いことだといわれると。確かにビットコインゴールドなど、乗っ取りしたかったかのようなハードフォークは存在します。しかし、それは絶対に防ぐべきことなのでしょうか？リアルワールドでは、善悪は白黒簡単にスイッチのように決められているでしょうか？

なんだか悪いようなことをする人たちにも人権はあるんではないだろうか？その「悪」の行為も、もしかして思わぬ副産物を生んだりするんではないだろうかという視点はいりませんか。政治とか社会って、そんなに単純に正義が決まるもんではない。そもそも、OSSにも息づくハッカー精神てのは、そういう態度のはずだったのでは？？？善とか悪の背後にある仕組みをハックして明らかにし、改造してしまえ！って態度だったはず。

私は、ブロックチェーンやスマートコントラクトでカッチリした契約社会になるのが、嫌なんですよ。そういう社会になると・・・

弁慶が勧進帳を偽造して義経を逃がせない、血も涙も物語性もない社会ということになるから

てめえらの血は何色だ！判官びいきの精神はどこへ行った！ｗ

続く。

前回のエントリで、Ethereumのブロックサイズを決めるBlock Gas Limit（BGL）はマイナーの投票で決められると書きました。しかし、投票結果がどう実際のブロックに反映されるのかがわからなかった。

そうしたら、偶然ピンポイントな回答が書いてあるエントリが見つかりました（感謝）

どうやら、「最新のブロックの採掘に成功したマイナーの設定が、次のブロックのBGLとして採用される」という仕様らしいです。そして、1回で動かせるのは前回のBGLの1/1024だけらしいです。増加に投票することも減少に投票することもできるようです。

ここで、マイニングプールの投票行動を知ることができます。

https://www.etherchain.org/tools/gasLimitVoting

表中の項目は推測ですが、左から

• Vote Up リミット増加に投票した回数
• Vote Down 同じく現象への投票回数
• Largest Upvote 増加へ投票して最大どれだけのガスリミットになったか。
• Lowest Downvote 同じく減少へ投票して最小どれだけのガスリミットになったか

と思われます。

現状、BGLは800万程度で推移しているようです。

アタックがあるとマイナーにBGLを変化させる要請があったりするようです。

ビットコインはスケーラビリティの問題に行き当たっており、その解決のためブロックサイズをどうするかという論争が延々と続きました。そして、方針の違いからハードフォークを起こしました。いまではハードフォークは、スケーラビリティと無関係の動機からも起る様になっています。

ビットコインとその分派のブロックサイズ

下記のようになっています。

• ビットコインアンリミテッド 可変（市場にゆだねる）
• ビットコインコアのSegWit導入 (ブロックウェイトが4Mまで)
• ビットコインクラシック 2M
• ビットコインキャッシュ 8M

最近ハードフォークしたゴールドなどについては調べてないのですが、ブロックサイズとスケーラビリティというのは、厄介な問題であり続けてきたわけです。

じゃあ、Ethereumはどうなのか？Contractに欠陥があって大金が盗まれたりしていますし(これはスケーラビリティと無関係)、最近はICOがあると混雑することもあるようです。しかし、ビットコインのようには騒ぎになっていないように見えます。

ここを見ると、驚いたことに暗号通貨のトランザクションの過半数をEthreumのトランザクションが占めていることになってます。ちょっと驚きました。Ethereumがどうして多くのトランザクションをさばけているのか？スケーラビリティでビットコインのような論争に陥っていないのはどうしてなのか？とても興味の沸くところです。

やはりブロックサイズがスケーラビリティにとって影響の大きなところなので、Ethereumのブロックサイズがどうなっているか調べました。

Block Gas Limit

結論からいうと、Ethereum にはBlock Gas Limit というものが存在します。Gas Limitには2種類あって、それは Transaction Gas Limit と Block Size Gas Limit です。

Transaction Gas Limit

ユーザーがトランザクションをEthereumに送るときに設定する、消費されるGasの制限値。無限にGasが消費されて無一文になるのを防ぐためのものです。

Block Gas Limit

ひとつのブロックに含めることができるGasの合計量。マイナーによる設定値

ひとつのブロックに含むことが出来るトランザクションは、Transaction Gas Limitの合計がBlock Gas Limit以下に制限されるわけです。

A～Eの５つのトランザクションがあって、それぞれのTransaction Gas Limit が10、20、30、40、50であるとします。そのとき、Block Gas Limit = 100であるなら、ブロックに入れられるトランザクションは、

A(10)+B(20)+C(30)+D(40)、B(20)+C(30)+E(50)、D(40)+E(50)

などになります。

そして、Block Gas Limitはマイナーがクライアントで指定します。Gethの場合、–targetgaslimitオプションになります。

マイナーが上記オプションで指定することがBlock Gas Limitへの投票となるらしい・・・のですが、単なる多数決なのか何なのか、調べないとよくわかりません。

Bitcoin Unlimited どう違うのか？

この仕組みは、Bitcoin Ultimateのエマージェントコンセンサスと似ています。エマージェントコンセンサスも、マイナーがブロックサイズに影響のあるいくつかのパラメーターを指定して、あとは市場でブロックサイズが調節されます。

どちらにしても、固定されないブロックサイズを持ったチェーンがどのように機能しているのか、興味深いです。Ethereumが、攻撃されながらもトランザクションを大量に処理できているのはなぜか？これは実は、技術にとどまらない本質が潜んでいそうです。

この後も掘り下げていきます。

ビットコインが分裂するとかしないとかで、最初にやりだしたのは誰なのかしらという感じになってますが、ここへ来てナードの産物が必ず通る道に差し掛かってるようです。

Nerd vs. Geek

仕事を手伝っているEdgarさんが、3月にこんなことを書いてます。

Why Ethereum is great for payments

内容は、「支払いにおいてEthereumがBitcoinより優れた手段である」という主張です。理由として、以下を挙げています。

UTXOの直感的な分かりにくさ

Bitcoinの場合、ユーザーが手数料の金額を見て「あれ？」と感じる場面があるということですね。

斎藤から吉田に100bitcoin送りたいとき、Walletは斎藤が持っているbitcoin（正確には未使用のトランザクション・UTXO）をかき集めて100bitcoin以上にしてから、吉田に送ります。集めた100bitcoinを超えた金額は、自分自身に向けたトランザクションになります。

例えば、

UTXO （10+30+30+50) = 120

斎藤 → (100) 吉田

斎藤 → (20) 斎藤

このチマチマしたトランザクションを発生させる仕様のため、トランザクションの構成によっては（テッキーでない）ユーザーの直感と実際の手数料の金額が乖離する場合があるということです。送金額と手数料が、リニアの関係からかけ離れるんですね。

Ethereumのトランザクションは、誰が誰にX ETH送るという直感的な情報を持っています。

セキュリティ確保

Walletの秘密鍵の管理などセキュリティ確保の面でも、Ethereumは有利です。

Bitcoinのスクリプト言語は制限があり、複雑なことをするに向いていません。一方、Ethereumはチューリング完全なプログラム言語を備え、複雑なセキュリティ仕様を実現することが容易です。複数の秘密鍵を別々の場所に保管しても管理しやすくしたり、Walletに支払いを止めさせる権限より初期化する権限を上位にしたりといったルールを比較的容易に記述できます。

Bitcoinでやると、こう（http://fc16.ifca.ai/bitcoin/papers/MES16.pdf）なります。これを理解して実装する暇のあるやつはいないということです。

スケーラビリティ

Bitocoinが分裂の危機を迎えたり乗り越えそうになったりしていますが、その主な理由はスケーラビリティを確保するための方針がまとまらないことにあります。Ethereumは、この点でもよいポジションにあります。

Edgar先生曰く

An established governance procedure for capacity increases, not an endless political food-fight.

Ethereumには、確立したキャパシティ増加プロセスのためのガバナンスがある。終わらない政治のフードファイトの代わりに、です。

スケーラビリティ確保に役立っているEthereumのデザインについては、別の記事で書こうと思います。

結局これら3点すべて、「技術者や学者特有の考え方の癖」に原因が求められます。Edgar先生曰く、ビットコインコアの開発メンバーには、現在は数学者が多く参加しているそうです。すると、こういった人種は潔癖症なことが多く、仕様などについて延々と議論という名のバトルが展開されたりするわけです。延々とです。

Ethereumの中心人物のVitalikは、20歳前後ととても若いです。そのせいか、古参の原理主義者の限界をやすやすと超えた発想をできるのかもしれません。Vitalikを中心としたEthereumコミュニティは、THE DAOの事件でのソフトフォークとハードフォークの件、あの大事件をむしろシステムを見る視点を本質的に一つ上のレベルに導いてしまいました（少なくとも私は導かれた）。何しろ、ハードフォークして当たり前という世界が開けそうなことに、ここ20年で一番未来を感じました、私は。

日本のオジサンたちにはこれがわからんのですよ。 例の斉藤賢爾さんも、ビットコインのほうがEthereumよりマシなどといってるのですから。ソフトフォークのほうがハードフォークよりマシともいっておられる。パラダイムが古いんです。

日本のテック野郎にEdgar先生のエントリから、次の言葉を送ります。

Busting out of the nerd ghetto(オタクのスラム街から抜け出せ)

もうね、セガサターンがプレステに負けたときから私はこういってますよ。技術や製品の普及の秘訣は、オタクとパンピーの構成員における割合が適正であることです。Bitcoinは、やたらと知名度が上がった状態で大混乱しているわけで、とてもよくない状態だと思います。

雑誌・現代思想でビットコインとブロックチェーン特集があったので、急遽購入。野口悠紀雄氏や慶応SFCの斉藤賢爾氏など有名どころが寄稿してます。

私は、栃木県に住んでいる英国人のEdmund Edgarさんの仕事をときどき手伝っているのですが、彼はブロックチェーンやビットコインに詳しいんです。ちなみに彼は日本語ペラペラです(笑) そこで色々と話を聞き出したり、その手の英語サイトの議論やブログを読んでいます。そして、少なくとも中年以上の日本人ITエンジニアや研究者は、1周遅れのパラダイムにしがみついている人がほとんどじゃないかという思いが強くなってます。

ナイーブというか潔癖症というか、とにかくカチッと固まった世界しか相手にしたくないようなのですよね。客観信仰とでもいいましょうか。

昨年夏に、EthereumのTHE DAOコントラクトのバグを突かれることで、不正にETHが数十億円分奪取される事件がありました。その対応としてソフトフォークとハードフォークという2つの対応が考えられる中で、現実にはハードフォークで対応されました。ソフトフォークは、以前のブロックチェーンの仕様と互換性を保ちつつ、盗んだ奴の口座を凍結する対応。ハードフォークは互換性なく完全な新しいブロックチェーンへの移行です。

斉藤賢爾氏のような人からすると、特にハードフォークはありえないような話らしいんですよね。彼によると、ビットコインも含めブロックチェーンの設計から間違っているそうなんですよ。そのことについて「現代思想」の女性経済学者との対談で語るところによると

「あなたたちは、自分たちのやっていることをわかっていますよね？」

という気分だそうですが。いや、彼らはどう見てもわかっていますよ？

斉藤さんやある割合の日本人エンジニアの感覚は、

「ブロックチェーンがフォークすることは歴史が分岐することとなる、よって好ましくない」

だと思います。しかし、Ethereumの開発中心人物で若干20歳のVitalik中心に展開されるフォークについての議論を追うと、フォークそれ自体がとんでもない間違いとは思っておらず、問題にもされていないように見える。THE DAO事件が起きてしまったから後付けでというわけでもないはずです。私の英語がたいしたことないとはいえ、この印象は間違っていないと思います。

Ethereumの公式ブログのVitalikのポストです。Edgarさんに教えてもらいました。

The Subjectivity / Exploitability Tradeoff

私はこの”Subjectivocracy”という単語を見て衝撃を受けました。主観主義とでも訳すべきでしょうか。客観主義がダメであるというのは昔っからの私の持論ですが、西洋哲学の本場の人たち自体客観信仰している人ばかりではないんですね。

• Subjectivity  → 主観
• Objectivity → 客観

ですが、このエントリを読むと、日本人エンジニアや研究者が神聖視していると思われる客観性は、同時にCURSE（呪い）でもあるとVitalikはいっています。

Objectivity has often been hailed as one of the primary features of Bitcoin, and indeed it has many benefits. However, at the same time it is also a curse.

客観性はビットコインの主な特徴として歓迎されているし、事実役に立つことも多い。しかし、同時に呪いでもあるんだ。（拙訳）

エントリはけっこう長いのですが、是非読んでみて欲しいです。システムがSubjective（主観的）であるとき、Not exploitable(攻撃しにくい)がマネージコストがかかる。Objective（客観的）であるとき、オートでシステムが維持できるが攻撃しやすい。そのトレードオフだということです。オートでAIっぽく世界が進行する・・・60年代70年代生まれのパソコン少年が喜びそうな世界ですねｗｗｗｗ だけど、本場のあちらの人たちはもっと大人のようです。

ハードフォークすることを歴史の分岐だから好ましくないとするのではなく、それぞれが自分の好む（主観的な）世界を選択することができるという考え方。こちらのほうが断然よいと思いませんか？

Edmund Edgarさんは、Subjectivocracyを実装したRealyty Tokenというプロジェクトを構想しています。これがまた刺激的なんですが、今一生懸命ホワイトペーパー読んでます(笑)

EthereumとBitcoinそれぞれについて、トランザクションがどういう構造をしているか調べてみたいと思います。

Ethereum

• nonce
• メッセージの受領人
• 送信者を特定する署名
• 送受信されるEtherの量
• オプショナルなデータフィールド。Contractに送られるmessageを格納できる。
• STARTGAS値
• GASPRICE値

Ethereumのトランザクションは、「誰から誰にどれだけのEtherを送る」という情報を単純に持っているようです。nonceは、マイニングのときに求めるあれなのかどうかは、まだ不明です。

Bitcoin

• バージョン
• トランザクションインプット数
• トランザクションインプット
• トランザクションアウトプット数
• トランザクションアウトプット
• Locktime

一方Bitcoinは、トランザクションインプットとトランザクションアウトプットの集合体です。これは「Bitocin+トランザクションアウトプット」のキーワードで検索してくるとたくさん出てきますが、誰かにビットコインを送金したいアカウントは、

1. 自分が使える未使用トランザクションアウトプットをかき集める（トランザクションインプット）
2. それを送り先アカウントの使える未使用トランザクションアウトプットとして生成する（トランザクションアウトプット）

という手順で送金を行います（間違っていたら指摘してください）。Locktimeはトランザクションの処理にまつわるUNIXタイムスタンプか、またはブロック高です。

手数料

トランザクションをブロックチェーンに取り込むには、マイナーに対して支払う手数料が必要です。

Ethereumは、STARTGAS値とGASPRICE値から手数料が求められます。Bitcoinは、トランザクションアウトプットとインプットの差額が手数料になっています。それぞれどういう計算で手数料が求められるのかは、詳しく調べていません。Ethereumについては、

Estimating transaction costs

ここを見るとよいかと思います。

Contract間通信のためのトランザクション

Ethereumの場合は、送金だけではなくContractでいろいろな処理を行うことができます。Contractのメソッドを呼び出すためにはMessageを投げますが、EthereumのトランザクションはMessageをそのデータフィールドに格納できます。