Simple Science

最先端の科学をわかりやすく解説

# コンピューターサイエンス# 暗号とセキュリティ

スマートコントラクトでの再入可能性の防止

再入可能性リスクからスマートコントラクトを守る方法を学ぼう。

― 1 分で読む


スマートコントラクトの再入スマートコントラクトの再入可能性リスクするための重要な戦略。スマートコントラクトのセキュリティを強化
目次

スマートコントラクトは、イーサリアムみたいなブロックチェーン上で動くプログラムなんだ。これを使うことで、中央集権なしでアプリを作れる。これらのアプリは、分散アプリケーション(dApp)って呼ばれて、イーサやトークンみたいなデジタル資産を扱える。

スマートコントラクトの重要な部分はその機能。機能は、スマートコントラクトがタスクを実行するための基本的な要素なんだけど、設計が雑だと問題が起こることもある。例えば、再入侵っていう問題があって、これは関数が実行中に自分自身を呼び出すときに起こるんだ。これが起きると、資金がなくなったりするセキュリティの問題につながる。

再入侵の説明

再入侵っていうのは、関数が処理中に中断されて、終わる前にまた呼ばれること。これ、他のコントラクトの関数を呼んで、そこから元の関数に戻るときに起きる。これを悪用されると、資金やデータを操作されちゃう。

これを防ぐために、開発者たちは再入侵を防ぐ方法を考えた。デザインパターンを使ったり、ガス量を制限したり、特殊な関数修飾子を使って攻撃から守るんだ。

再入侵を制限する一般的なパターン

チェック-エフェクト-インタラクションパターン

このパターンでは、関数はまず全ての条件をチェック(チェック)して、その後にコントラクトの状態を変更(エフェクト)して、最後に他のコントラクトとやり取り(インタラクション)するべきだって言ってる。この順番でやることで、再入侵が起きてもコントラクトの状態に影響を与えないようになる。

ガス制限

再入侵を防ぐための別の効果的な方法は、外部呼び出しに渡すガスの量を制限すること。Solidityでは、イーサを送るための3つの主な方法があって、transfer()send()call()なんだけど、最初の2つはガス量を固定に制限するから再入侵が起こりにくい。でも、call()は残りのガスを全部渡しちゃうから問題が起こる可能性がある。だから、開発者はこれらのコマンドを使うときに気をつけなきゃいけない。

非再入侵モディファイア

再入侵を防ぐために広く使われている方法は、非再入侵モディファイアを使うこと。このモディファイアは、関数が終わるまで再度呼ばれないようにロックするものなんだ。これを使うことで、開発者は関数が同時に何度も呼ばれないように守れるんだ。

再入侵を防ぐことの重要性

再入侵を防ぐことはめっちゃ大事で、スマートコントラクトの整合性とセキュリティを保つのに役立つ。2023年には、再入侵の脆弱性によって大きな財務損失が発生した実際の事件がたくさんあったから、より良い防護策を実装することが開発者には求められてる。

読み取り専用の再入侵

もう一つの再入侵のタイプは、読み取り専用の再入侵。これは、別の関数がまだ処理中のときに読み取り専用の関数にアクセスされると起きる。これによってデータの不整合が生じて、悪用される脆弱性を生むことがある。契約内の正確な情報を維持するためには、読み取り専用の再入侵を防ぐことが重要なんだ。

読み取り専用の再入侵を防ぐための戦略

読み取り専用の再入侵を避ける一つの方法は、読み取り専用関数を呼ぶ前に特別なチェックを使うこと。ただし、これをやるとガス使用量が増えるから、開発者はセキュリティと効率のバランスを見つけなきゃいけないんだ。

事例研究

Exactly Protocolインシデント

このケースでは、攻撃者が許可を出す者のふりをして契約を騙した。非再入侵モディファイアを使わなかったせいで、攻撃者が資金を盗むことができたんだ。

Orion Protocolインシデント

