EIP-7002: Una mejor forma de hacer staking en Ethereum

La transición de Ethereum de Proof of Work (Pow) a Proof of Stake (PoS), también conocida como The Merge, fue un momento clave en la historia de la red. Además de darle a Ethereum una renovación de marca muy necesaria al reducir su huella de carbono, Proof of Stake fue crucial para un objetivo clave a largo plazo: reducir la barrera para participar en el consenso de Ethereum. The Merge reemplazó los recursos computacionales (poder de minería) con capital financiero como base de la seguridad económica de Ethereum, abriendo la oportunidad para que cualquiera pueda ejecutar de manera rentable y sencilla un nodo validador al apostar 32 ETH en Beacon Chain.

Si bien la prueba de participación ha traído beneficios, todavía hay muchas áreas por mejorar. Algunas de ellas son:

• Reducción de la centralización de la participación y la cartelización de los validadores
• Minimizar los gastos operativos generales para los validadores e incentivar el staking individual
• Mejorar la economía del staking y la experiencia del usuario (UX)
• Mejorar la simplicidad, la seguridad y la descentralización de las operaciones de participación delegadas y multipartidistas

EIP-7002: Retiros activables en la capa de ejecución es una nueva propuesta de mejora de Ethereum (EIP) que soluciona algunos de los problemas antes mencionados. La EIP introduce un mecanismo para que los participantes retiren a los validadores de la Beacon Chain utilizando credenciales de retiro en lugar de depender de la clave de firma de un validador para activar las operaciones de retiro, lo que desvincula de manera efectiva la clave de firma de un validador de la clave de retiro.

Esta “separación de preocupaciones” entre las claves de firma del validador y las claves de retiro tiene un beneficio fundamental: reduce los supuestos de confianza en el staking delegado al permitir que las credenciales de retiro conserven el control del ETH en staking. Exploraré por qué esta característica es necesaria a lo largo de este artículo y analizaré otros beneficios de EIP-7002, especialmente para el staking en solitario y el staking con tecnología de validación distribuida (DVT). El artículo también considerará algunas posibles desventajas de implementar EIP-7002 en Ethereum.

¡Vamos a sumergirnos!

Preparando el escenario: Una historia de llaves, guantes blancos y duelo

Si desea hacer staking de ETH y validar la Beacon Chain hoy, tiene dos opciones principales: staking individual y staking delegado; existen otras vías para hacer staking de ETH, pero estas son más o menos retiradas en un espectro entre las opciones mencionadas anteriormente. El staking individual es sencillo:

• Deposite 32 ETH en el contrato de depósito de Beacon Chain para activar un nuevo validador
• Generar claves para realizar tareas de validación (verificar transacciones, certificar bloques, agregar certificaciones y proponer bloques)
• Configurar un nodo validador y sincronizar un cliente de capa de ejecución (EL) y capa de consenso (CL)
• Mantenga su validador en línea y funcionando correctamente para evitar sanciones

Hay más pasos (las preguntas frecuentes sobre validadores de Staking Launchpad tienen una excelente descripción general para los posibles validadores), pero estos son, en líneas generales, los aspectos más importantes del lanzamiento de un validador. Es importante destacar que el staking en solitario no requiere intermediarios ni contrapartes y le permite conservar el 100 % de las recompensas recibidas por la validación (certificación de bloques y propuesta de bloques) en Beacon Chain. Pero no es gratis: usted tiene la responsabilidad de administrar su validador y necesitará cierto nivel de experiencia técnica para ejecutar una operación de staking en solitario.

Si la idea de gestionar un validador te parece difícil, puedes optar por la vía del staking delegado. Sigues siendo responsable de proporcionar 32 ETH para registrar un nuevo validador, solo que ahora delegas la responsabilidad de operar el validador a un tercero. El operador del nodo validador proporciona lo que algunos describirían como un "servicio de guante blanco" y exige una compensación por este servicio. Por ejemplo, es posible que se te pida que compartas una parte de las recompensas de tu validador con el operador del nodo como parte del acuerdo inicial.

La parte de "guante blanco" significa que el operador asume la responsabilidad de mantener su validador operativo y seguro, lo que significa que puede hacer cosas como transmitir Netflix un viernes por la noche (o lo que sea que haga en su tiempo libre) sin preocuparse por sanciones por no cumplir con las tareas del validador o preocuparse por la seguridad de sus claves de validación.

Sin embargo, hay una salvedad: el staking delegado requiere confiar en el operador del nodo para evitar poner en riesgo sus 32 ETH al cometer una infracción susceptible de ser recortada (por ejemplo, firmar dos bloques en conflicto) o directamente robar sus fondos. Es mucho pedir (y definitivamente no es para personas con problemas de confianza), pero el acuerdo funciona bien la mayoría de las veces cuando los operadores de nodos son honestos.

Pero Ethereum no se construyó sobre la base del lema de la Web2 "confía en mí, hermano", por lo que es frecuente ver expresiones como "sin confianza" y "sin confianza" en conversaciones en Twitter y Reddit sobre criptomonedas. El staking delegado en su forma más pura entra en conflicto con este lema, pero hay una solución alternativa en la forma en que se generan los pares de claves durante el proceso de activación de un nuevo validador.

Cada validador tiene dos claves: una clave de retiro y una clave de validador. La clave de retiro es un par de claves pública y privada que se requiere para retirar parcial o totalmente el saldo de un validador de Beacon Chain, dependiendo de si desea "extraer" (retirar solo las recompensas) o "salir" (retirar el saldo de 32 ETH más las recompensas). Tenga en cuenta que la clave de retiro debe actualizarse de las credenciales BLS predeterminadas ( 0x00 ) a las credenciales 0x01 que apuntan a una dirección Ethereum para permitir el retiro parcial o total del saldo de un validador.

La clave de retiro se genera en el momento del depósito a través de una interfaz como Staking Launchpad y se codifica para crear un ID de retiro que se incluye en los datos de depósito del validador, lo que proporciona a Beacon Chain información sobre quién depositó los 32 ETH. La siguiente infografía de Protecting Withdrawal Keys de Attestant ofrece una excelente descripción general de cómo se integra la clave de retiro en el proceso de solicitud de depósito del validador:

La clave del validador es un par de claves pública y privada que se requiere para ejecutar las tareas que se esperan de cada validador de Ethereum, principalmente votar por bloques y proponer bloques para que otros voten (“votar” y “certificar” se usan indistintamente, pero se refieren al mismo concepto de verificar transacciones y confirmar la validez de los bloques). La clave pública del validador sirve como su identidad criptográfica única en el protocolo de consenso de Ethereum, mientras que se espera que la clave privada esté oculta y se use para firmar datos de bloques (las claves del validador también se describen como claves de firma por este motivo).

Ahora, la diferencia principal entre las claves de validación (firma) y las claves de retiro:

La clave de firma de un validador se utiliza con frecuencia (piense en cada 6,5 minutos o en la duración de un intervalo durante el cual se seleccionará a cada validador para certificar o proponer un bloque) y es mejor guardarla en una ubicación en línea de fácil acceso, como una billetera activa. Sin embargo, una clave de retiro se utiliza con menos frecuencia y se puede guardar en una ubicación segura y fuera de línea, como una billetera fría, hasta que un participante desee retirar fondos de la dirección de retiro asociada con un validador en particular.

Esta distinción es crucial para reducir los supuestos de confianza en una configuración de staking delegado: como la clave de retiro no es necesaria para las tareas de validación, un staker puede conservar el control del ETH en staking compartiendo la clave del validador con el operador del nodo y conservando la clave de retiro. De esa manera, un operador deshonesto no puede huir con los fondos de un staker después de retirar el saldo de un validador sin la aprobación de este.

