¿Cómo completa Ethereum la transformación de 1 a 2?

Título original: Introducción | eth1 -> conversión eth2

Nota del editor: esta publicación de Vitalik en el Foro de investigación de Ethereum el 19 de octubre de 2020 propone cómo imagina que Eth1 se transforme en un subsistema de la cadena de balizas fragmentadas, explicando cómo los desarrolladores, cómo percibirá el usuario el proceso. Para ser precisos, esta no es una propuesta para Eth1, porque el contenido de la propuesta no involucra cómo la cadena y la ecología de Eth1 forman un amplio consenso social para completar esta transformación, por el contrario, solo involucra la fragmentación de la baliza. ¿Qué procedimiento debe elegir un subsistema ("Eth1 EE") qué estado en Eth1 como su estado inicial? Además, los lectores también pueden usar esto para obtener una idea de la infraestructura que debería tener en la mente del autor una cadena de baliza fragmentada que está lista para completar la conversión, como la apatridia y EE; de esta manera, el desarrollo de la baliza fragmentada la cadena se puede invertir la dirección y el progreso.

La hoja de ruta presentada en este artículo se usa para completar la conversión de eth1 a eth2 Si usted es un desarrollador o usuario de aplicaciones, los cambios e incluso las interrupciones que puede sentir son en realidad muy limitados. Las aplicaciones existentes seguirán ejecutándose sin ningún cambio. Todos los saldos de cuentas, códigos de contrato y almacenamiento de contratos (incluidos los saldos ERC20, las posiciones de deuda garantizada, etc.) seguirán existiendo.

Necesitas lidiar con las siguientes situaciones:

El costo de gas de los códigos de operación de acceso IO (SLOAD, BALANCE, EXT*, CALL*) aumentará. El costo de gas de CALL es aproximadamente 1 gas por byte de código al que se accede.

Debe descargar el código que implementa las actualizaciones de red. Básicamente, esto no es diferente de otras actualizaciones como Bizancio y Constantinopla. Pero la descarga es un poco más grande, porque si aún no tiene un cliente eth2, deberá descargar uno.

La cadena de bloques de Ethereum puede suspenderse durante aproximadamente 1 hora. Una hora después, "Ethereum" parecía estar nuevamente en línea, pero de hecho, eth1 ya no era un sistema independiente, sino un subsistema que se ejecutaba dentro de eth2.

Los ingresos totales de la minería de Bitcoin en agosto fueron de 638 millones de dólares estadounidenses, un aumento del 6 % mensual: Golden Finance News, según los datos de The Block Research, los ingresos totales de la minería de Bitcoin en agosto fueron de 638 millones de dólares estadounidenses. un aumento del 6% desde los 597 millones de dólares estadounidenses en julio. [2022/9/1 13:02:29]

Eso es todo. Si es un desarrollador, siempre que se asegure de que la escala de testigo requerida por su aplicación no sea demasiado alta (medida por el número de todas las ranuras de almacenamiento + contratos + códigos de contrato a los que se accede mediante una sola transacción), su aplicación consumirá más gas. debido a La posibilidad de choque debido a cambios en la cantidad es muy pequeña.

Suponiendo que la fase 0-2 se haya completado y la cadena eth2 funcione de manera estable. La cadena eth1 también funciona de manera estable. La especificación de la fase 0 ha dispuesto un mecanismo llamado votación eth1_data. En este mecanismo, los validadores votarán para llegar a un consenso sobre el último valor de hash de bloque de la cadena principal eth1; este mecanismo se utiliza actualmente para procesar depósitos. Reutilizaremos este mecanismo para pasar el estado completo (raíz) de eth1 a eth2.

Actualmente, el mecanismo tiene un retraso de aproximadamente 6 horas (de las cuales 4 horas se deben a ETH1_FOLLOW_DISTANCE "Distancia de seguimiento de la cadena principal Eth1", y las otras 2 horas se deben al período de votación), pero estos parámetros cambiarán con el tiempo antes la conversión se completa con el tiempo, lo que reduce el retraso a alrededor de 1 hora.

El mecanismo básico que afecta la conversión de eth1 a eth2 se muestra en la siguiente figura:

Especifique una altura TRANSITION_HEIGHT (de la cadena eth1). El bloque eth1 con altura TRANSITION_HEIGHT se considerará el bloque "final" de la cadena eth1. A partir de este bloque, eth1 (de la "cadena ortodoxa") operará como un subsistema de eth2.

El gigante internacional de alquiler de automóviles Enterprise ha solicitado marcas registradas relacionadas con Metaverse: según las noticias del 2 de junio, según el tweet del abogado estadounidense Mike Kondoudis, el gigante internacional de alquiler de automóviles Enterprise ha solicitado marcas registradas relacionadas con Metaverse para su nombre y logotipo, lo que indica que ha lanzado servicios de alquiler/concesionario de automóviles virtuales y planes para servicios de transporte/compartición de automóviles virtuales. [2022/6/2 3:58:00]

El código de "validador honesto" para eth2 se ajusta en consecuencia a (1), lo que impide que los validadores voten por bloques eth1 con números de bloque > TRANSITION_HEIGHT . Si el algoritmo de votación ha seleccionado el bloque eth1 con un número de bloque > TRANSITION_HEIGHT , se votará por el bloque eth1 de TRANSITION_HEIGHT en su lugar.

