@Dusk_Foundation
Algo en el whitepaper de Dusk me sorprendió: admite abiertamente una falla en su propio diseño en lugar de simplemente vender la visión. Los generadores de bloque se eligen mediante una fórmula determinista, de modo que un provisionador a veces puede saber con antelación que están “alineados” para un intento posterior del mismo bloque si los anteriores fallan; eso crea un incentivo extraño para simplemente dejar que esos intentos se derrumben.
El documento llama a esto el problema del incentivo del generador futuro, y en vez de pasarlo por alto, propone parches reales: recompensar a la gente solo por votar, vincular parte de la recompensa de un generador a cuántos votos incluye y mantener al generador que sigue en la línea fuera de la votación actual. Ese tipo de honestidad parece dirigido a quienes auditan sistemas como trabajo, no a quienes persiguen una narrativa, lo cual encaja con el planteamiento completo de Dusk hacia las finanzas reguladas.
Aun así, un parche no es una solución. Las recompensas ajustan la conducta, pero no eliminan la previsibilidad subyacente, y un provisionador bien financiado que no se preocupe por la reputación todavía podría decidir que el riesgo vale la pena. Es el mismo tipo de brecha que aparece entre el código y la ley: un protocolo puede hacer que la mala conducta sea costosa, pero solo un tribunal o un regulador puede hacerla decisiva independientemente de lo profundas que sean las bolsillos de alguien.
Todo esto no hace menos reflexivo el enfoque de Dusk; solo significa que la parte interesante de un whitepaper a menudo es el párrafo que admite una debilidad, no el que vende el resultado. Lee los límites que un proyecto se impone por sí mismo y, luego, decide cuánto de lo demás merece tu confianza.
Todavía estoy aprendiendo estas cosas, un paper a la vez, y honestamente esa es la parte divertida.
@Dusk_Foundation #dusk $DUSK