Attribués une fois après une réponse correcte.
Comprendre aléa et automatisation asynchrones
À connaître avant : Le problème de l’oracle · Smart contracts et composabilité
Parcours de lecture · 15 / 41 · 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
- 01Figer les entrées
- 02Demande identifiée
- 03Réponse vérifiée ultérieure
- 04Appliquer les règles figées
Ces repères représentent des notions liées, pas nécessairement des étapes successives.
Lire l’explication
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.
Replacez le mécanisme dans son contexte
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.
Appliquer dans l’atelier →Ce que ce mécanisme ne garantit pas
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.
La distinction qui change l’analyse
Une demande asynchrone produit un résultat ultérieur, pas une valeur immédiate. Consignez identifiant, réponse attendue et traitement des retards ou absences. L’interface ne devrait pas annoncer la réussite dès la soumission.
À vous de l’expliquer
Reprenez le cas ci-dessus. Nommez ce qui est établi, ce qui reste à vérifier et la preuve qui permettrait de conclure. Une réponse solide traite les deux côtés du schéma.
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.