¿Posible error en el algoritmo de validación del libro blanco?

Si tomamos el algoritmo de validación de bloques descrito en el libro blanco (Sección Blockchain y Minería), dice en el punto 6:

Sea TXla lista de transacciones del bloque, con ntransacciones. Para todo iadentro 0...n-1, listo S[i+1] = APPLY(S[i],TX[i]). Si alguna aplicación devuelve un error , o si el gas total consumido en el bloque hasta este punto supera el GASLIMIT, devuelve un error .

¿Es cierta la audaz afirmación? Quiero decir, si la parte en negrita fuera cierta, ¿implicaría que los bloques válidos no pueden contener transacciones con errores? ¿O es simplemente un algoritmo de validación genérico que no se corresponde con el real?

(Sé con certeza que hay bloques válidos con transacciones fallidas, por ejemplo, excepción de falta de gas, desbordamiento de la pila de llamadas, etc., por ejemplo, https://etherscan.io/tx/0x3967f859c56c61f3365f6873ea001985e4e694952a9c22b68be731132c8e3e77 )

Respuestas (2)

Es importante entender que este es un algoritmo de validación de bloques. Cuando esta sección del documento técnico habla sobre la devolución de un error, se trata de la capa de bloque en lugar de la capa de transacción. Un error en el nivel de validación del bloque no permitirá que un bloque se propague a la red, a diferencia de un error en la capa de transacción, que se transmitirá a la red, como se muestra en el enlace de ejemplo.

si el total de gas consumido en el bloque hasta este punto excede el GASLIMIT, devuelve un error

Al pensar en esto desde una perspectiva de validación de bloques, esto tiene mucho sentido. Si un minero intenta incluir transacciones en su bloque cuyo total gases mayor que el GASLIMIT, el bloque no será válido y, por lo tanto, nunca verá la red. Si este no fuera el caso, los mineros incluirían cada transacción en su bloque para recibir todas las tarifas de transacción.

Si alguna aplicación devuelve un error... devuelve un error.

La clave para esto es entender que se trata de una aplicación y no de una transacción específica. En esta declaración, una aplicación se refiere a un cliente de minería o alguien que está validando los bloques. Con este entendimiento, es más claro que esta afirmación es verdadera: si la aplicación de validación de bloques devuelve un error, devuelve un error.

Gracias. Pensé que la "aplicación" se refería al APPLY. Entonces, ¿te refieres literalmente a una excepción en el programa en ejecución (y no en el nivel de EVM) o me equivoqué? (Lo siento, pero para mí sigue siendo un poco confuso)
Sí, lo interpreto como un nivel de aplicación/programa. Es confuso, pero mi razón es que este documento técnico es una descripción general de alto nivel, mientras que el documento amarillo se sumerge en la operación de EVM.
Lo siento, pero todavía estoy pensando en ello :). ¿Puede dar un ejemplo concreto? (Solo puedo pensar en "instrucciones no válidas en el código de bytes para ejecutar" o "el remitente no tiene suficiente dinero para enviar al destinatario"). ¿Mis ejemplos son correctos o todavía están en otro plano?
Para el error de la aplicación, esto sería algo así como que el cliente configura un bloque incorrectamente para que sea rechazado de la red. Por ejemplo, si se supone que usted (el minero) debe incluir un timestampen el bloque, y en realidad no incluye uno en el bloque cuando lo envía a la red, será rechazado a nivel de aplicación. Para el total de gas consumido, eso es simplemente si usted (un minero) intenta incluir transacciones cuya combinación gases superior a gasLimit.
Aquí, usted describió los puntos 2 y solo la parte del punto 6 que me quedó clara. En el punto 6 Buterin se refiere a las transacciones individuales. La aplicación parece referirse a varias aplicaciones. Es confuso para los recién llegados.
El punto 2 hace referencia a una marca de tiempo válida, que tiene ciertas características como que no puede ser anterior a la anterior ni puede ser X minutos (no recuerdo el número exacto) posterior a la anterior. El ejemplo que di estaba destinado a explicar un parámetro de bloque no válido, en general. Otro ejemplo puede ser pasar la marca de tiempo como una cadena, en lugar de un número entero. Otro más sería enviar un nonce no válido o altura de bloque (otros dos parámetros incluidos en un bloque).

error de corrección:

o si el gas total consumido en el bloque

=> o si el gas total consumido en la transacción


En el caso de bloque, el gasLimit del encabezado del bloque debe ser mayor que la suma de gasLimit de las transacciones.