12 時間のカウントダウン、イーサリアムプロトコル層の 7 年間の変更を振り返る

PANews

特邀专栏作者

2022-09-14 14:00

この記事は約4910文字で、全文を読むには約8分かかります

歴史を振り返ると、「世界コンピュータ」に向けたあらゆるステップが高密度のコードに記録されています。

原題:

原題:副題

イーサリアムとは

イーサリアムとは何ですか?千人いれば千通りの答えがあり、この記事で議論したいのは最も一貫した答え、つまりイーサリアムのプロトコルとは何かということです。または、より技術的な説明で、イーサリアムクライアント (PoW チェーン/ETH1) を開発したい場合、どのようなルールに従う必要がありますか?

最初のレベルのタイトル

概要

イーサリアムの以前のハードフォークを渡すことができますこのページチェック。 2015 年 7 月 30 日のリリース以来、39 の EIP を含む合計 14 のハードフォークが実行されました (「コンスタンティノープル」と「ピーターズバーグ」は同じものとみなされます)。最も近い 2 つのハードフォークは 26 日離れており、最も遠い 2 つのハードフォークは 490 日離れていました。

ハードフォークは「アクティブアップグレード」と「パッシブアップグレード」に分かれます。アクティブアップグレードは、イーサリアムプロトコルを修正する開発チームのイニシアチブを指しますが、パッシブアップグレードは、潜在的なセキュリティリスクに対処するために「実行する必要がある」アクションです。パッシブアップグレードには少なくとも「DAO Fork」、「Tangerine Whistle」、「Spurious Dragon」、「Muir Glacier」、「Arrow Glacier」、「Grey Glacier」が含まれており、これらはハッカーによる盗難（DAO Fork）に対処するか、 DDOS 攻撃 (タンジェリンホイッスル、スプリアスドラゴン)、または単純に難易度爆弾の処理 (ミュア氷河、アロー氷河、グレイ氷河)。「アクティブなアップグレード」は、（少なくとも名前の点では）白書の計画とほぼ一致しており、フロンティア（フロンティア、フロンティア解凍）、ホームステッド、メトロポリス（ビザンチウム、コンスタンティノープル/サンクトペテルブルク、イスタンブール）、ベルリンとロンドンイーサリアムのロードマップ変更後の移行アップグレード。さらに、いくつかのプロアクティブなアップグレードには、難易度ボムを延期するオプションも含まれていました。

副題

代表的なハードフォークの解釈

DAOフォーク

DAOフォーク

DAO フォークイベントは、イーサリアムの開発において最も広範なイベントです。 DAOのスマートコントラクトがハッキングされたため、約360万イーサがハッカーによって盗まれたが、28日間の凍結があった。この期間中、Carbonvote の助けを借りて、トークン所有者は自分の希望を表明し、イーサリアム財団は決める資金のこの部分は新しいスマートコントラクトに転送され、投資家が撤退できるようになります。このフォークによりイーサリアムクラシックが生み出され、多くの社会的議論も引き起こされました。

上海DOS

Devcon 2 の開催中、イーサリアムのコア開発者は上海に集まりましたが、イーサリアムネットワークは大量のネットワークトラフィックに見舞われました。攻撃、サービス拒否 (DOS) が発生します。 EXTCODESIZE オペレーションコードによって消費される実際のシステムリソースは、攻撃者が支払う必要があるトランザクション手数料よりもはるかに高いため、攻撃者はこのオペレーションコードを繰り返し呼び出し、ネットワーク全体のほとんどのノードが最新のブロックに追いつけなくなります。影響の少ないパリティクライアントを有効にするためにマイニングプールとフルノードを調整しながら、開発者はブロックガスを (5 M から 1.5 M に) 削減するように交渉しました。最終的に、Tangerine Whistle と Spurious Dragon の 2 つのハードフォークの助けを借りて、関連するオペコードの価格が調整され、DOS 攻撃の影響を軽減するために状態がクリーンアップされました。このハードフォークは、EIP-161 (Spurious Dragon に含まれる) の不適切な実装 (Go-ethereum と Parity がそれぞれ誤って実装した) により、追加の影響ももたらし、コンセンサスフォークとなりました。

