「Ethereum 2.0」の仕様と研究動向についてLayerX R&Dチームが解説

Ethereum 2.0の目的

中村龍矢氏：というわけで、「Ethereum 2.0について」を進めようと思います。

Ethereum 2.0というのは、実はシャーディングの話だけではなくて、Ethereum全般をアップグレードしようというプロジェクトです。シャーディングに限らず、Proof of Stakeですとか、あとから紹介するいろんなものを変えていこうというものになります。

目的はスケーラビリティの改善とセキュリティの向上。もともとProof of StakeもシャーディングもEthereumは本当にFoundationが初期の頃から基礎研究を進めてやったんですけれども、本格的に作るための仕様に落とし込むよとなったのが2018年ころからです。

以前はProof of Stakeから、シャーディングは別々で研究されていたんですけれども、かなりオーバーラップする部分があるということで、合体して今進めています。

覚えている方もいるかと思うんですけれども、はじめはProof of Stakeの最初のステップとして今のProof of Workのチェーンにハイブリッドで入れるという話があったんですけど、これは上記の理由で中止になりました。

誰がやっているかというと、当然Ethereum Foundationが中心になってやっていて、仕様の策定の部分とかそういったリーダーシップのところをやっています。

実際の開発はFoundationではなくて10個ぐらいの企業が取り組んでいます。その中にはConsenSysとかParityのような本当に有名な大きなブロックチェーン界隈の会社もありますけれども、本当にこのEthereum 2.0のためだけに作られたようなスタートアップもいくつもあって、みんなで混じって研究開発をやっている感じです。

Ethereum 2.0のアーキテクチャ

それではさっそく、先ほどの3つの観点からEthereum 2.0のほうを見ていこうと思います。まず1個目はアーキテクチャから。

Ethereumのアーキテクチャは、Hub-and-spokeになっています。まずこの一番上の黄色いチェーン。「Eth1 Chain」とありますけれども、これが今のEthereumですね。今動いているEthereumのブロックチェーン。

そして、その下の部分がEthereum 2.0のブロックチェーンになります。この赤色のものが「Beacon Chain」というもので、図は省略してますけれども、この下のたくさんあるのが「Shard Chain」です。

注意しないといけないのは、もうすでにこの図からわかるとおり、Ethereum 2.0のチェーンは別チェーンであると。なので、ハードフォークでEthereumの今のやつをアップグレードしようというよりかは、先に別々で作っておくというのがEthereum 2.0のアップグレードの仕方になります。

一つひとつ見ていくと、これが現行のEth1 Chainですよということ。じゃあどうやってEthereum 2.0の世界に行くかというと、Ethereum 2.0が始まるタイミングで、まだないんですけれども、デポジットコントラクトというものがデプロイされる予定です。

ここにEtherをデポジットすることによって、そのイベントをこちらで検知して、Ethereumのほうで同額のEtherが発行されて、というかたちで移動できるというふうになっています。

続きましてBeacon chain。これが一番大事な部分で、全体を管理するオーケストレーションするブロックチェーンです。

管理するといって何をするかというと、一番大事なのがこのバリデーターセットの管理です。どのバリデーターがどこを見るかを管理するのがBeacon chain。それから、後ほど紹介するクロスシャードトランザクションに関しても重要な役割を果たしているのがBeacon chainです。

そして最後にShard chain。これが実際にユーザーが使うチェーンになります。イメージとしては、今触っているようなコントラクト・アカウントみたいなものはこのShard chainのほうに置かれます。

「いくつあるんだ？」ということなんですけれども、最初は64のShard chainからスタートします。ここから徐々に増やしていきます。

シャードセキュリティ

それでは、2つ目。シャードセキュリティにいこうと思います。ちょっと復習ですけれども、シャードセキュリティというのは、ブロックチェーンを単純にN個に分けてしまうとセキュリティがN分の1になってしまうので、これをなんとかして解決する方法が必要です。

具体例としては、例えば100個のシャードに分割するとしたときに、仮に攻撃者が全体の0.5パーセントしかstakeを持っていなくても、それが全部1個のシャードに集中してしまうと、そのシャードの過半数を取れてしまうので、セキュリティが非常に下がると。

