Digamos que queremos confirmar que una transacción de valor txha alcanzado cierta finalidad, que definimos como esperar 12 confirmaciones de bloque. Hacemos esto para reducir la probabilidad de txperderse debido a una bifurcación o que se incluya en un bloque tío.
Los ejemplos que he visto usar getBlocky/o getTransactionprimero para asegurarme de que txse extrajeron en un bloque.
Luego esperan hasta que se hayan extraído 12 bloques nuevos y parecen usarlos getTransactionReceiptpara verificar si txtodavía está en la cadena de bloques.
¿Hay alguna diferencia funcional en este contexto entre usar getTransactiony getTransactionReceiptverificar si txtodavía tiene blockNumber? Las implementaciones no parecen usar ninguno de los datos adicionales devueltos, getTransactionReceiptlo que lo hace un poco confuso.
Digamos que ocurrió una bifurcación o txentró en un bloque huérfano antes de las 12 confirmaciones. ¿Significa esto que getTransactiony getTransactionReceiptdevolverá nulo para la transacción o cómo se refleja esto en estas llamadas?
No, no hay diferencia en este caso, son esencialmente equivalentes. Si el tx está huérfano, deberían devolver null, pero aún así debe verificar el número de bloque porque es posible que se haya agregado a la nueva cadena más tarde de lo esperado, dando menos probabilidad de finalización.
txde perderse en un tenedor? ¿Seguirán regresando los métodos nullo el número de bloque será null? No estoy seguro si txquedarse huérfano cubre el caso del tenedor.txque el número de bloque inicial de puede cambiar entre la primera y la última llamada (después de 12 bloques)? Y además, ¿significa esto que se recomienda esperar bloques adicionales para cubrir la diferencia para llegar a 12 confirmaciones?(tx.blockNumber - eth.blockNumber) > 12que tenga 12 confirmaciones.
Víctor Mezrín