¿Cuáles son las diferencias (y la relación) entre los pasos utilizados para (1) validar una transacción y (2) confirmar un bloqueo?

En la cadena de bloques de Ethereum, ¿cuál es la diferencia (y la relación entre) (1) el proceso utilizado para validar una transacción y (2) el proceso utilizado para confirmar un bloque? Parece que estos procesos son bastante autónomos ya que algunos bloques se confirman con cero transacciones. Pero un bloque solo puede confirmarse si todas las transacciones dentro de él han sido validadas, ¿verdad? Me encantaría tener más claridad sobre las similitudes y diferencias entre estos dos procesos.

Quizás mi terminología sea incorrecta, pero no he oído hablar de bloques confirmados (validados/verificados, sí). Escuché que las transacciones se confirman (separadas de la validación) en función de la cantidad de bloques en la cadena "ganadora" en la que aparecen. Los bloques se verifican/validan antes de agregarse a la cadena de bloques. ¿Nos referimos a lo mismo con términos diferentes?

Respuestas (1)

Puedo proporcionar un resumen de alto nivel que ayudará a que las cosas tengan más sentido a medida que busque los detalles en Google.

Son preocupaciones separadas.

La validación se ocupa de decidir si se permite la transacción. Por ejemplo, puedo enviar una transacción que transfiera todo su ether a mi cuenta. Los validadores notarán que mi transacción no está firmada con su firma, por lo que no está permitida por el protocolo, por lo tanto, no hay cambios de estado y pierdo todo el gas que envié.

Otras razones para invalidar una transacción. El remitente no tiene fondos suficientes, el contrato decidió que la entrada no era aceptable, el contrato decidió que la solicitud no era aceptable.

Minar un bloque es una preocupación aparte.

Un bloque de transacciones es un conjunto de transacciones en un orden específico . El pedido es importante porque la red necesita determinar un pedido para el procesamiento de transacciones. Sin consenso sobre el orden de los eventos, no es posible llegar a un consenso sobre los resultados.

El desafío aquí es doble. Hay latencia en la red, por lo que los nodos no aprenden sobre las transacciones pendientes exactamente en el mismo orden. Y, para ser completamente descentralizada, la solución no puede depender del reloj de nadie porque el reloj de nadie se considera mejor que el de los demás.

Los mineros ordenan las transacciones pendientes que conocen y cuando "encuentran" un bloque difunden la solución a la red. Esto elimina la ambigüedad del orden de los eventos para que la red pueda llegar a un consenso sobre el orden de los eventos. PoW es como una lotería. El ganador puede "considerar" que las transacciones en el bloque se desarrollaron en un orden determinado. También pueden decidir qué transacciones (es posible que no las conozcan todas o que las tarifas sean demasiado bajas). Las transacciones perdidas generalmente se procesarán en un bloque posterior.

Confirmación de una transacción

Después del bloque con mi transacción (fallida), existe una pequeña posibilidad de que un minero diferente anuncie un bloque con una solución diferente. Esto posiblemente contendrá las mismas transacciones pero en un orden diferente, o posiblemente una opinión diferente (tolerancia a fallas bizantinas) sobre la validez. Significa que un bloque puede ser derribado por una idea mejor. Aún así, llega un nuevo bloque cada 15 segundos, por lo que a medida que se acumulan, las probabilidades de que se derriben los bloques más antiguos se vuelven pequeñas. Es por eso que es costumbre esperar algunas confirmaciones para reconocer transacciones de alto valor.

Todos juntos ahora:

Mi transacción ridícula podría ser (digamos...) la tercera transacción en un bloque con el resultado de que perdí mi gasolina. La red llega a un consenso a través del proceso de minería de que la transacción fue la tercera procesada por la red y la transacción no fue válida y perdí mi gasolina por eso. Después de que lleguen algunos bloques más, podemos estar bastante seguros de que hemos visto la última palabra en el consenso de la red sobre mi lamentable hazaña.

Espero eso ayude.

Eso fue muy útil, Rob, ¡gracias! Entonces, ahora entiendo que la validación de una transacción es básicamente un proceso basado en evidencia (es decir, establecer que hay fondos suficientes, que la transacción está firmada, etc.). Y eso es independiente de si se confirmará o no. Entonces, ¿la confirmación de una transacción solo ocurre cuando el bloque se confirma suficientes veces? Solo quería asegurarme de que lo hice bien.
Quiero comprobar otra cosa... También estoy seguro de que la confirmación de un bloque implica (1) resolver el rompecabezas matemático + (2) difundir la solución a la red más rápido que otros que pueden estar resolviéndolo alrededor de la misma ¿tiempo? Todavía no tengo muy claro la relación entre (a) ordenar las transacciones en un orden particular y (b) resolver el rompecabezas matemático. ¿Cómo se relacionan con el proceso de confirmación?
Debido a la latencia de la red, los nodos aprenden sobre transacciones pendientes en diferentes órdenes. Debido a la física, no podemos esperar que todo sea más rápido que todo lo demás. Debido a la descentralización, el reloj de nadie es mejor que el de los demás, por lo que no podemos usarlos. El rompecabezas es una forma de eliminar la ambigüedad del orden correcto de los eventos dentro de un bloque. El minero que resuelve el rompecabezas primero gana el privilegio de anunciar las transacciones de pedidos que se van a procesar. Los detalles adicionales tratan el escenario cuando dos o más mineros anuncian una solución más o menos simultáneamente => eventual consenso
@RobHitchens: gracias por el lenguaje maravillosamente simple utilizado para explicar esto. ¿Alguna fuente donde pueda leer más sobre un eventual consenso en caso de que 2 o más mineros resuelvan/anuncien simultáneamente un nuevo bloque? Llegué a saber que crea una bifurcación en la cadena que se puede resolver esperando un número determinado de confirmaciones (6 en el caso de Ethereum por lo que leí, pero podría estar equivocado), pero ¿y si la bifurcación va más allá de ese conjunto? ¿número?
La prueba de trabajo es una de esas cosas para pasar un poco de tiempo viendo explicaciones desde muchos puntos de vista hasta que haga clic. El "tenedor" que describe es correcto. Se resuelve por la regla de la cadena más larga. A medida que se acumulan los bloques, el nodo observa qué cadena tiene la mayor cantidad de pruebas de la mayor cantidad de trabajo y la considera una cadena canónica.
Una propiedad no obvia que creo que es importante comprender es que ninguna transacción se pierde necesariamente cuando se rechaza un bloque porque, "oye... estamos siguiendo la otra bifurcación ahora". Ambas cadenas válidas tienen transacciones válidas del mismo mempool pendiente. En la mayoría de los casos, las cadenas tienen las mismas transacciones en un orden diferente.