イーサリアムの開発者Leo Glisic氏とGiulio Rebuffo氏は日曜日、既にネットワーク上にデプロイされているアプリケーションを保護するためのそれぞれ異なる戦略を示す対抗提案を提出した。両提案は、特定のスマートコントラクト操作に必要なガスを増加させるイーサリアム改善提案(EIP)-8037およびEIP-8038がもたらす潜在的な影響に対処するものである。この論争は、提案された価格変更を、イーサリアムの既存のガススケジュールを前提に設計されたコントラクトに干渉することなく導入できるかを開発者らが見極める中で、Glamsterdamにとって重大な問題となっている。

Glamsterdamのガス変更に互換性への懸念

論争の中心にあるのは、計画中のGlamsterdamアップグレードに含まれるEIP-8037とEIP-8038という、コントラクト作成コストとブロックチェーン保存データへのアクセスコストを変更する2つの提案である。ガスとは、トランザクションやスマートコントラクト命令の実行に必要な計算リソースを測るためにイーサリアムが使用する単位であり、ガス価格の変更はアプリケーションの動作に影響を与える可能性がある。特に、開発者が特定の実行制限を前提にコントラクトをプログラミングしている場合に顕著である。

Glamsterdamのようなイーサリアムのアップグレードは、複数のEIPをネットワークルールへの単一の調整済み変更としてまとめており、提案は通常、コア開発者によるレビュー、クライアント実装、テストネットでの検証を経てからアクティベーションの決定が行われる。今回の論争はそのプロセスの中で進行しており、異議が表面化しているのは、メインブロックチェーンに到達する前のテストネット評価の段階である。

EIP-8037では、スマートコントラクト作成の基本ガス料金が32,000から183,600ガスに引き上げられ、コード保存および実行に伴う追加コストは別途適用される。この引き上げは、一部の既存イーサリアムアプリケーションが、特定の操作が引き続き同じ量のガスを消費することを前提に開発されていたため、懸念を引き起こしている。

一部のコントラクトは、他のアプリケーションと対話する際に固定のガス許容量を割り当てている。その対話のコストが割り当て額を超えて増加した場合、操作が失敗する可能性がある。特にデプロイ後に変更できないスマートコントラクトにとってはリスクが高く、そのようなアプリケーションには改訂されたガススケジュールに適応する明確な手段がない場合がある。

セキュリティ研究者、広範なコントラクト障害を警告

この懸念はすでにGlamsterdamのテスト日程に影響を与えている。アップグレードはイーサリアムのテストネットワークにデプロイ済みだが、10月26日に予定されていた2回目のテスト演習は、セキュリティ研究者からの警告を受けて延期された。イーサリアムのテストネットワークは、アプリケーションやトランザクションに実際の資産が関わるメインブロックチェーンに導入する前に、開発者がプロトコル変更を評価することを可能にする。ガススケジュールは過去のイーサリアムアップグレードでも改訂されており、そのため再価格設定提案は古いコスト前提で書かれたコントラクトとの照合が定期的に行われている。

セキュリティ研究者のpcaversaccio氏は、提案されたガス調整を公に批判し、Glamsterdamは現状の形で進めるべきではないと主張した。

"imho Glamsterdam should not be shipped in its current form, period,"(個人的には、Glamsterdamは現状の形で出荷されるべきではない、断言して)とpcaversaccio氏はXに書いた。

同研究者は、この懸念が2週間前にイーサリアムのコア開発者に提起されていたと述べた。

匿名開発者のbanteg氏も、既存の互換性評価の範囲に疑問を呈し、ethereum/repricing-impactリポジトリにある約20万件の潜在的影響コントラクトのリストを指摘した。banteg氏によれば、評価における方法論的な限界により、既存のリストが示すよりも大幅に多くのコントラクトが影響を受けている可能性があるという。同氏はさらに、提案された変更が、あまり広く使われていないアプリケーションだけでなく、いくつかの主要なイーサリアムプロトコルのデプロイと運用に干渉する可能性があると警告した。

