ReGenesis を使用してイーサリアム ネットワークを改善する方法を学ぶ
編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfans)編集者注: この記事は以下から引用しました
イーサリアム愛好家 (ID: ethfans)
イーサリアム愛好家 (ID: ethfans)
DeFi アプリケーションにロックされている資金の額は 15 億ドルを超えており、新しい dApp がほぼ毎日発表されています。このままではイーサリアムは成功しすぎて消滅するかもしれない。インフラストラクチャ層に関する限り、状態の無限の増大は大きな問題です。
数日前、Alexey は EthResearch フォーラムに記事を投稿し、ReGenesis と名付けた興味深いアイデアを提案しました。
このアイデアは比較的単純で、一見すると過激に見えるかもしれません。定期的に (たとえば、100 万ブロックごとに) ローカルに保存されているすべての状態を削除し、最新のブロックのルート ハッシュを保持し、さらに 100 万ブロック後に再び状態の構築を開始します。 、次のステータスリセットが実行されます。
画像の説明
-ReGenesis : N ブロックごとに状態をリセットします。状態が成長するにつれて、次の ReGenesis が開始されるまでに必要な証明は少なくなります -
このアイデアがなぜ実現可能であり、調査する価値があるのかを理解するには、背景と説明が必要です。
それがこの記事の内容です。
現在の状況
1. 一元的な状態ストレージ
イーサリアムでトランザクションを送信するのは非常に簡単で、状態データを自分で用意する必要はありません。トランザクション送信者には状態を保存するインセンティブがありません。
(マイナーまたは取引所) インフラストラクチャ ノードを実行している場合は、トランザクションの検証とブロードキャストに必要な状態がすべて揃っていることを確認する必要があります。あなたがマイナーの場合は、さらに多くの状態が必要です。
したがって、現在の状態のストレージは、大規模なエンティティ (Infura、大手マイナー、取引所など) によって運営されるインフラストラクチャ ノードに集中しています。
2. 状態は無限に成長し続ける
本稿執筆時点 (6 月 29 日) では、Turbo-Geth クライアントの「現在の状態」は約 40 GB であり、さらに増加しています。
ここでの問題は、状態のサイズ自体ではなく、状態が無制限に増大することです。もちろん、SSD の容量がブロックチェーンの状態よりも速く増加することを祈ることもできます。
これまでのところ私たちは幸運に恵まれていますが、運だけが長期的な解決策となるわけではありません。
3. ステートレスイーサリアムはガスの価格を再設定するのが難しい
ステートレスなイーサリアムプロジェクトの場合、価格設定ブロック監視は非常に困難です。これらの監視はマイナーによって生成されるため、トランザクション送信者がトランザクション送信時にブロック監視のサイズを予測することは困難です。
したがって、既存のスマートコントラクトに影響を与えることなく、スマートコントラクトの動作を通じて証人価格を推測する方法を見つける必要があります。
石油などの提案はすでにいくつかありますが、これは本当に難しい問題です。
ReGenesis 後にトランザクションを実行する方法
さて、現在の状態をすべてゼロにするには、ルート ハッシュのみが保持されることがわかりました。データ量は 40 GB から 32 バイトに削減されます。
このとき、ステートレスなイーサリアムが役に立ちます。トランザクションを実行できるようにするには、証人を提供する必要があります。証人には、使用されたアカウント、コードとコントラクトのストレージ コンテンツ、およびルート ハッシュの検証に使用できるマークル証明が含まれています (証人およびステートレス イーサリアムの詳細については、ここをクリックしてください)。
ただし、ReGenesis とステートレス イーサリアムの間には 1 つの違いがあります。違いを説明する前に、明示的状態と暗黙的状態という 2 つの用語を紹介します。
geth ノードを実行しているとします。ピアノードが新しいブロック N を送信するたびに、ノードはそのブロック内のすべてのトランザクションを検証するために必要な状態データをすでに持っており、ブロック N-1 を同期していると想定します。
- 現在のイーサリアム: 両方のノードが必要な状態をすべて備えていると仮定します -
これは 100% 暗黙的な状態です。ピアは、すでに状態を持っていると想定するため、ブロックに状態を追加しません。
ステートレス イーサリアムでは、ノードを実行すると、ピアノードは新しいブロック N を送信し、いかなる状況でも暗黙的な状態がないとみなします。ブロック N を実行するために必要なものがすべてブロック N に詰め込まれています。これはブロック証人です。
画像の説明
同僚はあなたに明示的なステータスを送信します。
ReGenesis がブロック 10.000.000 から始まるとしましょう。現在、ブロックチェーンの最上位はブロック 10.001.000 です。 ReGenesis ノードは、ブロック 10.000.000 とブロック 10.001.000 の間のすべてのデータの暗黙的な状態を持っていると考えることができます。これらのブロックで使用されるすべてのアカウント、すべてのストレージ エントリ、およびすべてのコントラクトはすでにすべてのノードに保存されているため、ブロック監視は必要ありません。これにより、準ステートレス同期の実験で見られたように、証人のサイズを大幅に削減できます。
画像の説明
- ReGenesis: ブロック 1 はノード 1 に欠けている情報を提供します -
画像の説明
- ReGenesis: ブロック 1 の状態をノード 1 の暗黙的な状態にマージします -
(トランザクション送信者として) 現在のブロック高さが 10.001.000 であるネットワークに新しいトランザクションを送信する必要がある場合は、次の手順を実行する必要があります。
必要なトランザクションを作成します。
暗黙的な状態に含まれないエントリの明示的な状態を作成し、トランザクション監視としてパッケージ化します (詳細は以下で説明します)。
それは正しい。
トランザクションを監視者とともにネットワークに送信します。
待ってください。これは、トランザクション送信側が ReGensis より前の状態を持っている必要があるということですか? ！
それは正しい。
ReGenesis の開始後にトランザクションを送信する場合は、証人を生成するために ReGenesis 前の状態情報が必要になる場合があります。
ただし、ほとんどの dApp では、実際に使用される少数の契約とアカウントの状態を保存する必要があります (もちろんマークル証明付き)。取引証人
上で取引証人という用語を述べたことにお気づきかもしれません。
画像の説明- 複合ブロック証人 -
画像の説明- 取引証人 -
画像の説明- ブロック証人はマイナーによって生成されます。複雑なガス価格設定メカニズムを通じてそれらを補償する必要があります -
取引証人には重要な利点があります。これらはトランザクション送信者によって生成され、トランザクションとともに送信されます。したがって、取引立会人の規模とその価格設定方法をすぐに知ることができます。 EVM を通じて価格を再設定する必要はありません。
画像の説明
- トランザクション証人はトランザクション送信者によって生成され、補償がはるかに簡単になります -
トランザクション監視を使用する場合の潜在的な落とし穴は、データの重複です。ブロック内のすべてのトランザクションが同じ 2 つのアカウントによって行われたと仮定すると、トランザクション監視には重複データが含まれます。
ブロック証人はマイナーによって生成されます。マイナーはブロック内のトランザクションの正確な順序を知っているため、ブロック監視には常に最新のデータが含まれています。
トランザクション証人はトランザクション送信者から取得されます。したがって、ブロック内の以前のトランザクションによって生成された暗黙的な状態とトランザクション監視をマージするスマート マージ メカニズムが必要です。
ただし、ReGenesis のコンセプト全体ではトランザクション証人の使用が必要であるため、それは大したことではありません。
最初のレベルのタイトル
まだ取引証人を使用できないのはなぜですか?
簡単に言うと、Dynamic State Access (DSA) と、悪意のある攻撃者によるフロントランニング トランザクションの潜在的なリスクが原因です。
具体的には、ステートレス イーサリアムでは、このトランザクションの完全な状態を提供する必要があり、受信者は状態を持たないと仮定します。トランザクションで DSA を使用する場合、コードがストレージのどの部分を読み取るかは、コードの他の部分の値によって異なります。
理論的には、これにより DoS 攻撃が引き起こされる可能性があります。
アリスが A を含む証明を提供した場合、ボブはアリスのトランザクションがパッケージ化される前に K を変更することができ、アリスのトランザクションは失敗します。アリスが B を含む証明を提供した場合、ボブはトリックを繰り返すことができます。
もちろん、Alice は A と B を含む証明を提供できますが、ストレージ アドレスが uint64 によって決定されている場合、Alice は攻撃を防ぐために完全な状態を証明に含める必要がありますが、完全な状態を含めることはまったく現実的ではありません。
もちろん、この攻撃は理論上のものです。ただし、同様の攻撃がさらに出現する可能性があります。 dApps が保有する資金が多額であることを考えると、何かを壊さないように細心の注意を払う必要があります。
最初のレベルのタイトル
ReGenesis はこの問題をどのように軽減しますか?
ReGenesis の決定論は、ノードがどの程度の状態を持っているかを判断するのに役立ちます。ノードが持っていると確信できる状態については、証明は必要ありません。
この問題を軽減するために、トランザクションが成功するか、状態が不十分であるために失敗するかに関係なく、提供する証拠が状態に含まれていることを確認します。
アリスのトランザクションは失敗しましたが、トランザクションはパス A に必要なすべての証明をノードの暗黙的な状態に追加しました。
結論は
これで、アリスはこのトランザクションを再送信して、パス B に必要な証明を提供できるようになります。ボブは K を変更することでアリスのトランザクションをブロックできなくなりました。トランザクションにパス A を選択させるために K を変更したとしても、手遅れになります。パス A に必要な証明はすでにノードの暗黙的な状態に含まれているため、トランザクションはブロックされません。任意の証明をノードに送信できます。トランザクションがパス B に向けられている場合、トランザクションには B が必要とする証明が正確に含まれています。
最初のレベルのタイトル
結論は
最後に、ReGenesis のビジョンと要点を簡単にまとめてみましょう。
N 個のブロックが生成されるたびに、すべての状態がクリアされ、ルート ハッシュのみが保持されます。
ReGenesis の起動頻度は高すぎてはいけません。100 万ブロックごと、1,000 万ブロックごとなどに設定できます。
トランザクション送信者は、(トランザクション監視として) 明示的な状態を提供する必要があります。
トランザクション送信者は、トランザクション証人の規模に基づいてガス料金を支払います。
これを行うには、トランザクション送信者は、関心のあるコントラクト/アカウントの ReGenesis 前の状態を保存する必要があります。
明示的な状態が不十分なためにトランザクションが失敗した場合、トランザクションによって提供された証明を暗黙的な状態に追加します。これにより、次回トランザクションを送信するときに同じ証明を提供する必要がなくなります。
トランザクション証明からの明示的な状態は、スマート マージ メカニズムを通じて、ブロック内で以前に実行されたトランザクションによって生成された暗黙的な状態とマージされます。
マクロの観点から見ると、ReGenesis ソリューションには次の利点があります。
トランザクション送信者とインフラストラクチャ ノードの間のインセンティブ バランスを変更し、それによって状態ストレージの分散化を改善します。
