¿Cuándo se eliminan las transacciones "pendientes" de la cadena de bloques?

Es importante tener en cuenta que, en el contexto de esta pregunta, las transacciones nunca se eliminan de la cadena de bloques. La cadena de bloques representa transacciones que fueron validadas por nodos (localmente) y registradas como bloques en la cadena de bloques (de forma remota). Cada nodo completo en la red Ethereum posee su propia copia de la cadena de bloques en la memoria local, lo que significa que cuando una transacción llega a uno de estos nodos para su validación, este proceso se realiza fuera de línea. Una transacción puede permanecer pendiente en un nodo o nunca llegar a la cadena de bloques por varias razones, que se pueden agrupar en cuatro categorías.

El primero de los cuales, quizás el más obvio, es la falla de la máquina; el nodo simplemente podría estar dañado de alguna forma. Sin embargo, hay suficientes nodos que validan las transacciones, por lo que la falla de algunos no es suficiente para detener la cadena, pero la falla generalizada de la máquina podría evitar que se registren las transacciones pendientes.

La segunda razón es que la transacción en sí no es válida y no se puede validar, o aún no se puede validar. Si una transacción no es válida porque es intrínsecamente no válida, nunca llegará a la cadena. Pero una transacción que "debería" ser válida puede encontrarse en el mempool de un nodo completo debido a una brecha de nonce, por ejemplo. Tal vez se realizaron múltiples transacciones en rápida sucesión y la red no las serializó correctamente o el cliente que generó la transacción está mal codificado y se le asignó un nonce no válido, lo que resultó en una transacción que llegó a un nodo con un nonce que era más alto (o incluso más bajo) de lo que esperaba el nodo. En este caso, esta transacción residirá en el mempool hasta que otra transacción de la misma dirección con el nonce faltante llegue a la cadena, y luego el nodo intentará validar esta transacción "fuera de servicio". Sin embargo, si la transacción con el nonce faltante nunca llega a la cadena, entonces esta transacción "fuera de servicio" residirá en el mempool indefinidamente hasta que el nodo la elimine sin otra razón que la falta de memoria local (espacio en disco) . Si el nodo tuviera una cantidad infinita de memoria, probablemente se aferraría a esta transacción para siempre, pero ciertamente ese no es el caso.

La tercera razón es la competencia. Si la red está lo suficientemente caliente, donde hay más transacciones dispuestas a pagar más gasolina que la suya, lo suficiente como para mantener su transacción en un mempool el tiempo suficiente para purgarlo (nuevamente, sin otra razón que la falta de espacio en disco en el nodo mismo ), es posible que su transacción nunca se convierta en un bloque en la cadena.

Y la cuarta razón es la excepción a la regla. Un principio básico de Ethereum es "romper cosas" y ciertamente es posible que los cambios futuros en el protocolo puedan poner en peligro las transacciones pendientes. Se advierte a los desarrolladores de Ethereum en la puerta que estén preparados para cualquier cosa y los eventos del pasado, a saber, la infame bifurcación dura, refuerzan la sabiduría de este consejo.

Pero la respuesta práctica a la pregunta es siempre que el nodo se quede sin espacio en disco asignado a su mempool. Entonces, la pregunta operativa se convierte en: ¿por qué la transacción está inactiva en un mempool?

Todas las transacciones se mantienen en Mempool, un término prestado de Bitcoin. Puede ver todas las transacciones pendientes actuales aquí: Transacciones pendientes

Hay un límite para el tamaño de Mempool y una vez que alcance su límite, comenzará a eliminar transacciones. Este artículo Cuando hay demasiadas transacciones pendientes lo explica bastante bien.

En Geth 1.6.5, la configuración básica para el mempool está en una estructura Go llamada TxPoolConfig. Uno de los campos interesantes en esa estructura es GlobalSlots ("Número máximo de ranuras de transacciones ejecutables para todas las cuentas"). En la configuración predeterminada (DefaultTxPoolConfig), GlobalSlots se establece en 4096. Una vez que se alcanza ese límite, Geth comienza a liberar espacio expulsando algunas de las transacciones en su mempool de acuerdo con un conjunto de reglas bastante complejo.