J’ai vu la même équation être vérifiée deux fois aujourd’hui et j’ai failli passer à côté du pourquoi.
En lisant une note de sécurité de Dusk, une formule de frais : la limite de gaz multipliée par le prix du gaz égale le frais maximum. Elle est appliquée deux fois : une fois à l’entrée dans le mempool, puis à nouveau lors de l’exécution dans la machine virtuelle (VM).
Au premier passage, j’ai pensé que c’était une redondance. Ceinture et bretelles, rien de plus à creuser.
Je n’ai pas survécu au paragraphe suivant. Le contrôle uniquement au niveau du mempool n’était pas suffisant : un proposant malveillant n’est pas tenu de n’inclure que la version « honnête au mempool » des champs d’une transaction.
C’est là le vrai manque. Une valeur prouvée ou signée dans une partie d’une transaction n’est pas liée à toutes les couches qui l’utilisent ensuite. Quelqu’un peut s’engager à un frais légitime au départ et tout de même en fournir un autre à l’exécution, à moins que l’exécution refuse indépendamment de faire confiance à la vérification précédente.
Signer et prouver le frais maximum, vérifier au mempool, puis le proposant construit le bloc sans aucune obligation de préserver cela. La VM exécute alors une logique de remboursement en se basant sur ce qui est réellement arrivé.
Ça revient sans cesse : la plupart de la confiance repose sur le fait que le proposant reste honnête entre les points de contrôle — exactement l’hypothèse que la deuxième vérification tente d’éviter, parce qu’on ne peut pas s’y fier.
Je ne sais pas combien d’autres champs dans ce pipeline ne reçoivent qu’une seule couche de contrôle.
Qu’advient-il de cette vérification en cas de vraie congestion, quand les proposant sont sous pression pour construire vite ? 👍
#dusk $DUSK @Dusk
En lisant une note de sécurité de Dusk, une formule de frais : la limite de gaz multipliée par le prix du gaz égale le frais maximum. Elle est appliquée deux fois : une fois à l’entrée dans le mempool, puis à nouveau lors de l’exécution dans la machine virtuelle (VM).
Au premier passage, j’ai pensé que c’était une redondance. Ceinture et bretelles, rien de plus à creuser.
Je n’ai pas survécu au paragraphe suivant. Le contrôle uniquement au niveau du mempool n’était pas suffisant : un proposant malveillant n’est pas tenu de n’inclure que la version « honnête au mempool » des champs d’une transaction.
C’est là le vrai manque. Une valeur prouvée ou signée dans une partie d’une transaction n’est pas liée à toutes les couches qui l’utilisent ensuite. Quelqu’un peut s’engager à un frais légitime au départ et tout de même en fournir un autre à l’exécution, à moins que l’exécution refuse indépendamment de faire confiance à la vérification précédente.
Signer et prouver le frais maximum, vérifier au mempool, puis le proposant construit le bloc sans aucune obligation de préserver cela. La VM exécute alors une logique de remboursement en se basant sur ce qui est réellement arrivé.
Ça revient sans cesse : la plupart de la confiance repose sur le fait que le proposant reste honnête entre les points de contrôle — exactement l’hypothèse que la deuxième vérification tente d’éviter, parce qu’on ne peut pas s’y fier.
Je ne sais pas combien d’autres champs dans ce pipeline ne reçoivent qu’une seule couche de contrôle.
Qu’advient-il de cette vérification en cas de vraie congestion, quand les proposant sont sous pression pour construire vite ? 👍
#dusk $DUSK @Dusk