Hoy vi la misma ecuación verificarse dos veces y casi me pasé el porqué.
Leyendo una nota de seguridad de Dusk, una fórmula de tarifas: el límite de gas por el precio del gas equivale a la tarifa máxima. Se aplica dos veces: una al entrar al mempool, y otra dentro de la ejecución de la VM.
Primera lectura, pensé que era redundancia. Cinturón y tirantes; nada que profundizar.
No sobrevivió al siguiente párrafo. La validación solo en mempool no era suficiente: no se requiere que un proponente malicioso incluya únicamente la versión “honesta” del mempool de los campos de una transacción.
Ahí está la brecha real. Un valor que se prueba o firma en una parte de una transacción no vincula todas las capas que luego lo consumen. Alguien puede comprometerse con una tarifa legítima de antemano y aun así pasar otra diferente a la ejecución, a menos que la ejecución rechace de forma independiente confiar en que la comprobación anterior ocurrió.
Firma y prueba la tarifa máxima, el mempool lo verifica, el proponente construye el bloque sin obligación de preservar eso, y la VM ejecuta la lógica de reembolso contra lo que realmente haya llegado.
Vuelve a lo mismo: la mayor parte de la confianza recae en que el proponente se mantenga honesto entre puntos de control, exactamente la suposición de la que existe la segunda comprobación porque no se puede confiar en ella.
No sé cuántos otros campos en ese proceso solo reciben una capa de este tipo.
¿Qué pasa con esa comprobación bajo congestión real, cuando los proponentes están presionados para construir rápido? 👍
#dusk $DUSK @Dusk
Leyendo una nota de seguridad de Dusk, una fórmula de tarifas: el límite de gas por el precio del gas equivale a la tarifa máxima. Se aplica dos veces: una al entrar al mempool, y otra dentro de la ejecución de la VM.
Primera lectura, pensé que era redundancia. Cinturón y tirantes; nada que profundizar.
No sobrevivió al siguiente párrafo. La validación solo en mempool no era suficiente: no se requiere que un proponente malicioso incluya únicamente la versión “honesta” del mempool de los campos de una transacción.
Ahí está la brecha real. Un valor que se prueba o firma en una parte de una transacción no vincula todas las capas que luego lo consumen. Alguien puede comprometerse con una tarifa legítima de antemano y aun así pasar otra diferente a la ejecución, a menos que la ejecución rechace de forma independiente confiar en que la comprobación anterior ocurrió.
Firma y prueba la tarifa máxima, el mempool lo verifica, el proponente construye el bloque sin obligación de preservar eso, y la VM ejecuta la lógica de reembolso contra lo que realmente haya llegado.
Vuelve a lo mismo: la mayor parte de la confianza recae en que el proponente se mantenga honesto entre puntos de control, exactamente la suposición de la que existe la segunda comprobación porque no se puede confiar en ella.
No sé cuántos otros campos en ese proceso solo reciben una capa de este tipo.
¿Qué pasa con esa comprobación bajo congestión real, cuando los proponentes están presionados para construir rápido? 👍
#dusk $DUSK @Dusk