Fuente |vitalik.ca

Autor | Vitalik Buterin

Un agradecimiento especial a Georgios Konstantopoulos, Karl Floersch y al equipo de Starkware por sus comentarios y revisión.

Un tema que aparece a menudo en las discusiones sobre expansión L2 es el concepto de "capa3 (L3)". Si podemos construir un protocolo L2 que ancle la seguridad L1 y le agregue escalabilidad, entonces ciertamente podemos construir un protocolo L3 que ancle la seguridad L2 y le agregue más escalabilidad, para lograr una mayor expansión.

Brevemente, la idea es la siguiente: si tiene una solución que le permite escalar cuadráticamente, ¿puede construir esa solución sobre sí misma y escalar exponencialmente?

Hice puntos similares en mi artículo sobre escalabilidad de 2015, la idea de escalado multicapa en el artículo de Plasma y otros lugares. Desafortunadamente, esta simple concepción de L3 no se implementa tan fácilmente como el punto anterior.

Siempre hay algunas cosas en el diseño de esta solución que no se pueden apilar directamente y solo pueden generar una única mejora en la escalabilidad, debido a limitaciones en la disponibilidad de datos, retiros de emergencia que dependen de la banda ancha L1 y otros problemas.

Las vistas más nuevas sobre L3, como el marco propuesto por Starkware, son más complejas: estas soluciones L3 no solo apilan la misma solución encima de su propia red, sino que asignan diferentes usos para L2 y L3. Alguna forma de este enfoque podría ser una buena idea, si pudiera implementarse de la manera correcta. Este artículo detallará lo que puede tener sentido y lo que no en una arquitectura de tres niveles.

(Nota del traductor: versión china del artículo anterior de StarkWare "Expansión fractal: de L2 a L3")

¿Por qué no siempre puedo escalar apilando paquetes acumulativos encima de otros?

Rollup (lea un artículo más extenso sobre rollup aquí. Nota del traductor: la versión china del artículo vinculado "Vitalik: una guía incompleta para rollups") es una tecnología de expansión que combina varias tecnologías para resolver los dos principales cuellos de botella de expansión en el funcionamiento de blockchain: la informática. y datos. El cálculo se puede resolver mediante pruebas de fraude o SNARK (Nota del traductor: la versión china del artículo vinculado está aquí), los cuales dependen de muy pocos actores para procesar y verificar cada bloque, y solo requieren que otros participantes ejecuten una pequeña porción de. el cálculo para comprobar que la prueba se completó correctamente.

Estos esquemas, especialmente los SNARK, son casi infinitamente escalables, y realmente se puede escalar más potencia informática en una sola prueba simplemente siguiendo construyendo "múltiples pruebas SNARK encima de una prueba SNARK".

Los datos son diferentes. El rollup utiliza una serie de técnicas de compresión para reducir la cantidad de datos necesarios para almacenar una transacción en la cadena: una simple transferencia de moneda se reduce de aproximadamente 100 bytes a aproximadamente 16 bytes, una generación ERC-20 en una cadena compatible con EVM. se reducen de aproximadamente 180 bytes a aproximadamente 23 bytes, mientras que una transacción ZK-SNARK que preserva la privacidad se puede comprimir de aproximadamente 600 bytes a aproximadamente 80 bytes.

Básicamente, los datos en todos los casos se pueden comprimir a 1/8 de su tamaño original. Sin embargo, el resumen aún necesita que los datos estén disponibles en la cadena en un intermediario para garantizar que los usuarios puedan acceder a ellos y verificarlos. Por lo tanto, los usuarios pueden calcular de forma independiente el estado del resumen y usarlo como prueba cuando el generador de pruebas existente se desconecta. El generador se une al proceso de prueba.

