La posibilidad de solicitar la salida de un validador de Ethereum mediante EIP-7002 depende de quién controla su credencial de retiro, no simplemente de quién lo opera. La especificación describe una vía por la que una credencial de retiro de la capa de ejecución puede iniciar una solicitud de retiro o de salida. Su utilidad práctica es que quien controla esa credencial pueda actuar sin depender exclusivamente de la clave de firma activa del operador. Ahora bien, presentar una solicitud no significa que el validador ya haya salido, y una transacción ejecutada correctamente tampoco demuestra que los ETH hayan llegado.
Para entender el mecanismo conviene distinguir cuatro conceptos. La capa de ejecución procesa las transacciones y las llamadas a contratos de Ethereum. La capa de consenso gestiona la participación de los validadores y las transiciones de estado correspondientes. La clave de firma BLS activa de un validador firma los mensajes necesarios para sus tareas operativas. Su credencial de retiro identifica la autoridad de retiro; en la modalidad basada en una dirección de ejecución que se explica aquí, puede apuntar a una cuenta de propiedad externa, o EOA, o a un contrato inteligente.
Esta guía se basa en la especificación EIP-7002 con estado Final, no en un servicio de comisiones en tiempo real ni en un panel de validadores. Su fecha de creación, el 9 de mayo de 2023, documenta el origen de la propuesta, no su activación. La distinción que importa a lo largo de todo el proceso es entre poder solicitar una acción, que el protocolo la acepte y recibir finalmente los fondos.
Operar un validador y tener autoridad de retiro son funciones distintas
La sección de motivación de la EIP explica el problema que abordaba la propuesta: con el esquema anterior, solo la clave activa podía iniciar una salida. Si el propietario conservaba la credencial de retiro, pero encargaba a un tercero la operación del validador, podía necesitar la cooperación del operador para comenzar a salir. Los autores señalan tanto el riesgo de que el titular de la clave activa retuviera los fondos como la dificultad de recuperarlos cuando se perdían las claves activas.
EIP-7002 añade otra vía de inicio. La credencial de retiro puede mantenerse separada de la clave de firma utilizada en la operación habitual y, al mismo tiempo, adquirir la capacidad de activar el mecanismo de solicitud descrito. La separación importa porque operar un validador y controlar el destino y la autoridad de retiro de su capital en staking son responsabilidades diferentes. Encargar la primera a un proveedor no implica necesariamente entregarle la segunda.
Sin embargo, ser propietario económico no convierte automáticamente a alguien en el controlador de la credencial que reconoce el protocolo. Quien posee un token representativo de una participación en un fondo de staking o un saldo en una cuenta de custodia puede tener un derecho sujeto a los contratos o las condiciones del producto sin controlar ninguna credencial de los validadores subyacentes. No basta con preguntar de quién era el dinero que financió el staking: hay que identificar qué dirección reconoce el protocolo y quién puede hacer que esa dirección actúe.
La distinción tiene un paralelo en otros activos: la custodia y el control de claves pertenecen a capas de riesgo diferentes. Esa guía trata sobre tesorerías de Bitcoin, no sobre el mecanismo de salida de Ethereum. Su aportación pertinente aquí es separar la protección técnica de las claves de las cuestiones financieras y de custodia más amplias. EIP-7002 establece una vía de control dentro del protocolo; no determina las condiciones de reembolso del cliente, su cobertura de seguro ni su relación jurídica con el proveedor.
Qué identifica una solicitud de retiro
La solicitud vincula una dirección de origen, una clave pública de validador y un campo de importe. En la interfaz de la capa de ejecución, los datos de entrada contienen una clave pública de validador de 48 bytes seguida de un importe de tipo uint64: en total, 56 bytes. Son campos técnicos del mensaje, no una instrucción para revelar una clave de firma ni una frase semilla. La clave pública identifica al validador, pero por sí sola no autoriza a gastar fondos.
La clave pública es necesaria porque varios validadores pueden compartir una misma credencial de retiro de la capa de ejecución. Una dirección, por sí sola, no permitiría saber a cuál se refiere la solicitud. La justificación del uso de la clave pública y el requisito de coincidencia del llamante explican las dos partes del problema de autorización: identificar al validador correcto y vincular la solicitud con la dirección de retiro correcta.
El contrato registra la dirección que lo llama directamente mediante CALLER, expuesto en Solidity como msg.sender. La especificación exige que esa dirección coincida con la credencial de retiro registrada en el estado de la cadena de baliza. Un monedero ajeno no adquiere autoridad sobre otro validador por pagar gas o aportar su clave pública. Tampoco debe confundirse la admisión en la cola de ejecución con una prueba de que el consenso ya ha validado la autoridad del llamante para la acción solicitada.
El campo de importe es distinto del valor enviado con la transacción para pagar la comisión de la solicitud. Conceptualmente, una salida completa pone fin a la participación del validador, mientras que un retiro parcial permite retirar parte de un saldo sin terminar por completo esa participación. El documento de referencia remite a otra especificación para el procesamiento detallado en consenso. Por tanto, no permite que esta guía concrete las unidades del importe, valores especiales de ese campo, condiciones detalladas de elegibilidad ni plazos de espera exactos.
Cinco etapas entre enviar la solicitud y recibir los ETH
El mecanismo se entiende mejor como una secuencia de comprobaciones. Cada una responde a una pregunta más limitada que la siguiente. Aunque un monedero las reúna en un único indicador de progreso, las diferencias siguen siendo importantes cuando una solicitud parece haberse completado correctamente y los fondos esperados aún no han llegado.
| Etapa | Qué ocurre | Qué no demuestra |
|---|---|---|
| 1. Envío de la transacción | Se envía una transacción al contrato de solicitudes de la capa de ejecución. | El envío por sí solo no demuestra su inclusión ni su ejecución correcta. |
| 2. Admisión en ejecución | Una llamada que cumple los requisitos y paga una comisión suficiente añade un mensaje a la cola de ejecución. | La admisión no demuestra que se cumplan los requisitos del consenso ni que la salida haya terminado. |
| 3. Inclusión de la solicitud | Se extrae de la cola un número limitado de mensajes para incorporarlos a las solicitudes de un bloque. | La inclusión no demuestra que todas las solicitudes produzcan el cambio de estado deseado. |
| 4. Procesamiento en consenso | El consenso aplica sus reglas de validación y de transición de estado. | Una solicitud procesada no prueba, por sí sola, que se haya recibido un pago. |
| 5. Retiro final | El retiro resultante debe comprobarse por separado. | El comprobante previo de ejecución no sustituye a la evidencia del saldo recibido. |
Desplaza la tabla horizontalmente para ver todas las columnas.
El esquema de procesamiento en consenso lo indica expresamente: una solicitud «puede no superar las validaciones —por ejemplo, si el validador ya ha salido— sin que el bloque resulte inválido», según la traducción del texto de la EIP. Por ello, una transacción de ejecución válida puede coexistir con una solicitud que no produzca la transición deseada del validador. Revisar únicamente el comprobante de la transacción deja parte del proceso sin resolver.
Las capas intercambian los datos de las solicitudes incorporados al bloque, en lugar de exigir que el consenso consulte sincrónicamente a la ejecución para obtenerlos. La EIP explica que el consenso debe conservar datos suficientes para ejecutar su parte de la transición de estado incluso cuando la ejecución no esté disponible. Esta separación arquitectónica también ayuda a interpretar lo que ve el usuario: ejecutar la transacción y procesar el estado del validador son eventos relacionados, pero distintos.
El máximo de 16 y el objetivo de 2 cumplen funciones diferentes
La especificación de referencia fija un máximo de 16 solicitudes de retiro extraídas de la cola por bloque. Por separado, establece un objetivo de 2 solicitudes por bloque para el mecanismo dinámico de comisiones. Son controles distintos: el máximo limita la carga de procesamiento de solicitudes que se transmite al consenso; el objetivo influye en la respuesta de la comisión a la demanda.
La cola existe porque la ejecución puede admitir más llamadas de solicitud de las que recibe el consenso en un solo bloque. En vez de rechazar todas las llamadas que superen el máximo de extracción por bloque, el diseño almacena los mensajes para procesarlos más adelante. Esto puede evitar rechazos durante periodos de mucha actividad, pero no elimina la acumulación de solicitudes pendientes. Un mensaje puede haberse admitido correctamente y seguir esperando su inclusión entre las solicitudes que se transmiten, en número limitado, a la siguiente etapa.
La justificación de la limitación de solicitudes describe otra amenaza: alguien dispuesto a pagar el gas podría ocupar la capacidad disponible a un coste suficientemente bajo como para obstaculizar a los usuarios legítimos. La comisión adicional busca encarecer de forma creciente una demanda excesiva sostenida. Los autores describen una respuesta exponencial al uso acumulado por encima del objetivo, no un recargo fijo que permanezca igual durante la congestión.
Ninguno de estos parámetros promete un retiro. El objetivo no significa que salgan exactamente dos propietarios por bloque, y el máximo tampoco equivale a 16 salidas o pagos completados. Las solicitudes pueden estar sujetas a comprobaciones de elegibilidad y no son unidades de ETH. Convertir ese límite en una capacidad de ETH por bloque exigiría supuestos que la especificación no establece. Ninguna de las dos cifras proporciona una estimación actual del tiempo de espera.
Gas, comisión de solicitud y límites de la dirección llamante
Hay dos costes diferenciados: el gas ordinario de la transacción y la comisión de retiro exigida por el contrato de solicitudes. Pagar uno no sustituye al otro. La comisión de solicitud depende del estado del contrato, que puede cambiar entre la preparación de la transacción y su inclusión. Una cifra mostrada previamente no tiene por qué coincidir con la comisión aplicable cuando se ejecute la llamada.
La sección sobre pagos de comisión en exceso establece, en traducción: «Las comisiones pagadas en exceso no se devuelven al llamante». También explica cómo un contrato puede consultar la comisión vigente, rechazar una cifra superior a un límite elegido y efectuar la solicitud con el pago requerido dentro de una misma secuencia de ejecución. Es una capacidad de una lógica contractual diseñada para ello, no una prueba de que todos los monederos la incorporen.
Cuando la credencial está controlada por un contrato, cobran relevancia directa la autorización de los monederos inteligentes y los riesgos de sus módulos. Una dirección puede ser la credencial de retiro reconocida y, aun así, carecer en su código de una vía autorizada para realizar la llamada necesaria. El propietario debe entender qué firmantes, módulos, mecanismos de recuperación o controles de actualización pueden autorizar esa vía. La etiqueta «monedero inteligente» no acredita ninguno de esos detalles de implementación.
Un contrato intermediario genérico que reenvía llamadas no resuelve el mismo problema para una credencial EOA. Si el intermediario realiza la llamada, el contrato de solicitudes ve como llamante al intermediario, no a la EOA que está detrás. La EIP advierte expresamente de esta restricción. Su advertencia más amplia sobre los pagos en exceso desde una EOA debe interpretarse junto con la incertidumbre de la comisión y la ausencia de devoluciones; no como una afirmación matemática de que jamás pueda producirse un pago exacto. Una interfaz o un simulador tampoco adquieren autoridad de retiro por ayudar a preparar la solicitud.
Cómo cambia la vía de control según la modalidad de staking
La EIP contempla la posibilidad de que ciertos productos de custodia dependan de que las credenciales de retiro no puedan iniciar solicitudes. Por eso conviene revisar las políticas del servicio además de su funcionamiento técnico. La siguiente comparación es un marco de diligencia, no una conclusión sobre ningún proveedor. En todas las modalidades hay que separar quién puede autorizar una acción de la credencial, quién opera el validador y quién tiene un derecho económico.
| Modalidad | ¿Quién puede autorizar la vía descrita? | ¿Qué debe verificarse? | ¿Qué riesgos permanecen? |
|---|---|---|---|
| Propietario y operador individual | Quien controla la credencial de retiro coincidente. | La credencial registrada, la identidad del validador y una vía de solicitud utilizable. | Gestión de claves, elegibilidad, colas y exposición operativa del validador. |
| Operador separado del propietario de la credencial EOA | El propietario que controla la credencial EOA coincidente. | Que el propietario controla realmente la dirección registrada, y no solo una cuenta del servicio. | Incertidumbre de comisiones, retrasos de procesamiento y conducta del operador antes de la salida. |
| Credencial de retiro de contrato | Quien esté facultado por la lógica de autorización del contrato para iniciar la llamada. | Funciones disponibles, permisos, recuperación y autoridad de actualización. | Restricciones del contrato, defectos de código y dependencias de gobernanza. |
| Derecho sobre un fondo de staking o un servicio de custodia | El controlador de la credencial subyacente; no automáticamente cada cliente o titular de tokens. | Estructura de credenciales, procedimiento de reembolso y condiciones del producto. | Dependencias de contraparte o de contratos y un proceso de liquidez del cliente separado. |
Desplaza la tabla horizontalmente para ver todas las columnas.
También hay que distinguir otro límite: el slashing de un validador no es una salida voluntaria. El slashing responde a infracciones demostrables y a las penalizaciones asociadas, no a una solicitud ordinaria del propietario para dejar de participar. La admisión de una solicitud no prueba que haya terminado toda exposición operativa. La conducta del proveedor, las obligaciones que continúan vigentes y las reglas de penalización aplicables deben evaluarse por separado del comprobante de ejecución.
Controlar una credencial de retiro válida tampoco garantiza un reembolso contractual ni un seguro. Un proveedor puede tener obligaciones frente a sus clientes que van más allá de sus controles sobre los validadores dentro del protocolo. A la inversa, el procedimiento de retiro ofrecido al cliente puede imponer dependencias que no son visibles en la credencial del validador. Para resolver esas cuestiones hace falta la documentación del producto concreto; no basta con deducirlas de la interfaz de EIP-7002.
Un ejemplo hipotético con propietario, operador e interfaz
Supongamos que un propietario contrata a un operador para gestionar un validador, pero conserva el control de su credencial de retiro basada en una dirección de ejecución. Conoce la clave pública correcta del validador y utiliza una interfaz que le ayuda a preparar una solicitud EIP-7002. Todos los actores de este ejemplo son hipotéticos; no se presupone ningún saldo, cotización de comisiones ni tiempo de espera.
La primera pregunta es si la llamada efectiva procede de la dirección registrada como credencial a través de una vía de autorización utilizable. Después hay que comprobar la admisión en ejecución: ¿se ejecutó correctamente la llamada y se añadió un mensaje a la cola? El propietario necesita luego pruebas independientes de que la solicitud llegó al consenso y produjo el cambio de estado pertinente del validador. Por último, la recepción del retiro requiere su propia confirmación. Un indicador verde en la transacción solo responde a una parte de esta secuencia.
Compárese con una segunda persona hipotética que posee un token representativo de una participación en un fondo de staking. Puede controlar perfectamente ese token y carecer de autoridad sobre la credencial del validador. Su vía de salida puede pasar por el contrato de reembolso del fondo o por un custodio. La diferencia no está en la calidad de la interfaz, sino en qué dirección reconoce el protocolo y qué permisos conectan el derecho del usuario con esa dirección.
Los fallos del protocolo no son instrucciones de recuperación de un monedero
La especificación también define el comportamiento ante fallos de infraestructura. Una llamada de sistema fallida o la ausencia de código en la dirección designada para el contrato de solicitudes hacen que el bloque correspondiente sea inválido según las reglas descritas. Estas secciones explican requisitos del protocolo y el comportamiento de los clientes de Ethereum. No demuestran que esté ocurriendo uno de esos fallos, y el registro de la propuesta no es un panel del estado actual de la cadena.
Los usuarios no deben reinterpretar las explicaciones sobre recuperación de infraestructura como operaciones que deban realizar en su monedero. Desplegar contratos de reemplazo o cambiar parámetros de una bifurcación no es una respuesta normal a un retiro que tarda en aparecer. Tener en cuenta la versión aplicable significa consultar la documentación de implementación correspondiente y distinguir entre un problema de transacción, uno de autorización, un retraso de cola y un resultado del consenso antes de sacar conclusiones.
Lista de comprobación para evaluar el acceso a la salida
La preparación más útil consiste en identificar la autoridad y las pruebas necesarias antes de depender de una interfaz de retiro. Esta lista sirve para comprender el esquema de control, no para construir ni enviar una transacción.
- Identificar la credencial de retiro realmente registrada para el validador.
- Identificar la clave pública correcta del validador sin revelar claves secretas.
- Determinar si la autoridad de retiro corresponde a una EOA, a un contrato o a una dirección controlada por el proveedor.
- Si corresponde a un contrato, establecer qué permisos permiten la llamada requerida y quién puede cambiarlos.
- Separar el gas de la transacción de la comisión adicional de solicitud y comprender que los pagos en exceso no se devuelven.
- Distinguir la ejecución correcta, la inclusión de la solicitud procedente de la cola, el estado en consenso y los fondos recibidos.
- Contemplar la espera en cola sin convertir una estimación antigua en un plazo vigente.
- Revisar las condiciones del proveedor y la exposición operativa o a penalizaciones de forma independiente de la interfaz de solicitudes.
- No compartir nunca una frase semilla ni una clave de firma para demostrar la propiedad de un validador u obtener asistencia para salir.
Preguntas frecuentes
¿Puede el operador bloquear indefinidamente al propietario de la credencial de retiro?
El mecanismo descrito elimina la dependencia exclusiva del titular de la clave activa para iniciar la vía de la credencial de retiro. Eso no supone una garantía incondicional de plazos. El propietario debe controlar realmente una credencial coincidente y utilizable; siguen importando los permisos del contrato, el procesamiento de la solicitud y la elegibilidad en consenso. Un cliente que solo posee un derecho frente al proveedor puede no ser quien controla esa credencial.
¿Puede cualquiera forzar la salida del validador de otra persona?
Pagar gas y aportar la clave pública de un validador ajeno no concede autoridad de retiro. La especificación exige que la dirección llamante coincida con la credencial de retiro reconocida en el estado de la cadena de baliza. Como la admisión en ejecución y la validación en consenso son procesos separados, ver un mensaje en cola no basta para demostrar que una solicitud no autorizada pueda producir una salida.
¿Una transacción ejecutada correctamente demuestra que se retiraron los ETH?
No. Puede acreditar que la ejecución fue correcta y dejar sin resolver la elegibilidad en consenso y el retiro final. La EIP permite expresamente ciertos fallos de validación en consenso sin invalidar el bloque. La inclusión de la solicitud, las pruebas del estado del validador y el saldo recibido responden a preguntas diferentes; un único comprobante de ejecución no sustituye a las tres.
¿Una salida es lo mismo que el slashing?
No. Una salida solicitada por el propietario es conceptualmente distinta de una expulsión forzosa por una infracción sujeta a slashing. EIP-7002 ofrece una vía para presentar solicitudes, no declara que las penalizaciones desaparezcan cuando una transacción se ejecute correctamente. Evaluar la exposición que aún tenga un validador concreto exige conocer su estado y las reglas de consenso aplicables, no solo comprobar que se envió una solicitud.
¿Usar un monedero inteligente garantiza que la salida funcione?
No. El contrato debe ser la credencial reconocida y admitir la llamada necesaria mediante su lógica real de autorización. Los umbrales de firmas, los módulos, las restricciones de recuperación o la autoridad de actualización pueden afectar al acceso. La programabilidad abre posibles vías de control, pero la existencia y la seguridad de una vía concreta requieren pruebas específicas de su implementación.
¿Por qué un token de staking líquido no concede automáticamente autoridad sobre el validador?
El titular del token controla la posición de ese token en su cuenta, mientras que EIP-7002 comprueba la autoridad asociada a la credencial de retiro del validador. Son objetos diferentes y pueden tener controladores distintos. Para entender el acceso efectivo a la salida hay que identificar la vía de reembolso del producto y quién controla la credencial subyacente, en vez de tratar la propiedad del token representativo como un permiso directo para retirar un validador.
