Conceptos básicos de Re-staking

Dado un activo X, denotamos por [X] el activo restakeado, es decir, un activo que "encaja" a X de tal manera que parte o todo X puede ser capturado por alguna parte dada alguna condición arbitraria.

El ejemplo básico introducido por EigenLayer es el de un staker en solitario que vuelve a apostar su ETH actual en juego. Para hacerlo, el staker en solitario actualiza su dirección de retiro a la dirección de unEigenLayer pod. EigenPods son contratos inteligentes que rastrean los servicios a los que el validador en solitario se ha inscrito para asegurar con su participación. El EigenPod se convierte en el propietario del activo soETH, mientras acredita al validador en solitario con una representación de su ETH apostado.

La propiedad del activo soETH en nuestro marco denota el “primer derecho” sobre el ETH retirado del protocolo de Ethereum, es decir, posee un reclamo más senior que cualquier otro participante en la cadena. Cuando el apostador en solitario decide retirar su ETH del protocolo de Ethereum, el ETH retirado se filtra a través del contrato EigenPod, verificando si al apostador en solitario se le permite canjear la cantidad total de soETH o no (veremos más adelante en qué casos esto podría no ser así). Con nuestros balances:

Hacemos que cada paso sea explícito en lo siguiente:

1. El validador en solitario deposita su ETH en el protocolo de Ethereum, recibiendo una posición virtual de soETH del protocolo de Ethereum.
2. El validador en solitario deposita virtualmente su soETH en EigenLayer configurando su dirección de retiro a la dirección del pod de EigenLayer. A cambio, el validador en solitario recibe una posición virtual [soETH] de EigenLayer, lo que les permite finalmente ejecutar el orden de las operaciones en reversa.

Desequilibrios de saldo

Ya podemos hacer algunas observaciones interesantes a partir de las hojas de balance anteriores. La primera es que el protocolo Ethereum no tiene absolutamente ninguna concepción de [soETH], ya que esto no aparece en su propia hoja de balance. Este problema se discutió en “Desglose de PBS: Hacia compromisos de proponentes reforzados por protocolo (PEPC)Un validador sancionado por EigenLayer todavía tiene un balance completo de staking en la hoja de balance del protocolo Ethereum, lo que puede inducir riesgos morales y desequilibrios de recompensa (un validador realmente medio staked aún gana recompensas completas del protocolo Ethereum). Detallamos el escenario de sanción en las siguientes hojas de balance, dando números arbitrarios para ilustrar el problema:

Este problema se soluciona tan pronto como EigenLayer informa fielmente el corte de EigenLayer de un validador al protocolo Ethereum, reequilibrando las hojas. Esto es posible con EIP-7002: Salidas activables de la capa de ejecución, aunque a un nivel básico, ya que el desencadenador binario simplemente sale del validador, pero todavía se requiere la capa intermedia de EigenLayer o el EigenPod para activar la señal al protocolo PoS de Ethereum. Esta acción es en interés de EigenLayer porque el buen cálculo beneficia a los servicios que están asegurados a través de EigenLayer y también aumenta en última instancia la confianza de los operadores y re-apostadores en la ejecución fiel de la plataforma.

Un disparador más fino podría forzar una retirada parcial del saldo del validador del consenso de Ethereum, sin salir completamente del validador. Esto es deseable para los servicios de EigenLayer que desean penalizar parcialmente a los validadores, sin activar una salida. Tenga en cuenta que ni EIP-7002 ni las retiradas parciales desencadenadas por la capa de ejecución están disponibles en la red principal de Ethereum hoy. Tenga también en cuenta que@mikeneuder/eip-7251-faq">MaxEB (eliminando el límite de 32 ETH en el principal de un único validador en juego) se combinaría muy bien con retiros parciales, eliminando un incentivo adicional para que los validadores permanezcan desagregados (ejecutando muchos validadores de 32 ETH en lugar de un único validador de 2048 ETH, por ejemplo).

Falta esta función de retiro parcial, hay un incentivo adicional para mantener la contabilidad de EigenLayer separada de la contabilidad del protocolo de Ethereum, lo que, como mencionamos anteriormente, puede introducir desalineaciones. A continuación, representamos un validador sancionado por 8 ETH por EigenLayer, que no sale del validador de sus deberes de consenso (el saldo de expulsión es de 16 ETH):

