Una nueva hoja de ruta de Ethereum sin estado: comprender los testigos de bloque y la vida útil del estado en la ruta crítica.

Ha pasado un tiempo desde que se publicó la última "hoja de ruta" integral para Ethereum sin estado, y muchas cosas han cambiado. Parece que es hora de "escribirlo todo" de nuevo.

No estamos resolviendo el problema de la minería sin estado.

No estamos resolviendo el problema de DSA (Dynamic State Access), ni vamos a adjuntar datos testigo (testigo) a las transacciones con fines de ejecución.

Es difícil precisar exactamente cuál es nuestro objetivo. Pero creo que mientras observemos las necesidades, naturalmente habrá un gradiente de objetivos.

Validadores sin estado a través de Block Witness

Queremos/necesitamos validadores para poder validar bloques sin guardar el estado completo. Una propuesta es requerir que se adjunte un testigo de bloque al bloque en el protocolo, de modo que el cliente pueda usar los datos del testigo de bloque para verificar el estado raíz obtenido al ejecutar el bloque.

Para ello necesitamos:

A: Testigos significativamente más pequeños (tamaño de datos de testigos de hasta 100 MB para árboles de Patricia hexadecimales actuales)

B: Permitir que los verificadores obtengan testigos confiables junto con bloques

Usamos un Verkle Trie para resolver el requisito A, reduciendo los gastos generales de prueba a un tamaño constante (teóricamente, según el límite de gasolina actual de 12,5 millones, el límite de tamaño de prueba es de aproximadamente 800k y el promedio es de aproximadamente 200k). Consulte también "Propuesta para aplicar un verkle trie al estado de Ethereum". También vale la pena mencionar que unificar el verkle trie requeriría modificar el comportamiento del código de operación SELFDESTRUCT o eliminar el código de operación por completo.

Resolvemos el requisito B haciendo que los mensajes de atestación se conviertan en parte de la operación del protocolo (probablemente como una lista de acceso en el encabezado del bloque), de modo que quien reciba la prueba confirme que es la prueba correcta para el bloque correspondiente. Aún no se ha determinado la responsabilidad de generar y transmitir testimonios a través de chismes.

Datos: La dirección del contrato de depósito de Ethereum 2.0 ha recibido 3200 ETH prometidos por V God: Según los datos de OKLink, hasta ahora, la dirección del contrato de depósito de Ethereum 2.0 (0x00000000219ab540356cbb839cbe05303d7705fa) ha recibido 19 685 ETH, por un valor aproximado de 7,8706 millones de dólares. Los registros de transacciones hipotecarias comienzan con 0x1db3, que pertenece a la dirección de la billetera de V God, y se ha hipotecado un total de 3200 ETH para esta dirección.

Según noticias anteriores, la condición para que Ethereum 2.0 inicie el bloque génesis es que al menos 16.384 nodos de verificación completen la hipoteca antes del 1 de diciembre, y cada nodo hipoteca 32 ETH, un total de 524.288 ETH. [2020/11/5 11:44:04]

Lectura adicional: ¿Por qué la apatridia es importante para ETH 2.0?

Restricción del crecimiento del estado a través de la expiración del estado (Caducidad del estado)

Los proponentes de bloques (o mineros) todavía necesitan generar bloques. No proponemos resolver el problema de la minería de bloques sin estado, porque esto cambiaría nuestro objetivo de aliviar la creciente carga del mantenimiento estatal.

Nuestro objetivo es imponer restricciones económicas al tamaño total del estado. Planeamos lograr esto a través de la "vida útil del estado", consulte: Límite de estado minimizado de conflicto de resurrección, toma 2 - # 17 por vbuterin.

En términos generales, la llamada vida útil del estado es dejar que el estado se "desactive" después de un período de tiempo (alrededor de 12 meses). El protocolo ya no gestiona el estado desactivado. Cualquier interacción con un estado desactivado debe ir acompañada de una prueba de que el estado desactivado se reactiva. Este esquema no introduce ningún mecanismo complejo de "arrendamiento" en la EVM, pero en realidad hace cumplir el "arrendamiento estatal". El resultado es un límite superior rígido en el tamaño total del estado.

Arquitectura de cliente sin estado a través de "Portal Client"

Lectura adicional: Renovación completa de la hoja de ruta "Stateless Ethereum" - #2 por dankrad

El protocolo DevP2P Ethereum actual no admite bien a los clientes sin estado. Incluso modificar el protocolo para admitir clientes sin estado no es trivial. Es decir, confiando solo en la "ruta crítica", podemos crear clientes adecuados para la infraestructura combinada Eth1+Eth2, pero estos clientes no serán útiles para la mayoría de las personas que usan clientes para usar la API JSON-RPC.

Otra iniciativa en curso es construir la infraestructura de red necesaria para respaldar el despliegue generalizado de "clientes de portal" ultraligeros. El llamado "portal" significa que el cliente puede ver la red y los datos relacionados, pero no tiene que participar en el acuerdo de manera significativa.

Los "Clientes del Portal" participarán en una red peer-to-peer dedicada diseñada para:

1. Recuperar cualquier estado a pedido.

State Network DHT - Actualización de desarrollo #2 - #5 por pipermerriam

2. Recupere cualquier historial de blockchain a pedido.

Alexandria - HackMD (obsoleto, pero conceptualmente representativo)

3. Participar en transmisiones de chismes de transacciones, pero sin acceso al estado.

Chismes de transacciones escalables - #3 por pipermerriam

4. Participe en transmisiones de chismes en bloque, pero no es necesario que cumpla con los requisitos de sigilo del protocolo DevP2P Ethereum.

Cualquier "cliente sin estado" que quiera atraer a los usuarios de la API JSON-RPC participará en este tipo de red. Esperamos que los clientes existentes aprovechen este tipo de red para hacerse más livianos.

Esta no es una ruta crítica para el objetivo principal de la fusión Eth1+Eth2, pero ayuda a extender los casos de uso de los clientes sin estado más allá de los validadores.

Regenesis (puede que no limpie el estado)

En el pasado, "Regenesis" tenía dos significados diferentes:

Se utiliza un nuevo bloque de génesis para reiniciar la cadena de bloques y llegar a un consenso sobre el estado de génesis.

Para "desactivar" un estado, se debe proporcionar una prueba para "revitalizar" el estado.

El mecanismo de activación/desactivación ahora se clasifica como un esquema de "caducidad de estado".

Hay muchos beneficios al reiniciar la cadena de bloques con un nuevo bloque de génesis. Entre ellos, el punto más importante es liberar a todos los clientes de los requisitos invisibles provocados por las reglas de la bifurcación histórica, haciendo que los clientes sean más simples. Esto también ayuda a los nodos a reducir el tiempo de sincronización necesario para obtener una copia completa del estado.

Triángulo binario

El mecanismo principal utilizado para reducir el tamaño del testigo ha sido reemplazado por Verkle Trie.

Lectura de referencia: EIP-3102: Estructura trie binaria

Merkelización de código

El mecanismo secundario utilizado para reducir el tamaño de los testigos ha sido reemplazado por Verkle Tries.

Lectura de referencia: EIP-2926: Merkleización de código basada en fragmentos

Enlace original:

https://ethresear.ch/t/an-updated-roadmap-for-stateless-ethereum/9046

Autor: pipermerriam

Traducción y revisión: Min Min y A Jian

Tags：

cadena de bloques