Con la operación de la red , la cantidad de datos de nodo se hace cada vez más grande, y el costo de ejecutar el nodo completo de es cada vez mayor. Ahora, un nodo completo de , la cantidad de almacenamiento de datos de bloque es a menudo cientos de G hasta T, por un lado, conduce directamente a un aumento significativo en el costo de almacenamiento de la computadora que ejecuta el nodo completo. Si queremos ejecutar el nodo en una PC común, la PC ordinaria se usa para los datos ligeros de . Obviamente, la mayoría del espacio de almacenamiento en el disco duro es difícil de recibir para las personas; Por un lado, también limita en gran medida los escenarios de aplicación de la tecnología . Ya sea un teléfono móvil o un dispositivo IoT, actualmente no tiene la capacidad de cargar algunos discos duros de almacenamiento T. .
Para resolver este problema, diferentes plataformas de han propuesto sus propias soluciones de nodo ligero, entre las cuales las típicas son el esquema SPV de Bitcoin y el esquema de verificación de estado de Ethereum. Sin embargo, hay ciertas deficiencias en estos dos esquemas. El esquema SPV de Bitcoin puede verificar que la transacción haya ocurrido realmente, pero no puede verificar el valor específico de la cuenta en un momento determinado; el esquema de verificación de estado de Ethereum puede verificar que la transacción se haya producido, y el valor específico de la cuenta se puede verificar en un momento determinado, pero debido a que este esquema requiere que los datos se escriban en el encabezado del bloque, el rendimiento del consenso y la solidez son reducidos.
Basado en el esquema SPV de Bitcoin y el esquema de verificación de estado de Ethereum, Ultrain propone un nuevo esquema de nodo ligero, que no solo puede cumplir con los requisitos funcionales de verificar la ocurrencia de transacciones y verificar los valores específicos de las cuentas en un momento determinado, sino también cumplir con el consenso requisitos en términos de rendimiento y robustez, donde el rendimiento es más de 10 veces el de la solución Ethereum.
Los nodos en el modo de nodo ligero no necesitan sincronizar grandes cantidades de datos de bloque. Con el método de verificación de Merkel del estado mundial, los nodos pueden verificar la corrección del estado sin reproducir los bloques históricos, lo que puede habilitar más aplicaciones. Escenarios (como ejecutar nodos ligeros en dispositivos integrados con recursos limitados). Este artículo presentará el problema de verificación del estado mundial, el programa SPV de Bitcoin, el programa de verificación del estado mundial Ethereum y el programa específico adoptado por Ultrain.
1, la cantidad de datos de sincronización de nodos
La red de nodos de puede entenderse como una máquina de estado distribuida. Cada nodo comienza desde el mismo estado de creación y actualiza el estado de creación bloque por bloque de acuerdo con las transacciones contenidas en cada bloque, formando un estado mundial constantemente actualizado. Con el tiempo, los datos almacenados localmente en cada nodo continuarán creciendo, principalmente incluyendo datos de bloques históricos y datos de estado mundial actualizados constantemente. El volumen de datos acumulados de los bloques producidos por Bitcoin desde su creación en 135 meses (2009/01 ～ 2020/03) ha alcanzado 263.6GB, y ahora está creciendo a una tasa de más de cuatro GB por mes.
Cuando el nodo completo de Ethereum se sincroniza en modo completo (el nodo sincronizará todos los encabezados de bloque, cuerpos de bloque y reproducirá las transacciones en el bloque para generar datos de estado mundial) desde la red, los datos actuales que se sincronizarán han alcanzado doscientos o trescientos GB, si archiva el estado del mundo histórico, la cantidad de datos ha excedido 4T. Los nodos de Ethereum también admiten el modo rápido para la sincronización. La diferencia entre este modo y el modo completo es que las transacciones en el bloque no se reproducen para reconstruir el estado mundial, sino que los datos del estado se sincronizan desde la red. Además, el nodo Ethereum también admite el modo de sincronización de luz. En este modo, el nodo solo sincroniza los datos del encabezado del bloque y no sincroniza el cuerpo del bloque y los datos de estado. Solo se obtiene de la red cuando se necesita el bloque y el estado correspondientes.
A partir de los datos anteriores de bitcoin y Ethereum, podemos ver que la cantidad de datos necesarios para implementar y ejecutar un nodo completo está aumentando, lo que lleva a requisitos cada vez más altos para las especificaciones de hardware de las máquinas de nodos y el umbral del ancho de banda de la red. Un nuevo nodo tarda unos días en completar la sincronización de datos históricos, y luego puede comenzar a participar en el proceso de consenso para generar bloques. El costo de ejecutar todos los nodos es relativamente alto. En el documento técnico de bitcoin, se menciona el esquema SPV que pueden usar los nodos ligeros, que también se puede usar para la verificación de pagos sin sincronizar todos los datos de bloque. La verificación del pago aquí es solo para verificar que el pago de la transacción ha ocurrido, no para verificar la legitimidad de la transacción (como si el saldo de la cuenta es mayor que el monto de la transferencia, etc.).
2, esquema de Bitcoin SPV
SPV (verificación de pago simple) se describe en el documento técnico de bitcoin. SPV es un esquema técnico que puede verificar la validez del pago sin ejecutar todos los nodos y guardar todos los encabezados de bloque en un entorno de nodo ligero. La estructura de bloques en bitcoin se divide en cabeza de bloque y cuerpo de bloque. La cabeza del bloque contiene los atributos necesarios del bloque, que tiene un tamaño de solo 80 bytes. El cuerpo del bloque contiene todas las transacciones bajo el bloque actual. Generalmente, un bloque contiene cientos de transacciones, cada transacción generalmente requiere más de 400 bytes.
Bitcoin utiliza la estructura de datos del árbol de Merkel para organizar las transacciones contenidas en el bloque: agrupe todas las transacciones en el bloque en pares, procese las transacciones y luego procese el hash resultante, y repita el proceso hasta que solo quede un hash, que se llama raíz de Merkle. El nodo en la parte inferior del árbol de Merkel es el valor hash de los datos de la transacción. Cada nodo primario es el valor hash combinado de dos nodos secundarios. Finalmente, el nodo raíz se calcula mediante el cálculo de capa arriba. Este valor raíz de Merkel se almacena en el bloque de bitcoin.
Después de que el nodo ligero obtiene todos los cabezales de bloque en la cadena más larga de la red y los almacena localmente, puede llevar a cabo la verificación de pago SPV: el cliente ligero primero calcula el valor hash de la transacción de pago a verificar; luego localiza el bloque que contiene el hash de la transacción y obtiene la secuencia de valores de hash necesaria para construir el árbol de Merkel de la transacción de pago que se verificará desde el bloque; de acuerdo con la espera de corrección Verifique el valor hash de la transacción y su secuencia de valores hash necesarios para calcular la raíz de Merkel; compare el valor de raíz de Merkel calculado con la raíz de Merkel en la cabeza del bloque, si es igual, demostrará que la transacción es real.
El tamaño de la cabeza de bloque de bitcoin siempre se fija en 80 bytes, aproximadamente 6 bloques por hora, 52560 bloques por año, y la nueva capacidad de almacenamiento es de aproximadamente 4 millones de bytes por año. El esquema SPV ahorra enormemente el espacio de almacenamiento de los nodos ligeros. Del proceso anterior, podemos ver que este esquema SPV de bitcoin solo asegura que la transacción de verificación haya sucedido, pero no se puede usar para verificar los cambios en el estado mundial causados por el intercambio. Ethereum almacena el valor de Merkel de la transacción en el encabezado del bloque, que se puede aplicar al esquema SPV similar a bitcoin; Además, Ethereum también almacena el valor de Merkel del estado mundial en la cabeza del bloque, que se puede utilizar para verificar el valor del estado mundial.
3, esquema de verificación del estado mundial de Ethereum
La cuenta de Ethereum contiene cuatro atributos, nonce, balance, storageroot y codehash. Ethereum usa stateobject para administrar el estado de la cuenta, y la cuenta está marcada de forma exclusiva con la dirección. Todos los objetos de cuenta se insertan en la estructura Merkle patrica trie (MPT) uno por uno para formar un estado. El campo raíz en la estructura de datos del encabezado de bloque almacena el valor raíz de statetrie, que es el valor hash del estado mundial.
Suponemos que hay dos cuentas a y B en la cadena de bloques Ethereum, y el saldo inicial de la cuenta es de 10 monedas de éter. En el bloque con el número de 1000, ha habido una transacción: la cuenta a transfiere una moneda de éter a la cuenta B, cambia el saldo de la cuenta a a 9 monedas de éter y el saldo de la cuenta B a 11 monedas de éter (excluyendo los honorarios del minero ) En el cliente ligero Ethereum similar al bitcoin SPV, podemos usar los datos raíz de Merkel de la transacción almacenada en el bloque con el número de bloque 1000 para verificar que la cuenta a haya transferido un Ethereum a la cuenta B, pero solo usando los datos raíz de Merkel de la transacción, no podemos verificar si el saldo de la cuenta a es 9 Ethereum (o el saldo de la cuenta BI no puede verificar el valor específico del estado mundial.
El valor de raíz de Merkel (raíz de campo) del estado mundial de la cabeza del bloque en Ethereum se puede usar para verificar el valor específico del estado mundial. Este campo es el valor hash RLP del nodo raíz del "estado trie" en el Ethereum indicadob. En el bloque, cada cuenta está representada por un objeto de objeto de estado, y la cuenta está identificada de forma exclusiva por una dirección. Su información se modifica durante la ejecución de transacciones relacionadas. Todos los objetos de cuenta se pueden insertar en una estructura Merkle patrica trie (MPT) uno por uno para formar un "estado trie".
En eip-1186 de Ethereum, se agrega la interfaz ETH (getproof) para devolver la información (ruta Merkle) requerida por la verificación de cuenta de Merkel y sus valores de almacenamiento para completar la verificación de los valores del estado mundial. Eth? Getproof tiene tres parámetros de entrada:
1) Datos: 20 bytes – dirección de la cuenta (cuenta externa / cuenta de contrato)
2) Matriz: 32 bytes – dirección de datos de estado de paridad
3) Cantidad | etiqueta: – es el número de bloque especificado o cadena "más reciente" o "más antiguo"
Los datos devueltos por esta interfaz son los siguientes:
1) Saldo: saldo de cuenta
2) Codehash: valor hash del código de la cuenta del contrato; se devuelve un valor fijo para una cuenta externa
3) Nonce: el valor nonce de la cuenta, que indica cuántas transacciones se han enviado o cuántos contratos se han creado.
4) Storagehash: valor raíz de Merkel del valor de estado
5) Prueba de cuenta: Se requiere la matriz de secuencia de Merkel para la verificación de la cuenta
6) Storageproof: una matriz de información requerida para la verificación del valor del estado, incluidos los siguientes campos:
Tecla Ø: dirección correspondiente al valor de estado
Ø valor: valor específico del estado
Øproof: matriz de secuencia de Merkel requerida para la verificación del valor del estado
Después de que el nodo ligero obtenga la información de retorno anterior a través de la interfaz ETH – getproof, primero, de acuerdo con los cuatro valores de atributo devueltos (nonce, balance, codehash, Storagehash), construya el objeto de la cuenta, realice la operación de hash después de la codificación RLP y el valor obtenido se puede combinar con la prueba de cuenta para verificar con el valor raíz del árbol de Merkel del estado mundial almacenado en la cabeza del bloque; después de que se pasa la verificación, es equivalente a confirmar la corrección del campo de almacenamiento de información y luego combinarlo con la secuencia de Merkel en prueba de almacenamiento para completar la verificación del valor del estado. Los códigos de ejemplo de verificación relevantes son los siguientes:
4, esquema de verificación del estado mundial Ultrain
Ethereum usa el árbol MPT (Merkle patrica trie) para administrar todos los objetos de la cuenta. Statetrie almacena información de todas las cuentas, como el saldo, el número de transacciones iniciadas, la matriz de instrucciones de la máquina virtual, etc. con la ejecución de cada transacción, statetrie De hecho, ha estado cambiando. Después de completar todas las transacciones en el bloque, el estado en tiempo real de toda la información de la cuenta se registrará en el encabezado del bloque.
Ultrain usa chainbase para almacenar toda la información del estado mundial, y la ejecución de transacciones intrabloque actualizará el valor del estado de los objetos relacionados en chainbase, por lo que la información en tiempo real del estado mundial se almacena en chainbase. Cuando el cliente consulta la información en la base de la cadena a través de la interfaz de obtención de registros de la tabla, realmente confía en el proveedor de la interfaz para confiar en la exactitud de los datos que proporciona; Además, la interfaz solo puede proporcionar información de estado en tiempo real y no puede consultar el valor de estado alto del bloque especificado. El esquema de verificación de estado del mundo ultrain puede especificar la información de estado de consulta de bloque alto y proporcionar la información de ruta de Merkel requerida para la verificación de información de estado, a fin de eliminar la dependencia de confianza en el proveedor de interfaz.
En el esquema de verificación del estado mundial ultrain, cada nodo minero serializa todos los cambios realizados en el estado mundial por todas las transacciones en el bloque (es decir, los cambios en los datos almacenados en la base de la cadena) al final de la ejecución de la transacción en bloque, y organiza ellos en los nodos de hoja del árbol de Merck en un cierto orden, y luego calcula el valor de la raíz de Merck del cambio de estado mundial del bloque capa por capa. El valor de la raíz de Merkel calculado se guarda en la memoria. Cuando la altura del bloque alcanza un cierto intervalo (por ejemplo, cada 100 bloques), haga otro cálculo numérico de la raíz de Merkel para el cambio de estado mundial de todos los bloques en el intervalo y escriba el resultado (llamado valor de raíz de Merkel acumulativo del cambio de estado mundial) y la altura del bloque de cada bloque en el intervalo y el valor raíz correspondiente de Merkel en el sistema de archivos. Para evitar que el rendimiento del hilo principal se vea afectado, esta parte de la lógica se completa con un hilo separado. Todos los nodos mineros escribirán el valor acumulado de raíz de Merkel del cambio de estado mundial en el contrato del sistema a través de la transacción en cadena, y el valor entrará en vigencia solo cuando más de 2/3 mineros reporten el mismo valor raíz de Merkel.
Para proporcionar la función de consulta de la verificación del estado mundial, es necesario establecer los nodos que proporcionan el servicio de consulta del estado mundial. Seleccione un nodo no minero (es decir, un nodo que solo recibe transacciones y bloques y no participa en el proceso de consenso) y almacene todos los cambios en el estado mundial en cada bloque en el sistema de archivos después de la finalización de la ejecución de la transacción, y responder a la solicitud de datos del nodo de consulta de verificación y enviar los datos de cambio de estado al nodo de consulta para su almacenamiento. El nodo de consulta usa rocksdb para almacenar la modificación de cada bloque en el estado mundial, incluido el número de bloque, la secuencia y el contenido de modificación (el contenido de estado específico modificado); Al almacenar cada bloque de datos, el nodo de consulta, similar al nodo minero, calcula el valor de Merkel del cambio de estado mundial correspondiente de cada bloque y almacena el valor en Rocksdb. Además, el nodo de consulta proporciona una interfaz de consulta para que el nodo ligero responda a su solicitud de consulta.
Cuando un nodo ligero consulta y verifica un estado mundial específico, debe seguir los siguientes tres pasos:
1） Primero, la interfaz de obtención de filas de la tabla se utiliza para consultar los valores de estado mundiales específicos. La interfaz necesita ingresar la información de la tabla de datos (código, alcance, tabla) donde se debe consultar el estado mundial y la información de la altura del bloque
Los datos devueltos incluyen la información específica del estado (como el saldo de la cuenta del campo de datos en el ejemplo) y los bytes binarios correspondientes a la información (campo sin procesar en el ejemplo, que también puede generar el nodo de luz de acuerdo con el archivo ABI del contrato); Además, la interfaz devolverá el bloque ﹐ num y la información de secuencia correspondiente a la modificación del estado mundial.
2) De acuerdo con la altura del bloque y la información del número de secuencia devuelta por la interfaz de obtención de filas de la tabla, obtenga la información de secuencia correspondiente del árbol de Merkel requerida para verificar el estado. El nodo de luz llama a la siguiente interfaz:
El campo de rutas devuelto por esta interfaz es la información de la secuencia del árbol de Merkel:
3) De acuerdo con los datos brutos devueltos de la fila de la tabla get y los datos de las rutas devueltas de la prueba de la fila de la tabla get, el nodo ligero puede llamar a la siguiente interfaz para calcular el valor raíz del árbol de Merkel (el nodo claro también puede implementar su propia lógica de cálculo Raíz de Merkel de acuerdo con los datos en bruto y rutas):
La interfaz devuelve el valor raíz calculado de Merkel, que el nodo minero puede comparar con el valor correspondiente escrito en el contrato del sistema mediante la transacción. El mismo valor significa que se pasa la verificación (en este ejemplo, la altura del bloque con el cambio de estado mundial es 34186, si el intervalo de bloque seleccionado por el nodo minero es 100, la raíz de Merkel correspondiente a la altura del bloque de 34200 debería leerse del contrato del sistema Comparación de valores).
En resumen, el proceso de interacción entre nodos ligeros y nodos de servicio de consulta se muestra en la siguiente figura:
El esquema SPV de bitcoin, el esquema de verificación de estado de Ethereum y el esquema de verificación de estado de Ultrain se describen en este documento. Podemos ver que el nodo de luz no necesita resincronizar una gran cantidad de datos para verificar que la transacción realmente ocurrió y para verificar el valor específico del estado mundial en un momento determinado. Por lo tanto, los recursos de almacenamiento y computación requeridos por el nodo de luz se reducen considerablemente. La ejecución de nodos de luz en dispositivos, como dispositivos de Internet de las cosas, se da cuenta de la combinación de Internet de las cosas y la tecnología , lo que permite más escenarios comerciales.
