Saltar al contenido
Financial Context Wiki

Colas de salida y retiro de validadores

Una solicitud de salida de un validador, la cola de capacidad de salida, el retraso de responsabilidad, la barrida o reclamación de retiro y el canje por parte del proveedor son diferentes etapas. Reconstruya la máquina de estados exacta del protocolo, la autoridad, el rendimiento, la posibilidad de sanción y la ruta de los activos antes de estimar cuándo se podrán gastar los fondos.

Actualizado

Solo para fines educativos; no es un consejo de inversión. Invertir puede resultar en pérdidas.

Respuesta directa

Una cola de salida de validadores limita la velocidad a la que el peso del consenso puede salir de un conjunto de validadores activos. No es necesariamente el mismo mecanismo que una cola de solicitud de retiro, un retraso por desvinculación o responsabilidad, un barrido automático de saldos elegibles, un reclamo iniciado por el usuario, o una cola de redención de un proveedor de staking. La pregunta útil no es “¿cuánto tiempo es la cola?” sino “¿en qué estado se encuentra esta posición, cuál es la siguiente transición y qué condición hace que el activo sea gastable por su propietario?”

Separar estas etapas y reclamaciones:

  • Aceptación de la solicitud: un mensaje firmado, transacción, llamada de contrato o instrucción del proveedor está válidamente incluido y atribuido al validador, cuenta o posición correcta.
  • Capacidad de salida o desactivación: un protocolo limita cuántos validadores o el peso efectivo pueden dejar de participar por época, sesión u otro intervalo.
  • Responsabilidad o demora de desvinculación: una posición vacante o no delegada permanece bloqueada, y puede seguir expuesta a sanciones por comportamientos anteriores atribuibles.
  • Procesamiento de retiro: un saldo elegible es impulsado por un barrido de protocolo, extraído por una transacción de reclamo, liberado de una cuenta de participación o transferido cuando se procesa una cola de vencimiento.
  • Redención del proveedor: un custodio, grupo, token de staking líquido o contrato de re-staking aplica su propio agrupamiento, liquidez, tarifas, tasa de cambio, permisos y retrasos alrededor del protocolo base.

Ethereum ilustra por qué las distinciones son importantes. Una salida completa de validador puede iniciarse con la clave de firma del validador o, bajo las reglas actuales, desde la capa de ejecución por la autoridad de retiro. Después de la programación de la salida y el posterior estado de retiro, un retiro completo elegible con credenciales de retiro de ejecución se ejecuta automáticamente. Los validadores heredados Type 1 y los validadores compuestos Type 2 tienen un comportamiento diferente en retiros parciales. Por lo tanto, una transacción de solicitud, salida por consenso, época de retiro y barrido son observaciones separadas.

Esas etiquetas Ethereum no son universales. En una cadena Cosmos SDK, la desdelegación de un delegador crea una entrada de desunión con un tiempo de finalización configurado por la cadena, y los módulos externos pueden poner una desunión en espera. En Solana, una autoridad de cuenta de participación desactiva una delegación, la participación se enfría a lo largo de los límites de las épocas, y la autoridad de retiro puede retirar la participación inactiva sujeta a cualquier bloqueo. Los contratos de restaking pueden agregar otra retirada en cola y una ventana sujeta a sanción. Siempre inspeccione la red, versión, módulo, contrato y términos de servicio exactos.

Cómo analizar el momento de salida y retiro

1. Define la posición y el conjunto de reglas

Registre el network, chain ID, bifurcación activa o tiempo de ejecución, bloque o época, versión del cliente/especificación, módulo de staking o contratos, y términos del servicio. Identifique si el objeto es una identidad de validador, auto-stake, participaciones delegadas, cuenta de stake, reclamación agrupada, token de staking líquido o asignación re-stakeada. No aplique una regla de salida del validador a la redención de un delegador o a la responsabilidad fuera de la cadena de un proveedor.

