Muchas gracias a Anders Elowsson por las discusiones iniciales que impulsaron esta serie de publicaciones y por sus comentarios útiles sobre el texto. Gracias también a Caspar Schwarz-Schilling, Julian Ma, Thomas Thiery, Davide Crapis, Mike Neuder, Drew Van der Werff, Kydo y muchos otros por las discusiones y comentarios sobre el texto. Foto de portada por @pawel_czerwinski?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Pawel Czerwinski on Unsplash.

Staking, re-staking, liquid staking, liquid re-staking, re-staked liquid staking tokens, node operators and capital providers… Hemos observado desde el lanzamiento de la Beacon Chain en diciembre de 2020 una colección cada vez más variada de mecanismos y construcciones, comenzando desde el mecanismo de staking propio del protocolo.

En las discusiones dentro de nuestro equipo, sentimos la necesidad de un lenguaje preciso que nos permita eliminar ambigüedades con respecto a la arquitectura de estos mecanismos. Esperamos enfatizar la existencia de puntos de control y desalineamientos de incentivos a través del uso de notación y balances, ya que los matices son muy importantes para resaltar adecuadamente las oportunidades y riesgos. El ejercicio se realizó principalmente para nuestro propio entendimiento, pero al hacerlo, sentimos que proporcionaba una forma útil de agregar una colección de hechos y discusiones dispares en un enfoque coherente y sistemático.

En esta publicación y las dos siguientes, presentamos estas construcciones junto con estudios de caso. No pretendemos hacer una revisión exhaustiva de todo el material producido por todos los brillantes equipos que trabajan en estos mecanismos, y pretendemos que nuestra semántica se actualice según sea necesario cada vez que nuevos hechos revelen lagunas o errores en nuestros modelos.

1. Parte 1: Licuefacción
2. Parte 2: Re-staking
3. Parte 3: Conjuntos de construcción avanzados para mayores de 16 años

La serie actual de publicaciones tampoco llega a conclusiones sobre la optimalidad o el uso de estas construcciones, más allá de proporcionar definiciones y contexto para su existencia. Las publicaciones futuras abordarán estas preguntas y ofrecerán propiedades de estos mecanismos, como su utilidad para varias clases de stakers y su economía en un contexto más amplio.

¡Entremos en ello!

Activo

El “tipo” más básico de nuestra semántica es el de un activo. Un activo puede ser tokens nativos de una cadena de bloques descentralizada, como ETH, tokens enraizados en alguna cadena de bloques como ERC-20 o NFT, o activos construidos a partir de otros activos, como los derivados lo son.

Balances

En lo siguiente, ilustramos nuestras construcciones con balances que muestran la creación y transferencia de activos entre múltiples partes involucradas. Siempre proporcionamos los balances en el mismo formato:

1. La primera fila representa el "estado previo", denotando qué activos son actualmente propiedad de cada parte.
2. La última fila representa el "estado posterior", que denota qué activos son propiedad de cada parte después de que todas las operaciones hayan concluido.
3. Las filas intermedias representan operaciones, con una nueva fila simplemente denotando un nuevo conjunto de operaciones, dividido de los demás con el propósito de exposición.

Utilizamos dos operaciones básicas repetidamente, que vale la pena detallar aquí:

1. Transferencia de activos: la Parte A simplemente transfiere algunos activos a la Parte B.

1. Acuñación de recibos: A menudo representamos situaciones en las que la Parte A recibe un reclamo de la Parte B, lo que permite a la Parte A canjear algunos activos de la Parte B. El recibo es entonces una responsabilidad para la Parte B y un activo para la Parte A. En el siguiente ejemplo, la Parte A transfiere un activo a la Parte B y recibe un reclamo de la Parte B.

No usamos hojas de balance de una manera muy ortodoxa, estamos más inspirados en el Economía del Dinero y la Bancacurso, así como el de Daniel H. NeilsonPronto Partidoboletín (mientras afirmamos en el registro que probablemente no somos tan rigurosos como cualquiera de ellos). Sin embargo, creemos que este conjunto mínimo de operaciones es suficiente para proporcionar la intuición necesaria.

Protocol Staking

Solo staker

La primera operación básica consiste en colocar ETH en juego en el protocolo de Prueba de Participación de Ethereum. En el caso más simple, un titular de ETH coloca su ETH directamente en el protocolo, recibiendo un saldo “virtual” de soETH (el “so” significa operador en solitario). Representamos la relación con los siguientes balances, que se leen línea por línea en los diferentes participantes:

