Sincronización por fases de Ethereum: refactorización del modo de sincronización completa (Full Sync)

La sincronización por etapas se refactoriza a partir del modo de sincronización completa de Go-Ethereum para un mejor rendimiento.

La sincronización por fases requiere muchas operaciones de lectura y escritura. Si bien nuestro objetivo es poder sincronizar nodos en HDD, aún recomendamos usar SSD.

Como su nombre lo indica, la sincronización por fases requiere que se ejecuten 10 fases secuencialmente.

El cliente Turbo-Geth aprende de cada par el bloque HEAD del nodo (es decir, el bloque más reciente) y luego ejecuta cada fase por turno, buscando la brecha que falta entre el bloque HEAD local y el bloque HEAD del par.

La primera fase (descarga de encabezados de bloque) establece el bloque HEAD local.

Las etapas se ejecutan secuencialmente. Durante la ejecución de cada etapa, la etapa no terminará hasta que el estado local del nodo alcance el estado objetivo.

Es decir, en circunstancias ideales (sin cortes de red, sin reinicios de aplicaciones, etc.), cada etapa solo debe ejecutarse una vez para completar la sincronización inicial.

Después de la última etapa, todo el proceso de sincronización comenzará nuevamente, buscando nuevos encabezados de bloque para descargar.

Si reinicia la aplicación entre dos etapas, la aplicación se reiniciará desde la primera etapa.

Si reinicia la aplicación mientras se ejecuta una etapa, la aplicación se reinicia desde la etapa actual para completar esa etapa.

A través del gráfico circular a continuación, podemos ver la proporción de tiempo que consume cada etapa (estos son los datos obtenidos de la sincronización completa). Aunque estos datos no son precisos, pero bastan como referencia.

Si la cadena de bloques se reorganiza, necesitamos "retroceder" algunos de los datos sincronizados.

La regresión se refiere a la regresión de la última etapa a la primera etapa. Sin embargo, una cosa a tener en cuenta es que el grupo de transacciones no se actualiza hasta que realizamos el respaldo, por lo que conocemos el nuevo nonce.

El orden de fase de la reversión se muestra en el siguiente ejemplo (ocurre secuencialmente de derecha a izquierda).

estado.unwindOrder = []*Etapa{

   // Desconexión del conjunto de tx (la reinyección de transacciones en el conjunto debe ocurrir después de la ejecución de desconexión)

Las autoridades financieras de Corea del Sur están tomando medidas activamente para regular los atributos de valores de los activos virtuales: según las noticias del 3 de agosto, siguiendo a la Comisión de Bolsa y Valores de EE. UU. (SEC), las autoridades financieras de Corea del Sur también están tomando medidas activamente para regular los atributos de valores de los activos virtuales. activos virtuales. El Servicio de Supervisión Financiera (FSS) de Corea del Sur anunció que además del anuncio del FSS del "Plan de Supervisión de Tokens de Valores" a finales de año, si está claro que los tokens que se negocian actualmente son valores bajo la ley actual, el Supervisor Financiero La autoridad puede realizar investigaciones y sanciones. El encargado de la FSC dijo que el sistema legal coreano es diferente al de Estados Unidos, por lo que es necesario revisar si el token es un valor bajo la ley de mercado de capitales de Corea.

Se informa que DAXA, una agencia de consulta conjunta establecida por las cinco principales criptobolsas de Corea del Sur (Upbit, Bithumb, Coinone, Korbit y Gopax), también está discutiendo qué activos virtuales son valores a través de inspecciones internas y recopilando sugerencias externas. Sin embargo, el alcance de los tokens de seguridad no está claro y es difícil garantizar que tales revisiones internas sean consistentes con el juicio legal de las autoridades. Por lo tanto, el mercado espera que el intercambio coreano decida si listar tokens a través de un juicio más conservador de los atributos de los valores.

Noticias anteriores, la SEC de EE. UU. enumeró nueve criptomonedas involucradas en el incidente de "comercio de información privilegiada de Coinbase" como valores, y está investigando si Coinbase enumeró valores no registrados. (Noticias económicas del Herald) [2022/8/3 2:55:56]

   etapas, etapas, etapas, etapas, etapas, etapas, etapas, etapas, etapas, etapas,

 }

Preprocesamiento a través de  ETL 

Algunas etapas utilizan nuestro marco ETL para ordenar los datos por valor clave antes de insertarlos en la base de datos.

Esto puede reducir en gran medida la situación de amplificación de escritura de la base de datos (amplificación de escritura).

Entonces, cuando generamos un índice, o Hashed State, pasamos por un proceso de varios pasos.

Escriba los datos procesados ​​en varios archivos temporales ubicados en el directorio de datos;

