A medida que aumenta el uso de acumulaciones y aloja las aplicaciones del ecosistema, los costos de migración para los usuarios aumentarán y los pedidos centralizados obtendrán una influencia monopólica sobre los precios. Los controladores de los pedidos centralizados están justificados para maximizar la extracción de valor (MEV) de los usuarios tanto directamente (p. ej., a través de tarifas) como indirectamente (p. ej., a través de transacciones anticipadas, ataques sándwich, etc.). - Café exprés
Como lo mencionó el equipo de Espresso, los paquetes acumulativos centralizados eventualmente enfrentarán problemas de precios de monopolio y MEV. Además, los resúmenes centralizados rompen inherentemente la componibilidad, lo que lleva a resúmenes fragmentados. **
Sin embargo, casi todos los paquetes acumulativos actuales todavía están centralizados, porque crear un paquete acumulativo escalable, sin permiso y descentralizado es extremadamente desafiante. Otra razón es que el lanzamiento centralizado de Rollups primero puede ayudar a incubar el ecosistema y ganar participación de mercado.
Y cuando hablamos de Rollups descentralizados, especialmente zkRollups, hay dos niveles de descentralización. La primera es la descentralización del probador, y la segunda es la descentralización del ordenante. Para lograr una descentralización completa, también es necesario resolver el problema de coordinación entre el ordenante y el probador.
Bajo la tendencia de la modularización, actualmente hay tres tipos principales de participantes en el Rollup descentralizado. La primera categoría tiene como objetivo lograr Rollups totalmente descentralizados y propone una solución completa. La segunda categoría son los protocolos diseñados para resolver redes de probadores. Finalmente, existen múltiples soluciones que están funcionando para descentralizar el clasificador.
Resúmenes descentralizados
En zkRollups, Polygon y Starknet han ideado soluciones para descentralizar sus Rollups.
Polígono
Antes de la introducción de POE (Prueba de eficiencia), Polygon zkEVM adoptó POD (Prueba de donación), lo que permitía al clasificador ofertar por la oportunidad de crear el siguiente lote de transacciones. Sin embargo, esto crea el problema de que una sola parte malintencionada puede controlar toda la red haciendo la oferta más alta.
Después de adoptar POE, el ordenante y el probador participarán en la red sin permiso de manera más eficiente bajo sus propias condiciones de hardware. Cualquiera puede unirse a Polygon zkEVM siempre que tenga sentido económico.
En Polygon zkEVM, el clasificador requiere 16 GB de RAM y una CPU de 4 núcleos, mientras que el probador requiere 1 TB de RAM y una CPU de 128 núcleos. Además, existe una función denominada agregador, que es responsable de recopilar datos de L1, enviarlos al probador, recibir la prueba y enviarla a L1. Podemos considerar al agregador y al probador como el mismo sujeto, porque la relación entre el agregador y el probador es muy simple, y el agregador le paga al probador para producir la prueba.
Esta arquitectura es muy simple: cualquier ordenante puede empaquetar transacciones basadas en el estado anterior en L1 sin permiso y actualizar el estado correspondiente. Al mismo tiempo, cualquier agregador puede enviar una prueba para verificar el estado actualizado.
En POE, la eficiencia se refiere no solo a la eficiencia de la red de los participantes que compiten entre sí, sino también a la eficiencia económica del secuenciador y del probador. En L2, el ordenante y el probador comparten la tarifa de transacción, y el ordenante paga la tarifa por lote al agregador para generar la prueba. Esto asegura que los participantes estén económicamente motivados para contribuir a la eficiencia de la red, lo que da como resultado un ecosistema más sólido y sostenible.
clasificador
Ingresos: tarifas de transacción L2
Costo: tarifa por lotes (calculada en $MATIC) + tarifa de transacción L1 (método de secuencia de llamadas por lotes)
Agregador (Probador)
Ingresos: batchFee (calculado en $MATIC)
Costo: costo de prueba + tarifa de transacción L1 (llame al método de verificarBatchesTrustedAggregator)
Coordinador: tarifa por lotes
parámetros iniciales
loteFee= 1 $MATIC
veryBatchTimeTarget = 30 minutos. Este es el tiempo objetivo para el lote de validación. El protocolo actualizará la variable batchFee para lograr este tiempo objetivo.
multiplicadorBatchFee = 1002. Este es el multiplicador de tarifas por lotes, que va de 1000 a 1024, con 3 decimales.
Regulador
diffBatches: el número de lotes agregados > 30 minutos menos el número de lotes <= 30 minutos. El valor máximo es 12.
Proceso de coordinación
Aumente la recompensa de agregación para incentivar a los agregadores cuando diffBatches > 0.
Cuando diffBatches < 0, reduzca la recompensa de agregación para suprimir el agregador y ralentizar el proceso de agregación.
Starknet
Starknet también tiene como objetivo construir un Rollup escalable y sin permiso de confirmación rápida. Si bien aún no se ha alcanzado la especificación final para la solución descentralizada, publicaron algunos borradores en el foro hace unos meses.
En comparación con el mecanismo simple de Polygon zkEVM, el esquema de Starknet es más complicado porque incluye consenso L2 y prueba de protocolo encadenada en la red de prueba.
clasificador
En lugar de simplemente agregar una capa de consenso dentro de la capa de pedidos, Starknet propone un protocolo de consenso de doble libro mayor. En este protocolo, L2 proporciona una respuesta rápida como protocolo en vivo, mientras que los puntos de control de L1 brindan una confirmación final como protocolo seguro.
Para el protocolo en vivo de L2, se pueden adoptar varios mecanismos de consenso, como sistemas PoS resistentes a Sybil, como Tendermint o DAG. Por otro lado, el protocolo seguro de L1 implica múltiples contratos que manejan la gestión de Stake, la verificación de pruebas y la actualización de estado, respectivamente.
El flujo de trabajo típico del acuerdo de consenso de doble libro mayor es el siguiente:
Primero, use la salida del libro mayor vivo L2 como la entrada del libro mayor seguro L1 para generar un libro mayor vivo verificado.
Luego, tome el libro mayor en vivo verificado como entrada e ingréselo nuevamente en el protocolo de consenso puro de L2 para asegurarse de que el libro mayor en vivo verificado sea siempre el prefijo del libro mayor en vivo.
Repita el proceso anterior.
Al crear un protocolo de consenso de doble libro mayor, existe una compensación entre el costo y la latencia. La solución ideal tiene como objetivo lograr una aprobación final rápida y de bajo costo.
Para reducir los costos de gas en L2, Starknet divide los puntos de control en "nivel de minutos" y "nivel de horas". Para los puntos de control de "nivel de minuto", solo el estado en sí está comprometido con la cadena, mientras que el resto de los datos (pruebas de validez, disponibilidad de datos, etc.) se envía a través de la red StarkNet L2. Estos datos son almacenados y verificados por los nodos completos de StarkNet. Por otro lado, los puntos de control "por hora" se validan públicamente en L1. Ambos tipos de puntos de control proporcionan la misma confirmación final. Para los puntos de control de "nivel de minutos", la prueba de validez es verificada por los nodos completos de StarkNet y puede ser emitida por cualquier nodo en L1 para dar la finalidad de L1 a los puntos de control de "nivel de minutos". Por lo tanto, el probador necesita generar pequeñas pruebas para ser ampliamente difundidas en la red L2.
Para reducir aún más la latencia, Starknet propone un protocolo de elección de líder para determinar el líder por adelantado. La lógica básica es la siguiente: el líder de la época actual i está predeterminado en función de la cantidad de L1 apostada y cierta aleatoriedad. Específicamente, en la época i-2, el método de elección de líder en mosaico lexicográficamente a los clasificadores en función de la cantidad de promesas en la época i-3. Luego, envíe una transacción para actualizar el nonce y elija un punto al azar. El clasificador correspondiente a la posición donde cae el punto será el líder de la época i.
Certificador
Bajo el módulo POE, existe una competencia abierta entre los participantes, lo que puede conducir a una situación en la que el ganador se lo lleva todo. Starknet intenta lograr un mecanismo de competencia sin riesgo de centralización. Aquí hay algunas opciones:
Rotación: Esto puede resolver en parte el problema de centralización, pero puede no proporcionar incentivos para encontrar a la mejor persona para probar el trabajo.
Basado en apuestas: el clasificador determina la probabilidad de ser elegido como probador en función de la cantidad que apuesta.
Esquema de compromiso-revelación: el primer compromiso debe prometer tokens para obtener una oportunidad de monopolio breve y luego generar pruebas dentro de esta ventana de tiempo. Para evitar ataques DDoS, si el primero no puede generar pruebas a tiempo, los tokens colaterales requeridos por el segundo aumentarán exponencialmente. Aunque bajo este mecanismo, la red puede perder la máquina con el mejor rendimiento, pero se pueden cultivar más probadores.
Además de la competencia entre probadores, la barrera de entrada debe reducirse para que más probadores puedan participar en la red. Starknet propone un protocolo complejo que utiliza pruebas recursivas llamadas pruebas de protocolo encadenadas.
En los protocolos de prueba de cadena, la propia cadena de bloques se divide en varias bifurcaciones diferentes. De esta manera, las pruebas no solo pueden ser recursivas, sino que la generación de pruebas también puede ser concurrente. Por ejemplo, en una configuración de 3 ramas, 12 bloques negros se dividen en 3 filas, cada fila representa una rama. Podemos pensar en cada rama como una subcadena donde cada bloque debe dar fe del bloque anterior. Desde el punto de vista de toda la cadena, la ranura n necesita probar la ranura n-3. El intervalo de 3 bloques permite suficiente tiempo para que el ordenante calcule y compre las pruebas por adelantado. Esto es algo similar a la fragmentación, donde un atacante solo necesita controlar una rama para controlar toda la red de probadores.
Para unir estas ramas, Starknet propone una tecnología de tejido que puede fusionar múltiples nodos para verificar conjuntamente la legitimidad de las transacciones y garantizar la consistencia y confiabilidad de los registros de transacciones.
Una solución es exigir que cada ranura se fusione con varias sucursales al mismo tiempo. Otra solución es intentar alternativamente que cada rama se fusione con otras ramas, reduciendo así la carga de trabajo de la prueba. Por supuesto, este también es un problema abierto, y puede haber mejores soluciones en el futuro.
coordinación
Para garantizar activamente que el probador pueda tener suficiente espacio de ganancias, Starknet propone un método para referirse al esquema EIP1559: establezca la tarifa base como el límite inferior del precio del recurso del probador, realice activamente el descubrimiento de precios y el clasificador puede usar consejos para motivar al experimentador. De esta manera, el probador siempre recibirá un sobrepago y solo los casos extremos afectarán el proceso de prueba. De lo contrario, si al probador se le paga cerca del precio de mercado, una ligera fluctuación podría desencadenar un bloqueo del probador.
Descentralización de certificadores
Desde la perspectiva de los Rollups, es más fácil lograr la descentralización en el probador que en el clasificador. Además, el probador actual es un cuello de botella en el rendimiento y debe mantenerse al día con la velocidad de dosificación del clasificador. Cuando no se ha resuelto la descentralización del clasificador, el probador descentralizado también puede prestar servicios para el clasificador centralizado.
De hecho, no solo los Rollups, zkBridge y zkOracle también necesitan una red de probadores. Todos ellos requieren una fuerte red distribuida de probadores.
A la larga, una red de probadores que puede acomodar diferentes potencias informáticas es más sostenible; de lo contrario, las máquinas con mejor rendimiento monopolizarán el mercado.
Mercado de prueba
Algunos protocolos no coordinan la relación entre el secuenciador y el probador, sino que abstraen directamente la coordinación en un mercado de pruebas. En este mercado, las pruebas son mercancías, los probadores son productores de pruebas y los protocolos son consumidores de pruebas. El equilibrio del mercado es más eficiente bajo la influencia de la "mano invisible".
Mío
Mina ha establecido un mercado de pruebas llamado Snarketplace donde se comercializan las pruebas de Snark. La unidad más pequeña aquí es la prueba de Snark de una sola transacción. Mina emplea un árbol recursivo de prueba de estado llamado Scan State.
Scan State es un bosque de árboles binarios donde cada transacción es un nodo. Se genera una sola prueba en la parte superior del árbol que puede probar todas las transacciones en el árbol. El probador tiene dos tareas: la primera es generar pruebas y la segunda es fusionar pruebas.
Después de que el probador complete el trabajo y presente la oferta, el productor de bloques del protocolo Mina seleccionará al postor con el precio más bajo. Este es también el precio de equilibrio, ya que los postores presentarán ofertas por encima del costo de las pruebas, y los productores de bloques no comprarán pruebas que no valgan la pena.
=Nada; Base
El mercado de prueba de Mina está diseñado para su propio protocolo, mientras que =nil; Foundation propone un mercado de prueba general para servir a todo el mercado.
El servicio de mercado consta de tres componentes: DROP DATABASE, zkLLVM y Proof Market.
DROP DATABASE: Es un protocolo de sistema de gestión de bases de datos, que puede considerarse como una capa DA.
Proof Market: es una aplicación que se ejecuta en DROP DATABASE, similar a lo que algunos llaman un "intercambio descentralizado" a prueba de zk.
zkLLVM: es un compilador que convierte lenguajes de programación de alto nivel en entradas para protocolos de computación comprobables.
Cada prueba consta de sus diferentes entradas y circuitos, por lo que cada prueba es única. Un circuito define un tipo de prueba, similar a cómo se define un "par de transacciones" en términos financieros. Además, diferentes sistemas de prueba introducen más circuitos.
El flujo de trabajo es el siguiente: el lado de la demanda de la prueba puede escribir código en un lenguaje de programación de alto nivel, luego enviarlo a =nil;zkLLVM a través de la cadena de herramientas, generando un circuito único que se convertirá en un par comercial único en el mercado.
Por el lado de la demanda de prueba, pueden hacer una compensación entre costo y tiempo. Los probadores también considerarán su poder de cómputo e ingresos. Por lo tanto, en el mercado habrá diferentes potencias de cómputo, alta potencia de cómputo generará pruebas más rápido, pero a un costo mayor, mientras que baja potencia de cómputo generará pruebas más lento, pero más barato.
CONFIGURACIÓN EN DOS PASOS
Recientemente, Opside propuso un esquema de compromiso de dos pasos para descentralizar la red de probadores. El esquema divide la presentación de la prueba en dos fases para evitar la situación en la que siempre gana el probador más rápido.
Paso 1: Envíe el hash de la prueba de conocimiento cero del bloque T-th
A partir del bloque T+11, los nuevos probadores ya no pueden enviar hashes.
Paso 2: Envíe una prueba de conocimiento cero
Después del bloque T+11, cualquier probador puede presentar una prueba de conocimiento cero. Si al menos una prueba de conocimiento cero pasa la verificación, se usará para verificar todos los hashes enviados, y el probador verificado recibirá las recompensas PoW correspondientes en proporción al monto de la hipoteca.
Si no se verifica ninguna prueba de conocimiento cero antes del bloque T+20, todos los probadores que enviaron hashes serán penalizados. Luego, vuelva a abrir el clasificador, puede enviar un nuevo hash, vuelva al paso 1.
Este método puede acomodar diferentes potencias informáticas. Sin embargo, la garantía requerida todavía introduce un nivel de centralización.
Descentralización del clasificador
La descentralización de los ordenantes es más compleja que la de los validadores. Esto se debe a que el clasificador tiene el poder de empaquetar y organizar transacciones, y es necesario considerar cuestiones como el MEV y la distribución de ingresos.
Dado que Ethereum priorizará la capacidad de respuesta sobre la capacidad de respuesta, las soluciones L2 deberían complementar esta compensación al priorizar la capacidad de respuesta sobre la capacidad de respuesta. Sin embargo, en comparación con los clasificadores centralizados, los clasificadores descentralizados se sacrifican inherentemente en términos de capacidad de respuesta. Por lo tanto, es necesario implementar varias optimizaciones para resolver este dilema.
Actualmente, hay tres propuestas diferentes de clasificador descentralizado. La primera solución se realiza optimizando el mecanismo de consenso. El segundo esquema implica una red de secuenciadores compartidos. El tercer esquema se basa en validadores L1.
consenso
El protocolo de consenso es el principal responsable de ordenar transacciones y garantizar su disponibilidad, no de ejecutarlas. Sin embargo, agregar directamente otra capa de consenso, como se mencionó anteriormente, no es una solución fácil.
Para mejorar la capacidad de respuesta, un enfoque común es confiar en un conjunto más pequeño de validadores. Por ejemplo, Algorand y Polkadot usan comités más pequeños muestreados aleatoriamente para procesar lotes de transacciones. Todos los nodos utilizan balizas aleatorias y una función aleatoria verificable (VRF), con una probabilidad de ser incluidos en un comité en un período determinado proporcional a su cantidad apostada.
Para reducir el tráfico de la red, se pueden utilizar comités de disponibilidad de datos (DA) más pequeños. O utilice VID (Dispersión de Información Verificable). VID distribuye el código de borrado de los datos a todos los nodos que participan en el consenso, de modo que cualquier subconjunto de nodos que tenga una tasa de compromiso lo suficientemente alta pueda cooperar para restaurar los datos. La compensación de este enfoque es reducir la complejidad de la transmisión, pero aumentar la complejidad de la recuperación de datos.
Arbitrum seleccionó entidades acreditadas para formar el conjunto de validadores, como ConsenSys, Ethereum Foundation, L2BEAT, Mycelium, Offchain Labs, P2P, Quicknode, Distributed Ledger Research Center (DLRC) de IFF y Unit 410 para unirse al Comité Clasificador. La contrapartida de este enfoque es compensar la falta de cantidad mejorando la calidad de la descentralización.
Red de secuenciador compartido
Los clasificadores juegan un papel vital en las cadenas de bloques modulares, especialmente en los paquetes acumulativos. Cada paquete acumulativo generalmente crea su propia red de clasificadores. Sin embargo, este enfoque no solo crea problemas de redundancia sino que también dificulta la composición. Para resolver este problema, algunos protocolos proponen construir una red clasificadora de resumen compartida. Este enfoque reduce la complejidad de lograr atomicidad, componibilidad e interoperabilidad, características que los usuarios y desarrolladores necesitan desesperadamente en cadenas de bloques abiertas y sin permiso. Además, también elimina la necesidad de un cliente ligero separado para la red de pedidos.
Astria
Astria está desarrollando una blockchain de middleware para el ecosistema Rollup de Celestia, que incluye su propia colección de pedidos distribuidos. Este conjunto de ordenantes es responsable de aceptar transacciones de múltiples acumulaciones y escribirlas en la capa base sin ejecutarlas.
El papel de Astria se centra principalmente en el pedido de transacciones y opera independientemente de la capa base y del Rollup. Los datos de transacciones se almacenan en la capa base (por ejemplo, Celestia), mientras que los nodos completos de resumen mantienen el estado y ejecutan operaciones. Esto asegura que Astria esté desacoplada de Rollup.
Para finalizar, Astria proporciona dos niveles de Compromiso:
"Compromiso suave": permite que Rollup proporcione confirmaciones de bloqueo rápidas a sus usuarios finales.
“Compromiso firme”: La velocidad es la misma que la capa base, lo que garantiza una mayor seguridad y finalidad.
Café exprés
Espresso ha hecho una contribución significativa en el campo de la tecnología de conocimiento cero. Su último desarrollo es una solución integral para clasificadores descentralizados que se puede aplicar a Optimistic Rollups y zkRollups.
La red de pedidos descentralizados consta de:
Consenso de HotShot: priorice el alto rendimiento y la rapidez de finalización sobre la disponibilidad dinámica.
Espresso DA: combinación de solución DA basada en comité y VID, donde los nodos de gran ancho de banda alimentan datos a todos los demás nodos. La disponibilidad de cada bloque individual también está respaldada por un pequeño comité elegido al azar. Los VID brindan una copia de seguridad confiable pero más lenta, lo que garantiza la disponibilidad siempre que no se comprometa un porcentaje suficientemente alto del peso apostado de todos los nodos.
Rollup REST API: Ethereum compatible con JSON-RPC.
Contrato de secuenciador: verifique el consenso de HotShot (es decir, actúe como un cliente ligero) y registre los puntos de control (es decir, haga un compromiso criptográfico con la transacción) y administre la tabla de compromiso de HotShot.
Red P2P: protocolo Gossip.
En comparación con Astria, Espresso ofrece DA. Por lo tanto, el flujo de trabajo será ligeramente diferente, de la siguiente manera:
El usuario crea y envía una transacción a Rollup.
La transacción se propaga a través de la red de pedidos y se retiene en el mempool.
Designe un líder a través del mecanismo de compromiso HotShot, proponga un bloque y propáguelo a los ejecutores y probadores de Rollup.
El líder envía la transacción al Comité de Disponibilidad de Datos y recibe un certificado DA como retroalimentación.
El líder también envía un compromiso con el bloque al contrato del clasificador de capa 1, junto con el certificado que utiliza el contrato para validar el bloque.
Espresso presenta el protocolo Gossip para pruebas para brindar una experiencia de usuario más flexible. Proporciona tres opciones para la finalidad de la transacción:
Rápido: los usuarios pueden confiar en el servidor de resumen que ejecutó la transacción y generó la prueba, o pueden aprovechar la baja latencia de HotShot para ejecutar la transacción.
Moderado: El usuario puede esperar un tiempo a que se genere la prueba y luego verificarla.
Lento: los usuarios pueden esperar las actualizaciones de estado verificadas de L1 para obtener el estado actualizado sin suposiciones ni cálculos de confianza.
Además de las optimizaciones anteriores, Espresso también planea que todo el conjunto de validadores de Ethereum participe en la ejecución del protocolo de pedidos de Espresso. El uso del mismo conjunto de validadores proporcionará una seguridad similar y compartir valor con los validadores L1 será más seguro. Además, Espresso también puede aprovechar la solución de replanteo de ETH proporcionada por EigenLayer.
Radio
Radius está construyendo una capa de pedidos compartidos sin confianza basada en pruebas de conocimiento cero, enfocándose en resolver el problema MEV en L2, porque los ingresos de L2 provienen principalmente del espacio de bloques. La compensación a considerar es el equilibrio entre los ingresos de MEV y L2. El objetivo de Radius es eliminar MEV, que es perjudicial para los usuarios, y propone un servicio de dos capas.
La capa superior se dirige a las transacciones regulares de los usuarios y brinda protección criptográfica contra MEV no deseados mediante el uso de rompecabezas de bloqueo de tiempo. Específicamente, emplea la tecnología Practical Verifiable Delayed Encryption (PVDE), que generará pruebas de conocimiento cero para acertijos de bloqueo de tiempo basados en RSA en 5 segundos. Este método proporciona una solución práctica para proteger a los usuarios de MEV dañinos. En resumen, el contenido de la transacción no puede conocerse hasta que el secuenciador determina el orden de las transacciones.
La capa subyacente está diseñada para constructores de bloques y les permite participar en actividades generadoras de ingresos mientras mitiga el impacto negativo de MEV.
Resúmenes basados
El resumen basado es un concepto propuesto recientemente por Justin Drake, donde los proponentes del bloque L1 cooperan con los buscadores y constructores de L1 para incluir bloques acumulativos en el siguiente bloque L1 sin permiso. Puede verse como una red de secuenciadores compartidos en L1. Las ventajas y desventajas de la acumulación basada en datos son obvias.
En el lado positivo, Based Rollup aprovecha la vitalidad y la descentralización proporcionada por L1, y su implementación es simple y eficiente. El resumen basado también es económicamente consistente con L1. Sin embargo, esto no significa que Based Rollup comprometa su soberanía. Aunque MEV se transfiere a L1, el Rollup basado aún puede poseer tokens de gobierno y cobrar tarifas base. Según la hipótesis, el resumen basado puede aprovechar estas ventajas, lograr el dominio y, en última instancia, maximizar los rendimientos.
en conclusión
Al observar las propuestas propuestas, se puede ver que la descentralización de Rollup aún tiene un largo camino por recorrer. Algunas de estas propuestas aún se encuentran en la etapa de borrador y requieren más discusión, mientras que otras solo han completado las especificaciones preliminares. Todos estos escenarios deben implementarse y probarse rigurosamente.
Si bien es posible que algunos paquetes acumulativos no propongan explícitamente las soluciones descentralizadas correspondientes, a menudo incluyen mecanismos de escape para abordar puntos únicos de falla debido a ordenadores centralizados. Por ejemplo, zkSync proporciona un método FullExit que permite a los usuarios retirar sus fondos directamente de L1. Cuando el sistema entra en modo éxodo y no puede procesar nuevos bloques, el usuario puede iniciar una operación de retiro.
Para lograr la resistencia a la censura, estos Rollups a menudo también permiten a los usuarios enviar transacciones directamente en L1. Por ejemplo, zkSync emplea una cola de prioridad para este tipo de transacciones enviadas en L1. De manera similar, Polygon zkEVM incluye un método forzado por lotes en el contrato L1. Cuando no ocurre ninguna agregación dentro de una semana, el usuario puede llamar a este método en L1 y proporcionar la matriz de bytes de la transacción y la tarifa de baño al probador.
Lo que es seguro es que en un futuro previsible, la descentralización de Rollup será una solución combinada, que puede incluir las soluciones importantes mencionadas anteriormente o algunas otras variantes innovadoras.
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Comprender los paquetes acumulativos descentralizados en un artículo
Título original: "Resumen descentralizados"
A medida que aumenta el uso de acumulaciones y aloja las aplicaciones del ecosistema, los costos de migración para los usuarios aumentarán y los pedidos centralizados obtendrán una influencia monopólica sobre los precios. Los controladores de los pedidos centralizados están justificados para maximizar la extracción de valor (MEV) de los usuarios tanto directamente (p. ej., a través de tarifas) como indirectamente (p. ej., a través de transacciones anticipadas, ataques sándwich, etc.). - Café exprés
Como lo mencionó el equipo de Espresso, los paquetes acumulativos centralizados eventualmente enfrentarán problemas de precios de monopolio y MEV. Además, los resúmenes centralizados rompen inherentemente la componibilidad, lo que lleva a resúmenes fragmentados. **
Sin embargo, casi todos los paquetes acumulativos actuales todavía están centralizados, porque crear un paquete acumulativo escalable, sin permiso y descentralizado es extremadamente desafiante. Otra razón es que el lanzamiento centralizado de Rollups primero puede ayudar a incubar el ecosistema y ganar participación de mercado.
Y cuando hablamos de Rollups descentralizados, especialmente zkRollups, hay dos niveles de descentralización. La primera es la descentralización del probador, y la segunda es la descentralización del ordenante. Para lograr una descentralización completa, también es necesario resolver el problema de coordinación entre el ordenante y el probador.
Bajo la tendencia de la modularización, actualmente hay tres tipos principales de participantes en el Rollup descentralizado. La primera categoría tiene como objetivo lograr Rollups totalmente descentralizados y propone una solución completa. La segunda categoría son los protocolos diseñados para resolver redes de probadores. Finalmente, existen múltiples soluciones que están funcionando para descentralizar el clasificador.
Resúmenes descentralizados
En zkRollups, Polygon y Starknet han ideado soluciones para descentralizar sus Rollups.
Polígono
Antes de la introducción de POE (Prueba de eficiencia), Polygon zkEVM adoptó POD (Prueba de donación), lo que permitía al clasificador ofertar por la oportunidad de crear el siguiente lote de transacciones. Sin embargo, esto crea el problema de que una sola parte malintencionada puede controlar toda la red haciendo la oferta más alta.
Después de adoptar POE, el ordenante y el probador participarán en la red sin permiso de manera más eficiente bajo sus propias condiciones de hardware. Cualquiera puede unirse a Polygon zkEVM siempre que tenga sentido económico.
En Polygon zkEVM, el clasificador requiere 16 GB de RAM y una CPU de 4 núcleos, mientras que el probador requiere 1 TB de RAM y una CPU de 128 núcleos. Además, existe una función denominada agregador, que es responsable de recopilar datos de L1, enviarlos al probador, recibir la prueba y enviarla a L1. Podemos considerar al agregador y al probador como el mismo sujeto, porque la relación entre el agregador y el probador es muy simple, y el agregador le paga al probador para producir la prueba.
Esta arquitectura es muy simple: cualquier ordenante puede empaquetar transacciones basadas en el estado anterior en L1 sin permiso y actualizar el estado correspondiente. Al mismo tiempo, cualquier agregador puede enviar una prueba para verificar el estado actualizado.
En POE, la eficiencia se refiere no solo a la eficiencia de la red de los participantes que compiten entre sí, sino también a la eficiencia económica del secuenciador y del probador. En L2, el ordenante y el probador comparten la tarifa de transacción, y el ordenante paga la tarifa por lote al agregador para generar la prueba. Esto asegura que los participantes estén económicamente motivados para contribuir a la eficiencia de la red, lo que da como resultado un ecosistema más sólido y sostenible.
clasificador
Agregador (Probador)
Coordinador: tarifa por lotes
Starknet
Starknet también tiene como objetivo construir un Rollup escalable y sin permiso de confirmación rápida. Si bien aún no se ha alcanzado la especificación final para la solución descentralizada, publicaron algunos borradores en el foro hace unos meses.
En comparación con el mecanismo simple de Polygon zkEVM, el esquema de Starknet es más complicado porque incluye consenso L2 y prueba de protocolo encadenada en la red de prueba.
clasificador
En lugar de simplemente agregar una capa de consenso dentro de la capa de pedidos, Starknet propone un protocolo de consenso de doble libro mayor. En este protocolo, L2 proporciona una respuesta rápida como protocolo en vivo, mientras que los puntos de control de L1 brindan una confirmación final como protocolo seguro.
Para el protocolo en vivo de L2, se pueden adoptar varios mecanismos de consenso, como sistemas PoS resistentes a Sybil, como Tendermint o DAG. Por otro lado, el protocolo seguro de L1 implica múltiples contratos que manejan la gestión de Stake, la verificación de pruebas y la actualización de estado, respectivamente.
El flujo de trabajo típico del acuerdo de consenso de doble libro mayor es el siguiente:
Primero, use la salida del libro mayor vivo L2 como la entrada del libro mayor seguro L1 para generar un libro mayor vivo verificado.
Luego, tome el libro mayor en vivo verificado como entrada e ingréselo nuevamente en el protocolo de consenso puro de L2 para asegurarse de que el libro mayor en vivo verificado sea siempre el prefijo del libro mayor en vivo.
Repita el proceso anterior.
Al crear un protocolo de consenso de doble libro mayor, existe una compensación entre el costo y la latencia. La solución ideal tiene como objetivo lograr una aprobación final rápida y de bajo costo.
Para reducir los costos de gas en L2, Starknet divide los puntos de control en "nivel de minutos" y "nivel de horas". Para los puntos de control de "nivel de minuto", solo el estado en sí está comprometido con la cadena, mientras que el resto de los datos (pruebas de validez, disponibilidad de datos, etc.) se envía a través de la red StarkNet L2. Estos datos son almacenados y verificados por los nodos completos de StarkNet. Por otro lado, los puntos de control "por hora" se validan públicamente en L1. Ambos tipos de puntos de control proporcionan la misma confirmación final. Para los puntos de control de "nivel de minutos", la prueba de validez es verificada por los nodos completos de StarkNet y puede ser emitida por cualquier nodo en L1 para dar la finalidad de L1 a los puntos de control de "nivel de minutos". Por lo tanto, el probador necesita generar pequeñas pruebas para ser ampliamente difundidas en la red L2.
Para reducir aún más la latencia, Starknet propone un protocolo de elección de líder para determinar el líder por adelantado. La lógica básica es la siguiente: el líder de la época actual i está predeterminado en función de la cantidad de L1 apostada y cierta aleatoriedad. Específicamente, en la época i-2, el método de elección de líder en mosaico lexicográficamente a los clasificadores en función de la cantidad de promesas en la época i-3. Luego, envíe una transacción para actualizar el nonce y elija un punto al azar. El clasificador correspondiente a la posición donde cae el punto será el líder de la época i.
Certificador
Bajo el módulo POE, existe una competencia abierta entre los participantes, lo que puede conducir a una situación en la que el ganador se lo lleva todo. Starknet intenta lograr un mecanismo de competencia sin riesgo de centralización. Aquí hay algunas opciones:
Además de la competencia entre probadores, la barrera de entrada debe reducirse para que más probadores puedan participar en la red. Starknet propone un protocolo complejo que utiliza pruebas recursivas llamadas pruebas de protocolo encadenadas.
En los protocolos de prueba de cadena, la propia cadena de bloques se divide en varias bifurcaciones diferentes. De esta manera, las pruebas no solo pueden ser recursivas, sino que la generación de pruebas también puede ser concurrente. Por ejemplo, en una configuración de 3 ramas, 12 bloques negros se dividen en 3 filas, cada fila representa una rama. Podemos pensar en cada rama como una subcadena donde cada bloque debe dar fe del bloque anterior. Desde el punto de vista de toda la cadena, la ranura n necesita probar la ranura n-3. El intervalo de 3 bloques permite suficiente tiempo para que el ordenante calcule y compre las pruebas por adelantado. Esto es algo similar a la fragmentación, donde un atacante solo necesita controlar una rama para controlar toda la red de probadores.
Para unir estas ramas, Starknet propone una tecnología de tejido que puede fusionar múltiples nodos para verificar conjuntamente la legitimidad de las transacciones y garantizar la consistencia y confiabilidad de los registros de transacciones.
Una solución es exigir que cada ranura se fusione con varias sucursales al mismo tiempo. Otra solución es intentar alternativamente que cada rama se fusione con otras ramas, reduciendo así la carga de trabajo de la prueba. Por supuesto, este también es un problema abierto, y puede haber mejores soluciones en el futuro.
coordinación
Para garantizar activamente que el probador pueda tener suficiente espacio de ganancias, Starknet propone un método para referirse al esquema EIP1559: establezca la tarifa base como el límite inferior del precio del recurso del probador, realice activamente el descubrimiento de precios y el clasificador puede usar consejos para motivar al experimentador. De esta manera, el probador siempre recibirá un sobrepago y solo los casos extremos afectarán el proceso de prueba. De lo contrario, si al probador se le paga cerca del precio de mercado, una ligera fluctuación podría desencadenar un bloqueo del probador.
Descentralización de certificadores
Desde la perspectiva de los Rollups, es más fácil lograr la descentralización en el probador que en el clasificador. Además, el probador actual es un cuello de botella en el rendimiento y debe mantenerse al día con la velocidad de dosificación del clasificador. Cuando no se ha resuelto la descentralización del clasificador, el probador descentralizado también puede prestar servicios para el clasificador centralizado.
De hecho, no solo los Rollups, zkBridge y zkOracle también necesitan una red de probadores. Todos ellos requieren una fuerte red distribuida de probadores.
A la larga, una red de probadores que puede acomodar diferentes potencias informáticas es más sostenible; de lo contrario, las máquinas con mejor rendimiento monopolizarán el mercado.
Mercado de prueba
Algunos protocolos no coordinan la relación entre el secuenciador y el probador, sino que abstraen directamente la coordinación en un mercado de pruebas. En este mercado, las pruebas son mercancías, los probadores son productores de pruebas y los protocolos son consumidores de pruebas. El equilibrio del mercado es más eficiente bajo la influencia de la "mano invisible".
Mío
Mina ha establecido un mercado de pruebas llamado Snarketplace donde se comercializan las pruebas de Snark. La unidad más pequeña aquí es la prueba de Snark de una sola transacción. Mina emplea un árbol recursivo de prueba de estado llamado Scan State.
Scan State es un bosque de árboles binarios donde cada transacción es un nodo. Se genera una sola prueba en la parte superior del árbol que puede probar todas las transacciones en el árbol. El probador tiene dos tareas: la primera es generar pruebas y la segunda es fusionar pruebas.
Después de que el probador complete el trabajo y presente la oferta, el productor de bloques del protocolo Mina seleccionará al postor con el precio más bajo. Este es también el precio de equilibrio, ya que los postores presentarán ofertas por encima del costo de las pruebas, y los productores de bloques no comprarán pruebas que no valgan la pena.
=Nada; Base
El mercado de prueba de Mina está diseñado para su propio protocolo, mientras que =nil; Foundation propone un mercado de prueba general para servir a todo el mercado.
El servicio de mercado consta de tres componentes: DROP DATABASE, zkLLVM y Proof Market.
Cada prueba consta de sus diferentes entradas y circuitos, por lo que cada prueba es única. Un circuito define un tipo de prueba, similar a cómo se define un "par de transacciones" en términos financieros. Además, diferentes sistemas de prueba introducen más circuitos.
El flujo de trabajo es el siguiente: el lado de la demanda de la prueba puede escribir código en un lenguaje de programación de alto nivel, luego enviarlo a =nil;zkLLVM a través de la cadena de herramientas, generando un circuito único que se convertirá en un par comercial único en el mercado.
Por el lado de la demanda de prueba, pueden hacer una compensación entre costo y tiempo. Los probadores también considerarán su poder de cómputo e ingresos. Por lo tanto, en el mercado habrá diferentes potencias de cómputo, alta potencia de cómputo generará pruebas más rápido, pero a un costo mayor, mientras que baja potencia de cómputo generará pruebas más lento, pero más barato.
CONFIGURACIÓN EN DOS PASOS
Recientemente, Opside propuso un esquema de compromiso de dos pasos para descentralizar la red de probadores. El esquema divide la presentación de la prueba en dos fases para evitar la situación en la que siempre gana el probador más rápido.
Este método puede acomodar diferentes potencias informáticas. Sin embargo, la garantía requerida todavía introduce un nivel de centralización.
Descentralización del clasificador
La descentralización de los ordenantes es más compleja que la de los validadores. Esto se debe a que el clasificador tiene el poder de empaquetar y organizar transacciones, y es necesario considerar cuestiones como el MEV y la distribución de ingresos.
Dado que Ethereum priorizará la capacidad de respuesta sobre la capacidad de respuesta, las soluciones L2 deberían complementar esta compensación al priorizar la capacidad de respuesta sobre la capacidad de respuesta. Sin embargo, en comparación con los clasificadores centralizados, los clasificadores descentralizados se sacrifican inherentemente en términos de capacidad de respuesta. Por lo tanto, es necesario implementar varias optimizaciones para resolver este dilema.
Actualmente, hay tres propuestas diferentes de clasificador descentralizado. La primera solución se realiza optimizando el mecanismo de consenso. El segundo esquema implica una red de secuenciadores compartidos. El tercer esquema se basa en validadores L1.
consenso
El protocolo de consenso es el principal responsable de ordenar transacciones y garantizar su disponibilidad, no de ejecutarlas. Sin embargo, agregar directamente otra capa de consenso, como se mencionó anteriormente, no es una solución fácil.
Para mejorar la capacidad de respuesta, un enfoque común es confiar en un conjunto más pequeño de validadores. Por ejemplo, Algorand y Polkadot usan comités más pequeños muestreados aleatoriamente para procesar lotes de transacciones. Todos los nodos utilizan balizas aleatorias y una función aleatoria verificable (VRF), con una probabilidad de ser incluidos en un comité en un período determinado proporcional a su cantidad apostada.
Para reducir el tráfico de la red, se pueden utilizar comités de disponibilidad de datos (DA) más pequeños. O utilice VID (Dispersión de Información Verificable). VID distribuye el código de borrado de los datos a todos los nodos que participan en el consenso, de modo que cualquier subconjunto de nodos que tenga una tasa de compromiso lo suficientemente alta pueda cooperar para restaurar los datos. La compensación de este enfoque es reducir la complejidad de la transmisión, pero aumentar la complejidad de la recuperación de datos.
Arbitrum seleccionó entidades acreditadas para formar el conjunto de validadores, como ConsenSys, Ethereum Foundation, L2BEAT, Mycelium, Offchain Labs, P2P, Quicknode, Distributed Ledger Research Center (DLRC) de IFF y Unit 410 para unirse al Comité Clasificador. La contrapartida de este enfoque es compensar la falta de cantidad mejorando la calidad de la descentralización.
Red de secuenciador compartido
Los clasificadores juegan un papel vital en las cadenas de bloques modulares, especialmente en los paquetes acumulativos. Cada paquete acumulativo generalmente crea su propia red de clasificadores. Sin embargo, este enfoque no solo crea problemas de redundancia sino que también dificulta la composición. Para resolver este problema, algunos protocolos proponen construir una red clasificadora de resumen compartida. Este enfoque reduce la complejidad de lograr atomicidad, componibilidad e interoperabilidad, características que los usuarios y desarrolladores necesitan desesperadamente en cadenas de bloques abiertas y sin permiso. Además, también elimina la necesidad de un cliente ligero separado para la red de pedidos.
Astria
Astria está desarrollando una blockchain de middleware para el ecosistema Rollup de Celestia, que incluye su propia colección de pedidos distribuidos. Este conjunto de ordenantes es responsable de aceptar transacciones de múltiples acumulaciones y escribirlas en la capa base sin ejecutarlas.
El papel de Astria se centra principalmente en el pedido de transacciones y opera independientemente de la capa base y del Rollup. Los datos de transacciones se almacenan en la capa base (por ejemplo, Celestia), mientras que los nodos completos de resumen mantienen el estado y ejecutan operaciones. Esto asegura que Astria esté desacoplada de Rollup.
Para finalizar, Astria proporciona dos niveles de Compromiso:
Café exprés
Espresso ha hecho una contribución significativa en el campo de la tecnología de conocimiento cero. Su último desarrollo es una solución integral para clasificadores descentralizados que se puede aplicar a Optimistic Rollups y zkRollups.
La red de pedidos descentralizados consta de:
En comparación con Astria, Espresso ofrece DA. Por lo tanto, el flujo de trabajo será ligeramente diferente, de la siguiente manera:
El usuario crea y envía una transacción a Rollup.
La transacción se propaga a través de la red de pedidos y se retiene en el mempool.
Designe un líder a través del mecanismo de compromiso HotShot, proponga un bloque y propáguelo a los ejecutores y probadores de Rollup.
El líder envía la transacción al Comité de Disponibilidad de Datos y recibe un certificado DA como retroalimentación.
El líder también envía un compromiso con el bloque al contrato del clasificador de capa 1, junto con el certificado que utiliza el contrato para validar el bloque.
Espresso presenta el protocolo Gossip para pruebas para brindar una experiencia de usuario más flexible. Proporciona tres opciones para la finalidad de la transacción:
Además de las optimizaciones anteriores, Espresso también planea que todo el conjunto de validadores de Ethereum participe en la ejecución del protocolo de pedidos de Espresso. El uso del mismo conjunto de validadores proporcionará una seguridad similar y compartir valor con los validadores L1 será más seguro. Además, Espresso también puede aprovechar la solución de replanteo de ETH proporcionada por EigenLayer.
Radio
Radius está construyendo una capa de pedidos compartidos sin confianza basada en pruebas de conocimiento cero, enfocándose en resolver el problema MEV en L2, porque los ingresos de L2 provienen principalmente del espacio de bloques. La compensación a considerar es el equilibrio entre los ingresos de MEV y L2. El objetivo de Radius es eliminar MEV, que es perjudicial para los usuarios, y propone un servicio de dos capas.
La capa superior se dirige a las transacciones regulares de los usuarios y brinda protección criptográfica contra MEV no deseados mediante el uso de rompecabezas de bloqueo de tiempo. Específicamente, emplea la tecnología Practical Verifiable Delayed Encryption (PVDE), que generará pruebas de conocimiento cero para acertijos de bloqueo de tiempo basados en RSA en 5 segundos. Este método proporciona una solución práctica para proteger a los usuarios de MEV dañinos. En resumen, el contenido de la transacción no puede conocerse hasta que el secuenciador determina el orden de las transacciones.
La capa subyacente está diseñada para constructores de bloques y les permite participar en actividades generadoras de ingresos mientras mitiga el impacto negativo de MEV.
Resúmenes basados
El resumen basado es un concepto propuesto recientemente por Justin Drake, donde los proponentes del bloque L1 cooperan con los buscadores y constructores de L1 para incluir bloques acumulativos en el siguiente bloque L1 sin permiso. Puede verse como una red de secuenciadores compartidos en L1. Las ventajas y desventajas de la acumulación basada en datos son obvias.
En el lado positivo, Based Rollup aprovecha la vitalidad y la descentralización proporcionada por L1, y su implementación es simple y eficiente. El resumen basado también es económicamente consistente con L1. Sin embargo, esto no significa que Based Rollup comprometa su soberanía. Aunque MEV se transfiere a L1, el Rollup basado aún puede poseer tokens de gobierno y cobrar tarifas base. Según la hipótesis, el resumen basado puede aprovechar estas ventajas, lograr el dominio y, en última instancia, maximizar los rendimientos.
en conclusión
Al observar las propuestas propuestas, se puede ver que la descentralización de Rollup aún tiene un largo camino por recorrer. Algunas de estas propuestas aún se encuentran en la etapa de borrador y requieren más discusión, mientras que otras solo han completado las especificaciones preliminares. Todos estos escenarios deben implementarse y probarse rigurosamente.
Si bien es posible que algunos paquetes acumulativos no propongan explícitamente las soluciones descentralizadas correspondientes, a menudo incluyen mecanismos de escape para abordar puntos únicos de falla debido a ordenadores centralizados. Por ejemplo, zkSync proporciona un método FullExit que permite a los usuarios retirar sus fondos directamente de L1. Cuando el sistema entra en modo éxodo y no puede procesar nuevos bloques, el usuario puede iniciar una operación de retiro.
Para lograr la resistencia a la censura, estos Rollups a menudo también permiten a los usuarios enviar transacciones directamente en L1. Por ejemplo, zkSync emplea una cola de prioridad para este tipo de transacciones enviadas en L1. De manera similar, Polygon zkEVM incluye un método forzado por lotes en el contrato L1. Cuando no ocurre ninguna agregación dentro de una semana, el usuario puede llamar a este método en L1 y proporcionar la matriz de bytes de la transacción y la tarifa de baño al probador.
Lo que es seguro es que en un futuro previsible, la descentralización de Rollup será una solución combinada, que puede incluir las soluciones importantes mencionadas anteriormente o algunas otras variantes innovadoras.