Reorgs y confirmaciones: ¿cuántos bloques es seguro esperar?
Todo backend que acredita un depósito tiene que responder a una pregunta: ¿cuándo es una transacción lo bastante firme como para actuar sobre ella? Trata un bloque como final demasiado pronto y una reorg puede borrar un depósito que ya acreditaste. Espera demasiado y frustras a los usuarios. La respuesta correcta es por cadena.
Por qué ocurren las reorgs
Cuando se producen dos bloques válidos casi a la misma altura, la red discrepa temporalmente sobre la punta. Una rama gana a medida que más bloques se construyen sobre ella, y las transacciones de la rama perdedora regresan al mempool. Este es un comportamiento normal del consenso, no un ataque. Las reorgs cortas de uno a dos bloques ocurren de forma rutinaria en la mayoría de las cadenas.
Los modelos de finalidad difieren
Las cadenas de proof-of-work como Bitcoin tienen finalidad probabilística: confirmaciones más profundas significan probabilidades de reversión exponencialmente menores, nunca exactamente cero. Ethereum tras el Merge añade finalidad económica mediante checkpoints aproximadamente cada dos épocas (~13 minutes), tras lo cual una reversión exige penalizar (slashing) un tercio del stake. Las L2 heredan su propia superficie de reorg del sequencer más la capa de asentamiento. Un único umbral no vale para todos.
Umbrales prácticos
Ajustes habituales en producción: Bitcoin 3–6 confirmaciones según el valor, Ethereum 12–32 blocks (o esperar a la etiqueta finalized), cadenas EVM de alto rendimiento proporcionalmente más bloques porque los tiempos de bloque son más cortos. Para cualquier cosa de alto valor, guíate por la etiqueta finalized/justified en lugar de un recuento de bloques en bruto, para heredar así la propia garantía de finalidad de la cadena.
Detectar una reorg en tu backend
Registra el hash del bloque contra el que acreditaste, no solo la altura. En cada nueva cabecera, retrocede y confirma que los hashes de los padres siguen coincidiendo con lo que anotaste; una discrepancia significa una reorg que debes manejar revirtiendo los créditos provisionales. Suscribirse a las nuevas cabeceras y conciliar hashes es más barato que depurar un doble crédito después de que ocurra.
Preguntas frecuentes
¿No puedo simplemente esperar más para estar completamente seguro?
Esperar más reduce el riesgo pero nunca llega a cero en cadenas probabilísticas, y perjudica la experiencia de usuario. Usar la etiqueta de finalidad de una cadena, donde exista, es una palanca mejor que limitarse a aumentar un recuento de bloques.
¿Las L2 sufren reorgs?
Sí. Un sequencer centralizado puede reordenar o descartar transacciones no confirmadas, y la L2 también depende de su capa de asentamiento. Trata la finalidad de una L2 como función tanto del sequencer como del asentamiento en L1.
Relacionado
Recarga, obtén tu clave y publica.
Autoservicio. Paga en cripto o con tarjeta. Medido por créditos: las primitivas pesadas cuestan más, las simples son baratas.
Obtener clave API