作成者別アーカイブ: mekpsy

ブロックチェーンOracle問題のソリューション、Realitio

ブロックチェーンのOracle問題というものがあります。ブロックチェーンにチェーン外の情報を取り入れるとき、その情報の正しさをどう担保するのか?という問題です。

Oraclizeが代表的なOracleのソリューションですが、去年からRealitioというOracleプロジェクトに協力させてもらってます。Edmund Edgarさんのプロジェクトになります。チェーン外の情報の正しさを確かめるのに、OraclizeはTLSNotary Proofなどの情報科学の手法を使ってますが、Realitioは報酬とボンドによる動機付けを採用しています。

https://realit.io/

何度かの修正を経て、現在Ethereumのメインネットでリアルマネーテストを行っています。

ユーザーがやることの流れとしては、次のようになります。

  1. 質問者は、カウントダウン期間や報酬額(ETH)などいくつかの設定をして質問を投稿する。
  2. 回答者は、ボンド(ETH)を設定して答えを投稿する。
  3. 2.の答えに対抗する回答者が現れずにカウントダウン期間が過ぎたら、2.の答えがファイナルアンサー
  4. 対抗したい回答者は、2.のボンド額の倍以上を設定して自分の答えを投稿。このとき、カウントダウン期間はリセットされる。
  5. カウントダウン期間が過ぎるまで4.を繰り返し
  6. ファイナルアンサーを投稿した回答者には、質問者が設定した報酬とそこまで連なった回答のボンドの総額(ETH)が、送られます。
  7. 調停者(アービトレーター)に調停を依頼することも出来ます。この場合、調停者がファイナルアンサーを決めることになります。

ETHを獲得できるという動機付けで、正しい答えを投稿することを促す仕組みになってます。興味のある方は、White paperを読んでみてください。

Oraclizeがアルゴリズムで外部データを検証しているのに対して、Realitioは人間を経済的に動機付けてデータの正しさを担保しようとしてます。これはEthereum開発者のVitalikのSubjectivocracyというブログポストに影響を受けています。TLSNotary Proofがどういう仕組みなのか知らないのですが、どうも100%情報の正しさを証明するわけではないみたいです。だから、人間で確かめるか機械で確かめるか、面白い試みだと思います。

いまのところ投稿されている質問は、こんな感じです。

  • Did the price of ether (ETH) fall below $100 on Coinbase at any point in 2018?
    (CoinbaseでのETHの価格が、2018年内に100ドルを下回るか?)
  • Did North Korea stop their nuclear weapons program by September 1st, 2018?
    (北朝鮮は今年の9月1日までに核兵器開発プログラムを停止したか?)
  • Did Donald Trump say “everybody would be very poor” if he was impeached?
    (トランプ大統領は、「私を弾劾すれば皆貧しくなるだろう」といったのか?)
  • Who won the 2018 NCAA basketball championship?
    (2018年のNCAAバスケットボールのチャンピオンはどのチームか?)

どう機能していくかは、質問と回答がもっと集まらないと何とも分からないですね。

オリジナルのContractを作ってRealitioと連携することもできます。また、調停者には人間でもContractでもなることができます。Edgarさんは、Realitioとリアルな機関との提携も視野に入れているみたいです。

Onokuwaのクリエイター支援通貨 CLAP

Onokuwaという会社が、CLAPという仮想通貨とそれを使うアプリをリリースしている。なんでも、クリエイターとファンを繋ぐ経済圏を作ることが目的だそうだ。当ブログも経済圏の創出を目指しているので、興味がある。

CLAPはVALUと違って、円やビットコインと紐づかないという特徴があって、これは凄く好ましいことと思う。CLAPを獲得するには、現実世界のどこかにある「CLAP SPOT」に足を運ばないといけない。そこでQRコードを読み込むことになるよう。

(※いつの間にかアクセスできなくなってました。Onokuwaに何があったのか?)

http://www.clapworld.io/

CLAPを手に入れると何が出来るのかは、定かではない・・・。足を運んだ先のクリエイターさんの特典なり、手に入るのかもしれない。何しろ経済圏を作りたいらしいし、オリコンなんかに代わる評価指標になりたいといってるので、いろいろ企画をしているのだと思う。

