> 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/execution-model.md).

# Modelo de execução

Como a Rome EVM processa transações Ethereum na Solana — emulação por proxy, modos atômico (VmAt) vs. iterativo (VmIt) e o ciclo de vida completo da transação.

A Rome EVM executa bytecode Solidity dentro de um programa on-chain da Solana. Esta página explica como as transações EVM são processadas.

## Ciclo de vida da transação

```
1. O usuário assina a transação EVM (MetaMask / ethers.js)
                    ↓
2. O Rome Proxy recebe via eth_sendRawTransaction
                    ↓
3. O Proxy emula a transação off-chain (emulador Mollusk SVM)
   → Estima o gas, verifica a atomicidade, identifica as contas necessárias
                    ↓
4. O Proxy encapsula a transação EVM como instrução(ões) da Solana
   → Se a transação couber em uma transação Solana → Atômica (VmAt)
   → Se a transação exceder o orçamento de CU → Iterativa (VmIt)
                    ↓
5. O validador Solana executa a(s) instrução(ões)
   → O programa Rome EVM interpreta o bytecode EVM
   → Chamadas CPI para outros programas Solana (se houver)
                    ↓
6. Alterações de estado confirmadas nas contas Solana
                    ↓
7. Hercules indexa o evento → produz o bloco EVM
```

## Execução atômica (VmAt)

O modo padrão. Toda a transação EVM é executada em uma única transação Solana.

**Máquina de estados:** `Lock → Init → Execute → Commit → GasTransfer → Exit`

**Propriedades:**

* Execução tudo ou nada — se qualquer etapa falhar, toda a transação é revertida
* \~1,4M de unidades de computação disponíveis por transação Solana
* Adequado para transferências, chamadas simples de contratos, swaps e a maioria das operações DeFi
* Finalidade em menos de um segundo (tempo de bloco da Solana)

**Quando é usado:** Selecionado automaticamente quando o emulador determina que a transação cabe no orçamento computacional de uma única transação Solana.

## Execução iterativa (VmIt)

Para operações intensivas em computação que excedem o orçamento de uma única transação. A execução EVM é dividida entre várias transações Solana.

**Como funciona:**

1. Cada etapa (uma transação Solana) executa **quantos opcodes EVM couberem em seu orçamento computacional** — um tamanho de etapa adaptativo, não uma contagem fixa
2. Após cada etapa, o estado da VM é serializado (formato Borsh) em uma `StateHolder` conta
3. A próxima etapa desserializa o estado e continua a execução
4. As contas envolvidas são bloqueadas por TTL durante **3 a 4 segundos** durante a execução de várias etapas; uma sessão é limitada a **160 etapas**; após isso, a próxima etapa libera os bloqueios da sessão e a encerra sem confirmar nada

**Máquina de estados:** `FromStateHolder → Lock → Init → Execute → Serialize → NextIteration → ... → Completed`

**Bloqueio de contas:**

* Um **bloqueio exclusivo** por conta gerenciada (contas de saldo e armazenamento) — apenas uma sessão iterativa pode manter uma conta por vez; uma transação atômica que grava em uma conta bloqueada é recusada com `AccountLocked` até o bloqueio expirar, e o cliente reenviar
* **TTL:** 3 segundos, renovado a cada etapa (4 segundos quando a sessão acessa mais de 28 contas)
* **CPIs de trilha legada são recusadas** dentro de uma transação iterativa (`CpiProhibitedInIterativeTx`); os efeitos da trilha em cache são preparados e confirmados no final

**Quando é usado:** implantações grandes de contratos, pilhas de chamadas profundas, qualquer operação que exceda \~1,4M de CU. Uma verificação de emparelhamento BN254 por si só não precisa disso; consulte [Orçamento de computação](/pt-br/conceitos-principais/compute-budget.md).

## Emulação

Antes de enviar uma transação para a Solana, o Proxy a emula off-chain usando o **emulador Mollusk SVM**. Isso:

1. Estima o consumo de gas
2. Determina se o modo atômico ou iterativo é necessário
3. Identifica todas as contas Solana que a transação acessará
4. Valida que a transação não falhará on-chain

