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

# Modelo de ejecución

Cómo Rome EVM procesa transacciones de Ethereum en Solana: emulación por proxy, modos atómico (VmAt) e iterativo (VmIt), y el ciclo de vida completo de la transacción.

Rome EVM ejecuta bytecode de Solidity dentro de un programa en cadena de Solana. Esta página explica cómo se procesan las transacciones EVM.

## Ciclo de vida de la transacción

```
1. El usuario firma la transacción EVM (MetaMask / ethers.js)
                    ↓
2. Rome Proxy la recibe vía eth_sendRawTransaction
                    ↓
3. El proxy emula la transacción fuera de la cadena (emulador Mollusk SVM)
   → Estima el gas, verifica la atomicidad, identifica las cuentas requeridas
                    ↓
4. El proxy envuelve la tx EVM como instrucción(es) de Solana
   → Si la tx cabe en una sola tx de Solana → Atómica (VmAt)
   → Si la tx supera el presupuesto de CU → Iterativa (VmIt)
                    ↓
5. El validador de Solana ejecuta la(s) instrucción(es)
   → El programa Rome EVM interpreta el bytecode EVM
   → Llamadas CPI a otros programas de Solana (si las hay)
                    ↓
6. Los cambios de estado se confirman en las cuentas de Solana
                    ↓
7. Hercules indexa el evento → produce el bloque EVM
```

## Ejecución atómica (VmAt)

El modo predeterminado. Toda la transacción EVM se ejecuta dentro de una sola transacción de Solana.

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

**Propiedades:**

* Ejecución de todo o nada — si cualquier paso falla, toda la transacción se revierte
* \~1,4 M unidades de cómputo disponibles por transacción de Solana
* Adecuado para transferencias, llamadas simples a contratos, swaps y la mayoría de las operaciones DeFi
* Finalidad en menos de un segundo (tiempo de bloque de Solana)

**Cuándo se usa:** Se selecciona automáticamente cuando el emulador determina que la transacción cabe dentro del presupuesto de cómputo de una sola transacción de Solana.

## Ejecución iterativa (VmIt)

Para operaciones intensivas en cómputo que superan el presupuesto de una sola transacción. La ejecución EVM se divide en múltiples transacciones de Solana.

**Cómo funciona:**

1. Cada paso (una transacción de Solana) ejecuta **tantos opcodes EVM como caben en su presupuesto de cómputo** — un tamaño de paso adaptable, no un número fijo
2. Después de cada paso, el estado de la VM se serializa (formato Borsh) en un `StateHolder` cuenta
3. El siguiente paso deserializa el estado y continúa la ejecución
4. Las cuentas involucradas se bloquean con TTL durante **3-4 segundos** durante la ejecución de varios pasos; una sesión tiene un límite de **160 pasos**; más allá de eso, el siguiente paso libera los bloqueos de la sesión y la termina sin confirmar nada

**Máquina de estados:** `Desde StateHolder → Bloquear → Iniciar → Ejecutar → Serializar → SiguienteIteración → ... → Completado`

**Bloqueo de cuentas:**

* Un **bloqueo exclusivo** por cada cuenta gestionada (cuentas de saldo y de almacenamiento) — solo una sesión iterativa puede mantener una cuenta a la vez; una transacción atómica que escriba en una cuenta bloqueada se rechaza con `AccountLocked` hasta que el bloqueo caduque, y el cliente lo reenvía
* **TTL:** 3 segundos, renovados en cada paso (4 segundos cuando la sesión toca más de 28 cuentas)
* **Las CPI de la ruta heredada se rechazan** dentro de una transacción iterativa (`CpiProhibitedInIterativeTx`); los efectos de la ruta en caché se preparan y se confirman al final

**Cuándo se usa:** despliegues grandes de contratos, pilas de llamadas profundas, cualquier operación que supere \~1,4 M CU. Una verificación de emparejamiento BN254 por sí sola no lo necesita; véase [Presupuesto de cómputo](/es/conceptos-basicos/compute-budget.md).

## Emulación

Antes de enviar una transacción a Solana, el Proxy la emula fuera de la cadena usando el **emulador Mollusk SVM**. Esto:

