The Ethereum design direction.

The Ethereum design direction.

See the Ethereum design direction from the latest upgrades.

F4a070b8c7ef49bce7126605f15ce214?s=128

nakajo2011

January 29, 2020
Tweet

Transcript

  1. 2.

    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. 3.

    Copyright © 2019 chaintope Inc. All rights reserved. 今回お話しする領域
 3

    
 
 今回はEthereum Core領 域の話 簡単な紹介
  3. 4.

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


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

    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. 6.

    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. 7.

    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. 8.

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


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

  8. 9.

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


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

    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. 11.

    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. 12.

    Copyright © 2019 chaintope Inc. All rights reserved. Ethereumのトランザクション
 12

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

  12. 13.

    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. 14.

    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. 15.

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

    Merkle Patricia Trie • Account情報の集合がEthereumのStateである。 • EthereumはStateのcommitmentを持つ。 • そのため、Block検証には今まで保存された全ての State情報が必要となる。 • Block生成は約15秒間隔。
  15. 16.

    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. 17.

    Copyright © 2019 chaintope Inc. All rights reserved. Ethereumに記録されているアカウント数
 17

    https://etherscan.io/chart/address より • 2020年1月16日現在、約90Mのアカウントが記録されている。 • アカウント数の増加=Stateデータの増加=パトリシアトライの成長。
  17. 18.

    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. 19.

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

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

    Copyright © 2019 chaintope Inc. All rights reserved. State Rent

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

    Copyright © 2019 chaintope Inc. All rights reserved. State Rent

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

    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. 23.

    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. 24.

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


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

    Copyright © 2019 chaintope Inc. All rights reserved. レイヤー2スケーリングの問題
 25

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

  25. 26.

    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. 27.

    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. 28.

    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. 29.

    Copyright © 2019 chaintope Inc. All rights reserved. EXCHANGE(DEX)のon-chain決済の処理
 29

    • MakerとTakerの署名がついた決済データをTransactionとしてスマート コントラクトに送る。 • スマートコントラクトでは、署名からMakerとTakerのアカウントアドレス を復元し、取引対象の2つのTokenの残高を書き換える。 Settlement DataにはMakerと Takerの署名も含まれる スマートコントラクト でアドレスを署名か ら復元
  29. 30.

    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. 31.

    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. 32.

    Copyright © 2019 chaintope Inc. All rights reserved. 信頼が最小化されたスケーラブルなサイドチェーンが構築可能
 最新のスケーリング手法:Optimistic

    Rollup
 32 1Blockのtxとroot hashを Ethereumに書き込む。 取引は全てSide Chainで高速に 処理をする。
  32. 33.

    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. 34.

    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. 35.

    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. 36.

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


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

    Copyright © 2019 chaintope Inc. All rights reserved. まとめ
 37

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

  37. 38.

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


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

    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. 40.

    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. 41.

    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. 42.

    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. 43.

    Copyright © 2019 chaintope Inc. All rights reserved. Eth 2.0

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