Ethereumコア開発者はより頻繁なハードフォークの利点を議論します
コンセンサスを変えるにはどれくらいの頻度で行き過ぎますか？
ethereumのベテランオープンソース開発者たちのグループは金曜日に隔週の会議でこの問題を議論し、そこでハードウェアとも呼ばれるシステム全体のアップグレードが3ヶ月ごとに制定される可能性を放った 。
「温度をチェックする」ことを望んで、質問をしている開発者は、 状態賃貸料のようなある種の今後のethereum改善提案（EIP）が完全な効果のために順次間隔をあけられた複数のアップグレードを必要とするだろうと説明しました。
しかし、ベンチャーキャピタルスタジオConsensysのシニアソフトウェアエンジニアであるJoseph Delong氏の立場からは、3か月が過ぎると「ターンアラウンドのためには速すぎる」と言えます。
Ethereum財団PéterSzilágyiのチームリーダーは同意し、次のように説明しました。
「（ソフトウェアの）クライアント開発者として仕事をしているのがハードフォークを実装してそれを実行することだけであれば、3か月で結構ですが、通常クライアントは多くのメンテナンスを必要とします。それで、3か月のハードフォークを始めたならば、それは一般的なメンテナンスとパフォーマンス改善から本質的にずっと時間をかけます。」
Ethereum Foundationのセキュリティ担当Martin Martin Hoste Swendeは、3ヶ月ごとのハードフォークは「悪いことになるだろう」と同意しながら、単純な変更が一致する特定のケースでは実行時間が短くなる可能性があると述べました。
「3か月ごとにハードフォークをスケジュールするのではなく、機能Xが完成し、テストケースが存在し、それがすべてのクライアントに実装されているかどうかを確認するのが目的です。もしそうなら、それから私達はかなり早くハードフォークすることができます」と、コールの間にスウェンデは主張しました。
しかし、開発者が一度に自分の計画を「一歩」踏むことを奨励して、Parity TechnologiesのFredrik Harryson CTOは、計画されたethereumハードフォークのための6ヶ月というスケジュールさえ達成されたことがないと述べました。
「（より短いハードフォーク）を本当にうまくやるために自動化する必要があると思うことがいくつかあります。ハードフォークにかかる時間の多くは、コードを作成するだけではありません。ハリーソンは言った。
これに加えて、Ethereum FoundationのアドバイザーであるGreg Colvin氏は、ethereumソフトウェアクライアントを構築しているほとんどのチームが、「テストネットの設定、テストケースの実行、テストの実行」のようなハードフォークの実装に不可欠な仕事を処理する「正しい人」を現在持っていないと述べましたその他の責任
これに対して、Harrysonは、問題はそのようなチームメンバーに参加するのに十分な財政がないことであると答えた。 「私たちにとって、それはお金です。そのために十分な資金がありません」とハリソンは言いました。
多段階アップグレード
しかし、それはより頻繁なハードフォークがあるべきかどうかの問題だけではありません。
本日の通話中に、開発者たちは、ethereum 2.0への差し迫った動きに照らして、現在のethereumブロックチェーンに野心的で長期的な変更が必要かどうかについても話し合った。 。
Alexey Akhunovやethereumの創設者であるVitalik Buterinのような開発者は、「[現在のethereum]チェーンの存続のためではない変更」に対して警告していると示唆しています。
「[EIP 615]が長年にわたる改善をもたらし、それが大きな利益を得るまでに数年がかかるため、私たちはこれをどれだけ超えることになるのでしょうか。」
EIP 615は、イスタンブールと呼ばれる次のエーテルハードフォークに含めることを検討されている5つの提案のうちの1つです。これは、Ethereum Virtual Machine（EVM）として知られているethereumコードベースの中心部に改良を導入することを目的としています。
EVMは、相互運用性を構築するために、 Hyperledgerなどの他のエンタープライズブロックチェーンイニシアチブが過去に報告されてきた重要なテクノロジでもあります。
「EVMの設計は、低ガスコストで高性能の実行を困難にします。 EIP 615 Colvin、Brooklyn Zelenka、Pawel Bylic、Christina Reitwiessnerの著者は、次のように述べています。
しかし、Swendeが今日の電話で指摘したように、提案されているEIP 615は少なくとも2つのハードフォークを完全に実行することを要求し、EVMの実際のコード計算に対する「プラスのスピード効果」は後者のハードフォークが実行されるまでは目立ちません。
「それがこのEIPに関する私の主な関心事です。それは多くの作業ですが、それがはるかに優れたEVMにつながるとは思いません。 Swende氏は、スマート契約のセキュリティ特性をリバース分析している場合のように、外部ツールにとってはより良いかもしれません」と述べています。
Zelenkaが提案したそのようなツールは、「未確定のethereum 2.0のリリース日」を考慮して、eWASMのようなEVMのアップグレードとスマートコントラクト開発者のスムーズなオンボーディングエクスペリエンスを継続する「前方互換性」を確保するために不可欠です。
「スマート契約開発者には他にも選択肢があります。 Zelenka氏は本日の呼びかけで次のように述べています。
さらに数週間EIPについての議論と議論を続けることに同意して、Swendeは現在のところ「最終的に解決するまでに基本的に2、3のハードフォークを要する古いエンジンにそのような大きな変更を実装する」ことに懐疑的であると結論付けました。
しかし、野心的でマルチハードなフォークのアップグレードについて最初の質問をした、Harryonは、ethereum 2.0の将来についての不確実な意見に同意しました。
「我々はロードマップを調整したり、ethereum 2.0がどうであろうとなかろうとに基づいて考えるべきではありません。」
Shutterstockによるフォーク画像