A lo largo de estos años, al ver los modelos económicos de las cadenas PoS, he desarrollado un hábito: no mirar la tasa anual inflada por los oficiales; primero ver cómo diseñan el "costo de hacer el mal" y el "costo de holgazanear". Solo cuando esas dos cifras están bien calculadas, la seguridad a largo plazo de esa cadena puede considerarse fundamentada.

La distribución de recompensas por producción de bloques de Dusk, desglosada, es: 80% para quienes producen bloques, 10% para el comité de votación y 10% para el tesoro técnico. A simple vista no parece nada novedoso. Lo que en realidad me hizo mirar dos veces es que dentro de ese 80% para los productores de bloques hay otra estructura: 70% se recibe fijo y el 10% restante es variable, atado a cuántas firmas de votantes se hayan incluido con este bloque. Cuanta más participación de votación completa haya, más obtiene esa parte variable. Este diseño resuelve un problema concreto: evitar que el productor de bloques, por conveniencia, se limite a producir con menos votaciones, y al hacerlo se quede también sin la probabilidad de recompensas para los votantes.

Siguiendo hacia abajo, hay otro mecanismo que antes no había prestado mucha atención: el problema de la incentivación para el próximo productor de bloques. En cada ronda, quién será el productor de bloques en la k-ésima iteración puede calcularse con anticipación; en las rondas posteriores, los candidatos que podrían llegar a ser productores de bloques, en teoría, tienen motivos para esperar que las rondas previas fracasen para que les toque a ellos y así obtener recompensas. Dusk ofrece cuatro capas de mitigación: el voto en sí también otorga recompensas, para que los votantes no se pongan a holgazanear apostando a una recompensa mayor pero con una probabilidad menor; la recompensa del productor de bloques se vincula a la integridad de la cantidad de votos; en cada ronda, los candidatos de la siguiente ronda quedan excluidos de la elegibilidad para votar; y además se establece un límite máximo de iteraciones por ronda.

Mirar una sola regla por sí sola no es algo sorprendente, pero que las cuatro se sumen para tapar el mismo agujero, este enfoque de "parches en capas", en realidad es la señal que yo uso para juzgar si un equipo realmente pasó por pruebas en testnet y vio escenarios maliciosos, en vez de simplemente subir en producción después de dibujar diagramas de arquitectura en papel. En la parte de sanciones, también se distingue entre gravedad: los errores pequeños conllevan un bloqueo y reducción de peso de forma blanda; los graves, como difundir bloques inválidos o votar dos veces, queman directamente una parte del depósito. La separación entre capas blandas y duras, y ese nivel de granularidad, me parece más maduro que el de muchas cadenas PoS que se lanzaron hace dos años.

En cuanto a la ingeniería de mecanismos, normalmente nadie quiere leerla; solo cuando ocurre un incidente alguien la saca a mirar. Yo, en cambio, pienso que debería ser al revés: el mejor momento para leerla es cuando todavía no ha pasado nada.

¿Con qué opción estás más de acuerdo para juzgar si una cadena PoS es madura?
@Dusk $DUSK #dusk