Desarrollador principal de Ethereum: se reemplazará el árbol hexadecimal MPT

Imagina que estás traduciendo un libro de 5000 páginas y el autor sigue llamándote para decirte que hizo ajustes a la historia y eso afecta las páginas que ya tradujiste... y esto podría seguir y seguir, eso es ethereum. Un dilema similar es encontrado en la conversión del árbol hexadecimal MPT utilizado actualmente a una estructura de árbol binario. En este sentido, Guillaume Ballet, el desarrollador central de Ethereum, propuso una solución que puede completar la operación de conversión en tres pasos en unos pocos días.

Con respecto a la propuesta, el cofundador de Ethereum, vitalik, comentó:

Aquí está la traducción:

Uno de los muchos problemas que afectan a Ethereum es la forma en que se almacenan los datos de cuentas y contratos, y la estructura elegida actualmente de Ethereum se llama Merkle Patricia Tree, o MPT para abreviar. Si bien tiene mucho sentido en teoría, en la práctica crea más problemas de los que resuelve. Los desarrolladores principales han estado discutiendo la conversión a árboles binarios durante años, y en este artículo aclararé mis pensamientos sobre el problema y luego le daré una solución.

El proceso propuesto introduce un período de transición durante el cual existirán ambas estructuras de árbol. La ventaja de esto es que la cadena principal puede seguir funcionando mientras se convierte la estructura de árbol y también garantiza que todas las cuentas se conviertan al formato de árbol binario.

Antecedentes

Actualmente, las cuentas de Ethereum se almacenan en un árbol hexadecimal. Los llamados dieciséis tenedores significan que un nodo tiene 16 nodos secundarios, lo cual es bueno en teoría porque significa que necesita menos "etapas" para almacenar todos sus datos.

Por ejemplo, este es el proceso de representar el par de clave y valor (170, v) en forma de árbol hexadecimal. En hexadecimal, 170 se representa como 0xaa, por lo que solo necesita dos capas: una para la primera a y otra para la segunda a.

Wirex completa la campaña de financiación colectiva de 3,7 millones de libras esterlinas antes de lo previsto, con la participación de casi 7000 inversores: la plataforma de pago de criptomonedas Wirex completó su campaña de financiación colectiva de 3,7 millones de libras esterlinas lanzada en Crowdcube 15 días antes de lo previsto, un 370 % más que el objetivo original y casi 7000 inversores. por 7000 inversores. Los fondos recaudados se utilizarán para ampliar su oferta de productos y lanzar 5 nuevas criptomonedas en su plataforma en países de Europa del Este. La compañía también utilizará los nuevos fondos para lanzar una Mastercard multidivisa, actualizar su programa de recompensas y expandirse a EE. UU. y Japón. La compañía espera que la medida la ayude a alcanzar su objetivo de tener 10 millones de clientes para fines de 2021. Se dice que Wirex está valorado actualmente en £ 125 millones, con más de 3 millones de clientes en 130 países de todo el mundo que utilizan su tarjeta multidivisa para almacenar y pagar con moneda fiduciaria y criptomonedas. (Altfi) [2020/10/14]

Figura 1: Este es un ejemplo de trie hexadecimal que muestra cómo se almacena el valor "v" en la clave 0xaa. Este árbol tiene solo claves de 2 bytes de largo y solo se expande a lo largo del subárbol de la clave 0xaa. Por brevedad, los subárboles irrelevantes se reemplazan con "...".

Tenga en cuenta que el árbol es poco profundo y ancho. Luego compárelo con la siguiente representación de árbol binario de los mismos pares de clave y valor. En binario, 170 se representa como 10101010.

Figura 2: Los mismos pares clave-valor que en la Figura 1, almacenados en forma de árbol binario. Para abreviar, los subárboles no relacionados se indican como "...".

Como puede ver, el árbol es mucho más profundo y angosto.

En Ethereum, cada bloque contiene un campo stateRoot, que es el hash de la raíz MPT. En resumen, este hash se obtiene triturando la lista de hash de los 16 hijos de la raíz. Cada una de estas columnas de sub-hash, a su vez, es el hash de su lista de sub-hash, y así sucesivamente.

Cada vez que se genera un nuevo bloque, el minero actualiza el árbol de cuentas y vuelve a calcular su hash raíz. El hash se almacena en el campo stateRoot del nuevo bloque y luego se sella el nuevo bloque.

La Figura 3 muestra que el campo raíz de estado del encabezado del bloque apunta a la raíz del árbol hexadecimal.

