Volvía una y otra vez a un pequeño detalle mientras leía@Dusk arquitectura esta noche: el hecho de que el staking y las transferencias no son dApps aquí. Están integradas en el propio bloque cero. Eso me detuvo un segundo.
La mayoría de las cadenas tratan estas cosas como elementos que despliegas más tarde, que puedes actualizar libremente y que parcheas cuando hace falta. #dusk las codifica directamente en los Contratos Génesis en el lanzamiento. El Contrato de Transferencia gestiona cada @Dusk movimiento, en ambas cuentas de Moonlight y en las notas de Phoenix, administrando deducciones de gas y reembolsando todo lo que no se use.
El Contrato de Stake es donde se pone más estricto: impone el mínimo de 1,000 $DUSK , hace seguimiento a los epochs de madurez, procesa el unstaking, todo automáticamente a través de Piecrust durante la validación del bloque. También las penalizaciones de slashing, blandas y duras, se ejecutan programáticamente sin posibilidad de anulación manual.
Ahí hay seguridad real en esa rigidez. Nada crítico depende de algún contrato actualizable que alguien olvidó auditar correctamente.
Pero la rigidez funciona en ambos sentidos. Si alguna vez hace falta cambiar la lógica central, no es un parche silencioso: es un hard fork completo, que requiere que los stakers estén alineados.
¿Vale la pena ese intercambio a largo plazo?
$PROM
$TAC
La mayoría de las cadenas tratan estas cosas como elementos que despliegas más tarde, que puedes actualizar libremente y que parcheas cuando hace falta. #dusk las codifica directamente en los Contratos Génesis en el lanzamiento. El Contrato de Transferencia gestiona cada @Dusk movimiento, en ambas cuentas de Moonlight y en las notas de Phoenix, administrando deducciones de gas y reembolsando todo lo que no se use.
El Contrato de Stake es donde se pone más estricto: impone el mínimo de 1,000 $DUSK , hace seguimiento a los epochs de madurez, procesa el unstaking, todo automáticamente a través de Piecrust durante la validación del bloque. También las penalizaciones de slashing, blandas y duras, se ejecutan programáticamente sin posibilidad de anulación manual.
Ahí hay seguridad real en esa rigidez. Nada crítico depende de algún contrato actualizable que alguien olvidó auditar correctamente.
Pero la rigidez funciona en ambos sentidos. Si alguna vez hace falta cambiar la lógica central, no es un parche silencioso: es un hard fork completo, que requiere que los stakers estén alineados.
¿Vale la pena ese intercambio a largo plazo?
$PROM
$TAC
