シャーディングなしでパフォーマンスを 10 倍に拡張できますか? Ethereum Turbo-Gethクライアントの簡単な紹介

Turbo-Geth は、2017 年に純粋に好奇心から始まったプロジェクトです (そう、CryptoKitties によって引き起こされた混雑の狂乱期間中です)。それはトライベースのデータベース スキーマの代替案の調査として始まりました。 2018 年 3 月、Turbo-Geth プロジェクトは Ethereum Foundation から小額の助成金 (25,000 ドル) を受け取りました。 2019 年の第 1 四半期と第 2 四半期には、Turbo-Geth が州家賃調査の州分析プラットフォームとして使用されました。 2019 年の第 3 四半期と第 4 四半期には、Turbo-Geth を使用してステートレス Ethereum のバックテストも実行されました。 Devcon5 が開催される頃には、概念的にはしっかりしていると思いました。

Devcon5 では、すべての実装が同様のデータ モデルに移行できるように、EIP の受け入れを 1 年間停止することを提案しました。しかし、誰もが懐疑的で、「コア開発者」グループが熱心ではなかったため、私の提案は採用されませんでした。

懐疑論は主に、状態ルートハッシュを効率的に計算および更新する方法に関するものです。 2020 年 3 月の EthCC 2020 カンファレンスで、私たちは「中間ハッシュ」と呼ばれる追加のデータ構造という解決策を提案しました。その後数か月かけて、私たちはこのソリューションを完全に実装しました。

段階的同期のアイデアは、テーブルごとの書き込みチャーンの測定を観察することから生まれました。データ チャーンの解決策は、事前に順序付けられたシーケンスでデータを挿入することです。私たちは 2019 年後半にこれらの現象を注意深く観察しましたが、最初の実験的な実装で大幅なパフォーマンスの向上が示されたのは 2020 年 2 月になってからでした。

段階的な同期は、アーキテクチャレベルでは非常に重要な変更でしたが（データモデルに大きな変更はありません）、2020 年 3 月から 7 月にかけてこの機能を実装しました。これにより、同期時間を大幅に（10 分の 1）短縮できます。

2020 年 8 月、状態表現データを 50 GB から 10 GB に削減する方法を見つけました。

2020 年 9 月には、「中間ハッシュ値」機能の粒度がさらに向上し、状態ルートハッシュの計算速度が 4 倍 (200 ミリ秒から 50 ミリ秒) 向上し、データ サイズが 7 GB から 2.5 GB に削減されました。

現在、ログの適切なインデックス作成を開発中です。

それで、これは何を意味するのでしょうか?

実際のところ、現在の実装はまだ効率の限界に達していないため、これは何の意味もありません。

まだ「未解決の謎」がいくつかあります。

1. 遠い過去の状態に対するマークル証明は効率的に生成できない（最近の履歴に対するマークル証明の生成効率には問題がない。これは中間ハッシュ値のスナップショットを導入することで緩和できる（これらのデータは比較的小さい）

2. 一部のコンセンサス計算は段階的な同期ではうまく機能しないため、理想的には、この 2 つを一緒に設計する必要があります。

カイコ

Apache 2.0 プロトコルの下で C++ で記述されたモジュール式 Ethereum 実装を作成するというアイデアは、"Aleth" プロジェクトが大部分放棄されたことがわかった 2019 年の初めに始まりました。

しかし、それは良い時期ではありませんでした。

2020年5月から6月にかけて、ついにその時が来ました。大きな転機は4つありました。

1. Turbo-Geth と Silkworm 間のデータベース互換性を確保するために、BoltDB から LMDB (C で実装されたデータベース) に切り替えました。

2. 段階的な同期パターンは、実装を比較的独立したコンポーネントに自然に分割します。これらのコンポーネントは、基本的にデータベース内のレコードを介して (または、データベース トランザクション内で対話が発生する場合はメモリ内のページを介して) 対話します。つまり、C++ 実装をコンポーネントごとに作成できるということです。

3. EVM (EVMC インターフェイスを使用) の以前の実験では、クロス言語インターフェイスの使用による大きなオーバーヘッドが明らかになりましたが、これは EVMC のデュアル インターフェイスによってさらに悪化しました。

4. 私たちは、専門家の協力を得て、予見可能な期間（5～10 年ではなく 1 年以内）でこれを達成できるだけの経験が十分にあると考えています。

未来

Silkworm プロジェクトを開始したことで、私たちの視野も広がりました。たとえば、実装を少しずつ他のプログラミング言語 (Rust など) に移行できるようになりました。

Ethereum 1.0 では、シャーディングを導入しなくても、スループットを少なくとも 10 倍に拡張できると考えています。私たちは3つの主な課題に直面しています。

1. ブロックのガス制限が高くなると、DOS 攻撃を受けやすくなります。 Turbe-geth のセキュリティ マージンは、おそらく他の実装よりも 10 倍高くなります。おそらく、カイコの場合はさらに高いでしょう。

2. ガス制限を高くすると、より大きなブロックが生成されます。これにより、次の 2 つの問題が発生します。

• ブロック転送の問題。これは事前コンセンサスを通じて処理できます（基本的にトランザクションのスループットと引き換えにトランザクションのレイテンシを犠牲にします）

• ダウンロードとストレージの問題をブロックします。これは、BitTorrent などの特殊なストレージ ネットワークを使用することで解決できます (このような作業はすでに進行中です)。

この記事へのリンク: https://www.8btc.com/article/649566
転載の際は出典を明記してください