El año pasado, 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 su 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. La práctica habitual es operar primero el proyecto y luego introducir incentivos simbólicos para atraer participantes del sistema y lograr gradualmente la descentralización.
Hay al menos dos dificultades para hacerlo. Una es que la introducción de un mecanismo de incentivo requiere costos adicionales: el costo de oportunidad para que los participantes compren tokens para participar en el compromiso, y los costos operativos para que la parte del proyecto mantenga el valor de los tokens. . En segundo lugar, incluso si se pagan los costos mencionados anteriormente y se construye una red descentralizada, aún se desconocen su seguridad y sostenibilidad. Para proyectos de nueva creación, estos dos puntos son particularmente complicados.
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 al verificador de Ethereum, lo que reduce el costo de capital tanto como sea posible; en segundo lugar, la seguridad económica del verificador de Ethereum. El conjunto es muy fuerte, por lo que la seguridad también está 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 en algunos servicios (como el intercambio de secretos) no sea atribuible, lo que hace imposible confiar en un mecanismo de reducción. Es necesario que haya un grupo 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
EigenLayer actúa como un mercado abierto, conectando a tres actores principales.
Re-Pledger. Si tiene exposición a la apuesta de Ethereum, puede participar en la nueva apuesta transfiriendo las credenciales de retiro a EigenLayer o simplemente depositando LST como stETH para participar. Si una nueva parte interesada no puede ejecutar un nodo AVS por sí misma, también puede delegar su exposición a un operador.
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. AVS, como demandante/consumidor, necesita pagar a los rehipotecadores y recibir la seguridad económica que estos le proporcionan.
Con estos conceptos básicos, veamos los casos de uso específicos de EigenLayer.
#EigenDA
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 daremos una introducción rápida a DAS y luego veremos cómo se implementa EigenDA y sus innovaciones.
EL
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 solo descargue una pequeña parte de los datos y también verificar que todos los datos estén disponibles?
El enfoque DAS consiste en permitir que los nodos muestreen aleatoriamente una pequeña parte de los datos varias veces. Cada muestreo exitoso aumentará la confianza de que el nodo cree que los datos están disponibles. 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 mecanismo 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 fragmentos y luego codificarlos para generar fragmentos 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 al DAS.
Además, también debemos verificar si los bloques redundantes resultantes están codificados correctamente, porque los datos originales no se pueden reconstruir utilizando bloques redundantes incorrectos. Danksharding adopta el compromiso KZG (Kate-Zaverucha-Goldberg). El compromiso KZG es un método para verificar un polinomio demostrando que su valor en una ubicación específica es consistente con un valor numérico específico.
El probador elige un polinomio p(x) y usa p(x) para calcular los compromisos para cada bloque de datos, llamado C1, C2,..., Cm. El probador publicará el compromiso junto con el bloque de datos. Para verificar la codificación, el verificador puede muestrear aleatoriamente t puntos x1, x2, ..., xt y pedirle al probador que abra compromisos en estos puntos: p(x1), p(x2), ..., 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 C1', C2', ..., Cm' utilizando el polinomio reconstruido p(x) y el bloque de datos y verificar que coincidan con los compromisos publicados C1, C2, ..., Cm.
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 obtenemos el DAS completo.
Cómo
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, después de obtener los datos, el secuenciador los divide en varios bloques, utiliza codificación 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 realizar la prueba de depósito en garantía, es necesario diseñar: un valor secreto para distinguir diferentes nodos DA para evitar trampas; una función específica para los nodos DA, que toma los datos DA y el valor secreto como entrada, y si hay una bomba 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.
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, KZG promete entre 32 y 64 núcleos de CPU para calcular 32 MB de datos en 1 segundo, 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 nodos es de solo 0,3 MB/s (mucho menor que los requisitos para ejecutar validadores de Ethereum).
** En resumen, podemos ver que EigenDA ha logrado 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 equivale a aprovechar el consenso de Ethereum: el proceso de Sequencer que emite compromisos KZG y firmas agregadas, verifica firmas mediante contratos inteligentes y elimina nodos maliciosos, todo ocurre en Ethereum, y Ethereum proporciona garantías de consenso, por lo que no hay Es necesario reiniciar la red de confianza. **
Problemas del DAS
Actualmente, DAS como tecnología en sí tiene algunas limitaciones. Debemos asumir que las contrapartes maliciosas utilizarán todos los medios posibles para engañar a los nodos ligeros para que acepten datos falsos. Sreeram había elaborado 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: cada nodo debe seleccionar de forma independiente y aleatoria un conjunto 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 varios nodos realicen DAS simultáneamente, lo que hace imposible que un atacante distinga 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
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) el proponente no lo incluye en el bloque. Esto no se puede atribuir y, por lo tanto, no puede aportar garantías económicas deterministas.
Si este servicio lo proporcionan los proponentes que participan en la recuperación, pueden asumir compromisos creíbles para la activación de operaciones, y si estas transacciones no están incluidas en el bloque, el proponente queda eliminado. Esto proporciona garantías más sólidas en comparación con 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 la ventana de tiempo antes de la liquidación, un índice de sobregarantía más alto significa un período de amortiguación más largo. Si la mayoría de las transacciones adoptan una estrategia de reacción basada en eventos con fuertes garantías proporcionadas por el proponente, entonces (para activos líquidos) la volatilidad del índice de sobregarantía puede limitarse a unos pocos intervalos de bloques, reduciendo así la tasa de sobregarantía y mejorando. 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.
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 alternativo B-alt al mismo tiempo y proponer este bloque alternativo B-alt cuando el relé no libera Builder_part. Esta flexibilidad no sólo garantiza la resistencia a la censura, sino que también resuelve el problema de la vitalidad del relevo.
Esto es consistente con el diseño de la capa de protocolo: el propósito de crList propuesto por ePBS, es decir, debemos garantizar que una amplia gama de proponentes puedan participar en la decisión de la composición del bloque para lograr la resistencia a la censura.
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 son defectuosos, es posible que la transacción descifrada no se incluya 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
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.
Rompamos 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, el proponente sólo se verá obligado a ceder el espacio o proponer un bloque diferente (lo que resultará en una reducción). En este momento, el compromiso del proponente está garantizado por la seguridad económica de apostar/cortar.
*Aproximadamente, un principio importante en el diseño de ePBS es la "seguridad de publicación de constructores honestos", que garantiza que se propondrán 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 promoció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 nuevas promesas de promesa aún pueden, en teoría, violar sus compromisos, aunque serán castigados financieramente; mientras que PEPC se centra en "Protocolo-aplicado", es decir, obligatorio se implementa en la capa de protocolo. 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 sobrecargues 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. La atención se centra en el consenso social, no en la negación de un nuevo compromiso.
En la infancia de Ethereum, el ataque DAO causó una gran controversia y la comunidad tuvo una acalorada discusión sobre si realizar un hard fork. Hoy en día, el ecosistema Ethereum, incluido Rollup, ya ha incluido una gran cantidad de aplicaciones. Por tanto, es muy importante evitar provocar grandes desacuerdos 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. pero 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 y la 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 y otras similares son reglas claras de decomiso.
Conclusión
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.
EigenLayer: Re-stake introduce una revolución de confianza en el middleware
Fuente: IOSG Ventures
El año pasado, 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 su 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. La práctica habitual es operar primero el proyecto y luego introducir incentivos simbólicos para atraer participantes del sistema y lograr gradualmente la descentralización.
Hay al menos dos dificultades para hacerlo. Una es que la introducción de un mecanismo de incentivo requiere costos adicionales: el costo de oportunidad para que los participantes compren tokens para participar en el compromiso, y los costos operativos para que la parte del proyecto mantenga el valor de los tokens. . En segundo lugar, incluso si se pagan los costos mencionados anteriormente y se construye una red descentralizada, aún se desconocen su seguridad y sostenibilidad. Para proyectos de nueva creación, estos dos puntos son particularmente complicados.
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 al verificador de Ethereum, lo que reduce el costo de capital tanto como sea posible; en segundo lugar, la seguridad económica del verificador de Ethereum. El conjunto es muy fuerte, por lo que la seguridad también está 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
EigenLayer actúa como un mercado abierto, conectando a tres actores principales.
Con estos conceptos básicos, veamos los casos de uso específicos de EigenLayer.
#EigenDA
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 daremos una introducción rápida a DAS y luego veremos cómo se implementa EigenDA y sus innovaciones.
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 solo descargue una pequeña parte de los datos y también verificar que todos los datos estén disponibles?
El enfoque DAS consiste en permitir que los nodos muestreen aleatoriamente una pequeña parte de los datos varias veces. Cada muestreo exitoso aumentará la confianza de que el nodo cree que los datos están disponibles. 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 mecanismo 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 fragmentos y luego codificarlos para generar fragmentos 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 al DAS.
Además, también debemos verificar si los bloques redundantes resultantes están codificados correctamente, porque los datos originales no se pueden reconstruir utilizando bloques redundantes incorrectos. Danksharding adopta el compromiso KZG (Kate-Zaverucha-Goldberg). El compromiso KZG es un método para verificar un polinomio demostrando que su valor en una ubicación específica es consistente con un valor numérico específico.
El probador elige un polinomio p(x) y usa p(x) para calcular los compromisos para cada bloque de datos, llamado C1, C2,..., Cm. El probador publicará el compromiso junto con el bloque de datos. Para verificar la codificación, el verificador puede muestrear aleatoriamente t puntos x1, x2, ..., xt y pedirle al probador que abra compromisos en estos puntos: p(x1), p(x2), ..., 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 C1', C2', ..., Cm' utilizando el polinomio reconstruido p(x) y el bloque de datos y verificar que coincidan con los compromisos publicados C1, C2, ..., Cm.
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 obtenemos el DAS completo.
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, después de obtener los datos, el secuenciador los divide en varios bloques, utiliza codificación 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 realizar la prueba de depósito en garantía, es necesario diseñar: un valor secreto para distinguir diferentes nodos DA para evitar trampas; una función específica para los nodos DA, que toma los datos DA y el valor secreto como entrada, y si hay una bomba 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.
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, KZG promete entre 32 y 64 núcleos de CPU para calcular 32 MB de datos en 1 segundo, 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 nodos es de solo 0,3 MB/s (mucho menor que los requisitos para ejecutar validadores de Ethereum).
** En resumen, podemos ver que EigenDA ha logrado 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 equivale a aprovechar el consenso de Ethereum: el proceso de Sequencer que emite compromisos KZG y firmas agregadas, verifica firmas mediante contratos inteligentes y elimina nodos maliciosos, todo ocurre en Ethereum, y Ethereum proporciona garantías de consenso, por lo que no hay Es necesario reiniciar la red de confianza. **
Actualmente, DAS como tecnología en sí tiene algunas limitaciones. Debemos asumir que las contrapartes maliciosas utilizarán todos los medios posibles para engañar a los nodos ligeros para que acepten datos falsos. Sreeram había elaborado 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
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) el proponente no lo incluye en el bloque. Esto no se puede atribuir y, por lo tanto, no puede aportar garantías económicas deterministas.
Si este servicio lo proporcionan los proponentes que participan en la recuperación, pueden asumir compromisos creíbles para la activación de operaciones, y si estas transacciones no están incluidas en el bloque, el proponente queda eliminado. Esto proporciona garantías más sólidas en comparación con 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 la ventana de tiempo antes de la liquidación, un índice de sobregarantía más alto significa un período de amortiguación más largo. Si la mayoría de las transacciones adoptan una estrategia de reacción basada en eventos con fuertes garantías proporcionadas por el proponente, entonces (para activos líquidos) la volatilidad del índice de sobregarantía puede limitarse a unos pocos intervalos de bloques, reduciendo así la tasa de sobregarantía y mejorando. 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.
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 alternativo B-alt al mismo tiempo y proponer este bloque alternativo B-alt cuando el relé no libera Builder_part. Esta flexibilidad no sólo garantiza la resistencia a la censura, sino que también resuelve el problema de la vitalidad del relevo.
Esto es consistente con el diseño de la capa de protocolo: el propósito de crList propuesto por ePBS, es decir, debemos garantizar que una amplia gama de proponentes puedan participar en la decisión de la composición del bloque para lograr la resistencia a la censura.
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 son defectuosos, es posible que la transacción descifrada no se incluya 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
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.
Rompamos 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 nuevas promesas de promesa aún pueden, en teoría, violar sus compromisos, aunque serán castigados financieramente; mientras que PEPC se centra en "Protocolo-aplicado", es decir, obligatorio se implementa en la capa de protocolo. 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 sobrecargues 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. La atención se centra en el consenso social, no en la negación de un nuevo compromiso.
En la infancia de Ethereum, el ataque DAO causó una gran controversia y la comunidad tuvo una acalorada discusión sobre si realizar un hard fork. Hoy en día, el ecosistema Ethereum, incluido Rollup, ya ha incluido una gran cantidad de aplicaciones. Por tanto, es muy importante evitar provocar grandes desacuerdos 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. pero 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 y la 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 y otras similares son reglas claras de decomiso.
Conclusión
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!