Bekannte Einschränkungen

Ehrliche Dokumentation der aktuellen Einschränkungen des Rome-Protokolls und ihrer Auswirkungen.

Ausführungseinschränkungen

Modexp-Precompile deaktiviert. Das Precompile für modulare Exponentiation (0x05) ist standardmäßig deaktiviert. Verträge, die auf RSA-Verifikation oder andere Modexp-Operationen angewiesen sind, schlagen fehl. Kann über ein Feature-Flag aktiviert werden.

SELFDESTRUCT entfernt. Der SELFDESTRUCT-Opcode wird nicht unterstützt, entsprechend Ethereums Dencun-Abkündigung. Verträge, die SELFDESTRUCT verwenden, werden zurückgesetzt.

256 Speicher-Slots pro Speicherkonto. Der Vertrags-Speicher ist über Solana-Konten mit jeweils 256 Slots aufgeteilt. Verträge mit großem Speicherbedarf verwenden mehrere Konten, was sich auf die CU-Kosten auswirkt.

CPI-Tiefenlimit von 4. Tief verschachtelte CPI-Aufrufe schlagen fehl. Entwerfen Sie Verträge mit flachen Aufrufbäumen.

Token-Einschränkungen

Transfer-Hooks werden nur bei transfer_checked. einfachen transfer Aufrufen ausgelöst, umgehen Hooks vollständig. Alle Rome-Bridge-Operationen verwenden transfer_checked, aber Integrationen von Drittanbietern müssen sich dessen bewusst sein.

Mint- und Burn-Operationen sind nicht mit Hooks versehen. Token-2022-Transfer-Hooks werden bei Mint/Burn nicht ausgelöst. Gesteuert über die Mint-Authority, nicht über Hooks.

Token-Umgehung durch Wrapping. Benutzer können Token-2022-Token potenziell in Standard-SPL-Token wrappen, um Transfer-Hooks zu umgehen. Abgemildert durch Wrapper-Blacklists und die PermanentDelegate-Erweiterung, aber nicht vollständig beseitigt.

Oracle-Einschränkungen

Keine historischen Rundendaten. Oracle-Gateway-Adapter unterstützen nur latestRoundData(). Historische Preisabfragen über getRoundData(roundId) lösen einen Revert aus.

Parser-Offsets werden empirisch validiert. Pyth- und Switchboard-Kontodaten werden mithilfe fest codierter Byte-Offsets geparst. Wenn Pyth oder Switchboard ihr Kontolayout ändern, liefern die Adapter falsche Daten, bis die Offsets erneut validiert wurden.

Infrastruktureinschränkungen

Einzelbetreibermodell. Jede Rome-Bereitstellung wird von einer einzigen Entität betrieben (dem Betreiber des Payer-Pools). Es gibt kein dezentrales Betreiber-Set.

Iteratives Modus-Locking. Während der iterativen Ausführung werden Konten für 3–4 Sekunden gesperrt. Dies kann bei stark genutzten Konten zu Konflikten führen.

Risiko der OP-Geth-Abweichung. Die Zustandsabweichung zwischen Rome EVM und OP-Geth bleibt eine anhaltende technische Herausforderung. Die Footprint-Validierung mindert dieses Risiko, beseitigt es jedoch nicht.

Was kommt als Nächstes

• Verantwortungsvolle Offenlegung — wie man Probleme meldet