【ITニュース解説】Gas Optimization Audit: Sentora Curator

ニュース記事「Gas Optimization Audit: Sentora Curator」は、Sentora CuratorというDeFi（分散型金融）プラットフォームの「ガス最適化監査」の結果をまとめたものだ。システムエンジニアを目指す皆さんにとって、これはスマートコントラクトの開発と運用において、いかに効率的でコストのかからないプログラムを作るかという視点がいかに重要かを示す良い事例となる。

まず「ガス」とは何かだが、ブロックチェーン上で行われるすべての操作や取引には手数料がかかる。この手数料を「ガス」と呼ぶ。例えるなら、車を動かすためのガソリンのようなものだ。より複雑な処理や、より多くのデータを扱う処理には、より多くのガスが必要となる。このガス代が高すぎると、ユーザーはサービスを利用しにくくなり、プラットフォーム全体の競争力にも影響が出てしまう。

Sentora Curatorは、イーサリアムのメインチェーン（L1）やその処理を高速化する補助的なチェーン（L2ロールアップ）上で、約24.7億ドルもの巨額の資産を管理する大規模なプラットフォームである。これまでのところ、その中核となるスマートコントラクト（プログラム）は、機能的には正しく動作することが検証済みで、安全性は高いと評価されている。しかし、今回の監査では、預金の実行、資金の引き出し、報酬の請求、プラットフォームの状態更新といった、ユーザーが頻繁に行う操作のガス消費量が、業界の標準的なベンチマークよりも高いことが判明した。これは、ユーザーにとって無駄なコストがかかっていることを意味する。

具体的にどれくらいの無駄があったかというと、預金や引き出し、報酬請求といった主要な操作で、現在のガス消費量が業界の目標値よりも30%前後も高い状況だった。プラットフォームを動かすためのプログラム（コントラクト）を新しく展開する際にも、約21%のガス代が余計にかかっていた。これほど大規模なプラットフォームでは、たとえ10%のガス削減であっても、年間で数百万ドル（数億円）ものユーザー手数料の節約につながるため、この問題は非常に重要視されている。

では、なぜこのようなガスの無駄が発生していたのだろうか。主な原因はいくつか挙げられている。 一つは「ループ内でのストレージの繰り返しの読み書き」だ。スマートコントラクトがブロックチェーン上にデータを永続的に保存することを「ストレージに書き込む」と言い、保存されたデータを読み出すことを「ストレージから読み込む」と言う。これらの操作は非常にガス代が高い。なのに、ループ処理（繰り返し処理）の中で、同じデータを何度も読み書きしていたため、無駄なガスを消費していた。 次に「ERC-20トークンの送金におけるaddress(this).balanceの不要なチェック」がある。ERC-20は、イーサリアムで最も一般的なトークンの規格だ。コントラクトがERC-20トークンを受け取ったことを確認するために、address(this).balanceという、コントラクト自身が保有するイーサリアム（ETH）の残高をチェックする記述があった。しかし、これはETHの残高を確認するものであり、ERC-20トークンの着金確認には不要なチェックだったため、無駄なガスを消費していた。 また、「冗長なrequire文」も問題だった。require文は、特定の条件が満たされない場合に、その取引を中断させるためのチェック機能だ。しかし、今回のSentora Curatorのコントラクトには、後のチェックによってすでに保証されているはずの条件を、手前で再度チェックするような記述が複数見られた。これにより、セキュリティ上のメリットがないにも関わらず、余計なガスを消費していた。 「非効率な配列の取り扱い」も原因の一つだ。配列とは、複数のデータを順番に並べて管理するリストのようなものだ。Sentora Curatorでは、動的にサイズが変わる配列（動的配列）を、ユーザーが預金や引き出しを行うたびに拡大したり縮小したりしていた。このような操作は、配列のサイズが大きくなると処理コストが非常に高くなる。 最後に「Solidity 0.8.xでのuncheckedブロックの欠如」だ。Solidity 0.8以降のバージョンでは、数値の計算でオーバーフロー（数値が表現できる最大値を超えてしまうこと）やアンダーフロー（最小値を下回ること）が発生しないように、自動的にチェックが行われる。これは安全性を高めるための機能だが、数学的にオーバーフローが絶対に起こらないような場所でもこのチェックが実行されてしまい、わずかながらガスを消費していた。uncheckedブロックを使えば、この自動チェックを無効にできるため、不要なガス消費を抑えられる。