Los datos solo se pueden comprimir una vez y no se pueden volver a comprimir; si los datos se pueden comprimir nuevamente, entonces generalmente hay una manera de poner la lógica del segundo compresor en la lógica del primero, y solo es necesario comprimir una vez para hacer el segundo compresor O el mismo efecto que el primer compresor. Entonces, de hecho, "crear un resumen sobre otro" no proporciona grandes ganancias en escalabilidad; sin embargo, este patrón se puede usar para otros propósitos, como veremos a continuación.

Entonces, ¿cómo es una versión L3 "razonable"?

Bueno, echemos un vistazo a lo que StarkWare defiende en su artículo sobre L3 (Nota del traductor: la versión china del artículo está arriba). El equipo de StarkWare está formado por criptógrafos muy inteligentes y realmente cuerdos, por lo que si abogan por L3, entonces su punto de vista es mejor que "si los datos del resumen se comprimen a 1/8, entonces es obvio que el resumen es construido sobre el paquete acumulativo" La idea de que los datos se compriman a 1/64" de su tamaño original es más compleja.

Aquí está el diagrama del artículo de StarkWare:

Aquí hay algunas citas:

Un ejemplo de dicho ecosistema se muestra en el primer diagrama de ejemplo, cuyo L3 incluye:

● StarkNet, que utiliza el plan de disponibilidad de datos Validium, por ejemplo, proporciona múltiples usos para aplicaciones que son extremadamente sensibles a los precios.

●Los sistemas StarkNet específicos de la aplicación se pueden personalizar para mejorar el rendimiento de la aplicación, por ejemplo, utilizando estructuras de almacenamiento específicas o métodos de compresión de disponibilidad de datos.

● Los sistemas StarkEx que utilizan soluciones de disponibilidad de datos Validium o Rollup (como los que sirven a dYdX, Sorare, Immutable y DeversiFi) traerán rápidamente beneficios de escalabilidad a largo plazo a StarkNet.

●Los ejemplos de privacidad de StarkNet (también como L4 en este ejemplo) permiten transacciones que preservan la privacidad sin empaquetar las transacciones en StarkNet público.

Podemos condensar este artículo en tres visiones de los “L3”:

L2 se usa para expansión y L3 se usa para funciones de personalización como la privacidad. Esta visión de L3 no pretende proporcionar "escalabilidad al cuadrado", sino que habrá una capa de la pila para ayudar a escalar la aplicación, y luego habrá capas de pila independientes para personalizar la funcionalidad para satisfacer las necesidades de diferentes casos de uso.

L2 se usa para expansión general y L3 se usa para expansión personalizada. La expansión personalizada puede presentarse en diferentes formas: las aplicaciones dedicadas pueden usar máquinas virtuales distintas de EVM para los cálculos, y la compresión de datos acumulativos también se optimizará en torno a la estructura de datos de la aplicación personalizada (incluida la conversión de "datos" de "pruebas" separadas de ella). y reemplazando completamente todas las pruebas de transacción en ese bloque con un solo SNARK en cada bloque).

L2 se usa para expansión sin confianza (como rollup) y L3 se usa para expansión de confianza débil (como Validium). Los validiums se refieren a sistemas que utilizan SNARK para verificar los resultados de los cálculos, pero ponen la disponibilidad de los datos en manos de un tercero o comité de confianza. En mi opinión, Validium está muy subestimado: en particular, un servidor centralizado que ejecute el generador de pruebas Validium y envíe hashes a la cadena con regularidad podría realmente servir bien para muchas aplicaciones de "blockchain empresarial". Validium tiene un índice de seguridad más bajo que el rollup, pero es mucho más barato en comparación.

En mi opinión, estas tres visiones son intrínsecamente sólidas. La idea de que un servicio de compresión de datos dedicado/personalizado requiere su propia plataforma es probablemente la menos convincente de todas: es fácil diseñar una solución de compresión de capa base L2 de propósito general, porque los usuarios pueden usar un subcompresor específico de la aplicación, pero hay otros casos de uso. son razonables. Pero todavía queda una gran pregunta: ¿Es una estructura de tres niveles la forma correcta de lograr estos objetivos? ¿Cuál es el punto de anclar Validium, los sistemas de privacidad y los entornos personalizados a L2 en lugar de solo a L1? La respuesta a esta pregunta es complicada.

