> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/ja/ji-ben-gai-nian/compute-budget.md). # Compute Budget Rome EVM操作におけるSolanaのコンピュートユニット（CU）コスト — アトミックとイテレーティブの予算、そしてCU効率の高いSolidityコントラクトの設計方法。 すべての Solana トランザクションには、Compute Units（CU）で測定される計算バジェットがあります。CU コストを理解すると、効率的な Rome コントラクトを設計するのに役立ちます。 ## バジェット概要 | モード | 最大 CU | 注記 | | ----------- | ---------------------------------------------- | ----------------------------------------------------------------------------------- | | アトミック（VmAt） | \~1,400,000 CU | 単一の Solana トランザクション | | 反復的（VmIt） | 1 レッグあたり最大約 1,400,000 CU。1 セッションあたり最大 160 回の反復 | 各レッグはそれぞれ独立した Solana トランザクションであり、アダプティブな opcode/step は各 tx の CU バジェットに収まるようにパックされます | 各 Solana トランザクションのデフォルトバジェットは 200,000 CU で、compute budget 命令（Rome SDK により自動的に追加されます）によって約 1.4M CU まで拡張できます。 反復実行は無制限ではありません。1 セッションは 160 回の反復後に終了し、Rust 版 Rome SDK の反復コンポーザーは最大 128 レッグを計画します。ウォレットが自ら署名するプランは次を経由します `rome_submitSignedV1Plan`。これは 1 回の呼び出しにつき最大 64 トランザクションを受け付けます。ほとんどの呼び出しではそれよりはるかに少ない数で済みます。レガシー・トラックの CPI は反復セッション内では拒否されるため、それを行う呼び出しはアトミックバジェット内に収める必要があります。参照 [リレイされた呼び出しと長時間呼び出し](/ja/gaido/call-evm-from-solana.md#relayed-calls-and-long-calls) および [制約](/ja/ji-ben-gai-nian/constraints.md). ## CU コストの見積もり ### EVM オペレーション | オペレーション | 概算 CU | 注記 | | ---------------------- | -------------------- | -------------------------------------------------------------- | | トランザクション署名検証（EVM キー経路） | \~25,000 CU | その `secp256k1_recover` syscall。以下の `ecrecover` プレコンパイルと同じコストです | | 単純な送金 | \~50,000-100,000 CU | 残高更新のみ | | ERC-20 送金 | \~100,000-150,000 CU | SPL プレコンパイル呼び出しを含みます | | コントラクト展開（小規模） | \~200,000-400,000 CU | バイトコードのサイズに依存します | | ストレージ書き込み（SSTORE） | \~5,000-20,000 CU | コールドアクセス vs ウォームアクセス | ### プレコンパイル・オペレーション | プリコンパイル | 概算 CU | 注記 | | --------------- | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ecrecover | \~25,700 CU | | | SHA-256 | 32 バイトワードごとの測定コストは約 257 CU | これに少額の固定コストが加わります。このプログラムでは、SHA-256、RIPEMD-160、identity プレコンパイルを、1 ワードあたり約 2,200 CU という共通の単価で計上しています。これは 3 つの中で最も高コストな RIPEMD-160 に合わせた値であるため、SHA-256 の呼び出しには実際の使用量より多く課金されます | | BN254 ecAdd | ほぼ 0 CU | 32 バイトをコピーするより安価 | | BN254 ecMul | \~4,200 CU | | | BN254 ecPairing | \~22,000 CU に加えてペアごとに約 12,800 CU | 4 ペアの検証は約 73,000 CU で、1 回のアトミックトランザクション内に十分収まります | これらの数値はプログラム独自のキャリブレーションに由来します。テストネットへのデプロイで Solana ノードから読み戻した compute units を使用しています。このページのために再計測したものではありません。ご自身の呼び出しは次で測定してください `computeUnitsConsumed`. ## 最適化テクニック ### 1. ホットパスには Yul を使う Solidity の最適化器でも十分なコードは生成されますが、Yul（インラインアセンブリ）は重要な処理の CU を大幅に削減できます。 ```solidity // 変更前: 約 600K CU function createPairAccount(bytes32 token0, bytes32 token1) external { // Solidity レベルの処理 } // 変更後: 約 150K CU（Yul 最適化） function createPairAccount(bytes32 token0, bytes32 token1) external { assembly { // 直接メモリ操作、ABI エンコードのオーバーヘッドを省く } } ``` ### 2. PDA 導出をキャッシュする PDA の導出は `find_program_address` を使うため高コストです。毎回計算するのではなく、導出した PDA をコントラクトのストレージに保存してください。 ```solidity mapping(address => bytes32) private cachedPdas; function getPda(address user) internal returns (bytes32) { bytes32 cached = cachedPdas[user]; if (cached != bytes32(0)) return cached; bytes32 pda = RomeEVMAccount.pda(user); cachedPdas[user] = pda; return pda; } ``` ### 3. 既知のプログラム ID をハードコードする ストレージからプログラム ID を読み込まないでください。定数を使いましょう。 ```solidity // 高コスト: ストレージから読み込む bytes32 splTokenProgram = storage_program_id; // 低コスト: コンパイル時定数 bytes32 constant SPL_TOKEN_PROGRAM = 0x06ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a9; ``` ### 4. アカウント数を最小化する Solana トランザクション内の各アカウントは CU のオーバーヘッドを追加します。次の方法でアカウント数を減らしてください。 * アカウントを共有する操作をまとめる * 中間アカウントの数を減らす * 冗長な ATA 作成チェックを避ける ### 5. 最適化設定を使う ```typescript // hardhat.config.ts — ビルドプロファイルで最適化器を有効化 solidity: { profiles: { default: { version: "0.8.28" }, production: { version: "0.8.28", settings: { optimizer: { enabled: true, runs: 200 } }, }, }, } ``` 次でビルド `npx hardhat compile --build-profile production`. ## CU 消費の測定 使用してください `eth_estimateGas` 送信前に CU を測定するには: ```bash cast estimate --rpc-url https://hadrian.testnet.romeprotocol.xyz/ \ 0xCONTRACT "myFunction(uint256)" 42 ``` または ethers.js で: ```javascript const gas = await contract.myFunction.estimateGas(42); console.log("推定 gas:", gas.toString()); ``` ## 次は * [制約](/ja/ji-ben-gai-nian/constraints.md) — 制限と境界の完全な一覧 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.rome.builders/ja/ji-ben-gai-nian/compute-budget.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.