#dusk $DUSK Antes de la actualización del protocolo, normalmente primero realizo una ronda de transferencias, verificación de firmas y llamadas al contrato. Las pruebas pasan todas; la bolsa está lista para reanudar los depósitos y retiros, y el robot también empieza a retirar el hedge temporal, volviendo a colocar el inventario de DUSK en el mercado. Este es un escenario de flujo de lo más habitual.
Pero Dusk tiene un detalle que me recuerda que no debo apretar el botón de reanudar con prisa.
En la VM temporal local de Dusk, al configurar la altura de bloque a Boreas, solo significa que el programa está simulando ese período. Para saber qué reglas usa la verificación de firmas BLS, también hay que configurar por separado la Host Query Policy. Si falta este paso, la interfaz de pruebas muestra Boreas, pero por debajo podría seguir validando firmas con las reglas antiguas de PreFork.
Esto puede provocar un incidente financiero muy real: el robot prueba con éxito bajo las reglas antiguas, pero después de la actualización del nodo oficial, el nuevo nodo rechaza las transacciones usando las reglas nuevas. La bolsa acaba de reanudar depósitos y retiros: los retiros de los usuarios quedan bloqueados. El inventario de market making ya retiró el hedge, pero el repo en cadena no logra enviarse. Un solo check verde del reporte de pruebas, al final, podría convertirse en un mercado más delgado y fondos detenidos.
La primera vez que vi la separación entre la configuración de la altura del bloque y las reglas de verificación, pensé que era un poco engorroso. Pero cuando metes la posición real, esa capa de complejidad en realidad vale bastante: el desarrollador, el auditor y la bolsa deben dejar por escrito claramente qué conjunto de protocolo están probando, para que otros puedan volver a correr las pruebas bajo la misma versión. Así, además de reducir el engorro de las transacciones, al menos también da una explicación que inspira tranquilidad al trading.
Creo que este es un punto muy valioso de Dusk para las transacciones. La evidencia de una actualización en una cadena financiera no puede limitarse a “las pruebas pasaron”; también hay que incluir la versión de Rusk, la estrategia de Hard Fork y las reglas de firma. Solo cuando estas tres cosas están alineadas, el equipo de trading se atreve a acortar el tiempo de parada de depósitos y retiros, reducir el inventario de respaldo y recuperar la rotación de fondos más rápido.
Para $DUSK , la credibilidad del trabajo de ingeniería termina reflejándose en una cuenta muy concreta: después de la actualización, habrá menos transacciones fallidas, la bolsa reanudará depósitos y retiros antes, los fondos del market making regresarán a la cadena más rápido y las llamadas reales y el Gas podrán ocurrir de forma continua.
Tener todo verde en las pruebas solo significa que el programa terminó de correr; si las reglas también coinciden, entonces el mercado se atreve a volver a poner el dinero. En fin, mi experiencia personal es que: hasta el último detalle, mientras esté relacionado con la credibilidad de la ingeniería, todo es muy importante.
@Dusk
$BTC
Pero Dusk tiene un detalle que me recuerda que no debo apretar el botón de reanudar con prisa.
En la VM temporal local de Dusk, al configurar la altura de bloque a Boreas, solo significa que el programa está simulando ese período. Para saber qué reglas usa la verificación de firmas BLS, también hay que configurar por separado la Host Query Policy. Si falta este paso, la interfaz de pruebas muestra Boreas, pero por debajo podría seguir validando firmas con las reglas antiguas de PreFork.
Esto puede provocar un incidente financiero muy real: el robot prueba con éxito bajo las reglas antiguas, pero después de la actualización del nodo oficial, el nuevo nodo rechaza las transacciones usando las reglas nuevas. La bolsa acaba de reanudar depósitos y retiros: los retiros de los usuarios quedan bloqueados. El inventario de market making ya retiró el hedge, pero el repo en cadena no logra enviarse. Un solo check verde del reporte de pruebas, al final, podría convertirse en un mercado más delgado y fondos detenidos.
La primera vez que vi la separación entre la configuración de la altura del bloque y las reglas de verificación, pensé que era un poco engorroso. Pero cuando metes la posición real, esa capa de complejidad en realidad vale bastante: el desarrollador, el auditor y la bolsa deben dejar por escrito claramente qué conjunto de protocolo están probando, para que otros puedan volver a correr las pruebas bajo la misma versión. Así, además de reducir el engorro de las transacciones, al menos también da una explicación que inspira tranquilidad al trading.
Creo que este es un punto muy valioso de Dusk para las transacciones. La evidencia de una actualización en una cadena financiera no puede limitarse a “las pruebas pasaron”; también hay que incluir la versión de Rusk, la estrategia de Hard Fork y las reglas de firma. Solo cuando estas tres cosas están alineadas, el equipo de trading se atreve a acortar el tiempo de parada de depósitos y retiros, reducir el inventario de respaldo y recuperar la rotación de fondos más rápido.
Para $DUSK , la credibilidad del trabajo de ingeniería termina reflejándose en una cuenta muy concreta: después de la actualización, habrá menos transacciones fallidas, la bolsa reanudará depósitos y retiros antes, los fondos del market making regresarán a la cadena más rápido y las llamadas reales y el Gas podrán ocurrir de forma continua.
Tener todo verde en las pruebas solo significa que el programa terminó de correr; si las reglas también coinciden, entonces el mercado se atreve a volver a poner el dinero. En fin, mi experiencia personal es que: hasta el último detalle, mientras esté relacionado con la credibilidad de la ingeniería, todo es muy importante.
@Dusk
$BTC