Ethereum whitepaper
•
17 likes•4,671 views
Discussion material about Ethereum WhitePaper Ethereum meeting at 19 Jun 2014 https://www.youtube.com/watch?v=YYUX3wR4XrM&feature=youtu.be
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (19)
More from Kenichi Kurimoto
Ethereum whitepaper
- 3. Bitcoin
- 4. 前書き Bitcoinには二つの大きな革命的コンセプト (1) 非中央集権P2P通貨 (2)非中央集権なトランザクションの’順序’を公的に合意するシステム (2)に対する注目が集まり始めてる colored coins, smart property, Namecoin 非中央集権両替所、金融デリバティブ、P2Pギャンブル、、、 smart contract から DAOへ
- 6. マイニング
- 7. マークルツリー
- 8. その他のblockchain application(1) •Namecoin 名前のレジスタ。blockchainのfirst-to-fileにぴったり Bitcoinのblockchainとは別の独自blockchainを管理 •Colored coins デジタルトークン。単位が一つの通貨と考えれば良い。 BitcoinのUTXOにcolorをアサインした通貨を発行 Bitcoinのblockchainをそのまま利用? colorの確定にblockchainのバックトラックが必要なためSPVが使えない •Metacoins 用途？ Bitcoin上のプロトコルを利用 すでにある、Bitcoinのネットワークやマイニングを利用するので低コスト
- 9. その他のblockchain application(2) 2種類のアプローチ: (1)独自のネットワークを作る (2)ビットコイン上のプロトコルを作る (1) 独自のblockchainを立ち上げ、全てをテストする必要 ーコスト高い 非中央集権合意ベースのアプリケーションの個数は多い ーその度にblockchain作るのか？ (2) bitcoinのSPVが使えない ー light nodeが作れない (独自のプロトコル外の物が混じることを禁止できないため セキュアにするためにはblockchainバックトラックが必要)
- 12. •新しいblockchainを作る - 何でもできるが、開発と立ち上げは非常に難しい •Bitcoinのスクリプトを利用する - 非常に簡単だが、できることが限られている •Bitcoin上にメタプロトコルを作る - スケーラビリティに難 Ethereum! チューリング完全、Value-awareness, blockchain-awareness, 状態 を追加したフレームワーク
- 13. Ethereum
- 14. 外部アカウント 秘密鍵コントロール • 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)
- 15. Ethereum acount, message and transaction(2) Ethereumのtransactionとは: 外部accountから送られるmessageを保持しておく 署名されたデータパッケージ • messageの受信者 • messageの送信者と署名 • Ether • 送付データ • ‘STARTGAS’, ‘GASPRICE’ STARTGAS 上限 GASPRICE 演算step毎に払う額
- 16. Ethereum acount, message and transaction(3) Transactionとmessageの仕組み Ethereumの重要なアイデア ‘外部accountとcontractが対等’である (どちらもmessageを送ったり、contractを作ったりできる)
- 17. Ethereum State Transition Function(1)
- 18. 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’]
- 19. 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 を送付者のアカウントに戻す。結果の状態を返す。
- 20. Ethereum State Transition Function(4) •transactionの最後を受信した時に contractが無い場合： フィーはGASPRICEに transactionのバイト数を掛けたもの •contractによって始められた messageは子計算に対して上限を決めれる •子計算が燃料切れになった時、 messageコールが起きた所まで状態が戻る
- 21. コード実行 ３種類のメモリにアクセスできる •Stack : PUSHとPOP •MEMORY: 無限に拡張できるバイトアレイ (セキュア???) •Storage: Key/Valueストア 上記二つは計算が終わればリセットだが、 Storageは長期保持される。
- 22. 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 と同一かどうかチェックする。もしそうなら、ブロックは有効であるそうでないなら有効でない。
- 24. Application
- 25. トークンシステム 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
- 26. 金融デリバティブ 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に送る。
- 27. 金融デリバティブ (1) 不明点 資産をバックアップするファンドを供給する一人の発行者の代わりに、暗号的に参照されて いる資産(例えばETH)が上昇する方に賭ける投機家によるマーケットが役割を果たします。 発行者と異なり、投機家は 彼らに有利なバーゲンを行うオプションがありません。なぜならば ヘッジングcontractはファンドをエスクローで保持しているからです。 (2) この手法は完全に非中央集権化されているわけではないことに注意しましょう。なぜならば、 price tickerを供給する信用できるソースがやはり必要になるからです。 Ethereumでは、システム全てを非中央集権化することに対して徹底的な哲学がある。
- 28. Identity and Reputation System Namecoinのような名前登録システム if !contract.storage[tx.data[0]]: contract.storage[tx.data[0]] = tx.data[1]
- 29. 非中央集権ファイルストレージ 誰もが自分のディスクを他人に貸し出すサービス データをブロックに分割して暗号化、マークルツリーを構成 次のcontractを作る：Nブロック毎にマークルツリーから適当にインデックスを選び、その オーナーシップを証明する transactionを出した人に X Ethere与える ??? ファイルをダウンロードしたい場合、 Etherを払ってリカバリー
- 30. Decentralized Autonomous Organizations 仮想的なエンティティで、 67%以上のメンバー、またはシェアホルダーがファンドを使ったり、コードを 書き換える権利を持つ コードのアウトライン： 2/3のメンバーが賛成した時に自分自身を修正するコード [0,i,K,V] ストレージインデックス kのvalueをvに変更する提案iの登録 [0,i] 提案iに対する賛成の登録 [2,i] 提案iを充分な投票が行われた後、確定する さらに伝達する委任を組み込む -> 問題に対して専門家が現れては消える -> 固定された有識者という権益層を作らない
- 32. 農産物保険 アイオワの農家がアイオワの降水量に逆ばりする contractを結ぶ 干ばつ -> お金を受け取る 順調に雨が降る -> 豊作
- 33. decentralized data feed データのフィードも中央集権化でコントロールされることを避けたい -> SchellingCoin N個のエンティティからデータを受信する 値でソートして 25%〜75%に入るもの全てが1トークンをもらう (皆が外れた値を提供したくないというインセンティブを持つことになる )
- 34. Smart複数署名エスクロー BitcoinのMultisigよりもっと複雑なものを作れる 例:５個の内４個によって何でも使うことができ、 5個の内３個で一日あたり 10%使用す ることができ、5個のうち2個で一日あたり0.5%使用することができる Ethereumは状態を持つので、非同期（異なるタイミング）で複数署名できる！ 最後の署名が行われた時に transactionが行われる。
- 35. クラウドコンピューティング P2Pギャンブル 予測市場 非中央集権マーケットプレイス SETI@HOMEのような粗結合の並列コンピューティング 演算の途中にチェックポイントを作って演算実行を証明
- 36. その他•懸念点
- 37. 修正GHOST実装 マイナーAがnonceを見つけたとして、マイナー Bに伝達される前にマイナー Bがnonceを見つけ ると、マイナーBの見つけたブロックは無駄に終わる マイニング間隔を縮めて無効ブロック生成率が上がると、 CPUパワーが大きい方の有利さが増 す。 GHOST - もっとも長いチェインを計算するときに無効ブロックも含める？ 無効ブロックへの報酬を考えることによって中央集権バイアスを無くす 修正GHOST実装 - １レベルまで。兄弟ブロックの子供まで考慮 Ethereumは40秒のブロックタイムで、 Litecoin(2.5分)と同等になるが、安全マージンをみて 60 秒としている
- 38. フィー マイナーは単純に言って、得られる報酬の期待値が実行コストを超えそうであればマイニングする が、単純計算から逸脱する部分がある 1. マイナーは実際には他の検証ノードよりもトランザクションの実行に高いコストを払う事がある。追加の検証時間がブロックの伝搬を遅らせ、 ブロックが無効になる可能性が増加するため。 2. マイニングを全くしないフルノードが存在する。 3. 実際にはマイニングパワーの分散は非常に不平等に終わる 4. ネットワークを傷つけようとする相場師、政敵、いかれた人達が存在する。彼らは頭が良く、自分たちのコストが他の検証ノードが払うコスト よりもかなり低い contractを作る 以下の回数以上のオペレーションができない？ blk.oplimit = floor((blk.parent.oplimit * (EMAFACTOR - 1) + floor(parent.opcount * BLK_LIMIT_FACTOR)) / EMA_FACTOR)
- 40. 通貨と発行(1) Ethereumのビルトイン通貨 Ether 単位 ●1: wei ●103: lovelace ●106: babbage ●109: shannon ●1012: szabo ●1015: finney ●1018: ether
- 41. 通貨と発行(2) 1BTC当たり 1000-2000etherの価格で販売リリース (開発者の給与や賞金、 Ethereumや仮想通貨エコシステムの利益、非営利プロジェクトへの投資へ ) 全体の量の30%が初期の貢献者へ報いるために Ethereum organizationへ。経費を払った後、残りはファン ドとして保有され残った額の 5.6%が毎月、開発者へ 全体の量の30%がマイナーへ
- 43. マイニング集中 Bitcoinマイニングの中央集権化の二つの問題 (1) ASIC (2) マイニングプール Ethereumアルゴリズム マイナーが状態から乱数をフェッチ、最後の Nブロックからランダムに選ばれた transactionを計算してハッシュを返す。 •contractには様々な種類の演算を入れる事ができるため専用 ASICを作れない •マイナーにブロックチェイン全体の保持と全ての transactionを検証できる必要性がある ことによってマイニングプールの必要性を無くす
- 44. スケーラビリティ BitcoinがVISAのように1秒あたり2000transactionになった場合、１時間当たり 1GB増加に なる × Ethereumは、もっと様々なアプリケーションが動く × Ethereumのフルノードはtransaction全てではなく状態を保持すれば良い ○ 二つの戦略？？