Escrito por: Hakeen
1. Hoja de ruta de actualización de Ethereum M2SVPS
La fusión
En la fase de fusión, el mecanismo de consenso de POW pasará a POS y las cadenas de balizas se fusionarán. Para facilitar la comprensión, simplificamos la estructura de Ethereum en la siguiente figura:
Primero definamos aquí qué es la fragmentación: una comprensión simple es el proceso de dividir horizontalmente la base de datos para distribuir la carga.
Después de cambiar a POS: los proponentes de bloques y los validadores de bloques se separan y el flujo de trabajo de POS es el siguiente (entendido según la figura anterior):
Las transacciones se confirman en Rollup Validadores agregan transacciones a bloques de fragmentos La cadena de baliza selecciona validadores para proponer nuevos bloques Los validadores restantes forman comités aleatorios y validan propuestas en fragmentos
Tanto la propuesta de un bloque como la demostración de la propuesta deben completarse en un espacio, normalmente 12 segundos. Cada 32 espacios forman un ciclo de época, y cada época interrumpirá la clasificación del validador y reelegirá al comité.
Después de la fusión, Ethereum implementará la separación entre proponente y constructor (PBS) para la capa de consenso. Vitalik cree que el objetivo final de todas las cadenas de bloques será tener una producción de bloques centralizada y una verificación de bloques descentralizada. Dado que los datos de los bloques de Ethereum fragmentados son muy densos, la centralización de la producción de bloques es necesaria debido a los altos requisitos de disponibilidad de datos. Al mismo tiempo, debe haber una manera de mantener un conjunto descentralizado de validadores que puedan validar bloques y realizar muestreos de disponibilidad de datos.
Los mineros y la verificación de bloques están separados. Los mineros construyen bloques y luego los envían a los validadores. Los validadores pujan por seleccionar sus propios bloques y luego votan para decidir si el bloque es válido.
La fragmentación es un método de partición que puede distribuir tareas informáticas y cargas de trabajo de almacenamiento en una red P2P. Después de este método de procesamiento, cada nodo no necesita ser responsable de procesar la carga de transacciones de toda la red, solo necesita mantener la información relacionada. su partición (o información de fragmentación) es suficiente. Cada fragmento tiene su propia red de validadores o nodos.
Problemas de seguridad relacionados con la fragmentación: por ejemplo, si toda la red tiene 10 cadenas de fragmentos, destruir toda la red requiere el 51 % de la potencia informática, y luego destruir un solo fragmento solo requiere el 5,1 % de la potencia informática. Por lo tanto, las mejoras posteriores incluyen un algoritmo SSF, que puede prevenir eficazmente ataques del 51% de la potencia informática. Según el resumen de Vitalik, pasar a SSF es una hoja de ruta de varios años. Incluso si actualmente se realiza mucho trabajo, será uno de los cambios más importantes implementados más adelante en Ethereum y estará muy por detrás del mecanismo de prueba PoS, fragmentación y fragmentación de Ethereum. Árbol Verkle después del despliegue completo.
La cadena de balizas es responsable de generar números aleatorios, asignar nodos a fragmentos, capturar instantáneas de fragmentos individuales y varias otras funciones. Es responsable de completar la comunicación entre fragmentos y coordinar la sincronización de la red.
Los pasos de ejecución de la cadena de balizas son los siguientes:
El productor del bloque confirma el encabezado del bloque junto con la oferta. El bloqueador (verificador) en la cadena de baliza selecciona el encabezado del bloque ganador y la oferta, y recibirá incondicionalmente la tarifa de la oferta ganadora independientemente de si el empaquetador de bloques finalmente genera el cuerpo del bloque. El comité (seleccionado aleatoriamente entre los validadores) vota para confirmar el encabezado del bloque obtenido. El empaquetador de bloques revela el cuerpo del bloque.
La oleada
El objetivo principal de esta ruta es impulsar el escalado centrado en Rollup. Surge se refiere a la adición de fragmentación de Ethereum, una solución de escalamiento que, según la Fundación Ethereum, permitirá aún más una cadena de bloques de segunda capa con tarifas de gas bajas, reducirá el costo de las transacciones acumuladas o agrupadas y facilitará a los usuarios operar nodos que protegen. la red Ethereum.
El diagrama aún se puede entender a través del siguiente diagrama simplificado:
Tome el principio operativo de zkrollup como ejemplo: zkrollup se divide en un secuenciador y un agregador. El secuenciador es responsable de clasificar las transacciones del usuario, empaquetarlas en lotes y enviarlas al agregador. El agregador ejecuta la transacción, comenzando desde la raíz del estado anterior (raíz del estado anterior), generando la raíz del estado posterior (raíz del estado posterior) y luego genera la prueba (prueba). El agregador finalmente envía la raíz del estado anterior y la raíz del estado posterior. , datos de la transacción y prueba a L1 El contrato es responsable de verificar si el certificado es válido y los datos de la transacción se almacenan en calldata. La disponibilidad de datos de Zkrollup permite a cualquiera restaurar el estado global de la cuenta en función de los datos de transacciones almacenados en la cadena.
Sin embargo, el costo de usar datos de llamada es muy elevado, por lo que todo el protocolo EIP-4844 (que puede cambiar en cualquier momento) propone cambiar el tamaño del bloque de transacciones a 1 ~ 2 MB, sentando una base sólida para futuras acumulaciones y fragmentación de datos. . El tamaño de bloque actual de Ethereum es de aproximadamente 60 KB ~ 100 KB. Tomando EIP-4844 como ejemplo, el límite de tamaño de bloque se puede aumentar entre 10 y 34 veces. Este formato de bloque se llama blob (también llamado fragmento de datos).
El azote
En esta etapa, Scourge es un complemento de la hoja de ruta y se utiliza principalmente para resolver problemas MEV. Entonces, ¿qué es MEV?
El nombre completo de MEV es Valor extraíble minero / Valor extraíble máximo. Este concepto se aplicó por primera vez en el contexto de la prueba de trabajo y originalmente se llamó "Valor extraíble minero". Esto se debe a que en la prueba de trabajo, los mineros dominan capacidades de roles como la inclusión, exclusión y ordenación de transacciones. Sin embargo, después de la transición a Prueba de participación mediante fusión, los validadores serán responsables de estos roles y la minería ya no se aplicará (el método de extracción de valor presentado aquí permanecerá después de esta transición, de ahí la necesidad de un cambio de nombre). Para seguir utilizando el mismo acrónimo para garantizar la continuidad manteniendo el mismo significado básico, ahora se utiliza "Valor máximo extraíble" como una alternativa más inclusiva.
El espacio de arbitraje incluye:
Al comprimir el espacio de almacenamiento, se obtiene la diferencia de precio de las tarifas del gas; Árbitro adelantado: búsqueda exhaustiva de transacciones en mempool, la máquina realiza cálculos localmente para ver si es rentable y, de ser así, inicia la misma transacción con la suya propia. dirección y utilizar tarifas de gas más altas; encontrar objetivos de liquidación: los robots compiten para analizar los datos de la cadena de bloques lo más rápido posible para determinar qué prestatarios pueden ser liquidados y luego ser los primeros en presentar una transacción de liquidación y cobrar las tarifas de liquidación ellos mismos. Transacciones sándwich: los buscadores monitorean transacciones grandes en DEX en el mempool. Por ejemplo, alguien quiere comprar 10.000 UNI usando DAI en Uniswap. Transacciones tan grandes tendrían un impacto significativo en el par UNI/DAI, aumentando potencialmente significativamente el precio de UNI en relación con DAI. El buscador puede calcular el impacto aproximado en el precio de esta gran transacción en el par UNI/DAI y ejecutar la orden de compra óptima inmediatamente antes de la gran transacción para comprar UNI a un precio bajo, y luego ejecutar la orden de venta inmediatamente después de la gran transacción. y el pedido grande resulta en un precio de venta más alto.
Desventajas de MEV:
Algunas formas de MEV, como las transacciones sándwich, pueden resultar en una experiencia de usuario significativamente peor. Los usuarios atrapados en el medio enfrentan un mayor deslizamiento y una peor ejecución comercial. En la capa de red, los pioneros generales y las subastas de tarifas mineras en las que a menudo participan (cuando dos o más pioneros aumentan gradualmente las tarifas mineras de sus propias transacciones, de modo que sus transacciones se empaquetan en el siguiente bloque), conducen a la red. congestión y altas tarifas mineras de otros que intentan realizar transacciones normales. Además de lo que ocurre dentro de un bloque, MEV también puede tener efectos nocivos entre bloques. Si el MEV disponible en un bloque excede significativamente la recompensa del bloque estándar, los mineros pueden verse incentivados a reminar el bloque y capturar MEV por sí mismos, lo que lleva a la reorganización de la cadena de bloques y a la inestabilidad del consenso.
La mayor parte del MEV es extraída por participantes independientes de la red llamados "buscadores". Los buscadores ejecutan algoritmos complejos en los datos de blockchain para detectar oportunidades MEV rentables, y hay robots que envían automáticamente estas transacciones rentables a la red. El problema MEV en Ethereum implica el uso de bots para explotar las transacciones de la red, provocando congestión y tarifas elevadas.
El borde
Verge implementará el "árbol Verkle" (una prueba matemática) y el "cliente sin estado". Estas actualizaciones técnicas permitirán a los usuarios convertirse en validadores de redes sin tener que almacenar grandes cantidades de datos en sus máquinas. Este es también uno de los pasos de la expansión acumulativa. Como se mencionó anteriormente, el principio de funcionamiento simple de zk rollup es que el agregador envía la prueba y el contrato de verificación en la capa 1 solo necesita verificar el compromiso KZG en el blob y el generado. prueba. A continuación se ofrece una breve introducción al compromiso de KZG, que es garantizar que todas las transacciones estén incluidas. Debido a que el resumen puede enviar transacciones parciales y generar pruebas, si se utiliza KZG, se garantizará que todas las transacciones se incluyan para generar pruebas.
The Verge asegura que la verificación es muy simple. Solo necesita descargar N bytes de datos y realizar cálculos básicos para verificar la prueba enviada por el paquete acumulativo.
Vale la pena mencionar que el paquete acumulativo ZK tiene muchas soluciones, como Stark, Snark o Bulletproof. Cada esquema tiene un enfoque diferente de prueba y verificación, por lo que existen compensaciones. Actualmente, los SNARK son más fáciles de usar que la tecnología STARK y la tecnología también es más completa. Por lo tanto, muchos proyectos utilizan SNARK al principio, pero con la iteración de la tecnología STARK, eventualmente recurrirán a STARK que sean resistentes a los ataques cuánticos. Aunque una de las principales mejoras de Ethereum en EIP-4844 para adaptarse al rollup es el formato de transacción blob, que amplía la capacidad del bloque, el principal cuello de botella de todas las pruebas de conocimiento cero actuales todavía reside en su propio algoritmo de prueba. Por un lado, se puede resolver mejorando el algoritmo. Por otro lado, el problema de la prueba se mejora apilando hardware, lo que también dio origen a la pista de minería ZK. Quienes estén interesados pueden acudir a este artículo.
La purga
The Purge reducirá la cantidad de espacio necesario para almacenar ETH en un disco duro en un intento de simplificar el protocolo Ethereum y eliminar la necesidad de que los nodos almacenen el historial. Esto puede mejorar enormemente el ancho de banda de la red.
EIP-4444:
Los clientes deben dejar de ofrecer encabezados, cuerpos y destinatarios históricos en la capa P2P que tengan más de un año. Los clientes pueden podar estos datos históricos localmente. Preservar la historia de Ethereum es fundamental y creo que hay varias formas fuera de banda de lograrlo. Los datos históricos se pueden empaquetar y compartir a través de enlaces magnéticos de torrents o redes como IPFS. Además, se pueden utilizar sistemas como Portal Network o The Graph para obtener datos históricos. El cliente debe permitir la importación y exportación de datos históricos. Los clientes pueden proporcionar scripts para obtener/validar datos e importarlos automáticamente.
El derroche
Esta ruta se compone principalmente de algunas correcciones de optimización gradual, como la abstracción de cuentas, la optimización EVM y el esquema de números aleatorios VDF.
La abstracción de cuenta (AA) mencionada aquí siempre ha sido el primer objetivo que la capa 2 de la serie ZK quiere lograr. Entonces, ¿qué es la abstracción de cuentas? Después de implementar la abstracción de cuentas, una cuenta de contrato inteligente también puede iniciar transacciones activamente sin depender del mecanismo de "metatransacción" (esto se propuso en EIP-4844).
En Ethereum, las cuentas se dividen en cuentas de contrato y cuentas externas. Actualmente, solo existe un tipo de transacción en Ethereum, que debe ser iniciada por una dirección externa. Las direcciones de contrato no pueden iniciar transacciones activamente. Por lo tanto, cualquier cambio en el estado del contrato debe depender de una transacción iniciada por una dirección externa. Ya sea una cuenta de firma múltiple, un mezclador de divisas o cualquier cambio de configuración de contrato inteligente, debe ser activado por al menos una cuenta externa. .
No importa qué aplicación se utilice en Ethereum, los usuarios deben tener Ethereum (y asumir el riesgo de las fluctuaciones del precio de Ethereum). En segundo lugar, los usuarios deben lidiar con una lógica de costos compleja, el precio del gas, el límite del gas y el bloqueo de transacciones. Estos conceptos son demasiado complejos para los usuarios. Muchas carteras o aplicaciones blockchain intentan mejorar la experiencia del usuario mediante la optimización del producto, pero con poco efecto.
El objetivo de la solución centrada en cuentas es crear una cuenta para el usuario basada en la gestión de contratos inteligentes. Los beneficios de implementar la abstracción de cuentas son:
El contrato actual puede contener ETH y enviar directamente una transacción con todas las firmas. El usuario no necesariamente necesita pagar tarifas de gas por la transacción, depende completamente del proyecto. Debido a la implementación de criptografía personalizada, en el futuro no será obligatorio utilizar curvas elípticas ESCDA para las firmas. En el futuro, el reconocimiento de huellas dactilares, el reconocimiento facial, la biometría y otras tecnologías de un teléfono móvil se podrán utilizar como métodos de firma. Esto mejora significativamente la experiencia de interacción del usuario con Ethereum.
2. Modularización de Ethereum
Actualmente, todo Ethereum ha visto una tendencia a la modularización, y la capa de ejecución es responsable de la Capa 2 (como arbitrum, zksync, starknet, polygon zkevm, etc.). Son responsables de ejecutar las transacciones de los usuarios en L2 y presentar pruebas. La capa 2 generalmente usa tecnología OP/tecnología ZK. En teoría, el TPS de la tecnología ZK es mucho mayor que el de OP. Actualmente, una gran cantidad de ecosistemas están en el sistema OP, pero en el futuro, con la mejora de la tecnología ZK. , se migrarán cada vez más aplicaciones al departamento de ZK. Esta sección es una descripción detallada de la hoja de ruta complementada con el por qué y el cómo.
En la actualidad, Ethereum solo separa la capa de ejecución. De hecho, otras capas todavía están mezcladas. En la visión de Celestia, la capa de ejecución solo hace dos cosas: para una sola transacción, ejecutar la transacción y se producen cambios de estado para las transacciones en el mismo lote, calcular la raíz del estado del lote; Parte del trabajo actual de la capa de ejecución de Ethereum está asignado a Rollup, conocido como StarkNet, zkSync, Arbitrum y Optimism.
Ahora Optimist, Polygon, Starknet, Zksync, etc. están explorando el camino de la modularidad.
Optimism propuso la pila de operaciones/base, Polygon también está desarrollando el uso de polígonos como una capa de disponibilidad de datos, y las superredes se utilizan para simplificar la creación de cadenas y compartir conjuntos de validadores.
Capa de liquidación: puede entenderse como el proceso de verificación de la validez de la raíz anterior al estado, raíz posterior al estado, prueba (zkRollup) o prueba de fraude (Optimistic Rollup) mencionada anteriormente mediante el contrato Rollup en la cadena principal. Capa de consenso: ya sea que se utilice PoW, PoS u otros algoritmos de consenso, la capa de consenso es llegar a un consenso sobre algo en el sistema distribuido, es decir, llegar a un consenso sobre la validez de la transición de estado (la raíz previa al estado es calculado y convertido en la raíz post-estado). En el contexto de la modularidad, la capa de liquidación y la capa de consenso tienen significados algo similares, por lo que algunos investigadores unifican la capa de liquidación y la capa de consenso. Capa de disponibilidad de datos: asegúrese de que los datos de la transacción se carguen completamente en la capa de disponibilidad de datos y que el nodo de verificación pueda reproducir todos los cambios de estado a través de los datos de esta capa.
Lo que hay que distinguir aquí es la diferencia entre disponibilidad de datos y almacenamiento de datos:
La disponibilidad de datos es claramente diferente del almacenamiento de datos: la primera se centra en si los datos publicados en el último bloque están disponibles, mientras que el segundo implica almacenar datos de forma segura y garantizar que se pueda acceder a ellos cuando sea necesario.
1. Varios paquetes acumulativos en la capa de liquidación
Desde la perspectiva de la capa de liquidación, actualmente se cree que el foco del resumen está en la serie ZK. Si el resumen del sistema ZK se utiliza para mejorar el tamaño, el consumo de gas y el costo del sistema de prueba ZK, y se combina con la recursividad y el procesamiento paralelo, su TPS se puede expandir enormemente. Entonces, comencemos con el resumen de ZK.
Con el desarrollo de la expansión de Ethereum, Vitalik considera que la tecnología Zero Knowledge Proof (ZKP) es la solución que se espera que sea el resultado final de la batalla de expansión.
La esencia de ZKP es permitir que alguien demuestre que sabe o posee algo. Por ejemplo, puedo demostrar que tengo la llave de la puerta sin tener que sacarla. Al demostrar que conoce la contraseña de una cuenta sin tener que ingresarla y correr el riesgo de quedar expuesto, esta tecnología tiene implicaciones para la privacidad personal, el cifrado, los negocios e incluso el desarme nuclear. Obtenga una comprensión más profunda con una versión modificada del problema millonario de Yao: este problema analiza a dos millonarios, Alice y Bob, que quieren saber cuál de ellos es más rico sin revelar su riqueza real.
Suponiendo que el apartamento se alquila por $1,000 por mes, para calificar como alquiler, tendría que pagar al menos 40 veces el alquiler de un mes. Entonces nosotros (los inquilinos) debemos demostrar que nuestro ingreso anual es superior a $40,000. Pero el propietario no quería que encontráramos lagunas jurídicas, por lo que decidió no publicar el alquiler específico. Su propósito era comprobar si cumplíamos con los estándares, y la respuesta fue simplemente sí o no, y él no era responsable de ese alquiler específico. cantidad.
Ahora hay diez casillas, marcadas de $10 a $100 mil en incrementos de $10 mil. Cada uno tiene una llave y una ranura. El propietario entró en la habitación con la caja y destruyó 9 llaves, sacando la llave de la caja con la etiqueta $40k.
El salario anual del inquilino alcanza los 75.000 dólares. El agente del banco supervisa la emisión de un documento que acredite los fondos específicos. La esencia de este documento es la declaración de activos del banco para verificar el documento de reclamación. Luego colocamos el archivo en el contenedor de 10k~70k. Luego, el propietario usa la llave de 40k para abrir la caja y cuando ve el documento de reclamo verificable en el interior, determina que el inquilino cumple con los criterios.
Los puntos involucrados incluyen que el declarante (banco) emite un certificado de cumplimiento de activos y el verificador (propietario de la vivienda) verifica si el inquilino está calificado a través de la clave. Se enfatiza nuevamente que solo hay dos opciones para los resultados de la verificación: calificado o no calificado, y no requiere ni puede exigir la cantidad específica de activos del inquilino.
Todavía podemos usar la siguiente figura como comprensión. Las transacciones se ejecutan en la capa 2 y las transacciones se envían en fragmentos. La capa 2 generalmente adopta la forma de acumulación, es decir, varias transacciones se empaquetan en un lote en la capa 2 para procesar las transacciones y luego se envían al contrato inteligente acumulado de la capa 1. Contiene las raíces de estado antiguas y nuevas. El contrato en la capa 1 verificará si las dos raíces de estado coinciden. Si coinciden, la raíz de estado anterior en la cadena principal será reemplazada por la raíz de estado nueva. Entonces, ¿cómo verificar que el estado raíz obtenido después del procesamiento por lotes sea correcto? Aquí se derivan el resumen optimista y el resumen zk. La tecnología antifraude y zk se utilizan respectivamente para la confirmación de transacciones y la verificación de la raíz del estado.
La capa 2 (acumulación) aquí es equivalente al declarante (banco) en el ejemplo anterior. Su operación de empaquetado es la operación de declaración. No declara el monto específico, pero confirma si se cumple el estándar. Lo que se empaqueta y envía a la capa 1 es este documento de declaración reclamable. La raíz de la verificación del estado antiguo y nuevo es que el propietario utilice la clave para verificar si la solidez financiera del inquilino que espera cumple con los estándares. El problema de verificación de raíz estatal es la declaración presentada por el banco. Cómo hacer la declaración para que el problema sea creíble.
Basado en un resumen optimista, es decir, a prueba de fraude, el contrato de resumen de la cadena principal registra un registro completo de los cambios de raíz de estado internos del resumen, así como el valor hash de cada lote (que desencadena el cambio de raíz de estado). Si alguien descubre que la nueva raíz de estado correspondiente a un determinado lote es incorrecta, puede publicar una prueba en la cadena principal de que la nueva raíz de estado generada por ese lote es incorrecta. El contrato verifica la prueba y, si se aprueba la verificación, se revierten todas las transacciones de procesamiento por lotes posteriores al procesamiento por lotes.
El método de verificación aquí es equivalente a que el declarante (banco) presente un documento de declaración de activos verificable y luego publique todos los documentos de activos en la cadena, y los datos también deben publicarse en la cadena, y otros retadores calcularán en función del original. datos para ver lo verificable Compruebe si hay errores o falsificaciones en los documentos del activo. Si hay algún problema, se realizará una impugnación. Si la impugnación tiene éxito, se presentará un reclamo al banco. La cuestión más importante aquí es la necesidad de reservar tiempo para que el retador recopile datos y verifique la autenticidad del documento.
Para Rollup que utiliza la tecnología Zero Knowledge Proof (ZKP), cada lote contiene una prueba criptográfica llamada ZK-SNARK. Los bancos utilizan tecnología de prueba criptográfica para generar documentos de declaración de activos. De esta forma, no es necesario reservar tiempo para los retadores y, por tanto, el rol de retador no existe.
2. La razón por la que el resumen de la serie ZK no es tan bueno como se esperaba ahora
En la actualidad, se lanzó hermez basado en polígonos y también se lanzaron zksync dev mainnet y starknet mainnet. Sin embargo, su velocidad de transacción parece estar muy por detrás de nuestra teoría. En particular, los usuarios de Starknet pueden sentir claramente que la velocidad de su red principal es sorprendentemente lenta. La razón es que todavía es muy difícil generar pruebas con tecnología de prueba de conocimiento cero, el costo sigue siendo alto y también existe una compensación entre la compatibilidad de Ethereum y el rendimiento de zkevm. El equipo de Polygon también admitió: "La versión testnet de Polygon zkEVM también tiene capacidades de rendimiento limitadas, lo que significa que está lejos de la forma final como una máquina de escalado optimizada".
3. Capa de disponibilidad de datos
Los pasos de ejecución abstractos de Ethereum son los siguientes:
En el proceso de descentralización de Ethereum, también podemos verlo en la hoja de ruta de The Merge: validadores descentralizados. El más importante de ellos es aprovechar la diversidad de clientes, reducir el umbral de entrada para las máquinas y aumentar el número de validadores. Por lo tanto, si algunos validadores cuyas máquinas no cumplen con los estándares quieren participar en la red, pueden usar clientes ligeros. El principio de funcionamiento de los nodos ligeros es solicitar encabezados de bloque a través de nodos completos cercanos que solo necesitan descargar y verificar. encabezados de bloque. Si los nodos ligeros no participan, entonces todas las transacciones requieren que los nodos completos realicen la verificación, por lo que los nodos completos deben descargar y verificar cada transacción en el bloque. Al mismo tiempo, a medida que aumenta el volumen de transacciones, los nodos completos están bajo una presión cada vez mayor. , por lo que la red de nodos tiende gradualmente a ser de alto rendimiento y centralizada.
Pero el problema aquí es que un nodo completo malicioso puede dar un encabezado de bloque faltante o no válido, pero un nodo ligero no puede falsificarlo. Hay dos formas de resolver este problema. La primera es utilizar prueba de fraude, lo que requiere un nodo completo confiable. Supervise la validez del bloque y construya una prueba de fraude después de descubrir un bloque no válido. Si la prueba de fraude no se recibe dentro de un período de tiempo, se determinará como un encabezado de bloque válido. Pero aquí obviamente necesitamos un nodo completo confiable, lo que requiere configuraciones confiables o suposiciones honestas. Sin embargo, el productor de bloques puede ocultar algunas transacciones y la prueba de fraude obviamente no es válida, porque los nodos honestos también dependen de los datos del productor de bloques. Si los datos en sí están ocultos, entonces los nodos confiables piensan que los datos enviados son todos los. datos, entonces, naturalmente, no se generará ninguna prueba de fraude.
En un artículo del que son coautores Mustarfa AI-Bassam y Vitalik, se propone una nueva solución: la codificación de borrado. Los códigos de borrado se utilizan para resolver problemas de disponibilidad de datos. Por ejemplo, Celestia y Polygon utilizan códigos de borrado de Reed-Solomon. Pero la forma de garantizar que los datos transmitidos sean completos se puede combinar con el compromiso/antifraude de KZG.
En el compromiso / prueba de fraude de KZG, puede garantizar que el productor de bloques publique datos completos sin ocultar transacciones, y luego los datos se codifiquen mediante codificación de borrado y luego mediante muestreo de disponibilidad de datos, de modo que los nodos ligeros puedan verificar los datos correctamente.
Los datos enviados por el agregador en Rollup se almacenan en la cadena en forma de datos de llamada, porque los datos de datos de llamada son más baratos que otras áreas de almacenamiento.
Costo de datos de llamada en gas = Tamaño de transacción × 16 gas por byte
El costo principal de cada transacción es el costo de los datos de llamada, porque el almacenamiento en cadena es extremadamente costoso y esta parte representa entre el 80% y el 95% del costo acumulativo.
Debido a este problema, propusimos el nuevo formato de transacción blob de EIP-4844 para expandir la capacidad del bloque y reducir la tarifa de gas requerida para enviar a la cadena.
4. Capa de disponibilidad de datos dentro y fuera de la cadena
Entonces, ¿cómo resolver el problema de los datos costosos en la cadena? Hay varios métodos:
La primera es comprimir el tamaño de los datos de llamada cargados en L1. Ha habido muchas optimizaciones en esta área. El segundo es reducir el costo de almacenar datos en la cadena, proporcionar "bloques grandes" y mayor espacio de disponibilidad de datos para la acumulación a través del proto-danksharding y danksharding de Ethereum, y utilizar la codificación de borrado y el compromiso de KZG para resolver el problema de los nodos ligeros. Como EIP-4844. La tercera es poner la disponibilidad de datos fuera de la cadena. Las soluciones comunes para esta parte incluyen Celestia/Polygon Disponibilidad, etc.
Según la ubicación donde se almacena la disponibilidad de datos, los dividimos como se muestra en la siguiente figura:
La solución de Validium: coloque la disponibilidad de datos fuera de la cadena, luego estos datos de transacciones serán mantenidos por operadores centralizados y los usuarios necesitarán configuraciones confiables, pero el costo será muy bajo, pero al mismo tiempo casi no habrá seguridad. Posteriormente, tanto Starkex como Arbitrum Nova propusieron el establecimiento de DAC como responsable del almacenamiento de los datos de las transacciones. Los miembros del DAC son individuos u organizaciones que son bien conocidos y están dentro de la jurisdicción legal, y se asume que no se confabularán ni harán el mal.
Zkporter propone a los tutores (titulares del token zksync) que se comprometan a mantener la disponibilidad de los datos. Si se produce una falla en la disponibilidad de los datos, se perderán los fondos prometidos. Volition permite a los usuarios elegir la disponibilidad de datos dentro y fuera de la cadena y elegir entre seguridad y costo según sus necesidades.
Aquí es cuando aparecen celestia y polígono disponible. Si Validium tiene requisitos de disponibilidad de datos fuera de la cadena pero teme una baja descentralización, lo que puede conducir a ataques de clave privada similares a los puentes entre cadenas, entonces una solución DA universal descentralizada puede resolver este problema. Celestia y Polygon Aprovech proporcionan a Validium una solución DA fuera de la cadena al convertirse en una cadena separada. Sin embargo, a través de una cadena separada, aunque se mejora la seguridad, el costo aumentará en consecuencia.
La expansión de Rollup en realidad tiene dos partes: una es la velocidad de ejecución del agregador y la otra requiere la cooperación de la capa de disponibilidad de datos. Actualmente, el agregador es ejecutado por un servidor centralizado. alcanza infinito, entonces el principal dilema de la expansión es que se ve afectado por el rendimiento de datos de la solución de disponibilidad de datos subyacente. Si el resumen va a maximizar el rendimiento de sus transacciones, es fundamental cómo maximizar el rendimiento del espacio de datos de la solución de disponibilidad de datos.
Volviendo al principio, utilice el compromiso de KZG o la prueba de fraude para garantizar la integridad de los datos y utilice la codificación de borrado para expandir los datos de las transacciones para ayudar a los nodos ligeros a realizar muestreos de disponibilidad de datos, garantizando aún más que los nodos ligeros puedan verificar los datos correctamente.
Quizás también quieras preguntar, ¿cómo opera el compromiso de KZG para garantizar la integridad de sus datos? Quizás pueda darte una pequeña respuesta:
Compromiso de KZG: Demostrar que el valor de un polinomio en una ubicación específica es consistente con un valor numérico específico. Un compromiso KZG no es más que un tipo de compromiso polinómico que es capaz de verificar un mensaje sin recibir un mensaje específico. El proceso aproximado es el siguiente:
Convierta los datos en polinomios mediante codificación de borrado y amplíelos. El uso de KZG promete garantizar que nuestra expansión sea efectiva y que los datos originales sean válidos. Luego use la expansión para reconstruir los datos y finalmente realice un muestreo de disponibilidad de datos.
El confirmador genera un compromiso y lo vincula al mensaje. Envíe el mensaje enlazado al verificador. El esquema de comunicación aquí está relacionado con el tamaño de la prueba. Verificador (verificador), varios valores traídos al campo finito verifican si todavía son iguales a a (este es el proceso de muestreo de disponibilidad. El principio básico es que cuanto mayor sea el tiempo de verificación, mayor será la probabilidad de corrección).
Celestia requiere que los validadores descarguen bloques completos y ahora danksharding utiliza técnicas de muestreo de disponibilidad de datos.
Dado que los bloques están parcialmente disponibles, debemos garantizar la sincronización en cualquier momento al reconstruir los bloques. Cuando un bloque queda parcialmente disponible, los nodos se comunican entre sí para reconstruirlo.
Comparación del compromiso de KZG y la prueba de fraude de datos:
Se puede ver que KZG promete garantizar que la expansión y los datos sean correctos, y la prueba de fraude presenta a un tercero para su observación. La diferencia más obvia es que las pruebas de fraude requieren un intervalo de tiempo para que los observadores reaccionen antes de informar el fraude. En este momento, se requiere la sincronización directa de los nodos para que toda la red pueda recibir pruebas de fraude a tiempo. KZG es significativamente más rápido que la prueba de fraude. Utiliza métodos matemáticos para garantizar que los datos sean correctos sin necesidad de tiempo de espera.
Puede acreditar que los datos y su extensión son correctos. Sin embargo, dado que el compromiso KZG unidimensional requiere mayores recursos, Ethereum elige el compromiso KZG bidimensional.
Por ejemplo, 100 filas × 100 columnas, es decir, 100.000 acciones. Pero cada muestreo no es una garantía de uno entre 10.000. Luego, expandir cuatro veces significa que al menos 1/4 de la acción total no debe estar disponible. Solo entonces se puede extraer una acción no disponible, lo que significa que realmente no está disponible porque no se puede recuperar. Solo cuando 1/4 no está disponible y no se puede recuperar, el error se puede descubrir realmente de manera efectiva, por lo que la probabilidad de sacar una vez es aproximadamente 1/4. Después de bombear más de diez o quince veces, se puede lograr una garantía de confiabilidad del 99%. Ahora elija entre 15 y 20 veces.
5、EIP-4844（Proto-Danksharding）
En la implementación del proto-danksharding, todos los validadores y usuarios aún deben verificar directamente la disponibilidad de los datos completos.
La característica principal introducida por proto-danksharding es un nuevo tipo de transacción, al que llamamos transacciones portadoras de blobs. Una transacción que lleva un blob es similar a una transacción normal, excepto que también lleva un dato adicional llamado blob. Los blobs son muy grandes (~125 kB) y mucho más baratos que cantidades similares de datos de llamadas. Sin embargo, no se puede acceder a estos blobs desde EVM (solo hay promesas para los blobs). Y los blobs se almacenan en la capa de consenso (cadena de balizas) en lugar de en la capa de ejecución. En realidad, este es el comienzo de la formación gradual del concepto de fragmentación de datos.
Debido a que los validadores y clientes aún necesitan descargar el contenido completo del blob, el objetivo de ancho de banda de datos en proto-danksharding es 1 MB por ranura en lugar de los 16 MB completos. Sin embargo, dado que estos datos no compiten con el uso de gas de las transacciones existentes de Ethereum, todavía existen grandes ganancias en escalabilidad.
Si bien implementar la fragmentación completa (usando muestreo de disponibilidad de datos, etc.) es una tarea compleja y sigue siendo una tarea compleja después de la proto-danksharding, esta complejidad está contenida en la capa de consenso. Una vez que se implemente la fragmentación proto-danksharding, los equipos de clientes ejecutivos, los desarrolladores de paquetes acumulativos y los usuarios no necesitarán más trabajo para completar la transición a la fragmentación completa. Proto-danksharding también separa los datos de blobs de los datos de llamadas, lo que facilita a los clientes almacenar datos de blobs en menos tiempo.
Vale la pena señalar que todo el trabajo lo modifica la capa de consenso y no requiere ningún trabajo adicional por parte del equipo del cliente, los usuarios o los desarrolladores del Rollup.
Tanto EIP-4488 como proto-danksharding dan como resultado un uso máximo a largo plazo de aproximadamente 1 MB por ranura (12 segundos). Esto equivale a unos 2,5 terabytes por año, mucho más que la tasa de crecimiento que Ethereum necesita hoy.
En el caso de EIP-4488, resolver este problema requiere la propuesta de vencimiento del historial EIP-4444 (mencionada en la sección de hoja de ruta), donde ya no se requiere que los clientes almacenen el historial más allá de un cierto período de tiempo.
6. Fragmentación de datos
Aquí, explicaré lo más posible desde la perspectiva de un principiante los temas que todos están discutiendo durante la expansión de Ethereum. Entonces, volvamos a la fragmentación y enfaticemos una vez más el concepto unilateral de fragmentación: una comprensión simple es el proceso de dividir horizontalmente la base de datos para distribuir la carga.
Aquí, un problema muy importante con nuestra fragmentación de datos es que en PBS (los proponentes y los constructores de bloques están separados, como se menciona en la hoja de ruta The Merge), en la fragmentación, cada grupo de nodos solo procesa Las transacciones dentro del fragmento serán relativamente independientes entre fragmentos. Entonces, ¿cómo deberían los usuarios A y B transferirse fondos entre sí si están en fragmentos diferentes? Entonces necesita buenas capacidades de comunicación entre sectores.
La forma antigua era fragmentar la capa de disponibilidad de datos, y cada fragmento tenía comités y proponentes independientes. En el conjunto de validadores, cada validador se turna para verificar los datos fragmentados y descarga todos los datos para su verificación.
debilidad es:
Se requiere una tecnología de sincronización estricta para garantizar que los validadores puedan sincronizarse dentro de una ranura. Los validadores deben recolectar votos de todos los comités y aquí también habrá retrasos. Además, también resulta muy estresante para el verificador descargar completamente los datos.
El segundo enfoque es abandonar la validación completa de los datos y, en su lugar, adoptar un enfoque de muestreo de disponibilidad de datos (implementado más adelante en The Surge). Aquí hay dos métodos de muestreo aleatorio: 1) Bloquear el muestreo aleatorio, muestreando parte de los datos en fragmentos. Si la verificación pasa, el verificador firma. Pero el problema aquí es que puede haber casos en los que se omitan transacciones. 2) Reinterpretar los datos en polinomios mediante codificación de borrado y luego utilizar las características de los polinomios para restaurar los datos en condiciones específicas para garantizar la disponibilidad completa de los datos.
La clave del "sharding" es que el validador no es responsable de descargar todos los datos, y es por eso que Proto-danksharding no se considera "sharding" (aunque tenga "sharding" en su nombre). Proto-danksharding requiere que cada validador descargue por completo todos los shard blobs para verificar su disponibilidad. Luego, Danksharding introducirá el muestreo, y un único validador solo necesita descargar fragmentos de shard blobs.
3. El futuro de Ethereum: Capa 3
La serie ZK Layer 2, que se considera la futura expansión de Ethereum, como zksync y starknet, han propuesto el concepto de Layer 3. Una comprensión simple es la Capa 2 de la Capa 2.
Los altos costos de transacción en Ethereum lo están empujando (L3) a convertirse en la capa de liquidación de L2. Se cree que en un futuro cercano, debido a costos de transacción significativamente más bajos, mayor soporte para herramientas DeFi y mayor liquidez proporcionada por L2, los usuarios finales llevarán a cabo la mayoría de sus actividades en L2, y Ethereum se convertirá gradualmente en la capa de liquidación.
L2 mejora la escalabilidad al reducir los costos de gas por transacción y aumentar las tasas de transacción. Al mismo tiempo, las L2 conservan los beneficios de la descentralización, la lógica universal y la componibilidad. Sin embargo, algunas aplicaciones requieren una personalización específica, que puede funcionar mejor con una nueva capa independiente: ¡L3!
L3 está relacionada con L2 del mismo modo que L2 está relacionada con L1. Siempre que L2 pueda admitir contratos inteligentes de Verifier, L3 se puede implementar utilizando pruebas de validez. Cuando L2 también usa pruebas de validez enviadas a L1, como lo hace StarkNet, esto se convierte en una estructura recursiva muy elegante donde las ventajas de compresión de las pruebas L2 se multiplican por las ventajas de compresión de las pruebas L3. En teoría, si cada capa lograra, digamos, una reducción de costos de 1000 veces, entonces L3 podría ser 1.000.000 de veces más barato que L1, manteniendo al mismo tiempo la seguridad de L1. Este también es un caso de uso real para las pruebas recursivas de las que Starknet se enorgullece.
Aquí se necesita parte del conocimiento de la "capa de disponibilidad de datos dentro y fuera de la cadena". Toda la Capa 3 incluye:
Rollup (disponibilidad de datos en la cadena), validez (disponibilidad de datos fuera de la cadena). Los dos tipos corresponden a diferentes requisitos de aplicación. Las empresas de Web2 que son sensibles al precio y los datos pueden utilizar Validium para sacar los datos de la cadena, lo que reduce en gran medida los costos de gas en la cadena y pueden lograr privacidad sin revelar los datos del usuario, lo que permite a las empresas controlar completamente sus datos utilizando formatos de datos personalizados. El modelo de negocio de datos de la empresa anterior aún puede funcionar sin problemas.
L2 es para extensiones y L3 es para funciones personalizadas como la privacidad.
En esta visión, no se intenta proporcionar "escalabilidad cuadrática", sino que hay una capa en la pila que ayuda a escalar las aplicaciones y luego las capas se separan según los requisitos funcionales personalizados para diferentes casos de uso.
L2 es para extensiones generales y L3 es para extensiones personalizadas.
Las extensiones personalizadas pueden presentarse en diferentes formas: aplicaciones especializadas que utilizan algo distinto al EVM para el cálculo, paquetes acumulativos cuya compresión de datos está optimizada para el formato de datos específico de la aplicación (incluida la separación de "datos" de las "pruebas" y el reemplazo completo de la prueba con un solo SNARK por bloque), etc.
L2 se usa para expansión sin confianza (rollup) y L3 se usa para expansión de confianza débil (validium).
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" pueden funcionar mejor con un servidor centralizado que ejecute un probador de Validium y envíe hashes a la cadena con regularidad. Validium es menos seguro que el rollup, pero puede ser mucho más económico.
Para los desarrolladores de dApps, existen varias opciones de infraestructura:
Desarrolle un Rollup usted mismo (ZK Rollups o Optimistic Rollups)
La ventaja es que puede heredar el ecosistema Ethereum (usuarios) y su seguridad, pero para un equipo de dApp, el costo de desarrollo de Rollup es obviamente demasiado alto.
Elige Cosmos, Polkadot o Avalancha
El costo de desarrollo será menor (por ejemplo, dydx eligió Cosmos), pero perderá el ecosistema Ethereum (usuarios) y la seguridad.
Desarrolla tu propia blockchain de Capa 1
El costo de desarrollo y la dificultad que conlleva son muy altos, pero puede tener el mayor control.
Comparemos tres situaciones:
Dificultad/Costo: Capa alternativa 1 > Paquete acumulativo > Cosmos Seguridad: Paquete acumulativo > Cosmos > Capa alternativa 1 Ecología/Usuarios: Paquete acumulativo > Cosmos > Capa alternativa 1 Control: Capa alternativa 1 > Cosmos > Paquete acumulativo
Como desarrollador de dApp, si desea heredar la seguridad y el tráfico de Ethereum, no puede volver a desarrollar una cadena y solo puede elegir el paquete acumulativo. Sin embargo, es muy costoso desarrollar un paquete acumulativo de Capa 2 usted mismo, por lo que la solución adecuada es utilizar el SDK de Capa 3 para desarrollar un paquete acumulativo específico de la aplicación (paquete acumulativo específico de la aplicación), es decir, la Capa 3.
4. El desarrollo futuro de la Capa 2
Dado que Ethereum está diseñado según el modelo de cuenta, todos los usuarios están en un árbol de estado completo, por lo que no se puede realizar el paralelismo. Por lo tanto, los grilletes del propio Ethereum requieren que despegue las operaciones de ejecución y combine múltiples transacciones acumuladas en una sola. una capa de asentamiento. Todos los problemas ahora se centran en mejorar el rendimiento de la capa 2. El uso de la Capa 3 no solo puede mejorar el rendimiento de las transacciones, sino que también la implementación del procesamiento paralelo en la Capa 2 también puede mejorar en gran medida el rendimiento de toda la red.
Starknet también está explorando activamente la cuestión de la paralelización. Aunque el algoritmo de prueba actual sigue siendo un obstáculo, no se espera que sea un obstáculo en el futuro. Los posibles obstáculos incluyen:
Manejo de tx del clasificador: algunos trabajos de clasificación parecen ser inherentemente seriales. Ancho de banda: Las interconexiones entre múltiples secuenciadores serán limitadas. Tamaño del estado L2
En la comunidad starknet, los miembros también señalaron que el método de procesamiento paralelo de aptos es muy bueno. Por su parte, Starknet también está avanzando actualmente en la capacidad de realizar clasificación tx en paralelo dentro del clasificador.
5. Resumen
Ethereum está eliminando la capa de ejecución y moviendo todo hacia su visión de una capa de liquidación "global". Aunque actualmente todo Ethereum progresa lentamente, eso se debe a que es demasiado grande en su conjunto y cada actualización implica muchos intereses y compensaciones. Pero es innegable que Ethereum está experimentando cambios importantes: la gran cantidad de actividades en cadena de Ethereum, las mejoras en los mecanismos económicos y la escalabilidad de Ethereum 2.0 lideran ICO, Defi, NFT innovadores y muchas otras cosas que merecen entusiasmo. El entusiasmo de la comunidad Ethereum espera. Creo que a medida que más y más países implementen nodos de Ethereum, por ejemplo, el gobierno de la capital argentina planea implementar nodos de verificación de Ethereum en 2023, Ethereum realmente podrá hacer realidad su gran visión en un futuro cercano.