Al investigar la cadena PoS, lo que más me preocupaba antes era el APY y el período de bloqueo. Después de estudiar la Succinct Attestation y el Proof-of-Blind Bid de Dusk, empecé a fijarme en un problema más práctico: cuando $DUSK ya ha entrado en el estado de Blind Bid, ¿qué condiciones necesita cumplir el usuario para poder recuperarlo realmente?
Yo pensaba que participar en el consenso era, básicamente, solo apostar y delegar. Pero al revisar la documentación técnica de Dusk, descubrí que en realidad es una conversión de estados. En condiciones normales, el usuario bloquea #dusk en el Bid Contract, genera una bid que incluye el monto comprometido y un secretHash, la inserta en el Merkle Tree y, además, adjunta dos alturas clave: h{eligibility} (inicio para participar en el consenso) y h{expiration} (altura de vencimiento). En la fase de Generation, la red extrae al Generator de forma privada mediante Proof-of-Blind Bid; la identidad del pujador se mantiene siempre ofuscada. Mientras tanto, el Provisioner entra al comité mediante un sorteo determinista y, durante las fases de Reduction y Agreement, realiza dos rondas de votaciones sobre los bloques candidatos para lograr la finalización estadística.
Lo que realmente me preocupa es que enviar una Bid no significa poder salir en cualquier momento. Porque el Bid Contract establece que antes de que se alcance h{expiration}, el usuario no puede iniciar F^{WithdrawBid}. Además, Dusk separa los roles: puedes ser Generator (competir por el derecho a proponer bloques mediante Blind Bid) o Provisioner (participar en la validación bloqueando el stake en el Stake Contract). Si actúas como Provisioner con doble firma o con mala conducta, cualquiera puede llamar a la función F^{Slash} del Stake Contract para denunciarte; tu stake será castigado parcialmente. Es decir, participar en el consenso no es un botón, sino una ventana de tiempo regida por reglas del protocolo: tu @Dusk te protege a la vez que te expone al riesgo de sanción antes de que venza.
Por lo que veo, la verdadera solución de Dusk es: en el consenso PoS, resolver la transparencia del proceso de elección del líder y el problema de MEV. El protocolo arma estos estados con Blind Bid, un sorteo determinista, separación de roles y finalización estadística. El costo también es evidente: los usuarios ya no solo tienen que “apostar DUSK para ganar rendimientos”, sino que deben entender la relación entre Bid, Stake, Generator, Provisioner y Slashing.
Durante mucho tiempo voy a observar no tanto lo fácil que es entrar con el stake, sino si los usuarios comunes realmente entienden qué están esperando cuando participan en el consenso.
Yo pensaba que participar en el consenso era, básicamente, solo apostar y delegar. Pero al revisar la documentación técnica de Dusk, descubrí que en realidad es una conversión de estados. En condiciones normales, el usuario bloquea #dusk en el Bid Contract, genera una bid que incluye el monto comprometido y un secretHash, la inserta en el Merkle Tree y, además, adjunta dos alturas clave: h{eligibility} (inicio para participar en el consenso) y h{expiration} (altura de vencimiento). En la fase de Generation, la red extrae al Generator de forma privada mediante Proof-of-Blind Bid; la identidad del pujador se mantiene siempre ofuscada. Mientras tanto, el Provisioner entra al comité mediante un sorteo determinista y, durante las fases de Reduction y Agreement, realiza dos rondas de votaciones sobre los bloques candidatos para lograr la finalización estadística.
Lo que realmente me preocupa es que enviar una Bid no significa poder salir en cualquier momento. Porque el Bid Contract establece que antes de que se alcance h{expiration}, el usuario no puede iniciar F^{WithdrawBid}. Además, Dusk separa los roles: puedes ser Generator (competir por el derecho a proponer bloques mediante Blind Bid) o Provisioner (participar en la validación bloqueando el stake en el Stake Contract). Si actúas como Provisioner con doble firma o con mala conducta, cualquiera puede llamar a la función F^{Slash} del Stake Contract para denunciarte; tu stake será castigado parcialmente. Es decir, participar en el consenso no es un botón, sino una ventana de tiempo regida por reglas del protocolo: tu @Dusk te protege a la vez que te expone al riesgo de sanción antes de que venza.
Por lo que veo, la verdadera solución de Dusk es: en el consenso PoS, resolver la transparencia del proceso de elección del líder y el problema de MEV. El protocolo arma estos estados con Blind Bid, un sorteo determinista, separación de roles y finalización estadística. El costo también es evidente: los usuarios ya no solo tienen que “apostar DUSK para ganar rendimientos”, sino que deben entender la relación entre Bid, Stake, Generator, Provisioner y Slashing.
Durante mucho tiempo voy a observar no tanto lo fácil que es entrar con el stake, sino si los usuarios comunes realmente entienden qué están esperando cuando participan en el consenso.