Comprendre aléa et automatisation asynchrones
À la fin, expliquez le schéma avec vos mots, résolvez le cas et justifiez la correction.
Prérequis : Le problème de l’oracle · Smart contracts et composabilité
Niveau 2 · Intermédiaire →Parcours de lecture · 15 / 35 · Intermédiaire
Les besoins des contrats dépassent les cours financiers.
L’essentiel
Les besoins des contrats dépassent les cours financiers. Un jeu peut vouloir un tirage vérifiable ; une application peut avoir besoin qu’une fonction soit déclenchée quand une condition est remplie. Les services VRF visent un aléatoire accompagné d’une preuve vérifiable, tandis que l’automatisation sert au déclenchement d’actions selon une logique définie.
Le mécanisme
Un aléatoire vérifiable ne garantit pas que toutes les règles du jeu soient équitables. L’application peut conserver d’autres pouvoirs, et la manière de traiter la requête et son résultat compte. De même, automatiser une mauvaise règle ne la rend pas correcte.
Les points d’attention
Pour les actifs tokenisés, publier une valeur liquidative ou un état de réserves peut améliorer l’accès à l’information. La donnée reste liée aux processus qui la produisent : fréquence d’actualisation, qualité de l’attestation et définition exacte des actifs couverts.
Comprendre en profondeur
Un aléa vérifiable permet de contrôler qu’un résultat respecte le processus cryptographique du service. Demande et réponse sont séparées : l’application doit conserver l’association entre demande et tirage. L’automatisation soumet des transactions lorsque les conditions configurées sont remplies ; les contrats ne se réveillent pas spontanément.
Limites et erreurs fréquentes
L’aléa ne corrige pas des règles injustes. Permettre d’abandonner un résultat défavorable ou de changer les participants après la demande compromet le tirage. L’automatisation dépend aussi du financement, du gas et de l’état applicatif. La fonction exécutée doit revérifier les conditions plutôt que croire aveuglément une observation antérieure hors chaîne.
Le mécanisme en un schéma
- Figer les entrées
- Demande identifiée
- Réponse vérifiée ultérieure
- Appliquer les règles figées
Appliquer la leçon à un cas
Une loterie ferme les inscriptions, demande un aléa et attend la réponse. Une seconde demande concerne un autre tirage. Reliez chaque réponse à sa liste initiale par identifiant, même si les réponses arrivent dans l’ordre inverse.
Figez les participants admissibles et les règles du tirage concerné. Associez la réponse par identifiant, pas par ordre d’arrivée, et définissez à l’avance l’indisponibilité. Un nombre aléatoire vérifiable ne prouve pas que l’application l’a utilisé conformément aux règles annoncées.
Préparer une note de correction
Décrivez le passage et la correction proposée. Vous pourrez copier cette note pour la partager ; rien n’est envoyé. N’incluez aucune donnée personnelle ou confidentielle.