- イーサリアム 1.xの進捗状況
- イーサリアム・バーチャルマシンからeWASMへの移行が予定される「イーサリアム 1.x」の開発が加速している。2019年6月を予定している大型アップデートに向け、4つのチームが各種問題の解決を試みている。
イーサリアム 1.xの進捗状況について
以前報道したように、Ethereum 1.xという新たなアップグレードが計画されている。
このアップグレードは、ユーザビリティの向上を目的としたもので、現在、イーサリアム 1.xについてのリサーチ、開発スピードが加速している。
イーサリアム・バーチャルマシンからの移行が予定される”eWASM”は、イーサリアム仕様のウェブアセンブリで、移植性に優れ、容量や読み込み時間の効率性が優れているという特徴があるとされる。
ethereum 1.xのコードの変更点こそ現時点では決定していないが、2019年6月を予定しているアップデートに向けて、様々な意見交換がされている。
それら意見の中には、アップグレードする際に空のステートで、新たにチェーンを作成するといった提案まで存在する。
イーサリアムの設立者Vitalik氏は、「ethereum 2.0(セレニティ)」と呼ばれるアップグレードの内容と期日を変更し、実施日を遅らせている。変更内容は、それぞれ別々に導入予定であったシャーディングとキャスパー(PoSへの移行)を同じタイミングで導入するというものだ。
ただし、イーサリアム開発者らの間では、2020年までに「ethereum 2.0」を導入することは厳しいのではないかとの見方も広まっている。
それゆえ、近い将来に実行できる中道の案を何か考え、現在抱えているスケーラビリティなどの問題を少しでも解決する必要があるとの声が上がっていた。その中で生まれた案が「ethereum 1.x」だ。
開発陣に不協和音も
ethereum 1.xの提案は、突発的なものであり、一部で論争に発展した。Devcon4の開催時、ethereum 1.xに関しての議論が内密に行われたことから、一部では不快感を示すメンバーもいたという。
しかし現在は、「パブリック・フォーラム」も開設され、ethereum 1.xについて、開かれた議論が行われている。
Parityイーサリアム・クライアントのリリースマネジャーSchoedon氏も、（コミュニティの分裂を防ぐため）コミュニティのステークホルダー全体で「最終的に論争が巻き起こらないよう」全ての案を出し合い語り尽くすことが肝要だとしている。
同氏は、これからの議論は、チャタムハウスルール（会議参加者の行動規範）の下で、互いの意見を尊重しながら進められていくと方針を示していた。
そして先日、開発者の間で開かれた議論を促進するため、協定世界時(UTC)14:00に上述したルールのもとに会議が行われた。
ethereum 1.xの開発状況
Devcon4で行われた会議「meeting minutes」によれば、現在4つの異なったグループがethereum 1.xに取り組んでいるとのことだ。
そのうちの一つは、イーサリアムのコアデベロッパーであるAlexey Akhunov氏が率いるグループで、イーサリアム・プラットフォームへのストレージ・レントの導入へ向けて取り組んでいる。
ストレージ・レントは、今年の3月下旬頃から議論され始めたメカニズムである。
その議論が巻き上がった理由は、イーサリアム・プラットフォームの利用者が急増していることにある。
それに伴い、ノードが保存しなければならないデータ量も急激に増加し、課題となっており、イーサリアムネットワークに新規参入しづらいといった弊害も生み出している。
データ量が増えれば増えるほど、新規ユーザーがコピーしなければならないアクティブ・データが増えるために時間がより掛かり、データベースを圧迫するからだ。
そうした中、解決を試みようとイーサリアムの設立者Vitalik氏が、ブログにて「レント・フィー(賃借料)」の導入を提唱した。このコンセプトは、ブロックチェーン上に「アクセス可能な状態」で保存したいデータの期間に応じてレント・フィーを請求するというものだ。
一方で、こうしたデータをオフチェーンで管理するという手法も提案されている。
もう一つのチームも、このブロックチェーン・データの保存方法に関する問題の解決に向けて、この手法に取り組んでいる。「ステートレス・コントラクト」と呼ばれるこの手法は、「ストレージ・フィー」の導入よりも簡単であるとAkhunov氏は発言している。
残された課題
ただし、課題点も多く残されている。
もしこの手法が採用されれば、データ管理の責任が、dApps開発者により重くのしかかることになるからだ。
さらに、開発者がどのようにオフチェーンのデータを共有、アップデートするのかといった問題もある。
同氏は、以下のように言及した。
「ステートレス・コントラクト」には問題がある。
導入が簡単だと考える人も多いが、確かにプロトコルのアップデートという面ではより簡単である。
しかし、dApps開発者のサポートという面においては、かなり難しくなるだろう。
3つ目のグループ
第三のグループは、「シミュレーション・グループ」と呼ばれ、ブロックサイズを変更したときにブロックチェーン上に起こりうる問題を分析しており、以前行われたコードの最適化と深く関連している。
最適化を行ったことにより、ブロックの生成速度は向上した。
しかしその結果、イーサリアム・マイナーはより多くのトランザクションをブロックに加えなければならず、またより多くのトランザクション・フィーが求められる。
調査によれば、マイナーが報酬として得るトランザクション・フィーの最大値「ガス・リミット」が少なすぎるとの結果が出ている。
このことについて、同氏は以下のように述べた。
どのようにネットワーク上でブロックを生成するか、ガスリミットを上げるとどうなるのか、といった研究があまりにも少ない。
同チームは、ガスリミットを上げた際のテストも実施しており、これが現在抱えるスケーリング問題を解くカギとなるとしている。
上述した2つが、ethereum 1.xの大きな特徴となっている。
同氏はこう言及している。
我々はこれらの問題を別々ではなく、同時に解決したい。
それぞれ分けるのではなく、全体的に解決しなければならない。
常識にとらわれないアプローチ
4つ目のグループは、スマートコントラクトをデプロイする際にかかる「コストの削減」に取り組んでいる。
潜在的には、この取り組みがスマートコントラクトのデータ保存コスト削減につながる可能性もある。
スマートコントラクトのコードを実行する新たなバーチャルマシン「eWASM」を早期に導入することにより、イーサリアム開発者が新たな技術やプレコンパイルと呼ばれる機能をより簡単に利用することが可能となる。
プレコンパイルはスマートコントラクトを動作させる際によく利用され、最適化することにより、イーサリアムのプラットフォーム上で固定された手数料やガス代でネイティブに運用することができる。/p>
Akhunov氏曰く、イーサリアムネット上には、そのような機能はほとんどないとのことだが、その機能の需要は大変高い。
もし多くの人が求めるプレコンパイルの機能をすべて実装しようとすれば、それ以外の作業は何もできなくなる。
プレコンパイルを開発する際の大きなハードルの一つは、スマートコントラクトを利用する際の、公正なガスコストがいくらであるべきかを決定することだ。
通常であれば、開発者がプレコンパイルを実行する際にかかるエネルギーや時間をもとに定義をする。ただ、eWASMのエンジンではそれら価格決定の処理が自動で行われる。
Akhunov氏の発言は以下の通りだ。
eWasmエンジンは、「メータリング」と呼ばれる機能を備える。
「メータリング」により、消費されるガスの量によって、適切な費用が自動で調節・請求される。
長期的な目標は、同時にプレコンパイルをする必要性を取り払うことだとしている。
その他の利点としては、eWASMエンジンを導入することにより、スマートコントラクトをネイティブネットワークと同じ速さで効率よく動作させることができることが挙げられる。
パリティ開発者Afri Schoedon氏が「常識にとらわれない」ソリューションと評する、これら提案を用いてイーサリアムネットワークを維持していくことを計画している。
これらソリューションに関するプロジェクトはすさまじい速さで進行しているものの、広い合意がコミュニティ内で得られない限り、アップデートは行わないと同氏は語った。
これまでのアップデート状況
- オリンピック (2015年5月に実施)
- フロンティア (2015年7月30日に実施)
- ホームステッド (2015年3月14日に実施)
- メタロポリス (2つの段階に分けられ、一つ目が実施済み)
- 1)ビザンティウム (2017年10月16日に実施)
- ethereum 1.x (2019年6月実施予定)
- 2)コンスタンティノープル (延期中 ethereum 1.x実施後に実施予定)
- セレニティ (2020年以内の実施は厳しいとの声が多く見られる)
