En una reunión sobre operaciones de liquidación, alguien dijo: «Se confirma en unos segundos». Lo primero es preguntar a qué estado se refiere esa afirmación. El secuenciador y los bloques de L2 pueden ofrecer una respuesta visible antes, pero eso solo indica que la solicitud ha entrado en una fase del procesamiento; el batcher añade otra capa de verificabilidad al publicar los datos en DuskDS; y el compromiso de estado y el estado final son las pruebas que más se acercan a lo que exige un compromiso de liquidación.
Por eso, los SLA de experiencia y los SLA de liquidación deben definirse por separado. El SLA de experiencia puede indicar cuánto se tarda en ver una respuesta del secuenciador o de L2 tras el envío; el SLA de liquidación debe especificar cuándo se publican los datos, cuándo puede consultarse el compromiso de estado y cuándo se alcanza el estado final. Que el primer plazo sea corto no significa que el compromiso posterior ya se haya cumplido.
Esta separación por etapas también facilita explicar los retrasos. El usuario puede ver la transacción rápidamente y, aun así, tener que esperar a que el batcher publique los datos o a que se establezca el estado subyacente. Si se anuncia la finalización basándose únicamente en el momento más temprano, el equipo financiero puede confundir la visibilidad con una autorización para liberar los fondos. La lista de verificación debe registrar el objeto, el momento y el siguiente paso de cada etapa, en lugar de limitarse a conservar un único estado de «confirmado».
En la descripción de la liquidación de @Dusk , $DUSK no constituye una prueba de SLA. #dusk puede hablar de velocidad y finalidad, pero no debe presentar una inclusión rápida como una liquidación finalizada.
Si el equipo quiere incluir los tiempos de espera en un contrato o en un compromiso operativo, debe definir y medir por separado los cuatro hitos. Sin una definición de los hitos, «liquidación en segundos» solo describe una impresión de la experiencia; no puede servir como SLA del estado final.
Al separar los dos SLA, se evita que la experiencia del usuario y la responsabilidad de liquidación se comprometan mutuamente más allá de lo debido.
El contrato también debe especificar los límites de inicio y fin de cada intervalo: desde el envío hasta la inclusión, desde la inclusión hasta la publicación de los datos, desde la publicación hasta el compromiso de estado y, por último, hasta el estado final.
Las definiciones deben quedar claras.
Si los momentos son distintos, los compromisos no pueden ser los mismos.
Por eso, los SLA de experiencia y los SLA de liquidación deben definirse por separado. El SLA de experiencia puede indicar cuánto se tarda en ver una respuesta del secuenciador o de L2 tras el envío; el SLA de liquidación debe especificar cuándo se publican los datos, cuándo puede consultarse el compromiso de estado y cuándo se alcanza el estado final. Que el primer plazo sea corto no significa que el compromiso posterior ya se haya cumplido.
Esta separación por etapas también facilita explicar los retrasos. El usuario puede ver la transacción rápidamente y, aun así, tener que esperar a que el batcher publique los datos o a que se establezca el estado subyacente. Si se anuncia la finalización basándose únicamente en el momento más temprano, el equipo financiero puede confundir la visibilidad con una autorización para liberar los fondos. La lista de verificación debe registrar el objeto, el momento y el siguiente paso de cada etapa, en lugar de limitarse a conservar un único estado de «confirmado».
En la descripción de la liquidación de @Dusk , $DUSK no constituye una prueba de SLA. #dusk puede hablar de velocidad y finalidad, pero no debe presentar una inclusión rápida como una liquidación finalizada.
Si el equipo quiere incluir los tiempos de espera en un contrato o en un compromiso operativo, debe definir y medir por separado los cuatro hitos. Sin una definición de los hitos, «liquidación en segundos» solo describe una impresión de la experiencia; no puede servir como SLA del estado final.
Al separar los dos SLA, se evita que la experiencia del usuario y la responsabilidad de liquidación se comprometan mutuamente más allá de lo debido.
El contrato también debe especificar los límites de inicio y fin de cada intervalo: desde el envío hasta la inclusión, desde la inclusión hasta la publicación de los datos, desde la publicación hasta el compromiso de estado y, por último, hasta el estado final.
Las definiciones deben quedar claras.
Si los momentos son distintos, los compromisos no pueden ser los mismos.