Los acuerdos de participación delegada, en los que el staker posee la clave de retiro, se describen típicamente como "sin custodia" para reflejar que la entidad que opera el nodo validador en nombre del staker en última instancia no tiene control sobre el ETH en stake. Esto contrasta con las soluciones de participación con custodia en las que el servicio de participación controla tanto las claves de firma como las de retiro; el "servicio de guante blanco con esteroides" es un buen modelo mental para la participación con custodia: un staker simplemente proporciona 32 ETH para financiar al validador y delega todo lo demás (incluido el inicio de solicitudes de depósito del validador y el almacenamiento de claves de retiro) al servicio de participación.

En teoría, separar las claves de firma del validador de las claves de retiro resuelve el problema de la confianza en los acuerdos de participación delegada. En la práctica, la relación entre el operador del nodo y el participante en una configuración de participación sin custodia aún tiene un elemento de confianza debido al mecanismo actual para retirar un validador y desencadenar un retiro total o parcial del saldo del validador a la dirección de retiro.

Para retirar un validador de la Beacon Chain, se debe enviar un “Mensaje de salida voluntaria” (VEM) firmado con la clave del validador para su procesamiento en la capa de consenso. Una vez incluido en un bloque (cada bloque puede incluir un máximo de 16 operaciones de solicitud de retiro), el mensaje de retiro se agrega a la cola de solicitudes de retiro ; la demora en el retiro final se ve influenciada por factores como la cantidad de retiros en cola o la tasa de abandono del validador.

Subrayé el requisito de firmar una solicitud de retiro voluntario con la clave de firma del validador para destacar un problema con las soluciones de staking “sin custodia” existentes: un staker debe confiar en el operador del nodo (que controla la clave del validador necesaria para firmar un VEM) para procesar las solicitudes de retiro. Esto reintroduce efectivamente la confianza en la relación entre los operadores de nodos y los servicios de staking; peor aún, pone a los stakers en riesgo de ser “agraviados” por operadores de nodos maliciosos.

En un ataque de duelo , el objetivo del atacante es causar pérdidas a la otra parte, no necesariamente beneficiarse directamente. Para poner esto en contexto, considere el escenario en el que Alice delega a Bob para operar un validador en su nombre, pero decide retirar sus 32 ETH más tarde. Bob podría cumplir con la solicitud de Alice y activar una solicitud de retiro firmando un Mensaje de Salida Voluntaria (VEM)... o negarse a firmar el mensaje de solicitud de retiro y detener la operación de retiro de Alice. Bob no se beneficiará directamente al rechazar la solicitud de Alice; todo lo que puede hacer es mantener el ETH de Alice como "rehén" al negarse a ayudar a Alice a retirar su validador.

Vale, eso no es 100% exacto; Bob puede hacer muchas cosas malas para causarle a Alice aún más “dolor”:

1. Reducir el saldo del validador de Alice cometiendo deliberadamente una infracción que pueda ser objeto de reducción o incurriendo en sanciones. La sanción individual por no cumplir con las obligaciones del validador (por ejemplo, no realizar las certificaciones) o por cometer una infracción que pueda ser objeto de reducción (por ejemplo, firmar dos bloques en conflicto en la misma ranura) suele ser baja, pero aumenta en proporción a la cantidad de validadores que cometen infracciones similares en el mismo período. Por ejemplo, no realizar una o dos certificaciones reducirá el saldo de un validador en una pequeña fracción, pero esa reducción aumenta exponencialmente si se produce una fuga de inactividad (en la que varios validadores están desconectados).

   
   

Con el mecanismo actual, un Bob malintencionado puede reducir el saldo del validador de Alice de 32 ETH hasta en un 50 por ciento incurriendo en penalizaciones y recortes hasta que el validador sea retirado por la fuerza del consenso de Beacon Chain (después de que su saldo efectivo caiga a 16 ETH). Si usamos 1 ETH = $2000, el ataque de duelo de Bob le costará a Alice al menos $32 000 (16 ETH) en un caso normal (sin penalizaciones correlacionadas) y $64 000 (32 ETH) en el peor de los casos (es decir, donde todo el saldo puede ser recortado debido a penalizaciones por correlación).

Quien puede destruir algo, controla algo. — Paul Atreides (Dune)

1. Exigir un rescate a Alice a cambio de no cometer un delito que pueda ser objeto de corte. Esto no coincide exactamente con la definición anterior de "dificultad", pero hay que tener en cuenta que el único recurso de Bob es quemar ETH si Alice decide jugar duro. Por lo tanto, la situación es diferente de los tipos de ataque más comunes, en los que el objetivo es (siempre) obtener beneficios con una pérdida mínima.

Nota: Bob (el operador del nodo) puede ser honesto en este escenario, pero un adversario podría comprometer la clave del validador y tomar como rehén el ETH de Alice. Esto explica el “riesgo de contraparte” que deben asumir los usuarios de una plataforma de staking como servicio (SaaS) y es otra razón por la que el staking en solitario, con su filosofía de “no confiar en nadie más que en uno mismo”, se considera el estándar de oro para los stakers de Ethereum.

¿Significa esto que todos los servicios de staking sin custodia en realidad no son sin custodia? No exactamente. Una solución sencilla es que el servicio de staking firme un mensaje de solicitud de retiro voluntario por adelantado (preferiblemente una vez que el validador se activa en Beacon Chain) que el staker puede enviar de forma independiente a un nodo de consenso de Ethereum cuando desee retirar.

Al firmar con antelación las solicitudes de retiro voluntario de un staker, el acuerdo entre un staker y un operador de nodo vuelve al estado original de no custodia. Sin embargo, los mensajes de solicitud de retiro firmados con antelación no son sostenibles por muchas razones:

Problemas con solicitudes de retiro firmadas previamente para staking sin custodia

Complejidad

Los flujos de trabajo de solicitudes de retiro firmadas previamente requieren más comunicación entre el operador del servicio de staking y el delegador de staking: debe enviar una solicitud de un mensaje de solicitud de retiro y esperar a que el servicio de staking envíe las solicitudes de retiro firmadas. También existe el problema de la seguridad al usar e intercambiar solicitudes de retiro firmadas previamente:

• Un servicio de staking debe tomar precauciones adicionales (como cifrar el mensaje de solicitud de retiro y compartirlo a través de un canal de comunicación seguro (fuera de la cadena)) para evitar que los mensajes de solicitud de retiro caigan en manos equivocadas.
• Un participante debe tomar precauciones adicionales para almacenar el mensaje de solicitud de retiro en una ubicación segura, ya que perder el mensaje de solicitud de retiro equivale a perder potencialmente la capacidad de retirar de forma independiente el saldo del validador.

Además, las solicitudes de retiro firmadas previamente actualmente son válidas para dos bifurcaciones de Ethereum o aproximadamente 12 meses, si espera que las bifurcaciones ocurran aproximadamente cada seis meses. Esto significa que un staker tiene que volver a enviar una solicitud de retiro voluntario al operador del servicio de staking varias veces en un año calendario. Sin embargo, esto ya no será así cuando se implemente EIP-7044 y las solicitudes de retiro firmadas por el validador sean válidas indefinidamente.

La EIP-7044 corrige el problema de los mensajes de salida que expiran, pero introduce un nuevo conjunto de problemas, en particular para los grandes pools de staking. Como antecedente, el enfoque actual en los pools de staking descentralizados es exigir a los nuevos operadores de nodos validadores que envíen solicitudes de retiro previamente firmadas antes de recibir fondos del pool. En este caso, las solicitudes de retiro firmadas brindan seguridad criptoeconómica, ya que reducen el poder que tiene un operador (no confiable) sobre los fondos del validador; un pool de staking puede activar la solicitud de retiro de un operador de nodo validador que no coopera al enviar la solicitud de retiro previamente firmada en la cadena.

