Filtros: ¿qué es "más reciente" y "pendiente"?

Quiero monitorear cuentas para transacciones entrantes (RPC/IPC API) y llamar a una función cada vez que una de varias cuentas monitoreadas reciba éter que esté "confirmado", como en "hace suficientes bloques que las posibilidades de doble gasto son insignificantes".

¿Hay una implementación de referencia de esto?

Estoy investigando los filtros y las palabras "pendiente" y "más reciente" siguen apareciendo. ¿Qué quieren decir?

Respuestas (2)

Último significa el último bloque que ya está dentro de su propia cadena. Todas las transacciones contenidas dentro pueden considerarse ejecutadas con éxito. Desde el punto de vista de la seguridad, por supuesto que puede haber reorganizaciones, pero en general son transacciones ejecutadas.

Queda pendiente por otro lado la recopilación de transacciones que pueden ser ejecutadas por la red (que tu propio nodo conoce), pero que aún no han sido realizadas. Pendiente es útil para mostrar interfaces de usuario reactivas donde la interfaz de usuario puede mostrar inmediatamente que algo está entrando, aunque no hay garantías de que esas transacciones, si es que alguna vez lo hacen, se ejecuten con éxito.

¿Qué quiere decir exactamente con "su propia cadena"? También "en cuanto a la seguridad, por supuesto que puede haber reorganizaciones", exactamente, entonces, ¿cómo mido/mitigo esto?
@spraff Su nodo local mantiene su propia copia de la cadena de bloques; "más reciente" significa que está en el bloque principal de esa cadena. Puede mitigar la posibilidad de reorganizaciones contando a cuántos bloques del encabezado de la cadena se encuentra el TX en cuestión, y no considerarlo completamente aceptado hasta que esté un número de bloques debajo del encabezado (que se muestra como "confirmaciones", por lo general).
Ethereum es un sistema descentralizado, por lo que diferentes nodos pueden ver el sistema en un estado diferente: por ejemplo, cuando se está poniendo al día/sincronizando, solo ve un estado anterior hasta que se pone al día. Además, las cadenas de bloques se denominan eventualmente consistentes, lo que significa que eventualmente todos los nodos están de acuerdo en un estado, pero el estado real actual puede ser diferente entre ellos. Su cadena local es lo que su propio nodo cree que es el estado actual. Con respecto a las reorganizaciones, depende de los fondos con los que trabaje: asegúrese de que cueste más hacer una reorganización profunda (pow) de lo que se puede ganar con ella.
Por ejemplo, si está intercambiando unos pocos dólares de éter (por ejemplo, un café), incluso una pequeña reorganización cuesta demasiado para que valga la pena. Si intercambia millones, es posible que desee esperar bastantes bloques para asegurarse de que alguien no gaste el doble de dinero, ya que puede valer la pena implementar un grupo de GPU para intentar revertir esa transferencia.
Entonces, ¿cuál es el criterio, algo así como $reorg < k*$amount*2^confirmationssupongo? Si es así, ¿tenemos una estimación aproximada del coeficiente?

Para obtener ideas sobre una "implementación de referencia", consulte: ¿Cómo puede una DApp detectar una reorganización de bifurcación o cadena usando web3.js o bibliotecas adicionales?

Probablemente también quiera saber: ¿Qué cantidad de confirmaciones se considera segura en Ethereum?


La respuesta de @ Péter es excelente y lo único que se debe agregar es web3.eth.defaultBlockla definición:

"más reciente", el último bloque (jefe actual de la cadena de bloques)

"pendiente", el bloque extraído actualmente (incluidas las transacciones pendientes)

pendinges igual latesta más transacciones pendientes (aquellas que no han sido minadas en un bloque).

Esta es una definición pobre, que necesita ser actualizada. Como mencionó Peter, "pendiente" incluye todas las transacciones conocidas en el grupo de miembros, no solo lo que podría caber en el bloque extraído actualmente, especialmente porque la mayoría de los nodos no son mineros.
@GViz Ese es un comentario justo y creo que estarán abiertos a un PR para modificar: github.com/ChainSafe/web3.js/blob/1.x/docs/web3-eth.rst#L193