Revisé el mecanismo de Newton Protocol de “antes de la liquidación” y terminé en la parte de la que la gente normalmente evita hablar.
Así que esto es con lo que me quedé, digamos:
Newton no deja de decir que cada transacción se comprueba *antes* de la liquidación. Imagina a un guardia justo antes de que se abra la puerta. Lo entiendo. Tiene sentido en el papel.
Pero entonces está el “recibo” que produce cada verificación: una instantánea de la cadena en un momento específico… aunque, obviamente, las cadenas en realidad no se congelan.
Sinceramente, esto podría ser la verdadera dirección hacia la que se está moviendo ahora el relato modular/AVS. El sector no hace más que perseguir una ejecución más rápida y una coordinación fuera de la cadena porque la liquidez, básicamente, premia la velocidad. Pero en cuanto la aplicación de la normativa depende de estados de la cadena que aún pueden reorganizarse bajo tus pies, la industria se topa directamente con el mismo muro: las criptomonedas quieren la capacidad de respuesta de Web2 sin debilitar las suposiciones de finalidad.
Aquí fue donde empecé a dar vueltas: en cadenas del mundo real, “en este momento” es algo efímero. Un reorg puede simplemente borrar el bloque del que dependía tu aprobación, junto con cualquier estado al que estuviera atado. Es una locura.
Entonces, ¿qué pasa con el recibo? Supón que una transacción se aprueba, el usuario mueve fondos y luego un reorg borra el bloque del que venía esa aprobación. El recibo existía… pero solo en una versión de la historia que ya no está.
Vale, volvamos esto raro—imagino seguridad aeroportuaria. Te dan el pase, pero el aeropuerto sigue reconstruyéndose. Tu credencial todavía existe—but todo lo que depende de ella sigue cambiando. Entonces, ¿revalidas cada vez, o sigues confiando en algo ligado a un diseño que ya no existe?
Esa es la parte que no termino de sacarme de la cabeza.
Aquí va mi opinión polémica, y desearía que más gente lo comentara: si la gran promesa de Newton es “aplicar antes del settlement”, el debate real no es solo sobre la seguridad. Es sobre *en qué* anclas esa aplicación. Cuando la cadena se reordena, ¿Newton vacía todos esos recibos y los vuelve a validar, agregando latencia y dudas? ¿O simplemente confía en el recibo original como si fuera dogma—even si ese estado ya está bastante muerto? Porque son dos compensaciones totalmente distintas.
Si los recibos se revalidan después de los reorgs, la aplicación se vuelve más lenta. Si no lo haces, estás confiando en aprobaciones ligadas a estados que quizá ya no existan. Ninguno de los dos resultados se siente limpio.
La velocidad de la aplicación y la confianza en la finalización del estado se sienten como si se movieran en direcciones opuestas cuando las cadenas se vuelven inestables.
Entonces, opinad: si quieres “aplicación antes del settlement”, ¿quieres que esos recibos sobrevivan a los reorgs de la cadena, o deberían re-chequearse siempre contra lo que termine siendo la “historia final”? ¿O eso simplemente destruye el argumento de valor de “aplicación instantánea” que Newton está vendiendo?
La pila modular/AVS está convergiendo hacia menor latencia porque la liquidez premia la rapidez, pero una vez que la aplicación depende de estados sensibles a reorgs, aparece una restricción: cripto quiere la capacidad de respuesta de Web2 sin romper los supuestos de finalización.
Porque si la “aplicación previa al settlement” depende de recibos atados a estados que pueden simplemente desaparecer, todavía no sé realmente cuál de las dos compensaciones es peor.