> 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/id/memulai/architecture.md).
# Arsitektur
Bagaimana komponen Rome saling terhubung — eksekusi EVM di dalam program Solana.
Rome menyematkan interpreter bytecode EVM di dalam program on-chain Solana. Pada jalur kunci EVM, pengguna mengirim transaksi EVM bertanda tangan ke Rome Proxy melalui Ethereum JSON-RPC standar. Proxy mengirimkannya ke program Rome EVM di Solana. Satu transaksi EVM dapat memerlukan beberapa transaksi Solana untuk menulis potongan ke akun holder atau menjalankan eksekusi iteratif. Pada jalur kunci Solana v1, proxy menyusun transaksi. Dompet Solana menandatanganinya dan mengirimkannya langsung ke Solana RPC. Tidak ada lapisan eksekusi terpisah untuk disinkronkan — state EVM *adalah* State Solana.
## Ikhtisar sistem
## Komponen
### Program Rome EVM (on-chain)
Inti dari Rome — program Solana BPF yang berisi interpreter bytecode EVM lengkap (sebuah fork dari SputnikVM). Program ini:
* Menerima transaksi EVM bertanda tangan dan body EIP-1559 tanpa tanda tangan sebagai instruksi Solana. Sebuah kunci Solana mengotorisasi body tanpa tanda tangan melalui tanda tangan fee payer Solana atau instruksi verifier Ed25519
* Menjalankan bytecode Solidity di dalam runtime Solana
* Memetakan setiap alamat Ethereum (H160) ke sebuah PDA saldo per chain yang berisi nonce, saldo native, dan kode. PDA penyimpanan terpisah dikaitkan dengan PDA saldo. Setiap alamat juga memiliki alamat yang diturunkan program untuk otoritas atas panggilan Solana, disebut **PDA otoritas eksternal**. PDA ini dibagikan oleh setiap chain pada program. PDA ini memiliki akun token SPL alamat tersebut dan menandatangani panggilan lintas program (CPI) miliknya
* Mengekspos precompile untuk memanggil Solana (CPI, System, Helper, Withdraw) bersama precompile Ethereum. Keluarga cached menambahkan SystemCached (`0xff…04`), SplCached (`0xff…05`), ASplCached (`0xff…06`), dan WithdrawCached (`0xff…0b`). Factory men-deploy wrapper pada jalur cached ini
* Menyimpan state EVM (saldo, nonce, kode, storage) sebagai data akun Solana
* Satu program Rome EVM menampung banyak chain ID. Chain ID merupakan bagian dari alamat PDA saldo dan storage, bukan dari PDA otoritas eksternal
### Rome Proxy (server JSON-RPC)
Rome Proxy adalah server JSON-RPC Ethereum standar. Pengguna terhubung ke `https://hadrian.testnet.romeprotocol.xyz/` untuk Hadrian (testnet) dan `https://rubicon.mainnet.romeprotocol.xyz/` untuk Rubicon (mainnet). Proxy menerjemahkan panggilan API Ethereum menjadi aktivitas Solana:
* `eth_sendRawTransaction` → mengirim satu atau beberapa transaksi Solana v1: atomik `DoTx`, potongan holder (`TransmitTx`) plus `DoTxHolder`, atau leg iteratif. Pembayar gabungan menandatangani dan membayar SOL. Penerima biaya gabungan mengumpulkan gas pengguna
* `eth_call` → menjalankan interpreter EVM secara native di emulator pada akun Solana aktif yang dibaca melalui RPC. Mollusk menjalankan program Solana yang dijangkau oleh CPI. Ini juga menjalankan program Rome EVM ketika proxy mengukur compute unit
* `eth_estimateGas` → mensimulasikan untuk estimasi gas. Satu unit gas adalah satu lamport biaya Solana. Estimasi tidak pernah di bawah 21.000
* `eth_getBalance`, `eth_getCode`, `eth_getTransactionCount`, `eth_getStorageAt` → membaca akun Solana aktif melalui emulator. `eth_getBlockByNumber`, receipt dan log berasal dari Hercules
Ini juga mengekspos ekstensi Rome: `rome_emulateTx`, `rome_emulateRegRollup`, `rome_mintId`, `rome_buildInfo` dan `rome_getResources`. Metode dompet Solana meliputi `rome_emulateCallAccounts`, `rome_composeUnsignedAtomicV1`, `rome_composeUnsignedIterativeV1`, `rome_submitSignedV1Plan`, `rome_relayUnsignedV1`, `rome_composeExternalDepositV1` dan `rome_sendUnsignedTransaction`. Proxy juga mengekspos `rome_solanaTxForEvmTx`.
### Hercules (pengindeks)
Hercules memantau program Rome EVM di Solana dan merekonstruksi blok yang kompatibel dengan Ethereum di PostgreSQL. Ini berisi transaksi, receipt, log, dan perubahan state. Pada chain publik, ia berjalan dalam mode slot-aligned, sehingga nomor blok dipetakan ke slot Solana dan slot yang sama menghasilkan blok yang sama pada pengindeks apa pun. Proxy menyajikan blok-blok ini ke dompet dan explorer.
Hercules mengindeks blok yang terkonfirmasi. Ia memeriksa ulang setiap blok pada finalized dan memuat ulangnya jika blockhash berubah. Sang [Melalui explorer](/id/aplikasi-di-rome/via.md) membaca data Hercules.
### Precompile
Rome mengimplementasikan ecrecover, SHA-256, RIPEMD-160, identity, operasi kurva BN254 dan blake2f dengan semantik Ethereum, kecuali data kegagalan dari BN254 dan blake2f. Panggilan BN254 atau blake2f yang gagal mengembalikan Rome's `Error(string)` data revert alih-alih buffer kosong. Modexp (`0x05`) dinonaktifkan dan me-revert dengan `"panggilan big_mod_exp dinonaktifkan"`. blake2f menolak lebih dari 1.000.000 putaran, yang diizinkan Ethereum.
Precompile non-EVM menjangkau Solana: **CpiProgram** (`0xFF…08`, CPI arbitrer), **System** (`0xFF…07`, derivasi PDA dan helper base58), **HelperProgram** (`0xFF…09`, pembuatan ATA/PDA, transfer SPL, gas↔lamports), dan **Withdraw** (`0x42…16`). Keluarga cached adalah **SystemCached** (`0xff…04`), **SplCached** (`0xff…05`), **ASplCached** (`0xff…06`dan **WithdrawCached** (`0xff…0b`). CPI lama berjalan segera dan hanya dalam transaksi atomik. CPI cached dicatat selama eksekusi dan dikirim saat commit. Mereka me-revert bersama EVM. Mereka dapat berjalan dalam transaksi iteratif. Lihat [Contract Addresses](/id/referensi/contract-addresses.md) referensi untuk tabel lengkap.
## Mode eksekusi
Rome mengeksekusi transaksi EVM dengan salah satu dari dua cara:
### Atomik (VmAt)
Satu transaksi Solana. Seluruh transaksi EVM dijalankan dalam satu anggaran compute transaksi Solana (\~1,4 juta compute unit). Digunakan untuk sebagian besar operasi — transfer, panggilan kontrak biasa, swap.
### Iteratif (VmIt)
Untuk pekerjaan yang melampaui anggaran satu transaksi. Eksekusi dipecah ke beberapa transaksi Solana:
1. Setiap langkah (sebuah transaksi Solana) menjalankan sebanyak opcode EVM yang muat dalam anggaran computenya — ukuran langkah bersifat adaptif, bukan tetap
2. State VM diserialisasi Borsh ke dalam sebuah `StateHolder` akun di antara langkah-langkah
3. Akun dikunci TTL selama beberapa detik selama eksekusi
Proxy kembali ke eksekusi iteratif ketika compute unit, heap, atau jumlah instruksi tidak muat dalam satu transaksi Solana. Satu sesi dibatasi hingga 160 iterasi. CPI jalur lama ditolak dalam transaksi iteratif, karena tidak dapat dipecah across legs. CPI jalur cached diizinkan.
## Pemetaan akun
Setiap alamat Ethereum dipetakan secara deterministik ke PDA saldo Solana yang diturunkan dari chain ID dan alamat di bawah program Rome EVM. Saldo gas native-nya adalah sebuah field dalam PDA itu, bersama nonce dan kode kontrak. Slot storage berada di PDA storage terpisah. Saldo SPL berada di akun token yang dimiliki oleh PDA otoritas eksternal terpisah. Otoritas itu dibagikan di setiap chain pada program yang sama.
## Dua cara masuk
* **Jalur kunci EVM:** sebuah dompet mengirim transaksi EVM yang ditandatangani secp256k1 ke Rome Proxy. Proxy mengirim transaksi Solana.
* **Jalur kunci Solana:** sebuah dompet mengotorisasi body EIP-1559 tanpa tanda tangan dengan kunci Solana-nya. Untuk rute v1 langsung, proxy menyusun transaksi Solana. Dompet menandatanganinya dan mengirimkannya langsung ke Solana RPC. Rute relay menggunakan proxy untuk mengirimkannya sebagai gantinya. Rute legacy yang lebih lama membuat dompet membangun, menandatangani, dan membayar sebuah `DoTxUnsigned` transaksi Solana, dan program menurunkan pengirim dari penandatangan Solana.
Kunci publik Solana dipetakan ke alamat sintetis `keccak256(pubkey)[12:]`, 20 byte terakhir dari hash. Lihat [Cara Solana dan EVM bertemu di Rome](/id/konsep-inti/how-solana-and-evm-meet.md).
## Siapa yang menandatangani panggilan ke Solana
Program Rome EVM menandatangani CPI dengan PDA otoritas eksternal dari pemanggil langsung precompile. Sebuah kontrak menandatangani sebagai dirinya sendiri. Untuk membelanjakan token SPL milik pengguna, kontrak memerlukan delegasi SPL dari pengguna tersebut. Pengguna memberikannya dengan `HelperProgram.approve_spl(spender, amount, mint)`. Panggilan langsung dari alamat EVM atau sintetis pengguna ke precompile menggunakan PDA otoritas eksternal pengguna.
## Akun holder
Transaksi Solana (v1) dibatasi 4 KB, tetapi transaksi EVM (terutama deployment kontrak) bisa jauh lebih besar. Rome memecah transaksi besar menjadi potongan 3.600 byte dan menulisnya secara berurutan ke **akun holder** (hingga 80 KB). Lalu ia merakit setiap transaksi dan mengeksekusinya on-chain. Rome SDK mengelolanya secara transparan. Biaya tanda tangan setiap potongan dibebankan ke gas pengirim.
## Gas dan penetapan harga
Setiap chain memiliki token gas sendiri: SOL atau token SPL. Sumber harga adalah Hermes API, pool Meteora DAMM v1, pool Meteora DAMM v2, atau harga tetap. Ini menyediakan konversi antara token gas dan SOL untuk biaya transaksi Solana yang mendasarinya.
* Satu unit gas adalah satu lamport biaya Solana
* `eth_gasPrice` adalah wei token gas per lamport
* Pengirim membayar biaya penerima dari saldo gas native-nya. Pembayar proxy membayar SOL
* Tanpa penerima biaya, seperti pada jalur atomik dompet Solana, tidak ada gas EVM yang dikenakan. Dompet membayar SOL secara langsung
* Saldo native memiliki 18 desimal. Ini didukung oleh SPL token gas yang disimpan di dompet program per-chain
## Finalitas
Rome menggunakan finalitas Solana. SDK menunggu `confirmed`. Hercules memeriksa ulang setiap blok yang diindeks pada `terselesaikan` dan memuat ulangnya jika blockhash berubah.
## Berikutnya
* [Jaringan](/id/jaringan/networks.md) — sambungkan ke Hadrian (testnet) dan Rubicon (mainnet)
* [Quickstart](/id/memulai/quickstart.md) — deploy kontrak pertama Anda
* [Model Eksekusi](/id/konsep-inti/execution-model.md) — eksekusi atomik vs iteratif secara mendalam
* [Interop Token](/id/konsep-inti/token-interop.md)
* [Batasan](/id/konsep-inti/constraints.md)
* [Call Solana from EVM](/id/panduan-pengembang/call-solana-from-evm.md)
* [Call EVM from Solana](/id/panduan-pengembang/call-evm-from-solana.md)
* [Referensi precompile](/id/referensi/precompiles.md)
* [Cara Solana dan EVM bertemu di Rome](/id/konsep-inti/how-solana-and-evm-meet.md)
---
# 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/id/memulai/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.
