La frase que cambió Midnight para mí fue contundente: una transacción puede fallar en la fase fallible y aún dejar efectos garantizados detrás.
Una vez que leí eso, no pude volver al modelo mental normal de cripto. Los documentos de Midnight dicen que las transacciones pasan por un chequeo de conformidad, luego una fase garantizada, y luego una fase fallible. Si ocurre un fallo en la fase garantizada, la transacción no se incluye. Pero si ocurre un fallo más tarde, los efectos garantizados aún se aplican y el libro mayor registra un éxito parcial. Los documentos también dicen que las tarifas para todas las fases se recogen en la fase garantizada y se pierden si la fase fallible falla. Eso significa que el fallo en Midnight no siempre es un retroceso. A veces es residuo.
Esa es una realidad del producto mucho más grande de lo que suena al principio.
Muchas personas todavía piensan en el fallo de la transacción en términos simples. Funcionó, o falló y no pasó nada realmente. Midnight debilita ese atajo. Su semántica está escalonada. Algunas partes de la acción pueden volverse reales antes de que se permita que las partes posteriores fallen. La documentación es clara que la ejecución de fase puede incluir cosas como insertar compromisos, insertar anuladores, verificar raíces pasadas, y actualizar el conjunto de raíces pasadas. Así que para cuando una condición falible falla, la transacción ya puede haber cambiado el estado del libro mayor de maneras que la aplicación no puede ignorar.
La tarifa ya se ha ido también.
Esa combinación es lo que hace que el modelo sea serio. Un fallo tardío no es solo un mensaje de error. Puede ser un plan fallido sentado sobre un prefijo exitoso.
La forma más clara de ver el problema es con un flujo de acceso privado. Imagina una aplicación Midnight donde un usuario intenta ejercer algún permiso privado. La aplicación quiere que la acción se sienta simple. El usuario presiona una vez y espera una respuesta limpia. Detrás de la pantalla, sin embargo, la transacción puede pasar la conformidad, entrar en la fase garantizada, cobrar tarifas, y aplicar los efectos que pertenecen allí. Luego, una condición falible posterior falla. Tal vez alguna regla de negocio no se cumplió. Tal vez una rama posterior no pudo completarse. Desde el punto de vista del usuario, la acción falló. Desde el punto de vista de Midnight, el fallo llegó después de que el libro mayor ya se había movido.
Eso no es un pequeño caso de borde semántico. Eso es comportamiento del producto.
Y Midnight no trata esa división como accidental. La documentación dice que si una llamada de contrato contiene secciones garantizadas y falibles, la sección falible debe comenzar con ckpt. Me gusta ese detalle porque hace la arquitectura honesta. La línea entre "esto debe sobrevivir" y "esto puede abortar aún" es explícita. Los constructores no solo están decidiendo qué hace su lógica privada. Están decidiendo qué se permite que el sistema conserve si la intención completa nunca llega.
Ahí es donde comienza la presión de diseño.
Un constructor puede mirar un contrato de Midnight, ver que las pruebas son correctas, y aún así perderse la pregunta más difícil. Si esta acción falla tarde, ¿qué ya se ha vuelto verdadero? Si la respuesta es "algunos compromisos, algunos anuladores, la tarifa, y un registro de éxito parcial", entonces la aplicación no puede hablar sobre fallos de la misma manera que lo haría un sistema de retroceso normal. La lógica de reintento cambia. La mensajería al usuario cambia. El soporte cambia. Un estado de error rojo ya no puede significar "no pasó nada."
Ese es el verdadero intercambio. Midnight obtiene un modelo de transacción más expresivo. El trabajo garantizado puede separarse del trabajo falible posterior. Eso es útil. Le da a los constructores más control sobre la estructura de ejecución. Pero el precio es que las aplicaciones tienen que diseñar en torno al éxito parcial como un estado de primera clase. No un error. No un accidente de implementación. Un estado.
Si no lo hacen, el producto comienza a mentir.
El usuario ve "fallido." El libro mayor dice "completado parcialmente." La tarifa se ha ido de cualquier manera. Esa brecha es donde comienza la confusión. Un equipo puede interpretarlo fácilmente mal también. Pueden tratar el problema como un fallo de tiempo de ejecución normal, cuando el verdadero problema es que el modelo de transacción permitió que algunos efectos sobrevivieran por diseño. Midnight no lo ocultó de ellos. La documentación se los dijo. El error es pretender que la experiencia del usuario puede permanecer todo-o-nada después de que la semántica dejó de ser todo-o-nada.
Esa es la razón por la que creo que el modelo de ejecución de Midnight merece más atención de la que recibe. La gente hablará sobre privacidad, divulgación selectiva, y lo que puede permanecer oculto. Está bien. Pero un producto serio no solo se define por lo que puede ocultar. También se define por lo que permite que el fallo signifique. Midnight cambia ese significado de una manera muy exacta. Una acción privada fallida puede aún tener una mitad frontal irreversible.
Así que el estándar de revisión real no puede detenerse en "¿verifica la prueba?" También tiene que preguntar: ¿qué efectos se colocaron en la fase garantizada, qué sobrevive a un fallo tardío, y explica la aplicación eso de manera honesta al usuario? En Midnight, esos no son detalles secundarios de UX. Son parte de la semántica.
Las aplicaciones Midnight más fuertes serán aquellas que traten el éxito parcial como un estado real del producto desde el primer día. Las más débiles seguirán llamándolo fallo y esperarán que nadie note que el libro mayor ya se movió.
@MidnightNetwork $NIGHT #night