Pero un operador de nodo validador no se sentirá exactamente cómodo si las solicitudes de retiro firmadas previamente se almacenan en un servidor aleatorio debido al riesgo de que alguien active accidentalmente/deliberadamente una solicitud de retiro falsa al obtener el mensaje de salida firmado. En el peor de los casos, las salidas forzadas probablemente resultarían en una pérdida para un operador de nodo validador (por ejemplo, si solicitó un préstamo contra futuras recompensas de Beacon Chain). Esto significa que los grupos de staking deben tomar aún más precauciones de seguridad y almacenar los mensajes de solicitud de retiro de forma segura, especialmente en un mundo posterior a EIP 7044 donde las solicitudes de retiro firmadas tienen fechas de vencimiento infinitas.

Una posible solución es cifrar las solicitudes de retiro firmadas con una clave pública compartida generada a través de un protocolo DKG (Generación de clave distribuida) y requerir un quórum de claves compartidas para reconstruir la clave privada antes de que se pueda descifrar la solicitud de retiro. Esto reduce la suposición de confianza que implica que una de las partes almacene las solicitudes de retiro, siempre que nadie controle suficientes claves compartidas para descifrar unilateralmente las solicitudes de retiro firmadas previamente sin la participación de otros participantes. Pero aparece un caso extremo si una o más claves compartidas privadas se extravían, se pierden o se roban, lo que hace que sea difícil o directamente imposible descifrar la solicitud de retiro firmada si se hace necesario activar la retirada de un validador.

Cumplimiento normativo

Los servicios de staking han sido objeto de un intenso escrutinio por parte de una gran variedad de reguladores, en particular la SEC (Comisión de Bolsa y Valores), liderada por el enemigo público número uno de las criptomonedas: Gary Gensler. Por ejemplo, Kraken cerró su operación de staking como servicio de custodia a principios de este año y pagó 30 millones de dólares en multas por "ofrecer valores no registrados a través de su plataforma de staking de criptomonedas".

En teoría, es poco probable que un servicio de staking sin custodia quede en la mira de la SEC debido a la naturaleza no custodial de su acuerdo con el propietario de la participación:

1. El depósito de 32 ETH (o múltiplos de 32 ETH) para activar un validador proviene de una dirección de retiro controlada por el staker, y el protocolo identifica la dirección de retiro como la propietaria del depósito de 32 ETH. Esto significa que un servicio de staking sin custodia no puede retirar el saldo del validador y “mezclar el dinero de los clientes con el suyo”, como la SEC acusó a Kraken de hacer.

En un exchange como Kraken, el saldo de la billetera de un usuario es "virtual", ya que todos los fondos del cliente se guardan en una o más billeteras controladas por el exchange. Entonces, si haces staking de 32 ETH a través de un servicio de staking de custodia administrado por un exchange, lo que realmente tienes es un pagaré del exchange que promete devolver 32 ETH (más un porcentaje de las recompensas del validador) cuando desees retirarlos.

1. Los participantes pueden retirar fondos de forma independiente enviando solicitudes de salida previamente firmadas sin correr el riesgo de que un servicio de staking fraudulento impida los retiros. Por el contrario, un servicio de staking de custodia (especialmente un exchange como Kraken) tiene el control de los activos de un participante y puede bloquear los retiros por razones arbitrarias.

Estos dos hechos eliminan la necesidad de “protección del inversor”; no soy un experto en políticas, así que disculpen cualquier error en esta línea de razonamiento. Pero aún puede haber un pequeño inconveniente o dos si actualmente está ejecutando un servicio de staking institucional, sin custodia:

• Durante el breve (o probablemente largo) período que transcurre entre la activación de un validador y el envío de una salida voluntaria firmada previamente al staker, el servicio de staking controla los 32 ETH, lo que los convierte en “custodios” a los ojos de un regulador. Para agravar aún más el problema, se encuentran las breves fechas de vencimiento de las salidas firmadas previamente (pre-EIP 7044): entre el momento en que se firma un nuevo mensaje de salida y se envía al staker, el operador del nodo validador tiene cierto control sobre los ETH en staking.
• Si bien los mensajes de salida regulares se transmiten en cadena y se pueden verificar públicamente, una salida firmada previamente debe cifrarse y compartirse fuera de la cadena de forma privada entre el operador del nodo y el staker. Esto hace que sea más difícil para un tercero, como un regulador, verificar que el servicio de staking realmente firmó una intención de salida como parte del acuerdo de depósito inicial del validador, o si el intercambio se repitió una vez que expiró el mensaje de salida original (es decir, antes de EIP 7004).

En resumen: las salidas prefirmadas alivian algunos problemas con el staking delegado, pero no son suficientes para que el staking en Ethereum sea confiable, seguro y descentralizado. Para devolver la “no custodia” al staking sin custodia, necesitamos una mejor solución, que ahora tenemos gracias a EIP-7002. Las secciones posteriores cubrirán EIP-7002 en detalle y abordarán las diversas ventajas de EIP, así como los posibles problemas asociados con su implementación.

Descripción general de EIP-7002: Retiros activables en la capa de ejecución

La EIP-7002 soluciona el problema de agente-principal en el staking delegado (donde los stakers deben confiar en los operadores de nodos validadores para firmar previamente las solicitudes de retiro o cumplir con las solicitudes de retiro futuras) al introducir una nueva operación de retiro voluntario que se puede activar con las credenciales de retiro de un validador. Esto permite a los stakers retirar ETH en staking sin depender de la entidad que posee la clave de firma del validador (es decir, el servicio de staking en una configuración de staking delegado) para procesar los retiros.

La característica principal de EIP-7002 es la introducción de un contrato de solicitud de retiro de validador con estado que mantiene una cola de solicitudes de retiro de validador que se originan en la capa de ejecución. A intervalos, se eliminan de la cola una cantidad de solicitudes de retiro y se agregan a la solicitud de ejecución de un bloque de Beacon Chain. Esto permite que las solicitudes de retiro de la capa de ejecución se "inyecten" en la capa de consenso y se procesen como parte de las operaciones de Beacon Chain, de manera similar a cómo los depósitos que se originan en el contrato de depósito se pasan de la capa de ejecución a la capa de consenso para su procesamiento.

Las solicitudes de retiro son transacciones regulares de Ethereum con la dirección del contrato del validador como destino e indican la intención de retirar un validador (identificado por su clave pública). Un mensaje de retiro del validador es válido si (a) está firmado por la dirección de Ethereum a la que se hace referencia en la credencial de retiro de la capa de ejecución del validador ( 0x01 ) (b) el validador que se retirará está activo en Beacon Chain. Estas comprobaciones son ejecutadas por la capa de consenso después de que la solicitud de retiro llega a Beacon Chain; el contrato de solicitud de retiro del validador solo confirma si una transacción de solicitud de retiro paga suficiente gas en el momento en que un staker llama al contrato de solicitud de retiro.

Todas las solicitudes de retiro de la capa de ejecución se procesan de la misma manera que una operación de solicitud de retiro voluntario regular activada desde la capa de consenso, que conserva invariantes en torno a las solicitudes de retiro máximas permitidas de los retiros de validadores activos. El mecanismo dentro del protocolo de EIP-7002 para transferir solicitudes de retiro entre las capas de ejecución y consenso también elimina la necesidad de conexiones a un nodo de consenso para activar solicitudes de retiro (lo que es necesario para retirar validadores con solicitudes de retiro firmadas previamente). Los validadores ahora pueden recibir fondos y retirarse desde la misma dirección de la capa de ejecución, lo que explica el nombre de la EIP como "Retiros activables de la capa de ejecución".

Después de haber visto cómo funciona EIP-7002 a un alto nivel, ahora podemos profundizar en los detalles más finos de EIP. La siguiente sección cubrirá la especificación actual de EIP-7002 y analizará los aspectos clave del mecanismo de solicitud de retiro del validador. Si prefiere omitir la discusión técnica y explorar las ventajas de implementar EIP-7002, puede pasar a la siguiente sección, que destaca algunas de las mejoras en la experiencia del usuario (UX) de staking que permite EIP-7002.