コラボをしている音楽グループとして、Miliがいる。

http://projectmili.com/

ビジュアルとしては、こういうプロダクトに似合う系統。個人的にも好み。曲はまだ聴いてないw

ブロックチェーン屋さんとしては、ブロックチェーンをどういう状態で組み込んだ設計をしているのか、そこが知りたいんだが、情報がない・・・。

4月のTechCrunchの記事 によると、こんなふうに書いてあるが・・・。

森川氏は「新しい価値指標としてのCLAPには、透明性と特定の機関に依存しないことを求めて、ブロックチェーンを使うことを選んだ。ブロックチェーンを利用することで、指標をグローバルに広めることもできる」と話している。「またブロックチェーンは個人間のP2P取引に用いられる仕組み。たまったCLAPをファンからクリエイターへ、クリエイターが別の才能を持つクリエイターへ、という形でやり取りすることで、価値を個人間で流通させることも目指している」(森川氏)

ブロックチェーンを採用しても、自動的に透明性や非中央集権制が確保できるわけではない。パブリック型・コンソーシアム型・プライベート型で、また、合意形成のアルゴリズムの種類で、その辺の性質は変わってくる。もっというと、Ethereumやビットコインのフォーク騒ぎを見れば分かるように、コミュニティのガバナンスが大きく影響してくる。

もし、CLAPに採用されているブロックチェーンが、株式会社Onokuwaが単独で運用するプライベートチェーンならば、一般ユーザーから見れば、それは単に株式会社Onokuwaを信用するだけの話で、ブロックチェーンかどうかはあまり意味がないんだよなあ。このケースでは、ブロックチェーンで動いていようが、WEB+DBで動いていようが、

ブロックチェーンなら何となく新しいから信用できそう

くらいのイメージ以上の違いはないのだ。完全プライベートチェーンで意味のあるユースケースはほんとう難しくて、こないだ「おお!!これは!!!!!!!」みたいな、プライベートチェーンならではの社内アプリ(そう、社内向けだからプライベートチェーンが生きるのだ)がスタートするかと思ったら、以後音沙汰なしてガッカリしているくらい。

オリコンに代わる指標を作るという意志があるみたいなので、そこはブロックチェーンを使う意味が出てきそうだけど、やっぱりそこでもプライベートなのかパブリックなのかコンソーシアムなのかってことは、変わらず問題なのだよなあ。

やりようによっては、コンソーシアム型チェーンで評価指標を作るのはありえると思う。

とりあえずCLAP、落としてみます。参加クリエイター、増えますように。