El solo staker es responsable de las operaciones de su validador correspondiente. Esto significa que si el solo staker realiza adecuadamente sus deberes de consenso, el protocolo Ethereum acredita su saldo de soETH con soETH recién acuñado. Por el contrario, cuando el solo staker recibe penalizaciones o es reducido, el protocolo debita su saldo de soETH. Cuando el solo staker desea retirar su saldo de soETH y obtener ETH, el retiro se procesa en una relación de 1:1, es decir, por x unidades de soETH en el saldo de consenso del validador, el solo staker recibe x ETH a cambio (en el caso de un retiro completo).

Tenga en cuenta que no representamos las recompensas de la “capa de ejecución”, por ejemplo, las tarifas de prioridad y MEV. Estas recompensas son una adición directa al modelo presentado anteriormente y constituyen una simple transferencia de ETH de las partes en la capa de ejecución al solo validador que asume las funciones de productor de bloques.

Utilizando un Proveedor de Servicios de Staking (SSP)

Una relación más compleja está en juego cuando un Proveedor de Servicios de Staking (SSP) intermedia la relación entre el titular que desea hacer staking (”delegador”) y el protocolo Ethereum. En este caso, el titular de ETH primero proporciona al SSP ETH nativo con el propósito de que se haga staking. El SSP hace staking de ETH y obtiene el control sobre el activo “soETH” que se ejecuta en la capa de validación. Confiere un activo virtual noETH al delegador (el “no” significa operador de nodo), contra el cual su ETH en staking es canjeable.

Nuestro uso de la palabra 'redimible' ya introduce cierta incertidumbre aquí. Como hemos visto anteriormente, el protocolo de Ethereum permite al staker en solitario retirar su saldo de soETH contra ETH a la paridad. ¿Es esto también cierto para el staker que delega su ETH al SSP a cambio de noETH? En general, esto no es cierto. En primer lugar, 1 noETH podría redimir menos de 1 soETH, si se produjera un recorte. En segundo lugar, dado que la mayoría de los SSPs ofrecen su servicio a cambio de una tarifa, 1 noETH redime una fracción del soETH acreditado a la cuenta del SSP en exceso de su principal en juego. Un balance más preciso separaría el principal del rendimiento, por ejemplo:

A continuación, “desglosamos” el activo soETH entre el principal pETH y el rendimiento yETH. pETH se canjea como máximo por 32 ETH, a menos que se produzca un recorte. yETH canjea las recompensas de la capa de consenso y de ejecución obtenidas por el SSP. El SSP proporciona reclamaciones correspondientes al delegado, no.pETH y no.yETH. El delegado siempre puede recibir su principal completo, incluidos los recortes, de modo que exista un tipo de cambio de 1:1 entre no.pETH y pETH. Sin embargo, el SSP cobra una tarifa, por lo que el tipo de cambio entre no.yETH y yETH es inferior a 1 (1 no.yETH canjea menos de 1 yETH). El desglose del activo puede ser útil en algunos lugares, pero también introduce una complejidad adicional que no es crítica para las secciones siguientes, por lo que seguimos utilizando soETH y noETH para representar toda la reclamación.

Otro aspecto a considerar es si el SSP agrupa o no el ETH de sus depositantes.

1. Sin agrupación: Un SSP abre múltiples agrupaciones paralelas, una para cada depositante. Supongamos que los depositantes A y B proporcionan su ETH al SSP, que abre validadores A y B, uno para cada depositante. Supongamos entonces que el validador A es sancionado con la mitad de su depósito, mientras que el validador B no lo es. En este caso, el depositante A puede retirar su ETH en juego a una tasa de 1:0.5 (1 participación de noETH canjea 0.5 participaciones de ETH en juego), mientras que el depositante B puede retirar su ETH a una tasa de 1:1 (módulo comisiones). Entonces, es incorrecto hablar de un solo noETH, ya que en la práctica existen noETH-A y noETH-B que representan reclamaciones diferentes.
2. Pooling: El protocolo de Ethereum requiere unidades de 32 ETH para ser colocadas en staking, lo que significa que si los depositantes A y B desearan hacer staking solo de 16 ETH cada uno, no podrían hacerlo con la construcción detallada en el punto anterior. En este caso, agruparían sus ETH bajo algún SSP, quien luego socializaría sus recompensas y pérdidas, induciendo la misma tasa de retiro para ambos depositantes. Entonces, sería correcto hablar de un solo noETH, ya que el valor del reclamo es compartido por ambos depositantes, en proporción a la cantidad que depositaron.

