#dusk $DUSK @Dusk Mientras leía las notas de la versión de Boreas, me detuve en un pequeño cambio: DUSK ya no fija precios de SHA-256, Keccak y el hash genérico como si cada entrada costara lo mismo.

Un hash de 32 bytes y una llamada de hash de varios kilobytes hacen la misma consulta al host, pero no exigen el mismo trabajo. Boreas añade precios basados en el tamaño para esos tres, mientras que la verificación de multisig BLS escala según la cantidad de claves. La verificación KZG y la recuperación de secp256k1 no se describen como con precio según la longitud de la entrada. Preguntar qué consulta es “la más cara” sin fijar la longitud de la entrada y el número de claves es casi la pregunta equivocada.

La comparación es un precio plano por llamada de API frente al cómputo impuesto a los validadores. DUSK se acercó a la segunda opción.

Hay una complicación. Boreas es consciente de los forks: la ejecución histórica mantiene la semántica previa al fork, mientras que los contratos actuales reciben el nuevo calendario. Un cómputo equivalente puede implicar distinto gas según el contexto de ejecución necesario para la reproducción, algo incómodo para los desarrolladores que prevén costos.

Para DUSK, una mejor precisión del gas debería reducir la infrafacturación de cargas criptográficas y hacer la ejecución más consistente entre nodos. No prueba que las transiciones de estado hayan pasado a ser más baratas. Quizá se volvieron más honestamente cobradas, incluso cuando el número sube.

Sigo esperando datos de referencia por “bucket” de entrada. La contabilidad determinista solo convence cuando el gas cobrado se ajusta al trabajo real de CPU.
@Dusk #dusk #Dusk