Parity implementiert ein wirklich nützliches Trace-Modul , um tief in Blöcke und Transaktionen einzutauchen.
Eine bestimmte Methode trace_transaction ermöglicht es Ihnen, die EVM-Ausführungspfade einer Transaktion zu untersuchen.
In der Dokumentation ist jedoch nicht klar, was die verschiedenen Ansprechwerte darstellen.
Die meisten Werte sind (glaube ich) ziemlich offensichtlich. Diejenigen, die mich verwirren, liegen gasinnerhalb der actionEigenschaft des Ergebnisses und gasUsedinnerhalb der resultEigenschaft.
Ich gehe davon aus, dass sie das maximal verfügbare Gas in diesem bestimmten Schritt darstellen, bzw. die von diesem Schritt verbrauchte Gasmenge, ABER der Anfangswert gasentspricht nicht dem mit der Transaktion gesendeten und eine Summierung der gasUsedWerte entspricht nicht dem Wert für gasUsed zurückgegeben durch einen Aufruf an getTransactionReceipt.
Ein Beispiel.
Diese (zufällige) Transaktion im Ropsten-Testnet.
Der erste Anruf hat einen Gaswert von 576552 , während die Transaktion mit einem Gaslimit von 600000 eingereicht wurde .
Die Summe der gasUsedWerte ist 102979 , wohingegen ein Aufruf von 93518getTransactionReceipt einen Gesamtgasverbrauch zurückgibt .
Die Geth-Debug-Module zeigten auch eine Differenz von 93518 zwischen dem ersten und dem letzten EVM-Befehl.
Kann jemand klären, was diese Werte tatsächlich darstellen?
Nachdem ich nichts von jemandem gehört hatte, der bei Parity arbeitete, ging ich weiter und untersuchte dies weiter.
Die Eigenschaft gibt die von diesem SchrittgasUsed verbrauchte Gasmenge zurück . Die erste Ablaufverfolgung (die mit null ) stellt die vom Benutzer übermittelte Transaktion dar. Alle anderen Ablaufverfolgungen sind Unterablaufverfolgungen , z. B. die von Ihnen aufgerufene Funktion, die eine andere Funktion aufruft.traceAddress
Die gasUsedfür die Anfangsverfolgung enthalten nicht die Standardtransaktionskosten 21000ODER die Eingabedatenkosten 4für Null-Byte-Daten und 68für Nicht-Null-Byte-Daten. Dies ist im gelben Papier (Seite 20) skizziert.
Wenn Sie den gasUsedWert der anfänglichen Spur nehmen, 21000 addieren und dann die Eingabedatenkosten berechnen, erhalten Sie den Gasverbrauchswert zurück von getTransactionReceipt.
Während ich hier bin, um die Eingabedatenkosten zu berechnen, entfernen Sie das 0xPräfix und teilen Sie die Hex-Eingabedaten alle zwei Zeichen auf ( jedes Hexadezimalzeichen hat 4 Bits ).
0xa600bcbesteht aus drei Datenbytes: a6, 00, und bc. Das sind zwei Nicht-Null-Bytes und ein Null-Byte.
Dies erklärt nicht, warum Parity die gasUsedauf diese Weise zurückgibt. Es könnte wirklich eine Dokumentation vertragen.
Thomas JayRush
llllllllllll
trace module? Muss ich die Blöcke zuerst lokal "synchronisieren" und dann diesen Befehl verwenden?Thomas Cloes