> 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/ru/nachalo-raboty/key-concepts.md).

# Ключевые понятия

Основная терминология и концепции для разработки на Rome Protocol.

## Понятия Solana

**Программа** — Аналог смарт-контракта в Solana. Программы — это исполняемые программы без состояния, развёртываемые в блокчейне. Rome EVM сам по себе является программой Solana.

**Счёт** — Всё состояние в Solana хранится в счетах. У каждого счёта есть владелец (программа), баланс (лампорты) и данные. В отличие от Ethereum, код и состояние хранятся в отдельных счетах.

**PDA (адрес, производный от программы)** — Детерминированный адрес, полученный из сидов и идентификатора программы. PDA позволяют программам «владеть» счетами без приватного ключа. Rome использует PDA для сопоставления адресов Ethereum со счетами Solana.

**CPI (межпрограммный вызов)** — Одна программа Solana вызывает другую в рамках той же транзакции. Так контракты Rome EVM взаимодействуют с Jupiter, Kamino, SPL Token и другими программами Solana.

**SPL Token** — Стандартная токен-программа Solana. Эквивалент ERC-20 в Ethereum. Все взаимозаменяемые токены в Solana (USDC, SOL и т. д.) являются токенами SPL.

**Token-2022** — Токен-программа SPL нового поколения с расширениями, такими как Transfer Hooks, Confidential Transfers и Permanent Delegates.

**Transfer Hook** — Расширение Token-2022, которое вызывает программу при каждом `transfer_checked` вызове.

**ATA (ассоциированный токеновый счёт)** — Детерминированный токеновый счёт для конкретной пары кошелёк + mint. У каждого пользователя есть один ATA на каждый токен, который он хранит.

**Лампорты** — Наименьшая единица SOL. 1 SOL = 1 000 000 000 лампортов (10^9).

**Compute Units (CU)** — Аналог газа Ethereum в Solana. У каждой транзакции есть бюджет вычислений (по умолчанию около 200 тыс. CU, максимум около 1,4 млн CU). Операции потребляют CU.

## Понятия Rome

**Программа Rome EVM** — Программа Solana, содержащая интерпретатор байткода EVM. Развёртывается с определённым идентификатором программы для каждой среды.

**Chain ID** — Каждое приложение в Rome получает свой собственный EVM chain ID. Это создаёт изолированные EVM-среды, которые используют одно и то же базовое состояние Solana.

**Атомарное выполнение (VmAt)** — EVM-транзакция, выполняющаяся полностью в рамках одной транзакции Solana. Используется для большинства операций.

**Итеративное выполнение (VmIt)** — EVM-транзакция, разделённая на несколько транзакций Solana, где каждый шаг упаковывает столько opcode, сколько помещается в бюджет вычислений одной транзакции Solana (адаптивно, а не фиксированным числом). Используется для вычислительно интенсивных операций, таких как BN254 pairing.

**Счёт-буфер** — Ончейн-буфер, который хранит крупные EVM-транзакции (до 80 КБ), превышающие лимит размера транзакции Solana в 1 232 байта. Управляется SDK прозрачно.

**StateHolder** — Ончейн-счёт, который хранит сериализованное состояние VM между шагами итеративного выполнения.

**Rome Proxy** — JSON-RPC-сервер (порт 9090), который преобразует вызовы Ethereum API в транзакции Solana. К нему подключаются MetaMask и Hardhat.

**Hercules** — Индексатор блоков, который отслеживает события Rome EVM в Solana и формирует данные блоков, совместимые с Ethereum.

**Плательщик** — Ключевая пара Solana, которая подписывает и оплачивает транзакции Solana от имени пользователей EVM. Управляется Proxy через пулы плательщиков.

## Понятия токенов

**SPL\_ERC20 / SPL\_ERC20\_cached** — Контракты-обёртки ERC-20, представляющие SPL-токен внутри Rome EVM. Обёртка считывает балансы напрямую из базового счета SPL-токена — отдельного состояния нет. Сегодня фабрика развёртывает кэшированную версию.

**ERC20SPLFactory** — Контракт-фабрика, который развёртывает обёртки для любого SPL-токена.

**Реестр** — Канонические обёртки, газовые токены и настройки моста курируются вне цепочки в [rome-protocol/registry](https://github.com/rome-protocol/rome-registry); в блокчейне нет контракта реестра токенов. Это удерживает каждый актив привязанным к единственному каноническому SPL mint.

## Предкомпилированные контракты

**Стандартные предкомпилированные контракты Ethereum** — ecrecover (0x01), SHA-256 (0x02), RIPEMD-160 (0x03), identity (0x04), modexp (0x05), BN254 ecAdd/ecMul/ecPairing (0x06-0x08), Blake2f (0x09).

**Системный предкомпилированный контракт** (`0xFF...07`) — получение PDA и преобразование в base58 из Solidity.

**CpiProgram — предкомпилированный контракт** (`0xFF...08`) — межпрограммный вызов (`invoke` / `invoke_signed`) плюс сокращённые пути для чтения между состояниями.

**HelperProgram — предкомпилированный контракт** (`0xFF...09`) — создание ATA/PDA, переводы SPL и преобразование gas↔lamports; основной интерфейс для SPL-операций, подписываемых пользовательским PDA.

**Контракт вывода** (`0x42...16`) — вывод SOL или SPL-токенов из EVM обратно в Solana.

Семейство кэшированного трека (`0xff…04/05/06/0b`) отражает их для чтений с эффективным использованием CU; контракт последовательно использует один трек.

## Типы транзакций

**RheaTx** — Одна EVM-транзакция в одном rollup. Самый распространённый тип.

**RemusTx** — Несколько EVM-транзакций в разных rollup, выполняемых атомарно. Если хотя бы одна транзакция завершается сбоем, все откатываются.

**RomulusTx** — Комбинированные EVM-транзакции + нативные инструкции Solana в одной атомарной операции. Самый мощный тип — сочетание Solidity и Solana в одной транзакции.

## Что дальше

* [Модель выполнения](/ru/osnovnye-ponyatiya/execution-model.md) — подробный разбор того, как EVM-транзакции выполняются в Solana
* [Интероперабельность токенов](/ru/osnovnye-ponyatiya/token-interop.md) — как взаимодействуют ERC-20 и SPL-токены
* [Ограничения](/ru/osnovnye-ponyatiya/constraints.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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.rome.builders/ru/nachalo-raboty/key-concepts.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.