Este artículo analiza las ideas de evolución y las razones de diseño de la solución de expansión Rollup.

Autor original: ORFEO

Fuente original: The SeeDAO

El proyecto L2 vuelve a estar en el punto de mira.

Como representante de la ruta de expansión de Rollup en L2, después del airdrop de Arbitrum, se lanzará la Era zkSync. Detrás de los interminables nuevos diseños y hojas de ruta, ¿cuál es la línea principal de Rollup y cuál es el pensamiento evolutivo? Echemos un vistazo hoy.

Puntos principales de este artículo:

• La idea de expansión de L1 escrita para el tercer grado.
• Diseñe una solución de resumen desde cero
• Cómo usar la prueba de conocimiento cero para hacer que Rollup evolucione nuevamente

Comenzando con una analogía

Para Bitcoin y Ethereum, desde su nacimiento, hay dos críticas más importantes de los usuarios comunes:

• Lento: El carril es originalmente angosto, y si hay demasiados autos, se bloqueará.
• Caro: los peajes en picos planos no son baratos. Si desea pasar rápidamente durante el período pico, debe usar la “capacidad de dinero” para agregar dinero y dejar que los mineros vuelen helicópteros para atraparlo.

Estas dos críticas se derivan de dos factores en el diseño de blockchain:

• Capacidad de bloqueo: de forma análoga a un carril, cuanto mayor sea la capacidad de bloqueo, más automóviles puede acomodar y es menos probable que se bloquee.
• Mecanismo de incentivo: no importa cuán grande sea el camino de entrada, existe la posibilidad de que se bloquee. En este caso, ¿quién puede pasar primero? Depende de quién tenga prisa, pero no puede simplemente escuchar las palabras de las personas. , depende de la disposición a pagar, como llamar a una ambulancia, serán varios cientos.

Si la cadena de bloques realmente puede ser como un camino de entrada, entonces la solución fundamental es, naturalmente, ampliar el camino de entrada y, al mismo tiempo, cooperar con los medios de precios para guiar el tiempo para salir, y no salgas si no estás en una apurarse.

Sin embargo, aunque ampliar los carriles y aumentar la capacidad de los bloques es una solución atractiva para la eficiencia del tráfico, es el último recurso en el diseño de cadenas de bloques. Debido a que cuanto mayor sea el tamaño del bloque, mayores serán los requisitos de hardware para los mineros y menos mineros podrán cumplir con los requisitos; de acuerdo con esta idea, si desea procesar miles de transacciones por segundo como Visa, solo terminará haciendo otra Visa centralizada va en contra del propósito central de la falta de confianza de blockchain.

hay alguna otra solucion? Sí, además de la orientación del tiempo, también podemos optimizar el espacio, incluidos, entre otros, los siguientes:

• Abrir diferentes carriles, uno para camiones grandes, uno para automóviles y otro para autobuses, sin interferir entre sí. Con base en esta idea, podemos llegar a algunas cadenas principales, cadenas laterales o Plasma con sus propias fortalezas.
• Optimice el diseño de la ruta, desvíe el tráfico adecuadamente, no vaya a la ciudad para hacer nada, debe tomar esta carretera principal, debe pasar por el puesto de control aquí —— Basado en esta idea, podemos fragmentar.
• ¿Por qué tienes que salir? No es demasiado tarde para tener una reunión remota y llegar a un acuerdo, y no es demasiado tarde para firmar un acuerdo fuera de línea. Con base en esta idea, podemos tener un canal estatal (State Channel).
• No necesariamente tienes que conducir solo cuando salgas, también puedes compartir el coche o tomar el transporte público —— En base a esta idea, tenemos al protagonista de este artículo, Rollup.

Como un autobús en la cadena de bloques, la clave de Rollup es ahorrar espacio y gasolina (gasolina, juego de palabras):

• Ahorre espacio, por lo que no es fácil quedarse atascado, y el peaje compartido por cada persona es mucho menor que conducir solo;
• Se ahorra gasolina, por lo que el precio del boleto está cerca de la gente y todos pueden pagarlo.

De esta forma, los dos slots de “lento” y “caro” son resueltos por Rollup.

Volvamos a la cadena de bloques y veamos el plan específico de Rollup.

Diseñe un Rollup desde cero;

En lugar de echar un vistazo a la respuesta estándar (sin mencionar que no hay), es mejor tener algo de suspenso e imaginar lo que hará cuando tenga la tarea de diseñar Rollup para Ethereum.

