Golden Observation｜Propuesta de cadena de balizas ejecutables de Ethereum 2.0

Jinse Finance informó que el 26 de noviembre, hora de Beijing, el desarrollador central de Ethereum, Mikhail Kalinin, inició una propuesta de transición de Eth1 a Eth2 "Cadena de balizas ejecutables” en el Foro de investigación de Ethereum. De acuerdo con esta propuesta, este modelo de implementación de eth2, que reemplaza fragmentos ejecutables y admite un solo hilo de ejecución contenido dentro de la cadena de balizas. La idea original de esta propuesta fue propuesta por Vitalik Buterin, fundador de Ethereum, para reducir la complejidad mediante la incorporación de datos eth1 (transacciones y raíces de estado, etc.) en bloques de balizas y permitir que los proponentes de balizas generen datos eth1 ejecutables.

El siguiente es el contenido de la propuesta, que ha sido editada y editada después de Jinse Finance.

El diseño de fragmentación de Eth1 asume la comunicación con fragmentos de datos a través de la cadena de balizas. Este enfoque tiene sentido si la fase 2 con múltiples fragmentos de ejecución se desarrolla sin problemas. Debido a la hoja de ruta centrada en el resumen, Eth1 se colocará en un fragmento dedicado, lo que agregará una complejidad innecesaria a la capa de consenso y aumentará la demora entre la publicación de datos en el fragmento y el acceso al mismo.

Así que proponemos deshacernos de esta complejidad incorporando datos eth1 (transacciones, raíces de estado, etc.) en bloques de balizas y haciendo que los validadores de cadenas de balizas produzcan datos eth1 ejecutables.

Resumen de la propuesta

El motor Eth1 es mantenido por cada validador en el sistema. Cuando un validador tiene la intención de proponer un bloque de baliza, le pide a eth1-engine que cree datos de eth1. Luego, los datos de Eth1 se incrustan en el cuerpo del bloque de baliza que se está generando. Si los datos de eth1 no son válidos, también invalida el bloque de baliza que lleva esos datos.

Modificación del motor Eth1

De acuerdo con el contenido anterior, el diseño se centra en Eth1 Shard, eth1-engine y eth2-client están débilmente acoplados y se comunican a través del protocolo RPC (consulte la relación de cliente eth1 + eth2). El motor Eth1 mantiene constantemente grupos de transacciones y descargadores de estado que requieren su propia pila de red. También debe reservar almacenamiento para bloques eth1.

La propuesta actual elimina el concepto de bloques eht1, hay dos formas posibles para que eth1-engine maneje este cambio:

Cree sintéticamente un bloque eth1 a partir de los datos eth1 transportados por el bloque beacon

Modifique el motor para que el procesamiento de transacciones no requiera bloques eth1, pero use datos eth1

Usamos datos ejecutables para referirnos a datos que incluyen la raíz del estado eth1, la lista de transacciones, la base de monedas, la marca de tiempo, el hash de bloque y todos los demás datos necesarios para la funcionalidad de transición del estado eth1.

La lista de responsabilidades del motor eth1 es similar a lo que asumimos anteriormente para Eth1 Shards. Sus principales funciones son:

Ejecución de transacciones. El cliente Eth2 envía datos ejecutables al motor eth1. El motor Eth1 actualiza su estado interno mediante el procesamiento de datos.

Mantenimiento del grupo de transacciones. El motor Eth1 propaga y rastrea transacciones en el cable utilizando el protocolo de red ETH. Las transacciones pendientes se mantienen en el mempool y se utilizan para crear nuevos datos ejecutables.

Creación de datos ejecutables. Eth2-client envía hash de bloque anterior y raíz de estado eth1, base de monedas, marca de tiempo y toda la demás información necesaria para crear datos ejecutables (parte de la lista de transacciones).

administración del Estado. El motor eth1 mantiene almacenamiento de estado para poder ejecutar funciones de ejecución de estado eth1.

