> 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/zh/he-xin-gai-nian/choose-your-core.md).

# 选择你的核心

双通道应用可以将其核心逻辑保留在 Solidity 侧或原生 Solana 侧。这是一个判断题——请权衡对你的应用最重要的因素。

大多数 Rome 应用都是双通道的：一个共享状态，可同时被 MetaMask（EVM）和 Phantom（Solana）用户访问。你可以用两种镜像式架构来构建它，区别在于 **哪一侧承载核心逻辑。** 该选择哪一种并没有硬性规则——这是一种基于对以下因素重要性的综合判断： *你的* 应用：你已有的代码和资源、团队专长、安全态势、你偏好的工具链、性能，以及各用户群体将如何使用它。

## (a) Solidity 核心；Solana 用户通过合成发送者

你的逻辑是一个 Solidity 合约。Phantom 用户的 Solana 签名会作为来自其 Rome 派生身份的 EVM 交易执行（即 `external_auth` PDA）——他们无需 EVM 密钥。通常在你已经有一个 Solidity 合约（尤其是经过加固或审计的合约）、想使用标准 EVM 工具链（Hardhat / Foundry / viem），或者逻辑较为简单时，这种方案很合适。

*阅读：* [aerarium](https://github.com/rome-protocol/aerarium) ——一个由 EVM 和 Solana 用户共享的 Compound v3 借贷市场（Solidity 核心）。

## (b) 原生 Solana 程序核心；EVM 用户通过轻量 CPI 路由器访问

你的逻辑是一个原生 Solana 程序；一个轻量的 Solidity 路由器让 EVM 用户通过 CPI 访问它。通常在你已经有一个 Solana 程序，或者以原生方式运行核心逻辑对你正在构建的内容很重要时，这种方案很合适。

*阅读：* [rome-dex](https://github.com/rome-protocol/rome-dex) ——一个原生 AMM（Solana 核心）配合 EVM 路由器，因此两个通道都交易同一个资金池。

## 例如：性能

性能是其中一个 *可能* 左右选择——把它当作一个例子来看。对于复杂逻辑，原生 Solana 执行可能比 EVM 解释器便宜得多：我们测得的一次交换在原生环境下大约便宜 6 倍。如果你的应用有一条高频、计算密集的路径，这种差异可能对你很重要；如果没有，它大概不会影响决策。把它当作众多因素之一，而不是一条规则。

## 无论你选择哪种方式

保持核心逻辑 **与权限主体无关** ——根据签名的权限主体执行，因此调用方可以是 Solana 公钥 *或* 或 EVM 用户的 PDA——保持账户集合精简并适配 ALT，以便 EVM 通道保持低成本，并且 **测试两个通道。**

## 下一步

* [从 EVM 调用 Solana](/zh/kai-fa-zhe-zhi-nan/call-solana-from-evm.md) ——(b) 形态的 CPI 机制，以及任何 Solidity→Solana 调用。
* [计算预算](/zh/he-xin-gai-nian/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/zh/he-xin-gai-nian/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.