EthereumKenichi Kurimoto

Ethereum White Paperに関する ディスカッション

Bitcoin

前書き

Bitcoinには二つの大きな革命的コンセプト

(1) 非中央集権P2P通貨

(2)非中央集権なトランザクションの’順序’を公的に合意するシステム

(2)に対する注目が集まり始めてる　　　　colored coins, smart property, Namecoin 非中央集権両替所、金融デリバティブ、P2Pギャンブル、、、

smart contract から DAOへ

状態遷移システムとしてのビットコイン

bitcoinはtransactionによって全体の元帳が変わる状態遷移システムである

状態：まだ使われていない Transactionアウトプット：UTXOの集合

(UTXOはオーナーと単位の情報を持っている )

マイニング

マークルツリー

その他のblockchain application(1)

•Namecoin 名前のレジスタ。blockchainのfirst-to-fileにぴったり Bitcoinのblockchainとは別の独自blockchainを管理

•Colored coins 　 デジタルトークン。単位が一つの通貨と考えれば良い。　　　 BitcoinのUTXOにcolorをアサインした通貨を発行 Bitcoinのblockchainをそのまま利用? colorの確定にblockchainのバックトラックが必要なためSPVが使えない

•Metacoins 用途？　　　　 Bitcoin上のプロトコルを利用 すでにある、Bitcoinのネットワークやマイニングを利用するので低コスト

その他のblockchain application(2)

2種類のアプローチ: (1)独自のネットワークを作る (2)ビットコイン上のプロトコルを作る

(1) 独自のblockchainを立ち上げ、全てをテストする必要　 ーコスト高い 非中央集権合意ベースのアプリケーションの個数は多い ーその度にblockchain作るのか？

(2) bitcoinのSPVが使えない ー light nodeが作れない (独自のプロトコル外の物が混じることを禁止できないため セキュアにするためにはblockchainバックトラックが必要)

スクリプティング(1)

Bitcoinのスクリプトで弱いバージョンの”smart contract”が可能

スタックベースのプログラミング言語ー実際の通常の取引もスクリプトベース

Multisigのようなことも可能　　(詳細知らない)

しかし、、、、

スクリプティング(2)

•チューリング完全ではない Loopが無い

•Value-blindness 通貨量をコントロールするようなスクリプト書けない 沢山の単位のUTXO準備して選ぶしかない

•ステートが無い UTXOは使われるか使われないかのみ　 多段のcontractを作れない

•Blockchain blindness blockchainのデータを参照できない。乱数の素

•新しいblockchainを作る - 何でもできるが、開発と立ち上げは非常に難しい

•Bitcoinのスクリプトを利用する - 非常に簡単だが、できることが限られている •Bitcoin上にメタプロトコルを作る - スケーラビリティに難

Ethereum!チューリング完全、Value-awareness, blockchain-awareness, 状態 を追加したフレームワーク

Ethereum

外部アカウント 　 秘密鍵コントロール

• nonce• Ether balance• storage

contract アカウント 　

• nonce• Ether balance• contract code• storage

transactionを作ってsign

message　

を送ることができる

messageを受け取ってcodeアクティベート　　　•storageへの読み書き •他のmessageを送る •contractを作る

Ethereum acount, message and transaction(1)

Ethereum acount, message and transaction(2)

Ethereumのtransactionとは: 外部accountから送られるmessageを保持しておく 署名されたデータパッケージ

• messageの受信者• messageの送信者と署名• Ether• 送付データ• ‘STARTGAS’, ‘GASPRICE’

STARTGAS 上限GASPRICE 演算step毎に払う額

Ethereum acount, message and transaction(3)

Transactionとmessageの仕組み

Ethereumの重要なアイデア ‘外部accountとcontractが対等’である(どちらもmessageを送ったり、contractを作ったりできる)

Ethereum State Transition Function(1)

Ethereum State Transition Function(2):例

if !contract.storage[msg.data[0]]:

contract.storage[msg.data[0]] = mesg.data[1]

Serpantという上位言語 -> EVMコードにコンパイルされる

contractのstorageは空で始まるtransactionは10Etherと共に送付されるSTARTGAS=2000 GASPRICE=0.001データフィールドは二つ [2, ‘CHARLIE’]

Ethereum State Transition Function(3):例if !contract.storage[msg.data[0]]:

contract.storage[msg.data[0]] = mesg.data[1]

1. transactionが有効でformatが正しいかチェック

2. transactionのsenderが 2000x0.001=2 ether持っているかチェック 持っていればsender accountから2 ether 引く

3. gasを2000に初期化: トランザクションが170バイトでバイトあたりのフィーが 5と 仮定する。850を引く事になるので、1150gasが残っている事になる。

4. 10以上のetherを送付者のacountから引いて、contractのアカウントにそれを足す。

5. コードを実行する。： contractのストレージのインデックス 2が使われているか

チェックし、もし使われていなければストレージのインデックス 2に CHARLIE を