これらの警告により、ネットワーク上で既に稼働しているコントラクトの機能を維持しながらガス再価格設定をどう実装するか、イーサリアム開発者の意向への注視が強まっている。

EIP-8488、既存と新規コントラクトに別個のガスルールを提案

Glisic氏の提案であるEIP-8488は、アップグレード前にデプロイされたスマートコントラクトと、その後に作成されるコントラクトを区別する互換性メカニズムを導入するものである。このアプローチでは、既存のコントラクトはイーサリアムの現在のガス価格ルールで引き続き動作し、新しくデプロイされるコントラクトは、EIP-8037とEIP-8038が導入する高いガスコストを反映した改訂版の命令セットを使用する。

この提案は、イーサリアムの命令セットを実質的に2つのバージョンに分割し、古いアプリケーションが確立済みの実行コストを維持できる一方で、新しいアプリケーションには更新された価格構造に従うことを求めるものである。

"Existing contracts keep the legacy schedule,"(既存のコントラクトはレガシースケジュールを維持する)とEIP-8488の草案には記されている。

新規コントラクトは、改訂されたガススケジュールに関連付けられたV2オペコードを使用することが求められる。このアプローチは、アップグレードできないアプリケーションの互換性リスクを低減しつつ、将来のデプロイに向けた計画済みのガス価格変更をイーサリアムが導入できるようにすることを目的としている。

代替案、二重ガス計測を導入

Rebuffo氏は、トランザクション課金には新しいガス価格スケジュールを適用しつつ、古いスマートコントラクトの既存の実行動作を維持するという別のメカニズムを提案した。新旧のアプリケーション用に別個の命令セットを維持するのではなく、この設計は各トランザクション内に2つのガス計測メカニズムを導入する。1つ目のメーターは既存のガスルールに従ってコントラクト実行を追跡し、2つ目は更新された価格スケジュールを用いてトランザクション料金を計算する。

この構造では、新しいスケジュールがトランザクション手数料を決定するが、古いアプリケーションは以前のガスルールで確立された前提の下で引き続き実行される。この提案は、既存のスマートコントラクトが依存する実行条件から、トランザクションコストの計算を分離することを目指している。

ただし草案は、この設計が実装レベルでは未検証であることを認めている。

"no execution-client implementation or consensus tests have been run for this design,"(この設計に対して実行クライアントの実装やコンセンサステストは行われていない)と提案には記されている。

開発者、Glamsterdamのガス変更を巡る決断迫る

競合する2つの提案は、同じ互換性問題に対する異なるアプローチを浮き彫りにしている。Glisic氏のEIP-8488は、既にデプロイされたコントラクトの既存ガス価格を維持しつつ、新しい命令を通じて改訂版スケジュールを導入する。Rebuffo氏の代替案は、更新されたトランザクション課金を適用しつつ、レガシーな実行動作を維持する。いずれのアプローチも、計画されているガス再価格設定が、イーサリアムの既存の実行コストに依存するアプリケーションを混乱させるのを防ぐことを目指している。

影響を受けるコントラクトには、デプロイ済みコードを容易に変更できない確立されたプロトコルが含まれる可能性があるため、この問題は注目を集めている。セキュリティ警告を受けてテストが既に延期されている中、これらの提案は、Glamsterdamの互換性リスクを評価する開発者に有望な技術的解決策をもたらすものである。

議論を前進させるマイルストーンは具体的である。互換性メカニズムを備えた再日程のテストネット検証の実施、およびいずれかの草案が進む場合には、それを評価するための実行クライアント実装とコンセンサステストの結果である。これらのステップが実施されるまで、Glamsterdamが開発サイクルを進める中で互換性の問題は未解決のままである。

入手可能な情報からは、いずれの提案が採択されるかは明らかになっていない。Rebuffo氏の設計も実行クライアント実装やコンセンサステストの結果がなく、その技術的実現可能性は今後の評価に委ねられている。

出典:CoinDesk

初出:Hokanews