これをどうするかということなのですが、まず一番ベーシックな防御から紹介します。この図にあるとおり、バリデーターの定期的なシャッフルというのがシャーディングにおける、シャードセキュリティの一番ベーシックなセキュリティになります。

Ethereum 2.0の場合は、まずBeacon chainで定期的に乱数を生成します。その乱数に基づいてどのバリデーターがどこを見るかという割当をシャッフルします。これはEthereum 2.0だけではなくてほかのシャーディングの研究でも使われている、非常に一般的なアプローチです。

この図で説明すると、この赤いのがアタッカーだとして、この緑が正直なものだとします。当然この赤いのが1個のシャードに集まってしまうと、もうそのシャードは壊れてしまうわけですが、ランダムにやると、当然この全体の比率からはズレるものの、統計的にある程度この赤の割合のばらつきが抑えられると。

なので、この標本の数を工夫すると、シャードがアタッカーに全部支配される可能性が無視できるまでに小さくできる。これが基本的なシャッフルによるセキュリティの担保の仕方になっています。

これはどういう仮定に基づいているかというと、アタッカーが誰か変わらない、Static Adversaryという仮定に基づいています。つまり、もしこのアタッカーがこのシャッフルの間隔よりも早く特定のシャードをターゲットできると、当然そのシャードは壊れてしまいます。こういうのを暗号の世界ではAdaptive adversaryと呼びます。

このAdaptive adversaryという仮定が現実ではどういうふうに現れるかというと、例えばBribing（賄賂）ですね。シャードがシャッフルされたあとに、特定のシャードのバリデーターに、「秘密鍵をくれたらいくらあげますよ」というふうにスマート・コントラクトによって賄賂を渡すと……。

そうすると、利潤を最大化しようとするバリデーターは、はじめからその賄賂というオプションを意識していて、そういったプログラムを持っていて、その秘密鍵を渡してしまうかもしれない。そうすると、シャッフルしたところで、本当に短い時間でアタッカーが特定のシャードをターゲットしてしまいますので、そのシャードはセキュリティが壊れてしまうことになります。

当然これはあり得る仮定なので、先ほどのシャッフルという基本的な防御に加えて、いくつかいろんなシャーディングの研究では、これを防ぐ方法を考えています。

このへんから少しEthereum 2.0とかほかのシャーディングのプロトコルとで分かれてくる部分になるのですが、Ethereum 2.0に関しては、Fraud proofとData availability checkという2つによって担保しています。

ここは非常におもしろい部分ではあるんですけれども、始めてしまうとこれだけで半日ぐらいいってしまいますので、いったんここでは2行で紹介しています。

Fraud proofというのが、不正な状態遷移、無からお金を作るとかあったことをなくすといったものを「これは違うでしょう」と証明をして、そのブロックを無効化するアプローチ。

もう1個は、このFraud Proofのベースになっている「おかしいですよね？」という証拠が作られるためには、おかしいブロックのデータをみんなが見える状態じゃないといけないと……。つまりデータがavailableじゃないといけない。というわけで、データがavailableかどうかを事前にチェックする必要がある。これがData Availability Checkです。

このように、まず基本的にシャッフルによって各シャードにアタッカーが集中することを防ぎ、万が一集中してもこういった暗号のちょっとしたテクニックを使って復旧するのが、シャーディングのセキュリティになっています。

ここでよくある質問として「じゃあBeacon chainはどうなんですか？」というのがあります。各シャードのセキュリティはわかったけれども、当然Beacon chainは全体を管理しているので非常に大事ですので「これが攻撃されたらどうなるんだ？」と質問がでてきます。

ここは、Beacon chainは全バリデーターによって守られているというふうになっています。すなわち、各バリデーターはShard chainだけ見るのではなくて、同時にBeacon chainを見ます。もっと言うと、Beacon chainのコンセンサスの投票とShard chainのコンセンサスがまったく同じ、1回投票すると両方になるという、ちょっと合体されてるってテクニックが使われています。

これによってBeacon chainのセキュリティは全バリデーターと同じですので、シャーディングの特有のセキュリティが下がる問題はありません。これはかなりEthereum 2.0のベーシックになっている発想で、非常に賢いアプローチかなと思います。

クロスシャードトランザクション