Aquí radica el problema: volver a calcular la raíz hash mediante el hash de todos los nodos lleva demasiado tiempo, por lo que, para calcular el nodo raíz, los mineros recuperarán hashes hermanos de la base de datos. Aunque no lleva mucho tiempo obtener todas las hojas de la base de datos y hacer hash de todo el árbol, esta operación aún lleva mucho tiempo. Esto se debe a que cada hash debe obtenerse de la base de datos.

En un árbol hexadecimal, normalmente se obtienen 15 hashes hermanos por etapa. En el ejemplo anterior, son 30 hashes.

Aún más profundo, un árbol binario solo necesita un hash hermano por etapa. En el ejemplo anterior, ¡solo hay 8 hashes! Por eso, en la práctica, los árboles binarios son mejores.

Anular método de conversión

Desafortunadamente, cambiar Ethereum de un árbol hexadecimal a un árbol binario no es una tarea fácil. Hay una gran cantidad de datos para transformar y se necesitan más de 15 segundos de tiempo de bloque para realizar los cambios.

Más allá de eso, imagina que estás traduciendo un libro de 5000 páginas y el autor sigue llamándote para decirte que hizo ajustes a la historia, lo que afecta las páginas que ya tradujiste... y podría durar para siempre.

Este es el problema que tiene Ethereum actualmente, porque los usuarios pueden actualizar las direcciones que se han convertido, lo que significa que debe comenzar el proceso de conversión nuevamente.

Una propuesta para resolver este problema es tener un período de transición, durante el cual se coloca un árbol binario superpuesto encima del árbol hexagonal, cuya función es contener todos los cambios que ocurren en el estado hasta que el árbol base se transforma en un árbol binario.

Esta transición se dividirá en tres pasos:

En este enfoque, se determina que a la altura del bloque H1, el bloque tiene dos stateRoots: uno para el árbol hexadecimal "base" y otro para el árbol binario "superpuesto".

Figura 4: Durante la transición, el bloque tiene 2 raíces de estado: una es la raíz de solo lectura de un árbol hexadecimal tradicional y la segunda es la raíz del árbol binario "superpuesto".

El árbol hexadecimal se considera de solo lectura, por lo que cualquier actualización del estado será una actualización del árbol superpuesto.

Cuando una transacción lee o actualiza una cuenta, el sistema primero busca en el árbol superpuesto. Si la cuenta no se encuentra allí, el sistema buscará el valor en el antiguo árbol hexadecimal.

Mientras tanto, el hextree se está convirtiendo en segundo plano. Ahora se pueden hacer inserciones sin preocupaciones, ya que todos los cambios se almacenan en el árbol superior.

Una vez que se complete el proceso de conversión en segundo plano, los mineros anunciarán que están listos para cambiar reemplazando la raíz base del árbol hexadecimal de solo lectura con el resultado de la conversión. Las operaciones de lectura y escritura en el estado son las mismas que en el paso 1.

Figura 5: la segunda etapa de conversión, el encabezado del bloque reemplaza la raíz base del árbol hexadecimal con el árbol binario transforma las raíces subyacentes para señalar a la red que están listas.

Cuando una secuencia de bloques lo suficientemente grande tiene el mismo valor para la raíz base transformada, significa que la mayoría de los mineros han completado la transformación y han llegado a un consenso sobre cómo debería verse el árbol transformado. A continuación, ingrese al proceso de fusión.

El proceso de fusión ocurre de manera incremental: cada vez que se genera un nuevo bloque, se eliminan n claves de la superposición y se reinsertan en el árbol base. Este proceso continuará hasta que se eliminen todas las claves de la superposición. En esta etapa, la raíz del estado de anulación se elimina del encabezado del bloque.

Además, si la ejecución de una transacción escribe en una clave que se encuentra en el árbol superpuesto, esa clave se elimina del árbol superpuesto y se escribe directamente en el árbol base.

Siguiente

Hemos creado un prototipo inicial para estimar cuánto tiempo llevará completar la transición. Creemos que todo el proceso se puede completar en un tiempo razonable (del orden de unos pocos días). Publicaré más detalles a medida que mejore el algoritmo.

Gracias

Esta propuesta se benefició de los valiosos aportes de Alexey Akhunov, Vitalik Buterin, Anna George, Sina Mahmoodi, Tomasz Stanczak y Martin H. Swende.

Discusión relacionada: https://ethresear.ch/t/overlay-method-for-hex-bin-tree-conversion/7104

Tags：

OKX Exchange App Download