Licuefacción

Nuestros depositantes ahora poseen un activo virtual que hemos llamado noETH. Este activo virtual es un reclamo que representa acciones del monto actual apostado por el SSP bajo el protocolo Ethereum. Aunque esto ya suena como una versión líquida de la posición ETH en juego, queremos enfatizar que se necesita un paso adicional para llegar allí: la liquidación a través de la emisión de un token que representa el reclamo de los activos noETH. La posición noETH se vuelve líquida, también conocida como fungible y transferible. Escribimos esta operación con el operando L., para que el activo L.noETH sea una abstracción, por ejemplo, stETH o cbETH, o cualquier otro activo conocido como un Token de Participación Líquida “LST”.

Para hacer esto evidente, desglosamos las funciones del SSP como la recopilación de la participación del protocolo de los delegados, y los operadores de nodos que proporcionan los servicios de validación para el SSP. Luego obtenemos los siguientes balances:

Cuando el SSP es simplemente un intermediario entre algunos operadores de nodos y el delegado, el paso de obtener L.noETH a partir de noETH es casi invisible dada la naturaleza de las cadenas de bloques, donde el activo contable noETH, escrito como una entrada de libro mayor, resulta ser el activo líquido L.noETH en sí mismo, programable y listo para ser compuesto. En otras palabras, si ya tenemos un token que representa cierto noETH como una entrada de cadena de bloques, noETH y L.noETH son indistinguibles. Sin embargo, queremos hacer hincapié en la diferencia, ya que existen casos en los que los delegados no tienen acceso a una representación líquida (desde el punto de vista de la cadena de bloques) de su activo en juego. Por ejemplo, en el pasado, los depositantes que apostaron su ETH con Coinbase no recibieron de Coinbase el activo líquido cbETH. En este caso, los depositantes tenían derecho a un reclamo virtual que representaba alguna línea en las entradas de libro mayor interno de la base de datos de Coinbase, que no estaban registradas en una cadena de bloques.

Roles of the SSP

En muchos casos, el SSP, visto como protocolo, no es simplemente un envoltorio, un contrato en cadena que recibe ETH e imprime L.noETH a cambio. La función principal del SSP es intermediar la relación entre un principal (el delegante) y agentes (operadores de nodos). Si el principal no confía en que los agentes le proporcionarán un rendimiento adecuado mientras protegen los activos del principal, el principal no delegará sus activos a los operadores de nodos para apostar en su nombre. ¿Cómo proporcionan los SSP buenas garantías?

1. El primer componente es incentivar un buen rendimiento para los operadores de nodos. Los operadores de nodos reciben más recompensas del protocolo Ethereum cuanto mejor desempeñen sus servicios de validación. Los incentivos se alinean fácilmente al permitir que los operadores de nodos compartan las ganancias que generan para sus delegados, a través de tarifas.
2. El segundo componente es desalentar a las partes malintencionadas de convertirse en operadores de nodos. Podríamos suponer que en el peor de los casos, estas partes malintencionadas están intrínsecamente motivadas para atacar el protocolo de Ethereum y causar un gran evento de reducción de costos mínimos para ellos mismos. Aquí existen dos enfoques. Podríamos requerir que los operadores pongan algo en juego, de manera que estos ataques sean lo más costosos posible para los operadores. También podríamos restringir a los operadores de nodos, impidiéndoles realizar unilateralmente acciones punibles.

Pools como Lido abordan el segundo problema al seleccionar un conjunto de operadores de nodos, de modo que el rendimiento esté garantizado por el protocolo y la DAO de Lido. Sus operadores no tienen ETH en juego, pero @mikeneuderlos sistemas externos de aplicación (desde los suaves como "reputación en juego" hasta los más duros como las retiradas desencadenadas por la capa de ejecución, como se discute en la segunda publicación) están destinados a garantizar su buen comportamiento.

Algo en juego para desalentar a los operadores maliciosos

Mientras tanto, construcciones como Rocket Pool incentivan la validación honesta por parte de los operadores de nodos que no están verificados ni empleados por alguna organización, contribuyendo sin permiso. El operador de nodos abre un Minipool, primero contribuyendo con su propia participación, ya sea 8 o 16 ETH. Luego, el protocolo completa la participación del operador del nodo con la participación recibida de los delegadores. Como corolario, el rendimiento del operador de Minipool en su propia participación aumenta con su desempeño.