AVS claims

Uno puede preguntarse a dónde van los 8 [soETH] en el ejemplo anterior. Esta decisión queda en manos de los Servicios Validados Activamente (AVS) impulsados por EigenLayer. Un AVS es un servicio que exige cierta participación como garantía. La presencia de una participación permite que el servicio se comprometa de manera creíble con cierto rendimiento, ya que la participación puede ser reducida si el servicio no se realiza correctamente.

El validador de re-staking se inscribe en AVSs a través de su EigenPod. Cuando lo hace, el EigenPod acuña nuevas reclamaciones que se ofrecen a los AVSs, representando el colateral actualmente retenido bajo el EigenPod. Ahora debemos hacer la distinción entre dos tipos de reclamaciones:

1. AVS afirma: Utilizamos [soETH] para denotar estas afirmaciones, enfatizando que se derivan del valor del activo entre corchetes [ ].
2. Reclamo de re-staker: Ahora utilizaremos [soETH]* para enfatizar la calidad especial de este reclamo, que es redimido por el re-staker solo después de que se resuelvan todos los reclamos de AVS. En otras palabras, el reclamo del re-staker tiene la menor antigüedad, redimiendo los activos restantes una vez que se resuelvan todos los demás reclamos de AVS.

1. El staker en solitario vuelve a apostar.
   1. soETH está bajo el control del EigenPod.
   2. [soETH]* es recibido por el solo re-staker, una reclamación por sus activos restakeados.
2. El staker en solitario acuña un nuevo reclamo, [soETH] de su EigenPod.
3. La reclamación se da como garantía al AVS.
   1. [soETH] se transfiere al AVS.
   2. Al re-staker se le da el recibo avs.[soETH].

Una vez que el validador actúa en contra de los objetivos del AVS (por ejemplo, desencadenando una condición de reducción de la AVS), el AVS puede decidir, por ejemplo, quemar la reclamación del validador por sus ETH en juego, o mantener la apuesta como ingreso para el AVS. Ilustramos esta segunda opción a continuación, asumiendo que el protocolo de Ethereum simplemente acredita 8 ETH al EigenPod como una retirada parcial después del informe de reducción de EigenLayer, después de lo cual EigenLayer lo transfiere al AVS:

1. El AVS reduce el colateral del re-staker en solitario.
   1. El colateral del AVS consiste en 32 [soETH]. Una vez que se informa el recorte, el AVS elimina 8 [soETH] del colateral y reporta el recorte al EigenPod, que también disminuye sus pasivos en 8 [soETH].
   2. El AVS ya no acredita 32 avs. [soETH] al solucionador en solitario, disminuyendo esta reclamación en 8 avs. [soETH].
   3. Habiendo sido reducido por el AVS, el EigenPod disminuye la reclamación del re-staker en solitario en 8 [soETH]*.
2. El EigenPod informa el corte al protocolo de Ethereum, desencadenando la retirada de 8 ETH.
   1. La reclamación de activos en juego en el protocolo Ethereum desciende a 24 soETH.
   2. Se procesa un retiro parcial de 8 ETH, y el EigenPod recibe los 8 ETH previamente bloqueados en el protocolo Ethereum.
3. El EigenPod reenvía la multa de 8 ETH al AVS, que es libre de disponer de ella como le plazca.

Re-re-re-re-…-staking

La característica (y riesgo) ofrecida por EigenLayer es la capacidad para que un re-staker siga ingresando nuevos compromisos que prometen respetar. En otras palabras, después de que la participación se vuelva a apostar, la participación re-apostada se puede volver a apostar, una y otra vez, y otra vez... Más prácticamente, el re-staker ingresa nuevos compromisos al inscribirse en más servicios a través de su EigenPod.

Para lograr la plena generalidad, y en previsión de las secciones siguientes en las que se vuelven a apostar activos distintos de soETH, denotamos por $X$ el activo que es vuelto a apostar por el que vuelve a apostar. Veamos cómo funciona la re-apostación múltiple:

Denotamos por [X]p el activo X reestacado p veces. Por ahora, esta es una definición simple, pero insinuaremos algunas de las propiedades de estos activos después de detallar los pasos de estos balances. El EigenPod puede imprimir estas responsabilidades a voluntad, forjando nuevos activos cada vez que el reestacador se compromete con nuevos AVSs.