También podríamos comenzar desde las dos perspectivas de reducir los costos de computación (ahorrar gasolina) y reducir los costos de almacenamiento (ahorrar espacio), y primero proponer una solución más radical llamada Rollup 1.0;.

Resumen 1.0;

Rollup 1.0 consta de 3 puntos principales:

• Existe un proveedor de servicios (Operador) que recopila las transacciones de “carpooling” (Transacción) de todos y “envía órdenes” cuando el carpool está lleno o no pero se cumple el tiempo acordado, teniendo en cuenta el precio y la puntualidad;
• Todos los cálculos involucrados en las transacciones enviadas por todos los realiza este proveedor de servicios fuera de la cadena, porque los cálculos fuera de la cadena son más rápidos que los dentro de la cadena, y los cálculos suelen ser la mayor parte de los costos dentro de la cadena, lo que puede ahorrar una gran cantidad de dinero;
• Después del cálculo, obtenga el estado actualizado (como el último saldo en su cuenta) y guárdelo en la cadena, para que el costo de almacenamiento sea mucho menor.

En pocas palabras, es recopilar de forma regular y cuantitativa las solicitudes de transacciones de todos, y después de los cálculos fuera de la cadena, solo los resultados de los cálculos se solidifican en la cadena.

Esta solución resuelve perfectamente los dos principales puntos débiles de “lento” y “caro”, pero parece generar nuevos problemas:

• Incentivo: Quién brindará el servicio de “carpooling” y cuáles son los beneficios.
• Problema de revisión (Censura): El proveedor de servicios deliberadamente no procesa mi pedido (o cuelga o se cierra), ¿qué debo hacer?
• Problema de fraude (Fraude): ¿Qué debo hacer si el proveedor de servicios engaña y manipula los resultados de los cálculos, lo que hace que transfiera dinero a otros, y él malversa el dinero?

Para estos tres nuevos problemas, podemos iterar una versión del plan.

Resumen 2.0;

El problema de la motivación se resuelve mejor, y los problemas que se pueden resolver con dinero no son problemas. El proveedor de servicios puede compartir el costo del “carpooling” en partes iguales y cobrar una pequeña “propina” adicional. Aun así, sigue siendo una situación en la que todos ganan con la persona que “carpooling”.

El problema de la revisión es un poco más problemático, pero la solución es muy común en el campo de la cadena de bloques y es la descentralización. Un grupo de personas son proveedores de servicios, lo cual es mejor que un solo proveedor de servicios; cualquiera puede ser un proveedor de servicios, lo cual es mejor que un grupo fijo de personas. En la última forma de jugar, si todos los proveedores de servicios no son buenos, usted también puede ser un proveedor de servicios o ir directamente a L1 para iniciar el arbitraje.

El fraude es un poco más difícil. Se puede dividir en dos preguntas: una es cómo identificar el fraude y la otra es cómo prevenirlo.

En primer lugar, para identificar el fraude, necesitamos conocer los datos de transacción (Transacción) de todos, el estado antes de la transacción (Estado), para calcular el nuevo estado (Estado’) después de la transacción y compararlo con el nuevo estado almacenado en la cadena del proveedor de servicios. Si es el mismo, significa que el proveedor de servicios es honesto, de lo contrario, significa que mintió. Sin embargo, no conocemos los datos de la transacción porque no están en la cadena. Como resultado, solo podemos ser escépticos e incapaces de juzgar si el proveedor de servicios es honesto o no.