Orion Protocolでは、攻撃者が再入侵のテクニックを使って、悪意のあるコントラクトにトークンを預けて契約を操作した。この事件は、より良いセキュリティ対策の必要性を浮き彫りにした。

Curve Financeインシデント

Curve Financeの事件は、非再入侵モディファイアがあれば大きな財務損失を防げた可能性があることを示してる。契約には似たような保護があったけど、コンパイラのバグでそれが機能しなかったんだ。

読み取り専用の再入侵に対処する

読み取り専用の再入侵の課題をさらに説明するために、Sentimentのインシデントを見てみよう。攻撃者は、一連の取引を利用して担保の価格を膨らませて、契約の状態を正確に反映していない読み取り関数を利用したんだ。

Sentiment攻撃のステップ

  1. 攻撃者が大量のWETH、WBTC、およびUSDCを手に入れる。
  2. それらの資産をプールに預けて、Balancer Pool Tokens(BPT)を受け取る。
  3. 攻撃者が内部関数を操作しながらプールから退出する。
  4. その結果、契約が実際の担保価値以上に借りることを許可し、攻撃者にとって大きな利益をもたらす状況になる。

この事件は、チェックしないと読み取り専用の再入侵が損失をもたらすことを示してる。

将来のインシデントを防ぐ

開発者は、両方のタイプの再入侵を防ぐためのいくつかの戦略を使うことができる。これには:

  1. 非再入侵モディファイア: 関数にこれを実装することで、再入侵呼び出しをブロックできる。
  2. アクセス制限: 関数のサブセットにアクセスコントロールを適用することで、悪用のリスクを減らせる。
  3. 時間ベースのロック: 特定の関数に時間制限を設けることで、短時間内に複数の呼び出しを防げる。

こういった戦略を使うことで、開発者はスマートコントラクトのセキュリティを大幅に向上させられる。

結論

要するに、再入侵を防ぐことは、スマートコントラクトのセキュリティを維持するために欠かせない。再入侵のさまざまなタイプを理解し、防護戦略を採用することで、開発者はより安全な分散型アプリケーションを作れる。ブロックチェーンエコシステムが成長するにつれて、こうしたセキュリティ対策の重要性はますます高まって、ユーザーやその資産を守ることになるんだ。

オリジナルソース

タイトル: Temporarily Restricting Solidity Smart Contract Interactions

概要: In this work we explore ways to restrict the ability to call Solidity smart contract functions for a specified duration. We describe methods to restrict functions from being called twice in the same transaction, block, or time period. This is related to the notion of non-reentrant functions, which are functions that can be called within a previous execution. These methods can be used to restrict interactions with entire sets of functions of smart contracts. We are motivated to revisit this topic for two reasons. First, we note that sixteen real-world smart contracts exploits in 2023 resulting in over $136M USD lost or stolen that could have been prevented by restricting function calls. As part of this survey, we dissect a new class of exploit that involves so-called read-only reentrancy: exploits that re-enter read-only functions to make smart contract state inconsistent in order to enable their exploitation. Second, while some of these approaches are simple, they may not always behave the same across different blockchains that support Solidity.

著者: Valerian Callens, Zeeshan Meghji, Jan Gorzny

最終更新: 2024-05-15 00:00:00

言語: English

ソースURL: https://arxiv.org/abs/2405.09084

ソースPDF: https://arxiv.org/pdf/2405.09084

ライセンス: https://creativecommons.org/licenses/by/4.0/

変更点: この要約はAIの助けを借りて作成されており、不正確な場合があります。正確な情報については、ここにリンクされている元のソース文書を参照してください。

オープンアクセスの相互運用性を利用させていただいた arxiv に感謝します。

著者たちからもっと読む

類似の記事

分散・並列・クラスターコンピューティングビザンチン合意の進展:ゴリラスンドグラス

ゴリラスンドグラスは、ビザンチン環境で強い安全性と生存性を持つコンセンサスプロトコルを強化するよ。

― 1 分で読む