Ethereum se ha subvertido a sí mismo: la introducción de la criptografía para lograr un gran avance en el rendimiento 2.0

El rendimiento es el cuello de botella que obstaculiza el desarrollo de las cadenas públicas, y mejorar el rendimiento es el principal objetivo de diseño de la mayoría de las cadenas públicas que esperan superar a Ethereum. Sin embargo, cuando nos paramos hoy y miramos hacia atrás, encontraremos que la mayoría de estas cadenas públicas son seleccionado a través de mecanismos. Está diseñado para mejorar el rendimiento de un sistema distribuido, pero debido al teorema CAP del sistema distribuido (triángulo imposible), hay que pagar un precio por mejorar el rendimiento. Cuando el propósito de este sistema distribuido es un libro mayor , estos costos pueden incluso ser inaceptables. Ethereum también ha estado probando varios métodos para mejorar el rendimiento. En vísperas del lanzamiento de 2.0, "probó" la criptografía. Ethereum 2.0 será una cadena pública basada en "sistema distribuido + criptografía". Esta criptografía no se refiere a la parte utilizada para la firma y la privacidad, sino que se refiere al componente central de un sistema de alto rendimiento. esa parte. Desde este punto de vista, quizás podamos decir que no son otros los que subvierten a Ethereum, sino él mismo. Saltó de la idea única de diseño de sistemas distribuidos y se embarcó en el camino del diseño combinado de sistema distribuido + criptografía. Este artículo intentará presentar cómo se combina el diseño del sistema distribuido con el diseño de criptografía en Ethereum 2.0 para lograr un gran avance en el rendimiento de la cadena pública. Fragmentación de estado: de un solo libro mayor a varios libros mayores La cadena de bloques es un libro mayor distribuido, y los nodos productores de bloques son mineros que llevan las cuentas y son responsables de escribir las transacciones en el libro mayor. Además de competir por los derechos de contabilidad, el trabajo más importante de los productores de bloques, o de su propio trabajo, es verificar si las transacciones que empaquetan son legales. No es difícil completar este trabajo, porque el nodo productor del bloque tiene el libro mayor en sus manos y solo necesita verificar si el remitente de la transacción tiene el dinero. Para la cadena pública no fragmentada, todos los nodos tienen el mismo libro mayor y, para evitar conflictos de contabilidad, solo un nodo productor de bloques puede llevar libros a la vez. Ethereum propone la fragmentación del estado, que en realidad divide un libro mayor en varios libros mayores. De esta manera, algunos nodos mantienen cuentas en el libro mayor n.° 1, y algunos nodos mantienen cuentas en el libro mayor n.° 2... (equivalente a 7-11 de una caja registradora La plataforma se amplía a múltiples cajas registradoras), y múltiples nodos mantienen cuentas al mismo tiempo, y el rendimiento de toda la cadena pública mejorará cualitativamente. Pero si arreglamos la relación entre los nodos productores de bloques y los libros mayores/fragmentos, por ejemplo, se determina que cuatro nodos a, b, c y d son responsables del libro mayor número 1, entonces los malos solo necesitan comprar parte de a, b, c y d Puede destruir el libro mayor, y mientras se mejora el rendimiento de la cadena pública, la seguridad disminuirá en la misma proporción. Por lo tanto, los nodos productores de bloques deben asignarse de forma aleatoria y dinámica a diferentes registros, para garantizar que la cadena pública fragmentada tenga la misma seguridad que la cadena pública no fragmentada. Pero la asignación dinámica traerá nuevos problemas: ¿qué libro mayor debe contener el nodo? Puede asignarse a cualquiera de los 64 libros de contabilidad (Ethereum planea iniciar 64 fragmentos) para llevar las cuentas. La solución dada por Ethereum es que el nodo productor de bloques no lleva ningún libro mayor, o en otras palabras, el nodo productor de bloques puede llevar cuentas sin necesidad de un libro mayor. Esto traerá dos beneficios principales. Primero, sin importar a qué fragmento esté asignado el nodo, puede comenzar la contabilidad (generación de bloques) de inmediato, y casi no toma tiempo obtener y sincronizar el libro mayor del fragmento. Por lo tanto, el nodo puede Es fácil saltar entre diferentes fragmentos, el segundo es que el nodo de producción de bloques no necesita almacenar registros y no necesita una configuración de hardware alta. Cualquiera que hipoteque 32ETH puede convertirse en verificador, lo cual es muy útil para la descentralización de Ethereum. PoS Y la seguridad de toda la cadena pública. Pero hay un nuevo problema en el papel: si el nodo del bloque no tiene un libro de contabilidad en sus manos, ¿cómo sabe si el remitente de la transacción tiene suficiente dinero? Aquí es donde entra en juego la criptografía. Compromiso de vectores: puede sonar increíble poder llevar cuentas sin un libro mayor desde la consulta hasta la prueba, pero la idea es simple: en el pasado, un nodo tenía un libro mayor y, después de que llegaba una transacción, buscaba en el libro mayor para verificar si la transacción fue legal; en el futuro, el nodo no tiene un libro mayor, y el remitente de la transacción debe presentar una prueba criptográfica al enviar la transacción (para distinguir, el siguiente texto se refiere a la prueba criptográfica en particular como prueba ), y prueba que la transacción es legal. ¿Por qué el nodo productor de bloques puede juzgar si una determinada transacción es legal a través de una prueba? Aquí están involucrados dos conceptos importantes de criptografía, el primero se llama "Prueba de miembro". Se refiere al proceso de probar que un individuo es parte de un grupo. Si se puede probar que un determinado estado de cuenta es parte de todo el estado del libro mayor, el nodo productor de bloques puede, por supuesto, creer en este estado de cuenta y utilizarlo como base para juzgar la legalidad de la transacción. El segundo se llama "Compromiso de vector", que puede comprimir un grupo, sin importar cuán grande sea el grupo, en un solo número y luego dar una prueba de membresía, que muestra que un individuo pertenece al grupo detrás del grupo de números. , y puede probar la posición del individuo en el grupo, y actualizar el certificado. El árbol de Merkle es uno de los métodos que se pueden usar para los compromisos de vectores, lo tomamos como ejemplo para ver cómo implementar la prueba de membresía. La siguiente figura es un árbol de Merkle. Los nodos de hoja en la capa inferior almacenan datos de la aplicación, y otros nodos que no son de hoja almacenan los valores hash de sus nodos secundarios. Si conoce el valor del nodo verde y todos los nodos amarillos, puede realizar tres operaciones hash de abajo hacia arriba para obtener el valor de la raíz del árbol de Merkle, que es 6c0a. Entonces, si el verificador tiene el valor de la raíz del árbol (6c0a), el proveedor de prueba toma el valor del nodo verde y todos los valores de los nodos amarillos como prueba para el verificador, ¿podrá el verificador calcular el valor hash tres veces igual a 6c0a para juzgar si el valor del nodo verde está en este árbol de Merkle? La respuesta es sí. Esta es la prueba de pertenencia del nodo verde al árbol Merkle, que se realiza como un compromiso de vector, y así es como funcionan los nodos SPV (Verificación de pago simple) de Bitcoin. Como se muestra en la figura a continuación, los nodos SPV no almacenan bloques/libros completos, pero almacenan la raíz del árbol de Merkle en cada bloque (los nodos de hoja de este árbol de Merkle almacenan todas las transacciones en el bloque), cuando necesita consultar Cuando existe una transacción, se le pedirá al nodo completo una prueba de la transacción, que es similar a un paquete (ruta Merkle) de los valores del nodo verde y el nodo amarillo anteriores, y luego el nodo SPV calculará el hash total de estos valores Si el valor es igual al valor de la raíz del árbol de Merkle en su mano, si son iguales, significa que la transacción es miembro del árbol de Merkle, es decir, la transacción existe. El nodo SPV solo almacena el encabezado del bloque (recuadro verde), que contiene la raíz del árbol de Merkle (recuadro rojo). El nodo SPV juzga si la transacción existe a través de la prueba de membresía. El sistema de prueba consta de tres partes: el nodo tiene un breve resumen (raíz del árbol)); el proveedor de la prueba da una prueba; el nodo calcula la prueba para ver si coincide con el resumen en su mano. En este punto, hemos completado "cuentas corrientes sin libros mayores", que es cambiar el pensamiento de consulta a pensamiento de prueba; lo siguiente que queremos lograr es "llevar cuentas sin libros mayores". Para los nodos de producción de bloques en fragmentos de Ethereum 2.0, su sistema de prueba también consta de tres partes: resumen, prueba y verificación, pero debe usar la prueba proporcionada por el remitente de la transacción (no el nodo completo) para juzgar si una nueva transacción es legal (en lugar de si existe la transacción anterior), y utilice este juicio como base para la contabilidad. Apátridas: De la comprobación de los libros de contabilidad a la comprobación de los comportamientos Imagine una pequeña aldea con solo 3 transacciones entre los aldeanos todos los días, y el jefe de la aldea es responsable de llevar las cuentas con el libro de contabilidad. A ahora quiere transferir 5 yuanes a B. La idea tradicional es muy simple: el jefe de la aldea verifica si hay 5 yuanes en la cuenta de A y, de ser así, anota esta nueva transacción. Ahora cambie la forma de pensar: suponga que A quiere transferir 5 yuanes a B esta mañana, y el líder de la aldea sabe que la cuenta de A tiene 10 yuanes ayer por la mañana, entonces si A puede probar que las 3 transacciones de ayer no tienen nada que ver con él, ¿verdad? ¿Significa que su cuenta todavía tiene 10 dólares esta mañana? De esta manera, ¿puede el jefe de la aldea anotar esta nueva transacción sin consultar el libro mayor? La respuesta es sí. ¿Qué pasa si A tuvo una transacción ayer? Es muy simple. En este momento, A no prueba que no tiene ninguna transacción, pero prueba que solo tuvo una transacción ayer, y que la transacción costó 3 yuanes; el jefe de la aldea sabe que todavía tiene 7 yuanes, por lo que puede registrar la nueva transacción. Este cambio de pensamiento es muy importante y debes entenderlo, este es el misterio de la "apatridia". No es difícil encontrar que incluso un nodo SPV que no tiene un libro mayor realmente necesita usar el libro mayor, o el estado, al consultar transacciones, pero no almacena el estado por sí mismo, sino que va a todo el nodo para obtener el prueba de este estado; pero bajo esta nueva idea, el papel del estado puede ser completamente reemplazado por "prueba de comportamiento", entonces esta cadena puede diseñarse sin estado. (Nota: la palabra "prueba de comportamiento" no tiene origen, el autor la describe para facilitar su comprensión) ¿Cómo lograr la apatridia? ¿Cómo completar la contabilidad con la ayuda de la prueba de comportamiento? Sigue siendo el método de certificación de membresía. ¿Se puede usar un árbol de Merkle para completar esta prueba de membresía? Es teóricamente posible, pero para el escenario de aplicación "sin estado", la sobrecarga de su uso es demasiado alta. En este artículo, presentamos la Prueba de membresía a través del "Compromiso de subvector agregable" para la contabilidad sin libro mayor. Compromisos de subvectores agregables (aSVC) es un resultado de investigación reciente del artículo "Compromisos de subvectores agregables para criptomonedas sin estado" de Alin Tomescu, Ittai Abraham, Vitalik Buterin (Ethereum), Justin Drake (Ethereum Square), Dankrad Feist (Ethereum), Dmitry Khovratovich (Etéreo). Su proceso de trabajo es el siguiente: 1. Inicializar la fragmentación, es decir, determinar la situación inicial de la cuenta cuando se establece el libro de cuentas. Supongamos que un fragmento tiene 100 cuentas cuando se establece, y estas cuentas tienen saldos iniciales. Necesitamos usar v(i) para representar la i-ésima cuenta, que es un par de valores como (dirección i, saldo i ); use V Representa todas las cuentas, es un conjunto de valores como (dirección 1, saldo 1) (dirección 2, saldo 2)...(dirección 100, saldo 100). Al mismo tiempo, se deben generar dos valores, el primero se llama c, que es un compromiso con V, que representa todas las cuentas y el saldo en la cuenta del fragmento en este momento. Los nodos productores de bloques tienen c en sus manos (se puede comparar con la raíz del árbol de Merkle para facilitar la comprensión), que es el resumen para futuras verificaciones. El segundo se llama π(i), que es una prueba de que v(i) es un miembro de V, que representa la i-ésima cuenta y el saldo de la cuenta está en el libro mayor general V. Cada cuenta tiene y solo tiene su propio π(i), que es la prueba enviada al nodo de bloque al enviar transacciones en el futuro. Durante la fase de inicialización, la generación de compromisos y pruebas requiere un "estado" inicial. 2. Primera transacción. La cuenta i inicia la primera transacción de todo el fragmento. En este momento, debe enviar π(i) y la transacción al nodo de bloque, y el nodo de bloque calcula π(i) para ver si el resultado es consistente con c en su propia mano Si coinciden, puede creer cuánto saldo tiene la cuenta del remitente y usarlo para juzgar si la transacción que envió es legal. 3. El siguiente es el punto clave: actualizar c y π(i). c (compromiso de todo el libro mayor) ya no se genera de acuerdo con el estado, se genera usando c antes de la primera transacción y el cambio de saldo causado por la primera transacción; π(i) (la prueba de sí misma de la cuenta) No es generado de acuerdo al estado, se genera con π(i) antes de que ocurra la primera transacción, y el cambio de cuenta por la primera transacción. Después de completar la actualización de c y π(i), el nodo productor de bloques tiene un nuevo compromiso (nueva c) que puede prometer el nuevo saldo de todos los usuarios, y la cuenta también tiene una nueva prueba (nueva π(i) que puede probar su nuevo equilibrio )). Por analogía, cada transacción cambiará c una vez, y cambiará todos los π(i) una vez, pero este cambio ya no depende de los datos de estado, depende de los antiguos c y π(i), así como de la transacción anterior; cuando Cuando se necesita verificar una nueva transacción, el nodo que produce el bloque siempre tiene la última c en sus manos, y puede juzgar si una transacción es legal y si se puede empaquetar en un bloque a través de c y el π(i) proporcionado por la cuenta. Entonces, en este punto, finalmente se realiza la "contabilidad sin libros mayores". No importa los productores de bloques o las cuentas, lo que tienen en sus manos es algún tipo de prueba criptográfica, no el estado de los libros mayores. También se debe mencionar que la apatridia y la fragmentación parecen ser una combinación perfecta, pero la apatridia no es un diseño para la fragmentación, es un diseño para cadenas públicas. El objetivo de diseño de aSVC es convertirse en una prueba eficiente de membresía, reducir la sobrecarga de comunicación y la sobrecarga de cálculo en el proceso anterior, de modo que este esquema pueda usarse para la realización de blockchain sin estado. Desde la perspectiva del artículo, utilizando el esquema aSVC, el tamaño de c y π(i) es de solo unas pocas docenas de bytes, el tiempo de actualización de π(i) es O(1), y el tiempo de verificación también es O( 1). Admite la agregación de múltiples pruebas en una prueba de tamaño O (1). Esta implementación de bajo costo es exactamente de lo que se trata aSVC. Sin embargo, al igual que la discusión de Vitalik en el Foro de investigadores de Ethereum, aSVC aún necesita una mayor optimización. El final del artículo es un breve resumen del texto completo: el diseño de fragmentación del estado del sistema distribuido se combina con el diseño de prueba de membresía de la criptografía para lograr un gran avance en el rendimiento de Ethereum 2.0. 1. Por seguridad, la fragmentación del estado de Ethereum 2.0 necesita asignar aleatoriamente nodos productores de bloques. 2. Si el nodo productor de bloques necesita libros de contabilidad, la sincronización de libros de contabilidad se convertirá en un nuevo cuello de botella de rendimiento y el almacenamiento de libros de contabilidad también afectará la descentralización de PoS. 3. ¿Hay alguna forma de verificar el saldo sin un libro mayor? 4. El primer cambio de pensamiento: cambiar la forma de consultar el libro mayor por la forma de probar el libro mayor. Esto debe hacerse con la ayuda de la criptografía. 5. El segundo cambio de pensamiento: cambie la forma de probar el estado del libro mayor a la forma de probar el comportamiento de la transacción, y realice la contabilidad sin estado y sin libro mayor. Esto debe hacerse con la ayuda de la criptografía. 6. Hay muchas herramientas para la criptografía.Cuando tiene un objetivo, necesita seleccionar y combinar las herramientas apropiadas para formar una solución de acuerdo con los requisitos de la aplicación y optimizar la solución. Compromiso de subvector agregable Easter Egg En el artículo, describimos el trabajo de aSVC en lenguaje natural. Si está interesado, puede entenderlo más claramente a través de la definición API de aSVC. Como se muestra en la siguiente figura: el primer cuadro rojo es para generar un compromiso c durante la inicialización, el segundo cuadro rojo es para actualizar c de acuerdo con la transacción, el primer cuadro verde es para generar una prueba π(i) durante la inicialización, y el segundo cuadro verde es para La transacción actualiza π(i); el cuadro azul es el nodo de bloque que usa c y π(i) para la verificación. En el proceso anterior, el trabajo central es cambiar la antigua c por la nueva c y cambiar la antigua π(i) por la nueva π(i) de acuerdo con los cambios causados ​​por la transacción. No solo debe poder completar la actualización, sino que también se puede aceptar la sobrecarga de esta actualización, este es el problema clave que debe resolver aSVC. Tomemos la actualización de c como ejemplo para presentar cómo lo hace aSVC. Como se mencionó anteriormente, lo que c promete es V, y de c a la nueva c es en realidad de la promesa V a la promesa de una nueva V

Tags：

USDC