Operaciones de solicitud de retiro del validador

Según EIP-7002, una solicitud de retiro del validador (definida en pseudocódigo como add_withdrawal_request() ) es una CALL a la dirección del contrato de solicitud de retiro del validador. El campo de transacción para las llamadas al contrato de solicitud de retiro del validador tiene dos valores:

• source_address : un valor de 20 bytes que representa la dirección de retiro que inició la transacción
• validator_pubkey : un valor de 48 bytes que representa la clave pública del validador del que se saldrá

Después de que un staker llama al contrato de solicitud de retiro con validator_pubkey como entrada, el contrato de solicitud de retiro del validador ejecuta las siguientes operaciones (revisaré las partes clave de esta operación más adelante):

• Confirma que la transacción paga suficiente gas para cubrir EXIT_FEE
• Aumenta el contador de salida ( EXIT_COUNT ) en uno para el bloque actual
• Inserta el mensaje de salida en la cola.
• Aumenta los retiros excedentes para el bloque actual ( EXCESS_EXITS ) en uno
• Reembolsa a la persona que llama (si pagó de más por gasolina) enviándole un estipendio de 2300 dólares por gasolina ( EXCESS_RETURN_GAS_STIPEND )

Un detalle importante: el contrato de solicitud de retiro del validador no verifica si source_address es una dirección de retiro válida para el validador identificado por validator_pubkey , ni tampoco verifica si validator_pubkey . Esto expone un sutil problema de seguridad que puede surgir si un atacante llena la cola con mensajes que están condenados a fallar; esto es principalmente un ataque de duelo con el objetivo de evitar el procesamiento de solicitudes de retiro legítimas. EIP-7002 aborda este problema cobrando una tarifa que se ajusta dinámicamente en las transacciones de solicitud de retiro (el mecanismo de tarifa de retiro se analiza más adelante).

Retiros máximos y objetivos por bloque

MÁXIMO DE SOLICITUDES DE RETIRO POR BLOQUE

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK es la cantidad de solicitudes de retiro de la capa de ejecución que se pueden incluir en un bloque de Beacon Chain. Este valor está establecido actualmente en 16 para reflejar operaciones similares en Beacon Chain, como VoluntaryExit (operaciones de salida activadas directamente desde la capa de consenso con la clave de validación de un staker).

La especificación también señala que establecer MAX_WITHDRAWAL_REQUESTS_PER_BLOCK en 16 limita el tamaño de las cargas útiles de ejecución (y, por extensión, el tamaño de los bloques de Beacon Chain) y reduce la sobrecarga de procesamiento de las operaciones de salida en la capa de consenso. Esto es útil ya que podemos esperar que algunos participantes sigan saliendo de los validadores utilizando el mecanismo actual de activación de salidas desde la capa de consenso (es decir, a través de salidas prefirmadas o mensajes de salida voluntaria en tiempo real).

SOLICITUDES DE RETIRO DE OBJETIVO POR BLOQUE

En teoría, la EIP-7002 permite incluir hasta 16 operaciones de salida de la capa de ejecución en un bloque, pero apunta a una estimación más conservadora de dos salidas por bloque. Según la especificación , TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK se ha establecido en 2 para limitar la tasa de abandono de los validadores y preservar la invariancia de los retiros máximos permitidos por época definidos por la función get_validator_churn_limit() de Beacon Chain, incluso en situaciones en las que todo el ETH en circulación está en staking.

Cola de solicitudes de retiro del validador

CONTADOR_DE_SOLICITUDES_DE_RETIRADA

WITHDRAWAL_REQUEST_COUNT es la cantidad de solicitudes de retiro incluidas en el bloque actual. Después de cada llamada exitosa al contrato de solicitud de retiro del validador, el valor de la variable WITHDRAWAL_REQUEST_COUNT almacenada en el almacenamiento del contrato del validador se incrementa en uno (definido en pseudocódigo como increment_count() ).

En cualquier momento, el valor de WITHDRAWAL_REQUEST_COUNT estará entre TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK (2) y MAX_WITHDRAWAL_REQUESTS_PER_BLOCK (16) dependiendo de cuántas operaciones de solicitud de retiro se agreguen a la carga útil de ejecución del bloque. WITHDRAWAL_REQUEST_COUNT también es una entrada para la función que calcula el monto a pagar por una nueva operación de solicitud de retiro ( MIN_WITHDRAWAL_REQUEST_FEE ).

SOLICITUDES DE RETIRO EN EXCESO

EXCESS_WITHDRAWAL_REQUESTS es la diferencia entre MAX_WITHDRAWAL_REQUESTS_PER_BLOCK y TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK : la cantidad de solicitudes de retiro que quedan sin usar en el bloque actual. Como se mencionó, cada bloque puede incluir un máximo de 16 solicitudes de retiro, pero en situaciones normales puede incluir dos solicitudes de retiro, por lo que EXCESS_WITHDRAWAL_REQUESTS es equivalente a “la diferencia entre la cantidad de solicitudes de retiro que un bloque puede consumir teóricamente y la cantidad de solicitudes de retiro que realmente utiliza”.

El contador de excedentes del contrato de solicitud de retiro se actualiza en función del uso del último bloque y es un factor (entre otros) que determina la tarifa que paga una transacción que llama al contrato de solicitud de retiro del validador. Esto garantiza que las tarifas de retiro tengan un precio de acuerdo con el uso actual, lo que es similar a EIP-1559 , que calcula la base_fee para un nuevo bloque en función de la diferencia entre el límite de gas objetivo y el gas utilizado por el bloque anterior.

COLA DE SOLICITUDES DE RETIRO

WITHDRAWAL_REQUEST_QUEUE es una lista de todas las solicitudes de retiro pendientes (ordenadas en orden de llegada) almacenadas actualmente en el WITHDRAWAL_REQUEST_QUEUE_STORAGE_SLOT del contrato del validador (como WITHDRAWAL_REQUEST_QUEUE_HEAD_STORAGE_SLOT y WITHDRAWAL_REQUEST_QUEUE_TAIL_STORAGE_SLOT ). La cantidad de solicitudes de retiro en la cola puede ser ilimitada, pero la variable MAX_WITHDRAWAL_REQUESTS_PER_BLOCK limita la cantidad de solicitudes de retiro pendientes que se pueden sacar de la cola en cada bloque.

La cola de solicitudes de retiro mantiene un índice de “cabeza” y otro de “cola” (ambos simplemente hacen referencia al conjunto de solicitudes cerca del inicio y el final de la cola) que se actualiza después de cada bloque para dar cuenta del procesamiento de una o más solicitudes de retiro. Esta es una cola FIFO (primero en entrar, primero en salir), por lo que las solicitudes se ejecutan según el momento en que se agregan a la cola, lo que tiene implicaciones de seguridad, especialmente en lo que respecta a la violación de validadores honestos.

Tarifas del contrato de retiro del validador

MIN_WITHDRAWAL_REQUEST_FEE es el monto que una dirección que llama al contrato de solicitud de retiro del validador para retirar un validador debe pagar en gas. Antes de insertar una solicitud de retiro en la cola, el contrato de solicitud de retiro del validador verifica que la tarifa de gas asociada a la transacción sea igual o superior al valor actual de MIN_WITHDRAWAL_REQUEST_FEE . Si la transacción tiene gas sobrante después de ejecutarse correctamente, se acreditan exactamente 2300 gas a la dirección de envío.

Según la especificación, este diseño sigue la característica ahora obsoleta de Solidity, donde invocar la función fallback() en un contrato de destino o enviar ETH a través de transfer() o send() reenvía un estipendio de 2300 gas al destinatario. Los cambios en los costos del gas (comenzando con la bifurcación de Berlín/Estambul) han reducido la utilidad de esta característica (lea Deje de usar transfer() de Solidity ahora para obtener algo de contexto), pero la idea original de un sistema de contabilidad de gas simple sigue siendo útil. En el contexto de EIP-7002, enviar un reembolso fijo de 2300 gas simplifica el mecanismo de tarifa para el contrato de solicitud de retiro del validador.