セットする。これは187 gasを使用するので、残った gasの量は 1150 - 187 = 963になる。

6. 963 * 0.001 = 0.963 ether を送付者のアカウントに戻す。結果の状態を返す。

Ethereum State Transition Function(4)

•transactionの最後を受信した時に contractが無い場合： フィーはGASPRICEに transactionのバイト数を掛けたもの

•contractによって始められたmessageは子計算に対して上限を決めれる

•子計算が燃料切れになった時、 messageコールが起きた所まで状態が戻る

コード実行

３種類のメモリにアクセスできる

•Stack : PUSHとPOP•MEMORY: 無限に拡張できるバイトアレイ (セキュア???)•Storage: Key/Valueストア　上記二つは計算が終わればリセットだが、 Storageは長期保持される。

Blockchainとマイニング(1)

1. 参照されている一つ前のブロックが存在していて有効であるかチェックする

2. ブロックのタイムスタンプが一つ前のブロックのものより大きく、かつ１５分後以内であるかチェックする

3. ブロック番号、difficulty,トランザクションのルート 、uncle root（訳注：注目するブロックの先祖の子孫） と燃料の上限

(様々な低位のEthereum独自のコンセプト )が有効であるかチェックする

4. ブロックのproof of workが有効かチェックする

5. S[0] を一つ前のブロックの STATE_ROOT にする

6. TX をブロックチェインの n個のトランザクションリストとする。すべて の0...n-1 に対してS[i+1] = APPLY(S[i],TX[i])

7. もしアプリケーションがエラーを返した場合やトータルの燃料がブロック内で GASLIMIT を超えた場合エラーを返す。

8. S_FINAL を S[n],にする。しかし、ブロックのリワードはマイナーに与えられる

9. S_FINAL が STATE_ROOT と同一かどうかチェックする。もしそうなら、ブロックは有効であるそうでないなら有効でない。

Blockchainとマイニング(2)

それぞれのブロックに状態を記録する必要がある。

殆どの状態は変わらないので、前のブロックの状態へのポインタで済む

パトリシアツリー

Application

トークンシステム

from = msg.sender

to = msg.data[0]

value = msg.data[1]

if contract.storage[from] >= value:

contract.storage[from] = contract.storage[from] -

value

contract.storage[to] = contract.storage[to] + value

金融デリバティブ

EtherのUS$に対するボラタリティに対するヘッジ contract

1. 団体Aが1000 ether入力するのを待つ

2. 団体Bが1000 ether入力するのを待つ

3. データフィードcontractに問い合わせる事で計算された、 1000 etherのUSDでの

価値をstorageに記録する。これを $xとする

4. ３０日後、AとBがcontractを再アクティーベートできるようにしておいて、 (再びデータフィード

contractに問い合わせることによって得られた新しい値に相当する )$xの価値があるetherをAに送り、

残りをBに送る。

金融デリバティブ

(1) 不明点 資産をバックアップするファンドを供給する一人の発行者の代わりに、暗号的に参照されている資産(例えばETH)が上昇する方に賭ける投機家によるマーケットが役割を果たします。発行者と異なり、投機家は 彼らに有利なバーゲンを行うオプションがありません。なぜならばヘッジングcontractはファンドをエスクローで保持しているからです。

(2) この手法は完全に非中央集権化されているわけではないことに注意しましょう。なぜならば、price tickerを供給する信用できるソースがやはり必要になるからです。

Ethereumでは、システム全てを非中央集権化することに対して徹底的な哲学がある。

Identity and Reputation System

Namecoinのような名前登録システム

if !contract.storage[tx.data[0]]:

contract.storage[tx.data[0]] = tx.data[1]

非中央集権ファイルストレージ

誰もが自分のディスクを他人に貸し出すサービス

データをブロックに分割して暗号化、マークルツリーを構成

次のcontractを作る：Nブロック毎にマークルツリーから適当にインデックスを選び、そのオーナーシップを証明する transactionを出した人に X Ethere与える ???

ファイルをダウンロードしたい場合、 Etherを払ってリカバリー

Decentralized Autonomous Organizations

仮想的なエンティティで、 67%以上のメンバー、またはシェアホルダーがファンドを使ったり、コードを書き換える権利を持つ

コードのアウトライン：2/3のメンバーが賛成した時に自分自身を修正するコード

[0,i,K,V] ストレージインデックス kのvalueをvに変更する提案 iの登録[0,i] 提案iに対する賛成の登録[2,i] 提案iを充分な投票が行われた後、確定する

さらに伝達する委任を組み込む -> 問題に対して専門家が現れては消える -> 固定された有識者という権益層を作らない

救済可能wallet

アリスは秘密鍵のハックを恐れている。 -> 以下のcontractを結ぶ

•アリスは一人で一日あたり最大でファンドの1%を引き出せる

•ボブは一人で一日あたり最大でファンドの1%を引き出せるが、アリスは自分の鍵でこの権利を終わらせる

