> 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/pt-br/conceitos-principais/compute-budget.md). # Orçamento de computação Custos de unidades de computação da Solana (CU) para operações da Rome EVM — orçamentos atômicos vs. iterativos e como projetar contratos Solidity eficientes em CU. Toda transação Solana tem um orçamento de computação medido em Compute Units (CU). Entender os custos em CU ajuda você a projetar contratos Rome eficientes. ## Visão geral do orçamento | Modo | CU máximo | Observações | | ---------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | Atômico (VmAt) | \~1.400.000 CU | Uma única transação Solana | | Iterativo (VmIt) | Até \~1.400.000 CU por etapa; no máximo 160 iterações por sessão | Cada etapa é sua própria transação Solana; opcodes adaptativos por etapa — ajustados ao orçamento de CU de cada tx | Cada transação Solana tem um orçamento padrão de 200.000 CU, que pode ser ampliado para \~1,4 milhão de CU por meio de instruções de compute budget (adicionadas automaticamente pelo SDK da Rome). A execução iterativa não é ilimitada. Uma sessão termina após 160 iterações, e o composer iterativo do SDK Rust da Rome planeja no máximo 128 etapas. Um plano que a própria carteira assina passa por `rome_submitSignedV1Plan`, que aceita no máximo 64 transações per chamada. A maioria das chamadas precisa de muito menos. CPIs do caminho legado são recusadas dentro de uma sessão iterativa, então uma chamada que as utilize precisa caber no orçamento atômico. Veja [Chamadas retransmitidas e chamadas longas](/pt-br/guias-do-desenvolvedor/call-evm-from-solana.md#relayed-calls-and-long-calls) e [Restrições](/pt-br/conceitos-principais/constraints.md). ## Estimativas de custo em CU ### Operações EVM | Operação | CU aproximado | Observações | | ------------------------------------------------------ | -------------------- | ------------------------------------------------------------------------------------ | | Verificação de assinatura da transação (via chave EVM) | \~25.000 CU | Os `secp256k1_recover` syscall, o mesmo custo que o `ecrecover` pré-compilado abaixo | | Transferência simples | \~50.000-100.000 CU | Apenas atualizações de saldo | | Transferência ERC-20 | \~100.000-150.000 CU | Inclui chamada ao pré-compilado SPL | | Implantação de contrato (pequena) | \~200.000-400.000 CU | Depende do tamanho do bytecode | | Gravação em storage (SSTORE) | \~5.000-20.000 CU | Acesso frio vs. quente | ### Operações de pré-compilado | Precompilado | CU aproximado | Observações | | --------------- | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ecrecover | \~25.700 CU | | | SHA-256 | \~257 CU por palavra de 32 bytes medida | Além de um pequeno custo fixo. O programa precifica SHA-256, RIPEMD-160 e o pré-compilado de identidade com um único valor compartilhado por palavra de cerca de 2.200 CU, ajustado ao RIPEMD-160, o mais caro dos três, então uma chamada SHA-256 é cobrada acima do que realmente usa | | BN254 ecAdd | Próximo de 0 CU | Mais barato do que copiar 32 bytes | | BN254 ecMul | \~4.200 CU | | | BN254 ecPairing | \~22.000 CU mais \~12.800 CU por par | Uma verificação com quatro pares fica em torno de 73.000 CU, bem dentro de uma transação atômica | Esses números vêm da calibração do próprio programa, que usou unidades de computação lidas de um nó Solana em uma implantação na testnet. Eles não foram reavaliados para esta página; meça sua própria chamada com `computeUnitsConsumed`. ## Técnicas de otimização ### 1. Use Yul para caminhos críticos O otimizador do Solidity produz código razoável, mas Yul (assembly inline) pode reduzir significativamente o CU em operações críticas: ```solidity // Antes: ~600K CU function createPairAccount(bytes32 token0, bytes32 token1) external { // Operações no nível de Solidity } // Depois: ~150K CU (otimização em Yul) function createPairAccount(bytes32 token0, bytes32 token1) external { assembly { // Manipulação direta de memória, sem o overhead de codificação ABI } } ``` ### 2. Cache das derivações de PDA Derivação de PDA via `find_program_address` é cara. Armazene os PDAs derivados no storage do contrato em vez de calculá-los a cada chamada: ```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. Codifique IDs de programa conhecidos Não carregue IDs de programa do storage — use constantes: ```solidity // Caro: lê do storage bytes32 splTokenProgram = storage_program_id; // Barato: constante em tempo de compilação bytes32 constant SPL_TOKEN_PROGRAM = 0x06ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a9; ``` ### 4. Minimize a quantidade de contas Cada conta em uma transação Solana adiciona overhead de CU. Reduza o número de contas: * Agrupar operações que compartilham contas * Usar menos contas intermediárias * Evitar verificações redundantes de criação de ATA ### 5. Use as configurações do otimizador ```typescript // hardhat.config.ts — habilite o otimizador em um perfil de build solidity: { profiles: { default: { version: "0.8.28" }, production: { version: "0.8.28", settings: { optimizer: { enabled: true, runs: 200 } }, }, }, } ``` Compile com `npx hardhat compile --build-profile production`. ## Medindo o consumo de CU Use `eth_estimateGas` para medir o CU antes de enviar: ```bash cast estimate --rpc-url https://hadrian.testnet.romeprotocol.xyz/ \\ 0xCONTRACT "myFunction(uint256)" 42 ``` Ou via ethers.js: ```javascript const gas = await contract.myFunction.estimateGas(42); console.log("Gas estimado:", gas.toString()); ``` ## O que Vem a Seguir * [Restrições](/pt-br/conceitos-principais/constraints.md) — lista completa de limites e fronteiras --- # 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/pt-br/conceitos-principais/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.