Llevo dos semanas escuchando sobre Telegram y la situación con su bloqueo sin sentido y despiadado por parte de Roskomnadzor. Muchos han sido afectados, pero todo esto son temas para publicaciones en Geektimes. Lo que me sorprendió fue que todavía no he visto en Habr ninguna revisión sobre la red TON, basada en Telegram — Telegram Open Network. Quisiera llenar este vacío, ya que hay mucho que estudiar allí, a pesar de la falta de declaraciones oficiales al respecto.
Recuerden, hay rumores de que Telegram ha lanzado un ICO privado muy grande, ya habiendo recaudado cantidades increíbles. Se supone que este año se lanzará su propia criptomoneda Gram — y cada usuario de Telegram tendrá automáticamente una billetera, lo que por sí mismo crea una gran ventaja sobre otras criptomonedas.
Desafortunadamente, dado que no hay declaraciones oficiales, solo puedo basarme en , de lo cual les advierto de inmediato. Por supuesto, puede resultar ser una falsificación muy elaborada, pero tampoco se puede descartar que sea un verdadero whitepaper del futuro sistema, escrito por Nikolai Durov (y probablemente filtrado por alguien de los inversionistas). Pero incluso si se trata de un fraude, nadie puede prohibirnos estudiarlo y discutirlo, ¿cierto?
¿Qué dice este documento? Intentaré resumirlo con mis propias palabras, cercano al texto, pero en español y de manera un poco más humana (que me perdone Nikolai por su tendencia a caer en una matemática formal). Tengan en cuenta que incluso en caso de su autenticidad, se trata de una descripción preliminar del sistema y es muy probable que cambie para el lanzamiento público.
Descubrimos que, además de la criptomoneda, se propone mucho más. Desglosemos esto paso a paso.
- TON Blockchain. Esta es la base de todo el sistema. Si no saben qué es , les recomiendo que se informen, porque aquí habrá muchos blockchains. Anidados entre sí, virtualmente fragmentados e incluso 'verticales' dentro de los bloques de otros blockchains. Además, habrá algunos términos que suenan bastante bien como Enrutamiento Hipercubo Instantáneo y Paradigma de Fragmentación Infinita, pero hablaremos de eso más adelante. Y, por supuesto, proof-of-stake y contratos inteligentes.
- Red P2P de TON. Red de pares sobre la cual se construirá el funcionamiento del sistema. De ella se hablará en primer lugar en esta parte de la narrativa.
- TON Storage. Almacenamiento de archivos que, independientemente de la blockchain, se construirá sobre la mencionada red de pares. Se puede comparar con torrents.
- TON Proxy. Este es un servicio cuyo objetivo es aumentar el anonimato de los participantes de la red. Cualquier paquete se puede enviar no directamente, sino a través de túneles intermediarios con cifrado adicional, similar a I2P o TOR.
- TON DHT. Tabla hash distribuida para almacenar valores arbitrarios. También está construida sobre TON Network (pero utiliza la misma) y ayuda TON Storage a encontrar nodos "seedders", y TON Proxy — retransmisores intermedios. Sin embargo, es importante señalar que, a diferencia de la blockchain, esta tabla hash no es un almacenamiento seguro; no se puede guardar información importante en ella.
- TON Services. Plataforma para servicios arbitrarios. En esencia, es una nueva internet sobre todo lo descrito anteriormente. El intercambio de datos se realiza a través de TON Network/TON Proxy, y la lógica está en los contratos inteligentes de TON Blockchain. Y la interfaz con URL bastante familiares.
- TON DNS. Ya que se ha mencionado las URL familiares, también se necesita un convertidor de ellas a direcciones de 256 bits — cuentas, contratos, servicios y nodos.
- TON Payments. Y solo aquí se plantea la cuestión monetaria. Y no será solo gram — como con el etéreo, serán posibles cualquier tipo de "tokens"; los gramos serán solo la moneda "por defecto".
Esta es la primera parte que describe el nivel "aterrizado" de TON — su parte de red, construida sobre protocolos tradicionales. En la siguiente parte se hablará de la "pulpa" — la blockchain que será apoyada por el sistema descrito a continuación. Así, mi orden de narración difiere un poco del usado en el documento mencionado (que comienza directamente con el nivel abstracto).
Conceptos básicos
TL (Type Language). Este es un formato binario abstracto para estructuras de datos arbitrarias. Se utiliza en el protocolo de Telegram y se utilizará activamente en TON. Si desea familiarizarse con él en detalle — .
Hash (hash). Función que realiza una transformación irreversible de una estructura de datos arbitraria en un único número de longitud fija. En la documentación, se habla extensamente de la función .
Nodo de la red (node). Un nodo es un software que garantizará el funcionamiento del sistema. En particular, se supone que cada aplicación cliente de Telegram incluirá un nodo de TON. A un nivel bajo, los nodos tienen direcciones IPv4/IPv6 y se comunican a través del protocolo UDP; a un nivel más alto, poseen direcciones abstractas y implementan el protocolo ADNL (sobre direcciones abstractas y ADNL — ver más abajo). Cuando se habla de que algunas partes del sistema hacen algo o almacenan ciertos datos, se entiende que esto lo hacen los nodos de la red.
Dirección abstracta (o simplemente dirección, address). La dirección del nodo se define por su clave pública. Más estrictamente, es un hash de 256 bits (SHA256) de una estructura de datos que contiene la clave pública (no se especifica el algoritmo criptográfico concreto; como ejemplo se mencionan las curvas elípticas y RSA-2048). Para que un nodo pueda interactuar con otro, necesita conocer no solo la dirección de aquel, sino también esta estructura de datos. Teóricamente, un nodo físico puede crear cualquier cantidad de direcciones (correspondientes a diferentes claves).
A menudo se utiliza precisamente esta combinación: un «imagen» en forma de estructura TL (que contiene prácticamente cualquier dato) y el hash de 256 bits de la misma, que se utiliza para la direccionamiento.
Blockchain (blockchain). Un blockchain es una estructura de datos cuyos elementos (bloques) están ordenados en una «cadena», y cada bloque siguiente de la cadena contiene el hash del anterior. De esta manera se logra la integridad; los cambios solo pueden añadirse mediante la adición de nuevos bloques.
El servicio (el servicio). Los servicios dentro de TON pueden ser de diferentes tipos, dependiendo de si utilizan blockchain o no. Por ejemplo, uno (o varios) de los nodos de la red puede procesar ciertas solicitudes RPC a través del protocolo ADNL, sin crear registros en el blockchain, similar a los servidores web tradicionales. También se está considerando la posibilidad de implementar HTTP sobre ADNL, así como la transición del propio mensajero a este protocolo. Por analogía con TOR o I2P, esto lo haría más resistente a diversas bloqueos.
Al mismo tiempo, una serie de servicios implica tanto la interacción con la cadena de bloques como el procesamiento de solicitudes fuera de ella. Por ejemplo, para TON Storage — el almacenamiento de archivos — no es muy sensato almacenar los archivos mismos en la cadena de bloques. Solo se almacenarán los hashes de los archivos (junto con cierta metainformación sobre ellos), y como "servidores de archivos" actuarán nodos especializados de la red, dispuestos a entregarlos a otros nodos a través de ADNL.
Servicio en la nube (fog service). Se trata de algunos servicios que implican descentralización y participación abierta en ellos. Por ejemplo, TON Proxy es un servicio que puede mantener cualquier participante que desee proporcionar su nodo como intermediario (proxy), retransmitiendo paquetes entre otros nodos. Si lo desea, puede cobrar una tarifa establecida por ello — utilizando el sistema TON Payments para micropagos (que, a su vez, también es un servicio en la nube).
ADNL: Capa de Red de Datagramas Abstractos
A nivel más bajo, la interacción entre nodos se realizará a través del protocolo UDP (aunque se permiten otras opciones).
Como se mencionó anteriormente, para que un nodo pueda enviar un paquete a otro, debe conocer una de sus claves públicas (y, por lo tanto, la dirección que la determina). Encripta el paquete con esta clave y añade al principio del paquete una dirección de 256 bits del destinatario — dado que un nodo puede tener varias de estas direcciones, esto le permitirá determinar qué clave usar para la desencriptación.
Además, en lugar de la dirección del destinatario, al principio del paquete de datos puede haber un identificador conocido como canal. En tal caso, el procesamiento del paquete ya depende de los acuerdos específicos entre nodos — por ejemplo, los datos enviados a un cierto canal pueden estar destinados a otro nodo y deben ser reenviados a él (este es el servicio TON Proxy). Otro caso particular puede ser la interacción directa entre nodos, pero con cifrado mediante un par de claves individuales para este canal (previamente formadas a través del protocolo de Diffie-Hellman).
Finalmente, hay un caso especial que es el canal "cero" — si un nodo aún no conoce las claves públicas de sus "vecinos", puede enviarles paquetes sin cifrado alguno. Esto está destinado solo para la inicialización; una vez que los nodos envíen información sobre sus claves, se deben utilizar para la interacción futura.
El protocolo descrito anteriormente (256 bits de identificación del canal + contenido del paquete) se llama ADNL. La documentación menciona la posibilidad de implementar un análogo de TCP sobre él o una propia superestructura — RLDP (Reliable Large Datagram Protocol), pero no entra en detalles sobre su implementación.
TON DHT: Tabla hash distribuida
Como en otras sistemas distribuidos, TON propone la implementación de DHT — . Más concretamente, la tabla es . Si no estás familiarizado con este tipo de tablas hash, no te preocupes, a continuación describiré aproximadamente cómo están organizadas.
En un sentido abstracto, DHT asigna a claves de 256 bits ciertos valores binarios de longitud arbitraria. En este caso, las claves en la tabla son hashes de una cierta estructura TL (las estructuras mismas también se almacenan junto con la DHT). Esto es muy parecido a la formación de direcciones de nodos — y de hecho pueden estar presentes en la DHT (por ejemplo, bajo esta clave puede encontrarse la dirección IP del nodo correspondiente a la dirección abstracta, si no la oculta). Pero en general, los "prototipos de claves" (sus de reglas, descripciones de claves) son metadatos que indican el "propietario" de la entrada en la tabla hash (es decir, la clave pública de algún nodo), el tipo de valor almacenado y las reglas según las cuales esta entrada puede ser modificada posteriormente. Por ejemplo, una regla puede permitir que solo el propietario modifique el valor — o prohibir que el valor disminuya (para protegerse de ataques de repetición).
Además de las claves de 256 bits, se introduce el concepto de direcciones DHT. La diferencia con las direcciones normales de nodos es que la dirección DHT está obligatoriamente vinculada a una dirección IP. Si el nodo no oculta su IP, puede usar una dirección normal para DHT. Pero más a menudo, para las necesidades de DHT se creará una dirección separada, "semi-permanente".
Sobre las claves y direcciones DHT se introduce el concepto de distancia — en esto coincide todo con las tablas La distancia entre las claves es igual a XOR (la operación bit a bit exclusiva) entre ellas. Al igual que en las tablas de Kademlia, el valor correspondiente a una clave debe almacenarse en s nodos que tengan la menor distancia a esta clave (s aquí — un número relativamente pequeño).
Para que un nodo DHT pueda interactuar con otros nodos, mantiene en memoria una tabla de enrutamiento DHT que contiene direcciones DHT e IP de nodos con los que ha interactuado anteriormente, agrupadas por la distancia a ellos. Hay 256 de tales grupos (que corresponden al bit más significativo fijado en el valor de la distancia; es decir, los nodos a una distancia de 0 a 255 caerán en un grupo, de 256 a 65535 en el siguiente, y así sucesivamente). Dentro de cada grupo se almacena un número limitado de los 'mejores' nodos (en términos de ping a ellos).
Cada nodo debe realizar varias operaciones: almacenar un valor para una clave, buscar nodos y buscar valores. La búsqueda de nodos implica proporcionar los nodos más cercanos a una clave dada desde la tabla de enrutamiento; la búsqueda de valores es lo mismo, excepto en situaciones en las que el nodo conoce un valor para la clave (en ese caso, simplemente lo devuelve). Por lo tanto, si un nodo desea encontrar un valor en el DHT por su clave, envía solicitudes a un pequeño número de nodos más cercanos a esa clave desde su tabla de enrutamiento. Si entre sus respuestas no se encuentra el valor buscado, pero hay otras direcciones de nodos, la solicitud se repite a ellos.
TON DHT puede usarse para diversos propósitos, por ejemplo, para implementar un almacenamiento de archivos similar a torrents (ver TON Storage); para determinar direcciones de nodos que implementan ciertos servicios; para almacenar información sobre propietarios de cuentas en blockchain. Pero la aplicación más importante es la detección de nodos por sus direcciones abstractas. Para esto, la dirección se utiliza como clave, cuyo valor se necesita encontrar. Como resultado de la solicitud, se encontrará el nodo mismo (si la dirección buscada fue su dirección DHT semi-permanente), o el valor será una dirección IP y un puerto para la conexión, o bien otra dirección que se debe utilizar como un túnel intermediario.
Las redes superpuestas en TON
El protocolo ADNL descrito anteriormente permite que cualquier nodo intercambie información entre sí, aunque no necesariamente de las maneras más óptimas. Se puede decir que gracias al ADNL, todos los nodos forman un grafo global TON (idealmente, conexo). Sin embargo, también se prevé la posibilidad de crear redes superpuestas: subgrafos dentro de este grafo.
Dentro de tal red, la interacción se realiza solo de forma directa, a través de conexiones previamente establecidas entre los nodos participantes de la red (a través de los canales ADNL descritos anteriormente). La formación de tales conexiones entre vecinos y la búsqueda de los mismos son procesos automáticos que buscan mantener la conectividad de la red superpuesta y minimizar las latencias en el intercambio de datos dentro de ella.
Además, se prevé un método para difundir rápidamente grandes actualizaciones por difusión dentro de la red: estas se dividen en partes, se complementan con un código de corrección de errores, y todas estas piezas se envían de un participante a otro. De esta manera, un participante no necesita recibir todas las partes por completo antes de retransmitirlas en la red.
Las redes superpuestas pueden ser públicas y privadas. Unirse a una red pública no es difícil: solo hay que encontrar la estructura TL que la describe (puede ser pública o estar disponible mediante una clave específica en DHT). En el caso de una red privada, esta estructura debe ser conocida por el nodo de antemano.
Continuará
He decidido dividir la revisión de TON en varios artículos. Esta parte concluye aquí, y pasaré a examinar la estructura de la blockchain (más precisamente, de las blockchains) de las que se compondrá TON.
Fuente: habr.com
