¿Puede DFINITY, que se especializa en tecnologías subyacentes, imaginar que la Web3 se haga realidad realmente?

Recomendado: El mercado es alcista y bajista y se encuentra con la situación en Ucrania, haga clic aquí para unirse al grupo PANews para calentar motores

Título original: Interpretación del nuevo libro blanco de DFINITY, la cadena pública de acciones potenciales ¿Cuál es la tecnología subyacente en la era de la conexión de la Web 3.0?

Autor: TinTinLand

1

Conducir

A principios de febrero de 2022, Dmail, la primera DApp de correo electrónico privado desarrollada en base al ecosistema DFINITY, recibió una inversión estratégica de Amino Capital. Se informa que Dmail puede enviar correos electrónicos hacia y desde buzones tradicionales, y en comparación con los buzones tradicionales, Dmail con atributos de blockchain también puede realizar la transmisión cifrada de información y NFT de nombres de buzones. Se trata de una preparación para el software de comunicación en la era de la Web 3.0, que sirve de entrada a los sitios web descentralizados y a las DApps en forma de “identidad digital”. La pregunta que quiero hacer es, ¿por qué Dmail eligió Dfinity?

En comparación con las cadenas públicas de la cadena de bloques, Dfinity no ha surgido muchas veces. No hubo fuego DeFi cuando hubo una pequeña chispa, y no hubo ganas de un asiento en el primer año de “NFT”. Sin embargo, desde su lanzamiento, no es raro que personas como Dmail tengan una idea de cómo será la implementación específica de la Web 3.0.

DFINITY lanzó la versión de código abierto del software social de videos cortos “CanCan” en julio de 2020, que simplemente podemos comparar con Douyin de la Web 2.0. CanCan se basa en el lenguaje de programación de DFINITY, Motoko, y tiene menos de 1.000 líneas de código. Esto puede llamarse asombroso en comparación con las decenas de millones de líneas de código en Douyin y Facebook. Al mismo tiempo, el código de CanCan es de código abierto y la propiedad del producto no pertenece a ninguna autoridad centralizada. El 1 de octubre del mismo año, DFINITY dio a conocer su sistema de gobernanza y modelo económico de tokens, y la valoración del proyecto llegó a alcanzar los 9.500 millones de dólares, situándose entre los cinco primeros. A finales de diciembre del mismo año, se completó la evolución histórica de las cinco redes de cobre a mercurio. Dominic Williams, fundador y científico jefe de la Fundación DFINITY, dijo en el “Foro y Ceremonia de Premios de la Cumbre de la Era del Valor FAT 2020” que la computadora de Internet es la tercera gran innovación de blockchain.

Este artículo interpretará el texto original del libro blanco de DFINITY, partiendo de la lógica más baja de la explicación oficial, para ver cómo DFINITY puede partir de la tecnología, romper la gran tecnología de Internet y permitir que varios programas de la Web2.0 utilicen software autónomo y gobernanza descentralizada para lograr la sinergia de los negocios de código abierto, a fin de realizar realmente la Web3.0; Los lectores sin experiencia en la industria de la cadena de bloques pueden tener un umbral de lectura al leer este artículo, pero también son bienvenidos a comentar las preguntas que surgen a continuación, y pueden obtener respuestas inesperadas.

2

Contorno

A lo largo de la historia y el proceso actual de blockchain, BTC ha traído la era del dinero descentralizado, ETH representa el campo de los sistemas operativos, Filecoin representa el almacenamiento y DFINITY representa la innovación del campo informático y la implementación de la Web 3.0. Internet Computer (en lo sucesivo, IC) es la red principal, es un protocolo de capa 1, con el objetivo de desarrollar una red pública descentralizada, DFINITY es una computadora y tecnología de cadena de bloques virtual abierta, que extiende el ecosistema Ethereum a una amplia gama de escenarios de aplicaciones comerciales. En este artículo, usaremos el término oficial “Internet Computer” en el libro blanco para referirnos a la cadena “DFINITY” que se usa comúnmente en el escenario de comunicación actual. Esta sección explica principalmente los términos técnicos involucrados en algunos circuitos integrados, así como las diferencias en tecnología e implementación en comparación con otras cadenas públicas, o los puntos brillantes en tecnología y función. Se puede decir que IC es un nuevo intento de combinación de escalabilidad, descentralización y seguridad.

2.1 Protocolo de consenso

Al observar IC y varias otras cadenas públicas importantes desde la perspectiva de los protocolos de consenso, IC adopta un modelo híbrido de red controlado por DAO, que proporciona muchos de los beneficios de un protocolo PoS descentralizado al tiempo que tiene la eficiencia de un protocolo autorizado. Los protocolos de consenso de Bitcoin, Ethereum y Algorand están basados en blockchain, utilizando Proof of Work (PoW) o Proof of Stake (POS). Aunque estos protocolos están totalmente descentralizados, son menos eficientes que los protocolos autorizados.