¿Cuál es mejor?

¿Los depósitos y retiros serán más baratos y fáciles en los subárboles de L2?

Un argumento a favor de este modelo de tres niveles frente al modelo de dos niveles podría ser que el modelo de tres niveles permite que todo el subecosistema exista en un solo paquete acumulativo, lo que permite que las operaciones entre dominios dentro del ecosistema se realicen de manera muy económica sin pasando por la costosa L1.

¡Pero resulta que los depósitos y retiros pueden ser baratos incluso entre dos L2 (o incluso L3) que envían datos al mismo L1! La clave es darse cuenta de que los tokens y otros activos no necesariamente tienen que emitirse en la cadena subyacente. En otras palabras, puede tener un token ERC20 en Arbitrum, luego crear su contrato contenedor en Optimism y transferir activos entre los dos sin crear ninguna transacción L1.

Veamos cómo funcionaría un sistema así. Ahora existen dos tipos de contratos inteligentes: el contrato base en Arbitrum y el contrato token wrapper en Optimism. Para transferir activos de Arbitrum a Optimism, debe enviar tokens al contrato subyacente, que genera un recibo. Una vez que Arbitrum finaliza la transacción, puede tomar la prueba Merkle de ese recibo, que tiene su raíz en el estado L1, y enviarla al contrato de encapsulación de tokens en Optimism. El contrato de envoltorio lo verificará y le emitirá el token de envoltorio. Para transferir tokens nuevamente, puede realizar la misma operación a la inversa.

Mientras que la ruta Merkle requerida para probar un depósito Arbitrum verifica el estado de L1, Optimism solo necesita leer la raíz del estado L1 para procesar el depósito; no es necesario crear transacciones L1. Tenga en cuenta que, dado que los datos acumulados son el recurso más escaso, una implementación viable de dicho esquema sería utilizar pruebas SNARK o KZG para ahorrar espacio, en lugar de utilizar directamente pruebas Merkle.

En comparación con los tokens basados ​​en L1, esta solución tiene una debilidad clave, al menos en los rollups optimistas: los depósitos también deben esperar a que llegue la ventana a prueba de fraude. Si el token está en L1, los retiros de Arbitrum u Optimism a L1 tendrán un retraso de una semana, mientras que los depósitos son instantáneos.

Sin embargo, tanto los depósitos como los retiros en este esquema demoran una semana. Dicho esto, no está claro si una arquitectura de tres niveles con acumulación optimista sería mejor: existen muchas complejidades técnicas para garantizar que el juego a prueba de fraude se desarrolle de forma segura dentro de un sistema que ejecuta su propio mecanismo a prueba de fraude.

Afortunadamente, ninguno de estos problemas ocurre con el resumen de ZK. Por razones de seguridad, los paquetes acumulativos de ZK no requieren un período de espera de una semana, pero sí tienen requisitos de período más cortos (la tecnología de primera generación puede requerir un período de espera de 12 horas).

Hay dos razones, especialmente el paquete acumulativo ZK-EVM de uso general más complejo, que lleva más tiempo incluir el tiempo de cálculo no paralelo en el proceso de prueba de bloques. En segundo lugar, también hay consideraciones económicas: es necesario; Presentar pruebas con menos frecuencia para minimizar los gastos generales fijos asociados con las transacciones de prueba. La tecnología ZK-EVM de próxima generación, que incluye hardware especializado, resolverá el primer problema mencionado anteriormente, mientras que una tecnología de verificación por lotes mejor diseñada puede resolver el segundo problema. En realidad, se trata de una cuestión de optimización y prueba de envío por lotes que analizaremos a continuación.

Período de confirmación versus compensación de gastos generales fijos para acumulación y validación. Los L3 pueden ayudar a resolver este problema, pero ¿qué otras soluciones pueden ayudar?