Entonces, la mejor manera de prevenir el fraude es imposibilitar que ocurra el fraude. Esto es relativamente difícil, a menos que se verifique el cálculo del proveedor de servicios cada vez en la cadena, pero de esta manera, no habrá ninguna ventaja de " compartir coche". Por lo tanto, solo podemos dar un paso atrás y hacer que el costo del fraude sea muy alto, de modo que los proveedores de servicios tengan un pellejo en el juego, como pagar un depósito (Stake), que será confiscado si se encuentra un fraude. (Este método se llama consenso social, que pertenece a la seguridad basada en juegos, y también se menciona en “Weekly #3;”.)

Resumen 3.0;

Rollup 2.0 no está mal, pero el problema de identificar el fraude no está resuelto.

De acuerdo con la inferencia anterior, para identificar el fraude, debemos conocer los datos de la transacción, por lo que esta parte de los datos debe estar en la misma cadena que los datos de estado.

¿Quién se va a enterar de que son fraudulentos? Obviamente, es poco probable que se trate de un usuario común, ya que es imposible que todos puedan monitorear cada movimiento del proveedor de servicios las 7; x; 24 horas, por lo que solo puede ser un “cazarrecompensas” profesional (Validador). Si un “cazador de recompensas” informa un fraude dentro de los 7 días posteriores a que el proveedor de servicios “envíe la orden” y verifica que es cierto, la transacción se revertirá y el proveedor de servicios será sancionado. Por supuesto, de la misma manera, los “cazarrecompensas” también necesitan incentivos. Por ejemplo, después de que se descubre el fraude, una parte del depósito del proveedor del servicio se entregará al “cazarrecompensas” (solo una parte, para evitar la colusión entre el proveedor de servicios y el cazarrecompensas).

Resumen 4.0;

En la etapa de Rollup 3.0, toda la solución pudo funcionar sin problemas, pero se introdujeron nuevos costos. Los costos hasta ahora incluyen:

• Tarifas a los proveedores de servicios (incluidos costos y “propinas”);
• Costo de almacenamiento en cadena de datos de transacción y estado;
• Cuando el “Bounty Hunter” cree que el proveedor del servicio es fraudulento, el costo computacional de verificar lo que dijo es cierto en la cadena.

Echemos un vistazo a qué costos se pueden optimizar.

datos de la transacción

De manera específica, se agregan múltiples transacciones y el espacio ocupado puede ser menor que la suma del espacio ocupado por cada transacción.

Tomando como ejemplo la transacción de transferencia de ETH más simple, desmontamos la composición del contenido de cada transacción y podemos ver que el espacio de la firma representa la mayor proporción. Podemos combinar las firmas de todas las transacciones en una sola (agregación de claves), lo que ahorra una gran cantidad de gastos generales de almacenamiento (similar a Schnorr en Bitcoin). Además, también podemos optimizar otras partes, como deshacerse de Nonce, y elegir “gordo y delgado” tanto como sea posible cuando se “comparte el automóvil”, y una “persona que comparte el automóvil” que se ajuste perfectamente para maximizar el uso del “automóvil”. " espacio.

fuente:

Solo tres o dos veces, el tamaño de cada transacción de transferencia ETH se ha reducido de 112 bytes a 12 bytes, que es cerca de una décima parte de la anterior; por supuesto, existen otros medios para comprimir aún más los datos de la transacción.

En la operación real, podemos instalar dicho método en el contrato implementado en la cadena:

función storeTxData(bytes calldata data) external {;// no hacer nada}

Luego, cada vez que el “carpooling” tiene éxito, los datos de transacción combinados y comprimidos se pasan a este método como datos de llamada. Calldata no necesita almacenarse permanentemente, y después del Período de desafío de publicidad de consenso social (Período de desafío), no importará si se poda (Prune); el precio en sí es muy bajo y será más económico con la implementación de EIPs como Danksharding y Data Blob, esta forma de aplicar L1 a la distribución de almacenamiento de datos (Data Availability) también será más formal.

datos de estado

Ahora que los datos de la transacción se cargaron en la cadena, cualquiera puede calcular el estado actualizado a través de los datos de la transacción, y los datos del estado no son tan necesarios. Solo podemos conservar la Raíz de Merkel de los datos estatales, que se utiliza para permitir que los usuarios normales (“compartidores de vehículos compartidos”) soliciten retiros directamente a L1 cuando el proveedor de servicios no coopera, y confiar en Merkel Proof para demostrar que tienen dinero. en sus cuentas.

Costos de arbitraje de fraude

Cuando el “cazarrecompensas” informa de un fraude al proveedor de servicios, el cálculo del contrato en cadena (Repetición) se realiza una vez y se comparan los resultados del estado. Esto es teóricamente factible. Sin embargo, el costo de hacerlo no es bajo (aunque ya es bueno), y la segunda es que la suma del Gas de las transacciones incluidas en la “lista de carpooling” del Rollup puede exceder el límite de gas de Ethereum, imposibilitando para verificar.

Por lo tanto, el arbitraje debe reducir la carga, y la forma de reducir la carga es, naturalmente, poner operaciones de cálculo innecesarias fuera de la cadena. Una de las soluciones se llama Prueba Interactiva, el proceso general es el siguiente:

• “Bounty Hunter” paga un depósito, luego informa y divide todo el proceso de cálculo en n segmentos en orden, señalando que el proveedor de servicios tiene fraude en el segmento k (1;≤k≤n);
• El proveedor de servicios desglosó y desarmó el segmento k en el segmento k, y señaló qué segmento del “cazador de recompensas” era incorrecto;
• Entonces, de ida y vuelta, sabiendo que la operación de cálculo ya no se puede profundizar ni desmantelar, por ejemplo, cuando el “cazarrecompensas” piensa 1+;1;=;2;, el proveedor de servicios piensa 1+;1;= ;3;;
• En este momento interviene el contrato de la cadena, calcula 1+;1;, y obtiene 2;, determinando así que el proveedor del servicio es fraudulento, confiscando su depósito, y premiando una parte del mismo al “cazarrecompensas”.

(Durante todo el proceso, si una parte no responde después de un tiempo de espera, la parte falla).

De esta manera, el costo del arbitraje en toda la cadena es muy, muy bajo.

Habiendo dicho eso, hemos construido completamente una solución de resumen. Debido a que este esquema asume que el proveedor de servicios es honesto por defecto, a menos que haya un informe de “cazarrecompensas”, esta facción se llama el resumen del optimista, el llamado Resumen Optimista.

Entonces, ¿nuestro Rollup 4.0 es la mejor solución?

Rollup re-evolución

Después de nuestras múltiples iteraciones, Rollup 4.0 todavía tiene algunas imperfecciones:

• El fraude debe ser descubierto por los “cazarrecompensas”, pero si no hay fraude durante mucho tiempo, los “cazarrecompensas” pueden quebrar porque no son rentables, por lo que habrá una brecha (aunque poco probable, debido a la Las partes interesadas de la cadena acumulativa, como los proveedores de aplicaciones, probablemente actuarán como “cazarrecompensas”);
• Para estar seguro de que no hay fraude, basado en el consenso social, debe esperar varios días, lo que afectará operaciones como retiros;
• Hay muchos datos en la cadena y el costo sigue ahí;
• Actualmente, al depender de una capa de expansión de resumen, el rendimiento puede aumentarse 10 veces. ¿Es posible que sea mayor?

¿Existe una solución que pueda hacer que el fraude sea imposible en absoluto, hacer que la finalidad (Finality) sea más rápida, hacer que sea necesario cargar menos datos en la cadena y hacer que la expansión sea un orden de magnitud mayor? No quiero demasiado, pero hay un tipo de solución que puede satisfacer casi todas las imaginaciones: Zero Knowledge Rollup (ZK-Rollup para abreviar).

ZK-Rollup es una idea de resumen que utiliza prueba de conocimiento cero (ZKP). El llamado ZKP se refiere a la tecnología que convence a la otra parte de que conoce esta información sin revelar ninguna información confidencial. Para explicar ZKP, hay dos de mis ejemplos favoritos:

*Imagínese en una ciudad europea medieval y tengo un mapa del tesoro con un tesoro marcado en él. Para demostrarte que tengo un mapa del tesoro, pero sin dejarte saber la ubicación exacta del tesoro, te pongo una venda en los ojos, te arrastro a un carruaje y conduzco por la ciudad durante media hora para asegurarme. pierde el sentido de la dirección, finalmente llega al destino, sal del auto y te muestra el tesoro, y luego te lleva de regreso. Esta es una forma ingenua de ZKP.

• Otra analogía es más común. Supongamos que hay un Sudoku, yo sé la respuesta pero tú no, pero tú no crees que yo lo sepa; quiero demostrarte que lo sé, pero no quiero que sepas la respuesta. ¿qué hacer? Puedo poner Sudoku en la mesa con cartas, y luego poner los números abiertos hacia arriba y los números que deben completarse hacia abajo, y permitirle elegir verificar mi respuesta por fila o columna. Si es por fila, agruparé los números de cada fila, los dividiré y mostraré que cada fila es del 1 al 9;. Está bien repetirlo varias veces, así que puedes creer que realmente sé la respuesta con una alta probabilidad. Este es uno de los métodos de prueba interactivos de ZKP (debido a que es difícil lograr una interacción en cadena en tiempo real en la cadena de bloques, generalmente se usa una prueba no interactiva y la función Hash genera desafíos aleatorios).

En términos menos rigurosos, la idea central de ZKP es que el probador (Prover) primero oculta el conocimiento secreto, “compromete” (Commit), y luego el verificador (Verifier) inicia un desafío aleatorio (Challenge). si puede pasar con éxito el desafío, entonces hay una alta probabilidad de que tenga el conocimiento secreto correspondiente.

ZKP debe cumplir 3 requisitos:

• Si el probador miente, hay una alta probabilidad de fallar el desafío (Sólida);
• Si el probador tiene conocimiento, podrá pasar el desafío (Integridad);
• Durante la interacción entre las dos partes, el probador no divulgará ninguna información útil (conocimiento cero).

Para cumplir con estos tres requisitos, ZKP utiliza una variedad de problemas NP, incluida la descomposición de números primos más simple y logaritmos discretos (como el de Schnorr), etc.

ZKP no es una tecnología nacida para blockchain, pero puede usarse para la expansión L2, principalmente porque un buen ZKP tiene las siguientes características útiles:

• El probador (proveedor de servicios) puede proporcionar rápidamente una prueba, para garantizar que la eficiencia de cálculo en la cadena sea muy alta y no se convierta en un cuello de botella;
• El tamaño de la prueba es pequeño, o al menos proporcional a la cantidad de cálculo a probar, y el impacto de la cantidad de datos es lo más pequeño posible, por lo que el costo de almacenamiento en la cadena es bajo;
• El verificador (contrato L1) puede verificar rápidamente si la prueba es válida, por lo que el costo de cálculo en la cadena es bajo.

Con estas características, nuestra solución de resumen puede:

• No hay necesidad de un “cazador de recompensas”, el contrato L1 puede detectar el fraude en el acto por sí mismo;
• Siempre que la verificación ZKP sea válida, los retiros se pueden realizar de inmediato y la finalidad se reduce de días a minutos;
• Solo se requiere la diferencia entre estados en la cadena, el espacio es muy pequeño y el costo de almacenamiento es muy bajo (una ventaja adicional: también se mejora la privacidad);
• A través de la optimización personalizada de software y hardware del proceso de prueba y verificación, la capacidad de expansión se puede aumentar en otro orden de magnitud.

Por supuesto, cualquier mecanismo de seguridad tendrá requisitos previos potenciales, y ZKP no es una panacea para la cadena de bloques. ZKP todavía tiene muchas limitaciones en la actualidad, que deben superarse paso a paso, tales como:

• Tome como ejemplo el zk-SNARK más utilizado en la cadena de bloques. Muchos esquemas necesitan presentar tantas personas o empresas prestigiosas como sea posible al principio, y hacer una Configuración de confianza para generar un número aleatorio verdadero y garantizar que el proceso de generación sea verificable pero no completamente público (como en la ceremonia del Poder de Tau, siempre que se pueda confiar en una de las partes, pero aún cuenta como un defecto). Por supuesto, algunos esquemas zk-SNARK nuevos y zk-STARK mejorados posteriormente pueden resolver este problema, pero a veces se introducen nuevos problemas.
• Muchos problemas son difíciles de resumir como problemas de ZKP, lo que ha llevado a que la programabilidad no se haya resuelto bien durante mucho tiempo. Es difícil realizar ZKP que sea totalmente compatible con EVM en Ethereum, o incluso si puede ser logrado, pero otros aspectos (como la eficiencia de la verificación) se verán afectados.

fuente:

Por eso, en ZK-Rollup, un campo de expansión orientado al futuro, cada progreso es encomiable y gratificante.

fuente:

escribir al final

En lo que respecta al futuro de la expansión de la capacidad, el autor cree que, en comparación con la expansión de la capacidad nativa de L1, el diseño en capas que incluye el resumen es una idea más confiable. Modularización, cada capa resuelve las preocupaciones de cada capa, lo que es menos arriesgado que el apilamiento continuo en el ya “monolítico” L1; además, es poco probable teóricamente que la descentralización del L1 subyacente debido a la expansión de la capacidad sea La capa superior lo encuentra y lo hace arriba Además, esta idea de diseño en capas tiene aplicaciones aparentemente exitosas en campos distintos al blockchain. El punto de vista no es necesariamente correcto, pero esta es la cognición actual del autor.

Este artículo intenta resolver las razones de pensamiento y diseño de la solución de expansión de Rollup en un tono agnóstico del proyecto. Debido al nivel limitado, algunos lugares todavía son un poco contundentes, lo que puede no solo dejar de explicar en el lugar, sino que también aumenta la dificultad de comprensión; como un campo vertical que cambia cada día que pasa, el autor puede no ser consciente. de y tener en cuenta muchos nuevos desarrollos en el tiempo. Sinceramente bienvenidos amigos para corregir y comunicarse.