> 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/introducao/architecture.md).

# Arquitetura

Como os componentes da Rome se encaixam — execução EVM dentro de um programa da Solana.

A Rome incorpora um interpretador de bytecode da EVM dentro de um programa on-chain da Solana. Os usuários se comunicam com o Rome Proxy via o JSON-RPC padrão da Ethereum, e o proxy envia suas transações diretamente para o programa Rome EVM na Solana. Não há uma camada de execução separada para manter em sincronia — estado da EVM *é* estado da Solana.

## Visão geral do sistema

<figure><img src="https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-12ba59ef1fa43d6d8b5565a98efca4375a4d79c0%2Farchitecture.svg?alt=media" alt="User to Rome Proxy to the Rome EVM program on Solana, with Hercules indexing back"><figcaption></figcaption></figure>

## Componentes

### Programa Rome EVM (on-chain)

O núcleo da Rome — um programa BPF da Solana que contém um interpretador completo de bytecode da EVM (um fork do SputnikVM). Ele:

* Recebe transações EVM serializadas como instruções da Solana
* Executa bytecode de Solidity dentro do runtime da Solana
* Mapeia cada endereço Ethereum (H160) para uma PDA da Solana
* Expõe precompilações para chamar a Solana (CPI, System, Helper, Withdraw) ao lado das precompilações padrão da Ethereum
* Armazena o estado da EVM (saldos, nonce, código, armazenamento) como dados de conta da Solana

### Rome Proxy (servidor JSON-RPC)

Um servidor padrão Ethereum JSON-RPC na porta 9090 — o ponto de entrada para as redes públicas. Ele traduz chamadas da API Ethereum em atividade na Solana:

* `eth_sendRawTransaction` → serializa a tx da EVM → envia uma instrução da Solana
* `eth_call` → emula a execução off-chain via o emulador SVM Mollusk
* `eth_estimateGas` → simula para estimativa de gas
* `eth_getBalance`, `eth_getCode`, `eth_getBlockByNumber`, recibos, logs → servidos a partir do estado indexado

Ele também expõe extensões da Rome: `rome_emulateTx`, `rome_emulateRegRollup`, `rome_mintId`, `rome_buildInfo`, `rome_getResources`, e muito mais.

### Hercules (indexador)

Monitora o programa Rome EVM na Solana e reconstrói blocos compatíveis com Ethereum — transações, recibos, logs e mudanças de estado — com suporte de PostgreSQL. Nas redes públicas, ele opera em modo alinhado ao slot, então um número de bloco mapeia para um slot da Solana e o mesmo slot gera o mesmo bloco em qualquer indexador. O proxy serve esses blocos para carteiras e exploradores.

### Precompiles

A Rome implementa as precompilações padrão da Ethereum (ecrecover, SHA-256, RIPEMD-160, identity, modexp, as operações da curva BN254, blake2f) com semântica equivalente à mainnet, além de precompilações não-EVM que acessam a Solana: **CpiProgram** (`0xFF…08`, CPI arbitrária), **System** (`0xFF…07`, derivação de PDA e auxiliares base58), **HelperProgram** (`0xFF…09`, criação de ATA/PDA, transferências SPL, gas↔lamports), e **Withdraw** (`0x42…16`). Veja a [referência de Endereços de Contrato](/pt-br/referencia/contract-addresses.md) referência para a tabela completa.

## Modos de execução

A Rome executa uma transação da EVM de uma de duas maneiras:

### Atômico (VmAt)

Uma única transação da Solana. Toda a transação da EVM é executada dentro do orçamento de computação de uma transação da Solana (\~1,4 milhão de unidades de computação). Usado para a maioria das operações — transferências, chamadas comuns de contrato, swaps.

### Iterativo (VmIt)

Para trabalho que excede o orçamento de uma única transação. A execução é dividida em várias transações da Solana:

1. Cada etapa (uma transação da Solana) executa o máximo de opcodes da EVM que couberem em seu orçamento de computação — o tamanho da etapa é adaptativo, não fixo
2. O estado da VM é serializado em Borsh em uma `StateHolder` conta entre as etapas
3. As contas ficam bloqueadas por TTL por alguns segundos durante a execução
4. Usado para operações pesadas como o emparelhamento BN254

## Mapeamento de contas

Cada endereço Ethereum mapeia deterministamente para uma PDA da Solana derivada do chain ID e do endereço sob o programa Rome EVM. Essa PDA possui o saldo da conta (como contas de token SPL), o código do contrato, os slots de armazenamento e o nonce — tudo como dados de conta da Solana.

## Contas holder

Transações da Solana (v1) têm limite de 4 KB, mas transações da EVM (especialmente implantações de contratos) podem ser muito maiores. A Rome divide transações grandes em **contas holder**: a transação é dividida em partes gravadas sequencialmente em um holder (até 80 KB), depois montada e executada on-chain. O SDK da Rome gerencia isso de forma transparente.

## Gas e precificação

Cada rede tem seu próprio token de gas — qualquer token SPL. A precificação do gas lê uma pool Meteora DAMM (v1 ou v2, configurável) para converter entre o token de gas e SOL para as taxas subjacentes da transação da Solana.

## O que vem a seguir

* [Redes](/pt-br/redes/networks.md) — conecte-se ao Hadrian
* [Início rápido](/pt-br/introducao/quickstart.md) — implante seu primeiro contrato
* [Modelo de execução](/pt-br/conceitos-principais/execution-model.md) — execução atômica vs iterativa em detalhes


---

# 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/introducao/architecture.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.