La sobrecarga del resumen por transacción es económica: sólo entre 16 y 60 bytes de datos, dependiendo de la aplicación utilizada. Pero el rollup también debe pagar un alto costo fijo cada vez que se envía un lote de transacciones a la cadena: el rollup optimista paga 21,000 L1 de gas por lote, mientras que el rollup ZK paga más de 400,000 gas (si solo desea utilizar tecnología Quantum-safe como STARK puede requerir millones de pagos de gas).

Por supuesto, el resumen puede optar por esperar hasta que haya transacciones L2 por valor de 10 millones de gas antes de empaquetar y enviar el lote, pero esto hará que el intervalo del lote del resumen sea muy largo, lo que obligará a los usuarios a esperar más antes de obtener una confirmación de alta seguridad. Por lo tanto, tienen desventajas: intervalos de lotes largos y gastos generales óptimos, o intervalos de lotes más cortos y gastos generales mucho mayores.

Para poner algunos números concretos en perspectiva, exploremos un paquete acumulativo de ZK que cuesta 600.000 gas por lote, maneja transferencias ERC-20 totalmente optimizadas (23 bytes) y cuesta 368 gas por transacción. Supongamos que este paquete acumulativo tiene una transacción promedio por segundo (TPS) de 5 en las etapas inicial y media de adopción. Podemos calcular su intervalo de gas versus lote por transacción:

Si entramos en un sistema con muchos validium personalizados y entornos específicos de aplicaciones, la mayoría de ellos no manejarán más de 5 TPS. Por lo tanto, el equilibrio entre el tiempo de confirmación y los gastos generales comienza a ser crítico. De hecho, ¡el paradigma "L3" puede resolver el problema de la compensación! Incluso si se implementa de una manera simple, la solución de un paquete acumulativo ZK anidado dentro de otro paquete acumulativo ZK tendrá una sobrecarga fija de solo aproximadamente 8000 L1 de gas (la prueba ocupa 500 bytes). Esto cambia la tabla anterior a:

El problema de los costes básicamente se ha resuelto. Entonces, ¿es beneficiosa la L3? Tal vez. Pero vale la pena señalar que hay una manera de resolver este problema, que está inspirada en la verificación agregada ERC 4337.

Las contramedidas son las siguientes. Ahora, si cada rollup o validium de ZK recibe la prueba de que Snew=STF(Vendido,D), es decir, el nuevo estado debe ser el resultado del procesamiento correcto de los datos de la transacción o de la transformación del estado en la raíz del estado anterior, entonces lo harán. recibir la raíz del estado.

En este nuevo esquema, el resumen de ZK recibirá un mensaje del contrato del validador de lotes. Este mensaje se utiliza para informar al validador que ha verificado una prueba de lote que contiene reclamaciones, cada una de las cuales tiene el formato Snew=STF(Vendido, D). Esta prueba por lotes se puede construir mediante un esquema SNARK recursivo o agregación Halo.

Este es un protocolo abierto: cualquier ZK-rollup puede unirse, y los productores de pruebas de cualquier lote pueden agregar pruebas de cualquier ZK-rollup compatible y recibir una compensación por las tarifas de transacción del agregador. El contrato del procesador por lotes verificará la prueba una vez y luego pasará el mensaje que contiene el triple acumulado $(S_{old},S_{new},D)$ a cada paquete acumulativo. El triple proviene del procesador por lotes. Los hechos del contrato; será evidencia de la validez de la transacción.

Si se optimiza bien, el costo de cada acumulación en este esquema es de casi 8000 gas: 5000 para escribir el estado actualizado recién agregado, 1280 para la raíz del estado anterior y la raíz del nuevo estado, y los 1720 restantes para validar Utilice todo tipo de datos. Por tanto, esta solución también puede ahorrar costes.

De hecho, StarkWare ya tiene un esquema similar llamado SHARP, aunque aún no es un protocolo abierto sin permiso.