Las DAO operan mediante un protocolo de consenso autorizado para cada subred, y una DAO decide qué entidades pueden proporcionar copias de los nodos, configura la red, proporciona una infraestructura de clave pública y controla la versión del protocolo en la que se implementan las copias de los nodos. La DAO de IC se llama Network Nervous System (NNS) y se basa en el protocolo Pos, es decir, las decisiones relevantes son decididas por los miembros de la comunidad, y el poder de voto de los miembros de la comunidad está determinado por el número de tokens de gobernanza nativos (ICP) de IC que apuestan en NNS. Este mecanismo de gobernanza basado en PoS le permite crear nuevas subredes y agregar o eliminar réplicas de nodos de los existentes, así como implementar actualizaciones de software y realizar otros ajustes en el CI.

Desde esta perspectiva, también podemos entender por qué DFINITY llama a IC una red de máquinas de estado replicadas, porque NNS en sí mismo es una máquina de estado replicada. Al igual que otras máquinas estatales, se ejecutan en una subred específica y su pertenencia está determinada por el mismo sistema de gobernanza basado en PoS mencionado anteriormente. Al mismo tiempo, se mantiene una base de datos denominada registro, que registra qué réplicas de nodos pertenecen a qué subred, las claves públicas de las réplicas de nodos, etc. Por lo tanto, la red de control de la DAO sirve como un protocolo de consenso descentralizado, lo que permite al CI obtener un consenso efectivo, pero al mismo tiempo, debido al mecanismo de funcionamiento de la DAO, el CI también conserva las ventajas existentes de la descentralización.

El protocolo de consenso del CI también utiliza criptografía de clave pública, como el registro mantenido por NNS para vincular la clave pública a la réplica del nodo y la subred para formar un todo, lo que se denomina criptografía de clave en cadena, y el CI también prevé el modelo de comunicación para el protocolo de consenso y el protocolo que ejecuta la máquina de estado de replicación: espera adoptar un modelo asíncrono más factible y robusto (para cualquier mensaje enviado, el adversario puede retrasar la entrega de cualquier mensaje durante un tiempo arbitrario, por lo que no hay límite de tiempo para la entrega del mensaje) para hacer frente a los fallos bizantinos. Sin embargo, en la actualidad, no existe un modelo de consenso conocido que sea realmente factible bajo el modelo asíncrono, y en la siguiente interpretación de la arquitectura de CI, este artículo explicará con más detalle el enfoque técnico de CI para esta situación del mundo real.

2.2 Criptografía de clave de cadena

Como se mencionó anteriormente, el protocolo de consenso de IC también utiliza criptografía de clave pública: criptografía de clave en cadena, y hay varias partes principales que componen la criptografía de clave en cadena. El primer componente de la criptografía de clave de cadena es la firma de umbral: la firma de umbral es una técnica criptográfica madura que permite que una subred tenga una clave de firma de verificación común, y la clave privada de firma correspondiente se divide en varias copias y se distribuye a los nodos de la subred, mientras que la asignación garantiza que el nodo defectuoso no puede falsificar ninguna firma, y el fragmento de clave privada propiedad del nodo honesto permite que la subred genere firmas que se ajusten a los principios y protocolos de IC.

Una aplicación clave de estas firmas de umbral es que la salida individual de una subred puede ser verificada por otra subred o por un usuario externo, y la verificación se puede realizar simplemente verificando la implementación de la firma electrónica mediante la clave de firma de verificación pública de la subred modificada (la primera subred).

Como podemos ver, hay muchas otras aplicaciones de estas firmas de umbral en el CI. Se debe usar uno para hacer que cada copia de un nodo en una subred sea accesible a dígitos pseudoaleatorios impredecibles (derivados de dichas firmas de umbral). Esta es la base de las balizas aleatorias utilizadas por la capa de consenso y las cintas aleatorias utilizadas por la capa de ejecución.

Para implementar de forma segura las firmas de umbral, el IC emplea un innovador protocolo de generación de claves distribuidas (DKG) para construir una clave de verificación de firma pública y proporcionar a cada réplica de nodo un fragmento de la clave privada de firma correspondiente para los modelos asíncronos y de falla bizantino mencionados anteriormente.

2.3 ICP

ICP tiene las siguientes características:

Staking de NNS, es decir, facilitar la gobernanza de la red.

ICP se puede utilizar para hacer staking en NNS para obtener derechos de voto y así participar en la DAO que controla la red IC. Los usuarios que hacen staking de tokens en NNS y participan en la gobernanza de NNS también reciben tokens ICP recién acuñados como recompensas de votación. El número de recompensas está determinado por las políticas establecidas y aplicadas por NNS.

Canjear ciclos, es decir, como poder de producción.

El ICP se utiliza para pagar el uso del IC. Más específicamente, ICP se puede canjear por ciclos (es decir, quemado), que se puede usar para pagar los recursos (almacenamiento, CPU y ancho de banda) utilizados para crear tanques y tanques. La relación entre la PIC y el ciclo está determinada por NNS.

