> 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/introduccion/architecture.md).
# Arquitectura
Cómo encajan los componentes de Rome: ejecución EVM dentro de un programa de Solana.
Rome integra un intérprete de bytecode EVM dentro de un programa on-chain de Solana. Los usuarios se comunican con Rome Proxy mediante JSON-RPC estándar de Ethereum, y el proxy envía sus transacciones directamente al programa Rome EVM en Solana. No hay una capa de ejecución separada que mantener sincronizada — estado EVM *es* estado de Solana.
## Descripción general del sistema
## Componentes
### Programa Rome EVM (on-chain)
El núcleo de Rome: un programa BPF de Solana que contiene un intérprete completo de bytecode EVM (una bifurcación de SputnikVM). Hace lo siguiente:
* Recibe transacciones EVM serializadas como instrucciones de Solana
* Ejecuta bytecode de Solidity dentro del runtime de Solana
* Mapea cada dirección de Ethereum (H160) a un PDA de Solana
* Expone precompilados para llamar a Solana (CPI, System, Helper, Withdraw) junto con los precompilados estándar de Ethereum
* Almacena el estado EVM (saldos, nonce, código, almacenamiento) como datos de cuenta de Solana
### Rome Proxy (servidor JSON-RPC)
Un servidor JSON-RPC estándar de Ethereum en el puerto 9090 — el punto de entrada para las cadenas públicas. Traduce las llamadas a la API de Ethereum en actividad de Solana:
* `eth_sendRawTransaction` → serializar la tx EVM → enviar una instrucción de Solana
* `eth_call` → emular la ejecución fuera de la cadena mediante el emulador SVM de Mollusk
* `eth_estimateGas` → simular para la estimación de gas
* `eth_getBalance`, `eth_getCode`, `eth_getBlockByNumber`, recibos, logs → se sirven desde el estado indexado
También expone extensiones de Rome: `rome_emulateTx`, `rome_emulateRegRollup`, `rome_mintId`, `rome_buildInfo`, `rome_getResources`y más.
### Hercules (indexador)
Observa el programa Rome EVM en Solana y reconstruye bloques compatibles con Ethereum — transacciones, recibos, logs y cambios de estado — respaldado por PostgreSQL. En las cadenas públicas se ejecuta en modo alineado con slots, de modo que un número de bloque se asigna a un slot de Solana y el mismo slot produce el mismo bloque en cualquier indexador. El proxy sirve estos bloques a wallets y exploradores.
### Precompilados
Rome implementa los precompilados estándar de Ethereum (ecrecover, SHA-256, RIPEMD-160, identity, modexp, las operaciones de la curva BN254, blake2f) con semántica equivalente a la de mainnet, además de precompilados no EVM que interactúan con Solana: **CpiProgram** (`0xFF…08`, CPI arbitraria), **System** (`0xFF…07`, derivación de PDA y utilidades base58), **HelperProgram** (`0xFF…09`, creación de ATA/PDA, transferencias SPL, gas↔lamports), y **Withdraw** (`0x42…16`). Consulta la [Contract Addresses](/es/referencia/contract-addresses.md) referencia para la tabla completa.
## Modos de ejecución
Rome ejecuta una transacción EVM de una de dos maneras:
### Atómico (VmAt)
Una sola transacción de Solana. Toda la transacción EVM se ejecuta dentro del presupuesto de cómputo de una transacción de Solana (\~1,4 millones de unidades de cómputo). Se usa para la mayoría de las operaciones — transferencias, llamadas ordinarias a contratos, swaps.
### Iterativo (VmIt)
Para trabajo que supera el presupuesto de una sola transacción. La ejecución se divide en múltiples transacciones de Solana:
1. Cada paso (una transacción de Solana) ejecuta tantos opcodes EVM como quepan en su presupuesto de cómputo — el tamaño del paso es adaptativo, no fijo
2. El estado de la VM se serializa con Borsh en una `StateHolder` cuenta entre pasos
3. Las cuentas se bloquean con TTL durante unos segundos durante la ejecución
4. Se usa para operaciones pesadas como el emparejamiento BN254
## Mapeo de cuentas
Cada dirección de Ethereum se asigna determinísticamente a un PDA de Solana derivado del chain ID y la dirección bajo el programa Rome EVM. Ese PDA posee el saldo de la cuenta (como cuentas de tokens SPL), el código del contrato, los slots de almacenamiento y el nonce — todo como datos de cuenta de Solana.
## Cuentas contenedoras
Las transacciones de Solana (v1) tienen un límite de 4 KB, pero las transacciones EVM (especialmente los despliegues de contratos) pueden ser mucho más grandes. Rome prepara las transacciones grandes en **cuentas contenedoras**: la transacción se divide en fragmentos escritos secuencialmente en una cuenta contenedora (hasta 80 KB), luego se ensambla y se ejecuta on-chain. El SDK de Rome lo gestiona de forma transparente.
## Gas y precios
Cada cadena tiene su propio token de gas — cualquier token SPL. La fijación del precio del gas lee un pool DAMM de Meteora (v1 o v2, configurable) para convertir entre el token de gas y SOL para las comisiones subyacentes de la transacción de Solana.
## Qué sigue
* [Redes](/es/redes/networks.md) — conéctate a Hadrian
* [Inicio rápido](/es/introduccion/quickstart.md) — despliega tu primer contrato
* [Modelo de ejecución](/es/conceptos-basicos/execution-model.md) — ejecución atómica vs. iterativa en profundidad
---
# 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/introduccion/architecture.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.