Una reacción a este tipo de enfoque podría ser: ¿Pero no es ésta simplemente otra solución L3? En lugar de la estructura de la capa base <- rollup <- validium (capa base ← rollup ← validium), tiene la capa base <- mecanismo por lotes <- rollup o validium (capa base ← mecanismo por lotes ← rollup o validium).

Desde algún punto de vista arquitectónico filosófico, esto puede ser cierto. Pero aquí hay una diferencia importante: en lugar de tratar la capa intermedia como un sistema EVM complejo y completo, es un objeto simplificado y altamente especializado, por lo que es más probable que sea seguro y que no necesite nada más. Construido sin tokens especializados, también es más probable que la gobernanza sea mínima y no cambie con el tiempo.

Resumen: ¿Qué son realmente las "capas"?

Una arquitectura de escalamiento de tres capas que apila la misma solución de escalado encima de su propia red generalmente no funciona bien. Rollup construido sobre rollup, estas dos capas de rollup ciertamente no utilizan la misma tecnología.

Sin embargo, es posible utilizar una arquitectura de tres niveles donde el segundo y tercer nivel tienen diferentes propósitos. Validium construido sobre paquetes acumulativos tiene sentido, incluso si no se sabe si serán la mejor manera de trabajar a largo plazo.

Sin embargo, una vez que empezamos a investigar qué tipo de arquitectura tiene sentido, nos topamos con preguntas filosóficas: ¿Qué son "capas" y cuáles no? El modo de capa base <- mecanismo por lotes <- rollup o validium (capa base ← mecanismo por lotes ← rollup o validium) realiza el mismo trabajo que la capa base <- rollup <- rollup o validium (capa base ← rollup ← rollup o validium) modo. .

Pero en términos de cómo funciona, la capa de agregación de pruebas se parece más a ERC-4337 que a un resumen. Normalmente, no nos referiríamos a ERC-4337 como "L2". Del mismo modo, no llamaríamos a Tornado Cash “Capa 2”; por lo tanto, para mantener una categorización consistente, no llamaríamos al subsistema centrado en la privacidad construido sobre la L2 Capa 3. Por lo tanto, existe un debate semántico no resuelto sobre qué objetos deberían llamarse "capas" en primer lugar.

Puede haber muchas escuelas de pensamiento sobre este tema. Mi preferencia personal sería mantener el término L2 limitado a cosas que:

Su objetivo es aumentar la escalabilidad.

Siguen el modelo "blockchain dentro de blockchain": tienen sus propios mecanismos para manejar transacciones y estado interno.

Heredan completamente la seguridad de la blockchain Ethereum

Por lo tanto, el resumen optimista y el resumen ZK son L2, pero validium, esquemas de agregación de pruebas, ERC-4337, sistemas de privacidad en cadena y Solidity son otros esquemas. Podría tener sentido llamar L3 a algunas de estas soluciones, pero tal vez no a todas. En cualquier caso, podría ser prematuro definir un ecosistema multi-rollup antes de que se resuelva su arquitectura, y la mayor parte de la discusión es sólo teórica.

Es decir, el debate lingüístico es mucho menos importante que la cuestión técnica de qué estructura tiene realmente más sentido. Claramente, algún tipo de "capa" que atienda necesidades no escalables, como la privacidad, tiene un papel importante que desempeñar, y la importante función de agregación de pruebas obviamente debe cubrirse de alguna manera, una posición que se ocupa mejor mediante un protocolo abierto.

Pero al mismo tiempo, existen buenas razones técnicas para hacer que la capa intermedia entre el entorno de cara al usuario y L1 sea lo más fácil posible. En muchos casos, usar la "capa adhesiva" como un resumen de EVM puede no ser correcto. . A medida que madure el ecosistema de escalamiento L2, sospecho que las estructuras más complejas (y más simples) descritas en este artículo comenzarán a desempeñar un papel más importante.