> 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/de/kernkonzepte/choose-your-core.md). # Wähle deinen Kern Eine Dual-Lane-App kann ihre Kernlogik auf der Solidity-Seite oder der nativen Solana-Seite belassen. Das ist eine Ermessensentscheidung — wäge ab, was für deine App wichtig ist. Die meisten Rome-Apps sind zweispurig: ein gemeinsamer Zustand, auf den sowohl MetaMask- (EVM) als auch Phantom- (Solana-)Nutzer zugreifen. Man kann eine solche App in zwei spiegelbildlichen Formen bauen, die sich darin unterscheiden, **welche Seite die Kernlogik enthält.** Es gibt keine feste Regel, welche zu wählen ist — es ist eine weiche Abwägung dessen, was für *deine* App wichtig ist: der Code und die Assets, die du bereits hast, das Know-how deines Teams, dein Sicherheitsniveau, die Werkzeuge, die du bevorzugst, die Performance und wie jede Zielgruppe sie nutzen wird. ## (a) Solidity-Kern; Solana-Nutzer über einen synthetischen Absender Deine Logik ist ein Solidity-Vertrag. Die Solana-Signatur eines Phantom-Nutzers wird als EVM-Transaktion von seiner aus Rome abgeleiteten Identität aus ausgeführt (die `external_auth` PDA) — sie benötigen nie einen EVM-Schlüssel. Oft gut geeignet, wenn du bereits einen Solidity-Vertrag hast (insbesondere einen gehärteten oder auditierten), standardmäßige EVM-Tools (Hardhat / Foundry / viem) verwenden willst oder die Logik unkompliziert ist. *Lesen:* [aerarium](https://github.com/rome-protocol/aerarium) — ein Compound-v3-Kreditmarkt (Solidity-Kern), den sich EVM- und Solana-Nutzer teilen. ## (b) Nativer Solana-Programmkern; EVM-Nutzer über einen schlanken CPI-Router Deine Logik ist ein natives Solana-Programm; ein schlanker Solidity-Router ermöglicht es EVM-Nutzern, es per CPI zu erreichen. Oft gut geeignet, wenn du bereits ein Solana-Programm hast oder wenn es für das, was du baust, wichtig ist, den Kern nativ auszuführen. *Lesen:* [rome-dex](https://github.com/rome-protocol/rome-dex) — ein natives AMM (Solana-Kern) mit einem EVM-Router, sodass beide Fahrspuren über einen Pool handeln. ## Zum Beispiel: Performance Performance ist eine Sache, die *könnte* die Entscheidung beeinflussen kann — betrachte es als Beispiel. Die native Ausführung auf Solana kann bei rechenintensiver Logik deutlich günstiger sein als der EVM-Interpreter: Ein Swap, den wir gemessen haben, lief nativ ungefähr 6× günstiger. Wenn deine App einen stark genutzten, rechenintensiven Pfad hat, kann so ein Unterschied für dich wichtig sein; wenn nicht, wird er die Entscheidung wahrscheinlich nicht bestimmen. Betrachte es als einen von vielen Faktoren, nicht als Regel. ## Egal, wofür du dich entscheidest Halte den Kern **autoritätsunabhängig** — handle auf jede signierende Autorität, sodass der Aufrufer ein Solana-Public-Key sein kann *oder* die PDA eines EVM-Nutzers — halte den Accountsatz schlank und ALT-freundlich, damit die EVM-Fahrspur günstig bleibt, und **teste beide Fahrspuren.** ## Was als Nächstes kommt * [Solana aus EVM aufrufen](/de/entwicklerleitfaden/call-solana-from-evm.md) — die CPI-Mechanik für Form (b) und jeden Solidity→Solana-Aufruf. * [Compute Budget](/de/kernkonzepte/compute-budget.md) — mehr zu den Ausführungskosten. --- # 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/de/kernkonzepte/choose-your-core.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.