Aller au contenu
Financial Context Wiki

Files de sortie et de retrait des validateurs

Une demande de sortie du validateur, la file d'attente de capacité de sortie, le délai de responsabilité, le balayage ou la réclamation de retrait, et le rachat du fournisseur sont des étapes différentes. Reconstruisez l'état exact de la machine à états du protocole, l'autorité, le débit, la possibilité de pénalisation et le chemin des actifs avant d'estimer quand les fonds seront disponibles.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Un mécanisme de file d’attente de sortie pour un validateur limite la vitesse à laquelle le poids du consensus peut quitter un ensemble de validateurs actifs. Ce n’est pas nécessairement le même mécanisme qu’une file d’attente de demande de retrait, un délai de désengagement ou de responsabilité, un balayage automatique des soldes éligibles, une réclamation initiée par l’utilisateur, ou une file d’attente de rachat d’un fournisseur de staking. La question utile n’est pas « combien de temps dure la file d’attente ? » mais « dans quel état se trouve cette position, quelle transition est la suivante, et quelle condition rend l’actif disponible pour son propriétaire ? »

Séparez ces étapes et revendications :

  • Acceptation de la demande : un message signé, une transaction, un appel de contrat ou une instruction de fournisseur est valablement inclus et attribué au valideur, compte ou position correct(e).
  • Capacité de sortie ou de désactivation : est un protocole qui limite combien de validateurs ou de poids effectif peuvent cesser de participer par époque, session ou autre intervalle.
  • Responsabilité ou délai de déliaison : une position sortie ou non déléguée reste verrouillée et peut rester exposée à des pénalités pour un comportement antérieur imputable.
  • Traitement des retraits : un solde éligible est poussé par un balayage de protocole, tiré par une transaction de réclamation, libéré d’un compte de mise, ou transféré lorsqu’une file d’attente de maturité est traitée.
  • Rachat par le fournisseur : un gardien, un pool, un token de liquid-staking ou un contrat de restaking applique ses propres regroupements, liquidités, frais, taux de change, autorisations et délais autour du protocole de base.

Ethereum illustre pourquoi ces distinctions sont importantes. Une sortie complète d’un validateur peut être initiée avec la clé de signature du validateur ou, selon les règles actuelles, depuis la couche d’exécution par l’autorité de retrait. Après la planification de la sortie et le passage ultérieur à l’état retirable, un retrait complet éligible avec des informations d’exécution de retrait est automatiquement effectué. Les validateurs Type 1 hérités et les validateurs Type 2 cumulés ont un comportement différent en matière de retrait partiel. Une transaction de demande, une sortie par consensus, une époque retirable et un balayage sont donc des observations distinctes.

Ces étiquettes Ethereum ne sont pas universelles. Dans une chaîne Cosmos SDK, la désaffectation d’un délégateur crée une entrée de délégation en cours de libération avec un délai de complétion configuré par la chaîne, et les modules externes peuvent mettre une délégation en cours de libération en attente. Dans Solana, l’autorité du compte de mise désactive une délégation, la mise en jeu refroidit à travers les frontières d’époque, et l’autorité de retrait peut retirer la mise inactive sous réserve de tout verrouillage. Les contrats de restaking peuvent ajouter un autre retrait en file d’attente et une fenêtre susceptible d’être frappée de pénalité. Inspectez toujours le réseau exact, la version, le module, le contrat et les conditions de service.

Comment analyser le moment de sortie et de retrait

1. Définir la position et le règlement

Enregistrez le network, chain ID, le fork ou runtime actif, le bloc ou l’époque, la version client/spécification, le module de staking ou les contrats, et les conditions de service. Identifiez si l’objet est une identité de validateur, un auto-stake, des parts déléguées, un compte de mise, une réclamation groupée, un jeton de liquid-staking ou une allocation restaké. N’appliquez pas de règle de sortie du validateur à un remboursement de délégateur ou à une responsabilité hors chaîne d’un fournisseur.

2. Vérifiez l’autorité et demandez l’acceptation

