Este texto es una continuación de una serie de artículos en los que examino la estructura de la (presumiblemente) red distribuida Telegram Open Network (TON), que se está preparando para su lanzamiento este año. EN Describí su nivel más básico: la forma en que los nodos interactúan entre sí.
Por si acaso, permítanme recordarles que no tengo nada que ver con el desarrollo de esta red y que todo el material fue extraído de una fuente abierta (aunque no verificada). (también hay un acompañamiento , resumiendo brevemente los puntos principales), que apareció a finales del año pasado. La cantidad de información contenida en este documento, en mi opinión, indica su autenticidad, aunque no hay confirmación oficial de ello.
Hoy veremos el componente principal de TON: la cadena de bloques.
Conceptos basicos
Cuenta (cuenta). Un conjunto de datos identificados por un número de 256 bits. ID de la cuenta (la mayoría de las veces esta es la clave pública del propietario de la cuenta). En el caso base (ver más abajo cadena de trabajo cero), estos datos se refieren al saldo del usuario. "Ocupar" específico ID de la cuenta cualquiera puede hacerlo, pero su valor sólo puede cambiarse según ciertas reglas.
Contrato inteligente (contrato inteligente). En esencia, es un caso especial de una cuenta, complementada con un código de contrato inteligente y almacenamiento de sus variables. Si en el caso de una “billetera” puedes depositar y retirar dinero de ella de acuerdo con reglas relativamente simples y predeterminadas, entonces en el caso de un contrato inteligente estas reglas están escritas en la forma de su código (en cierto modo Turing completo). lenguaje de programación).
Estado de la cadena de bloques (estado de la cadena de bloques). El conjunto de estados de todas las cuentas/contratos inteligentes (en sentido abstracto, una tabla hash, donde las claves son identificadores de cuentas y los valores son los datos almacenados en las cuentas).
Mensaje (mensaje). Arriba utilicé la expresión "dinero de crédito y débito"; este es un ejemplo particular de mensaje ("transferir N gramos de la cuenta cuenta_1 a la cuenta cuenta_2"). Obviamente, sólo el nodo que posee la clave privada de la cuenta puede enviar dicho mensaje. cuenta_1 - y poder confirmarlo con una firma. El resultado de entregar dichos mensajes a una cuenta normal es un aumento en su saldo, y el resultado del contrato inteligente es la ejecución de su código (que procesará la recepción del mensaje). Por supuesto, también son posibles otros mensajes (transferir no cantidades monetarias, sino datos arbitrarios entre contratos inteligentes).
transacción (transaccional). El hecho de que se entregue un mensaje se llama transacción. Las transacciones cambian el estado de la cadena de bloques. Son las transacciones (registros de entrega de mensajes) las que forman los bloques en la cadena de bloques. En este sentido, puede pensar en el estado de la cadena de bloques como una base de datos incremental: todos los bloques son "diferencias" que deben aplicarse secuencialmente para obtener el estado actual de la base de datos. Los detalles específicos del empaquetado de estas "diferencias" (y la restauración del estado completo a partir de ellas) se analizarán en el próximo artículo.
Blockchain en TON: ¿qué es y por qué?
Como se mencionó en el artículo anterior, blockchain es una estructura de datos cuyos elementos (bloques) están ordenados en una "cadena", y cada bloque posterior de la cadena contiene un hash del anterior. Los comentarios plantearon la pregunta: ¿por qué necesitamos una estructura de datos de este tipo cuando ya tenemos un DHT, una tabla hash distribuida? Obviamente, algunos datos se pueden almacenar en DHT, pero esto sólo es adecuado para información no demasiado "sensible". Los saldos de criptomonedas no se pueden almacenar en DHT, principalmente debido a la falta de controles integridad. En realidad, toda la complejidad de la estructura blockchain crece para evitar interferencias con los datos almacenados en ella.
Sin embargo, la cadena de bloques en TON parece incluso más compleja que en la mayoría de los otros sistemas distribuidos, y por dos razones. El primero es el deseo de minimizar la necesidad de tenedores. En las criptomonedas tradicionales, todos los parámetros se establecen en la etapa inicial y cualquier intento de cambiarlos conduce en realidad al surgimiento de un "universo de criptomonedas alternativo". La segunda razón es el soporte para aplastar (fragmentación, fragmentación) cadena de bloques. Blockchain es una estructura que no puede volverse más pequeña con el tiempo; y normalmente cada nodo responsable del funcionamiento de la red se ve obligado a almacenarlo por completo. En los sistemas tradicionales (centralizados), la fragmentación se utiliza para resolver estos problemas: algunos de los registros de la base de datos se encuentran en un servidor, otros en otro, etc. En el caso de las criptomonedas, esta funcionalidad todavía es bastante rara, en particular debido al hecho de que es difícil agregar fragmentación a un sistema donde no estaba planeado originalmente.
¿Cómo planea TON resolver los dos problemas anteriores?
Contenido de cadena de bloques. Cadenas de trabajo.
En primer lugar, hablemos de lo que se planea almacenar en la cadena de bloques. Los estados de las cuentas (“billeteras” en el caso base) y los contratos inteligentes se almacenarán allí (para simplificar, asumiremos que esto es lo mismo que las cuentas). En esencia, esta será una tabla hash normal: las claves que contiene serán identificadores. ID de la cuentay los valores son estructuras de datos que contienen cosas como:
- equilibrar;
- código de contrato inteligente (solo para contratos inteligentes);
- almacenamiento de datos de contratos inteligentes (solo para contratos inteligentes);
- Estadísticas;
- (opcional) clave pública para transferencias desde la cuenta, por defecto account_id;
- cola de mensajes salientes (aquí se ingresan para reenviarlos al destinatario);
- una lista de los últimos mensajes entregados a esta cuenta.
Como se mencionó anteriormente, los bloques en sí consisten en transacciones: mensajes entregados a varias cuentas account_id. Sin embargo, además de account_id, los mensajes también contienen un campo de 32 bits. id_cadena de trabajo — el llamado identificador cadena de trabajo (cadena de trabajo, cadena de bloques de trabajo). Esto permite tener varias blockchains independientes entre sí con diferentes configuraciones. En este caso, workchain_id = 0 se considera un caso especial, cadena de trabajo cero — son los saldos en él los que corresponderán a la criptomoneda TON (Gramos). Lo más probable es que al principio no existan otras cadenas de trabajo.
Cadenas de fragmentos. Paradigma de fragmentación infinita.
Pero el crecimiento del número de blockchains no se detiene ahí. Tratemos con la fragmentación. Imaginemos que a cada cuenta (account_id) se le asigna su propia cadena de bloques (que contiene todos los mensajes que le llegan) y que los estados de todas esas cadenas de bloques se almacenan en nodos separados.
Por supuesto, esto es un gran desperdicio: lo más probable es que en cada uno de estos cadenas de fragmentos (cadena de fragmentos, fragmento de cadena de bloques) las transacciones llegarán muy raramente y se necesitarán muchos nodos potentes (de cara al futuro, observo que no estamos hablando solo de clientes en teléfonos móviles, sino de servidores serios).
Por lo tanto, las shardchain combinan cuentas mediante los prefijos binarios de sus identificadores: si una shardchain tiene un prefijo de 0110, incluirá transacciones de todos los account_ids que comiencen con estos números. Este prefijo_fragmento puede tener una longitud de 0 a 60 bits y, lo más importante, puede cambiar dinámicamente.
Tan pronto como una de las cadenas de fragmentos comienza a recibir demasiadas transacciones, los nodos que trabajan en ella, de acuerdo con reglas predeterminadas, la "dividen" en dos hijos: sus prefijos serán un poco más largos (y para uno de ellos este bit será igual a 0, y para el otro - 1). Por ejemplo, prefijo_fragmento = 0110b se dividirá en 01100b y 01101b. A su vez, si dos cadenas de fragmentos "vecinas" comienzan a sentirse lo suficientemente cómodas (durante algún tiempo), se fusionarán nuevamente.
Por lo tanto, la fragmentación se realiza "de abajo hacia arriba": asumimos que cada cuenta tiene su propia fragmentación, pero por el momento están "pegados" mediante prefijos. Esto es lo que significa Paradigma de fragmentación infinita (paradigma de fragmentación infinita).
Por otra parte, me gustaría subrayar que las cadenas de trabajo existen sólo virtualmente; de hecho, id_cadena de trabajo es parte del identificador de una cadena de fragmentos específica. En términos formales, cada cadena de fragmentos se define mediante un par de números (id_cadena de trabajo, prefijo_fragmento).
Error de corrección. Cadenas de bloques verticales.
Tradicionalmente, cualquier transacción en una cadena de bloques se considera "escrita en piedra". Sin embargo, en el caso de TON, es posible "reescribir la historia" - en caso de que alguien (el llamado. nudo pescador) demostrará que uno de los bloques fue firmado incorrectamente. En este caso, se agrega un bloque de corrección especial a la cadena de fragmentos correspondiente, que contiene el hash del bloque que se está corrigiendo (y no el último bloque de la cadena de fragmentos). Pensando en la cadena de fragmentos como una cadena de bloques dispuestos horizontalmente, podemos decir que el bloque correctivo está unido al bloque erróneo no hacia la derecha, sino desde arriba, por lo que se considera que se convierte en parte de una pequeña "cadena de bloques vertical". . Por lo tanto, podemos decir que las cadenas de fragmentos son cadenas de bloques bidimensionales.
Si, después de un bloque erróneo, los cambios realizados por él fueron referenciados por bloques posteriores (es decir, se realizaron nuevas transacciones basadas en transacciones no válidas), también se agregan correcciones a estos bloques "en la parte superior". Si los bloqueos no afectaron a la información “afectada”, estas “ondas correctivas” no se aplican a ellos. Por ejemplo, en la ilustración anterior, la transacción del primer bloque, que aumenta el saldo de la cuenta C, se reconoció como incorrecta; por lo tanto, la transacción que reduce el saldo de esta cuenta en el tercer bloque también debe cancelarse y se debe cancelar el bloque correctivo. debe cometerse encima del bloque mismo.
Cabe señalar que, aunque los bloques correctivos se muestran ubicados "arriba" de los originales, en realidad se agregarán al final de la cadena de bloques correspondiente (donde deberían estar cronológicamente). La ubicación bidimensional solo muestra a qué punto de la cadena de bloques estarán “vinculados” (a través del hash del bloque original ubicado en ellos).
Puedes filosofar por separado sobre lo buena que es la decisión de "cambiar el pasado". Parecería que si admitimos la posibilidad de que aparezca un bloque incorrecto en la cadena de fragmentos, entonces no podemos evitar la posibilidad de que aparezca un bloque correctivo erróneo. Aquí, hasta donde puedo decir, la diferencia está en la cantidad de nodos que deben llegar a un consenso sobre nuevos bloques: habrá una cantidad relativamente pequeña de personas trabajando en cada cadena de fragmentos".grupo de trabajo» nodos (que cambia su composición con bastante frecuencia), y la introducción de bloques correctivos requerirá el consentimiento de todos nodos validadores. Hablaré más sobre validadores, grupos de trabajo y otras funciones de nodos en el próximo artículo.
Una blockchain para gobernarlos a todos
Hay mucha información mencionada anteriormente sobre los diferentes tipos de blockchains, que a su vez también debería almacenarse en algún lugar. En particular, estamos hablando de la siguiente información:
- sobre el número y configuraciones de las cadenas de trabajo;
- sobre la cantidad de cadenas de fragmentos y sus prefijos;
- sobre qué nodos son actualmente responsables de qué cadenas de fragmentos;
- hashes de los últimos bloques agregados a todas las cadenas de fragmentos.
Como habrás adivinado, todas estas cosas se registran en otro almacenamiento de blockchain: cadena maestra (cadena maestra, dominar la cadena de bloques). Debido a la presencia de hashes de los bloques de todas las cadenas de fragmentos en sus bloques, hace que el sistema esté altamente conectado. Esto significa, entre otras cosas, que la generación de un nuevo bloque en la cadena maestra ocurrirá inmediatamente después de la generación de bloques en las cadenas de fragmentos; se espera que los bloques en las cadenas de fragmentos aparezcan casi simultáneamente aproximadamente cada 5 segundos, y el siguiente bloque en el masterchain - un segundo después de eso.
Pero, ¿quién será responsable de la implementación de todo este trabajo titánico: de enviar mensajes, ejecutar contratos inteligentes, formar bloques en shardchains y masterchain, e incluso verificar si hay errores en los bloques? ¿Todo esto lo harán en secreto los teléfonos de millones de usuarios con el cliente Telegram instalado? ¿O tal vez el equipo de Durov abandonará las ideas de descentralización y sus servidores lo harán a la antigua usanza?
De hecho, ni una ni la otra respuesta son correctas. Pero los márgenes de este artículo se están agotando rápidamente, por lo que hablaremos sobre las diversas funciones de los nodos (es posible que ya hayas notado menciones sobre algunos de ellos), así como la mecánica de su trabajo, en la siguiente parte.
Fuente: habr.com