O emulador executa a mesma lógica EVM que o programa on-chain — a macro `entrypoint!` garante tabelas de despacho idênticas tanto no programa quanto nas bases de código do emulador.

**Mollusk SVM** também pode executar programas BPF arbitrários da Solana durante a emulação, o que significa `eth_call` e `eth_estimateGas` lidar corretamente com chamadas CPI para SPL Token, Jupiter, Kamino etc.

## Mapeamento de contas

Todo endereço Ethereum é mapeado para uma PDA da Solana:

```
Endereço Ethereum (H160, 20 bytes)
    ↓
PDA = findProgramAddress(
    [chain_id, "ACCOUN_SEED", H160, bump],
    ROME_EVM_PROGRAM_ID
)
    ↓
Conta Solana (Pubkey, 32 bytes)
```

**Tipos de contas armazenados on-chain:**

| Tipo          | Seeds                                        | Finalidade                                      |
| ------------- | -------------------------------------------- | ----------------------------------------------- |
| Saldo         | `[chain, "ACCOUN_SEED", H160, bump]`         | Nonce, saldo, código do contrato                |
| Armazenamento | `[chain, "STORAGE", H160, slot_index, bump]` | Armazenamento do contrato (256 slots por conta) |
| TxHolder      | `[signer, "TX_HOLDER_SEED", index, bump]`    | Dados da transação preparados (máx. 80 KB)      |
| StateHolder   | `[signer, "STATE_HOLDER_SEED", index, bump]` | Estado serializado da VM entre iterações        |

## Contas Holder

A Rome envia transações Solana **v1**, que são limitadas a 4 KB (4.096 bytes) e 64 endereços. As transações EVM — especialmente implantações de contratos — podem ser muito maiores.

**Mecanismo de divisão:**

1. O SDK divide a transação codificada em RLP em partes
2. Cada parte é gravada em uma `TxHolder` conta por meio de `TransmitTx` instruções
3. Quando todas as partes estão preparadas, uma `DoTxHolder` instrução monta e executa a transação completa
4. Tamanho máximo do holder: **80 KB** por TxHolder

Isso é completamente transparente para o desenvolvedor — o SDK Rome lida automaticamente com a divisão e a remontagem.

## Tipos de transação compatíveis

| Tipo                    | EIP       | Descrição                                                                                                                                                                                                                                   |
| ----------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Legacy                  | —         | Transações Ethereum tradicionais                                                                                                                                                                                                            |
| Lista de acesso         | EIP-2930  | Padrões de acesso ao estado otimizados                                                                                                                                                                                                      |
| Taxa dinâmica           | EIP-1559  | Taxa base + taxa de prioridade                                                                                                                                                                                                              |
| EIP-1559 sem assinatura | —         | Um app `0x02`-corpo tipado sem assinatura secp256k1, autorizado pela assinatura Ed25519 de uma carteira Solana em vez disso (a via Solana; consulte [Chamar EVM a partir da Solana](/pt-br/guias-do-desenvolvedor/call-evm-from-solana.md)) |
| Depósito                | Tipo 0x7E | Transações de depósito, por exemplo, liquidação de entrada de bridge                                                                                                                                                                        |

## Estado com journal

A Rome EVM usa um modelo de estado com journal para gerenciar alterações de estado durante a execução:

* Todas as alterações (nonce, saldo, armazenamento, código) são rastreadas em um `Journal`
* Operações CALL/CREATE aninhadas adicionam frames de snapshot
* Em caso de reversão: as entradas do journal retornam ao snapshot
* Em caso de sucesso: as alterações são confirmadas nas contas Solana
* Instruções CPI não EVM são executadas imediatamente (as próprias garantias de atomicidade da Solana asseguram a correção)

## O que Vem a Seguir

* [Orçamento de computação](/pt-br/conceitos-principais/compute-budget.md) — custos de CU e estratégias de otimização
* [Restrições](/pt-br/conceitos-principais/constraints.md) — limites e fronteiras importantes


---

# 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/execution-model.md?ask=<question>&goal=<user_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.