貧民的DAppsプログラミング

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

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

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

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

  • 価格の範囲を 0.000001 ~ 1000000(106~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年代にいわれてました。ブロックチェーンプログラミングでは、けっこうチマチマと節約しながらプログラムするシーンが戻ってきたようです。

Web以前を思い出させるEthereumのDApp開発

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

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

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

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

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

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

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

ブロックチェーンへのうまいデータ格納方法を調べていて見つけたのが、この記事です。株などのオーダーブックを、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勉強会 実習課題 (1)

今回の目標

EthereumのDApp開発のための環境を構築し、TruffleのボイラープレートアプリケーションのひとつMetaCoinを動作させること。

エンジニアの人が集まっているようなので、まずコマンドライン(truffle console)で全て動かし、何をしているかコードレベルで確認します。今回の内容は、EthereumでDAppを作るための基本要素で、千本ノック的に体得するといいです。更の環境から7番まで、1時間かからないでいけるまで頑張りましょう(ニッコリ)

OSなどは各自の環境で違うと思いますが、ここではvagrant上のubuntu16.04でのコンソールの状態を転記しています。

実習

1. NodeJs をインストールしよう

ここに、apt-getなどパッケージマネージャーでのインストール方法が書いてあります。

https://nodejs.org/ja/download/package-manager/

ubuntuでのNode.js のインストール

確認

 2. Truffle をインストールしよう

確認

3. Ganache CLIをインストールしよう

Ganache CLIは、以前使っていたtestrpcがTruffle Suiteに取り込まれたものです。UI付きでトランザクションやアカウントの管理が出来るGanacheの、コマンドラインバージョンです。

http://truffleframework.com/ganache/

Ganacheは見た目がとてもきれいで使いやすそうなんですが、今回は時間と環境の制約上CLIバージョンを使用します。

4. MetaCoinプロジェクトを作ろう

MetaCoinは、truffleのボイラープレート(テンプレのようなもの)として用意してありますので、unboxします。MetaCoin以外にもいろいろあります。http://truffleframework.com/boxes/

contracts/MetaCoin.sol というファイルがContract本体になります。下にコードを掲載します。もう皆さん見飽きていると思いますが、今回確実に動作させて次に参りましょう。

truffle.jsのコンフィグを書き加えます。

5. Ganeche CLIを起動しよう

6.  Contractをマイグレートしよう

7. truffle console でMetaCoinを動かそう

truffle consoleを起動します。

ganache-cliがアカウントを10個用意してくれています。そのうちの2つでMetaCoinをやり取りしてみます。

現在のETH残高を確認。

deployされたMetaCoinをインスタンス化。

ContractのgetBalanceメソッドを呼び出して、送金前のMetaCoin残高を確認。これは、Ethereumの“Call”になります。→ CallとTransactionの違い

contarctのsendCoinメソッドを呼び出してMetaCoinをアカウント1からアカウント2へ送金。これはEthereumの“Transaction”になります。→ CallとTransactionの違い

送金後のETH、MetaCoin残高を確認

truffle console を終了。

8. CallとTransactionの違い

Ethreumブロックチェーンに対してクライアントから送る指示には、CallとTransactionがあります。違いは次のようになります。

Call

  • Gasを使用しない
  • ネットワークの状態を変えない
  • すぐに処理される
  • 値を返す

Transaction

  • Gasを使用する
  • ネットワークの状態を変化させる
  • マイニングされるまで処理されない
  • Transaction IDを返す

演習

Metacoin.solのメソッド getBalanceInEth を truffle console から実行して、結果を確認してみよう。

CryptoKittiesをカワイクする方法は?

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圏が林立している、そんな状況を妄想しています。まあ、ポケモンでも別にいいけど。

ハードフォークはブロックチェーン社会でWait&See(ハードフォークの意義2)

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

http://vitalik.ca/general/2017/03/14/forks_and_markets.html

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はいってます。ソフトフォークなら、そのまま同じツールを使い続けられますからね。だけど、ツールの使い方に目が行きがちな鉄器ーじゃなかったwテッキーなあなた。大切なのはツールの使い方じゃない。受け入れたくないことを強制されるかどうかなのです。

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

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

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

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

ハードフォークはブロックチェーン社会で義経を逃す(ハードフォークの意義1)

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

弁慶のドット絵

 

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

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

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

http://vitalik.ca/general/2017/03/14/forks_and_markets.html

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

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

ソフトフォーク
valid とみなす transaction を減らすやり方。アップグレードなしでも、チェーン上にい続けることができる
ハードフォーク
フォーク 前まで invalid だった トランザクション も valid とするかもしれないので、ユーザーは フォークしたチェーンの上にいたければ、クライアントアップグレードが必要。

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

Strictly Expanded Hard Fork
validとみなされるトランザクションを拡張するハードフォーク。フォーク前のルールは、フォーク後のルールのソフトフォークにあたる
Bilateral Hard Fork
互換性のない2つのルールに分岐するハードフォーク

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

ソフトフォーク
アタッカーのアドレス対象のトランザクションが、validではなくなる。現実には採用されなかった
ハードフォーク
実際にBilateral Hard Forkとして採用された。ETH/ETCとして2つのルールに分裂した

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

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

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

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

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

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

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

続く。

Block Gas Limitの設定の反映

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

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

http://individua1.net/how-is-the-block-gas-limit-determined/

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

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

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

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

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

と思われます。

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

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

Ethereumがトランザクションの過半数を占めているらしい

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

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

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

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

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

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

http://www.trustnodes.com/2017/11/22/ethereum-now-handles-transactions-digital-currencies-combined

ここを見ると、驚いたことに暗号通貨のトランザクションの過半数を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の5つのトランザクションがあって、それぞれの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が、攻撃されながらもトランザクションを大量に処理できているのはなぜか?これは実は、技術にとどまらない本質が潜んでいそうです。

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