ヴィタリック、イーサリアムのビーコン・実行クライアント分離の見直しを提案

ヴィタリックがクライアント分離アーキテクチャの見直しを提案
関連ニュース

ヴィタリックがクライアント分離アーキテクチャの見直しを提案

イーサリアム（Ethereum）の共同創業者であるヴィタリック・ブテリン（Vitalik Buterin）氏が、現在のビーコンクライアント（コンセンサスクライアント）と実行クライアントの分離構成について、見直しにオープンであるべきだと、自身のXで3月14日に提案した。同氏は、2つのデーモン（バックグラウンドで動作するプロセス）を実行してそれらを連携させることは、1つのデーモンを実行するよりもはるかに困難であり、ユーザーにとって不必要な複雑さを追加していると指摘している。

ブテリン氏は、「イーサリアムの目標は自己主権的な方法でイーサリアムを使用する際に優れたユーザーエクスペリエンス（UX）を提供することであり、多くの場合それは自身のノードを運用することを意味する」と語った。しかし現在のアプローチは不要な複雑さを追加しているという。

短期的な解決策としてブテリン氏は、任意のクライアントのドッカー（Docker）イメージを簡単に導入し、相互に連携させやすくする標準化された基本ラッパー（Wrapper）の必要性に言及している。また、イーサリアムクライアントのニンバス（Nimbus）による統合ノード（Unified Nimbus node）にも触れている。

長期的には、「リーンイーサリアム（Lean Ethereum）」のリーンコンセンサスがより成熟した段階で、アーキテクチャ全体を見直すことに対してオープンであるべきだと述べられている。

なおニンバスの統合ノードは、コンセンサス層と実行層を単一プロセスで動かす構成として説明されている。これにより、セットアップの簡素化、JWT不要化、煩雑な設定やクロスクライアント通信、タイミング問題の回避、共有データベースによる省容量化などが見込まれるという。

同統合ノードは、ウォレット／Web3バックエンド用途に加え、バリデーター用途でも利用できると説明されている。メインネット同期には合計約500GBの空き容量が必要で、コンセンサス側はチェックポイントから開始し、実行側はP2P経由で同期するとされている。

ブテリン氏の今回の提案は、イーサリアムのノード運用の簡素化とユーザーエクスペリエンスの向上を目指す問題提起とみられる。一方で、現在のイーサリアムではコンセンサスクライアントと実行クライアントを組み合わせる構成が標準であり、クライアント多様性も重視されている。

We should be open to revisiting whole beacon/execution client separation thing.

Running two daemons and getting them to talk to each other is far more difficult than running one daemon.

Our goal is to make the self-sovereign way of using ethereum have good UX. In many cases…
— vitalik.eth (@VitalikButerin) March 15, 2026