Los proveedores de nodos son pagados, es decir, se entregan como recompensa a los participantes.

ICP se utiliza para pagar a los proveedores de nodos, entidades que poseen y operan nodos de proceso para alojar las copias de los nodos que componen el IC. NNS determina regularmente (actualmente mensualmente) el ICP recién acuñado que cada proveedor de nodos debe recibir y lo libera en su cuenta. De acuerdo con las políticas establecidas y aplicadas por NNS, el pago de ICP se basa en que el proveedor del nodo proporcione servicios confiables al IC.

2.4 Ejecución de NNS

Como se mencionó anteriormente, la máquina de estado de replicación del CI puede ejecutar programas arbitrarios. La unidad de cómputo básica en un CI se llama tanque, y es el mismo concepto que un proceso, que contiene el programa y su estado (que cambia con el tiempo). El programa del tanque está codificado en WebAssembly (en lo sucesivo, Wasm), que es un formato de instrucción de dos mecanismos basado en una máquina virtual apilada. Wasm es un estándar de código abierto y, aunque fue diseñado originalmente para permitir aplicaciones de alto rendimiento en la web, también es adecuado para la informática de propósito general.

El IC proporciona un entorno de ejecución para ejecutar programas Wasm dentro del tanque y comunicarse (a través de mensajería) con otros tanques y usuarios externos. Si bien en principio es posible escribir un programa de tanque en cualquier lenguaje que compile a Wasm, el lenguaje antes mencionado llamado Motoko es muy consistente con la semántica de las operaciones de CI y se puede usar en CI.

Motoko es un programa de programación basado en actor-2 con soporte integrado para persistencia ortogonal 3 y mensajería asíncrona. La persistencia en cuadratura significa que la memoria mantenida por el tanque se conserva automáticamente (es decir, no tiene que escribirse en un archivo). Motoko tiene una serie de características de productividad y seguridad, que incluyen administración automática de memoria, genéricos, inferencia de tipos, coincidencia de patrones y aritmética arbitraria y de precisión fija.

Además de Motoko, el IC proporciona un lenguaje de definición de interfaz de mensajes y un formato de datos llamado Candid, que se utiliza para la interoperabilidad de tipo fijo, lenguaje de alto nivel y entre idiomas. Esto facilita que dos tanques cualesquiera, incluso si están escritos en diferentes lenguajes de alto nivel, se comuniquen entre sí. Con el fin de proporcionar soporte completo para el desarrollo de tanques para cualquier lenguaje de programación dado, se debe proporcionar soporte de tiempo de ejecución específico además del compilador Wasm para ese lenguaje. Actualmente, además de Motoko, el IC también es totalmente compatible con el desarrollo de tanques en el lenguaje de programación Rust.

Como resultado, los circuitos integrados admiten lenguajes de programación más seguros y entre lenguajes, que es uno de los factores importantes que hacen que los desarrolladores sean más eficaces y seguros en la creación de circuitos integrados.

2.5 Decisiones NNS

En la red blockchain DFINITY, BNS (Blockchain Nervous System) es el sistema de gobernanza en el que opera la red, y es uno de los bloques de construcción más importantes en la red blockchain, que puede ingresar automáticamente al sistema y tener una alta autoridad. Asume el papel de un supernodo. Cualquiera participa en la gobernanza de NNS apostando ICP en las llamadas neuronas. Los titulares de neuronas pueden proponer y votar sobre cómo se debe cambiar el CI, como la topología de la subred o el protocolo. Los derechos de voto de las neuronas se basan en PoS. Intuitivamente, cuanto más se apuesta por el ICP, mayores son los derechos de voto neuronales. Sin embargo, el poder de voto también depende de otras características de las neuronas, como que los titulares de neuronas que están dispuestos a apostar sus tokens durante un período de tiempo más largo, tengan un mayor poder de voto.

Cada propuesta tiene un período de votación definido. Si, al final del período de votación, la mayoría simple de los votantes a favor de la propuesta y el número de votos a favor supera el requisito de quórum establecido para el total de derechos de voto (actualmente 3%), se adopta la propuesta. Por lo demás, la propuesta fue rechazada. Además, en cualquier momento en que una mayoría calificada (más de la mitad del total de votos) esté a favor o en contra de la propuesta, la propuesta será aceptada o rechazada en consecuencia.

En términos más sencillos, el proceso de gobernanza del BNS se divide en cuatro fases: creación de neuronas, propuesta, votación y ejecución.

Crear neuronas: Como se mencionó anteriormente, el Neurosistema blockchain permite a los usuarios usar ICP para crear neuronas de votación. Cualquiera puede crear una neurona, y en el futuro se pueden crear decenas de miles de neuronas, que expresarán colectivamente la voluntad de la comunidad, mediada por algoritmos.

