Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Ethereum design direction.

The Ethereum design direction.

See the Ethereum design direction from the latest upgrades.

nakajo2011

January 29, 2020
Tweet

More Decks by nakajo2011

Other Decks in Programming

Transcript

  1. Copyright © 2019 chaintope Inc. All rights reserved. 自己紹介
 2

    • Yukishige Nakajo • 株式会社chaintope Chief Ethereum Researcher • 福岡県の飯塚市でEthereumの研究中 • Rust, EVM, 主にEth1.0 • https://twitter.com/nakajo https://y-nakajo.hatenablog.com/ • マスタリング・イーサリアム技術監修
  2. Copyright © 2019 chaintope Inc. All rights reserved. 今回お話しする領域
 3

    
 
 今回はEthereum Core領 域の話 簡単な紹介
  3. Copyright © 2019 chaintope Inc. All rights reserved. 最新のアップデートから見るEthereumの 動向


    4 1. Istanbul upgradeについて 2. パトリシアトライの成長に起因する課題と取り組み 3. レイヤー2スケーリングの取り組み 4. まとめ 5. Eth 2.0について
  4. Copyright © 2019 chaintope Inc. All rights reserved. Eth 1.0

    update schedule
 5 Fork number Block number Date Name 0 1 2015-07-30 Frontier 1 200000 2015-09-07 Frontier Thawing 2 1150000 2016-03-14 Homestead 3 1920000 2016-07-20 DAO Fork 4 2463000 2016-10-18 Tangerine Whistle 5 2675000 2016-11-22 Spurious Dragon 6 4370000 2017-10-16 Byzantium 7 7280000 2019-02-28 Constantinople 8 9069000 2019-12-08 Istanbul 9 9200000 2020-01-02 Muir Glacier 10 TBD 2020-06 (tentative) Berlin 11 TBD TBD London 12 TBC TBC Shanghai
  5. Copyright © 2019 chaintope Inc. All rights reserved. Eth 1.0

    update schedule
 6 Fork number Block number Date Name 0 1 2015-07-30 Frontier 1 200000 2015-09-07 Frontier Thawing 2 1150000 2016-03-14 Homestead 3 1920000 2016-07-20 DAO Fork 4 2463000 2016-10-18 Tangerine Whistle 5 2675000 2016-11-22 Spurious Dragon 6 4370000 2017-10-16 Byzantium 7 7280000 2019-02-28 Constantinople 8 9069000 2019-12-08 Istanbul 9 9200000 2020-01-02 Muir Glacier 10 TBD 2020-06 (tentative) Berlin 11 TBD TBD London 12 TBC TBC Shanghai Muir GlacierはDifficulty Bombを延期するためだけ のUpgradeなので、追加された改善提案は無い。
  6. Copyright © 2019 chaintope Inc. All rights reserved. Istanbul upgradeの概要


    7 • EIP-152:ZCashとの相互互換性のためにBLAKE2bハッシュ関数のprecompiled contract*を追加。
 • EIP-1108:zk-SNARKで用いられるalt_bn128楕円曲線のECADDおよびECMULの precompiled contract*のgasコストを削減。
 • EIP-1344:meta-transactionなどのセキュリティーを向上させるためにchainIDを取得す るopecodeの追加。
 • EIP-1884:パトリシアトライサイズに処理速度が依存するオペコードのgasコストを増加。 
 • EIP-2028:Layer2 Scaling Solutionのためにcalldataのgasコストを削減。これによりトラ ンザクションに載せるデータサイズの上限が緩和。 
 • EIP-2200:Constantinople Upgradeの直前で実装が延期されたEIP-1283をEIP-1703と 共に実装するための提案。これにより、複数回のフレーム間での同一Storageの書き換 えコストが安くなる。
 * precompiled contractとはネイティブ実装されたContractのこと 

  7. Copyright © 2019 chaintope Inc. All rights reserved. Istanbul upgradeの概要


    8 • Istanbulで取り込まれた改善提案の傾向から、Istanbul upgradeは以下の2つの問題を改善・緩和するためのもの と考えられる。
 1. パトリシアトライの成長に起因した一部オペコードの 処理速度低下の緩和。
 2. レイヤー2スケーリングのための環境改善。

  8. Copyright © 2019 chaintope Inc. All rights reserved. 最新のアップデートから見るEthereumの 動向


    9 1. Istanbul upgradeについて 2. パトリシアトライの成長に起因する課題と取り組み 3. レイヤー2スケーリングの取り組み 4. まとめ 5. Eth 2.0について
  9. Copyright © 2019 chaintope Inc. All rights reserved. パトリシアトライの成長に起因する問題
 10

    • フルノードの運用に高スペックなマシンが必要となる。
 ◦ ネットワークの分権化が脅かされる。
 • 現状のDisk I/O per Block。
 (送金txのみが格納された、Block gas limit = 10MのBlockを想定。1 blockに格納されるtxは 10000 / 21 = 476)
 ◦ Read: 476 * 2 * (6 * 32 * 16 + 80 + 32) = 約3MB
 ◦ Write: 476 * 2 * (6 * 32 + 80)= 約 260 + 25+α KB
 約 7 Log_16(90M) = 7 • 2018年3月以降フルノード運用には SSDが推奨されている。 • Dappsサービスを開始する時にフル ノードを立てるのが難しくなる。 => マイナーとバリデータの集中化、寡 占化につながる。
  10. Copyright © 2019 chaintope Inc. All rights reserved. EVM処理速度の推移
 11

    https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1884.md より AWS EC2インスタンスの m5.2xlargeを用いた完全同期処理 時のオペコードの処理時間の推移 グラフ。 最近の処理速度は2016年9月中 旬(ブロック番号2,300,000近辺)に DDoS攻撃を受けていた時以上に 遅くなっている。 【オペコードの説明】 SLOAD: Contractに保存されてい るStorageデータを読み出すオペ コード。 BALANCE: 指定されたアカウント の保有ETH量を取得するオペコー ド。 パトリシアトライデータの増加がEVMの処理速度にも影響している
  11. Copyright © 2019 chaintope Inc. All rights reserved. Ethereumのトランザクション
 12

    • TransactionはState情報を書き換えるトリガー。
 • Ethereumが保有しているAccount情報が書き換わる。
 • EthereumのStateはAccount情報の集合。つまり、Transactionを発行すると Ethreumが新しいStateへと変化する。

  12. Copyright © 2019 chaintope Inc. All rights reserved. Ethereumのアカウント構造
 13

    • Code Hash: Contractの本体コードの Hash値。
 • Storage Root Hash: Contractに保存さ れたデータのMerkle Root Hash値。 • Nonce: このアカウントが発行したTransaction数。
 • Balance: このアカウントが保有しているETHの量。

  13. Copyright © 2019 chaintope Inc. All rights reserved. Ethereumのアカウントの種類
 14

    • External Owned Account
 ◦ 秘密鍵を持つAccount。Transactionの発行は必ずEOAから行われる。 
 • Contract Account
 ◦ CodeとStorageも持つ。 
 ◦ Contractを作成した時に生成されるAccount。 
 ◦ NonceはこのAccountから新しいContractを生成した時にインクリメントされる。 

  14. Copyright © 2019 chaintope Inc. All rights reserved. Ethereumのブロック構造
 15

    Merkle Patricia Trie • Account情報の集合がEthereumのStateである。 • EthereumはStateのcommitmentを持つ。 • そのため、Block検証には今まで保存された全ての State情報が必要となる。 • Block生成は約15秒間隔。
  15. Copyright © 2019 chaintope Inc. All rights reserved. マークルパトリシアトライ(Merkle Patricia

    Trie)
 16 https://blog.ethereum.org/2019/12/30/eth1x-files-state-of-stateless-ethereum/ より • Stateデータの増加=パトリシアトライの成長= Key-Valueストアの増加。 • アカウント情報を取得する時はパトリシアトライの探索と、 Key-Valueストアに対する フェッチが発生。 => Stateの増加が処理速度低下につながる。 • Merkle Root Hashの算出が高速。O(log_16 n)
  16. Copyright © 2019 chaintope Inc. All rights reserved. Ethereumに記録されているアカウント数
 17

    https://etherscan.io/chart/address より • 2020年1月16日現在、約90Mのアカウントが記録されている。 • アカウント数の増加=Stateデータの増加=パトリシアトライの成長。
  17. Copyright © 2019 chaintope Inc. All rights reserved. Istanbulで実装された処理速度低下への改善提案とその影 響について


    18 • ストレージサイズに処理速度が依存するオペコードのgasコストを増加。
 ◦ SLOAD: 200 gas => 800 gas
 ◦ BALANCE: 400 gas => 700 gas
 ◦ EXTCODEHASH: 400 gas => 700 gas
 • Ethereumではハードウェアの進化や、ネットワークの成長に対して、各種オ ペコードのgasコストを調整する事で対応する方針。
 • 比較的よく使われているSLOADのgasコストが増加したため、今後は off-chainにデータを保存する傾向が高まるかもしれない。

  18. Copyright © 2019 chaintope Inc. All rights reserved. その他の改善提案:State Rent

    
 19 • Ethereum全体のstateサイズに上限を設定することが目的。
 • AccountのStorageに保存されているデータ量に応じて、家賃を支払わせる プロトコル。
 • 家賃を支払えない場合はCodeとStorageのデータを削除する。
 
 require rent fee
  19. Copyright © 2019 chaintope Inc. All rights reserved. State Rent

    の仕組み
 20 • Accountが持っているStorageのサイズとEthereumが保有しているデータ全 体量に応じて家賃が決定される。
 • 家賃はそのスマートコントラクトのStorageが変更されるタイミングで請求され る。
 • 家賃が払えないスマートコントラクトはcode hashとStorage root hash以外が 削除される。(元のdataと未払いの家賃を払えば復旧可能)
 State変更時に 家賃が引かれる 家賃が払えないとデータが削 除される。 Tx
  20. Copyright © 2019 chaintope Inc. All rights reserved. State Rent

    の課題
 21 • スマートコントラクトのデータを増加させ、家賃を払えなくする家賃増大攻撃 という新しい攻撃ベクトルが生まれる。
 • 特に、現状広く使われているERC20トークンはこの攻撃に弱い。
 • mainnetに展開済みのスマートコントラクトの大部分について、この脆弱性に 対応するように書き換える必要がある。
 • これは現実的ではないため、2019年末に提案はpendhingされた。
 
 Attack ERC20 Storage data ERC20 Storage data 少額のtokenを適当なアドレ スにばらまく
  21. Copyright © 2019 chaintope Inc. All rights reserved. その他の改善提案:Stateless Client


    22 • Dappsサービス提供者がノードを低コストで運用できるようにすることが目 的。
 • ブロック検証にFull Stateを必要としないClient。
 • Stateデータを持っていなくても、ブロックで変更されたStateが正しいことを検 証するためのBlock WitnessをHeaderに追加する。
 https://blog.ethereum.org/2019/12/30/eth1x-files-state-of-stateless-ethereum/ より block witness • BitcoinのSPVノードに似た考え方。 • ノートPCなど軽量スペックで動かすこと を目的としている。 • Dappsサービス提供者は提供サービス に関連するデータのみ保持すれば良く なる。
  22. Copyright © 2019 chaintope Inc. All rights reserved. Stateless Clientの課題


    23 • 現在のEthereumの状況ではblock-witnessが非常に大きくなるケースが存在 する。(https://ethereum-magicians.org/t/protocol-changes-to-bound-witness-size/3885 より)
 ◦ ETH送金txのみの場合:2.31MB
 ◦ 一般的なERC20の送金の場合: 1571KB
 ◦ 最悪ケースの場合:324MB!!
 ▪ 最悪のケースはcallオペコードを用いて、21KBのコード量を持つスマートコントラクト を大量に呼び出した場合。Witnessには呼び出されたスマートコントラクトのコードも 含める必要があるためデータサイズが増大する。 
 • Block Witnessの追加によってBlockサイズが増加し、同期に必要な帯域幅 が大きくなってしまう。

  23. Copyright © 2019 chaintope Inc. All rights reserved. 最新のアップデートから見るEthereumの 動向


    24 1. Istanbul upgradeについて 2. パトリシアトライの成長に起因する課題と取り組み 3. レイヤー2スケーリングの取り組み 4. まとめ 5. Eth 2.0について
  24. Copyright © 2019 chaintope Inc. All rights reserved. レイヤー2スケーリングの問題
 25

    • Ethereumでは次の2つのScaling Solutionが研究されている。
 ◦ Raiden Network:ペイメントチャンネルプロトコルを用いたERC20支払い のためのスケーリングソリューション。
 ◦ Plasma: サイドチェーン技術をベースとし、サイドチェーンの管理者にト ラストすることなくサイドチェーンを用いるためのソリューション。
 • どちらの研究もまだ有効なソリューションを打ち出せていない。

  25. Copyright © 2019 chaintope Inc. All rights reserved. Raiden Networkの現状


    26 https://explorer.raiden.network/ より • 2018年12月22日にv0.100.1 - Red Eyesがリリースされ、mainnet上で稼 働が開始。 • 1年経過したが利用者は少ない。 • Ethereumでは送金の高速化のみのソリューションは求められていないと考 えられる。
  26. Copyright © 2019 chaintope Inc. All rights reserved. 2019年内のTransactionの内訳
 27

    • GAME、EXCHANGE、CASINOで84%を占める。 • EXCHANGE、FINANCEでマーケットボリュームの80%を占める。 • EXCHANGEやGAME領域のスケーリングが必要。 https://dapp.review/article/238/2019-Dapp-Market-Report より
  27. Copyright © 2019 chaintope Inc. All rights reserved. EXCHANGE(DEX)の処理概要
 28

    1. 署名付きの売り注文を提出 2. オーダーブックに反映 3. オーダーブックを確認 4. 希望のオーダーに対して署名付き の買い注文を提出 5. Ethereumネットワークに決済トラン ザクションをブロードキャスト 1 2 3 4 5 • 今のDEXサービスはコストの高いオーダーマッチングはオフチェインで 行う。 • 決済が確定したものだけEthereumにブロードキャストする。 • 署名をつけることでRelayerのデータ改変を防ぐ。 • off-chainでの処理とon-chainでの処理に分けることで、高速なマッチ ング処理と透明な取引を両立させている。
  28. Copyright © 2019 chaintope Inc. All rights reserved. EXCHANGE(DEX)のon-chain決済の処理
 29

    • MakerとTakerの署名がついた決済データをTransactionとしてスマート コントラクトに送る。 • スマートコントラクトでは、署名からMakerとTakerのアカウントアドレス を復元し、取引対象の2つのTokenの残高を書き換える。 Settlement DataにはMakerと Takerの署名も含まれる スマートコントラクト でアドレスを署名か ら復元
  29. Copyright © 2019 chaintope Inc. All rights reserved. EXCHANGE(DEX)の抱える問題(Istanbul前)
 30

    • gasの制限でon-chainで一度に処理可能な数には上限がある。 • バッチ処理の効果が低い。 ◦ 1.4倍程度しか処理できる量は増えない。 ◦ exchangeに要するgas costが77,000 ~ 92,000(* IDEXより) ◦ バッチ処理で軽減されるのはtransaction発行手数料の21,000 gasの み。 gas cost gas cost gas cost
  30. Copyright © 2019 chaintope Inc. All rights reserved. Istanbulでの改善内容
 31

    • 同じStorageを1回のTransactionの処理で複数回書き換える場合は大幅に コストが下がる。 ◦ 5,000 gas -> 200 gas まで下がる。 • Transactionに載せることができるdata量が4倍まで引き上げられた。 • これら2つの変更により、バッチで処理可能な数が大幅に向上する。 ◦ ただし、ネッティング可能な取引を集めた場合のみ。 gas cost gas cost gas cost 条件付きで大幅に コストダウン 1/4
  31. Copyright © 2019 chaintope Inc. All rights reserved. 信頼が最小化されたスケーラブルなサイドチェーンが構築可能
 最新のスケーリング手法:Optimistic

    Rollup
 32 1Blockのtxとroot hashを Ethereumに書き込む。 取引は全てSide Chainで高速に 処理をする。
  32. Copyright © 2019 chaintope Inc. All rights reserved. Optimistic Rollupについて


    33 • Plasmaの研究から生まれた、最新のスケーリング手法。
 • Plasmaが対数的なスケーリングを実現するのに比べて、Optimistic Rollupで は線形にしかスケーリングしない。
 ◦ ~ 200倍程度。〜2000 tps
 • Plasmaに比べて実装が比較的容易
 ◦ Transaction Hashを全て記録する ため、Bitcoinと同程度の検証能力 を持つ。
 • Optimistic(楽観的)の意味は、管理者 に一定の信頼を置くため。
 ◦ 管理者の不正は証明(fraud proof) を提出することでチェック可能。

  33. Copyright © 2019 chaintope Inc. All rights reserved. Optimistic Rollupのスケーリング効果


    34 • gasコストについては単純計算で1/40。
 ◦ Transactionの最低手数料 21,000gas
 ◦ 32byteデータのgasコスト 32 * 16 = 512 gas
 • 最適化によって~2000tpsのスケーリングが期待されている。
 • Devcon5(in 大阪)のDemoでは Max 250tpsを記録。
 ◦ 今のEthereumが10 tps前後なの で、約25倍高速。

  34. Copyright © 2019 chaintope Inc. All rights reserved. Optimistic Rollupの課題


    35 • Side Chainをデザインしないといけないため、まだまだ実装のハードルは高 い。(とはいえ、Plasmaよりは簡単)
 • 不正証明の提出や、Root Chainにブロックデータを書き込む時の手数料をど う捻出するか。経済的な観点での実績はこれからの取り組み次第。
 • 不正証明を網羅するハードルが高い。
 • PlasmaグループのメンバーがOptimistic Rollupを社会実装するための営利団体、 「Optimism」を設立し、これらの課題を解 決していくことを1月16日に発表。 ttps://medium.com/ethereum-optimism/optimism-cd9bea61a3ee
  35. Copyright © 2019 chaintope Inc. All rights reserved. 最新のアップデートから見るEthereumの 動向


    36 1. Istanbul upgradeについて 2. パトリシアトライの成長に起因する課題と取り組み 3. レイヤー2スケーリングの取り組み 4. まとめ 5. Eth 2.0について
  36. Copyright © 2019 chaintope Inc. All rights reserved. まとめ
 37

    • Ethereum 1.0では成長し続けるStateデータの影響をどのように軽減していく かが長期的な課題。
 ◦ 多角的なアプローチでこの課題を解決するための取り組みが続けられ ている。
 • EthereumではLayer2のスケーリングソリューションが弱い
 ◦ Layer1であるEtherum自体の表現能力が高いことが起因している。
 ◦ そのため、Layer2では広範囲なケースの安全性を考慮する必要があり 複雑性が増している。
 ◦ 現在では多くのプロジェクトがOptimistic Rollupの実装に取り組み、ス ケーリングの改善に着手している。

  37. Copyright © 2019 chaintope Inc. All rights reserved. 最新のアップデートから見るEthereumの 動向


    38 1. Istanbul upgradeについて 2. パトリシアトライの成長に起因する課題と取り組み 3. レイヤー2スケーリングの取り組み 4. まとめ 5. Eth 2.0について
  38. Copyright © 2019 chaintope Inc. All rights reserved. Eth 2.0

    Roadmap
 39 
 
 Phase0 (2020/07?) • Beacon Chain • Fork Choice • Deposit Contract • Honest Validator Phase1 (2021?) • Custody Game • Shard Data Chains • Misc beacon chain updates Phase2 • Still actively in R&D https://github.com/ethereum/eth2.0-specs BLS署名の安全性が確認できるまで延期。 https://coinchoice.net/eth2_beacon-chain-launch-will-push-back-to -july_bnews/ しばらくの間、Eth 2.0とEth 1.0はそれぞれ 別々のネットワークとして同時に存在する。 現在の計画では、最終的に Eth1.0がEth2.0の shard chainの1つとして取り込まれる予定。
  39. Copyright © 2019 chaintope Inc. All rights reserved. Eth 2.0

    Phase 0
 40 https://docs.google.com/presentation/d/1_C_79ilyX0BsyMnSY84M3DoItPU9hBNxnvUEWOOLN7k/edit#slide=id.g620ddc 5326_1_2997 より • Eth 1.0は稼働を続けたまま、Eth 2.0が別のchainとして稼働。 • Phase 0ではEth 1.0でデポジットされたETH2を管理する機能のみを 持つ。 • 次に続くShardingのためのコンセンサスアルゴリズムをチェックするこ とが目的。
  40. Copyright © 2019 chaintope Inc. All rights reserved. Eth 2.0

    Phase 1
 41 • Eth 1.0とEth 2.0はそれぞれ稼働したまま。 • Phase 1でShard Chainが追加される。 • Phase 1ではShard Chain上でのスマートコントラクトの実行は行えな い。 • Phase 1はShardingのコンセンサス、特にクロスリンクが有効に稼働 するかをチェックすることが目的。
  41. Copyright © 2019 chaintope Inc. All rights reserved. Eth 2.0

    Phase 2
 42 • Phase 2では Eth 1.0からのデポジットは終了。 • Sharad Chain上で任意のスマートコントラクトが実行可能となる。 • Phase 2以降はShard Chain間で自由にETH2を転送可能になる。 • Eth 1.0をEth 2.0に統合する計画はあるが、どうなるかは未定。
  42. Copyright © 2019 chaintope Inc. All rights reserved. Eth 2.0

    のテストネットについて
 43 • Phase 0のテストネットが稼働中。 • etherscanがエクスプローラーサイトを公開している。 • Phase 0の公開は秒読みとなっているが、BLS署名の安全性が確認で きるまで延期。 https://beacon.etherscan.io/ より