Luego use una pila (montón) para insertar los datos en el archivo temporal en la base de datos e inserte los datos en el orden que pueda minimizar la amplificación de escritura de la base de datos.

Esta optimización a veces aumenta la velocidad de escritura en órdenes de magnitud.

Cada etapa contiene dos funciones, que son ExecFunc  en la etapa de avance y  UnwindFunc en la etapa de retroceso.

En teoría, algunas etapas pueden funcionar sin conexión, pero la versión actual no implementa esta función.

Fase 1: Descargar encabezados de bloques

En esta etapa, descargamos todos los encabezados de bloque entre el bloque HEAD local y el bloque HEAD del par.

Esta etapa requiere un uso intensivo de la CPU y es adecuada para su uso con procesadores multinúcleo debido a la prueba de trabajo requerida para verificar los encabezados de los bloques.

La mayoría de los retrocesos comienzan en esta etapa debido a las reorganizaciones de blockchain.

Esta fase empuja el puntero HEAD local (que apunta al bloque actualizado).

Fase 2: Block Hash

Extraiga una tabla de índice que asigne el valor hash del bloque al número de bloque (blockHash -> blockNumber) del encabezado del bloque para admitir una búsqueda más rápida y hacer que el proceso de sincronización sea más amigable para los discos duros mecánicos.

Etapa 3: descargar el cuerpo del bloque

En esta etapa, también descargaremos el cuerpo del bloque del encabezado del bloque descargado en la etapa anterior.

Se requiere una buena conexión a Internet para esta fase. La gran mayoría de los datos se descargan en esta etapa.

Fase 4: Restauración del remitente

Esta etapa recupera y almacena el remitente de cada transacción en cada bloque descargado.

Esta etapa también requiere un uso intensivo de la CPU y es adecuada para su uso con procesadores multinúcleo.

No se requiere conexión a Internet en esta etapa.

Etapa 5: Ejecución de bloques

En esta etapa, ejecutamos cada transacción en todos los bloques previamente descargados.

Una cosa a tener en cuenta es que durante la ejecución del bloque no verificamos el hash raíz ni creamos un árbol Merkle.

Esta etapa es de subproceso único, no requiere redes y ocupa mucho espacio en disco. Si la ejecución del bloque falla, la etapa se puede revertir.

Etapa 6: Cálculo de raíces estatales

Esta fase construye el árbol Merkle y verifica el hash raíz del estado actual.

Esta fase también crea hashes intermedios y los almacena en la base de datos.

Si no se almacenaron previamente hashes intermedios (lo que podría suceder durante la primera sincronización inicial), esta etapa construye el árbol Merkle completo y su hash raíz.

Si no hay hashes intermedios en la base de datos, esta fase utiliza el historial del bloque para determinar qué hashes están desactualizados y cuáles son los más recientes, y luego usa los hashes más recientes para construir parte del árbol Merk Er, solo reconstruye hashes obsoletos. .

Si el hash raíz no coincide, retrocede un bloque.

Fase 7: Generar estado hash

Durante la ejecución, Turbo-Geth usa almacenamiento de estado simple.

Estado simple: en el estado estándar (que llamamos "estado hash"), la dirección de la cuenta y el elemento de almacenamiento es  keccak256(dirección) , pero en el estado general, tanto la dirección de es  dirección  .

Sin embargo, para garantizar que algunas API funcionen correctamente y sigan siendo compatibles con otros clientes, también generamos un estado hash.

Si el estado hash no es nulo, observamos el History ChangeSet y solo actualizamos los elementos que han cambiado.

No se requiere conexión a Internet en esta etapa.

Etapa 8, 9, 10 : creación de índice

Se generan 3 índices durante la sincronización.

Estos 3 índices pueden deshabilitarse ya que no son utilizados por ninguna API.

Índice de consulta de transacciones

La tabla de índice consta de una asignación de hash de transacción a números de bloque.

Índice del historial de la cuenta

El índice almacena una asignación de direcciones de cuenta a una lista de bloques en los que ha cambiado el estado de la cuenta.

Índice histórico de la tienda

El índice almacena el mapeo desde la dirección del elemento de almacenamiento hasta la lista de bloques donde el elemento de almacenamiento ha cambiado hasta cierto punto.

En esta etapa, iniciamos el grupo de transacciones o actualizamos su estado. Por ejemplo, si se incluyen algunas transacciones en los bloques que hemos descargado, estas transacciones se eliminan del grupo de transacciones.

Al revertir, volveremos a agregar las transacciones en el bloque revertido al grupo de transacciones.

Enlace original:

https://github.com/ledgerwatch/turbo-geth/tree/master/eth/stagedsync

Por Alex Sharov

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

Tags：

Bitcoin