Escrito por: Vitalik Buterin, cofundador de Ethereum
Compilado por: Dong Yiming, atrapador de cadenas
Un agradecimiento especial a Georgios Konstantopoulos, Karl Floersch y al equipo de Starkware por sus comentarios y revisiones.
Un tema que a menudo resurge en las discusiones sobre escalamiento de la Capa 2 es el concepto de "Capa 3". Si podemos construir un protocolo de Capa 2 anclado a la Capa 1 con el objetivo principal de lograr su seguridad y aumentar su escalabilidad, entonces ciertamente podemos lograr seguridad construyendo un protocolo "anclado a la Capa 2" y agregar más escalabilidad sobre la Capa 3. protocolo para ampliar su escala?
Una versión simple de esta idea es: si tienes una solución que te permite lograr un crecimiento cuadrático, ¿puedes apilar esa solución encima de sí misma y obtener un crecimiento exponencial? Ideas similares incluyen mi artículo sobre escalabilidad de 2015 y la extensión multicapa mencionada en el artículo de Plasma. Desafortunadamente, un concepto de Capa 3 tan simple no es tan fácil de formar una solución factible. Siempre hay algo en el diseño que no es apilable y solo le brindará un aumento de escalabilidad debido a limitaciones de disponibilidad de datos, dependencia del ancho de banda de Capa 1 extraído con urgencia o muchos otros problemas.
Las ideas más nuevas en torno a la Capa 3, como el marco propuesto por Starkware, son más complejas: no simplemente apilan lo mismo encima de sí mismo, sino que asignan diferentes usos a la Capa 2 y a la Capa 3. Las formas potenciales de este enfoque podrían funcionar si se hicieran de la manera correcta. Este artículo detallará lo que puede y no tener sentido en una arquitectura de tres niveles.
¿Por qué no puedes seguir escalando apilando paquetes acumulativos encima de otros?
Los rollups son una tecnología de escalamiento que combina diferentes tecnologías para resolver los dos principales cuellos de botella de escalamiento de la ejecución de una cadena de bloques: computación y datos. El cálculo se ha resuelto mediante enfoques como las "pruebas de fraude" o SNARK, que dependen de un número muy pequeño de participantes para procesar y verificar cada bloque, lo que requiere que otros realicen solo una pequeña cantidad de cálculo para verificar que se completó el proceso de prueba. correctamente. Estos esquemas, especialmente los SNARK, son casi infinitamente escalables; podemos continuar creando "SNARK de muchos SNARK" para reducir más cálculos a una sola prueba.
Los datos son diferentes. Los rollups utilizan una serie de técnicas de compresión para reducir la cantidad de datos que las transacciones necesitan almacenar en la cadena: una simple transferencia de moneda se reduce de aproximadamente 100 bytes a aproximadamente 16 bytes, y una transferencia ERC20 en una cadena compatible con EVM se reduce de aproximadamente 180 bytes a aproximadamente 180 bytes.23 bytes, una transacción ZK-SNARK que preserva la privacidad se puede comprimir de aproximadamente 600 bytes a aproximadamente 80 bytes. Hay aproximadamente una compresión de 8x en todos los casos. Pero Rollup aún necesita que los datos estén disponibles en la cadena en un medio que garantice el acceso y la verificación del usuario, de modo que los usuarios puedan calcular de forma independiente el estado de Rollup y unirse como certificador cuando el certificador existente se desconecte. Los datos se pueden comprimir una vez, pero no otra vez. - - - Si puede, generalmente hay una manera de poner la lógica del segundo compresor en el primer compresor y obtener el mismo beneficio al comprimirlo una vez. Por lo tanto, "Acumulaciones sobre acumulaciones" en realidad no ofrece grandes ganancias en escalabilidad, pero, como veremos a continuación, este patrón se puede utilizar para otros fines.
Entonces, ¿cuál es la versión "sana" de la Capa 3?
Bueno, veamos qué defiende Starkware en su publicación sobre la Capa 3. Starkware fue formado por criptógrafos muy inteligentes, están cuerdos, por lo que si abogan por la capa 3, su versión será más compleja que "si los Rollups comprimen los datos 8 veces, entonces, obviamente, los Rollups sobre los Rollups comprimirán los datos 64 veces".
Aquí está la imagen de la publicación de Starkware:
Algunas citas:
La imagen de arriba muestra un ejemplo de dicho ecosistema. Su L3 incluye:
1. StarkNet con disponibilidad de datos de Validium, por ejemplo, a menudo utilizado en aplicaciones que son extremadamente sensibles a los precios.
2. Sistemas StarkNet específicos de aplicaciones personalizados para un mejor rendimiento de las aplicaciones, por ejemplo, empleando estructuras de almacenamiento específicas o compresión de disponibilidad de datos.
3. Los sistemas StarkEx (como los que prestan servicio a dYdX, Sorare, Immutable y DeversiFi) tienen disponibilidad de datos Validium o Rollup, lo que aporta inmediatamente beneficios de escalabilidad comprobados a StarkNet.
4. La instancia de privacidad de StarkNet (también L4 en este ejemplo) permite que existan transacciones de tipo que preservan la privacidad sin incluirlas en la StarkNet pública.
Podemos condensar el artículo en tres visiones de “L3”:
L2 se usa para expansión y L3 se usa para funciones de personalización como la privacidad. En esta visión, no hay ningún intento de proporcionar un "crecimiento cuadrático en escalabilidad"; en cambio, hay una capa en la pila que ayuda a escalar la aplicación, y luego hay capas independientes para satisfacer las necesidades de funcionalidad personalizada de diferentes casos de uso.
L2 se usa para expansión general y L3 se usa para expansión personalizable. El escalado personalizable puede presentarse en diferentes formas: aplicaciones especializadas que utilizan algo distinto al EVM para el cálculo, paquetes acumulativos de compresión de datos optimizados para el formato de datos específico de la aplicación (incluida la combinación de "datos" con "Prueba" por separado y reemplazar la prueba con un único SNARK ) etc.
L2 se usa para extensiones sin confianza (Rollups) y L3 se usa para extensiones de confianza débiles (Validiums). Validium es un sistema que utiliza SNARK para verificar los cálculos, pero deja la disponibilidad de los datos a un tercero o comité de confianza. En mi opinión, Validium está seriamente subestimado: en particular, muchas aplicaciones de "blockchain empresarial" podrían funcionar mejor con un probador que ejecute Validium y envíe hashes periódicamente a un servidor centralizado de la cadena. Proporcionar el mejor servicio. Validium tiene un nivel de seguridad más bajo que los paquetes acumulativos, pero puede ser mucho más económico.
En mi opinión, las tres visiones son fundamentalmente sólidas. La idea de que la compresión de datos especializada requiere su propia plataforma es probablemente la afirmación más débil: es muy fácil diseñar L2 con un esquema de compresión de capa base común que los usuarios pueden escalar automáticamente con subcompresores específicos de la aplicación, pero más allá de eso, estos casos de uso son todo legítimo. Pero eso todavía deja una gran pregunta: ¿Es una estructura de tres niveles la forma correcta de lograr estos objetivos? ¿Cuál es el punto de anclar la autenticación, los sistemas de privacidad y los entornos personalizados a L2 en lugar de solo a L1? Resulta que la respuesta a esta pregunta es bastante complicada.
¿Los depósitos y retiros se vuelven más baratos y fáciles en el árbol de subconjuntos de L2?
Un posible argumento a favor de la superioridad del modelo de tres niveles sobre el modelo de dos niveles es que el modelo de tres niveles permite que todo el subecosistema exista en un solo resumen, lo que permite que las operaciones entre dominios dentro de ese ecosistema se realicen muy rápidamente. a bajo precio sin pasar por el costoso acabado L1.
Pero resulta que incluso entre dos L2 o incluso L3, los depósitos y retiros pueden ser muy baratos. La clave para esto es que no es necesario emitir tokens y otros activos en la cadena raíz. Es decir, puede poseer un token ERC20 en Arbitrum, crear un contenedor para él en Optimism y avanzar y retroceder entre los dos sin ninguna transacción L1.
Veamos cómo funciona un sistema así. Hay dos tipos de contratos inteligentes: el contrato base en Arbitrum y el contrato de token encapsulado en Optimism. Para transferir de Arbitrum a Optimism, debe enviar tokens al contrato subyacente, que generará un recibo. Una vez que Arbitrum esté finalizado, puede tomar una prueba Merkle de ese recibo y rootearlo en el estado L1, luego enviarlo al contrato de token envuelto en Optimism, que lo verifica y le emite un token envuelto. Para mover el token hacia atrás, puedes hacer lo mismo a la inversa.
Aunque la ruta Merkle requerida para probar un depósito en Arbitrum pasa por el estado L1, Optimism solo necesita leer la raíz del estado L1 para procesar el depósito; no se requieren transacciones L1. Tenga en cuenta que, dado que los datos acumulativos son el recurso más escaso, la implementación real de este esquema utilizará pruebas SNARK o KZG en lugar de pruebas Merkle directamente para ahorrar espacio.
En comparación con los tokens basados en L1, este esquema tiene una debilidad fatal (al menos en las acumulaciones optimistas): los depósitos también deben esperar hasta la ventana de prevención de fraude. Si el token está arraigado en L1, retirarse de Arbitrum u Optimism a L1 requiere un retraso de una semana, pero los depósitos son instantáneos. Sin embargo, en este esquema, hay un retraso de una semana tanto para los depósitos como para los retiros. Dicho esto, no está claro que una arquitectura de tres niveles además de los paquetes acumulativos ideales sea mejor: existen muchas complejidades técnicas para garantizar que los juegos antifraude que se desarrollan dentro de un sistema que a su vez se ejecuta en juegos antifraude sean seguros.
Afortunadamente, ninguno de estos problemas será un problema con ZK Rollups. Por razones de seguridad, los ZK Rollups no requieren un período de espera de una semana, pero aún así requieren un período más corto por otras dos razones (la tecnología de primera generación podría requerir 12 horas). En primer lugar, especialmente los rollups ZK-EVM de uso general más complejos, tardan más en cubrir el tiempo de cálculo no paralelizable del bloque. En segundo lugar, las consideraciones económicas dictan que las certificaciones deben presentarse con poca frecuencia para minimizar los costos fijos asociados con las transacciones de certificación. La tecnología ZK-EVM de próxima generación, que incluye hardware especializado, resolverá el primer problema, mientras que una verificación por lotes mejor diseñada puede resolver el segundo problema. Lo que queremos discutir a continuación es la cuestión de la optimización y la prueba de envío por lotes.
Los rollups y validiums tienen una compensación entre el tiempo de confirmación y el costo fijo. L3 puede ayudar a resolver este problema, pero ¿qué más puede hacerlo?
El costo de los resúmenes por transacción es económico: son solo entre 16 y 60 bytes de datos, según la aplicación. Pero los Rollups también tienen que pagar un alto costo fijo cada vez que envían un lote de transacciones a la cadena: los Rollups Optimistas requieren 21,000 gas L1 por lote, y los Rollups ZK requieren más de 400,000 Gas (si desea brindar seguridad cuántica solo con STARKS , necesitas millones de Gas).
Por supuesto, Rollup podría simplemente optar por esperar hasta que haya una transacción L2 por valor de 10 millones de gas para enviar el lote completo (transacción), pero esto les daría un intervalo de lote muy largo, lo que obligaría a los usuarios a esperar más tiempo para una confirmación de alta seguridad. Por lo tanto, requieren una solución de compromiso: intervalos de lotes más largos y costos óptimos, o intervalos de lotes más cortos y costos mucho mayores.
Para darnos algunos números concretos, consideremos un ZK Rollup que cuesta 600.000 Gas por lote y procesemos una transferencia ERC20 totalmente optimizada (23 bytes) que cuesta 368 Gas por transacción. Supongamos que este paquete acumulativo se encuentra en una etapa temprana o media de adopción y tiene un TPS de 5. Podemos calcular el gas por transacción e intervalo de lote:
Si nos adentramos en un mundo con una gran cantidad de validación personalizada y entornos de aplicaciones específicas, muchos de ellos estarán muy por debajo de 5TPS. Por lo tanto, identificar el equilibrio entre tiempo y costo comienza a ser muy importante. De hecho, ¡el paradigma "L3" resuelve este problema! ZK Rollup en ZK Rollup, incluso una implementación simple, solo tiene un costo fijo de aproximadamente 8000 gas de capa 1 (500 bytes como prueba). Esto cambiará la tabla anterior a:
El problema está básicamente resuelto, entonces, ¿es bueno L3? Tal vez. Pero cabe señalar que existe otra forma de solucionar este problema inspirada en la verificación agregada ERC 4337.
La estrategia es la siguiente. Hoy en día, si cada ZK Rollup o Validium recibe una prueba, es una prueba de que Snew = STF(Vendido,D) : la nueva raíz del estado debe ser el resultado del procesamiento correcto de los datos de la transacción o incrementos de estado sobre la raíz del estado anterior. En este nuevo esquema, ZK Rollup aceptará un mensaje del contrato del validador de lotes que indique que ha verificado la prueba de un lote de declaraciones, cada una de las cuales tiene la forma Snew = STF(Sold,D) . Estas pruebas por lotes se pueden construir mediante esquemas SNARK recursivos o agregación Halo.
Este será un protocolo abierto: cualquier ZK-Rollup puede unirse y cualquier probador por lotes puede agregar pruebas de cualquier ZK-Rollup compatible y recibir una compensación por las tarifas de transacción del agregador. El contrato de lotes verificará la prueba una vez y luego entregará un mensaje a cada Rollup con el triple (Vendido, Nuevo, D) de esos solllups. El hecho de que el triple provenga del contrato de lotes se utilizará como evidencia de que la transformación es efectiva. .
Si se optimiza correctamente, el costo por resumen en este escenario podría estar más cerca de 8000, con 5000 para agregar las escrituras de estado recientemente actualizadas, 1280 para las raíces antiguas y nuevas, y 1720 adicionales para el procesamiento de datos diversos. Entonces nos dará el mismo ahorro. De hecho, Starkware ya tiene algo similar, llamado SHARP, aunque (todavía) no es un protocolo abierto sin permiso.
Una respuesta a este enfoque podría ser: ¿Pero no se trata realmente de otro enfoque de Capa 3? En lugar de capa base <- rollup <- validium tendremos capa base <- mecanismo por lotes <- rollup o validium. Desde la perspectiva de cierto marco filosófico, esto puede ser cierto. Pero hay una diferencia importante: la capa intermedia no es un sistema EVM completo y complejo, sino un objeto simplificado y altamente especializado, por lo que es más probable que sea seguro y que funcione sin otro token especializado. es más probable que esté mínimamente gobernado y que no cambie con el tiempo.
Conclusión: ¿Qué es exactamente una "Capa"?
Las arquitecturas de escalamiento de tres niveles que consisten en esquemas de escalamiento idénticos apilados encima de sí mismos generalmente no funcionan bien. La forma de Rollups encima de Rollups (donde dos capas de Rollups utilizan la misma tecnología) tampoco es satisfactoria. Sin embargo, una arquitectura de tres niveles con L2 y L3 con diferentes propósitos podría funcionar. Los validiums además de los rollups tienen sentido, incluso si definitivamente no son la mejor manera de hacer las cosas a largo plazo.
Sin embargo, una vez que empezamos a entrar en los detalles de qué arquitectura tiene sentido, nos adentramos en preguntas filosóficas: ¿Qué son "capas" y cuáles no? la capa base <- mecanismo por lotes <- rollup o validium y la capa base <- rollup <- rollup o validium hacen el mismo trabajo, pero en términos de cómo funcionan, la capa de agregación de pruebas se parece más a ERC-4337 que a los rollups. Normalmente, no nos referiríamos a ERC-4337 como "capa 2". Del mismo modo, no llamaremos a Tornado Cash "Capa 2", por lo que si queremos ser coherentes, no llamaremos al subsistema centrado en la privacidad que se encuentra en la parte superior de L2 L3. Entonces, en términos de lo que debería venir primero Llamado "Capa", hay un debate semántico sin resolver.
Hay muchas escuelas de pensamiento posibles a este respecto. Mi preferencia personal es limitar el término "Capa 2" a cosas que tengan las siguientes propiedades:
1. Su propósito es mejorar la escalabilidad.
2. Siguen el modelo "blockchain dentro de blockchain": tienen su propio mecanismo de procesamiento de transacciones y su propio estado interno.
3. Heredan toda la seguridad de la cadena Ethereum
Por lo tanto, los Rollups y ZK Rollups ideales son L2, pero la verificación, los esquemas de agregación de pruebas, ERC 4337, los sistemas de privacidad en cadena y Solidity son otra cuestión. Podría tener sentido llamar a algunos de ellos L3, pero probablemente no a todos; en cualquier caso, parece demasiado pronto para concretar una definición, y la arquitectura de un ecosistema de agregación múltiple está lejos de estar escrita en piedra, y la mayoría de las discusiones se llevan a cabo. lugar sólo en teoría.
Es decir, el debate lingüístico es menos importante que la cuestión técnica de qué estructura tiene realmente más sentido. Claramente, ciertas "capas" que atienden necesidades no escalables, como la privacidad, tienen un papel importante que desempeñar, y la importante funcionalidad de agregación de pruebas debe completarse de alguna manera, preferiblemente a través de protocolos abiertos. Pero al mismo tiempo, existen buenas razones técnicas para hacer que la capa intermedia que vincula el entorno de cara al usuario y L1 sea lo más simple posible; en muchos casos, ser la "capa adhesiva" para la acumulación de EVM puede no ser el enfoque correcto. Sospecho que a medida que madure el ecosistema de extensión L2, las estructuras más complejas (y más simples) descritas en este artículo comenzarán a desempeñar un papel más importante.
Enlace original:
https://vitalik.ca/general/2022/09/17/layer_3.html
**Este artículo solo representa las opiniones del autor original y no constituye ninguna opinión o recomendación de inversión.
-FIN-
[El propósito de la publicación de artículos es difundir información más valiosa. Los derechos de autor del artículo pertenecen al autor original. Su contenido y opiniones no representan la posición de Unitimes. Todas las imágenes que aparecen en esta plataforma WeChat se recopilan de Internet y los derechos de autor pertenecen al propietario de los derechos de autor. Si el propietario de los derechos de autor cree que su trabajo no es adecuado para que todos lo naveguen o no debe usarse de forma gratuita, agregue WeChat uniforms2018. para contactarnos, y esta plataforma hará las correcciones de inmediato. 】
Simplemente haz clic en " Me gusta " cuando vengas.
