Confirmaciones escalonadas por importe del pago

Una política de confirmaciones decide cuándo un pago está listo para abonarse. Paymos lee dos datos: la red que eligió quien paga y el valor en dólares de la factura. Cada red lleva su propia profundidad de confirmación para cada tramo de importe, así que una factura pequeña se cierra más superficial que una grande en la misma cadena. Esas profundidades son configuración y no una estimación, y por eso este artículo puede imprimirlas. Lo que no son es un reloj: los minutos que hay detrás de una cifra pertenecen a la producción de bloques de la cadena, y una integración debería liberar la mercancía con el estado confirmado de la factura, nunca con un temporizador.

¿Qué decide una política de confirmaciones?

Una política de confirmaciones convierte un evento en bruto de la cadena en un resultado de pago. En la mayoría de las redes eso significa contar los bloques construidos encima del que lleva el pago. En una red que emite una señal explícita de finalidad, la política lee esa señal. El comercio ve lo mismo en los dos casos —el estado de la factura— y nunca tiene que hacer la evaluación por su cuenta.

La política existe porque una observación reciente en la cadena no es un pago asentado. Un reorg —una reorganización de la cadena— puede sustituir bloques recientes, de modo que una billetera que enseña una confirmación ha probado la inclusión, no la permanencia. La profundidad compra probabilidad. Una señal de finalidad del protocolo compra una garantía más fuerte bajo las reglas de ese protocolo. La frontera de la integración está en el estado confirmado de la factura, no en el explorador de bloques que esté mirando alguien de soporte.

¿Por qué la espera segura depende del importe?

El importe es el valor expuesto si un bloque reciente queda desplazado. La seguridad es una propiedad de la red; el tamaño de la pérdida es una propiedad de la factura. Una política que ignora la segunda tiene que elegir una espera única para ambas, y ninguna respuesta sirve: lo bastante profundo para una transferencia de cinco cifras hace que un pedido de 20 $ se arrastre, y lo bastante rápido para ese pedido de 20 $ deja barata la de cinco cifras.

Escalonar el valor en dólares de la factura resuelve eso. Los umbrales son 100 $, 1.000 $ y 10.000 $, y cada tramo se aplica hasta su propio umbral incluido. Las cifras dentro de esos tramos cambian de una red a otra, y algunas redes usan menos tramos que otras, porque un bloque no significa lo mismo en todas las cadenas.

¿Cómo es en la práctica una política escalonada de confirmaciones?

Esta es la regla completa en las redes donde los tramos hacen casi todo el trabajo. Una factura en Ethereum espera 2 confirmaciones hasta 100 $, 6 hasta 1.000 $, 12 hasta 10.000 $ y 32 por encima. Tron abre en 2, pasa a 6 y se detiene en 19 por encima de 1.000 $, que es el punto en que 19 de sus 27 super representantes han solidificado el bloque. Base y Optimism van a 5 / 15 / 30 / 100 con los mismos umbrales. Arbitrum va a 40 / 120 / 240 / 800, una cifra que suena desmedida hasta que cuentas sus bloques de menos de un segundo: sus cuatro horizontes caen donde los de Base.

Varias cadenas no necesitan tramos. BSC y Polygon se asientan con su propia señal de finalidad. Solana se escanea en el compromiso finalized y se confirma al descubrirlo. TON pide un bloque, porque allí cada bloque de la masterchain nace final.

Citar una de esas cifras a solas es justo la manera de contar mal la regla. «Finalidad a las 19 confirmaciones en Tron» es exacto por encima de 1.000 $ y falso por debajo. Lleva el tramo con la cifra, o da la fila entera. La guía de confirmaciones explica por qué el mismo recuento en bruto no representa la misma seguridad en todas las redes.

¿Cuánto dura un tramo en tiempo de reloj?

Un recuento se convierte en duración solo a través del ritmo actual de bloques de la red. El tramo corto de Ethereum ronda los 24 segundos a cadencia normal y el más profundo, algo más de seis minutos; el más corto de Tron queda cerca de los seis segundos. Lee todos esos números como una aproximación.

Los bloques llegan más despacio cuando la red está congestionada, y la aritmética se mueve con ellos. Ahí está la línea que separa las dos mitades de esta política: la cifra es un ajuste, el tiempo es un pronóstico. Una etiqueta de la página de pago, una respuesta guardada de soporte o una cláusula de contrato que convierta el pronóstico en promesa se equivocará la primera tarde de tráfico alto.

¿Cómo afecta la finalidad del protocolo a la política?

Una red de prueba de participación puede emitir finalidad en lugar de insinuarla. Ethereum la organiza con los puntos de control de Casper FFG, que asientan la historia por épocas y no bloque a bloque. Aun así Paymos cuenta bloques en Ethereum —de 2 a 32, según el tramo—, así que el importe sigue formando parte de la decisión.

Donde la finalidad de una cadena llega rápida e incondicional, los tramos desaparecen del todo: por eso las cuatro redes de más arriba corren con un tramo único. Allí el consenso responde directamente lo que una profundidad solo puede hacer probable. Modelos distintos, un único resultado para el comercio: el estado de la factura.

¿Por qué la política debe seguir el comportamiento actual de la red?

Las redes cambian la velocidad y la firmeza con que producen bloques. La mejora Fermi de BSC acortó los tiempos de bloque y Heimdall v2 acortó el camino de Polygon hasta la finalidad. Cada uno de esos movimientos cambia lo que una cifra significa en el reloj sin tocar la cifra.

Ese es el argumento contra congelar un número en el código del comercio. Cuando una cadena se mueve, la configuración de profundidades es nuestra y se ajusta; una constante en el repositorio de un comercio cambia cuando alguien se acuerda de abrir una pull request. Los tramos de arriba son una foto de unos ajustes que mantiene Paymos, no una cláusula de un contrato.

¿Cuándo tiene sentido escribir a mano un número de confirmaciones?

Pocas veces, y nunca como sustituto del estado de la factura. Leer la tabla para entender la espera es un buen uso. Montar un if alrededor de 12 confirmaciones no lo es: esa constante deja fuera la red que eligió quien paga, el tramo en el que cayó la factura y el próximo cambio de cualquiera de los dos.

El trabajo de la integración es más estrecho y sobrevive a todo eso. Guarda el identificador de la factura de Paymos, verifica la firma de las actualizaciones de estado y haz que repetir la entrega sea seguro. Un pedido no debería salir porque venció un temporizador, porque una billetera mostró un bloque o porque un pago anterior en otra cadena se cerró rápido. Esas observaciones ayudan a soporte; no sustituyen al resultado confirmado de la factura que tienen delante.

¿Cómo aplica Paymos la política?

Paymos evalúa a la vez la red y el importe, y después comunica el resultado. Los pagos pequeños se cierran con menos confirmaciones, los grandes esperan un umbral más fuerte y el tiempo transcurrido sigue a lo que esté haciendo la cadena en ese momento. Las cifras se mueven solo cuando las mueve Paymos, y eso es exactamente lo que las separa de la comisión de red, un precio que fija la cadena y que ninguna página de aquí cita como importe fijo.

La página de cadenas admitidas lista las vías de pago disponibles. La explicación de las confirmaciones trata qué prueba un recuento de bloques y dónde la finalidad del propio protocolo es la señal más fuerte.