二つの城の襲撃者

によると

によるとChainSecurityのレポート, EIP-1283 により、一部の契約にリエントリー攻撃のリスクが導入されます。 TrailOfBits が与えるより詳細な分析また、影響を受ける可能性のある契約のリストも提供します。ハードフォークがアクティブ化される 32 時間前に、イーサリアム財団はコンスタンティノープルのアップグレードを延期するためにノードにアップグレードまたはダウングレードするよう促す文書を発行し、その後、サンクトペテルブルクハードフォークを導入する新しいバージョンをリリースしました。

爆弾危機

ミュア氷河とイスタンブールの 2 つのハードフォークの間が 26 日しかない理由は、コア開発者がディフィシティボムの爆発時間を誤って計算し、その結果ディフィニションボムを遅らせる提案がイスタンブールに含まれないことになったためです。ディフィシティボムがネットワークに影響を与えようとしていることが判明したとき、第76回コア開発者会議EIP-2384 はすぐに受け入れられ、Muir Glacier ハードフォークに組み込まれました。

ハードフォークの意思決定プロセスの変更

ハードフォークはどのように決まるのでしょうか？実際、イーサリアムには長い間書面による文書が不足しており、「社会的合意」にもっと依存しています（私が間違っていたら修正してください）。 EIP-233 はフォークの正式なプロセスを形式化しようとしましたが、受け入れられませんでした。

この記事ではイーサリアムコミュニティにおけるハードフォークの決定プロセスについての議論を示すことはできませんが、イーサリアムのハードフォークの決定プロセスは明らかに変化しています。ベルリンのハードフォークの前に、開発者はまずハードフォークの時間を決定し、次にどの EIP を含めるかを決定し、それを実装してテストしました。ベルリン以前のすべてのハードフォークはメタ EIP です。たとえば、イスタンブールのハードフォークは通過します。EIP-1679定義 (HFM-1679 と呼ばれます)。

マルティン・ホルスト・スヴェンデ氏が発表EIP中心のハードフォークプロセス, 中心的な観点は、EIP の受け入れをハードフォークから分離することです。コア開発者は、単一の EIP の承認、実装、テストに焦点を当てます。単一の EIP が受け入れられると、後続のハードフォークはその EIP を含めることを選択できます。。ベルリンのハードフォークは非推奨ですが、このプロセスがイーサリアムコア開発者にどのように受け入れられたかは、この記事の執筆時点では判明していません。HFM-2070、しかし可決Martin が提案したプロセスに従いました。

意思決定プロセスの変更はすぐに反映され、ベルリンのハードフォークテストネットがアクティブ化される 2 週間前に、開発者は EIP-2315 の非推奨について激しい議論を交わし、最終的に EIP-2315 を削除しました。新しいプロセスの採用により、土壇場での変更はハードフォークに大きな影響を与えず、最終的には予定どおりに実行されました。詳細については、「」を参照してください。EIP-2315 の削除: イーサリアムベルリンのアップグレードに先立つ緊急ブレーキ》

変わらない変わる

調査報告書調査報告書。

EIPの詳細な分析

これらのEIPはイーサリアムにどのような影響を与えたのか、誰がイーサリアムの意思決定に影響を与えたのか。この記事では、イーサリアムハードフォークに含まれるすべての EIP (メタプロポーザルを除く) を整理します。詳細については、リンクを参照してください。

https://primitiveslane.notion.site/cbd45cf0289c414b86715b8a9e71b28e?v=838baf2ac3a442a6b3fa03e58c5dc0ae

EIP が行っていること

ハードフォークに含まれる EIP の種類には、主に、課金モデルの変更、新しいオペコードの導入、困難爆弾、経済モデル、プリコンパイル、セキュリティ上の考慮事項などが含まれます。