Cartographiez la clé de signature du validateur, le justificatif de retrait ou l’autorité, l’autorité de mise, le propriétaire du compte, l’appelant du contrat, le bénéficiaire et le payeur des frais. Reproduisez les champs de message requis, le domaine de signature, l’indice ou la clé publique du validateur, le montant, le nonce, la destination et les frais. Confirmez l’inclusion finalisée et l’état résultant ; un fichier signé localement, une transaction soumise, un ticket de fournisseur ou une simulation réussie n’est pas une preuve que le protocole a accepté la demande.

3. Reconstruire la machine à états

Écrivez chaque état et transition plutôt qu’une seule date estimée. Un chemin de validateur illustratif est active -> exit_requested -> exit_scheduled -> exited -> withdrawable -> withdrawal_processed -> wallet_credited. Un délégataire peut plutôt passer par bonded -> unbonding -> matured -> transferred, tandis qu’un compte de mise peut être active -> deactivating -> inactive -> withdrawn. Enregistrez quelles transitions sont automatiques et lesquelles nécessitent une autre transaction ou action de service.

4. Quantifiez chaque goulot d’étranglement

Séparez les limites de demande d’entrée, le roulement de sortie des validateurs, les délais fixes, la capacité de balayage des retraits, les files d’attente des contrats, le regroupement des fournisseurs et la finalité ou la confirmation. Déterminez si la capacité est mesurée par les registres des validateurs, la mise effective, le solde, les demandes, le gas ou le temps écoulé. Interrogez queue_ahead, capacity_per_interval, la taille ou le solde de l’ensemble actif et toutes les limites au même point d’observation finalisé. Une estimation simple ceil((work_ahead + own_work) / capacity) n’est valable que lorsque les hypothèses d’ordre et de capacité sont respectées.

5. Localiser les devoirs, les récompenses et la possibilité de pénalisation

Trouvez l’époque, la hauteur ou l’état exact où les devoirs de proposition et de vote prennent fin, où les récompenses ordinaires s’arrêtent, où les pénalités peuvent encore être appliquées, et quand le solde cesse d’être susceptible de coupure. Ces moments ne doivent pas coïncider. Gardez le validateur en ligne et correctement configuré jusqu’à ce que l’état du protocole indique que ses devoirs sont terminés ; une demande de sortie diffusée ou le statut sur l’interface utilisateur ne constitue pas une autorité suffisante pour l’arrêter.

6. Suivez les couches d’actifs et de revendication

Suivez les unités natives depuis la comptabilité liée ou active jusqu’aux comptes en attente, en cours de débondage, retirables, en séquestre de contrat, en garde de fournisseur et le compte de destination. Évaluez séparément les parts, les jetons de reçu ou les jetons de staking liquide en utilisant leur taux de change et le prix du marché. Rapprochez les récompenses du protocole, les pénalités, le slashing, la commission, les frais de rachat, le gaz, les coûts de pont et les arrondis. La vente d’une créance transfère le risque de liquidité à un acheteur ; elle n’accélère pas la transition du protocole de base.

7. Vérifiez l’achèvement et planifiez la liquidité

Utilisez l’état finalisé, les événements du protocole, les enregistrements de la file d’attente, les objets de retrait, les soldes des comptes de destination et les passifs du fournisseur pour prouver chaque transition. Enregistrez les identifiants de demande et l’instantané des paramètres utilisé pour l’estimation. Élaborez des plans de trésorerie avec une plage et une marge de sécurité plutôt qu’une date unique, et définissez l’escalade en cas de balayages manquants, de contrats suspendus, de mauvaises informations d’identification, d’insolvabilité du fournisseur ou d’un solde différent de la réconciliation attendue.

Exemples travaillés

Calcul du timing en plusieurs étapes

Considérez un protocole illustratif avec block_time = 12 seconds et epoch = 30 blocks = 6 minutes. Une requête prend 4 blocks pour atteindre le point de confirmation choisi, attend 72 epochs pour la capacité de sortie, puis a un délai de responsabilité 8 epochs et un 12 blocks attendu jusqu’au traitement du transfert :

4 * 12 = 48 seconds.

72 * 6 = 432 minutes.

8 * 6 = 48 minutes.