Además, en caso de que se active-gnvl (2), el validador establecerá deposit_count para que sea 2**63 más alto que el valor real (es decir, el bit superior de deposit_count se usará como la marca "eth1 complete")

Cuando eth2 acepta eth1data con el indicador "eth1 completado", eth2 realiza una "transición de estado no convencional" que coloca la raíz de estado del bloque eth1 en el "entorno de ejecución de eth1" (una clase de En el estado del sistema a nivel contrato inteligente). ETH igual al suministro total de ETH en la cadena eth1 se agrega al saldo de este entorno de ejecución eth1.

Después de esto, la conversión está completa. Técnicamente hablando, la cadena eth1 seguirá funcionando, pero se ha convertido en una cadena sin valor; cuando llegue la edad de hielo, la cadena eth1 desaparecerá por completo.

El sistema eth1 ahora está dentro del sistema eth2. Por lo tanto, eth1 se transforma aún más en un subsistema de eth2 al enviar transacciones en eth2 contra el entorno de ejecución de eth1 (es decir, el subsistema eth2 descrito anteriormente). El entorno de ejecución de eth1 tiene el código que puede implementar toda la lógica de procesamiento de transacciones y EVM de eth1; tiene una función update(state_root, transaction, testigo) -> new_state_root, que puede seguir las reglas de la cadena eth1 con transacciones y mensajes testigo ( Prueba de Kerr predeterminada) como entrada para procesar la transacción y determinar la raíz del estado eth1 actualizado. Para saber cómo funcionan las atestaciones y las raíces estatales, lea Conceptos de clientes sin estado.

El código del entorno de ejecución de eth1 puede agregar funciones adicionales, es decir, extraer ETH y mensajes del entorno de ejecución de eth1 a otras partes de eth2 y copias del entorno de ejecución de eth1 en otros fragmentos. De forma predeterminada, todas las cuentas/contratos de eth1 se colocarán en el mismo fragmento, por lo que para aprovechar la mayor capacidad de eth2, debe usar esta función activamente para transferir su ETH u otras aplicaciones a otros fragmentos, pero es no dificil Necesitamos admitir transferencias de tokens entre fragmentos mediante la ampliación del estándar ERC20.

Antes de cambiar a ambas rutas de código, debemos realizar cambios en la parte del cliente que mira al usuario. El cliente comprueba eth2 para ver si se ha producido la transición. Si la transición no ha ocurrido, el cliente usa eth1 como antes para enviar transacciones, consultar saldos, etc., excepto que el cliente finge que todos los bloques eth1 con números de bloque > TRANSITION_HEIGHT no existen. Si se ha producido la transición, el cliente examina el entorno de ejecución de eth1 en eth2. El cliente completo procesará todas las transacciones en eth2 para el entorno de ejecución de eth1 de forma secuencial, a fin de continuar actualizando el árbol de estado de eth1 completo. Esto permite a los clientes completos generar certificaciones para las transacciones que desean enviar y "agruparlas" utilizando el formato eth2. Los clientes ligeros (y las billeteras como metamask) transmiten sus transacciones a los clientes completos, que les agregan datos testigo.

Desde la perspectiva del usuario, Ethereum puede "sentir" el pre-swap y el post-swap (Ethereum siente este último más fácilmente debido a PoS y EIP 1559). Si bien las rutas de código utilizadas por los intercambios de envoltura y transmisión son bastante diferentes, la funcionalidad que brindan es la misma.

Incluso podemos diseñar esta transición para que la billetera se comunique con el cliente a través de RPC sin ninguna modificación.

Digamos que crea una posición de deuda garantizada en MakerDAO y luego se va a la cama. Cuando te despiertas, descubres que la transición ha tenido lugar. Puede enviar una transacción para interactuar con su posición de deuda garantizada y liquidarla como antes, pero su cliente verá que se ha enviado la conversión, por lo que agregará los datos testigo a su transacción y la enviará a la red eth2, no a la red eth1.

Entre el momento en que la cadena eth1 alcanza TRANSITION_HEIGHT y el entorno de ejecución de eth1 en eth2 obtiene ese estado, hacemos un preprocesamiento del estado de eth1. En particular, podemos:

Reemplace el árbol Patricia hexadecimal con un árbol Merkle disperso binario y una función hash especializada para garantizar que la sobrecarga hash de las ramas siga siendo O(log(n)). Esto puede reducir el tamaño de las ramas del árbol Merkle en un factor de aproximadamente 4.

Reemplace RLP con árbol hash SSZ

Agregue campos de datos relacionados con el alquiler estatal a las cuentas

Borrar cuentas "polvorientas"

Modificar la estructura de la cuenta de acuerdo con la propuesta abstracta.

No copiaremos el método de generación de raíz de estado de Eth1 en EE, sino que calcularemos la raíz de estado aplicando el método modificado anterior (en lugar de incluir la raíz de estado de eth1 real en EE, incluiríamos la raíz del árbol de estado generado al realizar todas estas modificaciones). Este es un cálculo determinista, por lo que todos los validadores pueden calcular al mismo tiempo. Este gasto informático único puede mejorar en gran medida la eficiencia y la facilidad de uso de eth1 después de la conversión.

Enlace original:

https://ethresear.ch/t/the-eth1-eth2-transition/6265

Autor: Vitalik

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

Tags：

XMR