Aller au contenu
Financial Context Wiki

Verrous temporels : transactions et actions de gouvernance différées

Un verrou temporel oblige une transaction ou une action de contrat à attendre un bloc, un horodatage ou un intervalle. Découvrez comment le délai est imposé et quelles voies peuvent le contourner.

Mis à jour

À des fins éducatives uniquement ; ne constitue pas un conseil ou une recommandation d’investissement. Tout investissement peut entraîner des pertes.

Réponse directe

Un verrou temporel est une règle imposée par une blockchain ou un contrat intelligent qui empêche une transaction, une dépense ou une action administrative de devenir valide ou exécutable avant qu’une hauteur de bloc, un horodatage ou un intervalle défini soit atteint. Il modifie le moment où l’action peut se produire ; il ne détermine pas si elle est correcte.

Le terme recouvre des mécanismes différents. Un verrou au niveau d’une transaction peut rendre une pièce indisponible ou maintenir une transaction non finale jusqu’à ce qu’une condition de la chaîne soit satisfaite. Un verrou de gouvernance met en file une invocation de contrat déjà autorisée et exige un délai minimal avant son envoi par un exécuteur. Leurs horloges, transitions d’état et modes de défaillance diffèrent.

La valeur de sécurité vient du délai imposé. En gouvernance, il peut donner aux observateurs et aux utilisateurs le temps d’examiner la charge en file, d’alerter, d’annuler ou de suspendre par une voie autorisée, ou de sortir si une voie réelle existe. Cet avantage disparaît dès qu’une voie privilégiée peut modifier le même système sans passer par le verrou.

Fonctionnement

  1. Le mécanisme définit une horloge. Le seuil peut utiliser une hauteur de bloc, un horodatage dérivé de la chaîne ou le temps écoulé depuis un événement antérieur sur la chaîne. Ce sont des valeurs du protocole, pas des promesses d’heure civile exacte.
  2. L’action verrouillée est liée à une condition. Un verrou absolu indique une hauteur ou une heure future. Un verrou relatif mesure un intervalle depuis un événement, comme la confirmation de la sortie à dépenser. Un contrôleur de gouvernance enregistre une opération planifiée et son heure de disponibilité.
  3. La couche concernée impose l’attente. Les règles de consensus peuvent rejeter une transaction ou une dépense de script prématurée. Un contrat intelligent peut rejeter un appel anticipé. Un compte à rebours sur un site n’est pas un verrou, car l’interface peut être contournée.
  4. L’échéance change l’éligibilité, pas l’intention. Une fois la condition satisfaite, l’action peut devenir valide ou prête, sans être nécessairement diffusée ou exécutée automatiquement. Quelqu’un doit encore l’envoyer et les autres contrôles d’autorisation et de validité restent applicables.
  5. La couverture dépend de l’autorité. En gouvernance, le verrou doit détenir la propriété ou les rôles nécessaires sur le contrat cible, et toute voie privilégiée équivalente doit aussi être retardée. Les droits de proposition, d’annulation, d’exécution et d’administration déterminent qui peut planifier, arrêter, exécuter ou reconfigurer les opérations.

Bitcoin illustre la distinction transactionnelle. BIP 65 définit CHECKLOCKTIMEVERIFY, qui peut rendre une sortie indisponible jusqu’à une condition absolue de hauteur ou de temps. BIP 68 donne aux numéros de séquence des entrées admissibles un sens de verrou relatif imposé par consensus, mesuré depuis l’âge de la sortie dépensée. Ces règles ne sont pas la file d’un contrat de gouvernance.

Le TimelockController d’OpenZeppelin illustre le délai de gouvernance. Un proposant planifie une opération identifiée avec un délai au moins égal au minimum. Après expiration du minuteur, elle passe d’en attente à prête ; un exécuteur doit ensuite l’exécuter. L’annulation et les rôles suivent les règles du contrat, et la modification du délai minimal doit elle-même passer par le verrou.

Exemples

Mise à niveau de protocole en file

Une DAO approuve une mise à niveau et son gouverneur planifie dans le verrou l’adresse cible, la valeur, les données d’appel, la dépendance et le sel exacts. Pendant le délai, les outils de surveillance peuvent comparer la charge à la proposition et simuler ses effets. Lorsque l’opération est prête, un exécuteur autorisé l’envoie.

La protection n’existe que si le verrou contrôle réellement l’autorité de mise à niveau. Si un autre propriétaire, administrateur de proxy, conseil de sécurité ou module peut installer immédiatement la même mise à niveau, cette voie de contournement doit être évaluée séparément. Le délai n’est utile que si la surveillance est rapide et si retrait ou migration peuvent finir avant l’exécution.

Chemin de transaction différé

Un script peut proposer un chemin de dépense avant une échéance et un chemin de remboursement après. La chaîne impose la condition lors de la validation de la dépense. Atteindre le seuil ne déplace pas les fonds : la partie admissible doit construire et diffuser une transaction valide, et sa confirmation dépend toujours des frais et de l’inclusion dans un bloc.

Risques et liste de contrôle

  • Autorité de contournement : un autre propriétaire, rôle, module, une clé de mise à niveau ou une voie d’urgence peut exécuter l’action protégée sans attendre.
  • Horloge ou limite erronée : hauteur, temps de chaîne et temps écoulé ne sont pas interchangeables ; une erreur d’une unité peut autoriser la dépense plus tôt ou plus tard que prévu.
  • Délai insuffisant : l’attente peut être plus courte que le temps nécessaire pour détecter, analyser, communiquer et réagir.
  • Pas de sortie pratique : retraits suspendus, retards de pont, illiquidité, désengagement ou congestion peuvent empêcher d’agir pendant la fenêtre nominale.
  • Rôle compromis ou blocage : un proposant ou administrateur malveillant peut mettre des appels nuisibles en file ; des exécuteurs perdus ou des droits d’annulation trop larges peuvent bloquer des opérations légitimes.
  • Charge divergente : un titre lisible ne prouve pas que la cible, la valeur, les données, la dépendance et le sel planifiés réalisent ce qui a été approuvé.
  • Différences d’implémentation : expiration, annulation, lots, dépendances, exécution ouverte et modification du délai varient selon le contrat et la version.
  • Erreur de verrouillage : un mauvais horodatage, une mauvaise hauteur, séquence, branche de script ou clé peut rendre les actifs inaccessibles plus longtemps que prévu.

Idées reçues

Un verrou s’exécute-t-il automatiquement à l’échéance ?

Généralement non. L’échéance rend normalement l’action admissible. La transaction doit encore être diffusée ou un exécuteur doit appeler le contrat de gouvernance.

Un verrou rend-il la gouvernance sûre ?

Non. Il crée un temps de réaction, mais ne valide pas la charge, ne protège pas les clés privilégiées, ne garantit pas l’annulation et n’assure pas la sortie des utilisateurs. Une autorité parallèle sans délai peut annuler le contrôle.

Tous les verrous utilisent-ils l’heure civile ?

Non. Certains utilisent la hauteur de bloc, d’autres les horodatages de la chaîne, et d’autres un âge relatif. Les intervalles de bloc attendus et les horodatages ne sont pas des calendriers exacts.

Les verrous de transaction et de gouvernance sont-ils interchangeables ?

Non. Ils partagent l’idée d’une éligibilité différée, mais les règles de consensus, les conditions de script et les files de gouvernance protègent des actions différentes et doivent être examinées selon leurs propres spécifications.

Thèmes associés

Sources

Navigation

Rechercher dans le wiki...