Tenga en cuenta que el operador también debe garantizar una cierta cantidad de RPL, el token de Rocket Pool, proporcional a la cantidad de apuesta que tuvo que pedir prestada del grupo de ETH delegado para completar su propio Minipool. No mostramos esto en los siguientes balances, y destacamos algunos activos del mismo tipo con diferentes colores, para ilustrar su procedencia (ETH verde pertenece al delegante, ETH morado pertenece al operador).

Cuanto menor sea el colateral proporcionado por el operador, mayor será el riesgo de ataque apalancado, en donde el operador requiere una pequeña cantidad de fondos para controlar una cantidad mucho mayor de participación en la red de Prueba de Participación (PoS) de Ethereum. Para Lido, el riesgo de ataque apalancado es infinito considerando únicamente los activos en cadena puestos en juego por los operadores, pero obviamente menos que infinito considerando su reputación, contratos y flujos de efectivo futuros esperados de la validación honesta. Para los operadores de Rocket Pool, por ejemplo, aquellos que abren Minipools con colateral de 8 ETH, el factor de apalancamiento es de 4x, ya que 8 ETH les permite controlar 32 ETH de participación en el protocolo PoS de Ethereum. ¿Podemos requerir un colateral más bajo de los operadores?

Restringir a los operadores de nodos

Una forma de reducir aún más los riesgos de validación maliciosa es comprometer de manera creíble a los operadores de nodos a acciones específicas, por ejemplo, comprometerlos a nunca producir mensajes que puedan ser sancionados. ¡Más fácil decirlo que hacerlo!

Aquí, las tecnologías de validación distribuida (DVT) pueden ayudar, asegurando que todos los mensajes del operador sean verificados y firmados por un quórum de nodos antes de ser liberados en la red con una firma válida. Diva, un protocolo de staking, integra DVT para limitar las acciones de un operador. El operador debe apostar cierta cantidad de divETH (LST de Diva), equivalente a 1 ETH, para obtener una parte de la llave. Un conjunto de 16 partes de la llave forma un quórum de nodos DVT, así como un único validador virtual, como se muestra a continuación. Omitimos el protocolo de Ethereum, que simplemente emite la reclamación soETH en el último paso y recibe ETH recolectado de delegadores y operadores (el ETH verde pertenece al delegador, mientras que el ETH morado y amarillo son proporcionados por los operadores). También mostramos solo dos operadores en lugar de 16.

El cálculo del factor de apalancamiento para Diva no es tan sencillo. Contribuir con 1 ETH equivalente al validador virtual no le "otorga" el control de ninguna cantidad de ETH actualmente en juego, ya que las acciones conjuntas de más de 2/3 del quórum deciden los mensajes del validador virtual. Sin embargo, tenga en cuenta que el protocolo permite que el propietario de un solo ETH se convierta en operador y reciba un reclamo de noETH, canjeando el rendimiento obtenido de la validación de Ethereum PoS.

Además del factor de apalancamiento, otra métrica relevante aquí es la relación entre la cantidad de LSTs en circulación y la cantidad de stake del operador, o factor de garantía. Una relación alta implica que una menor cantidad de stake del operador se garantiza para validar en nombre de una mayor cantidad de stake delegado. Para Rocket Pool, los Minipools de 8 ETH tienen un factor de garantía igual a 3x, ya que 8 ETH garantizan 24 rETH en total. Mientras tanto, el factor de garantía de un validador virtual Diva es de 1x, ya que 16 partes clave (16 ETH) garantizan 16 divETH. Un alto factor de garantía 'abre espacio' para que se delegue más stake. Luego, Diva debe reclutar más stake del operador por unidad de stake delegado para ofrecer sus servicios. Por otro lado, permitir a los operadores que garanticen un solo ETH amplía el conjunto de operadores elegibles para aquellos con menos capital.

Validación en solitario de Liquid

Desde arriba, hemos aprendido que los titulares de un LST requieren que los operadores que validan en su nombre hagan un buen trabajo. Esta garantía la proporciona un contrato externo en el caso de los protocolos de tipo Lido, o haciendo que el operador ponga su propio capital en juego junto con el capital de sus delegados. Esto último requiere un modelo de juego teórico sólido para garantizar que el capital en juego por el operador no sea tan bajo como para permitir ataques baratos y, en última instancia, destruir el valor del LST para sus titulares.

