# S3. ビジネスロジックと経済のセキュリティ (Business Logic and Economic Security) ## 管理目標 スマートコントラクトのビジネスロジックと経済のセキュリティが、インセンティブ構造、トークノミクス、ロジックの脆弱性に関連する脅威に対して耐性があることを確認します。コントラクトは、安全な経済モデル、トークン処理、トランザクションの完全性を実装することで、不正使用、誤動作、予期しない動作を防ぐ必要があります。 ## S3.1 経済モデル (Economic Models) ### 管理目標 インセンティブ構造やトークノミクスを含む経済モデルが、エコシステム内で価値を確保し、適切な行動にインセンティブを与えるように設計され、実装されていることを確認します。コントラクトはトークン価値の変動に対応し、悪用の機会を作らないようにする必要があります。 ### S3.1.A インセンティブ構造 (Incentive Structures) | 参照コード | 要件 | L1 | L2 | L3 | SWE | | ------- | --------------------------------------------------------------------------------------------------------------------------------- | -- | -- | -- | --- | | S3.1.A1 | 会計を追跡し、ユーザーが支払いを引き出せるように、払い戻しプロセスがプッシュベースではなくプルベースのアプローチを導入していることを確認します。 | ✓ | ✓ | ✓ | | | S3.1.A2 | cbETH から ETH へのレートが低下する可能性があり、cbETH を保有またはやり取りするユーザーに影響を及ぼします。変換レートの変動に対応するためのメカニズムがあることを確認します。 | | ✓ | ✓ | | | S3.1.A3 | Ethereum 2.0 Beacon Chain のバリデータは、不正行為によってペナルティを受けたり削減される可能性があり、rETH の価値に影響を及ぼす可能性があります。価値評価ややり取りにおいて、これらのダイナミクスが考慮されていることを確認します。 | | ✓ | ✓ | | | S3.1.A4 | ETH と rETH との間の変換レートはステーキングから得られる報酬に基づいて時間の経過とともに変化する可能性があります。これらの変動が適切に管理され、捕捉されていることを確認します。 | | ✓ | ✓ | | ## S3.2 トークノミクス (Tokenomics) ### 管理目標 スマートコントラクトエコシステム内で使用されるトークンが、価値管理、リベースメカニズム、報酬システムなどの側面を含めて安全に実装されていることを確認します。コントラクトは、二重支出、不正報酬、不適切な手数料処理などのトークンの脆弱性を防ぐ必要があります。 ### S3.2.A トークンの経済的セキュリティとそのユースケース (Economic Security of Tokens and Their Use Cases) | 参照コード | 要件 | L1 | L2 | L3 | SWE | | ------- | ------------------------------------------------------------------------------------ | -- | -- | -- | --- | | S3.2.A1 | 二重支払いなどの脆弱性につながる可能性があるため、Merkle ツリーには重複した証明を含まないことを確認します。 | | ✓ | ✓ | | | S3.2.A2 | DeFi プロトコルがネガティブリベースメカニズムを備えたトークンを考慮していることを検証し、価値の変化と潜在的な計算ミスが適切に処理され、軽減されることを確認します。 | | ✓ | ✓ | | | S3.2.A3 | ユーザーが正しい報酬を受け取れるように、報酬請求が正しく実装されていることを検証します。 | | ✓ | ✓ | | | S3.2.A4 | トークンには、トークン転送の問題による、不正な手数料の適用や予期しない動作などの脆弱性がないことを検証します。 | | ✓ | ✓ | | | S3.2.A5 | 請求可能なすべてのアドレスには Merkle ツリーのリーフのハッシュ化プロセスに含まれており、攻撃者が資金を不正に請求することを防いでいることを検証します。 | | ✓ | ✓ | | ## S3.3 再入可能性とロジックの欠陥の防止 (Preventing Reentrancy and Logic Flaws) ### 管理目標 スマートコントラクトのトランザクションフローとロジックの完全性が再入攻撃やロジックの欠陥から保護されていることを確認します。コントラクトは堅牢な制御構造とセキュリティパターンを実装して、再入可能性を防ぎ、複雑なフローを処理し、状態遷移が安全かつ対照的であることを確保する必要があります。 ### S3.3.A トランザクションフローのセキュリティ (Transaction Flow Security) | 参照コード | 要件 | L1 | L2 | L3 | SWE | | ------- | ---------------------------------------------------------- | -- | -- | -- | --- | | S3.3.A1 | ループ制御構造のエッジケースをチェックして、break 文や continue 文による予期しない動作を防ぎます。 | | ✓ | ✓ | | | S3.3.A2 | 送信者と受信者が同じであるシナリオを考慮して、スマートコントラクトでの意図しない問題を防いでいることを確認します。 | | ✓ | ✓ | | | S3.3.A3 | 関数内で `NonReentrant` 修飾子が他の修飾子より前に適用され、再入攻撃を防いでいることを確認します。 | | ✓ | ✓ | | | S3.3.A4 | check-effect-interaction パターンが実装され、再入攻撃を防いでいることを検証します。 | | ✓ | ✓ | | | S3.3.A5 | 任意のユーザー入力と低レベルの呼び出しによる関数呼び出しが安全に処理され、リスクの発生を避けていることを確認します。 | | ✓ | ✓ | | ### S3.3.B 機能の完全性 (Function Integrity) | 参照コード | 要件 | L1 | L2 | L3 | SWE | | ------- | --------------------------------------------------------------- | -- | -- | -- | --- | | S3.3.B1 | パラメータセットごとに一意であることを意図した関数が複数回呼び出されず、潜在的な問題を防いでいることを確認します。 | | ✓ | ✓ | | | S3.3.B2 | 払い戻しや預け入れなどの関数の状態変化が対称的に処理され、一貫性がないことによる望ましくない動作を避けていることを検証します。 | | ✓ | ✓ | | --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://coky-t.gitbook.io/owasp-scsvs-ja/owasp-sumtokontorakutosekyuriti-001/0x12-s3-business_logic_and_economic_security.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.