Este texto es la continuación de una serie de artículos en los que examino la estructura de la red descentralizada Telegram Open Network (TON), que supuestamente se lanzará este año. He descrito su nivel más básico: el método de interacción entre nodos.
Por si acaso, recuerdo que no tengo relación con el desarrollo de esta red y todo el material proviene de una fuente abierta (aunque no verificada) — (también hay un documento adjunto, , que expone brevemente los puntos principales), publicado a finales del año pasado. La cantidad de información en este documento, en mi opinión, sugiere su autenticidad, aunque no hay confirmaciones oficiales de ello.
Hoy analizaremos el componente principal de TON: la blockchain.
Conceptos básicos
Cuenta (account). Un conjunto de datos identificado por un número de 256 bits account_id (más comúnmente, es la clave pública del propietario de la cuenta). En el caso básico (ver más abajo cero blockchain), estos datos representan el balance del usuario. Cualquiera puede "tomar" un determinado account_id pero su valor solo puede ser modificado de acuerdo con ciertas reglas.
Contrato inteligente (smart contract). En esencia, es un caso particular de cuenta, complementado con el código del smart contract y un almacenamiento de sus variables. Si en el caso de una "billetera" se puede depositar y retirar dinero de forma relativamente simple y predefinida, en el caso del smart contract esas reglas están escritas en forma de su código (en un lenguaje de programación de Turing completo).
Estado de la blockchain (state of blockchain). La combinación de los estados de todas las cuentas/smart contracts (en un sentido abstracto, es una tabla hash donde las claves son los identificadores de las cuentas y los valores son los datos almacenados en las cuentas).
Mensaje (message). Anteriormente, utilicé la expresión "depositar y retirar dinero" — este es un ejemplo específico de mensaje ("transferir N gramos de la cuenta account_1 a la cuenta account_2"). Evidentemente, solo un nodo que posea la clave privada de la cuenta puede enviar tal mensaje account_1 — y debe confirmar esto con una firma. El resultado de la entrega de tales mensajes a una cuenta normal es el aumento de su saldo, y para un smart contract es la ejecución de su código (que procesará la recepción del mensaje). Por supuesto, también existen otros mensajes (que transfieren no montos de dinero, sino datos arbitrarios entre smart contracts).
La transacción (transacción). El hecho de la entrega del mensaje se llama transacción. Las transacciones cambian el estado de la blockchain. Es a partir de las transacciones (registros de entrega de mensajes) de donde se forman los bloques en la blockchain. En este sentido, podemos imaginar el estado de la blockchain como una base de datos incremental: todos los bloques son 'diffs' que deben aplicarse secuencialmente para obtener el estado actual de la base de datos. Sobre los detalles del empaquetado de estos 'diffs' (y la recuperación del estado completo a partir de ellos) se hablará en el siguiente artículo.
Blockchain en TON: ¿qué es y para qué sirve?
Como se mencionó en el artículo anterior, la blockchain es una estructura de datos cuyos elementos (bloques) están organizados en una 'cadena', y cada bloque siguiente en la cadena contiene el hash del anterior. En los comentarios se planteó la pregunta: ¿para qué necesitamos realmente tal estructura de datos cuando ya tenemos DHT, que es una tabla hash distribuida? Es evidente que algunos datos pueden almacenarse en DHT, pero esto solo es adecuado para información que no es demasiado 'sensible'. No se pueden almacenar los saldos de criptomonedas en DHT, principalmente debido a la falta de verificaciones de integridad. De hecho, toda la complejidad de la estructura de blockchain surge para evitar interferencias en los datos almacenados en ella.
Sin embargo, la blockchain en TON parece ser aún más compleja que en la mayoría de los otros sistemas distribuidos, y hay dos razones para ello. La primera es el deseo de minimizar la necesidad de forks. En las criptomonedas tradicionales, todos los parámetros están establecidos en la etapa inicial y cualquier intento de cambiarlos prácticamente conduce a la aparición de un 'universo alternativo de criptomonedas'. La segunda razón es el soporte para el sharding de la blockchain. La 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 almacenarla en su totalidad. En los sistemas tradicionales (centralizados), se utiliza el sharding para resolver tales problemas: parte de los registros en la base de datos se almacena en un servidor, parte en otro, etc. En el caso de las criptomonedas, esta funcionalidad sigue siendo bastante rara, especialmente porque es complicado añadir sharding a un sistema donde no fue planeado desde el principio.¿Cómo planea TON resolver ambos problemas descritos anteriormente?, fragmentación) blockchain. El blockchain es una estructura que no puede hacerse más pequeña con el tiempo; y generalmente, cada nodo responsable del funcionamiento de la red se ve obligado a almacenarlo completamente. En sistemas tradicionales (centralizados), se utiliza la fragmentación para resolver problemas similares: parte de los registros en la base de datos se encuentra en un servidor, otra parte en otro, etc. En el caso de las criptomonedas, dicha funcionalidad es bastante rara hasta ahora, especialmente porque es complicado añadir fragmentación a un sistema donde no estaba planificada originalmente.
¿Cómo planea TON resolver ambos problemas descritos anteriormente?
Contenido de la blockchain. Workchains.
Primero, hablemos sobre qué se planea almacenar en la blockchain. Allí se almacenarán los estados de las cuentas ("billeteras" en el caso básico) y de los contratos inteligentes (para simplificar, consideraremos que esto es lo mismo que las cuentas). En esencia, será una simple tabla hash: las claves serán los identificadores account_id, y los valores serán estructuras de datos que contienen elementos como:
- saldo;
- código del contrato inteligente (solo para contratos inteligentes);
- almacenamiento de datos del contrato inteligente (solo para contratos inteligentes);
- estadísticas;
- (opcionalmente) clave pública para transferencias desde la cuenta, por defecto account_id;
- cola de mensajes salientes (aquí se almacenan para enviar al destinatario);
- lista de los últimos mensajes entregados a esta cuenta.
Como se mencionó anteriormente, los bloques consisten directamente en transacciones: mensajes entregados a diversas cuentas account_id. Sin embargo, además de account_id, los mensajes también contienen un campo de 32 bits workchain_id — el identificador del llamado workchain (workchain, blockchain en funcionamiento). Esto permite tener múltiples blockchains independientes entre sí con diferentes configuraciones. En este caso, workchain_id = 0 se considera un caso especial, workchain nulo — precisamente los saldos en él corresponderán a la criptomoneda TON (Grams). Es muy probable que, al principio, no existan otros workchains.
Sharding. Paradigma de Sharding Infinito.
Pero la cantidad de blockchains no se detiene aquí. Analicemos el sharding. Imaginemos que a cada cuenta (account_id) se le asigna su propia blockchain: en ella reposan todos los mensajes que le llegan, y los estados de todas esas blockchains se almacenan en nodos separados.
Por supuesto, esto es bastante derrochador: probablemente, en cada uno de estos shardchains (shardchain, blockchain shard) las transacciones llegarán muy raramente, y se necesitarán muchos nodos potentes (adelantando, señalaré que no se trata simplemente de clientes en teléfonos móviles, sino de servidores serios).
Por lo tanto, los shardchains agrupan cuentas por los prefijos binarios de sus identificadores: si un shardchain tiene un prefijo 0110, entonces incluirá las transacciones de todas las account_id que comienzan con esos dígitos. Este shard_prefix puede tener una longitud de 0 a 60 bits, y lo más importante es que puede cambiar dinámicamente.
Cuando uno de los shardchains comienza a recibir un número excesivo de transacciones, los nodos que trabajan en él, siguiendo unas reglas predefinidas, lo "dividen" en dos subcomponentes; sus prefijos serán un bit más largos (y para uno de ellos este bit será 0, y para el otro será 1). Por ejemplo, shard_prefix = 0110b se dividirá en 01100b y 01101b. A su vez, si dos shardchains "vecinos" comienzan a sentir suficiente tranquilidad (durante algún tiempo), se fusionarán nuevamente.
De esta manera, el sharding se hace "de abajo hacia arriba"; asumimos que cada cuenta tiene su propio shard, pero estos están, por un tiempo, "pegados" por prefijos. Esto es lo que significa Paradigma de Fragmentación Infinita (la parábola de sharding infinito.).
Cabe destacar que los workchains existen solo de manera virtual; en realidad, workchain_id esto es parte del identificador de un shardchain específico. Hablando en términos formales, cada shardchain se define por un par de números (workchain_id, shard_prefix).
Corrección de errores. Blockchains verticales.
Tradicionalmente se considera que cualquier transacción en una blockchain está "esculpida en piedra". Sin embargo, en el caso de TON se prevé la posibilidad de "reescribir la historia" — en caso de que alguien (el llamado nodo "pescador") demuestre que uno de los bloques fue firmado incorrectamente. En este caso, se añade un bloque correctivo especial al shardchain correspondiente, que contiene el hash del bloque siendo corregido (y no del último bloque en el shardchain). Al considerar el shardchain como una cadena de bloques dispuesta horizontalmente, se puede decir que el bloque correctivo se adjunta al bloque erróneo no a la derecha, sino en la parte superior; por tanto, se considera que se convierte en parte de un pequeño "blockchain vertical". Así, se puede afirmar que los shardchains son blockchains bidimensionales..
En caso de que, tras un bloque erróneo, los bloques posteriores hagan referencia a los cambios introducidos (es decir, se hayan realizado nuevas transacciones basadas en datos no válidos), se añaden correcciones a esos bloques "encima". Si los bloques no afectaron a la información "afectada", estas "ondas correctivas" no se extienden a ellos. Por ejemplo, en la ilustración anterior, se consideró incorrecta la transacción del primer bloque, que aumentaba el saldo de la cuenta C; por lo tanto, la transacción que reduce el saldo de esta cuenta en el tercer bloque también debe ser anulada, y se debe añadir un bloque correctivo encima del bloque mismo.
Es necesario señalar que, aunque los bloques correctivos se muestran colocados "sobre" los originales, en realidad se escriben al final de la cadena de bloques correspondiente (donde deben estar cronológicamente). La disposición bidimensional simplemente muestra a qué punto de la cadena de bloques se 'engancharán' (a través del hash del bloque original que contienen).
Se podría reflexionar por separado sobre cuán buena es la decisión de "cambiar el pasado". Parecería que, si permitimos la posibilidad de que aparezca un bloque incorrecto en la shardchain, no se puede evitar la posibilidad de que aparezca un bloque correctivo erróneo. Aquí, tanto como puedo juzgar, la diferencia radica en la cantidad de nodos que deben alcanzar consenso sobre los nuevos bloques: bajo cada shardchain trabajará un relativamente pequeño "grupo de trabajode" nodos (que cambia bastante a menudo), mientras que la introducción de bloques correctivos requerirá el consenso de todos los nodos validadores. Hablaré más sobre validadores, grupos de trabajo y otros roles de los nodos en el siguiente artículo.
Una cadena de bloques para gobernarlos a todos
Se ha mencionado mucha información sobre los diferentes tipos de cadenas de bloques, que también debe ser almacenada en algún lugar. En particular, se trata de la siguiente información:
- sobre la cantidad y configuraciones de los workchains;
- sobre la cantidad de shardchains y sus prefijos;
- sobre qué nodos son actualmente responsables de qué shardchains;
- hashes de los últimos bloques añadidos a todas las shardchains.
Como ya habrán deducido, todas estas cosas se registran en otra cadena de bloques de almacenamiento — masterchain (masterchain, cadena de bloques maestra). Gracias a la presencia de hashes de los bloques de todas las cadenas laterales en sus bloques, hace que el sistema esté altamente interconectado. Esto significa que la generación de un nuevo bloque en la cadena principal ocurrirá directamente después de la generación de bloques en las cadenas laterales, y se espera que los bloques en las cadenas laterales aparezcan casi simultáneamente cada 5 segundos, mientras que el siguiente bloque en la cadena principal aparecerá un segundo después de esto.
Pero, ¿quién será responsable de llevar a cabo todo este titánico trabajo: la transmisión de mensajes, la ejecución de contratos inteligentes, la formación de bloques en las cadenas laterales y en la cadena principal, y además la verificación de bloques en busca de errores? ¿Realmente se encargará de todo esto en silencio los teléfonos de millones de usuarios con Telegram instalado? O, tal vez, el equipo de Durov renunciará a las ideas de descentralización y serán sus servidores los que lo hagan a la antigua usanza?
De hecho, ninguna de las dos respuestas es correcta. Pero el espacio de este artículo se está agotando rápidamente, por lo que la discusión sobre los diferentes roles de los nodos (ya es posible que haya notado menciones de algunos de ellos), así como sobre las mecánicas de su funcionamiento, se tratará en la siguiente parte.
Fuente: habr.com