Ahora hacemos una pregunta distinta. El delegante obtiene L.noETH al agrupar la participación y mediar las reclamaciones a través de un protocolo que emite una representación líquida de la cantidad delegada, módulo recompensas, penalizaciones y tarifas. ¿Puede un delegante obtener L.soETH? En otras palabras, ¿podría un solo validador emitir una posición líquida a partir de su posición de validación?

El problema aquí es que los titulares del activo L.soETH deben estar seguros de que el valor de su reclamo no será destruido por una acción maliciosa del validador en solitario, por ejemplo, ser penalizado. Ya hemos visto un enfoque, a través de DVTs, para restringir las acciones del operador durante la validación.

Un enfoque diferente para DVT consiste en vincular las acciones del staker en solitario de modo que su riesgo de penalización se reduzca mediante la construcción de hardware. Validación en solitario de Liquid” de Justin Drake emplea SGX para garantizar que la clave de firma del validador nunca firme un mensaje que pueda ser castigado. SGX permite que el software precomprometido se ejecute sin alteraciones, aunque existen las advertencias habituales sobre su seguridad, que están fuera del alcance de este artículo. El validador en solitario aporta todo el capital (32 ETH), pero puede acuñar un LST que represente su propia validación y “libere” su capital del protocolo de Ethereum, para que pueda ser utilizado nuevamente, por ejemplo, como garantía para otras aplicaciones.

Detalles línea por línea:

1. El dispositivo SGX genera una clave privada, una clave pública y una certificación que demuestra el compromiso con un fragmento de código que impide que el apostador individual realice acciones punibles con su clave de firma privada.
2. Las claves de certificación y públicas se proporcionan al staker en solitario.
3. El staker en solitario registra estos con el contrato LST desplegado en la cadena, que es responsable de acuñar el activo líquido de validación en solitario. El staker en solitario también proporciona al contrato ETH, su participación.
4. El ETH se transfiere del contrato LST al contrato de depósito, y un activo de staking soETH se devuelve al contrato LST, que ahora filtra la salida del validador del protocolo PoS. El contrato LST emite el activo L.soETH, que es una representación líquida del ETH en juego del staker.

El activo L.soETH es fungible con los emitidos por otros apostadores en solitario usando el mismo procedimiento. Por construcción, el apostador en solitario líquido solo puede emitir 31 L.soETH de sus 32 ETH en juego. El excedente de 1 ETH se utiliza como garantía para pagar a las partes que liquidan la posición sin permiso cuando el saldo del apostador en solitario cae por debajo de 32 ETH, y para contabilizar la garantía congelada mientras el validador está en la cola después de una salida. Esto garantiza que 1 L.soETH siempre esté respaldado por 1 ETH.

¿Cuáles son los usos del activo L.soETH?

1. El validador individual que emite L.soETH podría utilizar este activo L.soETH como garantía para otros servicios. Estos servicios podrían considerar que esta es una “buena garantía”, ya que la única forma de que el validador individual degrade su calidad es desconectarse y incurrir en penalizaciones (no deslizamiento). Sin embargo, por construcción, el validador individual sale en cuanto su saldo de soETH se desvía incluso en una centésima de un ETH del saldo inicial de 32 ETH.
2. El staker en solitario también podría vender el activo L.soETH a otros titulares, recibiendo las ganancias. El activo L.soETH tendría que ser un activo productivo en sí mismo, como lo describió Justin en el “sETH productivo vs no productivoen la sección de su publicación, donde el activo L.soETH se convierte en un reclamo no solo al principal en juego, sino también a las recompensas obtenidas en la participación, por ejemplo, recompensas de consenso y MEV (hay dificultades para internalizar el MEV de manera minimizada en confianza).
   1. Tenga en cuenta que vender el activo L.soETH no otorga al apostador en solitario un apalancamiento adicional para lanzar un ataque a Ethereum. El apalancamiento se obtiene poniendo una pequeña cantidad de fondos en juego y controlando una cantidad mayor en el protocolo de PoS. Sin embargo, el dispositivo SGX evita que el apostador realice acciones punibles.

Conclusión de licuefacción

La siguiente tabla resume los 4 estudios de caso discutidos anteriormente:

La licuefacción es una forma para que un staker extraiga “más jugo” de su garantía en juego. En la siguiente publicación, discutiremos el re-staking como una alternativa relacionada para crear más activos a partir de la apuesta de uno.

Descargo de responsabilidad:

1. Este artículo es reimpreso de [ espejo], Todos los derechos de autor pertenecen al autor original [El precio de la agencia]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente los 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.