Propuestas: Cualquier usuario que ejecute neuronas puede hacer una propuesta en BNS, y BNS revisará la propuesta en función de la razonabilidad de la propuesta y de si proporciona una solución. El usuario que realiza la propuesta debe pagar dos tarifas: una es pagar a los revisores profesionales y a las neuronas que participaron en la votación, y la otra es el depósito de la propuesta, que se devolverá a la neurona después de que se adopte la propuesta, y esta cantidad se puede establecer para incentivar propuestas de alta calidad.

Votación: Además del proponente, otros usuarios también necesitan hacer staking de tokens a las neuronas durante la fase de votación y poder elegir votar activamente o seguir la votación. Los usuarios con capacidad de juicio independiente pueden optar por votar activamente, y el escenario de la votación posterior es adecuado para algunos usuarios que no pueden juzgar con precisión las propuestas. Una vez cerrado el tiempo de votación, BNS recopila los resultados de la red neuronal y determina automáticamente si la propuesta se aprueba o no.

Implementación: Justo ahora hay una interpretación del consenso de CI de la capa de ejecución, ¿cuál es la implementación específica de la implementación del sistema de gobernanza BNS? LA PROPUESTA DE EJECUCIÓN PASIVA IMPLICA PRINCIPALMENTE CAMBIOS EN LOS PARÁMETROS DE LOS CONTRATOS INTELIGENTES EN DFINITY, COMO LOS PARÁMETROS DE STAKING DE LAS NEURONAS. Los parámetros actualizados de la propuesta se escribirán pasivamente en la base de datos de contratos inteligentes de BNS y entrarán en vigor directamente cuando se ejecuten más adelante. Hay un caso especial en el que la propuesta está fuera del control del contrato inteligente de BNS, por ejemplo, en lo que respecta al nivel regulatorio de BNS, que requerirá una aplicación activa humana para anular la parte de “el código es ley” de DFINITY. Por ejemplo, modificando vulnerabilidades en el código del sistema o congelando contratos inteligentes o neuronas que violen las regulaciones de BNS. El proceso de ejecución activa se implementa invocando códigos de operación especiales agregados a la EVM. El funcionamiento de este paso es más humano y razonable, en lugar del actual “el código es ley” y “el código lo es todo” en el mundo actual de la cadena de bloques. Desde la perspectiva de la naturaleza humana, cubrir escenarios en los que el código no puede tomar decisiones puede aportar una gobernanza más eficaz e inteligente y, hasta cierto punto, también afecta realmente a la intención subyacente del “consenso”.

3

Interpretación de la Arquitectura

El protocolo IC consta de cuatro capas (como se muestra en la figura siguiente), a saber, la capa P2P, la capa de consenso, la capa de enrutamiento y la capa de ejecución. En esta parte, este artículo solo interpreta los roles y funciones de la arquitectura de cuatro capas, y analiza la construcción de la arquitectura general. PARA OBTENER UNA COMPRENSIÓN MÁS DETALLADA DE LA IMPLEMENTACIÓN TÉCNICA ESPECÍFICA DE UNA CAPA EN PARTICULAR, CONSULTE EL DOCUMENTO TÉCNICO ORIGINAL DE DFINITY.

Capa P2P 3.1

La capa P2P sirve como capa en la capa de protocolo informático de Internet para la obtención y el orden de mensajes, y su tarea es entregar mensajes de protocolo en una copia de los nodos de la subred.

Hay dos tipos de mensajes de protocolo: los mensajes utilizados para lograr el consenso y los mensajes de entrada iniciados por usuarios externos.

Podemos entender que la capa P2P básicamente proporciona un canal de difusión de “mejor esfuerzo”, es decir, si una copia de nodo honesta transmite un mensaje, el mensaje eventualmente será recibido por todos los nodos de la ciudad en la subred.

La capa P2P está diseñada con los siguientes objetivos:

Recursos limitados. Todos los algoritmos se ejecutan con recursos limitados (memoria, ancho de banda, CPU).

Prioridad. Dependiendo de atributos específicos, como el tipo, el tamaño y el turno, los diferentes mensajes se ordenarán con diferentes prioridades. Y las reglas para estas prioridades pueden cambiar con el tiempo.

Altamente eficiente. El alto rendimiento es más importante que la baja latencia. EL ALTO RENDIMIENTO ES TAMBIÉN LA RAZÓN POR LA QUE DFINITY ES MÁS EFICIENTE DESDE ABAJO QUE OTRAS CADENAS PÚBLICAS.

Anti-DOS/SPAM. Los nodos con errores no afectarán a la comunicación entre réplicas de nodos honestos.

3.2 Capa de consenso

3.2.1 Descripción general de la capa de consenso

La tarea de la capa de consenso de IC es ordenar los mensajes de entrada para asegurarse de que todas las réplicas de los nodos procesan los mensajes de entrada en el mismo orden. Existen muchos protocolos en la literatura que abordan este tema. IC adopta un nuevo protocolo de consenso, que se describirá en lenguaje general en este artículo. Cualquier protocolo de consenso seguro debe garantizar dos atributos, que son más o menos eso:

Seguridad: Todas las réplicas de nodos de facto aceptan el mismo orden de entradas.

Activo: todas las réplicas de nodo deben actualizar su estado una por una.

El objetivo de diseño de la capa de consenso de IC es realmente fácil de entender: cuando hay nodos maliciosos individuales, el rendimiento se degradará de manera flexible. Al igual que muchos protocolos de consenso, el protocolo de consenso IC se basa en blockchain. A medida que avanza el protocolo, el árbol de bloques con el bloque génesis como nodo raíz seguirá creciendo. Cada bloque que no es génesis contiene una carga útil, que consta de una serie de entradas y el hash del bloque principal.

Las réplicas honestas tienen una vista coherente del árbol de fragmentos: aunque cada réplica puede tener una vista local diferente del árbol de fragmentos, todas las réplicas del nodo ven el mismo árbol de fragmentos. Además, a medida que avanza el protocolo, siempre habrá una ruta en el árbol de bloques para finalizar el bloque. De nuevo, las réplicas de nodo honestas tienen una vista coherente de esta ruta de acceso: aunque cada réplica de nodo puede tener una vista local diferente de la ruta de acceso, todas las réplicas de nodo ven la misma ruta de acceso. Las entradas en la carga de los bloques a lo largo de esta ruta son las entradas ordenadas que serán procesadas por la capa de ejecución del CI.

El protocolo de consenso se basa en firmas electrónicas para verificar los mensajes en una copia de un nodo. Para lograr esto, cada copia del nodo se asocia con una clave de autenticación pública para el protocolo de firma. La correlación entre la réplica del nodo y la clave pública se puede obtener del registro mantenido por NNS. Esto también está en línea con el papel y el papel de la criptografía de clave de cadena en los circuitos integrados mencionados anteriormente.

3.2.2 Supuestos

Como se discutió en la Parte II, el CI propone la siguiente hipótesis:

Una subred contiene n réplicas de nodos y un máximo de f

Las réplicas de nodos con errores pueden mostrar un comportamiento arbitrario y malintencionado (es decir, un error bizantino). Suponemos que la comunicación es asincrónica y que no hay ninguna limitación previa en la latencia de los mensajes entre las réplicas de nodos, es decir, el modelo asincrónico mencionado anteriormente. En este punto, la programación de los mensajes puede ser completamente hostil. Bajo esta suposición de comunicación débil, el protocolo de consenso IC puede garantizar la seguridad. Pero para garantizar la actividad, debemos asumir una cierta forma de sincronización parcial, lo que significa que la red permanece sincronizada periódicamente a intervalos cortos. En este intervalo de sincronización, toda la información no presentada se presentará dentro del tiempo, es decir, un límite de tiempo fijo δ. El límite de tiempo δ no se conoce de antemano (el protocolo inicializa un valor límite razonable, pero ajusta dinámicamente el valor y aumenta el valor límite cuando el límite de tiempo es demasiado pequeño). Independientemente de si la red es asincrónica o parcialmente sincrónica, se supone que los mensajes enviados por una réplica de nodo honesta a otra réplica de nodo se entregarán finalmente.

3.2.3 Descripción general del protocolo

Al igual que muchos protocolos de consenso, el protocolo de consenso IC se basa en blockchain. A medida que avanza el protocolo, los árboles de bloques (ver 3.2.4 por ejemplo) con el bloque génesis como nodo raíz continuarán creciendo. Cada bloque que no es génesis contiene una carga útil, que consta de una serie de entradas y el hash del bloque principal. Las réplicas honestas tienen una vista coherente del árbol de fragmentos: aunque cada réplica puede tener una vista local diferente del árbol de fragmentos, todas las réplicas del nodo ven el mismo árbol de fragmentos. Además, a medida que avanza el protocolo, siempre habrá una ruta en el árbol de bloques para finalizar el bloque. Del mismo modo, las réplicas de nodo honestas tienen una vista coherente de esta ruta de acceso y, aunque cada réplica de nodo puede tener una vista local diferente de la ruta de acceso, todas las réplicas de nodo ven la misma ruta de acceso. Las entradas en las cargas de los bloques a lo largo de este camino han sido ordenadas y procesadas por la capa de ejecución, que se interpreta en el apartado anterior.

3.2.4 Ejemplo práctico

