En noviembre pasado, presentamos EigenLayer en este artículo "EigenLayer: Llevando la confianza a nivel de Ethereum al middleware". Durante casi un año, EigenLayer publicó su documento técnico, completó una ronda de financiación Serie A de 50 millones de dólares y lanzó la primera fase de la red principal. Durante este período, la comunidad Ethereum también mantuvo extensos debates sobre EigenLayer y sus casos de uso. Este artículo rastreará y clasificará estas discusiones.
fondo
En el ecosistema Ethereum, algunos servicios de middleware (como los oráculos) no dependen completamente de la lógica en cadena, por lo que no pueden depender directamente del consenso y la seguridad de Ethereum y necesitan redirigir la red de confianza. El enfoque habitual es operar primero el proyecto, luego introducir incentivos simbólicos para atraer participantes del sistema y lograr gradualmente la descentralización.
Hay al menos dos dificultades al hacer esto. Una es que la introducción de un mecanismo de incentivos requiere costos adicionales: el costo de oportunidad para que los participantes compren tokens para participar en el compromiso y el costo operativo para que la parte del proyecto mantenga el valor de los tokens. En segundo lugar, incluso si se pagan los costos anteriores y se construye una red descentralizada, aún se desconocen su seguridad y sostenibilidad. Estos dos puntos son especialmente complicados para proyectos de nueva creación.
La idea de EigenLayer es proporcionar seguridad económica para estos middleware (Servicios validados activamente, AVS) mediante la reapropiación por parte de los participantes de Ethereum existentes. Si estos nuevos contribuyentes trabajan honestamente, pueden ser recompensados, pero si hacen el mal, perderán su exposición original a la promesa de Ethereum.
Las ventajas de esto son: en primer lugar, la parte del proyecto no necesita guiar la nueva red de confianza por sí misma, sino que la subcontrata a validadores de Ethereum, reduciendo los costos de capital tanto como sea posible; en segundo lugar, la seguridad económica del conjunto de validadores de Ethereum es muy sólido, por lo que la seguridad también ha sido garantizada hasta cierto punto. Desde la perspectiva de los contribuyentes de Ethereum, volver a comprometerse les proporciona ingresos adicionales. Siempre que no exista una intención maliciosa subjetiva, el riesgo general es controlable.
Sreeram, el fundador de EigenLayer, mencionó una vez los tres casos de uso y modelos de confianza de EigenLayer en Twitter y podcasts:
Confianza económica. Es decir, la reutilización de la exposición a las apuestas de Ethereum y las apuestas de tokens de mayor valor significa una seguridad económica más sólida, como se analizó anteriormente.
Confianza descentralizada. Es posible que el comportamiento malicioso de algunos servicios (como el intercambio de secretos) no sea atribuible y no se pueda confiar en los mecanismos de reducción. Es necesario que haya un grupo de personas suficientemente descentralizado e independiente que haga algo para protegerse contra el riesgo de colusión y colusión.
Compromiso del validador de Ethereum. Los productores de bloques prometen ciertos compromisos creíbles frente a su exposición prometida. A continuación daremos algunos ejemplos para ilustrar más.
Participantes del sistema
![IOSG Ventures: una mirada a los últimos avances y casos de uso de EigenLayer en el campo de la "re-promesa"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-c0a688f2e8-dd1a6f -6d2ef1)
Fuente: IOSG Ventures
EigenLayer sirve como un mercado abierto que conecta a los tres actores principales.
*Re-promesas. Si tiene exposición a la apuesta de Ethereum, puede participar transfiriendo las credenciales de retiro a EigenLayer para participar en la nueva apuesta, o simplemente depositar LST como stETH para participar. Los re-stakeers también pueden delegar su exposición a los operadores si no pueden ejecutar un nodo AVS por sí mismos.
operador. Los operadores aceptan la delegación de los re-stakeers y ejecutan nodos AVS. Son libres de elegir qué AVS prestar servicio. Una vez que brinde servicio a AVS, debe aceptar las reglas de reducción definidas por él.
*avs. Como demandante/consumidor, AVS necesita pagar a los rehipotecadores y obtener la seguridad económica que estos le proporcionan.
Con estos conceptos básicos en mente, veamos los casos de uso específicos de EigenLayer.
DA propia
EigenDA es el producto estrella lanzado por EigenLayer y la solución se deriva de Danksharding, la solución de expansión de Ethereum. Entre ellos, el muestreo de disponibilidad de datos (DAS) también se utiliza ampliamente en proyectos DA como Celestia y Avail. En este capítulo damos una introducción rápida a DAS y luego analizamos la implementación de EigenDA y sus innovaciones.
EL
![IOSG Ventures: una mirada a los últimos avances y casos de uso de EigenLayer en el campo de la "recomprometida"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-7417ebaed1-dd1a6f -6d2ef1)
Fuente: Dankrad Feist
Como solución inicial para Danksharding, EIP-4844 introduce la "transacción portadora de blobs": cada transacción transportará un tamaño de datos adicional de aproximadamente 125 kb. En el contexto de la ruta de expansión de la fragmentación de datos, los nuevos datos sin duda aumentarán la carga sobre los nodos. Entonces, ¿hay alguna manera de hacer que el nodo descargue solo una pequeña parte de los datos y también verificar que todos los datos estén disponibles?
Lo que hace DAS es permitir que los nodos muestreen aleatoriamente una pequeña parte de los datos varias veces. Cada muestreo exitoso aumenta la confianza del nodo en que los datos están disponibles y, una vez que se alcanza un cierto nivel preestablecido, los datos se consideran disponibles. Sin embargo, todavía es posible que un atacante oculte una pequeña parte de los datos; también necesitamos algún tipo de tolerancia a fallos.
DAS utiliza codificación de borrado (Erasure Coding). La idea principal de la codificación de borrado es dividir los datos en varios bloques y luego codificar estos bloques, generando bloques redundantes adicionales. Estos bloques redundantes contienen parte de la información de los bloques de datos originales, de modo que cuando algunos bloques de datos se pierden o dañan, los bloques de datos perdidos se pueden recuperar a través de los bloques redundantes. De esta manera, la codificación de borrado proporciona redundancia y confiabilidad para DAS.
Además, también debemos verificar si los bloques redundantes resultantes están codificados correctamente, porque los datos originales no se pueden reconstruir con un bloque redundante incorrecto. Danksharding utiliza compromisos KZG (Kate-Zaverucha-Goldberg). El compromiso KZG es un método para verificar un polinomio, que puede demostrar que el valor del polinomio en una posición específica es consistente con el valor especificado.
El probador elige un polinomio p(x) y usa p(x) para calcular un compromiso para cada bloque de datos, llamado C1, C2, ..., Cm. El probador publicará el compromiso junto con el bloque de datos. Para verificar una codificación, el verificador puede muestrear aleatoriamente t puntos x 1, x 2, ..., xt y pedirle al probador que abra compromisos en estos puntos: p(x 1), p(x 2), ..., p(xt). Utilizando la interpolación lagrangiana, el verificador puede reconstruir el polinomio p(x) a partir de estos t puntos. El verificador ahora puede volver a calcular los compromisos C 1', C 2', ..., Cm' utilizando el polinomio reconstruido p(x) y el bloque de datos y verificar que coincidan con los compromisos publicados C 1, C 2, ... , Cm coincide.
En resumen, al utilizar los compromisos de KZG, los verificadores solo necesitan una pequeña cantidad de puntos para verificar la exactitud de toda la codificación. De esta forma conseguimos un DAS completo.
Cómo
Fuente: Capa propia
EigenLayer toma prestadas ideas de DAS y las aplica a EigenDA.
Primero, los nodos de EigenDA se vuelven a pignorar y registrar en el contrato EigenLayer.
En segundo lugar, una vez que el secuenciador obtiene los datos, los divide en varios bloques, utiliza códigos de borrado para generar bloques redundantes y calcula el compromiso KZG correspondiente a cada bloque de datos. Sequencer publica los compromisos de KZG uno por uno en el contrato EigenDA como testigo.
Posteriormente, el secuenciador distribuye el bloque de datos junto con su compromiso KZG a cada nodo EigenDA uno por uno. Después de que el nodo obtiene el compromiso KZG, lo compara con el compromiso KZG en el contrato EigenDA, almacena el bloque de datos después de confirmar que es correcto y lo firma.
Luego, el secuenciador recopila estas firmas, genera firmas agregadas y las publica en el contrato EigenDA, y el contrato EigenDA verifica las firmas. Una vez que se verifica que la firma es correcta, se completa todo el proceso.
En el proceso anterior, el nodo EigenDA solo afirma haber almacenado el bloque de datos mediante firmas. También necesitamos una forma de garantizar que el nodo EigenDA no mienta. EigenDA adopta Prueba de Custodia.
La idea de la prueba de depósito en garantía es poner una "bomba" en los datos y, una vez que el nodo los firme, se cortarán. Para implementar la prueba de custodia, es necesario diseñar: un valor secreto para distinguir diferentes nodos DA para evitar trampas; una función específica para el nodo DA, tomando los datos DA y el valor secreto como entrada, y la presencia o ausencia de bombas como salida. Si el nodo no almacena los datos completos que se supone que debe almacenar, esta función no se puede calcular. Dankrad ha compartido más detalles sobre la Prueba de depósito en garantía en su blog.
![IOSG Ventures: Una mirada a los últimos avances y casos de uso de EigenLayer en el campo de las "repropuestas"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-5e2b72172c-dd1a6f-6d2ef1 )
Fuente: Capa propia
Si hay un nodo diferido, cualquiera puede enviar una prueba al contrato EigenDA, y el contrato verificará la prueba, y si se pasa la verificación, el nodo diferido será multado.
En términos de requisitos de hardware, el compromiso de KZG de calcular 32 MB de datos en 1 segundo requiere aproximadamente entre 32 y 64 CPU de núcleo, pero este requisito es solo para el lado del secuenciador y no impondrá una carga al nodo EigenDA. En la red de prueba de EigenDA, el rendimiento de 100 nodos de EigenDA alcanzó los 15 MB/s, mientras que la demanda de ancho de banda de descarga de los nodos fue de sólo 0,3 MB/s (mucho menor que los requisitos para ejecutar validadores de Ethereum).
En resumen, podemos ver que EigenDA logra desacoplar la disponibilidad de datos y el consenso, y la propagación de bloques de datos ya no está limitada por el cuello de botella del protocolo de consenso y el bajo rendimiento de la red P2P. Porque EigenDA es equivalente a un viaje gratis en el consenso de Ethereum: el proceso de Sequencer que emite compromisos KZG y firmas agregadas, verifica firmas mediante contratos inteligentes y castiga a los nodos maliciosos ocurren en Ethereum, y Ethereum proporciona garantías de consenso, por lo que no hay necesidad. para reiniciar la red de confianza.
Problemas del DAS
Actualmente, DAS como tecnología en sí tiene algunas limitaciones. Debemos asumir que una contraparte maliciosa intentará engañar a los nodos ligeros para que acepten datos falsos por cualquier medio posible. Sreeram declaró lo siguiente en su tweet.
Para que un solo nodo tenga una probabilidad suficientemente alta de que los datos estén disponibles, se deben cumplir los siguientes requisitos:
Muestreo aleatorio: se requiere que cada nodo seleccione de forma independiente y aleatoria un grupo de muestras para el muestreo, y la contraparte no sabe quién solicitó qué muestras. De esta forma, la contraparte no puede cambiar su estrategia en consecuencia para engañar a los nodos.
Muestreo concurrente: se requiere que DAS sea realizado por múltiples nodos al mismo tiempo, de modo que el atacante no pueda distinguir el muestreo de un nodo del muestreo de otros nodos.
Muestreo de IP privada: significa utilizar una IP anónima para cada bloque de datos consultado. De lo contrario, el adversario puede identificar diferentes nodos que realizan muestreos y proporcionar selectivamente a los nodos las partes que han consultado sin proporcionar otras partes de los datos.
Podemos permitir que múltiples nodos ligeros realicen un muestreo aleatorio para satisfacer la concurrencia y la aleatoriedad, pero actualmente no existe una buena manera de satisfacer el muestreo de IP privado. Por lo tanto, todavía existen vectores de ataque contra DAS, por lo que actualmente DAS sólo ofrece garantías débiles. Estos problemas todavía se están resolviendo activamente.
Capa propia y MEV
![IOSG Ventures: una lista de los últimos avances y casos de uso de EigenLayer en el campo de las "nuevas promesas"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-56389daf61-dd1a6f-6d2ef1 )
Fuente: Capa propia
Sreeram habló sobre el uso de EigenLayer en la pila MEV en la Cumbre MEVconomics. Con base en las primitivas criptoeconómicas de apostar y recortar, los proponentes pueden implementar las siguientes cuatro características, que son el tercer punto mencionado anteriormente: el caso de uso del compromiso del validador.
Activación basada en eventos
Protocolos como Gelato pueden reaccionar a eventos específicos en cadena. Es decir, monitoreo continuo de eventos en la cadena, y una vez que ocurre un evento, se activan algunas operaciones predefinidas, que generalmente las completan oyentes/ejecutores de terceros.
Se llama "tercero" porque no existe conexión entre el oyente/ejecutor y el proponente que realmente maneja el espacio del bloque. Supongamos que un oyente/ejecutor desencadena una transacción pero (por alguna razón) un proponente no lo incluye en un bloque, lo que no se puede atribuir y, por lo tanto, no ofrece garantías económicas deterministas.
Si los proponentes participantes brindan este servicio, pueden asumir compromisos creíbles para la activación de operaciones, y si estas transacciones finalmente no se incluyen en el bloque, el proponente queda eliminado. Esto proporciona garantías más sólidas que los oyentes/ejecutores de terceros.
En aplicaciones prácticas (como los protocolos de préstamos), uno de los propósitos de fijar la tasa de sobregarantía es cubrir las fluctuaciones de precios dentro de un cierto rango de tiempo. Esto está relacionado con el período de tiempo previo a la liquidación, y una tasa de sobregarantía más alta significa un período de amortiguación más largo. Si una gran proporción de transacciones adopta una estrategia reactiva impulsada por eventos y cuenta con sólidas garantías proporcionadas por los proponentes, entonces (para activos altamente líquidos) la volatilidad de la tasa de sobrecolateralización puede limitarse a unos pocos intervalos de bloques, reduciendo así el exceso de colateralización. -tasa de garantía y mejora de la eficiencia del capital.
Subasta en bloque parcial
En el diseño actual de MEV-Boost, el proponente subcontrata completamente el espacio del bloque al constructor y solo puede recibir y proponer pasivamente todo el bloque presentado por el constructor. Hay solo un puñado de constructores en comparación con los proponentes más distribuidos, y pueden confabularse para censurar y extorsionar transacciones específicas, porque los proponentes no pueden incluir las transacciones que desean en MEV-Boost.
![IOSG Ventures: descripción general de los últimos avances y casos de uso de EigenLayer en el campo de las "nuevas promesas"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-acfbe6d8dc-dd1a6f-6d2ef1)
Fuente: Capa propia
EigenLayer propuso MEV-Boost++ para actualizar MEV-Boost e introdujo la parte del Proponente en el bloque. El proponente puede incluir cualquier transacción en la parte del Proponente. El proponente también puede construir un bloque B-alt alternativo al mismo tiempo y proponer este bloque alternativo B-alt si el relé no libera Builder_part. Esta flexibilidad garantiza la resistencia a la censura y al mismo tiempo resuelve el problema de la vitalidad del relevo.
Fuente: Dankrad Feist
Esto es consistente con el propósito del diseño de la capa de protocolo: la crList propuesta por ePBS, es decir, debemos asegurarnos de que una amplia gama de proponentes puedan participar en la decisión de la composición de los bloques para lograr la anticensura.
Cifrado de umbral
En la solución MEV basada en cifrado de umbral, las claves de cifrado y descifrado son gestionadas por un grupo de nodos distribuidos. Los usuarios cifran las transacciones, que se descifran y ejecutan después de incluirlas en un bloque.
Sin embargo, el cifrado de umbral se basa en el supuesto de honestidad mayoritaria. Si la mayoría de los nodos actúan mal, es posible que las transacciones descifradas no se incluyan en el bloque. Los proponentes de volver a apostar pueden asumir un compromiso creíble con la transacción cifrada para garantizar su inclusión en el bloque. Si el proponente no incluye la transacción descifrada, se eliminará. Por supuesto, si una mayoría maliciosa de nodos no libera la clave de descifrado, el proponente puede proponer un bloque vacío.
Subasta de Blockspace a largo plazo
Las subastas de espacios de bloques a largo plazo permiten a los compradores de espacios de bloques reservar por adelantado espacios de bloques futuros para un validador. Los validadores que participan en el re-stake pueden asumir compromisos creíbles y se perderán si no incluyen la transacción del comprador cuando expire. Esta garantía de acceso al espacio en bloque tiene algunos casos de uso práctico. Por ejemplo, la máquina Oracle necesita alimentar los precios en un cierto período de tiempo; Arbitrum publica datos L2 en Ethereum L1 cada 1-3 minutos, Optimism cada 30 segundos-1 minuto, y así sucesivamente.
##PEPC
![IOSG Ventures: una mirada a los últimos avances y casos de uso de EigenLayer en el campo de la "re-promestación"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-a2677d5154-dd1a6f -6d2ef1)
Fuente: Barnabé Monnot
Volvamos al PEPC (Compromiso del proponente aplicado por protocolo), que ha sido ampliamente discutido recientemente en la comunidad Ethereum. PEPC es en realidad la promoción o generalización de ePBS.
Desmontemos esta cadena lógica una por una.
Primero, tome PBS MEV-Boost fuera del protocolo como ejemplo. Actualmente MEV-Boost se basa en el mecanismo de corte a nivel del protocolo Ethereum, es decir, si un proponente firma dos encabezados de bloque diferentes a la misma altura de bloque, serán recortado. Debido a que el proponente necesita firmar el encabezado del bloque enviado por el retransmisor, lo que equivale a la vinculación entre el encabezado del bloque y el proponente, el retransmisor tiene motivos para creer que se propondrá el bloque del constructor. De lo contrario, sólo se puede obligar al proponente a abandonar el espacio o proponer un bloque diferente (lo que daría lugar a una barra diagonal). En este punto, el compromiso del proponente está garantizado por la seguridad económica de apostar/recortar.
*Aproximadamente, un principio importante en el diseño de ePBS es la "seguridad de publicación de constructores honestos", es decir, garantizar que se propongan bloques publicados por constructores honestos. Como PBS dentro del protocolo, ePBS se incorporará a la capa de consenso de Ethereum y estará garantizado por el protocolo.
PEPC es una extensión adicional de ePBS. ePBS promete que "se propondrá el bloque de construcción". Si esto se extiende a subastas de bloques parciales, subastas de bloques paralelas, subastas de bloques futuras, etc., podemos permitir que el proponente haga más cosas, y la capa de protocolo se asegura de que esas las cosas se hacen correctamente.
Existe una relación sutil entre PEPC y EigenLayer. No es difícil encontrar que existen algunas similitudes entre los casos de uso de PEPC mencionados anteriormente y los casos de uso de productor de bloques de EigenLayer. Sin embargo, una diferencia importante entre EigenLayer y PEPC es que los proponentes que participan en un nuevo compromiso todavía pueden teóricamente romper sus compromisos, aunque serán castigados financieramente; mientras que el enfoque de PEPC está en "aplicado por protocolo", es decir, en el protocolo capa Obligatorio se implementa en el bloque. Si la promesa no se puede ejecutar, el bloque no será válido.
(PD: a simple vista, es fácil encontrar que EigenDA es similar a Danksharding y MEV-Boost ++ es similar a ePBS. Estos dos servicios son como la versión optativa del diseño de la capa de protocolo. En comparación con la capa de protocolo, es una solución más rápida para el mercado, sigue el ritmo de lo que Ethereum hará en el futuro y mantiene la alineación de Ethereum mediante la repetición de apuestas).
¿No sobrecargar el consenso de Ethereum?
Hace unos meses, el artículo de Vitalik Don't Overload Ethereum Consensus fue considerado por la mayoría como una crítica a Restating. El autor cree que esto es sólo un recordatorio o advertencia para mantener el consenso social, y que la atención se centra en el consenso social en lugar de en la negación de volver a comprometerse.
En la infancia de Ethereum, el ataque DAO causó una gran controversia y la comunidad tuvo una acalorada discusión sobre si realizar una bifurcación dura. Hoy en día, el ecosistema Ethereum, incluido Rollup, ya alberga una gran cantidad de aplicaciones. Por lo tanto, es muy importante evitar causar grandes divisiones dentro de la comunidad y mantener la coherencia del consenso social.
Hermione crea una capa 2 exitosa y argumenta que debido a que su capa 2 es la más grande, es inherentemente la más segura, porque si hay un error que causa el robo de fondos, las pérdidas serán tan grandes que la comunidad no tendrá otra opción. sino bifurcar para recuperar los fondos de los usuarios. Alto riesgo.
La cita anterior del texto original es un buen ejemplo. Hoy en día, el TVL total de L2 supera los 10 mil millones de dólares estadounidenses, y si hay un problema, será extremadamente complicado. En este momento, si la comunidad propone implementar una bifurcación dura y revertir el estado, inevitablemente causará una gran controversia. Supongamos que usted y yo tenemos una gran suma de dinero, ¿cómo elegiremos: recuperar el dinero o respetar la inmutabilidad de la cadena de bloques? El punto de Vitalik es: los proyectos que dependen de Ethereum deben gestionar adecuadamente los riesgos y no deben intentar ganarse el consenso social de Ethereum y vincular fuertemente la vida o muerte del proyecto a Ethereum.
Volviendo a la discusión sobre EigenLayer, el enfoque de la gestión de riesgos es que AVS necesita definir reglas de reducción objetivas, en cadena y atribuibles para evitar desacuerdos. Por ejemplo, firma doble de bloques en Ethereum; firma de un bloque no válido de otra cadena en un puente entre cadenas basado en nodos ligeros; la prueba de depósito en garantía EigenDA analizada anteriormente, y más. Estas son reglas claras de decomiso.
Conclusión
![IOSG Ventures: una mirada a los últimos avances y casos de uso de EigenLayer en el campo de las "recompensaciones"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-fe74284cb5-dd1a6f -6d2ef1)
Fuente: Capa propia
Se espera que EigenLayer complete el lanzamiento de la red principal a principios del próximo año y lance su producto estrella EigenDA. Muchos proyectos de infraestructura han anunciado su cooperación con EigenLayer. Hablamos de EigenDA, MEV y PEPC anteriormente, y hay muchas discusiones interesantes en curso sobre diferentes casos de uso. La rehipotecación se está convirtiendo en una de las narrativas dominantes en el mercado. ¡Continuaremos siguiendo el progreso de EigenLayer y compartiremos cualquier opinión!
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
IOSG Ventures: descripción general de los últimos avances y casos de uso de EigenLayer en el campo del "re-stake"
Autor original: Jiawei, IOSG Ventures
Fuente: Capa propia
En noviembre pasado, presentamos EigenLayer en este artículo "EigenLayer: Llevando la confianza a nivel de Ethereum al middleware". Durante casi un año, EigenLayer publicó su documento técnico, completó una ronda de financiación Serie A de 50 millones de dólares y lanzó la primera fase de la red principal. Durante este período, la comunidad Ethereum también mantuvo extensos debates sobre EigenLayer y sus casos de uso. Este artículo rastreará y clasificará estas discusiones.
fondo
En el ecosistema Ethereum, algunos servicios de middleware (como los oráculos) no dependen completamente de la lógica en cadena, por lo que no pueden depender directamente del consenso y la seguridad de Ethereum y necesitan redirigir la red de confianza. El enfoque habitual es operar primero el proyecto, luego introducir incentivos simbólicos para atraer participantes del sistema y lograr gradualmente la descentralización.
Hay al menos dos dificultades al hacer esto. Una es que la introducción de un mecanismo de incentivos requiere costos adicionales: el costo de oportunidad para que los participantes compren tokens para participar en el compromiso y el costo operativo para que la parte del proyecto mantenga el valor de los tokens. En segundo lugar, incluso si se pagan los costos anteriores y se construye una red descentralizada, aún se desconocen su seguridad y sostenibilidad. Estos dos puntos son especialmente complicados para proyectos de nueva creación.
La idea de EigenLayer es proporcionar seguridad económica para estos middleware (Servicios validados activamente, AVS) mediante la reapropiación por parte de los participantes de Ethereum existentes. Si estos nuevos contribuyentes trabajan honestamente, pueden ser recompensados, pero si hacen el mal, perderán su exposición original a la promesa de Ethereum.
Las ventajas de esto son: en primer lugar, la parte del proyecto no necesita guiar la nueva red de confianza por sí misma, sino que la subcontrata a validadores de Ethereum, reduciendo los costos de capital tanto como sea posible; en segundo lugar, la seguridad económica del conjunto de validadores de Ethereum es muy sólido, por lo que la seguridad también ha sido garantizada hasta cierto punto. Desde la perspectiva de los contribuyentes de Ethereum, volver a comprometerse les proporciona ingresos adicionales. Siempre que no exista una intención maliciosa subjetiva, el riesgo general es controlable.
Sreeram, el fundador de EigenLayer, mencionó una vez los tres casos de uso y modelos de confianza de EigenLayer en Twitter y podcasts:
Participantes del sistema
![IOSG Ventures: una mirada a los últimos avances y casos de uso de EigenLayer en el campo de la "re-promesa"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-c0a688f2e8-dd1a6f -6d2ef1)
Fuente: IOSG Ventures
EigenLayer sirve como un mercado abierto que conecta a los tres actores principales.
*Re-promesas. Si tiene exposición a la apuesta de Ethereum, puede participar transfiriendo las credenciales de retiro a EigenLayer para participar en la nueva apuesta, o simplemente depositar LST como stETH para participar. Los re-stakeers también pueden delegar su exposición a los operadores si no pueden ejecutar un nodo AVS por sí mismos.
Con estos conceptos básicos en mente, veamos los casos de uso específicos de EigenLayer.
DA propia
EigenDA es el producto estrella lanzado por EigenLayer y la solución se deriva de Danksharding, la solución de expansión de Ethereum. Entre ellos, el muestreo de disponibilidad de datos (DAS) también se utiliza ampliamente en proyectos DA como Celestia y Avail. En este capítulo damos una introducción rápida a DAS y luego analizamos la implementación de EigenDA y sus innovaciones.
![IOSG Ventures: una mirada a los últimos avances y casos de uso de EigenLayer en el campo de la "recomprometida"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-7417ebaed1-dd1a6f -6d2ef1)
Fuente: Dankrad Feist
Como solución inicial para Danksharding, EIP-4844 introduce la "transacción portadora de blobs": cada transacción transportará un tamaño de datos adicional de aproximadamente 125 kb. En el contexto de la ruta de expansión de la fragmentación de datos, los nuevos datos sin duda aumentarán la carga sobre los nodos. Entonces, ¿hay alguna manera de hacer que el nodo descargue solo una pequeña parte de los datos y también verificar que todos los datos estén disponibles?
Lo que hace DAS es permitir que los nodos muestreen aleatoriamente una pequeña parte de los datos varias veces. Cada muestreo exitoso aumenta la confianza del nodo en que los datos están disponibles y, una vez que se alcanza un cierto nivel preestablecido, los datos se consideran disponibles. Sin embargo, todavía es posible que un atacante oculte una pequeña parte de los datos; también necesitamos algún tipo de tolerancia a fallos.
DAS utiliza codificación de borrado (Erasure Coding). La idea principal de la codificación de borrado es dividir los datos en varios bloques y luego codificar estos bloques, generando bloques redundantes adicionales. Estos bloques redundantes contienen parte de la información de los bloques de datos originales, de modo que cuando algunos bloques de datos se pierden o dañan, los bloques de datos perdidos se pueden recuperar a través de los bloques redundantes. De esta manera, la codificación de borrado proporciona redundancia y confiabilidad para DAS.
Además, también debemos verificar si los bloques redundantes resultantes están codificados correctamente, porque los datos originales no se pueden reconstruir con un bloque redundante incorrecto. Danksharding utiliza compromisos KZG (Kate-Zaverucha-Goldberg). El compromiso KZG es un método para verificar un polinomio, que puede demostrar que el valor del polinomio en una posición específica es consistente con el valor especificado.
El probador elige un polinomio p(x) y usa p(x) para calcular un compromiso para cada bloque de datos, llamado C1, C2, ..., Cm. El probador publicará el compromiso junto con el bloque de datos. Para verificar una codificación, el verificador puede muestrear aleatoriamente t puntos x 1, x 2, ..., xt y pedirle al probador que abra compromisos en estos puntos: p(x 1), p(x 2), ..., p(xt). Utilizando la interpolación lagrangiana, el verificador puede reconstruir el polinomio p(x) a partir de estos t puntos. El verificador ahora puede volver a calcular los compromisos C 1', C 2', ..., Cm' utilizando el polinomio reconstruido p(x) y el bloque de datos y verificar que coincidan con los compromisos publicados C 1, C 2, ... , Cm coincide.
En resumen, al utilizar los compromisos de KZG, los verificadores solo necesitan una pequeña cantidad de puntos para verificar la exactitud de toda la codificación. De esta forma conseguimos un DAS completo.
Fuente: Capa propia
EigenLayer toma prestadas ideas de DAS y las aplica a EigenDA.
Primero, los nodos de EigenDA se vuelven a pignorar y registrar en el contrato EigenLayer.
En segundo lugar, una vez que el secuenciador obtiene los datos, los divide en varios bloques, utiliza códigos de borrado para generar bloques redundantes y calcula el compromiso KZG correspondiente a cada bloque de datos. Sequencer publica los compromisos de KZG uno por uno en el contrato EigenDA como testigo.
Posteriormente, el secuenciador distribuye el bloque de datos junto con su compromiso KZG a cada nodo EigenDA uno por uno. Después de que el nodo obtiene el compromiso KZG, lo compara con el compromiso KZG en el contrato EigenDA, almacena el bloque de datos después de confirmar que es correcto y lo firma.
Luego, el secuenciador recopila estas firmas, genera firmas agregadas y las publica en el contrato EigenDA, y el contrato EigenDA verifica las firmas. Una vez que se verifica que la firma es correcta, se completa todo el proceso.
En el proceso anterior, el nodo EigenDA solo afirma haber almacenado el bloque de datos mediante firmas. También necesitamos una forma de garantizar que el nodo EigenDA no mienta. EigenDA adopta Prueba de Custodia.
La idea de la prueba de depósito en garantía es poner una "bomba" en los datos y, una vez que el nodo los firme, se cortarán. Para implementar la prueba de custodia, es necesario diseñar: un valor secreto para distinguir diferentes nodos DA para evitar trampas; una función específica para el nodo DA, tomando los datos DA y el valor secreto como entrada, y la presencia o ausencia de bombas como salida. Si el nodo no almacena los datos completos que se supone que debe almacenar, esta función no se puede calcular. Dankrad ha compartido más detalles sobre la Prueba de depósito en garantía en su blog.
![IOSG Ventures: Una mirada a los últimos avances y casos de uso de EigenLayer en el campo de las "repropuestas"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-5e2b72172c-dd1a6f-6d2ef1 )
Fuente: Capa propia
Si hay un nodo diferido, cualquiera puede enviar una prueba al contrato EigenDA, y el contrato verificará la prueba, y si se pasa la verificación, el nodo diferido será multado.
En términos de requisitos de hardware, el compromiso de KZG de calcular 32 MB de datos en 1 segundo requiere aproximadamente entre 32 y 64 CPU de núcleo, pero este requisito es solo para el lado del secuenciador y no impondrá una carga al nodo EigenDA. En la red de prueba de EigenDA, el rendimiento de 100 nodos de EigenDA alcanzó los 15 MB/s, mientras que la demanda de ancho de banda de descarga de los nodos fue de sólo 0,3 MB/s (mucho menor que los requisitos para ejecutar validadores de Ethereum).
En resumen, podemos ver que EigenDA logra desacoplar la disponibilidad de datos y el consenso, y la propagación de bloques de datos ya no está limitada por el cuello de botella del protocolo de consenso y el bajo rendimiento de la red P2P. Porque EigenDA es equivalente a un viaje gratis en el consenso de Ethereum: el proceso de Sequencer que emite compromisos KZG y firmas agregadas, verifica firmas mediante contratos inteligentes y castiga a los nodos maliciosos ocurren en Ethereum, y Ethereum proporciona garantías de consenso, por lo que no hay necesidad. para reiniciar la red de confianza.
Actualmente, DAS como tecnología en sí tiene algunas limitaciones. Debemos asumir que una contraparte maliciosa intentará engañar a los nodos ligeros para que acepten datos falsos por cualquier medio posible. Sreeram declaró lo siguiente en su tweet.
Para que un solo nodo tenga una probabilidad suficientemente alta de que los datos estén disponibles, se deben cumplir los siguientes requisitos:
Podemos permitir que múltiples nodos ligeros realicen un muestreo aleatorio para satisfacer la concurrencia y la aleatoriedad, pero actualmente no existe una buena manera de satisfacer el muestreo de IP privado. Por lo tanto, todavía existen vectores de ataque contra DAS, por lo que actualmente DAS sólo ofrece garantías débiles. Estos problemas todavía se están resolviendo activamente.
Capa propia y MEV
![IOSG Ventures: una lista de los últimos avances y casos de uso de EigenLayer en el campo de las "nuevas promesas"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-56389daf61-dd1a6f-6d2ef1 )
Fuente: Capa propia
Sreeram habló sobre el uso de EigenLayer en la pila MEV en la Cumbre MEVconomics. Con base en las primitivas criptoeconómicas de apostar y recortar, los proponentes pueden implementar las siguientes cuatro características, que son el tercer punto mencionado anteriormente: el caso de uso del compromiso del validador.
Activación basada en eventos
Protocolos como Gelato pueden reaccionar a eventos específicos en cadena. Es decir, monitoreo continuo de eventos en la cadena, y una vez que ocurre un evento, se activan algunas operaciones predefinidas, que generalmente las completan oyentes/ejecutores de terceros.
Se llama "tercero" porque no existe conexión entre el oyente/ejecutor y el proponente que realmente maneja el espacio del bloque. Supongamos que un oyente/ejecutor desencadena una transacción pero (por alguna razón) un proponente no lo incluye en un bloque, lo que no se puede atribuir y, por lo tanto, no ofrece garantías económicas deterministas.
Si los proponentes participantes brindan este servicio, pueden asumir compromisos creíbles para la activación de operaciones, y si estas transacciones finalmente no se incluyen en el bloque, el proponente queda eliminado. Esto proporciona garantías más sólidas que los oyentes/ejecutores de terceros.
En aplicaciones prácticas (como los protocolos de préstamos), uno de los propósitos de fijar la tasa de sobregarantía es cubrir las fluctuaciones de precios dentro de un cierto rango de tiempo. Esto está relacionado con el período de tiempo previo a la liquidación, y una tasa de sobregarantía más alta significa un período de amortiguación más largo. Si una gran proporción de transacciones adopta una estrategia reactiva impulsada por eventos y cuenta con sólidas garantías proporcionadas por los proponentes, entonces (para activos altamente líquidos) la volatilidad de la tasa de sobrecolateralización puede limitarse a unos pocos intervalos de bloques, reduciendo así el exceso de colateralización. -tasa de garantía y mejora de la eficiencia del capital.
Subasta en bloque parcial
En el diseño actual de MEV-Boost, el proponente subcontrata completamente el espacio del bloque al constructor y solo puede recibir y proponer pasivamente todo el bloque presentado por el constructor. Hay solo un puñado de constructores en comparación con los proponentes más distribuidos, y pueden confabularse para censurar y extorsionar transacciones específicas, porque los proponentes no pueden incluir las transacciones que desean en MEV-Boost.
![IOSG Ventures: descripción general de los últimos avances y casos de uso de EigenLayer en el campo de las "nuevas promesas"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-acfbe6d8dc-dd1a6f-6d2ef1)
Fuente: Capa propia
EigenLayer propuso MEV-Boost++ para actualizar MEV-Boost e introdujo la parte del Proponente en el bloque. El proponente puede incluir cualquier transacción en la parte del Proponente. El proponente también puede construir un bloque B-alt alternativo al mismo tiempo y proponer este bloque alternativo B-alt si el relé no libera Builder_part. Esta flexibilidad garantiza la resistencia a la censura y al mismo tiempo resuelve el problema de la vitalidad del relevo.
Fuente: Dankrad Feist
Esto es consistente con el propósito del diseño de la capa de protocolo: la crList propuesta por ePBS, es decir, debemos asegurarnos de que una amplia gama de proponentes puedan participar en la decisión de la composición de los bloques para lograr la anticensura.
Cifrado de umbral
En la solución MEV basada en cifrado de umbral, las claves de cifrado y descifrado son gestionadas por un grupo de nodos distribuidos. Los usuarios cifran las transacciones, que se descifran y ejecutan después de incluirlas en un bloque.
Sin embargo, el cifrado de umbral se basa en el supuesto de honestidad mayoritaria. Si la mayoría de los nodos actúan mal, es posible que las transacciones descifradas no se incluyan en el bloque. Los proponentes de volver a apostar pueden asumir un compromiso creíble con la transacción cifrada para garantizar su inclusión en el bloque. Si el proponente no incluye la transacción descifrada, se eliminará. Por supuesto, si una mayoría maliciosa de nodos no libera la clave de descifrado, el proponente puede proponer un bloque vacío.
Subasta de Blockspace a largo plazo
Las subastas de espacios de bloques a largo plazo permiten a los compradores de espacios de bloques reservar por adelantado espacios de bloques futuros para un validador. Los validadores que participan en el re-stake pueden asumir compromisos creíbles y se perderán si no incluyen la transacción del comprador cuando expire. Esta garantía de acceso al espacio en bloque tiene algunos casos de uso práctico. Por ejemplo, la máquina Oracle necesita alimentar los precios en un cierto período de tiempo; Arbitrum publica datos L2 en Ethereum L1 cada 1-3 minutos, Optimism cada 30 segundos-1 minuto, y así sucesivamente.
##PEPC
![IOSG Ventures: una mirada a los últimos avances y casos de uso de EigenLayer en el campo de la "re-promestación"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-a2677d5154-dd1a6f -6d2ef1)
Fuente: Barnabé Monnot
Volvamos al PEPC (Compromiso del proponente aplicado por protocolo), que ha sido ampliamente discutido recientemente en la comunidad Ethereum. PEPC es en realidad la promoción o generalización de ePBS.
Desmontemos esta cadena lógica una por una.
Existe una relación sutil entre PEPC y EigenLayer. No es difícil encontrar que existen algunas similitudes entre los casos de uso de PEPC mencionados anteriormente y los casos de uso de productor de bloques de EigenLayer. Sin embargo, una diferencia importante entre EigenLayer y PEPC es que los proponentes que participan en un nuevo compromiso todavía pueden teóricamente romper sus compromisos, aunque serán castigados financieramente; mientras que el enfoque de PEPC está en "aplicado por protocolo", es decir, en el protocolo capa Obligatorio se implementa en el bloque. Si la promesa no se puede ejecutar, el bloque no será válido.
(PD: a simple vista, es fácil encontrar que EigenDA es similar a Danksharding y MEV-Boost ++ es similar a ePBS. Estos dos servicios son como la versión optativa del diseño de la capa de protocolo. En comparación con la capa de protocolo, es una solución más rápida para el mercado, sigue el ritmo de lo que Ethereum hará en el futuro y mantiene la alineación de Ethereum mediante la repetición de apuestas).
¿No sobrecargar el consenso de Ethereum?
Hace unos meses, el artículo de Vitalik Don't Overload Ethereum Consensus fue considerado por la mayoría como una crítica a Restating. El autor cree que esto es sólo un recordatorio o advertencia para mantener el consenso social, y que la atención se centra en el consenso social en lugar de en la negación de volver a comprometerse.
En la infancia de Ethereum, el ataque DAO causó una gran controversia y la comunidad tuvo una acalorada discusión sobre si realizar una bifurcación dura. Hoy en día, el ecosistema Ethereum, incluido Rollup, ya alberga una gran cantidad de aplicaciones. Por lo tanto, es muy importante evitar causar grandes divisiones dentro de la comunidad y mantener la coherencia del consenso social.
Hermione crea una capa 2 exitosa y argumenta que debido a que su capa 2 es la más grande, es inherentemente la más segura, porque si hay un error que causa el robo de fondos, las pérdidas serán tan grandes que la comunidad no tendrá otra opción. sino bifurcar para recuperar los fondos de los usuarios. Alto riesgo.
La cita anterior del texto original es un buen ejemplo. Hoy en día, el TVL total de L2 supera los 10 mil millones de dólares estadounidenses, y si hay un problema, será extremadamente complicado. En este momento, si la comunidad propone implementar una bifurcación dura y revertir el estado, inevitablemente causará una gran controversia. Supongamos que usted y yo tenemos una gran suma de dinero, ¿cómo elegiremos: recuperar el dinero o respetar la inmutabilidad de la cadena de bloques? El punto de Vitalik es: los proyectos que dependen de Ethereum deben gestionar adecuadamente los riesgos y no deben intentar ganarse el consenso social de Ethereum y vincular fuertemente la vida o muerte del proyecto a Ethereum.
Volviendo a la discusión sobre EigenLayer, el enfoque de la gestión de riesgos es que AVS necesita definir reglas de reducción objetivas, en cadena y atribuibles para evitar desacuerdos. Por ejemplo, firma doble de bloques en Ethereum; firma de un bloque no válido de otra cadena en un puente entre cadenas basado en nodos ligeros; la prueba de depósito en garantía EigenDA analizada anteriormente, y más. Estas son reglas claras de decomiso.
Conclusión
![IOSG Ventures: una mirada a los últimos avances y casos de uso de EigenLayer en el campo de las "recompensaciones"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-fe74284cb5-dd1a6f -6d2ef1)
Fuente: Capa propia
Se espera que EigenLayer complete el lanzamiento de la red principal a principios del próximo año y lance su producto estrella EigenDA. Muchos proyectos de infraestructura han anunciado su cooperación con EigenLayer. Hablamos de EigenDA, MEV y PEPC anteriormente, y hay muchas discusiones interesantes en curso sobre diferentes casos de uso. La rehipotecación se está convirtiendo en una de las narrativas dominantes en el mercado. ¡Continuaremos siguiendo el progreso de EigenLayer y compartiremos cualquier opinión!