1. El re-staker pone el activo X bajo el control del EigenPod. Este acto es un compromiso por parte del re-staker de que si no logran proporcionar los servicios para los que se inscriben, parte o la totalidad del activo X puede serles quitado. La reclamación [X]* se recibe para representar este compromiso.
2. Detallamos aquí el re-staker comprometido a asegurar la cadena Y.
   1. El re-staker obtiene un primer activo reestacado [X]¹ al entrar en la cadena de seguridad AVS Y.
   2. El re-staker apuesta [X]¹ en la cadena Y, recibiendo así [X]¹ (un reclamo por su apuesta + recompensas - penalizaciones). La cadena Y debe “entender” que un activo re-apostado actualmente asegura su protocolo, es decir, debe estar seguro de que hay algo en juego para alguien.
3. Detallamos aquí el re-staker comprometiéndose a asegurar la cadena Z.
   1. El re-staker obtiene un activo re-staked [X]² al ingresar en la cadena de seguridad AVS "Securing chain Z".
   2. El re-apostador apuesta [X]² en la cadena Z, recibiendo soZ.[X]² (una reclamación por su apuesta + recompensas - penalizaciones). La cadena Z debe “entender” que un activo re-apostado actualmente asegura su protocolo, es decir, debe estar seguro de que hay algo en juego para alguien.

Basándonos en los balances anteriores, ahora abordamos algunas preguntas. Observamos que la cadena Y recibe [X]¹, mientras que la cadena Z recibe [X]². ¿Son estos activos del mismo tipo, y podríamos decir simplemente que ambos reciben activos de tipo [X]?

La respuesta sería no si hubiera una jerarquía de reclamaciones de AVS. Imagina un escenario en el que el re-staker comete delitos punibles en ambas cadenas al mismo tiempo, y ambas cadenas desean confiscar el colateral completo. Entonces podemos pensar en dos casos:

1. Caso 1: Los AVSs, aquí las cadenas Y y Z de mecanismos de consenso, simplemente queman los tokens que se descuentan, que es lo que hacen la mayoría de los protocolos de PoS. Cuando los tokens se queman, entonces la jerarquía de reclamos no importa realmente: si ambas cadenas Y y Z quisieran descontar al restaker por 32 ETH, todo lo que logran es quemar el mismo colateral dos veces.
   1. Nota: Anders llama a esto "spree-staking", re-staking múltiples veces sin jerarquía de reclamo 😊
2. Caso 2: Los AVSs quieren recibir los tokens que están en juego, por ejemplo, para compensar a alguna parte que haya sido perjudicada. Un ejemplo aquí es MEV-Boost+, el operador AVS es el proponente del bloque, que se compromete a no perder el tiempo con el contenido del bloque recibido en el claro, y si lo hace, se compromete a compensar al constructor y al relé por el desorden. En este caso, supongamos que varios AVS redimen sus reclamaciones al mismo tiempo después de desviaciones paralelas por parte del mismo restaker, y no hay suficiente en juego para cubrir todas las reclamaciones. A continuación, cobra relevancia la cuestión de la antigüedad de la reclamación o de la distribución de los pagos.

Desagregando AVSs

En la sección anterior, hemos presentado AVSs, que son servicios que el validador de re-staking se compromete a proporcionar. El compromiso está asegurado a través de EigenLayer, que se hace cargo de la participación del re-staker validador y resuelve las reclamaciones hechas por AVSs.

Pero ¿qué es exactamente un AVS? Al igual que hemos separado anteriormente los protocolos LST y los operadores LST, tiene sentido discutir aquí estos dos roles funcionales por separado y asignarles diferentes activos y reclamaciones.

En resumen, el AVS exige garantías para ofrecer un servicio, por ejemplo, un AVS hace la afirmación creíble de que un ataque al AVS provocará la pérdida de una fracción de la garantía actualmente retenida por el AVS. El AVS se ve así como un protocolo que involucra a los operadores para un servicio. Luego desambiguamos dos formas en que los re-stakers pueden interactuar con el AVS:

1. Re-stakers como operadores de AVS: AVS encarna un protocolo que busca operadores para funcionar, y los operadores de nodos que vuelven a apostar su soETH se convierten en operadores del protocolo AVS ellos mismos.
2. Re-stakers como proveedores de capital para un operador de AVS: En este caso, un operador de AVS acepta activos (re) apostados para realizar su función de operador en nombre de los delegantes que proporcionan el capital. El re-staker luego delega sus activos apostados nuevamente al operador de AVS, quien realiza alguna función en nombre del re-staker.

En las secciones anteriores, hemos identificado al validador que vuelve a apostar como proveedor de capital (su propia apuesta se vuelve a apostar) y como operador de AVS (se espera que ellos mismos proporcionen algún servicio). Sin embargo, podemos considerar una construcción diferente, donde el validador que vuelve a apostar no opera el AVS ellos mismos, en su lugar delegando esta función a algún operador. Esto podría permitir a los apostadores en solitario competir en rendimiento con los Proveedores de Servicios de Staking Integrados (SSPs)/operadores. El siguiente ejemplo presenta una situación donde un único operador de AVS valida en algunas cadenas Y y Z, en nombre de un apostador que vuelve a apostar. Hacemos la suposición de que todas las reclamaciones de AVS son del mismo tipo X (sin jerarquía de reclamaciones).

1. El re-staker pone el activo X bajo el control del EigenPod. Este acto es un compromiso por parte del re-staker de que si no logran proporcionar los servicios por los que se inscriben, parte o la totalidad del activo X puede serles quitado. La reclamación [X]* se recibe para representar este compromiso.
2. Detallamos aquí el re-staker comprometiéndose a asegurar la cadena Y, delegando las funciones de validación al operador AVS.
   1. El re-staker obtiene un activo re-empatado [X] al entrar en la "Cadena de aseguramiento Y" de AVS.
   2. El re-apostador entrega el activo re-apostado [X] a un operador de AVS, obteniendo el “recibo” noY.[X].
   3. El operador de AVS apuesta [X] bajo la cadena Y, recibiendo así [X] (una reclamación por su apuesta + recompensas - penalizaciones). La cadena Y debe "entender" que un activo re-apostado asegura actualmente su protocolo, es decir, debe estar seguro de que hay algo en juego para alguien.
3. Aquí detallamos el re-staker comprometiéndose a asegurar la cadena Z, delegando las responsabilidades de validación al operador AVS.
   1. El re-staker obtiene un activo re-estacado [X] al ingresar en la AVS "Asegurando la cadena Y".
   2. El re-staker entrega el activo re-apostado [X] a un operador de AVS, obteniendo el “recibo” noZ.[X].
   3. El operador AVS apuesta [X] debajo de la cadena Z, recibiendo soZ. [X] (un reclamo por su apuesta + recompensas - penalizaciones). La cadena Z debe "entender" que un activo replanteado actualmente asegura su protocolo, es decir, debe estar seguro de que hay algo en juego para alguien.

En este paradigma, recuperamos construcciones familiares. Ningún activo es recibido por el re-staker, insinuando la posibilidad de licuar dichas posiciones. Discutiremos estas construcciones avanzadas en la próxima publicación, pero antes de hacerlo, mencionemos la investigación en curso sobre "PBS para AVS" como un enfoque para reducir la centralización del operador.

Bajo el Marco de Delegación Optimista (MDO)propuesto por Drew Van der Werff (ver tambiénLa charla reciente del taller de criptoeconomía de Columbia de 0xKydo) un re-staker puede contratar la operación de los AVSs a los que se registra en un mercado abierto de “coprocesadores”. Los coprocesadores pueden ser identificados con el papel de “constructor” de PBS, una entidad especializada capaz de ejecutar operaciones potencialmente intensivas, a las que no pueden acceder entidades poco sofisticadas o limitadas en computación como los stakers individuales. Los coprocesadores presentan ofertas a los re-stakers, en un mecanismo de subasta de adquisiciones, permitiendo al re-staker determinar el operador más rentable. Para garantizar aún más el rendimiento, los coprocesadores son participantes con bonos, exponiéndose a perder su bono si presentan una pieza de trabajo provablemente inválida durante el transcurso de sus operaciones.

Descargo de responsabilidad：

1. Este artículo ha sido reimpreso de [ espejo] Todos los derechos de autor pertenecen al autor original [el precio de la agencia]. If there are objections to this reprint, please contact the Gate Learnequipo, y lo resolverán rápidamente.
2. Renuncia de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.