では、最後にクロスシャードトランザクションのほうに移ります。先ほど申し上げたとおり、データ層とアプリケーション層の2つに分かれているんですけれども、はじめのデータ層に関しては、Ethereum 2.0はMerkle Treeベースの方法を使っています。

右の図からいくとわかりやすいと思うんですけれども、先ほどの図の下部分を拡大していますが、各シャードはState rootを持っています。

これは今のブロックチェーンのState rootと同じで、状態遷移していったときにそのStateのMerkle Treeのルートだけをブロックヘッダーに書いてあります。この図でいうとこの四角いのが今で言うところのアカウントですが、それが全部暗号的に小さい、32バイトのデータにコミットされています。

このState rootがBeacon chainにも書かれています。さっきもあったとおり、Beacon chainのバリデーターとShard chainのバリデーターって基本的に同じですから、これができます。

さらに逆に、このBeacon chainのState rootというのがシャードに書かれています。これによって何が起こるかというと、各シャードはほかのシャードのState rootをBeacon chainのState rootを介して知っている状態になります。

なので、左の図を見ていただいて、あるシャードで何が起きたか証明したい人は、そのシャードにおけるMerkle Proof、それからBeacon chainのState rootのMerkle Proofを使うことによって、ほかの任意のシャードでイベントを証明できます。

ある意味では、あるシャードはほかの全部のシャードのLight clientと同じ機能を持っていると言えます。これによってデータがやりとりできるのがEthereum 2.0のアプローチです。

注意点は、このMerkle proofのやりとりはユーザーが行なうものです。ユーザーが自分でほかのシャードとやりとりしたいときに、自分でMerkle proofを提出する必要があります。なんでかというと、これを例えばBeacon chainとかでやってしまうと、Beacon chainが全部のシャードを見ることになるので、スケーラビリティがそもそもできなくなってしまいます。

このデータ層、データをやりとりするプロトコルに則ってアプリケーション層でいろいろなシャーディングトランザクションというのを踏んでいきます。

Yankingを使ってシャードをまたぐコミットの問題を解決する

シャーディングのクロスシャードトランザクションを説明するときにいくつかわかりやすい例があるのですが、非常に有名で使われるのが「Hotel-And-Train Problem」というんですけれども。

「旅行に行きたい」ですと、電車のチケットとホテルの部屋の予約をする必要があるのですが、その電車のチケットのコントラクトとホテルの部屋のコントラクトが別のシャードにあると、今のブロックチェーンみたいに簡単に2個同時に予約ができないので、電車だけ取れてホテルが取れないとか、そのまた逆があると。

これをどう防ぐかというのがよくあるクロスシャードトランザクションの問題です。もっと広く言うと、クロスシャードアトミックコミットですけれども。

Ethereum以外の研究だとよく使われるのが、昔ながらの分散DBの2 Phase Commitとか2 Phase Lockに近いもので、ホテルも電車も両方とも仮予約して、両方とも仮予約できたら本予約するというアプローチです。

これは悪くはないんですが、問題は普通の分散DBというのは普通にサーバで閉じているので、仮予約・仮予約→予約・予約でいいんですけれども、パブリックチェーンの場合はそれをユーザーにやらせてしまうので、仮予約だけして実際に予約をしないとかっていう攻撃って誰でもできる。こういう環境の違いが、ちょっと問題になっています。

なので、仮予約したら一定時間以内までに必ず本予約をするとかキャンセルをするとかっていういろんな制約をつけられるんですけれども、そうすると、両方コミットできるという性質が両方のシャードの時間的な同期性に依存してしまったりとか、あとは、そもそも仮予約の時間を定めたところで嫌がらせ攻撃というのは別にそこまで変わりません。そこでEthereumのほうで考えられているのがこのYankingというアプローチです。

YankingのYankは英語で「ぐっと引っ張る」みたいな意味なんですけど、「あるコントラクトを削除して、そのコピーを別のシャードに移す」のがYankingです。

どうやってこれでHotel-And-Train Problemを解決するかというと、ここの図にあるように、例えばホテルの部屋を「ホテルの部屋コントラクト」にするんじゃなくて、ホテルの部屋ごとにアイテムっぽく分けていきます。