La alternativa es diseñar un mecanismo especial que permita que el contrato de solicitud de retiro devuelva la cantidad máxima de gas restante de una transacción. Esto tendría sentido, especialmente en los casos en que la dirección de retiro es un contrato inteligente EOA: los contratos inteligentes pueden calcular valores precisos para MIN_WITHDRAWAL_REQUEST_FEE al verificar el estado del contrato, pero es probable que los EOA envíen más gas por cada llamada al contrato de solicitud de retiro. Esta ruta agrega más complejidad al diseño de EIP-7002 en comparación con el uso de una simple CALL para reenviar una cantidad fija de gas como reembolso; aunque los autores de EIP-7002 sugieren que esta característica puede incluirse en la especificación final dependiendo de los comentarios de las partes interesadas.

El cálculo de MIN_WITHDRAWAL_REQUEST_FEE es donde las cosas se ponen interesantes. La tarifa de solicitud de retiro es dinámica y está diseñada para responder a las condiciones de la red, similar a la tarifa base introducida por EIP-1559, y es una función de tres variables:

• La tarifa mínima (base) de retiro: MIN_WITHDRAWAL_REQUEST_FEE
• Número de retiros excedentes en el bloque actual: EXCESS_WITHDRAWAL_REQUESTS
• Fórmula de actualización de la tarifa de solicitud de retiro: WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION

Al igual que base_fee de EIP-1559, la tarifa de salida del contrato de retiro del validador es un mecanismo de limitación de velocidad: en el caso promedio (dos solicitudes por bloque), cualquiera que llame al contrato de solicitud de retiro del validador puede esperar pagar la tarifa de retiro mínima, pero el costo de una operación de retiro aumenta progresivamente a medida que se incluyen más solicitudes de retiro en un bloque. Esto se puede deducir de la especificación formal de EIP-7002 para actualizar la tarifa de solicitud de retiro : withdrawal_request_fee = MIN_WITHDRAWAL_REQUEST_FEE * e**(excess_withdrawal_requests / WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION) .

Una explicación del mecanismo de tarifa de solicitud de retiro de la especificación:

“El comportamiento bloque por bloque es aproximadamente el siguiente: si el bloque N procesa X solicitudes de retiro, entonces al final del bloque N excess_withdrawal_requests aumenta en X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK , y por lo tanto la tarifa de solicitud de retiro en el bloque N + 1 aumenta en un factor de e**((X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK) / (WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION) . Por lo tanto, tiene un efecto similar al EIP-1559 existente, pero es más “estable” en el sentido de que responde de la misma manera a las mismas solicitudes de retiro totales independientemente de cómo se distribuyan a lo largo del tiempo”.

Al aumentar progresivamente la tarifa de solicitud de retiro de acuerdo con el uso del contrato de solicitud de retiro del validador, EIP-7002 reduce el riesgo de que un atacante llene deliberadamente la cola de solicitudes de retiro para evitar que otros validadores realicen retiros. Los mensajes de recuperación en la cola de solicitudes de retiro se eliminan de la cola y se ordenan en orden de entrada-salida (FiFo) en lugar de, por ejemplo, orden de entrada-salida (LiFo) o transacción que paga más. Si bien podemos suponer que los precios del gas evitarán llamadas innecesarias al contrato de solicitud de retiro, un atacante malintencionado puede estar dispuesto a pagar más gas para "llenar" la cola de solicitudes de retiro y empujar la solicitud de retiro de otro validador al final de la cola.

El problema se agrava aún más por la centralización de la construcción de bloques en Ethereum posterior a la fusión. Si un atacante está integrado con uno o más constructores dominantes (para ponerlo en contexto: el 80-90% de los bloques hasta la fecha en Ethereum han sido producidos por 4-5 constructores ) y está dispuesto a pagar por la inclusión en la parte superior del bloque, puede adelantarse de manera efectiva a las solicitudes de retiro de uno o más participantes y evitar retiros oportunos de los validadores de la Beacon Chain.

¿Y por qué alguien pasaría por todo ese estrés? Una posible motivación podría ser que el atacante quiere perjudicar a los stakers que desean retirar validadores usando credenciales de retiro. Para usar lo anterior de Bob, el operador de nodo (malicioso) y Alice, la staker: Alice puede retirar rápidamente su validador para detener el ataque de duelo de Bob llamando al contrato de solicitud de retiro del validador con la credencial de retiro, pero Bob aún puede darse más para filtrar el saldo del validador de Alice enviando spam al contrato de solicitud de retiro del validador y retrasando la solicitud de retiro de Alice.

Estructura y validez del bloque

La EIP-7002 modifica levemente la estructura y la validación de los bloques Beacon al exigir que las solicitudes de retiro se coloquen en el cuerpo real del bloque (y la carga útil de ejecución en la capa de consenso). Las solicitudes deben estar incorporadas en la carga útil de ejecución de modo que, cuando la capa de consenso no se pueda alcanzar, esta aún tenga los datos necesarios para ejecutar por completo la parte de consenso de la función de transición de estado.

EIP-7002 también agrega nuevas condiciones de validez para los bloques. En primer lugar, la lista de solicitudes de retiro ( withdrawal_requests_list ) no puede superar MAX_WITHDRAWAL_REQUESTS_PER_BLOCK . En segundo lugar, la lista de solicitudes de retiro debe corresponder a la cantidad de solicitudes de retiro que se sacan de la cola de WITHDRAWAL_REQUEST_QUEUE cuando dichas solicitudes se organizan en orden de entrada, salida (FiFO).

EIP-7002 tiene una función ( expected_exit ) para confirmar que un bloque no incluye más solicitudes de retiro que el resultado de calcular NUM_WITHDRAWAL_REQUESTS_IN_QUEUE - MAX_WITHDRAWAL_REQUESTS_PER_BLOCK . Además, un nodo de consenso que vuelva a ejecutar el bloque calculará de forma independiente la codificación de las solicitudes de retiro iterando request_type y request_data en comparación con el compromiso del hash de la lista de solicitudes de retiro.

¿Por qué EIP-7002? El caso de las retiradas activables en la capa de ejecución

Supuestos de confianza reducidos en el staking delegado

En la introducción, señalé cómo la dependencia de la clave de firma de un validador para iniciar las salidas del validador introdujo el problema de la confianza; no incluí una definición de confianza, pero esta definición del artículo de Vitalik sobre modelos de confianza lo resume muy bien: “La confianza es cualquier suposición que hagas sobre el comportamiento de otras personas”. Al registrarse en un servicio de staking, sabiendo que un operador de nodo malicioso puede congelar los retiros, un staker esencialmente confía en que el operador del nodo actuará fielmente.

La EIP-7002 no elimina por completo el elemento de confianza en el staking delegado (aún se debe confiar en que el operador de un nodo no ejecutará un ataque de duelo), pero permitir que los participantes se retiren con credenciales de retiro reduce la carga de la confianza hasta cierto punto. Por ejemplo, un usuario no necesita "tener fe" en que un operador de nodo firmará un mensaje de salida voluntaria una vez que lo solicite.

Un aspecto sutil de la “falta de confianza” es que no se trata necesariamente de evitar la necesidad de confiar, sino de no tener que confiar porque (a) existen fuertes incentivos para que todas las partes actúen honestamente (b) las partes honestas tienen cierto grado de protección contra las acciones de las partes deshonestas. La capacidad de retirar un validador con credenciales de retiro es un ejemplo de esto último: Bob puede intentar causar problemas a Alice, pero ahora Alice tiene la capacidad de retirar su validador, con suerte antes de que Bob haga más daño.

Mejor gestión de riesgos para los pools de staking

Actualmente, los pools de staking no tienen forma de obligar a un operador de nodo validador a retirarse, lo que pone a los contribuyentes del pool en la incómoda posición de confiar en que los operadores de nodos actúen honestamente. Algunos pools de staking descentralizados requieren que los operadores de nodos proporcionen una fianza, pero dada la posibilidad de que un operador malintencionado se vea reducido a 0 ETH, la seguridad de una fianza podría ser inadecuada a los ojos de un staker reacio al riesgo.

Con la implementación de EIP-7002, los pools de staking pueden reducir en gran medida las suposiciones de confianza al complementar la seguridad ante la amenaza de reducir la garantía de un operador de nodo con procedimientos para retirar por la fuerza a un operador que se comporte mal mediante un retiro de la capa de ejecución. La posibilidad de retirar credenciales que apunten a una dirección de contrato inteligente (en lugar de una EOA) también abre nuevos diseños de respuesta a incidentes para los pools de staking; por ejemplo, un contrato inteligente podría enviar automáticamente una solicitud de retiro si un operador incurre en penalizaciones superiores a la media dentro de un período de tiempo. Sin embargo, esto requiere confiar en un oráculo para realizar un seguimiento del rendimiento del validador y en una red de guardianes para activar el contrato inteligente.

El otro beneficio hipotético para un pool de staking de implementar EIP-7002 es obviar la necesidad de solicitar y almacenar mensajes de retiro previamente firmados, lo que conlleva riesgos como he explicado anteriormente (por ejemplo, el acceso no autorizado a los mensajes de retiro podría resultar en retiros inesperados del validador). Esto también contribuye al objetivo de diseñar pools de staking sin confianza: en lugar de depender de solicitudes de retiro previamente firmadas almacenadas por unas pocas personas (de confianza), un contrato inteligente designado como la dirección de retiro podría ser controlado por la gobernanza, lo que permitiría a la comunidad decidir retirar a un operador de nodo de forma pública y transparente.

Mejor gestión de riesgos para configuraciones de TVP

La tecnología de validación distribuida (DVT) se considera una pieza fundamental de la infraestructura de staking de Ethereum por muchas razones:

• DVT reduce las barreras para el staking en solitario: varios participantes individuales pueden juntar fondos para activar conjuntamente un validador sin tener que confiar en todas las demás partes. Los esquemas de computación multipartidaria (MPC) pueden tolerar hasta ⅓ de nodos defectuosos, por lo que si un validador distribuido hipotético requiere 3 de 5 claves compartidas para reconstruir la clave de firma del validador, la firma puede ocurrir si dos nodos DVT están fuera de línea.
• La DVT mejora la tolerancia a fallas y la resiliencia para configuraciones de staking institucionales/en solitario: como se mencionó anteriormente, la clave de firma de un validador se puede dividir en diferentes claves compartidas y reconstruir solo cuando se requieren datos de bloques de firma. Esto reduce el riesgo de que un hacker comprometa la clave de firma del validador o de que un staker pierda el acceso a los fondos porque el dispositivo que almacena la clave de firma sufrió daños.

Sin embargo, las configuraciones de DVT aún conllevan cierto riesgo para los participantes debido a la forma en que funcionan actualmente los retiros y las salidas en la cadena Beacon. Si algunos nodos de DVT extravían las claves compartidas o se niegan a participar en el esquema de firma de umbral, salir de un validador se vuelve imposible, especialmente cuando:

• Las claves compartidas para cada participante en la configuración de DVT se generan al momento de activar un validador y no se pueden “actualizar” después de la ceremonia inicial de DKG (tenga en cuenta que un “participante” podría ser simplemente otro EOA propiedad del mismo staker); algunos protocolos de DVT permiten que se generen nuevas claves compartidas, aunque esto puede requerir que las claves compartidas restantes cumplan con el quórum de firmas requerido para la firma regular.
• El umbral de quórum (la cantidad de claves compartidas necesarias para generar conjuntamente una firma válida para el validador distribuido) no se puede cambiar una vez que el validador (distribuido) esté activo.

Si EIP-7002 no ofrece la opción de retirar un validador utilizando la clave de retiro, el beneficio de ejecutar una configuración DVT (de forma independiente o en conjunto con otros validadores) se reduciría en gran medida (por ejemplo, el saldo de un validador podría bloquearse para siempre). EIP-7002 ofrece una opción de seguridad alternativa para validadores distribuidos: si no es posible reconstruir la clave de firma, el validador puede retirarse de la cadena Beacon enviando una solicitud de retiro firmada con la clave de retiro reconstruida a partir de claves compartidas.

Mejor cumplimiento normativo: poner el factor “no custodio” en el staking sin custodia

Es poco probable que los autores de la EIP-7002 hayan establecido explícitamente el objetivo de facilitar la gestión de una empresa institucional regulada de staking como servicio. Aun así, la EIP ayuda con el problema de convencer a los reguladores de que una institución no custodia los ETH en staking. Un operador de staking en este escenario podría simplemente presentar un hash de la transacción de depósito firmada por la clave de retiro del staker (que ahora puede firmar y enviar salidas voluntarias) como prueba de que los fondos depositados en un validador nunca están bajo su custodia en ningún momento.

Hice hincapié en "cualquier momento" ya que, antes de la EIP 7044, un operador de nodo asume temporalmente el control del saldo del validador después de que expire la salida firmada previamente. E incluso con las salidas firmadas válidas perpetuamente de la EIP-7044, los operadores de nodo aún tienen la custodia de los 32 ETH depositados para un validador durante el breve período entre la activación del validador y la recepción por parte del staker de un mensaje de salida firmado por parte del operador del servicio de staking. La EIP-7002 elimina estas áreas incómodas y garantiza que los stakers tengan la custodia (demostrable) de los fondos durante todo el ciclo de vida del validador, desde el ingreso a la Beacon Chain hasta el retiro y el envío de fondos a la dirección de retiro del staker.

Mejor experiencia de usuario (UX) para todos

Un buen modelo mental para EIP-7002 es pensar en él como una “ abstracción de cuenta para la infraestructura de staking”. Para contextualizar, una clave de validación (o clave de firma) es siempre una EOA y viene con el mismo conjunto de restricciones en torno a la seguridad y el uso de la clave privada que afecta a las EOA regulares de Ethereum en la actualidad:

• Las claves de validación (firma) tienen un mayor riesgo de verse comprometidas. A diferencia de las claves de retiro almacenadas en almacenamiento en frío (fuera de línea), las claves de validación se almacenan en billeteras activas conectadas a Internet, lo que las hace susceptibles a ataques de phishing. Si la clave de firma de un validador se ve comprometida, los participantes y los proveedores de participación delegados son susceptibles a los vectores de duelo descritos en la introducción sin ningún plan de respaldo, más allá de "esperar hasta que el saldo baje a 16 ETH y el protocolo retire por la fuerza el validador".
• Las claves de validación tienen opciones limitadas para los esquemas de recuperación (si la pierdes una vez, la pierdes para siempre). Dividir una clave de validación en múltiples claves compartidas a través de la tecnología de validación distribuida (DVT) puede mitigar este riesgo, pero ejecutar una configuración de participación DVT en solitario no es trivial; además, como expliqué anteriormente, DVT no es una solución milagrosa, ya que las claves compartidas se pueden perder y complicar la actualización de las claves compartidas.
• Las claves de validación no pueden admitir diseños de staking más flexibles. Diferentes servicios de staking han desarrollado flujos de trabajo automatizados/flexibles para financiar validadores debido al beneficio de apuntar las credenciales de retiro a contratos inteligentes. Sin embargo, retirar un validador es un proceso manual que requiere firmar un mensaje de solicitud de retiro voluntario; el proceso podría automatizarse mediante un contrato inteligente que almacene solicitudes de retiro previas a la firma, pero eso conlleva ciertas suposiciones de confianza y consideraciones de seguridad explicadas anteriormente.

Podemos resolver la mayoría (o al menos algunos) de estos problemas una vez que las claves de retiro sean capaces de salir de los validadores. Para que esto funcione, un staker (o grupo de staking) deberá completar un cambio único de credenciales de retiro 0x0 a credenciales de retiro 0x01 ; si bien las credenciales 0x0 son una clave BLS (EOA) de forma predeterminada, las credenciales 0x01 pueden apuntar a cualquier dirección de Ethereum, incluidos los contratos inteligentes y las EOA. Establecer un contrato inteligente como la dirección de retiro para un validador es excelente para mejorar la experiencia del usuario (UX) del staking:

1. Las claves de retiro pueden tener mecanismos de recuperación flexibles, como la recuperación social. Un staker tendría uno o más "guardianes" que pueden autorizar una nueva clave para controlar el contrato inteligente de solicitud de retiro si la clave original es robada o perdida; los guardianes pueden ser amigos, parientes, compañeros stakers o un servicio especializado de terceros. La flexibilidad en los mecanismos de recuperación puede beneficiar particularmente a los stakers individuales; puede tener un interruptor de hombre muerto que active una salida EL y envíe fondos a una dirección designada si su validador deja de dar fe durante un período predeterminado (por ejemplo, porque ha "pasado al Más Allá").

2. Pueden surgir diseños de staking flexibles. Por ejemplo, un staker reacio al riesgo puede preferir un contrato de retiro multisig 2 de 2 (en el que el staker y el operador del nodo tienen una de las dos claves necesarias para aprobar las solicitudes de retiro) en lugar de almacenar la clave de retiro completa. Sigue siendo un contrato sin custodia (un operador de nodo no puede salir del validador sin aprobación), aunque requiere confiar en que el operador del nodo no bloqueará la salida de un validador negándose a firmar las transacciones de solicitud de retiro propuestas por el staker.

Para los pools de staking, la flexibilidad en los diseños de staking podría significar implementar contratos de retiro con lógica arbitraria para actualizar o transferir la propiedad de los validadores. En ausencia de EIP-7002, la única forma real en que un pool de staking puede administrar la propiedad de los validadores es mover las solicitudes de retiro firmadas previamente, lo que conlleva varios riesgos y casos extremos.

3. Los retiros de los validadores se pueden automatizar de forma segura. A diferencia de almacenar solicitudes de retiro firmadas previamente en un contrato inteligente, los contratos de solicitud de retiro pueden tener reglas complejas que rijan las solicitudes de retiro de los validadores; una idea de “ciencia loca” es un “grupo de staking basado en el tiempo” donde los operadores de nodos se rotan sin confianza. O considere si un gran grupo de staking como Lido quiere descentralizarse: la gobernanza puede optar por retirar algunos validadores controlados por un gran operador de nodo y redistribuir fondos a operadores más pequeños (o stakers individuales) para reducir los puntos de estrangulamiento de un operador de nodo que controla una cantidad considerable de validadores.

Estas son solo algunas de las primeras posibilidades que permite la EIP-7002, pero estoy muy seguro de que aparecerán más aplicaciones, al igual que siguen apareciendo nuevas funciones y casos de uso para billeteras inteligentes en Ethereum. Si estás leyendo esto y tienes ideas más concretas para aplicar la EIP-7002 a los diseños de staking, ¡no dudes en opinar en los comentarios!

¿Existen inconvenientes en la implementación de EIP-7002?

Posibles cambios importantes en los diseños de replanteo existentes

En el borrador de EIP, los autores de EIP-7002 reconocen posibles preocupaciones en torno a habilitar las credenciales de retiro para activar los retiros del validador, pero continúan diciendo: "no conocemos ningún diseño de staking que dependa de esta característica [es decir, la imposibilidad de retirar con credenciales de retiro]". Esto parece razonable; incluso yo tuve algunas dificultades para razonar sobre cualquier acuerdo de staking delegado que requiera esta característica. Pero el hecho de que no parezca obvio no significa que no exista.

“Escucha esas dudas silenciosas y persistentes. Si no sabes, no sabes lo que no sabes, no sabes cuánto no sabes y no sabes cuánto necesitabas saber”. — Eliezer Yudkowsky

Para brindar algo de contexto, incluiré capturas de pantalla de una conversación en torno a una propuesta temprana para implementar salidas aprobadas por credenciales de retiro a través de un Bus de Mensajes Generalizados (GMB) . El GMB es un contrato inteligente a nivel de sistema cuyos eventos son leídos y procesados por los clientes, como el contrato de depósito actual, y es capaz de transmitir mensajes desde la capa de ejecución a la capa de consenso. Si bien el autor o los autores insinuaron tipos de mensajes EL-a-CL más genéricos, el principal caso de uso propuesto del bus de mensajes EL-a-CL fue proporcionar una forma de activar salidas desde la capa de ejecución a través de credenciales de retiro 0x01.

A partir de este intercambio, ya tenemos un ejemplo de una relación entre el operador del nodo y el staker construida sobre la suposición de que el staker no puede salir y retirar un validador utilizando la clave de retiro. Otro ejemplo de un posible caso extremo de implementación de EIP-7002 proviene de una conversación sobre los planes de descentralización de Lido en el Lido Community Staking Podcast, que puede ver en YouTube . (EIP-7002 solo se menciona brevemente (28:55 a 30:00) en el video).

Como antecedente, Lido ha sido descrito como una “amenaza sistemática para Ethereum” porque controla aproximadamente el 33,3% de los validadores de Beacon Chain y podría poner en riesgo el consenso de Ethereum; por ejemplo, si Lido DAO obligara a los operadores de nodos a censurar transacciones o revertir bloques previamente finalizados ( Magnitud y dirección de los vectores de ataque de Lido de Mike Neuder describe la amenaza con más detalle).

Sin embargo, uno de los oradores del episodio vinculado anteriormente presenta el argumento convincente de que este vector de ataque (la DAO cooptando por la fuerza a los operadores de nodos para que ataquen el protocolo Ethereum) aún no existe, ya que los operadores de nodos tienen cierta capacidad de acción. La DAO puede retener la participación de un validador después de que salga, pero no puede depender de la amenaza de una salida forzada para obligar a un validador a atacar el consenso de Ethereum.

Con EIP-7002, la dinámica de poder cambia significativamente: los contratos de retiro regidos por la DAO pueden retirar a un operador en contra de su voluntad, lo que le otorga a la DAO influencia sobre los operadores de nodos. Este tipo de influencia es útil para proteger un protocolo de staking contra un conjunto de operadores maliciosos, como expliqué anteriormente. Pero también se puede usar de manera incorrecta en los siguientes escenarios:

• El protocolo de staking sufre un ataque de gobernanza y la DAO aprueba una propuesta maliciosa para provocar el retiro de un validador del contrato de retiro.
• Un atacante asume el control de uno o más validadores secuestrando la propiedad del contrato de solicitud de retiro y ejecuta una estrategia de chantaje exitosa.

Este es otro ejemplo de cómo EIP-7002 podría cambiar los supuestos existentes en los diseños de staking, esta vez, para los operadores de nodos que validan en nombre de un pool de staking como Lido. Sin embargo, este vector de ataque se puede mitigar fácilmente a través de diferentes métodos, como el uso de contratos de solicitud de retiro seguros, rigurosamente auditados y posiblemente no actualizables, o siguiendo las mejores prácticas para la gobernanza segura de DAO .

Para tener en cuenta el caso extremo en el que un operador de nodo sufre pérdidas debido a un retiro forzado después de rechazar las demandas de un atacante de violar las reglas del protocolo, los grupos de participación pueden inspirarse en las empresas de bienes raíces para proteger a los operadores de nodos:

• Antes de firmar un contrato de alquiler, los inquilinos deben entregar un “depósito de garantía”. El depósito se deposita en una cuenta bancaria fuera del control de la empresa inmobiliaria.
• Si el inquilino se muda del apartamento, pero deja daños importantes, la compañía inmobiliaria tiene derecho a utilizar el depósito de seguridad para cubrir el costo de las reparaciones.
• Si el apartamento está en buenas condiciones al momento de la salida del inquilino, el depósito de seguridad se devuelve en su totalidad al inquilino.

Un protocolo de staking puede adoptar un enfoque similar para proteger a los operadores de nodos mediante la contratación de una póliza de "fondo de seguro para operadores de nodos" a través de Nexus Mutual , Tidal Finance o cualquier otra plataforma de seguros nativa de criptomonedas. Si el validador de un operador se retira legítimamente, el fondo de seguro se devuelve a la DAO; si ocurre lo contrario (por ejemplo, el retiro de un validador se desencadena por una propuesta maliciosa o un error en el contrato de retiro), la póliza de seguro paga los daños al operador del nodo. Tenga en cuenta que este enfoque se puede generalizar a cualquier relación existente que dependa de las especificaciones actuales para salir de un validador.

Falta de soporte para mensajes EL-a-CL más complejos

El contrato de solicitud de retiro del validador de EIP-7002 proporciona una única funcionalidad: enviar una solicitud de retiro desde la capa de ejecución de Ethereum a la capa de consenso para retirar un validador. Sin embargo, algunos han sugerido implementar un marco de mensajería general (por ejemplo, una precompilación SendMessageToConsensusLayer o el contrato a nivel de sistema Generalized Message Bus (GMB) mencionado anteriormente) para pasar tipos genéricos de mensajes entre la capa de ejecución y la capa de consenso. Esto podría tener beneficios como desbloquear nuevas formas de activar validadores en Beacon Chain, especialmente si se permite adjuntar ETH a mensajes EL-to-CL.

Sin embargo, como explica Danny Ryan (uno de los autores de EIP-7002) en un comentario , dedicar un tiempo de ingeniería valioso a un marco de mensajería genérica EL → CL es una “gran tarea con una propuesta de valor poco clara”. Para ilustrarlo, los autores de la propuesta GMB (General Message Bus) solo identificaron otro caso de uso para un bus de mensajes entre el EL y el CL: la rotación de credenciales de retiro para un validador de credenciales 0x0 a 0x01 .

Esto significa que es más probable que veamos que el validador retira el contrato de solicitud antes de que los desarrolladores principales hablen sobre la implementación de un bus de mensajes general de EL a CL, si es que eso sucede alguna vez. No es que mantener las cosas simples sea malo.

La sencillez es un requisito previo para la fiabilidad. — Edsger W. Dijkstra

Nuevos vectores de riesgo para los participantes existentes

He explicado en detalle los beneficios de habilitar las credenciales de retiro para activar un retiro en su mayor parte, pero hay algunos casos extremos asociados con esa función. La idea es la siguiente (gracias a este comentario en GitHub ):

• Si la clave de firma de un validador se ve comprometida, un hacker puede exigir un rescate o intentar reducir el saldo del validador, pero no puede retirar fondos en ningún caso. Se producirá un juego de espera: ¿el atacante destruirá todo el saldo o el staker podrá retirar una parte de la participación una vez que el validador sea retirado por la fuerza?
• Sin embargo, una vez que se implementa EIP-7002, el hacker en el escenario anterior puede proceder a salir del validador y retirar el saldo (una vez que se implementa EIP-7002) en lugar de conformarse con un ataque de chantaje.

En resumen, los participantes individuales y los servicios de staking necesitarán más protección para las credenciales de retiro después de EIP 7002. Es por eso que la adopción de recuperación social, autenticación multifactor (MFA) y rotación de claves se consideran fundamentales para mejorar la seguridad de las operaciones de staking individuales/delegados.

Elección del mecanismo de limitación de velocidad

La funcionalidad add_withdrawal_request() del contrato de solicitud de retiro del validador no realiza ninguna verificación adicional, además de verificar la tarifa de solicitud de retiro adjunta, lo que potencialmente permite que un atacante obstruya la cola de mensajes con solicitudes de retiro no válidas (por ejemplo, los mensajes de salida para un validador inexistente o un validador inactivo se invalidarán durante las verificaciones de validez de la capa de consenso). EIP-7002 utiliza una tarifa de retiro con precio dinámico para limitar la tasa de solicitudes de retiro y hacer que dichos ataques sean costosos, de manera similar a cómo EIP-1559 desalienta los ataques de spam y el relleno de bloques al ajustar los precios del gas en función de la actividad de la red.

Un diseño alternativo es restringir las llamadas al contrato de solicitud de retiro del validador a los validadores reales, por ejemplo, verificando que validator_pubkey corresponda a la clave pública de un validador de Beacon Chain activo. Esto podría simplificar el diseño de EIP-7002 al eliminar la necesidad de un mecanismo de precios complejo al estilo de EIP-1559 y, potencialmente, reducir la tarifa de solicitud de retiro, ya que saturar la cola con solicitudes falsas puede ser un problema menor.

Sin embargo, esto requiere que la capa de ejecución pueda acceder sin necesidad de confiar en la información sobre la capa de consenso (para comprobar validator_pubkey con el registro de validadores de Beacon Chain), una característica que depende de la implementación de EIP-4788. Esto agrega más complejidad a EIP-7002 e introduce una nueva dependencia entre las dos EIP, lo que puede tener implicaciones para futuras mejoras de diseño, como se señala en esta sección de la justificación de EIP-7002 .

Incluso si se integrara la EIP-4788 con la EIP-7002, necesitaríamos mecanismos adicionales para evitar otras formas de spam que involucren a validadores legítimos; un ejemplo es enviar múltiples solicitudes de retiro para el mismo validador en un período muy corto. Esto, a su vez, requiere agregar (y aplicar) una nueva regla como "solo puede enviar una solicitud de retiro por validador cada 3 o 4 meses", lo que puede requerir incluso más cambios en el contrato de solicitud de retiro del validador.

En cambio, el mecanismo actual de limitación de velocidad es fácil de entender y garantiza suficiente protección contra la mayoría de los problemas de seguridad asociados con los retiros en la capa de ejecución. Por ejemplo, la tarifa de solicitud de retiro puede ajustarse automáticamente hacia arriba para evitar el duelo (intentar evitar que los validadores honestos se retiren) y el spam y los ataques DOS (intentar sobrecargar la Beacon Chain al obligar a los nodos de consenso a desperdiciar recursos en filtrar operaciones de retiro no válidas).

Conclusión: EIP-7002 y el futuro del staking en Ethereum

El staking delegado ha recibido críticas significativas en los últimos meses, pero es seguro asumir que la industria del staking como servicio llegó para quedarse. Si es así, es importante reducir el riesgo para las personas que delegan su participación, ya sea a un grupo de staking líquido o a un servicio de staking institucional sin custodia. EIP-7002 logra este objetivo al hacer que las credenciales de retiro 0x01 sean capaces de salir de los validadores y retirar la participación, y reducir la necesidad de que los participantes confíen en la honestidad de un operador de nodo.

La EIP-7002 también tiene otros efectos secundarios positivos. En particular, mejorar la resiliencia y la seguridad de las operaciones de staking en solitario y de los validadores distribuidos (al permitir una mejor recuperación de la pérdida de una clave de validación o de claves compartidas de DVT) debería reducir la barrera para el staking en solitario y reducir la centralización del staking en Ethereum.

Como es habitual, terminaré pidiéndote que consideres compartir este artículo con alguien a quien le pueda resultar informativo y, lo que es más importante, que te suscribas a Ethereum 2077 para obtener más información detallada sobre todo lo relacionado con la investigación y el desarrollo de Ethereum. También puedes conectarte conmigo en Twitter para compartir comentarios o sugerencias sobre este artículo.