12 * 12 = 144 seconds = 2.4 minutes.

Le temps illustratif total est 48 seconds + 432 minutes + 48 minutes + 2.4 minutes = 483.2 minutes = 8.0533 hours. Les étapes s’additionnent parce qu’elles sont séquentielles. Ce n’est pas une prévision Ethereum : les règles réelles peuvent utiliser des intervalles différents, un roulement dépendant de l’état, des délais minimaux, des algorithmes de balayage et des hypothèses de finalité.

File d’attente basée sur le poids avec capacité changeante

Supposons que work_ahead = 50,000 unités effectives, cette sortie représente own_work = 320, et capacity_per_epoch = 640 initial. Avec une capacité constante :

ceil((50,000 + 320) / 640) = ceil(78.625) = 79 epochs.

À 6 minutes par époque, c’est 79 * 6 = 474 minutes = 7.9 hours. Mais supposons que la capacité tombe à 512 après l’époque 30. Les premiers 30 époques traitent 30 * 640 = 19,200, laissant 50,320 - 19,200 = 31,120. Le reste prend ceil(31,120 / 512) = 61 epochs, donc le total révisé est 30 + 61 = 91 epochs = 9.1 hours. Une estimation en direct doit recalculer la capacité et l’ordre plutôt que de figer un taux sur un tableau de bord.

Rapprochement des soldes à la sortie

Un validateur illustratif commence avec des unités 32, gagne 0.40 avant la fin des devoirs, encourt 0.05 de pénalités ordinaires, et reçoit plus tard une réduction de 1.20 attribuable à la fenêtre d’exposition du protocole. Le montant disponible avant tout frais de fournisseur ou impôt est :

32 + 0.40 - 0.05 - 1.20 = 31.15 units.

La demande n’a pas verrouillé un paiement en unité 32. Les changements de solde du protocole, la comptabilité du fournisseur et les variations de prix du marché sont des registres séparés. Si la destination reçoit 31.15, cela réconcilie le chemin en unités natives mais ne dit rien sur la valeur en monnaie fiduciaire ni sur les droits de remboursement.

Réclamation liquide contre rachat en file d’attente

Supposons que les jetons de liquid-staking 100 puissent être vendus maintenant à 0.965 unités natives chacun, rapportant :

100 * 0.965 = 96.5 units.

Un fournisseur indique plutôt le rachat à une unité native par jeton après une file d’attente avec des frais de 0.2%, ou 100 * (1 - 0.002) = 99.8 units. La différence est de 99.8 - 96.5 = 3.3 units, et la remise pour vente immédiate par rapport aux produits cités en file d’attente est de 3.3 / 99.8 = 3.3066%. L’écart de 3.3 unités compense le temps, l’incertitude et la liquidité uniquement dans cette instantané ; la sanction, les variations de taux de change, la perte de contrat ou une file d’attente suspendue peuvent modifier les produits ultérieurs.

