jakiro
Autor: Vitalik, fundador de Ethereum;
Uno de los EIP desconocidos en la reciente horquilla Split DenCun Hard Split es el EIP-6780, que elimina la mayor parte de la función del código de operación autográfico.
>
Este EIP es un ejemplo clave del desarrollo del acuerdo de Ethereum.Eliminando la complejidad y agregandoNuevoGarantía de seguridad para simplificar los esfuerzos del acuerdo.Esta es una parte importante de la «purga» que llamo: Ethereum simplificado y los proyectos de deuda técnica despejada.Habrá más EIP con un espíritu similar, así queVale la pena comprender cómo los objetivos EIP-6780 y qué otros EIP pueden ser eliminados en la purga en el futuro.
¿Cómo simplifica EIP-6780 el acuerdo de Ethereum?
El EIP-6780 reduce la función del código de operación.Esto en sí no ha disminuidoespecificaciónLa complejidad.Sin embargo, mejora introduciendo dos nuevas variables invariableslograrEl
1. Después de EIP-6780, el número de ranuras de almacenamiento que se pueden editar en un solo bloque es máximo (aproximadamente: límite de gas / 5000).
2. Si el contrato tiene un código no vacío al comienzo de la transacción o bloqueo, tendrá el mismo código al final de la transacción o el final del bloque.
Anteriormente, estas variables invariantes no eran ciertas:
2. El código del contrato puede cambiarse de no vacío a vacío a través de la autocomprobación.Esto dificulta que las transacciones en las billeteras abstractas de la cuenta usen bibliotecas de código sin ser atacadas fácilmente por DOS.
Ahora, estas no son variablesTodoTrue hace que sea más fácil construir un cliente de Ethereum y otros tipos de infraestructura.Unos años más tarde, espero que el futuro EIP pueda completar este trabajo y
¿Qué otras «purgas» están en curso?
-
Geth ha eliminado recientemente miles de líneas de código y eliminó el soporte para la red POW previa a la mérima.
-
Este EIP refleja oficialmente tal hecho: ya no necesitamos código para preocuparnos por las «cuentas vacías» (ver: EIP-161, presenta este concepto como parte de la reparación del ataque DOS de Shanghai)
-
La ventana de almacenamiento en Dencun es de 18 días, lo que significa que los nodos de Ethereum solo necesitan unos 50 GB para almacenar datos de blob, y este número no aumentará con el tiempo con el tiempo.
Los dos primeros mejoraron significativamente la experiencia de los desarrolladores de clientes.Este último ha mejorado significativamente la vida útil de los operadores de nodos.
¿Qué otras cosas pueden requerir purga?
Preestablecido (precompilos)
Pre -compilación es el contrato de Ethereum.Esta idea es que la pre -compilación se puede usar para realizar formatos complejos que no se pueden implementar de manera efectiva en EVM.
Hoy, la preocompilación es muy exitosa, especialmente la aplicación basada en aplicaciones basada en la preocompilación de la curva ovalada.Sin embargo, hay otras pre -compilación que rara vez usan:
-
RIPEMD-160 : La introducción de la función hash es admitir una mejor compatibilidad con bitcoin -
Identidad : Volver a la pre -compilación de la misma salida que la entrada -
Blake2 : La introducción de la función hash es admitir una mejor compatibilidad con Zcash -
Moderno Introducir una potencia de moho muy grande para admitir el cifrado basado en RSA
Los hechos han demostrado que las necesidades de estos pre -compilaciónLejosDebajo de lo esperado.
Hay dos formas de eliminar estas pre -compilación:
-
Simplemente elimine la pre -compilación, por ejemplo.EIP-7266 elimina Blake2.Esto es simple, pero destruirá cualquier aplicación que todavía la esté usando.
-
Reemplace la pre -compilación en el bloque de código EVM que realiza la misma operación (aunque inevitablemente generará mayores costos de gas), por ejemplo.Este borrador de EIP se realiza para la pre -compilación de la identidad.Esto es más difícil, pero casi definitivamente no destruirá la aplicación usándola (a menos que haya muy pocos casos, el costo del gas del nuevo código EVM excede el de algunos límites de gas de bloque de entrada)
-
Las especificaciones son más simples y claras
-
En comparación con el árbol hexagonal de Merkle Patricia actual, en la mayoría de los casos, la longitud de la prueba de Merkle se ha acortado 4 veces
-
En comparación con el peor y el peor de los casos, la longitud de la prueba de Merkle está limitada (por ejemplo, el código de contrato o la salida de recibo largo)
-
No es necesario lograr un código de operación de bits complejo (necesidades RLP)
-
Para los casos de uso de ZK-Snark, se puede reutilizar la implementación existente de la implementación existente del árbol binario Merkle
Bloque histórico (EIP-4444)
Hoy, se espera que cada nodo Ethereum almacene permanentemente todos los bloques históricos.Durante mucho tiempo, las personas siempre han creído que este es un método muy derrochador, y debido a los altos requisitos de almacenamiento, se ha vuelto innecesario ejecutar el nodo Ethereum.En Dencun, presentamos a Blob, que solo necesita almacenar unos 18 días.Después de usar EIP-4444, después de un período de tiempo, el bloque Ethereum también se eliminará del nodo Ethereum predeterminado.
Un problema clave a resolver es: si los registros históricos antiguos no están almacenados por cada nodo, entonces qué usarVenir¿Y eso?De hecho, grandes entidades como los navegadores de bloques lo harán.Sin embargo, también es posible almacenar y pasar el protocolo P2P para almacenar y pasar la información, y no es difícil, lo que está más optimizado para las tareas.
La cadena de bloques Ethereum es permanente, pero se requiere que cada nodo almacene todos los datos para siempre es una forma muy «excesiva» de lograr esto permanente.
Una forma es apuntar a la red de torrent de punto simple para la antigua historia.El otro es un acuerdo más claro para el uso de Ethereum, como la red de portal.
O el formato de factor:
>
Reducir el almacenamiento del nodo Ethereum puede aumentar en gran medida el número de personas dispuestas a ser nodos.EIP-4444 también puede reducir el tiempo de sincronización de nodos, lo que también simplifica el flujo de trabajo de muchos operadores de nodos.Por lo tanto, EIP-4444 puede mejorar en gran medida la descentralización de los nodos de Ethereum.Potencialmente, si cada nodo está por defecto en una pequeña parte de los registros históricos, incluso podemos almacenar una copia de cada registro histórico específico en Internet como hoy.
Reforma log
Cita este borrador de EIP:
La introducción original del registro era permitir que la aplicación registre información sobre los eventos en la cadena para que las aplicaciones descentralizadas (DAPP) puedan consultar fácilmente esta información.Usando un filtro Bloom, DAPP podrá navegar rápidamente por los registros históricos, identificar varios bloques que contienen registros relacionados con su aplicación y luego identificar rápidamente qué transacciones individuales tienen los registros requeridos.
De hecho, este mecanismo es demasiado lento.Casi todos los DAPP que visitan registros históricos no están al final a través de las llamadas de RPC de nodos Ethereum (e incluso nodos de alojamiento remoto), sino a través de protocolos adicionales centralizados.
¿Qué podemos hacer?Podemos eliminar el filtro de floración y simplificar
Registro Código de operación, de esta maneraélLo que haces es crear un valor que ponga el hash en el estado.Luego, podemos construir un protocolo separado, utilizando ZK-snark y un cálculo incremental aumentado (IVC) para generar el «árbol de registro» correcto, indica que todos los registros dados que son fáciles de buscar en la tabla de búsqueda que es fácil de buscartema Y si necesita registros y aplicaciones, desea ser descentralizado, puede usar estos protocolos separados.Volver a SSZ
Hoy, la mayoría de las estructuras de bloques (incluidas las transacciones y los recibos) de Ethereum todavía usan un formato obsoleto basado en RLP y Merkle Patricia Trees para su almacenamiento.Esto hace que sea dificultades innecesarias desarrollar aplicaciones utilizando estos datos.
La capa de consenso de Ethereum se ha desplazado a simpleperializar (SSZ) más limpio y eficiente:
>
Fuente: https://eth2book.info/altair/part2/building_blocks/merkleization/
Sin embargo, todavía necesitamos completar la conversión y mover la capa de ejecución a la misma estructura.
Las principales ventajas de SSZ incluyen:
Hoy, hay tres tipos de estructuras de datos cifradas en Ethereum: árbol binario SHA256, lista de hash SHA3 RLP y árbol de patricia hexadecimal.Una vez que completemos la transición a SSZ, solo tendremos dos: árbol binario SHA256 y árbol Verkle.A la larga, una vez que nos viene bien en el hash de sarking lo suficiente, es probable que usemos el árbol binario de Merkle para reemplazar el árbol binario SHA256 y Verkle con el árbol binario de Merkle que usa el hash amigable de Snark (una especie de estructura de datos cifrada para todo Ethereum).
