> 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/constraints.md). # Restricciones Límites al construir sobre Rome EVM: tamaño de transacción de Solana, presupuesto de \~1,4M CU, límites de cuentas, diseño de almacenamiento y cómo Rome sortea cada uno. Límites y fronteras importantes al construir sobre Rome EVM. Comprender estas restricciones te ayuda a diseñar contratos que funcionen de forma fiable. ## Límites de transacción de Solana | Restricción | Valor | Impacto | | -------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------ | | Tamaño de la transacción | 4 KB (4.096 bytes) | Rome envía transacciones v1 de Solana; las transacciones EVM más grandes se almacenan temporalmente en cuentas holder (transparente) | | Unidades de cómputo por tx | \~1,4 M CU | Las operaciones que superan esto usan el modo iterativo, que tiene sus propios límites (abajo) | | Cuentas por tx | 64 direcciones | El límite de la transacción v1; cuenta todo lo que toca la tx EVM y sus CPI, incluidas las propias cuentas de Rome | | Tamaño máximo de holder | 80 KB | Tamaño RLP máximo para una sola transacción EVM | ## Límites de ejecución de EVM | Restricción | Valor | Notas | | ---------------------------------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Slots de almacenamiento del contrato | 256 por cuenta de almacenamiento | Se pueden crear varias cuentas de almacenamiento por contrato | | Opcodes por iteración | Adaptativo | Ajustado al presupuesto de CU de cada tx de Solana (VmIt) | | TTL del bloqueo de cuentas | 3 s (4 s cuando la sesión toca más de 28 cuentas) | Durante la ejecución iterativa; se renueva en cada paso | | Longitud de la sesión iterativa | 160 pasos | Al superar el límite, el siguiente paso libera los bloqueos de la sesión y la termina sin confirmar nada | | Tramos planificados por el SDK de Rome en Rust | 128 | El techo del compositor iterativo; las llamadas reales se resuelven en muchas menos | | Transacciones por plan firmado por la wallet | 64 | El máximo `rome_submitSignedV1Plan` acepta en una sola llamada; ver [Llamadas reenviadas y llamadas largas](/es/guias-para-desarrolladores/call-evm-from-solana.md#relayed-calls-and-long-calls) | | Billeteras de tesorería | 64 | Billeteras del fondo de comisiones | | Límite de tamaño del contrato | 24 KB | Igual que Ethereum (EIP-170, 24.576 bytes) | ## Restricciones de CPI | Restricción | Valor | Notas | | ------------------------------- | --------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Profundidad de CPI | Máximo 4 niveles | El límite de profundidad de CPI de Solana | | Cuentas por llamada CPI | Dentro del límite de 64 direcciones de la transacción | Compartido con cada otra cuenta que toca la transacción | | Profundidad CPI + Transfer Hook | Usa niveles de CPI | Los hooks de transferencia desde dentro de una CPI pueden exceder la profundidad | | Una pista por contrato | Legacy (`0xff…07/08/09`, `0x42…16`) **o** cached (`0xff…04/05/06/0b`) | Se rechaza mezclar llamadas mutantes de ambos en una sola transacción | | CPI heredada en modo iterativo | No permitido | Una CPI de pista heredada en una transacción iterativa falla con `CpiProhibitedInIterativeTx`; se permiten los efectos de la pista cached | **La profundidad de CPI es la restricción más crítica.** Rome EVM consume un nivel de CPI cuando Solana llama al programa Rome. Si tu contrato Solidity luego llama a otro programa de Solana vía CPI, eso es el nivel 2. Si ese programa llama a otro, eso es el nivel 3. Tienes como máximo 4 niveles en total. ``` Nivel 0: Runtime de Solana → Programa Rome EVM Nivel 1: Programa Rome EVM → Tu destino CPI (por ejemplo, Jupiter) Nivel 2: Jupiter → otro programa (por ejemplo, Raydium) Nivel 3: Raydium → SPL Token (profundidad máxima) ``` ## Restricciones de Transfer Hook de Token-2022 | Restricción | Impacto | | ------------------------ | --------------------------------------------------------------------------------------------------- | | Un hook por mint | Un mint de Token-2022 tiene una sola ranura de transfer-hook | | `transfer_checked` solo | Los hooks no se activan en un `transfer`. Las operaciones de puente de Rome usan `transfer_checked` | | Mint/burn no enganchados | Controlado mediante la autoridad de mint, no mediante hooks | ## Restricciones de gas y precios | Restricción | Notas | | -------------------------------- | ------------------------------------------------------------------------- | | Fuente del precio del gas | Pool DAMM de Meteora, v1 o v2 (token SPL de gas) | | Multiplicador del precio del gas | Configurable por proxy (`gas_price_mul`) | | Precio mínimo del gas | Establecido por la configuración del proxy | | Estimación de gas | Realizada fuera de la cadena mediante el emulador Mollusk antes del envío | ## Restricciones específicas de la red | Entorno | ID de cadena | ID de programa rome-evm | | ----------------- | ------------ | --------------------------------------------- | | Hadrian (testnet) | 200010 | `RPTWwELXAY4KC9ZPHhaxp7Sq1hHtU3HNEgLbSegCcWf` | | Rubicon (mainnet) | 7531 | `RomePq9X3iAoTr813HR7uRarafFDUJty6GdiEceYpzX` | ## Restricciones de precompilados | Precompilado | Restricción | | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Modexp (0x05) | **Deshabilitado** — una llamada revierte con `la llamada big_mod_exp está deshabilitada` hasta que Solana active la `big_mod_exp` syscall | | BN254 ecPairing (0x08) | Aproximadamente 22K CU más 12,8K por par según el precio del programa; una comprobación de cuatro pares encaja en una sola transacción atómica | | Precompilado de CPI (0xFF...08) | Las cuentas deben declararse por adelantado en la transacción de Solana | ## Validación de transacciones | Regla | Efecto | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Maleabilidad de la firma (EIP-2) | Se rechaza una transacción firmada cuyo `s` está por encima de la mitad del orden de la curva | | Forma del RLP | Se rechaza una transacción cuyo listado RLP contiene bytes sobrantes más allá de su último elemento | | Opcode no implementado | Aborta toda la transacción (`IncompatibleVersionEVM(opcode)`); no se confirma nada y un contrato llamante no puede absorberlo | | Medición de gas | Rome no tiene una tabla de gas por opcode: el gas pasado a `CALL`/`CREATE` no se aplica, y no existe un estipendio de 2300 gas: no dependas de la protección contra reentradas basada en estipendios | ## Restricciones del oráculo | Restricción | Valor | | -------------------------------- | ---------------------------------------------------------------------- | | Antigüedad máxima predeterminada | 60 segundos | | Datos históricos de rondas | No compatible — `getRoundData(roundId)` revierte | | EMA de Switchboard | No compatible — `latestEMAData()` revierte en SwitchboardV3 | | Desplazamientos del analizador | Validado empíricamente — debe volver a validarse antes del redepliegue | ## Recomendaciones de diseño 1. **Mantén la profundidad de CPI poco profunda.** Diseña los contratos para minimizar el anidamiento. Si llamas a Jupiter, que llama a Raydium, que llama a SPL Token, estás en 3 niveles: peligrosamente cerca del límite. 2. **Prefiere el modo atómico.** Diseña las operaciones para que entren dentro de \~1,4 M CU. El modo iterativo añade latencia (bloqueos de 3-4 segundos), un límite de 160 iteraciones por sesión y un aviso de la wallet por cada tramo en la vía de Solana cuando la wallet firma los tramos por sí misma. Una llamada que haga CPI de pista heredada no puede ejecutarse de forma iterativa en absoluto. 3. **Declara las cuentas por adelantado.** Todas las cuentas de Solana tocadas por CPI deben conocerse en el momento de creación de la transacción (la emulación del proxy las descubre). No es posible el descubrimiento dinámico de cuentas dentro de una llamada CPI, y el total debe ajustarse al límite de 64 direcciones. 4. **Elige una sola pista de precompilado por contrato.** Llamar a un programa personalizado de Solana (`invoke_signed`) es de pista heredada y solo atómico; ver [Integrar un programa de Solana](/es/guias-para-desarrolladores/integrate-solana-program.md). 5. **Usa `transfer_checked`.** Si estás construyendo algo que toca tokens Token-2022, usa siempre `transfer_checked` para asegurar que los hooks se activen. 6. **Prueba el consumo de CU.** Mide las unidades de cómputo reales de Solana a partir del recibo de la transacción (`computeUnitsConsumed`) — el `gasUsed` de EVM no es un proxy fiel de las CU de Solana. Optimiza con Yul para los caminos críticos. ## Qué sigue * [Presupuesto de cómputo](/es/conceptos-basicos/compute-budget.md) — costes detallados de CU por operación * [Interop de tokens](/es/conceptos-basicos/token-interop.md) — modelo de puente ERC-20 ↔ SPL * [Referencia de precompilados](/es/referencia/precompiles.md) — cada selector y su clase de despacho --- # 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/constraints.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.