#dusk $DUSK @Dusk he estado yendo y viniendo sobre algo relacionado con el anochecer (dusk) y creo que por fin encontré la forma real de ello.
saqué la lista de provisionadores hace un rato: las quince primeras direcciones tienen apenas menos de la mitad de todo lo que está vinculado (bonded), cero barras en cualquiera de ellas, y el participante más antiguo lleva más de un año en funcionamiento mientras que el más reciente maduró hace días. todo eso está ahí, por dirección, recalculado en cada bloque. eso es rigor real. nadie tiene que confiar en una afirmación sobre quién asegura esta cadena; pueden simplemente mirarlo.
luego ocurrió lo del puente. la wallet lanzó una alerta, los fondos se movieron, el equipo pausó cosas y envió un arreglo — excepto que el arreglo no estaba en esa misma capa verificable en absoluto. era una lista de bloqueo de destinatarios en el frontend de la web wallet. si estás ejecutando tus propias herramientas o la CLI, no heredas ninguna de esa protección. nada de eso toca la parte del stack que realmente está abierta a la inspección.
así que esto es lo que me ha dejado raro con el tema: la parte de dusk que es rigurosamente responsable (quién tiene participación, cuánto tiempo, posibles penalizaciones) no es la parte que tuvo que responder cuando realmente salió mal algo. la parte que respondió estaba en algún lugar que nadie puede auditar de la misma manera.
no digo que sea un mal intercambio necesariamente: enviar rápido probablemente importó más esa semana que la pureza arquitectónica. pero si una institución está evaluando a dusk sobre "qué tan verificable es este sistema", quizá esté calificando una capa distinta de la que realmente atrapará el próximo incidente.
así que, ¿qué capa te gustaría auditar primero: la que sostiene la participación (stake), o la que decide quién puede mover fondos?
saqué la lista de provisionadores hace un rato: las quince primeras direcciones tienen apenas menos de la mitad de todo lo que está vinculado (bonded), cero barras en cualquiera de ellas, y el participante más antiguo lleva más de un año en funcionamiento mientras que el más reciente maduró hace días. todo eso está ahí, por dirección, recalculado en cada bloque. eso es rigor real. nadie tiene que confiar en una afirmación sobre quién asegura esta cadena; pueden simplemente mirarlo.
luego ocurrió lo del puente. la wallet lanzó una alerta, los fondos se movieron, el equipo pausó cosas y envió un arreglo — excepto que el arreglo no estaba en esa misma capa verificable en absoluto. era una lista de bloqueo de destinatarios en el frontend de la web wallet. si estás ejecutando tus propias herramientas o la CLI, no heredas ninguna de esa protección. nada de eso toca la parte del stack que realmente está abierta a la inspección.
así que esto es lo que me ha dejado raro con el tema: la parte de dusk que es rigurosamente responsable (quién tiene participación, cuánto tiempo, posibles penalizaciones) no es la parte que tuvo que responder cuando realmente salió mal algo. la parte que respondió estaba en algún lugar que nadie puede auditar de la misma manera.
no digo que sea un mal intercambio necesariamente: enviar rápido probablemente importó más esa semana que la pureza arquitectónica. pero si una institución está evaluando a dusk sobre "qué tan verificable es este sistema", quizá esté calificando una capa distinta de la que realmente atrapará el próximo incidente.
así que, ¿qué capa te gustaría auditar primero: la que sostiene la participación (stake), o la que decide quién puede mover fondos?
