Transacción registrada en el nodo geth, pero no se puede ubicar la entrada de transacción en Ropsten

Al enviar nuevas transacciones una a la vez (es decir, separadas por 1 o varios minutos en el tiempo), se transmiten y extraen correctamente. Pero al enviar varios de ellos uno detrás de otro (separados por unos pocos segundos) la mayoría de ellos se pierden. El nodo Geth confirma la recepción de la transacción, pero blockchain Ropsten no los muestra.

Aquí hay un conjunto de transacciones, la mayoría de ellas no disponibles en Ropsten:

I0421 14:23:57.216680 internal/ethapi/api.go:1107] Tx(d83896adacd210a545d8bc53be2672d2bbb535cd6fd93fc6d74dcafb24c047ea) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:23:41.739022 internal/ethapi/api.go:1107] Tx(c6002dc6a3b28b6caba7ed7cb143d79147dc705437ccf70e267a4b2379f7920d) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:23:08.040512 internal/ethapi/api.go:1107] Tx(dcaa2a36ca4e2c5c3377e6b1f72d127242b4556c001efc3aca38c980c4e4c333) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:23:07.542375 internal/ethapi/api.go:1107] Tx(dcaa2a36ca4e2c5c3377e6b1f72d127242b4556c001efc3aca38c980c4e4c333) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:23:01.623979 internal/ethapi/api.go:1107] Tx(c70976a147e3e268131b0ed2be4555277371f439bbfe641ed1c55acaeec725eb) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:22:54.749671 internal/ethapi/api.go:1107] Tx(c3089a845110a871713bead6b71984ac5053cf4c2a3baa864e7ba0cf4499280b) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:22:49.069954 internal/ethapi/api.go:1107] Tx(fb629dc7f75b9ad486fd48afe3838c093567463d850b19c867c58520420eb9e7) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:22:35.357242 internal/ethapi/api.go:1107] Tx(1cae8925fb57971c126f37d2cef98f71696523cd109b7359f2f5845f1f05ca6a) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:22:24.175374 internal/ethapi/api.go:1107] Tx(9aceebdb23c4542ea5469d4cf05cc3ee7bddc7ea55fdae05ea63c45c9e581a70) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:22:16.787944 internal/ethapi/api.go:1107] Tx(7a2d0660aeec7698328e1e1ee96ecc929f4f6323fd22c5a337c92995bf88b4cf) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:22:08.852178 internal/ethapi/api.go:1107] Tx(73e7586a05ed17f1acb21fae93806349334881393c4493d4c708e3a902cd16c6) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:22:01.956836 internal/ethapi/api.go:1107] Tx(2ded9002531b59dd7c42dcb2a51ab420be555d8c7a26269334c24ce8971e1b6e) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:21:53.184982 internal/ethapi/api.go:1107] Tx(9a9ac63a5d7b061b1597892f63a906c195c258c66b81e8d2f943ca9b5664f314) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df

Por ejemplo,

https://ropsten.etherscan.io/tx/0x2ded9002531b59dd7c42dcb2a51ab420be555d8c7a26269334c24ce8971e1b6e

dice "No se puede localizar la entrada de transacción".

Mientras tanto otros como:

https://ropsten.etherscan.io/tx/0x9aceebdb23c4542ea5469d4cf05cc3ee7bddc7ea55fdae05ea63c45c9e581a70

han sido extraídos con éxito.

¿Cómo puedo averiguar dónde y por qué se perdieron esas transacciones? ¿Alguna idea de cómo depurar el proceso?

Referencias:

Transacción bloqueada desde ayer

¿Transacción minada o no?

¿Podría compartir algunos detalles más, está conectado con sus compañeros? ¿Estás completamente sincronizado? ¿Qué versión de Geth estás usando? ¿Está utilizando Ropsten o Ropsten-Relanzado?
Geth versión 1.5.9. Sí, admin.peers devuelve 64 pares. Totalmente sincronizado porque el registro muestra el mismo último bloque que ropsten.etherscan.io Supongo que es Ropsten simple.
¿Cómo estás creando las transacciones? Específicamente, ¿cómo estás asignando nonces?
Las transacciones se crean y firman utilizando ethereumJS lib a través de un nodo geth remoto a través de JSON-RPC. Los nonces se consultan con llamadas Web3.js al nodo.

Respuestas (2)

Las transacciones múltiples enviadas desde una cuenta durante un solo bloque pueden no necesariamente recibirse o extraerse en el orden enviado. El nonce para cada transacción aumenta, pero un minero debe invalidar una transacción de un nonce más bajo que el recibido anteriormente. Si están minando fuera de servicio, entonces las transacciones más antiguas (por segundos) podrían invalidarse.

¿Significa que no hay garantía de que se extraiga una transacción una vez transmitida?
Los nonces de transacción son estrictamente secuenciales. No puede haber lagunas. Entonces, esta respuesta es falsa, el minero no puede extraerlos en ningún otro orden que no sea su secuencia definida por su nonce.
@Péter Szilágyi Sí, los nonces aumentan estrictamente cuando se envían, por lo que cuando un minero recibe un nonce> nonce+1, entonces ese minero suelta el TX, ¿verdad? Entonces, cuando un minero recibe TX fuera de servicio, lo cual es posible debido a la demora en la propagación, ¿no eliminará los TX hasta que vea uno con nonce + 1?

Debe verificar si está en la cadena correcta, es posible que esté en una cadena incorrecta. Pruebe eth.getBlock(blockNumber)y compare el blockhash de retorno con etherscan.

En caso afirmativo, desde la consola geth, ¿puede intentar usar eth.pendingTransactions()para ver si estas transacciones aparecen como pendientes en su máquina?

En caso afirmativo, intente admin.peersver si está conectado a algún par. Si es así, intente:

var tx = eth.pendingTransactions()[index]y reemplácelo indexcon el índice de la transacción que desea retransmitir. Después:

eth.resend(tx, <optional gas price>, <optional gas limit>).

Hacer esto le permitirá retransmitir las transacciones a sus pares (debería establecer un precio de gasolina más alto).

> eth.pendingTransactions() TypeError: 'pendingTransactions' no es una función en <anónimo>:1:1
También puede verificar web.eth.blockNumbersolo para ver si se parece al último número de bloque en un explorador de blockchain
> eth.blockNumber 812712 igual que el último bloque en ropsten.etherscan.io
> eth.pendingTransactions [] lo que significa que no hay transacciones pendientes.
Transacción registrada en el nodo geth, pero no se puede ubicar la entrada de transacción en Ropsten
RespuestasAquíPolítica de privacidad1y, 0v