La siguiente imagen muestra un árbol de bloques. Cada bloque está marcado con una altura de bloque (30, 31, 32, ··· ) y la clasificación de los generadores de bloques, que muestra que cada bloque del árbol de bloques está notariado y marcado con el símbolo N. Esto significa que los bloques notarizados en cada árbol de bloques están respaldados por la notarización de al menos n-f copias de diferentes nodos. Se puede encontrar que puede haber más de un bloque notariado a la altura de bloque especificada. Por ejemplo, a la altura del bloque 32, podemos ver 2 bloques notariados, uno propuesto por el generador de bloques en el rango 1 y el otro propuesto por el rango 2, y lo mismo sucede en la altura del bloque 34. También podemos ver que los bloques con una altura de 36 también se confirman explícitamente, como se identifica con el símbolo F. Esto significa que n-f copias de diferentes nodos han soportado la confirmación final del bloque, lo que significa que estas copias de nodo (o al menos las copias de nodo honestas de estos) no soportan la notarización de ningún otro bloque. Se considera que todos los antepasados cuyo bloque está lleno de gris han recibido la confirmación final implícita.

**3.2.5 Imparcialidad **

La equidad es la base del consenso, por lo que otro atributo importante en los protocolos de consenso es la equidad. En lugar de establecer una definición universal, simplemente observamos que la invariancia de la vida implica una propiedad de equidad útil. Para recapitular, la invariancia significa esencialmente que en cualquier ronda, cuando el masternode es honesto y la red está sincronizada, el bloque propuesto por el masternode también se finalizará. En el turno en el que esto sucede, el nodo maestro honesto se asegura de que contiene todas las entradas que conoce en la carga del bloque (dependiendo de los límites del módulo del tamaño de la carga). Por lo tanto, a grandes rasgos, lo más probable es que cualquier entrada que se propague a un número suficiente de copias de nodo se incluya en el bloque final confirmado dentro de un período de tiempo razonable.

3.3 Capa de enrutamiento

Como se mencionó anteriormente, la unidad de cómputo básica en el CI se llama tanque. El IC proporciona el entorno operativo en el que los programas se pueden ejecutar en el tanque y pueden comunicarse (a través de mensajes) con otros tanques y usuarios externos. La capa de consenso empaqueta la entrada en la carga del bloque y, a medida que el bloque es confirmado por el reddest, la carga correspondiente se pasa a la capa de enrutamiento de mensajes y es procesada por el entorno de ejecución. A continuación, la capa de ejecución actualiza el estado en el tanque correspondiente de la máquina de estado de replicación y entrega la salida a la capa de enrutamiento de mensajes para su procesamiento.

Es necesario distinguir entre dos tipos de entradas:

Mensaje de entrada: Un mensaje de un usuario externo.

Mensajes entre subredes: mensajes de tanques de otras subredes.

También podemos distinguir entre dos tipos de salida:

Respuesta del mensaje de entrada: la respuesta al mensaje de entrada (que pueden recuperar los usuarios externos).

Mensajes entre subredes: mensajes que se transmiten a otros tanques de subred.

Cuando se reciben cargas de consenso, las entradas de esas cargas se colocan en diferentes colas de entrada. Para cada tanque C bajo una subred, hay varias colas de entrada: un mensaje de entrada a C, un tanque separado C’ para comunicarse con C y un mensaje entre subredes de C a C’.

En cada ronda, la capa de ejecución consume algunas de las entradas de estas colas, actualiza el estado de replicación en el tanque correspondiente y coloca las salidas en una cola diferente. Para cada tanque bajo una subred, hay varias colas de salida: para cada tanque con el que se comunica, hay una cola para mensajes entre subredes de C a C’. La capa de enrutamiento del mensaje toma los mensajes de la cola de mensajes y los coloca en el tráfico de subred a subred para que los procese el protocolo de transporte entre subredes, que realmente transmite los mensajes a otras subredes.

Además de estas colas de salida, también hay una estructura de datos históricos para los mensajes de entrada. Una vez que un mensaje de entrada ha sido procesado por el tanque, la respuesta a ese mensaje de entrada se registra en esa estructura de datos. En este punto, el usuario externo que proporcionó el mensaje de entrada podrá obtener la respuesta correspondiente. (Nota: El historial de entrada no mantiene un historial completo de todos los mensajes de entrada).

Hay dos puntos que deben aclararse, primero, el estado de la réplica del nodo incluye el estado del tanque, así como el “estado del sistema”. “Estado del sistema” incluye las colas, los flujos de datos y las estructuras de datos del historial de entrada mencionado anteriormente. Como resultado, tanto la capa de enrutamiento de mensajes como la capa de ejecución participan en la actualización y el mantenimiento del estado de réplica de la subred. Todo este estado debe actualizarse con un determinismo completo, de modo que todos los nodos mantengan exactamente el mismo estado.

El segundo punto a tener en cuenta es que la capa de consenso precede a la capa de enrutamiento de mensajes y a la capa de ejecución, lo que significa que cualquier bifurcación en la cadena de bloques de consenso ya se ha resuelto antes de que se pase la carga. De hecho, la capa de consenso permite un funcionamiento temprano y no necesita estar en la misma programación que la capa de enrutamiento de mensajes.