能力を持っている。

•アリスとボブは一緒であれば何でも引き出せる

農産物保険

アイオワの農家がアイオワの降水量に逆ばりする contractを結ぶ

干ばつ -> お金を受け取る

順調に雨が降る -> 豊作

decentralized data feed

データのフィードも中央集権化でコントロールされることを避けたい -> SchellingCoin

N個のエンティティからデータを受信する値でソートして 25%〜75%に入るもの全てが1トークンをもらう

(皆が外れた値を提供したくないというインセンティブを持つことになる )

Smart複数署名エスクロー

BitcoinのMultisigよりもっと複雑なものを作れる

例:５個の内４個によって何でも使うことができ、 5個の内３個で一日あたり 10%使用することができ、5個のうち2個で一日あたり0.5%使用することができる

Ethereumは状態を持つので、非同期（異なるタイミング）で複数署名できる！最後の署名が行われた時に transactionが行われる。

クラウドコンピューティング

P2Pギャンブル

予測市場

非中央集権マーケットプレイス

SETI@HOMEのような粗結合の並列コンピューティング演算の途中にチェックポイントを作って演算実行を証明

その他•懸念点

修正GHOST実装

マイナーAがnonceを見つけたとして、マイナー Bに伝達される前にマイナー Bがnonceを見つけると、マイナーBの見つけたブロックは無駄に終わる

マイニング間隔を縮めて無効ブロック生成率が上がると、 CPUパワーが大きい方の有利さが増す。

GHOST - もっとも長いチェインを計算するときに無効ブロックも含める？

無効ブロックへの報酬を考えることによって中央集権バイアスを無くす

修正GHOST実装 - １レベルまで。兄弟ブロックの子供まで考慮

Ethereumは40秒のブロックタイムで、 Litecoin(2.5分)と同等になるが、安全マージンをみて 60秒としている

フィー

マイナーは単純に言って、得られる報酬の期待値が実行コストを超えそうであればマイニングする

が、単純計算から逸脱する部分がある

1. マイナーは実際には他の検証ノードよりもトランザクションの実行に高いコストを払う事がある。追加の検証時間がブロックの伝搬を遅らせ、

ブロックが無効になる可能性が増加するため。

2. マイニングを全くしないフルノードが存在する。

3. 実際にはマイニングパワーの分散は非常に不平等に終わる

4. ネットワークを傷つけようとする相場師、政敵、いかれた人達が存在する。彼らは頭が良く、自分たちのコストが他の検証ノードが払うコスト

よりもかなり低い contractを作る

以下の回数以上のオペレーションができない？

blk.oplimit = floor((blk.parent.oplimit * (EMAFACTOR - 1) + floor(parent.opcount * BLK_LIMIT_FACTOR)) / EMA_FACTOR)

演算とチューリング完全性

Ethereumの仮想マシンはチューリング完全である

(1)JUMP, JUMPI命令があってLoopをコードに書ける (2)contractが他のcontractを呼べる。(無限ループの可能性 )

CSの実行停止問題があって、事前検証不可能

transactionに許される最大実行ステップ数を決めることで解消

通貨と発行(1)

Ethereumのビルトイン通貨 Ether

単位

●1: wei

●103: lovelace

●106: babbage

●109: shannon

●1012: szabo

●1015: finney

●1018: ether

通貨と発行(2)

1BTC当たり 1000-2000etherの価格で販売リリース (開発者の給与や賞金、Ethereumや仮想通貨エコシステムの利益、非営利プロジェクトへの投資へ )

全体の量の30%が初期の貢献者へ報いるために Ethereum organizationへ。経費を払った後、残りはファンドとして保有され残った額の 5.6%が毎月、開発者へ

全体の量の30%がマイナーへ

通貨と発行(3)

1.寄付金プールがある

2. bitcoinと異なり、供給は増え続ける

マイニング集中

Bitcoinマイニングの中央集権化の二つの問題 (1) ASIC (2) マイニングプール

Ethereumアルゴリズム マイナーが状態から乱数をフェッチ、最後の Nブロックからランダムに選ばれた transactionを計算してハッシュを返す。 •contractには様々な種類の演算を入れる事ができるため専用 ASICを作れない •マイナーにブロックチェイン全体の保持と全ての transactionを検証できる必要性がある ことによってマイニングプールの必要性を無くす

スケーラビリティ

BitcoinがVISAのように1秒あたり2000transactionになった場合、１時間当たり 1GB増加になる ×

Ethereumは、もっと様々なアプリケーションが動く ×

Ethereumのフルノードは transaction全てではなく状態を保持すれば良い ○

二つの戦略？？

結論

Ethereumはアプリケーションを直接サポートするのではなく、チューリング完全な言語をビルトインしたもの

Ethereumは非常にオープンな設計

金融、金融以外で、多数のアプリケーションの基礎レイヤーとなる