> 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/constraints.md). # Restrições Limites ao construir na Rome EVM — tamanho da transação da Solana, orçamento de \~1,4M CU, limites de accounts, layout de storage e como a Rome contorna cada um. Limites e fronteiras importantes ao desenvolver no Rome EVM. Entender essas restrições ajuda você a projetar contratos que funcionem de forma confiável. ## Limites de transação da Solana | Restrição | Valor | Impacto | | ----------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------- | | Tamanho da transação | 4 KB (4.096 bytes) | Rome envia transações Solana v1; transações EVM maiores são preparadas em contas holder (transparente) | | Unidades de computação por tx | \~1,4 milhão de CU | Operações que excederem isso usam o modo iterativo, que tem seus próprios limites (abaixo) | | Contas por tx | 64 endereços | Ao limite da transação v1; tudo o que a tx EVM e seus CPIs tocam, incluindo as próprias contas do Rome, conta | | Tamanho máximo do holder | 80 KB | Tamanho máximo de RLP para uma única transação EVM | ## Limites de execução do EVM | Restrição | Valor | Observações | | ------------------------------------------- | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Slots de armazenamento do contrato | 256 por conta de armazenamento | Várias contas de armazenamento podem ser criadas por contrato | | Opcodes por iteração | Adaptativo | Ajustado ao orçamento de CU de cada tx Solana (VmIt) | | TTL de bloqueio de conta | 3 s (4 s quando a sessão toca mais de 28 contas) | Durante a execução iterativa; renovado a cada etapa | | Duração da sessão iterativa | 160 etapas | Após o limite, a próxima etapa libera os bloqueios da sessão e a encerra sem confirmar nada | | Etapas planejadas pelo SDK Rome em Rust | 128 | O teto do compositor iterativo; chamadas reais se resolvem em muito menos | | Transações por plano assinado pela carteira | 64 | No máximo `rome_submitSignedV1Plan` aceita em uma única chamada; veja [Chamadas retransmitidas e chamadas longas](/pt-br/guias-do-desenvolvedor/call-evm-from-solana.md#relayed-calls-and-long-calls) | | Carteiras de tesouraria | 64 | Carteiras do pool de taxas | | Limite de tamanho do contrato | 24 KB | Igual ao Ethereum (EIP-170, 24.576 bytes) | ## Restrições de CPI | Restrição | Valor | Observações | | ------------------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ | | Profundidade de CPI | Máximo de 4 níveis | Limite de profundidade de CPI da Solana | | Contas por chamada de CPI | Dentro do limite de 64 endereços da transação | Compartilhado com todas as outras contas que a transação toca | | Profundidade de CPI + hook de transferência | Usa níveis de CPI | Hooks de transferência de dentro de CPI podem exceder a profundidade | | Uma trilha por contrato | Legado (`0xff…07/08/09`, `0x42…16`) **ou** em cache (`0xff…04/05/06/0b`) | Combinar chamadas modificadoras de ambos em uma transação é recusado | | CPI legado no modo iterativo | Não permitido | Um CPI de trilha legada em uma transação iterativa falha com `CpiProhibitedInIterativeTx`; efeitos da trilha em cache são permitidos | **A profundidade de CPI é a restrição mais crítica.** O Rome EVM consome um nível de CPI quando a Solana chama o programa Rome. Se seu contrato Solidity então chamar outro programa Solana via CPI, isso é nível 2. Se esse programa chamar outro, isso é nível 3. Você tem no máximo 4 níveis no total. ``` Nível 0: Solana Runtime → Programa Rome EVM Nível 1: Programa Rome EVM → seu alvo de CPI (por exemplo, Jupiter) Nível 2: Jupiter → outro programa (por exemplo, Raydium) Nível 3: Raydium → SPL Token (profundidade máxima) ``` ## Restrições de hook de transferência do Token-2022 | Restrição | Impacto | | ------------------------- | --------------------------------------------------------------------------------------------- | | Um hook por mint | Um mint Token-2022 tem um único slot de hook de transferência | | `transfer_checked` apenas | Hooks não são acionados em `transfer`. As operações de bridge do Rome usam `transfer_checked` | | Mint/burn sem hook | Controlado pela autoridade de mint, não por hooks | ## Restrições de gás e precificação | Restrição | Observações | | ----------------------------- | ------------------------------------------------------- | | Fonte de precificação do gás | pool Meteora DAMM, v1 ou v2 (token de gás SPL) | | Multiplicador do preço do gás | Configurável por proxy (`gas_price_mul`) | | Preço mínimo do gás | Definido pela configuração do proxy | | Estimativa de gás | Realizada off-chain via emulador Mollusk antes do envio | ## Restrições específicas da rede | Ambiente | ID da cadeia | ID do programa rome-evm | | ----------------- | ------------ | --------------------------------------------- | | Hadrian (testnet) | 200010 | `RPTWwELXAY4KC9ZPHhaxp7Sq1hHtU3HNEgLbSegCcWf` | | Rubicon (mainnet) | 7531 | `RomePq9X3iAoTr813HR7uRarafFDUJty6GdiEceYpzX` | ## Restrições de precompilado | Precompilado | Restrição | | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | Modexp (0x05) | **Desativado** — uma chamada reverte com `a chamada big_mod_exp está desativada` até que a Solana ative o `big_mod_exp` syscall | | BN254 ecPairing (0x08) | Cerca de 22 mil CU mais 12,8 mil por par, conforme a precificação do programa; uma verificação de quatro pares cabe em uma transação atômica | | Precompilado de CPI (0xFF...08) | As contas devem ser declaradas antecipadamente na transação Solana | ## Validação da transação | Regra | Efeito | | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Maleabilidade de assinatura (EIP-2) | Uma transação assinada cujo `s` valor de s está acima da metade da ordem da curva é rejeitado | | Formato RLP | Uma transação cuja lista RLP contém bytes excedentes após seu último item é rejeitada | | Opcode não implementado | Aborta a transação inteira (`IncompatibleVersionEVM(opcode)`); nada é confirmado e um contrato chamador não pode engoli-lo | | Medição de gás | Rome não tem uma tabela de gás por opcode: o gás passado para `CALL`/`CREATE` não é aplicado, e não existe stipend de 2300 gas — não confie em proteção contra reentrância baseada em stipend | ## Restrições do oráculo | Restrição | Valor | | -------------------------- | --------------------------------------------------------------------------- | | Staleness máxima padrão | 60 segundos | | Dados históricos de rodada | Não suportado — `getRoundData(roundId)` reverte | | EMA do Switchboard | Não suportado — `latestEMAData()` reverte no SwitchboardV3 | | Offsets do parser | Validados empiricamente — é preciso revalidar antes de uma nova implantação | ## Recomendações de design 1. **Mantenha a profundidade de CPI rasa.** Projete contratos para minimizar o aninhamento. Se você chama o Jupiter, que chama o Raydium, que chama o SPL Token, você está em 3 níveis — perigosamente perto do limite. 2. **Prefira o modo atômico.** Projete operações para caber em \~1,4 milhão de CU. O modo iterativo adiciona latência (bloqueios de 3-4 segundos), um limite de 160 iterações por sessão e um prompt de carteira por etapa na via Solana quando a própria carteira assina as etapas. Uma chamada que faz CPIs de trilha legada não pode ser executada de forma iterativa. 3. **Declare as contas antecipadamente.** Todas as contas Solana tocadas por CPI devem ser conhecidas no momento da criação da transação (a emulação do proxy as descobre). A descoberta dinâmica de contas dentro de uma chamada de CPI não é possível, e o total deve caber no limite de 64 endereços. 4. **Escolha uma trilha de precompilado por contrato.** Chamar um programa Solana personalizado (`invoke_signed`) é da trilha legada e apenas atômico; veja [Integrar um programa Solana](/pt-br/guias-do-desenvolvedor/integrate-solana-program.md). 5. **Use `transfer_checked`.** Se você estiver construindo qualquer coisa que interaja com tokens Token-2022, sempre use `transfer_checked` para garantir que os hooks sejam acionados. 6. **Teste o consumo de CU.** Meça as unidades de computação reais da Solana no recibo da transação (`computeUnitsConsumed`) — EVM `gasUsed` não é um proxy fiel para CU da Solana. Otimize com Yul para caminhos críticos. ## O que Vem a Seguir * [Orçamento de computação](/pt-br/conceitos-principais/compute-budget.md) — custos detalhados de CU por operação * [Interoperabilidade de tokens](/pt-br/conceitos-principais/token-interop.md) — modelo de bridge ERC-20 ↔ SPL * [Referência de precompilados](/pt-br/referencia/precompiles.md) — cada seletor e sua classe 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/pt-br/conceitos-principais/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.