電車のチケットがあるところにこのホテルの部屋のコントラクトをYankingでぐいっと持っていって、そうすると、もうクロスシャードというか、もはや普通の1個のブロックチェーン上のアトミック予約ですので、簡単にできるというのがYankingのアプローチです。要するに、任意のクロスシャードアトミックコミットを1個のチェーン上のアトミックコミットに帰着するアプローチです。

ほかにもいろいろな方法はあるんですけれども、いったんこれがEthereumのほうではデフォルトのアプローチとして使われることになるかと思います。

Ethereum 2.0のロードマップ

まとめと補足です。

EthereumではアーキテクチャとしてHub-and-spoke。HubがBeacon Chain、SpokeとしてたくさんのShard chainがとられています。

シャードセキュリティとしては、基本的な防御としての定期的なシャッフルに加えて、万が一特定のシャードにアタックされたときのためのFraud proof、それからData availability checkといったものがとられています。

それからクロスシャードトランザクション。Merkle Proofを使ってデータをやりとりするのと、そのデータのやりとりを使って2 Phase Commitっぽいものとか、Yankingといったものを使ってクロスシャードトランザクションを行ないます。

……というのがEthereum 2.0になります。

Ethereum 2.0の非常によくある質問の1つが「いつできるんですか？」というものなんですけれども、ここに一応ロードマップを書いています。

そもそも2.0は細かくフェーズに分かれています。Proof of Stakeもシャーディングもあまりに大きな変更ですので、一気にわーってやってしまうととんでもないことになってしまいますから、段階を踏んでやっていこうということです。

1個目がPhase 0。Beacon Chainのみ。さっきの一番偉いリーダーとなるBeacon Chainだけをデプロイするというものです。当然Shard Chainがないので何もぜんぜん便利じゃない。なので、どっちかというとPhase 0は半分テスト・半分本番みたいな意味合いが強いものです。

こちらはもうほぼ終わっていると僕は認識していて、specも終わっていますし、実装もいろんなスタートアップが取り組んでもう完了しています。さらにいろんなチームが作ったクライアントをまたぐ通信とかそういったものも行なうというテストも始まっています。

Beacon Chainに関しては、昔から言われてたんですけれども、今年中にはできるかなと思います。最初は、Ether、transferすらできないというだけなので、本当に1.0の中でもいろんなステップがあるのですが、そういう感じで進んでいく。

次のPhase 1で、Shard Chainがいよいよできるところですが、はじめはData Chainといってデータを記録するだけのブロックチェーンになります。コントラクトがない。EVMみたいなものもがないし、送金とかも最初はできるのかな？　とりあえずコントラクトというのがなくて、データをただ書くだけのブロックチェーンになります。

何に便利かというと、Ethereum界隈をフォローしている方だったら去年はもう耳がタコになるほど聞いたと思うんですけど、Rollupと呼ばれているLayer 2系のスケーラビリティソリューションに使えると。

PlasmaとかState channelと違ってRollupは基本的にトランザクションは全部オンチェーンに置くんですけれども、その検証をサボることによってスケールするというのがLayer 2になっているので、データだけ置けるだけでも非常に便利です。

なので、Ethereum 2.0のほうにデータを置いて、今のブロックチェーンで実際のRollupの状態遷移を行なうことによってスケールするというのがPhase 1の使いみちになっています。

Phase 2でいよいよ今でいうスマートコントラクトというのが使用可能になります。EVMではなくて、昔からeWASMという名前で開発されているWebAssemblyベースのVirtual Machineが導入される予定になっています。

Phase 2以降もまだまだいろいろな改善提案はあって、まず量子耐性をもたらすとか、あとはコンセンサスアルゴリズムを先ほど僕が紹介したCBC Casperに変えるですとか、STARKsをもっとやりやすくするとか、いろいろな理想のブロックチェーンに向かった提案があるんですけれども、それは全部Phase 2以降でやられるかたちになっています。

Ethereum 2.0の研究動向

では、残りたぶん15分ぐらいだと思いますので、最後にシャーディングの研究動向を話して、それからQ&Aに移ろうと思います。

Ethereum 2.0の研究動向とアカデミアのほうとで分けて話そうかなと思うのですが、Ethereum Foundationの理解としては、我々はProof of Stakeとかシャーディングという基礎はもう作った認識があります。ですので、今ホットなトピックは、その基礎の上でEthereum 2.0特有のアップグレードのところで、非常にホットに近年開発されています。

