Möglicher Fehler im Whitepaper-Validierungsalgorithmus?

Nehmen wir den im Whitepaper (Abschnitt Blockchain und Mining) beschriebenen Blockvalidierungsalgorithmus , so heißt es bei Punkt 6:

Sei TXdie Transaktionsliste des Blocks mit nTransaktionen. Für alle iin 0...n-1, set S[i+1] = APPLY(S[i],TX[i]). Wenn eine Anwendung einen Fehler zurückgibt oder wenn das im Block bis zu diesem Zeitpunkt insgesamt verbrauchte Gas das GASLIMIT überschreitet, geben Sie einen Fehler zurück .

Ist die kühne Behauptung wahr? Ich meine, wenn der fettgedruckte Teil wahr wäre, würde das bedeuten, dass gültige Blöcke keine Transaktionen mit Fehlern enthalten können? Oder ist es einfach ein generischer Validierungsalgorithmus, der nicht dem echten entspricht?

(Ich weiß mit Sicherheit, dass es gültige Blöcke mit fehlgeschlagenen Transaktionen gibt, z. B. Gasausnahme, Callstack-Überlauf usw., z. B. https://etherscan.io/tx/0x3967f859c56c61f3365f6873ea001985e4e694952a9c22b68be731132c8e3e77 )

Antworten (2)

Es ist wichtig zu verstehen, dass dies ein Blockvalidierungsalgorithmus ist. Wenn in diesem Abschnitt des Whitepapers über die Rückgabe eines Fehlers gesprochen wird, geschieht dies auf der Blockebene und nicht auf der Transaktionsebene. Ein Fehler auf Blockvalidierungsebene lässt nicht zu, dass ein Block an das Netzwerk weitergegeben wird, im Gegensatz zu einem Fehler auf Transaktionsebene, der an das Netzwerk gesendet wird, wie Sie in Ihrem Beispiellink gezeigt haben.

wenn das im Block bis zu diesem Punkt verbrauchte Gesamtgas das GASLIMIT überschreitet, wird ein Fehler zurückgegeben

Wenn man dies aus der Sicht der Blockvalidierung betrachtet, ist dies absolut sinnvoll. Wenn ein Miner versucht, Transaktionen in seinen Block aufzunehmen, deren Gesamtsumme gasgrößer als ist GASLIMIT, ist der Block ungültig und wird daher niemals das Netzwerk sehen. Wäre dies nicht der Fall, würden Miner jede Transaktion in ihren Block aufnehmen, um alle Transaktionsgebühren zu erhalten.

Wenn eine Anwendung einen Fehler zurückgibt ... einen Fehler zurückgeben.

Der Schlüssel dazu ist zu verstehen, dass es sich um eine Anwendung und nicht um eine bestimmte Transaktion handelt. In dieser Anweisung bezieht sich eine Anwendung auf einen Mining-Client oder jemanden, der die Blöcke validiert. Mit diesem Verständnis ist es klarer, dass diese Aussage wahr ist – wenn die blockvalidierende Anwendung einen Fehler zurückgibt, gib einen Fehler zurück.

Danke dir. Ich dachte, dass "Bewerbung" auf die APPLY. Sie meinen also buchstäblich eine Ausnahme im laufenden Programm (und nicht auf EVM-Ebene) oder habe ich es falsch verstanden? (Sorry, aber für mich immer noch etwas verwirrend)
Ja, ich interpretiere es als Anwendungs-/Programmebene. Es ist verwirrend, aber meine Begründung ist, dass dieses Whitepaper eine Übersicht auf höchster Ebene ist, während das gelbe Papier in den EVM-Betrieb eintaucht.
Entschuldigung, aber ich denke immer noch darüber nach :). Können Sie ein konkretes Beispiel nennen? (Ich kann nur an "ungültige Anweisungen im Bytecode ausführen" oder "der Absender hat nicht genug Geld, um es an den Empfänger zu senden") denken. Sind meine Beispiele richtig oder liegen sie noch in einer anderen Ebene?
Für den Anwendungsfehler wäre dies so etwas wie der Client, der einen Block falsch konfiguriert, sodass er vom Netzwerk abgelehnt wird. Wenn Sie (der Miner) zum Beispiel ein timestampin den Block aufnehmen sollen, und Sie tatsächlich keins in den Block aufnehmen, wenn Sie ihn an das Netzwerk senden, wird er auf Anwendungsebene abgelehnt. Für das gesamte verbrauchte Gas ist das einfach, wenn Sie (ein Miner) versuchen, Transaktionen einzubeziehen, deren Summe gasüber dem liegt gasLimit.
Hier haben Sie Punkt 2 beschrieben und nur den Teil von Punkt 6, der mir klar war. In Punkt 6 bezieht sich Buterin auf die Einzeltransaktionen. Anwendung scheint sich auf die verschiedenen gelten zu beziehen. Es ist verwirrend für Neuankömmlinge.
Punkt 2 verweist auf einen gültigen Zeitstempel, der bestimmte Merkmale aufweist, z. B. dass er nicht vor dem vorherigen liegen kann und auch nicht X Minuten (ich kann mich nicht an die genaue Zahl erinnern) nach dem vorherigen liegen kann. Das Beispiel, das ich gegeben habe, sollte allgemein einen ungültigen Blockparameter erklären. Ein weiteres Beispiel ist die Übergabe des Zeitstempels als Zeichenfolge und nicht als Ganzzahl. Ein weiterer würde eine ungültige Nonce oder Blockhöhe senden (zwei weitere Parameter, die in einem Block enthalten sind).

fehler Korrektur:

oder wenn das gesamte im Block verbrauchte Gas

=> oder ob das gesamte bei der Transaktion verbrauchte Gas ist

Im Falle eines Blocks muss das gasLimit des Blockheaders größer sein als die Summe des gasLimits der Transaktionen.

Möglicher Fehler im Whitepaper-Validierungsalgorithmus?
AntwortenHierDatenschutz-Bestimmungen1y, 0v