請求モデルの変更

課金モデル変更はEIP数としては10件と最も多く、25.6％を占めた。オペレーションコードの単価を増減することで、ガス消費量と実際のシステムリソースの不一致のバランスを調整します。これにより、システムが DOS によって攻撃されるという隠れた危険性を排除したり、特定の種類のアプリケーションの展開を容易にしたりできます。 DOS の隠れた危険の一部は、システムリソースの誤った評価によって引き起こされます。EIP-150 と EIP-160 はこの問題を解決します。一方、DOS の隠れた危険の別の部分は、システムの固有の特性です。状態データの増大に伴い、アクセス状態の実際のリソースも減少します。データ消費量もそれに応じて増加するため、対応するオペコードの単価を定期的に調整する必要があります。通常は EIP-1884 (私の意見では最もよく書かれた EIP の 1 つ) です。

イーサリアムの状態表現モデルのため、課金モデルは定期的に調整する必要がありますが、これは機能であり、不具合ではありません。

新しいオペコードの導入

合計 9 つの EIP がイーサリアム仮想マシン (EIP-1884 を除く) に新しいオペコードを導入し、23.08% を占めました。より影響力のあるものには、EIP-7 (DELEGATECALL)、EIP-1014(CREATE2)、EIP-3198(BASEFEE) などが含まれます。

難易度爆弾

合計 6 つの EIP がディフィシティボムを延期しており、15.4% を占めています。経済モデルの調整、つまり新規ブロック報酬の削減に伴うハードフォークが2回あります。これらのフォークのうち 3 つは、名前に Glacier が含まれるハードフォークであるディフィシティボムを遅らせるためだけに実装されました。ディフィシティボムの歴史については、を参照してください。経済モデル。

経済モデル

経済モデルに影響を与える EIP は 4 つあり、2 つは新しいブロックの報酬を削減し、1 つは難易度計算モデル (EIP-100) を調整し、さらに物議を醸した EIP-1559 は料金市場を調整しました。。

プリコンパイル済み

一部の暗号化操作をプリコンパイルするための 4 つの EIP があるため、操作効率を向上させるために EVM でそれらを実行する必要はありません。 EIP-152、EIP-196、EIP-197、EIP-198を含む。

セキュリティに関する考慮事項

他の

他の

その他の EIP には、ネットワークプロトコルの改善 (EIP-8)、トランザクション実行ステータスインターフェイスの追加 (EIP-658)、新しいトランザクションタイプの追加 (EIP-2718) などが含まれます。さらに、EIP-2 には Homestead のすべてのアップデートが含まれていますが、これはより複雑です。

EIP に貢献するのは誰ですか

これらの EIP の執筆には合計 43 名と 77 名が参加し、そのうち 11 名の著者が 2 つ以上の EIP (含む) に参加しました。最も多く執筆に参加したのはヴィタリック・ブテリンで、合計 17 件で 43.6% を占めました。マルティン・スウェンデとクリスチャン・ライトウィスナーはそれぞれ5回、アレックス・ベレグザッシとジェームズ・ハンコックはそれぞれ3回参加し、残りは2回しか参加しなかった。

Martin Swende はイーサリアム財団のセキュリティディレクター、Go-Ethereum エンジニア、EIP を中心としたハードフォークプロセスの提案者であり、Christian Reitwiessner は Solidity 言語の発明者です。

要約する

この記事では、イーサリアムの歴史におけるこれまでのハードフォークを紹介し、いくつかのハードフォークの背後にある代表的な出来事を解釈し、イーサリアムのハードフォーク意思決定プロセスがEIPを中心に変更したことを詳細に説明します。この記事では、以前のハードフォークで EIP が果たした役割とその背後にある貢献者についての詳細な分析も提供します。

イーサリアムが新たな時代を迎えようとしている今、過去が思い出されますが、読者の皆さんはどう感じますか?