1つ目がExecution Environmentで、先ほどのフェーズでいうとPhase 2に導入されるんですけれども、ひと言でいうと、今のEVM的なものをものすごく抽象化するタイプの研究の方針です。

今のEVMだと、例えばアカウントとコントラクトがもうプロトコルの中で決まっていて、それによってちょっといろいろやりにくいところがあったりとか、あとGASもプロトコルの中でありますし、EVMのOPCODEのセットというのも、一応Virtual Machineではあるもののかなり高級な命令が入ったりとかする。

そういったものを一切取っ払って、まぁ言ってみれば、今のEVMみたいなものさえもデプロイできる、今のEVMが今でいうコントラクトのようになるぐらいキャパシティの広いLayer 1にしようというのがExecution Environmentです。

これは非常に難しくて。とくにGASとかをどう定義するかとか、いろいろな研究の難しい部分があって、これもホットに開発が進んでいます。これがうまくいけば本当に薄いLayer 1になるので、暗号系のプロトコルとかは非常に追加しやすくなるんじゃないかなと思います。

2個目がStateless client。これはEthereum 2.0に限らずずっと言われていたもので、Ethereumというのは非常にステートがどんどん肥大化していって、フルノードとかシンクするのにものすごい時間がかかります。こういった問題を当然重く見ていて、そのアプローチとして挙がっているのがこのStateless clientというものです。

Statelessと言っている……まぁStateless clientというよりはStateless block validationとかそういったものが近いと思うんですけど、コンセンサスノード、バリデーターがステートを持たなくてもブロックの検証ができるようになるのがこのアプローチです。

そのほかいろいろあるんですけれども、例えばさっき話したYankingとか2 Phase Lockというのはいわゆる非同期クロスシャードトランザクションと言われていて、今の1個のブロックチェーンみたいに、callをしたときにそのcallの結果が1個のトランザクションの中で返ってくるというようなことはできない。1回Yankしたりとか1回Lockする必要があるので、なにかトランザクションを投げる必要があります。

これをクロスシャードでもやろうみたいなものすごく野心的な研究もあって、当然ちょっと仮定を変える必要があるんですけれども、これも研究テーマのうちの1つになっています。

それから署名集約とかPeer to Peerのプロトコル。これは最近auditがあったのかな！？　Phase 0の監査のレポートが上がったんですけれども、やっぱりもともとEthereumは、Peer to Peerのところはわりと雑で、ここの部分のセキュリティですとか効率化は今後も研究テーマになるかなと思います。

アカデミアにおける動向

アカデミアのシャーディングにおける研究動向です。ひと言でいうと、2018年のセキュリティ系トップカンファレンスに通った3本ぐらいの論文は、UTXO型で基本的に送金＋αぐらいしかできなくてベーシックなシャーディングだったんですけど、どんどん研究の切り口が広がっているのが今の流れになるかなと思います。

1個目がMonoxideというやつで、これもわりと大きなカンファレンスですけれども、アカウント型のシャーディングです。

それから、これシステム系のトップカンファレンスに挙がったのですが、「Towards Scaling Blockchain Systems via Sharding」。こちらはパーミッション型向けのシャーディングの提案です。今までのEthereum 2.0は当然パブリックチェーン向けなんですけど、パーミッション型向けのものでIntel SGXを使っています。

それから、こういったシャーディングの提案だけではなくて、アカデミアなので、だんだんいろんな提案が出てくると、それをまとめて定式化しようとか抽象化しようとか、その抽象化したところで理論的な限界とかを調べていこうという流れが出るんですけれども、シャーディングもその動きがあって、「Divide and Scale: Formalization of Distributed Ledger Sharding Protocols」という論文が、今まで出てきたシャーディングの提案を少しまとめて形式化をして、理論的にスケーラビリティとかを解析していこうというようなことをやっています。

若干これはまだちょっとファーストステップかなという感じがあるのですが、今後もこういう論文は出るかなと思います。

本当にいろいろあるんですけれども、ここで紹介しているのは、さっき話したData availability check、これの効率的な方法とかを提案している論文もあったりします。これは今年僕が参加したFCで出ていた論文だったりします。