2. Verificar autoridad y solicitar aceptación

Mapea la clave de firma del validador, la credencial o autoridad de retiro, la autoridad de participación, el propietario de la cuenta, el llamador del contrato, el beneficiario y el pagador de la tarifa. Reproduce los campos de mensaje requeridos, el dominio de la firma, el índice o clave pública del validador, la cantidad, el nonce, el destino y la tarifa. Confirma la inclusión finalizada y el estado resultante; un archivo firmado localmente, una transacción enviada, un ticket de proveedor o una simulación exitosa no son prueba de que el protocolo haya aceptado la solicitud.

3. Reconstruye la máquina de estados

Escriba cada estado y transición en lugar de una fecha estimada. Un camino ilustrativo del validador es active -> exit_requested -> exit_scheduled -> exited -> withdrawable -> withdrawal_processed -> wallet_credited. Un delegado puede, en cambio, moverse a través de bonded -> unbonding -> matured -> transferred, mientras que una cuenta de participación puede ser active -> deactivating -> inactive -> withdrawn. Registre qué transiciones son automáticas y cuáles requieren otra transacción o acción de servicio.

4. Cuantifica cada cuello de botella

Separar los límites de solicitud-ingreso, la rotación de salida de validadores, los retrasos fijos, la capacidad de barrido de retiros, las colas de contratos, la agrupación de proveedores y la finalización o confirmación. Determinar si la capacidad se mide por registros de validadores, participación efectiva, saldo, solicitudes, gas o tiempo transcurrido. Consultar queue_ahead, capacity_per_interval, tamaño del conjunto activo o saldo, y cualquier límite en el mismo punto de observación finalizado. Una estimación simple ceil((work_ahead + own_work) / capacity) es válida solo cuando se cumplen los supuestos de orden y capacidad.

5. Localiza deberes, recompensas y posibilidad de ser castigado

Encuentra la época, altura o estado exacto en que terminan las responsabilidades de propuesta y votación, cuando se detienen las recompensas ordinarias, cuando aún se pueden aplicar sanciones y cuando el saldo deja de ser susceptible de reducción. Estos tiempos no necesitan coincidir. Mantén el validador en línea y correctamente configurado hasta que el estado del protocolo indique que sus responsabilidades han terminado; una solicitud de salida transmitida o el estado en la interfaz no son autoridad suficiente para apagarlo.

6. Rastrear las capas de activos y reclamaciones

Siga las unidades nativas desde la contabilidad vinculada o activa hasta pendiente, desvinculación, retirables, custodia de contrato, custodia del proveedor y la cuenta de destino. Valore por separado las acciones, los tokens de recibo o los tokens de staking líquido utilizando su tasa de cambio y precio de mercado. Reconciliar recompensas del protocolo, penalizaciones, recortes, comisiones, tarifas de redención, gas, costos de puente y redondeo. Vender un reclamo transfiere el riesgo de liquidez a un comprador; no acelera la transición del protocolo base.

7. Verificar la finalización y planificar la liquidez

Utilice el estado finalizado, eventos del protocolo, registros de la cola, objetos de retiro, saldos de cuentas de destino y responsabilidades del proveedor para probar cada transición. Guarde los identificadores de solicitud y la instantánea de parámetros utilizada para la estimación. Construya planes de efectivo con un rango y un margen de contingencia en lugar de una sola fecha, y defina la escalada para barridos faltantes, contratos pausados, credenciales incorrectas, insolvencia del proveedor o un saldo que difiera de la conciliación esperada.

Ejemplos resueltos

Cálculo de temporización en varias etapas

Considere un protocolo ilustrativo con block_time = 12 seconds y epoch = 30 blocks = 6 minutes. Una solicitud tarda 4 blocks en llegar al punto de confirmación elegido, espera 72 epochs por capacidad de salida, luego tiene un retraso de responsabilidad de 8 epochs y un 12 blocks esperado hasta el procesamiento de la transferencia:

4 * 12 = 48 seconds.

72 * 6 = 432 minutes.

8 * 6 = 48 minutes.

12 * 12 = 144 seconds = 2.4 minutes.

El tiempo ilustrativo total es 48 seconds + 432 minutes + 48 minutes + 2.4 minutes = 483.2 minutes = 8.0533 hours. Las etapas se suman porque son secuenciales. Esto no es una previsión Ethereum: las reglas reales pueden usar intervalos diferentes, churn dependiente del estado, retrasos mínimos, algoritmos de barrido y supuestos de finalización.

Cola basada en el peso con capacidad variable

Supongamos unidades efectivas work_ahead = 50,000, esta salida representa own_work = 320, y capacity_per_epoch = 640 inicial. Con capacidad constante:

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

En 6 minutes por época, eso es 79 * 6 = 474 minutes = 7.9 hours. Pero asuma que la capacidad cae a 512 después de la época 30. Las primeras 30 épocas procesan 30 * 640 = 19,200, quedando 50,320 - 19,200 = 31,120. El restante toma ceil(31,120 / 512) = 61 epochs, por lo que el total revisado es 30 + 61 = 91 epochs = 9.1 hours. Una estimación en vivo debe recalcular la capacidad y el orden en lugar de congelar una tasa de tablero.

Conciliación de saldo a través de salida

Un validador ilustrativo comienza con unidades 32, gana 0.40 antes de que terminen los deberes, incurre en 0.05 de penalidades ordinarias y posteriormente recibe una reducción de 1.20 atribuible según la ventana de exposición del protocolo. La cantidad disponible antes de cualquier tarifa del proveedor o impuesto es:

32 + 0.40 - 0.05 - 1.20 = 31.15 units.

La solicitud no aseguró un pago en unidades 32. Los cambios en el balance del protocolo, la contabilidad del proveedor y los cambios en el precio de mercado son libros separados. Si el destino recibe 31.15, eso reconcilia la ruta en unidades nativas pero no dice nada sobre el valor en efectivo ni los derechos de reembolso.

Reclamación líquida frente a redención en cola

Supongamos que los tokens de liquid-staking 100 se pueden vender ahora a 0.965 unidades nativas cada uno, generando:

100 * 0.965 = 96.5 units.

Un proveedor, en cambio, cotiza el canje a una unidad nativa por token después de una cola con una tarifa de 0.2%, o 100 * (1 - 0.002) = 99.8 units. La diferencia es 99.8 - 96.5 = 3.3 units, y el descuento por venta inmediata respecto a los ingresos cotizados en la cola es 3.3 / 99.8 = 3.3066%. El diferencial de 3.3 unidades compensa solo, en esta instantánea, el tiempo, la incertidumbre y la liquidez; la reducción, cambios en el tipo de cambio, pérdida de contrato o una cola en pausa pueden cambiar los ingresos posteriores.