1. Estima el consumo de gas
2. Determina si se necesita el modo atómico o iterativo
3. Identifica todas las cuentas de Solana que tocará la transacción
4. Valida que la transacción no fallará en cadena

El emulador ejecuta la misma lógica EVM que el programa en cadena — la `macro entrypoint!` garantiza tablas de despacho idénticas en las bases de código del programa y del emulador.

**Mollusk SVM** también puede ejecutar programas BPF arbitrarios de Solana durante la emulación, lo que significa `eth_call` y `eth_estimateGas` que puede manejar correctamente llamadas CPI a SPL Token, Jupiter, Kamino, etc.

## Mapeo de cuentas

Toda dirección de Ethereum se mapea a una PDA de Solana:

```
Dirección de Ethereum (H160, 20 bytes)
    ↓
PDA = findProgramAddress(
    [chain_id, "ACCOUN_SEED", H160, bump],
    ROME_EVM_PROGRAM_ID
)
    ↓
Cuenta de Solana (Pubkey, 32 bytes)
```

**Tipos de cuenta almacenados en cadena:**

| Tipo           | Semillas                                     | Propósito                                          |
| -------------- | -------------------------------------------- | -------------------------------------------------- |
| Balance        | `[chain, "ACCOUN_SEED", H160, bump]`         | Nonce, balance, código del contrato                |
| Almacenamiento | `[chain, "STORAGE", H160, slot_index, bump]` | Almacenamiento del contrato (256 slots por cuenta) |
| TxHolder       | `[signer, "TX_HOLDER_SEED", index, bump]`    | Datos de transacción preparados (máx. 80 KB)       |
| StateHolder    | `[signer, "STATE_HOLDER_SEED", index, bump]` | Estado de la VM serializado entre iteraciones      |

## Cuentas contenedoras

Rome envía transacciones de Solana **v1**, que están limitadas a 4 KB (4.096 bytes) y 64 direcciones. Las transacciones EVM — especialmente los despliegues de contratos — pueden ser mucho más grandes.

**Mecanismo de división:**

1. El SDK divide la transacción codificada en RLP en fragmentos
2. Cada fragmento se escribe en una `TxHolder` cuenta mediante `TransmitTx` instrucciones
3. Una vez que todos los fragmentos están preparados, una `DoTxHolder` instrucción ensambla y ejecuta la transacción completa
4. Tamaño máximo del contenedor: **80 KB** por TxHolder

Esto es completamente transparente para el desarrollador — el SDK de Rome gestiona automáticamente la división y el reensamblado.

## Tipos de transacción compatibles

| Tipo                | EIP       | Descripción                                                                                                                                                                                                                         |
| ------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Legacy              | —         | Transacciones tradicionales de Ethereum                                                                                                                                                                                             |
| Lista de acceso     | EIP-2930  | Patrones optimizados de acceso al estado                                                                                                                                                                                            |
| Comisión dinámica   | EIP-1559  | Comisión base + comisión de prioridad                                                                                                                                                                                               |
| EIP-1559 sin firmar | —         | Una app `0x02`cuerpo tipado sin firma secp256k1, autorizado en su lugar por la firma Ed25519 de una cartera de Solana (la vía de Solana; véase [Llamar a EVM desde Solana](/es/guias-para-desarrolladores/call-evm-from-solana.md)) |
| Depósito            | Tipo 0x7E | Transacciones de depósito, por ejemplo, liquidación entrante del puente                                                                                                                                                             |

## Estado con diario

Rome EVM utiliza un modelo de estado con diario para gestionar los cambios de estado durante la ejecución:

* Todos los cambios (nonce, balance, almacenamiento, código) se registran en un `Diario`
* Las operaciones anidadas CALL/CREATE apilan marcos de instantánea
* En caso de reversión: las entradas del diario retroceden a la instantánea
* En caso de éxito: los cambios se confirman en las cuentas de Solana
* Las instrucciones CPI no EVM se ejecutan inmediatamente (la atomicidad propia de Solana garantiza la corrección)

## Qué sigue

* [Presupuesto de cómputo](/es/conceptos-basicos/compute-budget.md) — costos de CU y estrategias de optimización
* [Restricciones](/es/conceptos-basicos/constraints.md) — límites y fronteras 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/es/conceptos-basicos/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.