> 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/ko/getting-started/architecture.md).

# 아키텍처

Rome의 구성 요소가 어떻게 맞물리는지 — Solana 프로그램 내부에서의 EVM 실행.

Rome은 Solana 온체인 프로그램 내부에 EVM 바이트코드 인터프리터를 내장합니다. 사용자는 표준 Ethereum JSON-RPC를 통해 Rome Proxy와 통신하며, 프록시는 그들의 트랜잭션을 Solana의 Rome EVM 프로그램으로 직접 제출합니다. 동기화해야 할 별도의 실행 레이어는 없습니다 — EVM 상태 *인 것을 선택하세요* Solana 상태.

## 시스템 개요

<figure><img src="https://1350471780-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>

## 구성 요소

### Rome EVM 프로그램(온체인)

Rome의 핵심 — 완전한 EVM 바이트코드 인터프리터(SputnikVM의 포크)를 포함하는 Solana BPF 프로그램입니다. 다음을 수행합니다:

* 직렬화된 EVM 트랜잭션을 Solana 지시문으로 수신합니다
* Solana 런타임 내부에서 Solidity 바이트코드를 실행합니다
* 각 Ethereum 주소(H160)를 Solana PDA에 매핑합니다
* 표준 Ethereum 프리컴파일과 함께 Solana(CPI, System, Helper, Withdraw) 호출용 프리컴파일을 노출합니다
* EVM 상태(잔액, nonce, 코드, 저장소)를 Solana 계정 데이터로 저장합니다

### Rome Proxy(JSON-RPC 서버)

포트 9090의 표준 Ethereum JSON-RPC 서버 — 공개 체인의 진입점입니다. Ethereum API 호출을 Solana 작업으로 변환합니다:

* `eth_sendRawTransaction` → EVM 트랜잭션을 직렬화 → Solana 지시문 제출
* `eth_call` → Mollusk SVM 에뮬레이터를 통해 오프체인에서 실행을 에뮬레이션
* `eth_estimateGas` → 가스 추정을 위해 시뮬레이션
* `eth_getBalance`, `eth_getCode`, `eth_getBlockByNumber`, 영수증, 로그 → 인덱싱된 상태에서 제공

또한 Rome 확장 기능을 노출합니다: `rome_emulateTx`, `rome_emulateRegRollup`, `rome_mintId`, `rome_buildInfo`, `rome_getResources`, 그 외에도.

### Hercules(인덱서)

Solana의 Rome EVM 프로그램을 모니터링하고 PostgreSQL을 기반으로 Ethereum 호환 블록 — 트랜잭션, 영수증, 로그, 상태 변경 — 을 재구성합니다. 공개 체인에서는 슬롯 정렬 모드로 실행되므로 블록 번호는 Solana 슬롯에 매핑되고, 동일한 슬롯은 어떤 인덱서에서든 동일한 블록을 생성합니다. 프록시는 이 블록들을 지갑과 익스플로러에 제공합니다.

### 프리컴파일

Rome은 표준 Ethereum 프리컴파일(ecrecover, SHA-256, RIPEMD-160, identity, modexp, BN254 곡선 연산, blake2f)을 메인넷과 동등한 의미론으로 구현하며, Solana에 접근하는 비-EVM 프리컴파일도 추가로 제공합니다: **CpiProgram** (`0xFF…08`, 임의 CPI), **시스템** (`0xFF…07`, PDA 파생 및 base58 헬퍼), **HelperProgram** (`0xFF…09`, ATA/PDA 생성, SPL 전송, 가스↔lamports), 그리고 **출금** (`0x42…16`). 다음을 참조하세요: [컨트랙트 주소](/ko/reference/contract-addresses.md) 전체 표는 참조를 확인하세요.

## 실행 모드

Rome은 EVM 트랜잭션을 두 가지 방식 중 하나로 실행합니다:

### 원자적(VmAt)

단일 Solana 트랜잭션. 전체 EVM 트랜잭션이 하나의 Solana 트랜잭션 계산 예산(\~140만 컴퓨트 유닛) 내에서 실행됩니다. 대부분의 작업 — 전송, 일반적인 컨트랙트 호출, 스왑 — 에 사용됩니다.

### 반복적(VmIt)

단일 트랜잭션의 예산을 초과하는 작업에 사용됩니다. 실행은 여러 Solana 트랜잭션으로 나뉩니다:

1. 각 단계(Solana 트랜잭션)는 자신의 계산 예산에 들어가는 만큼의 EVM opcode를 실행합니다 — 단계 크기는 고정이 아니라 적응형입니다
2. VM 상태는 Borsh로 직렬화되어 `StateHolder` 단계 사이에 계정에 저장됩니다
3. 계정은 실행 중 몇 초 동안 TTL 잠금됩니다
4. BN254 페어링과 같은 무거운 작업에 사용됩니다

## 계정 매핑

모든 Ethereum 주소는 Rome EVM 프로그램 아래에서 체인 ID와 주소로부터 파생된 Solana PDA에 결정적으로 매핑됩니다. 그 PDA가 계정의 잔액(SPL 토큰 계정으로), 컨트랙트 코드, 저장 슬롯, nonce를 소유합니다 — 모두 Solana 계정 데이터로 저장됩니다.

## 홀더 계정

Solana(v1) 트랜잭션은 4KB로 제한되지만, EVM 트랜잭션(특히 컨트랙트 배포)은 훨씬 더 클 수 있습니다. Rome은 큰 트랜잭션을 다음에 단계적으로 적재합니다 **홀더 계정**: 트랜잭션은 청크로 분할되어 홀더에 순차적으로 기록되고(최대 80KB), سپس 조립되어 온체인에서 실행됩니다. Rome SDK가 이를 투명하게 관리합니다.

## 가스 및 가격 책정

각 체인은 고유한 가스 토큰 — 임의의 SPL 토큰 — 을 가집니다. 가스 가격 책정은 Meteora DAMM 풀(v1 또는 v2, 설정 가능)을 읽어 가스 토큰과 SOL 사이를 변환하여 기본 Solana 트랜잭션 수수료를 계산합니다.

## 다음 단계

* [네트워크](/ko/networks/networks.md) — Hadrian에 연결
* [빠른 시작](/ko/getting-started/quickstart.md) — 첫 번째 계약 배포
* [실행 모델](/ko/core-concepts/execution-model.md) — 원자적 실행 vs 반복적 실행 심층 설명


---

# 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/ko/getting-started/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.
