Saltar al contenido
Financial Context Wiki

Confirmaciones de bloque

Guía basada en la verificación de la profundidad de confirmación PoW, los estados safe y finalized de PoS, el reemplazo en mempool, las reorganizaciones y la política de abono de depósitos de las plataformas.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

Una confirmación de bloque es una afirmación específica del observador y del protocolo: una transacción está incluida en un bloque de la cadena canónica que ese observador ve en ese momento. La convención inclusiva habitual de Bitcoin Core cuenta el bloque que contiene la transacción como la primera confirmación. Para una altura de inclusión h y una altura de la mejor cadena H, la profundidad es H - h + 1. Algunos servicios muestran solo los descendientes como H - h, por lo que hay que declarar la convención.

En Proof of Work, la profundidad reduce el riesgo de reorganización bajo supuestos concretos, pero no crea un punto mágico de finalidad absoluta. Los sistemas Proof of Stake pueden exponer estados nativos del protocolo. Ethereum distingue latest, safe y finalized; un número fijo de bloques, slots o minutos no sustituye esas etiquetas. Los estados detectado, abonado, negociable y retirable de una plataforma son políticas internas distintas incluso después de cumplirse el umbral de la cadena.

Espera prevista
1.2 min
Rango ilustrativo
54s - 1.5 min

Los resultados son aproximaciones educativas. Salvo que se indiquen, excluyen reglas del mercado, impuestos, latencia, comportamiento de oráculos y otros parámetros específicos del protocolo.

Cómo funciona

  1. Fija cadena y red, activo, identificador de transacción, nodo o API, hora del observador, modelo de consenso y convención de conteo. Verifica destinatario, importe y memo o tag antes de considerar que un hash coincidente es el pago previsto.
  2. Separa firmado, difundido, aceptado por el mempool local de un nodo y propagado. Los mempools son vistas de política, no una cola global de consenso. Comprueba comisiones, ancestros sin confirmar, Replace-by-Fee o reemplazo por mismo nonce y gastos en conflicto.
  3. Verifica la inclusión mediante hash de bloque, altura, índice de transacción y ascendencia canónica, no solo por la altura o una insignia del explorador. En cadenas de cuentas, revisa también el estado del recibo, los logs y el cambio de estado efectivo; una ejecución incluida puede revertirse.
  4. Aplica el modelo de consenso. En PoW, declara la convención, calcula la profundidad y compara vistas independientes de mejor cadena y trabajo acumulado. En PoS, consulta los estados nativos head, safe, justified o finalized; no los infieras de una distancia fija en bloques o slots.
  5. Registra el ciclo de vida como estados explícitos: creada, difundida, aceptada en mempool local, incluida, profundidad canónica o estado safe/finalized, reorganizada, reincluida, reemplazada o en conflicto. Una reorganización no garantiza que la transacción original vuelva a todos los mempools.
  6. Separa el libro de la plataforma: observada, umbral de red cumplido, abonada, negociable y retirable. Aplica la política vigente de la plataforma según activo, red, importe e incidente; mantenimiento, cumplimiento normativo y revisión manual pueden añadir demoras independientes.
  7. Contrasta nodos o proveedores independientes y sigue monitorizando hasta alcanzar el estado requerido. Registra hashes, alturas, marcas de tiempo, etiquetas RPC y versión de la política, y ensaya reemplazo, reorganización, retraso de finalidad, nodo obsoleto, relay del puente e indisponibilidad de la plataforma.

Ejemplos desarrollados

  • Convención de conteo. Una transacción Bitcoin está en el bloque canónico h = 900,000 y la punta de la mejor cadena es H = 900,005. La profundidad inclusiva es 900,005 - 900,000 + 1 = 6 confirmations; una interfaz que cuenta solo descendientes muestra 900,005 - 900,000 = 5. La diferencia es terminológica si ambas se refieren al mismo hash y ascendencia.
  • Reorganización y reinclusión. La transacción tiene primero 1 confirmation en el bloque 900,000; después ese bloque sale de la mejor cadena y vuelve a 0 si sigue siendo válida y no tiene conflicto. Si se reincluye en 900,003 y la punta alcanza 900,006, la profundidad inclusiva es 900,006 - 900,003 + 1 = 4 confirmations. Si un conflicto confirmado la sustituye, Bitcoin Core puede informar confirmaciones negativas.
  • Las etiquetas PoS no son conteos de bloques. Supón que una transacción Ethereum está en el bloque de ejecución 20,000,000, mientras un nodo informa latest = 20,000,020, safe = 20,000,012 y finalized = 19,999,980, todos en una misma ascendencia. La profundidad latest numérica es 20,000,020 - 20,000,000 + 1 = 21; la transacción es safe, pero no finalized. Se requieren ascendencia de hashes y etiquetas del consenso; las alturas no bastan.
  • Umbral de cadena frente a abono de plataforma. La política exige 6 confirmations. Un depósito en el bloque 900,000 está en 5/6 cuando la punta es 900,004 y alcanza 6/6 en 900,005. Si después se aplica una 15-minute compliance hold, la elegibilidad en cadena y los tiempos de abono, negociación o retiro siguen siendo estados distintos; la retención no es una séptima confirmación.

Riesgos

  • Consultar la cadena, red o activo equivocados.
  • Usar un hash, destinatario, memo o tag incorrectos.
  • Tratar una transacción firmada pero no difundida como pendiente.
  • Tratar el mempool de un nodo como estado global de red.
  • No detectar rechazo por política, expulsión o falta de propagación.
  • Ignorar un reemplazo RBF, por mismo nonce o gasto en conflicto.
  • Interpretar mal ancestros, descendientes o comisiones de paquete sin confirmar.
  • Mezclar conteos inclusivos y de solo descendientes.
  • Confiar en un nodo obsoleto, sincronizando o aislado.
  • Comparar alturas sin verificar hashes y ascendencia.
  • Perder confirmaciones en una reorganización PoW corta.
  • Tratar una profundidad fija como seguridad absoluta para todo valor y adversario.
  • Confundir tiempo transcurrido, slots, epochs y bloques producidos.
  • Tratar el head PoS como safe.
  • Tratar un bloque safe como finalized.
  • No detectar un retraso de finalidad mientras siguen produciéndose bloques.
  • Tratar una ejecución incluida pero revertida como éxito de la aplicación.
  • Confundir logs de tokens o la interfaz del explorador con el estado resultante.
  • Equiparar detección, abono, negociación y permiso de retiro de la plataforma.
  • Tratar la confirmación de origen como finalización de un puente, emisor o flujo de destino.

Errores comunes

  • Un hash localizable o una entrada del mempool local ya están confirmados.
  • Una convención y el umbral de seis confirmaciones sirven para toda cadena, importe y servicio.
  • Una comisión mayor hace que los bloques posteriores o la finalidad PoS lleguen antes.
  • Un conteo fijo de bloques o slots de Ethereum equivale a safe o finalized.
  • La inclusión o finalidad garantiza ejecución correcta, destinatario correcto, abono de plataforma o finalización del puente.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...