Bekannte Einschränkungen

Aktuelle Rome-EVM-Einschränkungen und ihre Auswirkungen — nicht unterstützte Opcodes, Speicher-Account-Layout, CU-Grenzen, CPI-Tiefe und Oracle-Grenzen.

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

Ausführungseinschränkungen

SELFDESTRUCT wird nicht unterstützt. Der Opcode hat keinen Handler, daher bricht ein Vertrag, der ihn ausführt, die gesamte Transaktion ab (siehe unten); er macht nicht nur einen einzelnen Frame rückgängig.

Ein Opcode, den Rome nicht implementiert, bricht die gesamte Transaktion ab. Der Interpreter hat keinen Handler für das Byte, daher endet die Transaktion mit IncompatibleVersionEVM(opcode), nichts von dem, was sie getan hat, wird übernommen, und der Fehler erreicht den Absender, statt von einem aufrufenden Vertrag geschluckt zu werden.

Kein Opcode-spezifischer Gasplan. Der übergebene Gaswert an CALL, DELEGATECALL, STATICCALL und CREATE wird aus Gründen der ABI-Kompatibilität akzeptiert, aber nicht erzwungen — ein aufgerufener Vertrag läuft mit dem gesamten verbleibenden Budget des Aufrufers, und es gibt keinen 2300-Gas-Stipend. Reentrancy-Schutz auf Basis eines Stipendiums (transfer() / send()) ist auf Rome wirkungslos; verwenden Sie explizite Reentrancy-Sperren und das Checks-Effects-Interactions-Muster.

Modexp (0x05) ist deaktiviert. Ein Aufruf revertiert mit big_mod_exp-Aufruf ist deaktiviert bis Solana das big_mod_exp syscall.

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

~1,4 Mio. Compute Units pro atomarer Transaktion. Arbeit, die das Budget einer einzelnen Solana-Transaktion überschreitet, weicht auf iterative Ausführung aus (auf mehrere Transaktionen aufgeteilt). Einige Operationen sind nur atomar und können nicht iterativ ausgeführt werden — insbesondere Legacy-Track-CPI (CpiProhibitedInIterativeTx; Cached-Track-Effekte werden gestaffelt und laufen tatsächlich iterativ ab).

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

Orakel-Einschränkungen

Keine historischen Rundendaten. Oracle-Gateway-Adapter unterstützen nur latestRoundData(). Historische Preisabfragen über getRoundData(roundId) schlagen fehl.

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

Tooling-Einschränkungen

Kein Ethereum-ähnliches Transaktions-Tracing. debug_traceTransaction und trace_* werden nicht unterstützt. Die einzige Trace-Methode ist debug_traceRomeTransaction, die eine Transaktion, die mehrere Aufrufe zu einem Batch bündelt, in ihre Unteraufrufe und CPIs aufteilt. Gewöhnliche Transaktionen geben null. Für alles andere verwenden Sie eth_call und die Über den Explorer (der die Solana-Instruktionen hinter einer Transaktion anzeigt), um Fehler zu beheben. Siehe JSON-RPC.

eth_getLogs ist auf einen Bereich begrenzt. Öffentliche Chains lehnen zu breite Blockbereiche ab (Fehler -32005); begrenzen Sie Ihre Abfragen. Siehe JSON-RPC.

Infrastruktur-Einschränkungen

Modell mit einem einzigen Betreiber. Jede Rome-Instanz wird von einer einzelnen Einheit betrieben (dem Betreiber des Zahlerpools). Es gibt keinen dezentralen Betreiberkreis.

Sperrung im iterativen Modus. Während der iterativen Ausführung werden Konten für einige Sekunden gesperrt, was bei stark genutzten Konten zu Konflikten führen kann.

Was kommt als Nächstes

• Verantwortungsvolle Offenlegung — wie Probleme gemeldet werden