> 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/es/conceptos-basicos/compute-budget.md). # Presupuesto de cómputo Costes de unidades de cómputo de Solana (CU) para operaciones de Rome EVM: presupuestos atómicos frente a iterativos y cómo diseñar contratos Solidity eficientes en CU. Cada transacción de Solana tiene un presupuesto de cómputo medido en Unidades de Cómputo (CU). Entender los costos de CU te ayuda a diseñar contratos de Rome eficientes. ## Resumen del presupuesto | Modo | CU máx. | Notas | | ---------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | Atómico (VmAt) | \~1.400.000 CU | Una sola transacción de Solana | | Iterativo (VmIt) | Hasta \~1.400.000 CU por tramo; como máximo 160 iteraciones por sesión | Cada tramo es su propia transacción de Solana; opcodes/paso adaptativos — ajustados al presupuesto de CU de cada tx | Cada transacción de Solana tiene un presupuesto predeterminado de 200.000 CU, ampliable a \~1,4M CU mediante instrucciones de presupuesto de cómputo (añadidas automáticamente por el SDK de Rome). La ejecución iterativa no es ilimitada. Una sesión termina después de 160 iteraciones, y el composer iterativo del SDK de Rome en Rust planifica como mucho 128 tramos. Un plan que la cartera firma por sí misma pasa por `rome_submitSignedV1Plan`, que acepta como máximo 64 transacciones por llamada. La mayoría de las llamadas necesitan muchas menos. Las CPI de la ruta heredada se rechazan dentro de una sesión iterativa, así que una llamada que las haga tiene que ajustarse al presupuesto atómico. Véase [Llamadas reenviadas y llamadas largas](/es/guias-para-desarrolladores/call-evm-from-solana.md#relayed-calls-and-long-calls) y [Restricciones](/es/conceptos-basicos/constraints.md). ## Estimaciones de costo de CU ### Operaciones EVM | Operación | CU aproximado | Notas | | ---------------------------------------------------------- | -------------------- | --------------------------------------------------------------------------------------- | | Verificación de firmas de transacción (canal de clave EVM) | \~25.000 CU | La `secp256k1_recover` syscall, el mismo costo que el `ecrecover` precompilado de abajo | | Transferencia simple | \~50.000-100.000 CU | Solo actualizaciones de saldo | | Transferencia ERC-20 | \~100.000-150.000 CU | Incluye llamada al precompilado SPL | | Despliegue de contrato (pequeño) | \~200.000-400.000 CU | Depende del tamaño del bytecode | | Escritura en almacenamiento (SSTORE) | \~5.000-20.000 CU | Acceso frío vs. caliente | ### Operaciones precompiladas | Precompilado | CU aproximado | Notas | | --------------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ecrecover | \~25.700 CU | | | SHA-256 | \~257 CU por palabra de 32 bytes medida | Más un pequeño costo fijo. El programa valora SHA-256, RIPEMD-160 y el precompilado de identidad con una sola cifra compartida por palabra de aproximadamente 2.200 CU, dimensionada según RIPEMD-160, el más costoso de los tres, por lo que se cobra a una llamada SHA-256 más de lo que usa | | BN254 ecAdd | Cerca de 0 CU | Más barato que copiar 32 bytes | | BN254 ecMul | \~4.200 CU | | | BN254 ecPairing | \~22.000 CU más \~12.800 CU por par | Una verificación de cuatro pares es de unos 73.000 CU, muy dentro de una sola transacción atómica | Estas cifras provienen de la propia calibración del programa, que utilizó unidades de cómputo leídas desde un nodo de Solana en un despliegue en testnet. No se vuelven a medir para esta página; mide tu propia llamada con `computeUnitsConsumed`. ## Técnicas de optimización ### 1. Usa Yul para las rutas críticas El optimizador de Solidity produce código razonable, pero Yul (ensamblador en línea) puede reducir significativamente el CU para operaciones críticas: ```solidity // Antes: ~600K CU function createPairAccount(bytes32 token0, bytes32 token1) external { // Operaciones a nivel de Solidity } // Después: ~150K CU (optimización Yul) function createPairAccount(bytes32 token0, bytes32 token1) external { assembly { // Manipulación directa de memoria, omite la sobrecarga de codificación ABI } } ``` ### 2. Guarda en caché las derivaciones de PDA La derivación de PDA mediante `find_program_address` es costosa. Guarda las PDA derivadas en el almacenamiento del contrato en lugar de calcularlas en cada llamada: ```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. Codifica de forma fija los IDs de programa conocidos No cargues los IDs de programa desde el almacenamiento — usa constantes: ```solidity // Costoso: lee desde almacenamiento bytes32 splTokenProgram = storage_program_id; // Barato: constante en tiempo de compilación bytes32 constant SPL_TOKEN_PROGRAM = 0x06ddf6e1d765a193d9cbe146ceeb79ac1cb485ed5f5b37913a8cf5857eff00a9; ``` ### 4. Minimiza el número de cuentas Cada cuenta en una transacción de Solana añade sobrecarga de CU. Reduce el número de cuentas: * Agrupando operaciones que comparten cuentas * Usando menos cuentas intermedias * Evitando comprobaciones redundantes de creación de ATA ### 5. Usa la configuración del optimizador ```typescript // hardhat.config.ts — habilita el optimizador en un perfil de compilación solidity: { profiles: { default: { version: "0.8.28" }, production: { version: "0.8.28", settings: { optimizer: { enabled: true, runs: 200 } }, }, }, } ``` Compila con `npx hardhat compile --build-profile production`. ## Medición del consumo de CU Usa `eth_estimateGas` para medir el CU antes de enviar: ```bash cast estimate --rpc-url https://hadrian.testnet.romeprotocol.xyz/ \\ 0xCONTRACT "myFunction(uint256)" 42 ``` O mediante ethers.js: ```javascript const gas = await contract.myFunction.estimateGas(42); console.log("Gas estimado:", gas.toString()); ``` ## Qué sigue * [Restricciones](/es/conceptos-basicos/constraints.md) — lista completa de límites y restricciones --- # 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/es/conceptos-basicos/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.