Wie werden Ethereum Bytecode JUMPs und JUMPDESTs aufgelöst?

Question

Ich habe nach Informationen darüber gesucht, wie Ethereum mit Jumps und Sprungzielen umgeht. Von verschiedenen Blogs und dem gelben Papier, was ich fand, ist wie folgt:

Die genommen Operanden durch JUMP und die erste der beiden von JUMPI genommen Operanden sind der Wert der die PC eingestellt ist (unter der Annahme den ersten Stapel-Wert = 0 im Fall von JUMPI).

Allerdings betrachten this Schaffung Code des Vertragsform (Opcodes) die ersten Opcodes/Werte sind:

PUSH1 0x60 PUSH1 0x40 MSTORE CALLDATASIZE ISZERO PUSH2 0x00f8 JUMPI

Wie ich verstehe es bedeutet dies, dass, wenn der Wert von ISZERO auf den Stapel geschoben! = 0 dann PC ändert sich zu 0x00f8 als JUMPI nimmt zwei aus dem Stapel, überprüft, ob der zweite 0 ist und wenn nicht setzt auf den Wert des ersten Operanden.

Das Problem, das ich habe, ist, dass 0x00f8 in Dezimal 248 ist. Die 248. Position im Vertrag scheint MSTORE und nicht eine JUMPDEST zu sein, was dazu führen würde, dass der Vertrag in seiner Ausführung fehlschlägt, da JUMP* nur auf eine gültige JUMPDEST zeigen kann.

Vermutlich springen Verträge nicht absichtlich zu ungültigen Zielen?

Wenn jemand erklären könnte, wie Sprünge und Sprungziele gelöst werden, wäre ich sehr dankbar.

Answer 1

Falls es hilft andere:

Die Verwirrung aus dem EVM-Lese-Byte für Byte und nicht Wort für Wort entstanden ist.

Aus dem Beispiel in der Frage, 0x00f8 wäre das 248. Byte, nicht das 248. Wort.

Da jeder Opcode 1 Byte lang ist, wird normalerweise beim Lesen eines Opcodes um 1 erhöht.

Im Fall einer PUSH-Anweisung sind jedoch auch Informationen darüber enthalten, wie viele der folgenden Bytes als Operand genommen werden.

Zum Beispiel PUSH2 nimmt die 2 Bytes, die folgen, PUSH6 dauert 6 Bytes, die folgen, und so weiter. Hier würde um 1 für die PUSH und dann um 2 bzw. 6 für jedes Byte der Daten, die von PUSH verwendet werden, inkrementiert.