La explicación y explicación de la capa de enrutamiento nos da una comprensión más clara de cómo se transmite el protocolo de consenso hacia y desde el protocolo de consenso a través del enrutamiento de mensajes, y cómo se conecta a la capa de ejecución, a fin de promover la coordinación y consistencia del protocolo de consenso.

3.4 Capa de ejecución

El entorno de ejecución procesa una entrada a la vez, que se toma de una de las colas de entrada y se dirige a un tanque, dependiendo del estado de la entrada y del tanque, el entorno de ejecución actualiza el estado del tanque y adicionalmente puede agregar mensajes a la cola de salida. y actualice el historial de entrada (posiblemente junto con la respuesta al mensaje de entrada anterior). En un turno determinado, el entorno de ejecución procesará varias entradas. El programador determina qué entradas se ejecutarán en qué orden para un turno determinado. En lugar de entrar en demasiados detalles sobre el programador, destacaremos algunos de los objetivos:

Debe ser determinista, es decir, depender únicamente de los datos dados;

Debe distribuir la carga de trabajo de manera justa entre los tanques (pero optimizarse para el rendimiento en lugar de la latencia).

El número de trabajos completados en cada ronda se mide en ciclos y debe estar cerca de una cantidad predeterminada.

Otra tarea con la que debe lidiar el entorno de ejecución es la situación en la que uno de los tanques de una subred produce mensajes a través de las subredes más rápido de lo que pueden consumir las otras subredes. En respuesta a esta situación, implementamos un mecanismo de autorregulación para ralentizar el tanque de producción. Hay muchas otras tareas de administración de recursos y contabilidad que deben ser controladas por el entorno de tiempo de ejecución, pero todas estas tareas deben controlarse de forma determinista.

4

Criptografía de clave de cadena

En la sinopsis, explicamos que el protocolo de consenso del CI también utiliza la técnica de criptografía de clave pública: criptografía de clave de cadena, y una parte importante de la criptografía de clave de cadena es la firma de umbral. De hecho, la criptografía de clave de cadena abarca un complejo conjunto de técnicas utilizadas para mantener de forma robusta y segura las máquinas de estado de replicación basadas en blockchain a lo largo del tiempo, conocidas colectivamente como técnicas de evolución de la cadena. Cada subred opera dentro de épocas que contienen varias rondas (normalmente unos pocos cientos). La tecnología de evolución de la cadena permite muchas de las tareas básicas de mantenimiento que se realizan por época: recolección de elementos no utilizados, reenvío rápido, cambios de miembros de subred, reenvío secreto activo y actualizaciones de protocolos.

La comprensión de la tecnología de evolución de la cadena, es decir, la comprensión de la implementación técnica de la seguridad del protocolo de consenso IC. La tecnología de evolución de la cadena consta de dos componentes básicos: bloques de resumen y paquetes de puesta al día (CUP).

4.1 Bloque de resumen

El primer bloque de cada época es el bloque de resumen. El bloque de resumen contiene datos especiales que se utilizan para administrar fragmentos de clave para diferentes esquemas de firma de umbral. Hay dos esquemas de firma de umbral:

En un escenario con una estructura de umbral de f + 1/n, se genera una nueva clave de firma para cada época;

En un escenario con una estructura de umbral de n-f/n, la clave de firma se vuelve a compartir una vez por época.

Los escenarios con umbrales bajos se utilizan para balizas aleatorias y cintas aleatorias, mientras que los escenarios con umbrales altos se utilizan para comprobar el estado de replicación de la subred. Recuerde que el protocolo DKG requiere que para cada clave de firma, haya un conjunto de transacciones y que cada réplica de nodo pueda obtener su fragmento de clave de firma de forma no interactiva en función de este conjunto de transacciones. Recuerde de nuevo, entre otras cosas, que NNS mantiene un registro que determina los miembros de la subred. El registro (y los miembros de la subred) cambian con el tiempo. Como resultado, las subredes deben acordar la versión del registro que se usará en diferentes momentos y para diferentes propósitos. Esta información también se almacena en el bloque de resumen.

4.2 CUPAS

Con el resumen fuera del camino, echemos un vistazo a los paquetes de puesta al día, o CUPs. Antes de profundizar en la CUP, primero debemos señalar un detalle de las balizas aleatorias: las balizas aleatorias de cada ronda dependen de las balizas aleatorias de la ronda anterior. No es una característica fundamental del CUP, pero influye en el diseño del CUP. Un CUP es un mensaje especial (no en la cadena de bloques) que tiene todo lo que un nodo necesita para funcionar en el punto de partida de una época sin conocer ninguna información sobre la época anterior. Contiene los siguientes campos de datos:

La raíz del árbol hash de Merkel para todo el estado replicado (a diferencia del estado parcial de cada ronda de validación en el Capítulo 1.6).

época.

Baliza aleatoria para la primera ronda de la época.

La firma de umbral de la subred para (n - f)/n para los campos anteriores.