Nota: Los largos períodos de incertidumbre pueden generar una gran cantidad de basura en el almacenamiento, lo que aumenta el consumo de espacio en disco. Cuando la ejecución sin estado y la "creación de bloques" están en su lugar, el motor eth1 se puede ejecutar opcionalmente como una función de transición de estado puro, con una pequeña responsabilidad de que el almacenamiento de estado se puede deshabilitar, lo que reduce los requisitos de espacio en disco.

Manejo de bloques de baliza

La estructura ExecutableData reemplaza a Eth1Data como el cuerpo del bloque de baliza. Además, el procesamiento simultáneo de la cadena de balizas y eth1 permite depósitos instantáneos. Por lo tanto, los depósitos pueden eliminarse del cuerpo del bloque de baliza.

Estado de la baliza de acceso en EVM

Cambiamos la semántica del código de operación utilizado por BLOCKHASH para devolver el hash del bloque eth1. En su lugar, devuelve la raíz de la baliza. Esto permite comprobar el estado de la baliza o comprobar los datos contenidos en el bloque.

La lectura de estado asíncrono tiene una gran desventaja. Los clientes deben esperar un bloque antes de poder crear una transacción con una prueba vinculada a ese bloque o la raíz del estado que produjo. En resumen, el acceso de estado asíncrono se retrasa al menos una ranura.

Acceso directo al estado

Suponga que el motor eth1 tiene acceso a un árbol merkle que representa el estado de toda la baliza. El EVM puede entonces tener un código de operación que lea READBEACONSTATEDATA(gindex) para proporcionar acceso directo a cualquier estado de baliza. La complejidad de esta lectura depende del valor de gindex y es fácil de calcular, por lo que el precio del gas se puede deducir fácilmente. En segundo lugar, el tamaño de los datos devueltos es de 32 bytes, lo que encaja perfectamente en los 32 bytes de EVM.

Con este código de operación, se puede crear una biblioteca de accesos de estado de baliza de nivel superior, lo que proporciona una API conveniente para contratos inteligentes.

Este modelo elimina la latencia de acceso estatal. Por lo tanto, al alinear correctamente las operaciones de la cadena de balizas y las ejecuciones de eth1 (la última sigue a la primera), N-1 puede acceder a N-cruce de ranuras a datos de fragmentos de ranuras, lo que permite acumulaciones para probar los datos de la manera más rápida. Además, se reducen los datos y la complejidad computacional de la lectura del estado de la baliza.

El costo del acceso directo agrega complejidad al motor eth1. La capacidad de leer el estado de la baliza se puede lograr de diferentes maneras:

Pase el estado junto con los datos ejecutables. El principal problema con este enfoque es tratar con copias estatales de gran tamaño. Podría funcionar si el acceso directo estuviera restringido al subconjunto de datos de estado que necesita pasar una pequeña parte del estado a la ejecución.

canal de comunicación dúplex. Con un canal dúplex, eth1-engine podrá consultar el nodo de baliza para conocer el estado de la solicitud de EVM de forma síncrona. Dependiendo de cómo esté configurado el canal, la latencia puede convertirse en un cuello de botella en la ejecución de transacciones con lecturas de estado de baliza.

Motor eth1 integrado. Si eth1-engine está integrado en un nodo de baliza (por ejemplo, como una biblioteca compartida), puede leer el estado desde el mismo espacio de almacenamiento a través de las funciones de host proporcionadas por el nodo.

Se podría argumentar que la propuesta actual construye el modelo de ejecución en piedra y reduce nuestra capacidad de introducir más fragmentos ejecutables cuando sea necesario.

Por otro lado, varios fragmentos ejecutables introducen problemas como la comunicación entre fragmentos, el espacio de cuenta compartido, que son tan importantes y difíciles de resolver como la transformación esperada del modelo de ejecución.

Tags：

Bitcoin