これらのガスの無駄は、単なるコスト増だけでなく、いくつかのセキュリティ上のリスク（攻撃ベクトル）にもつながる可能性があることが指摘されている。 最も深刻なのは「報酬分配における無限ループ」の可能性だ。報酬トークンのリストを巡回する処理（claimRewards()関数）に上限が設定されていなかったため、もし悪意のある第三者が、ガバナンス機能（プラットフォームの運営に関する決定を行う機能）を利用して大量のダミートークンを報酬リストに追加した場合、報酬請求の処理が長くなりすぎてブロックチェーンの取引で許容されるガス制限を超えてしまう可能性がある。そうなると、ユーザーは報酬を請求できなくなり（サービス拒否攻撃）、プラットフォームの信頼性が損なわれる恐れがある。 また、「バッチ更新におけるストレージ書き込みの増幅」も問題だ。複数のデータをまとめて更新する処理（batchUpdateCurators()関数）で、同じ情報を複数回ブロックチェーンに書き込むような実装になっていた。一度の書き込みには高額なガス代がかかるため、これにより取引コストが不必要に増大し、悪意のあるユーザーが他のユーザーよりも高いガス代を支払って自分の取引を先に通す「ガス価格のフロントランニング」を誘発する可能性があった。 「預金・引き出しごとの動的配列のリサイズ」もリスクだ。ユーザーの預金者アドレスを保存する動的配列が、預金や引き出しのたびにリサイズされるため、預金者が増えるほど処理コストが急増する。これにより、少額の預金を多数繰り返し行うことで、特定のプールにおける後続の操作が非常に高価になり、実質的なサービス拒否攻撃を引き起こす可能性があった。

これらの問題を解決するため、監査レポートでは具体的な改善策が提案されている。 例えば、「報酬トークンリストに上限を設けてマッピングを使う」ことで、無限ループの可能性を排除し、ストレージの読み書きを効率化する。これは報酬請求時のガスを約30%削減する効果が見込まれる。 また、「バッチ更新におけるストレージ書き込みを統合する」ことで、同じ情報を複数回書き込まずに一度で済ませるようにする。これにより、batchUpdateCuratorsのガスを約20〜25%削減できる。 「冗長なrequire文を削除する」ことや、「動的配列をマッピングとカウンタに置き換える」ことも提案されている。特に、動的配列の置き換えは、預金・引き出し時のガスを約30〜40%も削減できる大きな改善点だ。 さらに、「数学的にオーバーフローが不可能な計算にはuncheckedブロックを適用する」ことで、安全性を損なわずにガスを節約する。 その他にも、ERC-20転送での不要なチェックの削除、外部配列パラメータにcalldataの使用を強制する（これはデータ転送の効率を高める）、古いデータを削除する際にガス払い戻しメカニズムを利用する、といった細かな最適化も提案されている。

これらの改善策を適用することで、Sentora Curatorは、最も頻繁に利用される機能のガス消費量を30〜40%削減できると見込まれている。これは年間で数千万ドルもの手数料節約につながり、ユーザーはより低いコストでサービスを利用できるようになるため、L2環境でのプラットフォームの採用を促進し、競争力を高めることになる。また、無限ループによるサービス拒否攻撃の可能性も排除され、プラットフォームの信頼性と安定性が向上する。

今回の監査結果は、コアロジックの堅牢性（機能の正しさ）と同時に、ガス効率という経済的側面、そしてそれが潜在的な攻撃面にもなりうるという、スマートコントラクト開発の複雑さを示している。単に動くプログラムを作るだけでなく、いかに「安く」「速く」「安全に」動かすかという視点が、特に大規模なDeFiプラットフォームにおいては極めて重要であることがわかるだろう。 今後のステップとしては、これらの改善策を開発チームがコードに落とし込み、徹底的なテストとガス消費量のベンチマークを行った後、コミュニティのレビューを経て、新しい最適化されたコントラクトが展開される予定だ。これによりSentora Curatorは、セキュリティを維持しつつ、よりガス効率の高いDeFiプラットフォームとしての新たな基準を確立することを目指している。

これはシステムエンジニアとして、プログラムの機能だけでなく、その実行コストや効率性、そしてそれに伴うリスクまで総合的に考慮する能力がいかに重要であるかを教えてくれる事例だ。