Para generar un CUP para una época determinada, la réplica del nodo debe esperar hasta que se haya finalizado el bloque de resumen de la época y se haya verificado el estado de ronda correspondiente. Como se mencionó anteriormente, todo el estado de replicación debe procesarse en un árbol de Merkle mediante una función hash. Si bien hay muchas técnicas utilizadas para acelerar este proceso, el costo sigue siendo significativo, por lo que cada época solo se procesa una vez. Dado que el CUP contiene solo la raíz de este árbol de Merkle, usamos un subprotocolo de sincronización de estado que permite que la réplica del nodo extraiga el estado que necesite del par. Una vez más, hemos utilizado mucha tecnología para acelerar este proceso, y sigue siendo costoso. Debido a que usamos firmas de alto umbral para los CUP, podemos garantizar que solo hay un CUP válido en cualquier época y que ese estado se puede extraer de muchos pares.

4.3 Implementación de la tecnología Chain Evolution

Recolección de elementos no utilizados: dado que el CUP contiene información sobre una época determinada, cada copia del nodo puede purgar de forma segura todas las entradas procesadas antes de esa época, así como los mensajes de la capa de consenso que ordenaron esas entradas.

Avance rápido: si una réplica de un nodo de una subred se retrasa significativamente con respecto a su nodo sincrónico (porque está inactivo o desconectado durante mucho tiempo), o si se agrega una nueva réplica del nodo a la subred, pueden reenviar rápidamente al punto de partida de la última época sin tener que ejecutar el protocolo de consenso y procesar toda la entrada antes de ese punto. Esta copia del nodo se puede hacer obteniendo la última CUP. Con los bloques de resumen y las balizas aleatorias contenidas en los CUP, así como los mensajes de consenso (aún no borrados) de otras copias de nodo, la réplica del nodo puede ejecutar el protocolo de consenso desde el punto de partida de la época correspondiente. El nodo también puede utilizar el subprotocolo de sincronización de estado para obtener el estado de replicación al principio de la época correspondiente, de modo que también pueda empezar a procesar las entradas generadas por la capa de consenso.

En el diagrama siguiente se muestra el avance rápido. Aquí, supongamos que necesitamos una réplica de nodo que necesita ponerse al día en el punto de partida de la época, (digamos) con una altura de bloque de 101 y un CUP. Este CUP contiene la raíz del árbol de Merkle replicado con una altura de bloque de 101, un bloque de resumen con una altura de bloque de 101 y una baliza aleatoria con una altura de bloque de 101. El nodo utiliza el subprotocolo de sincronización de estado para obtener todo el estado de replicación de la altura de bloque 101 de sus pares y verifica este estado con el árbol de Merkle en el CUP. Después de obtener este estado, la copia del nodo puede participar en el protocolo, obtener bloques con una altura de bloque de 102, 103, etc. (y otros mensajes relacionados con el consenso) del par y actualizar la copia de su estado de replicación. Si sus pares han confirmado bloques en un nivel superior, la copia del nodo procesará (así como certificará y finalizará) aquellos bloques finalizados obtenidos de los pares tan pronto como sea posible (tan rápido como lo permita la capa de ejecución).

5

Epílogo

Al igual que Ethereum, la visión de DFINITY es construir la “supercomputadora del mundo”, a través de la mencionada interpretación parcial y explicación técnica de su libro blanco. Los CI bajo esta visión tienen una gran oportunidad de ser realizados.

Podemos ver la innovación tecnológica y la viabilidad técnica de IC para hacer realidad su visión desde el modelo híbrido DAO del protocolo de consenso, desde la innovación tecnológica de generación rápida de bloques y alto rendimiento, y desde el sistema de neuronas BNS y su esquema de gobernanza ecológica. A diferencia del código actual de Ethereum, que es ley, la gobernanza del código IC agrega elementos de sabiduría colectiva a la base, no con el objetivo de establecer una arquitectura de código perfecta, sino con el objetivo de que el sistema pueda ajustar rápidamente las reglas. No se trata solo de una creación tecnológica, sino también de una brillante naturaleza humana. En el mundo de la cadena de bloques, el establecimiento, el mantenimiento y la modificación del consenso no pueden limitarse a codificar, sino que la esencia del núcleo deben ser las personas. El consenso válido y justo entre los grupos centrados en el ser humano está en el corazón de la industria de la cadena de bloques y es el atractivo de muchas Dapps descentralizadas.

En este artículo se citan e interpretan algunos de los contenidos de las notas del producto de IC, que describen más detalles sobre NNS, el estado de autenticación de cada ronda de subredes en la capa de consenso, las llamadas de consulta y actualización de los mensajes de entrada, la distribución de claves distribuidas en criptografía de claves en cadena, los esquemas PVSS, los protocolos básicos y los protocolos de recompartición, etc. Para los desarrolladores que desean una comprensión más completa y detallada de la tecnología subyacente del CI, la lectura del documento técnico original puede proporcionar explicaciones y explicaciones más detalladas.