Ayer tenía intención de rendirme, pero intenté ejecutar en mi entorno local la configuración de nodos para el nodo @Dusk , y al compilar el repositorio central de rusk` en la red de pruebas me quedé atascado en un log de comparación en un estado de consenso sincronizado.
Me fui a revisar la lógica de staking de los nodos en el módulo consensus/staking y noté un nombre de variable bastante interesante: AttestationCapacity. De inmediato me picó la curiosidad.
Al principio creí que era solo un campo normal para registrar la cantidad bloqueada del nodo, pero siguiendo la cadena de llamadas dentro de rewards_emission.rs, descubrí que Dusk en el fondo está jugando una estrategia bastante hardcore de “asignación por capacidad de cómputo”.
En la mayoría de cadenas PoS anteriores, las recompensas del nodo son completamente un “juego de capital”. ¿Qué significa? Que si compras más monedas y bloqueas por más tiempo, recibes más recompensas de inflación; incluso si el servidor del nodo está colgado con una Raspberry Pi, nadie lo controla. Pero en el código de Dusk, vinculan fuertemente el rendimiento por staking del nodo con la latencia de respuesta de los cálculos ZK de la Piecrust VM.
Si un nodo solo tiene mucho saldo, pero en la ronda de consenso SA anterior se atrasa medio paso al procesar hashes Poseidon o al validar pruebas Plonk, el algoritmo de atenuación en el sistema le va a restar directamente el peso dinámico de su AttestationCapacity. En palabras simples: los “colgados” que no tienen la capacidad de cómputo, el sistema les recorta las ganancias de forma automática.
Otra idea de diseño bastante interesante es su lógica de quema de Gas. En el módulo de procesamiento de comisiones fee_collector, para cada transacción válida, el Base Fee se fija como una quema a nivel de protocolo, y solo la Priority Fee se distribuye según el peso entre los nodos de cómputo que realmente participan en la verificación ZK.
Calculé con los logs de cómputo que saqué en la red de pruebas: cuando el sistema de liquidación de activos RWA de capa superior alcanza cierta frecuencia de transacciones, la tasa de quema del Gas base compensa rápidamente la inflación de las recompensas por bloque del sistema.
No intenta vender ninguna idea de “ultra súper deflación”, sino que escribe directamente, en el código a nivel base, un modelo triangular donde “contribución de cómputo”, “asignación de staking” y “quema de Gas” se condicionan mutuamente. Participar en el consenso no es recibir agua sin hacer nada: hay que meter capacidad de hardware real en la cadena, y todas esas recompensas están ancladas en $DUSK .
#dusk
Me fui a revisar la lógica de staking de los nodos en el módulo consensus/staking y noté un nombre de variable bastante interesante: AttestationCapacity. De inmediato me picó la curiosidad.
Al principio creí que era solo un campo normal para registrar la cantidad bloqueada del nodo, pero siguiendo la cadena de llamadas dentro de rewards_emission.rs, descubrí que Dusk en el fondo está jugando una estrategia bastante hardcore de “asignación por capacidad de cómputo”.
En la mayoría de cadenas PoS anteriores, las recompensas del nodo son completamente un “juego de capital”. ¿Qué significa? Que si compras más monedas y bloqueas por más tiempo, recibes más recompensas de inflación; incluso si el servidor del nodo está colgado con una Raspberry Pi, nadie lo controla. Pero en el código de Dusk, vinculan fuertemente el rendimiento por staking del nodo con la latencia de respuesta de los cálculos ZK de la Piecrust VM.
Si un nodo solo tiene mucho saldo, pero en la ronda de consenso SA anterior se atrasa medio paso al procesar hashes Poseidon o al validar pruebas Plonk, el algoritmo de atenuación en el sistema le va a restar directamente el peso dinámico de su AttestationCapacity. En palabras simples: los “colgados” que no tienen la capacidad de cómputo, el sistema les recorta las ganancias de forma automática.
Otra idea de diseño bastante interesante es su lógica de quema de Gas. En el módulo de procesamiento de comisiones fee_collector, para cada transacción válida, el Base Fee se fija como una quema a nivel de protocolo, y solo la Priority Fee se distribuye según el peso entre los nodos de cómputo que realmente participan en la verificación ZK.
Calculé con los logs de cómputo que saqué en la red de pruebas: cuando el sistema de liquidación de activos RWA de capa superior alcanza cierta frecuencia de transacciones, la tasa de quema del Gas base compensa rápidamente la inflación de las recompensas por bloque del sistema.
No intenta vender ninguna idea de “ultra súper deflación”, sino que escribe directamente, en el código a nivel base, un modelo triangular donde “contribución de cómputo”, “asignación de staking” y “quema de Gas” se condicionan mutuamente. Participar en el consenso no es recibir agua sin hacer nada: hay que meter capacidad de hardware real en la cadena, y todas esas recompensas están ancladas en $DUSK .
#dusk