> 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/klyuchevye-ponyatiya/choose-your-core.md).

# Выберите своё ядро

Приложение с двумя каналами может держать свою основную логику либо на стороне Solidity, либо на нативной стороне Solana. Это вопрос выбора — оценивайте, что важно для вашего приложения.

Большинство приложений Rome работают в двух режимах: единое общее состояние, к которому обращаются и пользователи MetaMask (EVM), и пользователи Phantom (Solana). Вы можете построить такое приложение в двух зеркальных вариантах, различающихся тем, **на какой стороне находится основная логика.** Строгого правила выбора нет — это мягкое решение, основанное на том, что важно для *вашего* приложения: код и ресурсы, которые у вас уже есть, экспертиза вашей команды, ваша модель безопасности, предпочитаемый стек инструментов, производительность и то, как будет использоваться каждый из вариантов аудитории.

## a) Ядро на Solidity; пользователи Solana через синтетического отправителя

Ваша логика — это контракт Solidity. Подпись пользователя Phantom в Solana выполняется как транзакция EVM от его идентичности, производной от Rome ( `external_auth` PDA) — им никогда не нужен ключ EVM. Часто это хороший вариант, если у вас уже есть контракт Solidity (особенно укреплённый или аудитированный), вы хотите использовать стандартные инструменты EVM (Hardhat / Foundry / viem) или логика проста.

*Читайте:* [aerarium](https://github.com/rome-protocol/aerarium) — кредитный рынок Compound v3 (ядро на Solidity), который используют и пользователи EVM, и пользователи Solana.

## b) Нативное ядро программы Solana; пользователи EVM через тонкий CPI-роутер

Ваша логика — нативная программа Solana; тонкий роутер на Solidity позволяет пользователям EVM обращаться к ней через CPI. Часто это хороший вариант, если у вас уже есть программа Solana или если для вашего проекта важно запускать ядро нативно.

*Читайте:* [rome-dex](https://github.com/rome-protocol/rome-dex) — нативный AMM (ядро Solana) с роутером EVM, чтобы оба потока торговали в одном пуле.

## Например: производительность

Производительность — это один из факторов, который *может* склонить выбор — рассматривайте это как пример. Нативное выполнение в Solana может быть значительно дешевле интерпретатора EVM для тяжёлой логики: одна своп-операция, которую мы измерили, при нативном выполнении обходилась примерно в 6 раз дешевле. Если в вашем приложении есть горячий, ресурсоёмкий путь, такая разница может быть для вас важна; если нет, она, вероятно, не будет определять решение. Рассматривайте это как один из факторов, а не как правило.

## Что бы вы ни выбрали

Сделайте ядро **независимым от источника полномочий** — действуйте на основании любой подписавшей полномочия стороны, чтобы вызывающей стороной мог быть pubkey Solana *или* PDA пользователя EVM — держите набор аккаунтов минимальным и совместимым с ALT, чтобы поток EVM оставался дешёвым, и **тестируйте оба потока.**

## Что дальше

* [Вызов Solana из EVM](/ru/rukovodstva-dlya-razrabotchikov/call-solana-from-evm.md) — механику CPI для варианта (b) и любой вызов Solidity→Solana.
* [Бюджет вычислений](/ru/klyuchevye-ponyatiya/compute-budget.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/ru/klyuchevye-ponyatiya/choose-your-core.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.