Riesgos y fallos de revisión

  • Cola incorrecta: Las colas de salida de validadores, entrada de solicitudes de retiro, desvinculación, barrido, contratos y reembolso del proveedor tienen estados y capacidades distintos.
  • Reglas incorrectas: Otra cadena, bifurcación, entorno de ejecución, versión del módulo, red de pruebas o despliegue del contrato puede usar transiciones diferentes.
  • Parámetros obsoletos: La tasa de salida, los retrasos fijos, los límites de barrido, las comisiones, los bloqueos y las condiciones del proveedor pueden cambiar después de la estimación.
  • Solicitud no aceptada: Firmar, transmitir, simular o abrir un ticket no demuestra la aceptación definitiva por el protocolo.
  • Confusión de autoridad: Las claves del validador, retiro, stake, propietario, custodio y administrador del contrato pueden autorizar acciones distintas.
  • Error de credenciales o destino: Una conversión irreversible de credenciales o una dirección de retiro incorrecta puede transferir el control de forma permanente.
  • Apagado prematuro: Dejar de cumplir funciones antes del estado de salida registrado puede causar la pérdida de recompensas o sanciones.
  • Error en el corte de recompensas: La solicitud, la salida programada, la salida efectiva, la elegibilidad para retirar y la transferencia pueden tener reglas de devengo diferentes.
  • Riesgo residual de slashing: Los fondos retirados, en desvinculación o en cola pueden seguir expuestos a infracciones anteriores atribuibles.
  • Desajuste entre cantidad y peso: Una cola expresada como número de validadores puede no reflejar la capacidad aplicada por saldo efectivo o participaciones.
  • Error de cola dinámica: Los cambios posteriores de parámetros o del conjunto activo pueden alterar el rendimiento aunque las solicitudes posteriores no puedan adelantarse.
  • Confusión entre barrido y reclamación: Al alcanzar la elegibilidad puede producirse un envío automático, exigirse una reclamación o quedar pendiente un barrido circular.
  • Confusión entre retiro parcial y total: El retiro de saldo excedente, la desvinculación parcial y la salida completa del validador no son equivalentes.
  • Bloqueos y retenciones: Los bloqueos de cuenta, controles de gobernanza, pausas de seguridad o retenciones de módulos externos pueden durar más que el vencimiento nominal.
  • Desajuste con el proveedor: Un servicio puede retrasar, agrupar, limitar, compensar o rechazar el reembolso aunque el protocolo base haya terminado.
  • Superposición de restaking: Salir de la cadena base puede no liberar el stake asignado a otro servicio ni terminar su periodo de penalización.
  • Riesgo de base del derecho líquido: Un token de staking líquido puede cotizar por debajo del valor de su derecho o perder convertibilidad bajo tensión.
  • Comisiones y pérdidas por redondeo: El gas, las tarifas dinámicas, la comisión, la conversión de participaciones, los puentes y los cambios de decimales afectan al importe recibido.
  • Fallo de custodia o contrato: Las claves comprometidas, la insolvencia, la autoridad de actualización, los errores o un fallo del puente pueden bloquear o desviar activos.
  • Error de observabilidad y finalidad: Los paneles pueden retrasarse, omitir entradas retenidas, confundir estados estimados y finalizados o mostrar un evento posteriormente reorganizado.

Conceptos erróneos comunes

¿Significa enviar una salida que las responsabilidades del validador se detienen inmediatamente?

No. La solicitud de inclusión, la programación de salida y el estado en el que terminan los deberes son separados. Continúe operando según el protocolo hasta que el estado finalizado confirme que el validador ya no necesita participar.

¿Significa ‘retirable’ que la cartera de destino ha sido acreditada?

No. withdrawable generalmente describe la elegibilidad. El protocolo aún puede necesitar revisar el validador, un usuario puede necesitar reclamar, una cuenta puede necesitar un retiro explícito, o un proveedor puede necesitar liberar su responsabilidad. Verifique el saldo de destino.

¿Puede la longitud de la cola dividida por la tasa de hoy dar una fecha exacta?

No. La pantalla puede contar la unidad incorrecta, la capacidad puede depender del estado, pueden seguir retrasos fijos y el tiempo de barrido, y se pueden omitir etapas del proveedor. Declara todas las suposiciones y calcula un rango.

¿Vender un token de liquid-staking evita la cola de salida?

Proporciona al vendedor liquidez inmediata en el mercado si existe un comprador. La participación subyacente o el derecho de recompra de otro titular sigue cumpliendo con el protocolo y las reglas del proveedor, mientras que el vendedor acepta el precio de mercado y los costos de negociación.

¿Es un período de desvinculación o retiro anunciado un máximo garantizado?

No. Puede ser un retraso mínimo o esperado que excluye la inclusión de solicitudes, congestión, finalización, barridos, retenciones, pausas de contrato, agrupamiento del proveedor o respuesta a incidentes. Solo las reglas activas y el estado observado definen la finalización.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...