The Ethereum design direction.

Slide 1

Slide 1 text

最新のアップデートから見るEthereumの動向    2020.01.24   

Slide 2

Slide 2 text

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/ ● マスタリング・イーサリアム技術監修

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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なので、追加された改善提案は無い。

Slide 7

Slide 7 text

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のこと  

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Slide 10

Slide 10 text

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サービスを開始する時にフルノードを立てるのが難しくなる。 => マイナーとバリデータの集中化、寡占化につながる。

Slide 11

Slide 11 text

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の処理速度にも影響している

Slide 12

Slide 12 text

Copyright © 2019 chaintope Inc. All rights reserved. Ethereumのトランザクション  12 ● TransactionはState情報を書き換えるトリガー。  ● Ethereumが保有しているAccount情報が書き換わる。  ● EthereumのStateはAccount情報の集合。つまり、Transactionを発行すると Ethreumが新しいStateへと変化する。 

Slide 13

Slide 13 text

Copyright © 2019 chaintope Inc. All rights reserved. Ethereumのアカウント構造  13 ● Code Hash: Contractの本体コードの Hash値。  ● Storage Root Hash: Contractに保存されたデータのMerkle Root Hash値。 ● Nonce: このアカウントが発行したTransaction数。  ● Balance: このアカウントが保有しているETHの量。 

Slide 14

Slide 14 text

Copyright © 2019 chaintope Inc. All rights reserved. Ethereumのアカウントの種類  14 ● External Owned Account  ○ 秘密鍵を持つAccount。Transactionの発行は必ずEOAから行われる。   ● Contract Account  ○ CodeとStorageも持つ。   ○ Contractを作成した時に生成されるAccount。   ○ NonceはこのAccountから新しいContractを生成した時にインクリメントされる。  

Slide 15

Slide 15 text

Copyright © 2019 chaintope Inc. All rights reserved. Ethereumのブロック構造  15 Merkle Patricia Trie ● Account情報の集合がEthereumのStateである。 ● EthereumはStateのcommitmentを持つ。 ● そのため、Block検証には今まで保存された全ての State情報が必要となる。 ● Block生成は約15秒間隔。

Slide 16

Slide 16 text

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)

Slide 17

Slide 17 text

Slide 18

Slide 18 text

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にデータを保存する傾向が高まるかもしれない。 

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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サービス提供者は提供サービスに関連するデータのみ保持すれば良くなる。

Slide 23

Slide 23 text

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サイズが増加し、同期に必要な帯域幅が大きくなってしまう。 

Slide 24

Slide 24 text

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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 より

Slide 28

Slide 28 text

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での処理に分けることで、高速なマッチング処理と透明な取引を両立させている。

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Copyright © 2019 chaintope Inc. All rights reserved. Istanbulでの改善内容  31 ● 同じStorageを１回のTransactionの処理で複数回書き換える場合は大幅にコストが下がる。 ○ 5,000 gas -> 200 gas まで下がる。 ● Transactionに載せることができるdata量が4倍まで引き上げられた。 ● これら2つの変更により、バッチで処理可能な数が大幅に向上する。 ○ ただし、ネッティング可能な取引を集めた場合のみ。 gas cost gas cost gas cost 条件付きで大幅にコストダウン 1/4

Slide 32

Slide 32 text

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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倍高速。 

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Slide 39

Slide 39 text

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つとして取り込まれる予定。

Slide 40

Slide 40 text

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のためのコンセンサスアルゴリズムをチェックすることが目的。

Slide 41

Slide 41 text

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のコンセンサス、特にクロスリンクが有効に稼働するかをチェックすることが目的。

Slide 42

Slide 42 text

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に統合する計画はあるが、どうなるかは未定。

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

株式会社chaintope 代表取締役社長　正田英樹福岡県飯塚市幸袋560-8 [email protected] 44