Risques et échecs de révision

  • Mauvaise file : Les files de sortie des validateurs, d’entrée des demandes de retrait, de déliaison, de balayage, de contrat et de remboursement du fournisseur ont des états et capacités distincts.
  • Mauvais jeu de règles : Une autre chaîne, un fork, un environnement d’exécution, une version de module, un testnet ou un déploiement de contrat peut utiliser des transitions différentes.
  • Paramètres obsolètes : Le taux de sortie, les délais fixes, les limites de balayage, les frais, les blocages et les conditions du fournisseur peuvent changer après l’estimation.
  • Demande non acceptée : Signer, diffuser, simuler ou ouvrir un ticket ne prouve pas l’acceptation définitive par le protocole.
  • Confusion d’autorité : Les clés du validateur, de retrait, de stake, du propriétaire, du dépositaire et de l’administrateur du contrat peuvent autoriser des actions différentes.
  • Erreur d’identifiant ou de destination : Une conversion irréversible d’identifiant ou une mauvaise adresse de retrait peut transférer le contrôle de façon permanente.
  • Arrêt prématuré : Cesser les fonctions avant l’état de sortie enregistré peut entraîner la perte de récompenses ou des pénalités.
  • Erreur de date d’arrêt des récompenses : Demande, sortie planifiée, sortie effective, éligibilité au retrait et transfert peuvent suivre des règles d’accumulation différentes.
  • Risque résiduel de slashing : Les fonds sortis, en cours de déliaison ou en attente peuvent rester exposés à des infractions antérieures attribuables.
  • Écart entre nombre et poids : Une file affichée en nombre de validateurs peut ne pas refléter la capacité imposée selon le solde effectif ou les parts.
  • Erreur de file dynamique : Les changements ultérieurs de paramètres ou de l’ensemble actif peuvent modifier le débit même si les demandes plus récentes ne peuvent pas passer devant.
  • Confusion entre balayage et réclamation : L’éligibilité peut déclencher un envoi automatique, exiger une réclamation ou laisser attendre un balayage circulaire.
  • Confusion entre partiel et total : Le retrait du solde excédentaire, le retrait partiel de délégation et la sortie complète du validateur ne sont pas équivalents.
  • Blocages et retenues : Les blocages de compte, contrôles de gouvernance, pauses de sécurité ou retenues de modules externes peuvent dépasser l’échéance nominale.
  • Décalage du fournisseur : Un service peut retarder, regrouper, limiter, compenser ou refuser le remboursement même après l’achèvement du protocole de base.
  • Chevauchement du restaking : La sortie de la chaîne de base peut ne pas libérer le stake affecté à un autre service ni mettre fin à sa période de pénalité.
  • Risque de base du droit liquide : Un jeton de liquid staking peut se négocier sous la valeur de son droit ou perdre sa convertibilité en période de tension.
  • Frais et pertes d’arrondi : Le gas, les frais dynamiques, les commissions, la conversion des parts, les frais de pont et les changements de décimales affectent le montant reçu.
  • Défaillance de garde ou de contrat : Des clés compromises, l’insolvabilité, les droits de mise à niveau, des bogues ou une défaillance du pont peuvent bloquer ou détourner les actifs.
  • Erreur d’observabilité et de finalité : Les tableaux de bord peuvent être en retard, omettre des entrées retenues, confondre les états estimé et finalisé ou afficher un événement ensuite réorganisé.

Idées reçues

Est-ce que la soumission d’une sortie signifie que les fonctions de validateur s’arrêtent immédiatement ?

Non. La demande d’inclusion, la planification de sortie et l’état à laquelle les fonctions se terminent sont distincts. Continuez à fonctionner selon le protocole jusqu’à ce que l’état final confirme que le validateur n’est plus requis pour participer.

Est-ce que ‘retirable’ signifie que le portefeuille de destination a été crédité ?

Non. withdrawable décrit généralement l’éligibilité. Le protocole peut encore devoir balayer le validateur, un utilisateur peut devoir réclamer, un compte peut nécessiter un retrait explicite, ou un fournisseur peut devoir libérer sa responsabilité. Vérifiez le solde de destination.

La longueur de la file d’attente divisée par le taux d’aujourd’hui peut-elle donner une date exacte ?

Non. L’affichage peut compter la mauvaise unité, la capacité peut dépendre de l’état, des délais fixes et le temps de balayage peuvent suivre, et des étapes du fournisseur peuvent être omises. Indiquez toutes les hypothèses et calculez une plage.

La vente d’un jeton de liquid-staking permet-elle de contourner la file d’attente de sortie ?

Cela donne au vendeur une liquidité immédiate sur le marché si un acheteur existe. La participation sous-jacente ou la réclamation de rachat d’un autre détenteur suit toujours le protocole et les règles du fournisseur, tandis que le vendeur accepte le prix du marché et les coûts de transaction.

Une période de déliement ou de retrait annoncée est-elle un maximum garanti ?

Non. Il peut s’agir d’un délai minimum ou prévu qui exclut l’inclusion de la demande, la congestion, la finalité, les balayages, les interruptions, les pauses contractuelles, le traitement en lot par le fournisseur ou la réponse aux incidents. Seules les règles actives et l’état observé définissent l’achèvement.

Sujets liés

Sources

Navigation

Rechercher dans le wiki...