Desde hai dúas semanas, o Runet está facendo ruído sobre Telegram e a situación co seu bloqueo sen sentido e sen piedade por parte de Roskomnadzor. O rebote ofendiu a moita xente, pero todos estes son temas para publicacións en Geektimes. Sorprendeume outra cousa: aínda non vin unha soa análise sobre Habré da rede TON prevista para o lanzamento con base en Telegram - Telegram Open Network. Quería suplir esta deficiencia, porque hai algo que estudar alí, aínda que non hai declaracións oficiais ao respecto.
Permíteme lembrarche que hai rumores de que Telegram lanzou unha ICO pechada a gran escala, xa que recolleu cantidades incribles de diñeiro. Espérase que a moeda criptográfica propia de Gram se lance este ano e cada usuario de Telegram terá automaticamente unha carteira, o que en si mesmo crea unha vantaxe significativa sobre outras criptomoedas.
Desafortunadamente, como non hai declaracións oficiais, só podo avanzar máis lonxe , do que vos aviso inmediatamente. Por suposto, pode resultar unha falsificación moi hábil, pero tamén é posible que este sexa un verdadeiro libro branco do futuro sistema, escrito por Nikolai Durov (e filtrado, probablemente, por un dos investidores). Pero aínda que sexa falso, ninguén nos prohibirá estudalo e discutilo, non?
Que di este documento? Tratarei de contalo coas miñas propias palabras, preto do texto, pero en ruso e un pouco máis humanamente (que Nikolai me perdoe a súa tendencia a entrar nas matemáticas formais). Teña en conta que aínda que isto sexa verdadeiro, este é un borrador de descrición do sistema e moi probablemente cambiará no momento do lanzamento público.
Aprendemos que ademais da criptomoeda, hai moito máis que se espera. Poñémolo en orde.
- TON Blockchain. Esta é a base de todo o sistema. Se non sabes o que é — Recomendo descubrilo, porque aquí haberá moitas cadeas de bloques. Cadenas de bloques aniñadas unhas dentro doutras, virtualmente fragmentadas e incluso "verticais" dentro de bloques doutras cadeas de bloques. Tamén haberá algúns termos interesantes como Enrutamento instantáneo de Hypercube и Paradigma de fragmentación infinita, pero sobre iso máis tarde. E, por suposto, proof-of-stake e contratos intelixentes.
- Rede TON P2P. Rede peer-to-peer sobre a base da cal se construirá o sistema. Ela falarase primeiro nesta parte da historia.
- Almacenamento TON. Almacenamento de ficheiros, que, independentemente da cadea de bloques, construirase na rede peer-to-peer mencionada anteriormente. Pódese comparar cos torrents.
- TON Proxy. Este é un servizo que ten como finalidade aumentar o anonimato dos participantes da rede. Calquera paquete pode enviarse non directamente, senón a través de túneles intermediarios con cifrado adicional, como I2P ou TOR.
- TON DHT. Táboa hash distribuída para almacenar valores arbitrarios. Tamén está construído enriba Rede TON (pero ao mesmo tempo é usado por el) e axuda Almacenamento TON atopar nodos de "distribución" e TON Proxy - Repetidores intermedios. Pero hai que ter en conta que, a diferenza da cadea de bloques, esta táboa hash non é un almacenamento seguro: non pode almacenar información importante nela.
- Servizos TON. Plataforma para servizos personalizados. En esencia, esta é unha nova Internet ademais de todo o descrito anteriormente. Intercambio de datos - vía Rede TON/TON Proxy, e a lóxica está nos contratos intelixentes do TON Blockchain. E unha interface con URL bastante coñecidos.
- TON DNS. Xa que falamos de URL coñecidos, tamén necesitamos un conversor deles en enderezos de 256 bits: contas, contratos, servizos e nodos.
- Pagos TON. E aquí é onde entra en xogo a cuestión do diñeiro. E non só será gram — do mesmo xeito que co éter, calquera "ficha" será posible; Os gramos serán só a moeda "predeterminada" aquí.
Esta é a primeira parte que describe a capa "enterrada" de TON: a súa parte de rede, construída sobre os protocolos tradicionais. Na seguinte parte falaremos sobre o "soft" - blockchain, que será compatible co sistema que se describe a continuación. Así, a miña orde de narración é algo diferente á utilizada no documento anteriormente mencionado (que comeza inmediatamente no nivel abstracto).
Conceptos básicos
TL (Idioma tipo). É un formato binario abstracto para estruturas de datos arbitrarias. Utilízase no protocolo de Telegram e empregarase activamente en TON. Se queres familiarizarte con el en detalle - .
haxix (de hash). Unha función que realiza unha transformación irreversible dunha estrutura de datos arbitraria nun único número de lonxitude fixa. Ao longo da documentación falamos da función .
Nodo da rede (nodo). Un nodo é o software que asegurará que o sistema funcione. En particular, suponse que cada aplicación cliente de Telegram incluirá un nodo TON. A un nivel baixo, os nodos teñen enderezos IPv4/IPv6 e se comunican mediante o protocolo UDP; nun nivel superior, teñen enderezos abstractos e implementar o protocolo ADNL (sobre enderezos abstractos e ADNL - ver máis abaixo). Cando se trata de que algunhas partes do sistema fan algo ou almacenan algúns datos, enténdese que isto o fan os nodos da rede.
Dirección abstracta (ou simplemente enderezo, enderezo). O enderezo dun nodo está determinado pola súa chave pública. De forma máis estrita, é un hash de 256 bits (SHA256) da estrutura de datos que contén a chave pública (non se especifica o algoritmo criptográfico específico: as curvas elípticas e RSA-2048 son exemplos). Para que un nodo se comunique con outro, necesita coñecer non só o enderezo daquel, senón tamén esta estrutura de datos. En teoría, un nodo físico pode crear calquera número de enderezos (correspondentes a diferentes claves).
Ademais, a miúdo úsase tal ligazón: un "prototipo" en forma de estrutura TL (que contén case todos os datos) e un hash de 256 bits, usado para o enderezo.
Blockchain (blockchain). Blockchain é unha estrutura de datos, elementos (bloques) que se ordenan nunha "cadea", e cada bloque posterior da cadea contén o hash do anterior. Deste xeito, conséguese a integridade: só se poden facer cambios engadindo novos bloques.
Servizo (servizo). Os servizos dentro de TON poden ser de varios tipos, dependendo de se usan blockchain ou non. Por exemplo, un (ou moitos) nodos de rede poden procesar certas solicitudes RPC usando o protocolo ADNL descrito a continuación, sen crear ningún rexistro na cadea de bloques, como os servidores web tradicionais. Incluída a posibilidade de implementar HTTP sobre ADNL, así como a transición do propio messenger a este protocolo. Por analoxía con TOR ou I2P, isto fará que sexa máis resistente a varios bloqueos.
Ao mesmo tempo, unha serie de servizos implican tanto a interacción coa cadea de bloques como o procesamento de solicitudes fóra dela. Por exemplo, para TON Storage - almacenamento de ficheiros - non é moi razoable almacenar os propios ficheiros na cadea de bloques. Só conterá hash de ficheiros (xunto con algunha metainformación sobre eles), e os nós de rede especializados actuarán como "servidores de ficheiros", preparados para envialos a outros nodos a través de ADNL.
Servizo de néboa (servizo de néboa). Estamos a falar dalgúns servizos que implican descentralización e participación aberta neles. Por exemplo, TON Proxy é un servizo que pode ser compatible con calquera participante que queira proporcionar o seu nodo como intermediario (proxy) que reenvía paquetes entre outros nodos. Se o desexa, pode cobrar unha taxa fixada por el por iso, utilizando o sistema TON Payments para micropagos (que, á súa vez, tamén é un servizo de néboa).
ADNL: Capa de rede de datagramas abstractos
No nivel máis baixo, a comunicación entre nodos realizarase mediante o protocolo UDP (aínda que outras opcións son aceptables).
Como se mencionou anteriormente, para que un nodo envíe un paquete a outro, debe coñecer unha das súas chaves públicas (e, polo tanto, o enderezo que define). Cifra o paquete con esta chave e engade o enderezo de destino de 256 bits ao comezo do paquete, xa que un nodo pode ter varios destes enderezos, isto permitiralle determinar que chave usar para o descifrado.
Ademais, en lugar do enderezo do destinatario, o inicio do paquete de datos pode conter o chamado. identificador canle. Neste caso, o procesamento do paquete xa depende de acordos específicos entre nodos; por exemplo, os datos enviados a unha determinada canle poden estar destinados a outro nodo e deben ser reenviados a el (este é o servizo). TON Proxy). Outro caso especial pode ser a interacción directa entre nós, pero co cifrado mediante un par de claves individual para esta canle (prexerado mediante o protocolo Diffie-Hellman).
Finalmente, un caso especial é a canle "nula": se un nodo aínda non coñece as claves públicas dos seus "veciños", pode enviarlles paquetes sen cifrar. Isto só está pensado para a inicialización: unha vez que os nodos envían información sobre as súas claves, deberían usarse para unha comunicación posterior.
O protocolo descrito anteriormente (256 bits de identificador de canle + contido do paquete) chámase ADNL. A documentación menciona a posibilidade de implementar un análogo de TCP enriba del ou o seu propio complemento - RLDP (Reliable Large Datagram Protocol), pero non entra en detalles sobre a súa implementación.
TON DHT: táboa hash distribuída
Como ocorre con outros sistemas distribuídos, TON implica a implementación de DHT - . Máis concretamente, a táboa é . Se non estás familiarizado con este tipo de táboas hash, non te preocupes, a continuación describirei aproximadamente como funcionan.
Nun sentido abstracto, DHT asigna claves de 256 bits a valores binarios de lonxitude arbitraria. Neste caso, as claves da táboa son hash dunha determinada estrutura TL (as propias estruturas tamén se almacenan xunto co DHT). Isto é moi similar á formación de enderezos de nodos, e de feito poden estar presentes no DHT (por exemplo, usando esa chave o enderezo IP dun nodo correspondente a un determinado nodo). enderezo abstracto, se non o oculta). Pero no caso xeral, os "prototipos de chaves" (o seu descricións, descricións clave) son metadatos que indican o "propietario" dunha entrada nunha táboa hash (é dicir, a chave pública dalgún nodo), o tipo de valor almacenado e as regras polas que esta entrada pode ser modificada posteriormente. Por exemplo, unha regra pode permitir que só o propietario cambie o valor ou prohibir cambiar o valor á baixa (para protexerse contra ataques de repetición).
Ademais das claves de 256 bits, introdúcese o concepto de enderezos DHT. A diferenza cos enderezos de host habituais é que o enderezo DHT está necesariamente ligado a un enderezo IP. Se un nodo non oculta a súa IP, pode usar un enderezo normal para DHT. Pero máis a miúdo, establecerase un enderezo "semipermanente" separado para as necesidades de DHT.
O concepto de distancia introdúcese enriba das claves e enderezos DHT -nisto todo coincide coas táboas — a distancia entre as teclas é igual ao XOR (OU exclusivo bit a bit) delas. Como nas táboas de Kademlia, o valor correspondente a unha determinada chave debe almacenarse s nodos que teñen a distancia máis curta a esta chave (s aquí hai un número relativamente pequeno).
Para que un nodo DHT se comunique con outros nodos deste tipo, mantense na memoria Táboa de enrutamento DHT — Enderezos DHT e IP dos nodos cos que antes interactuaba, agrupados por distancia ata eles. Hai 256 grupos deste tipo (corresponden ao bit máis significativo definido no valor de distancia, é dicir, os nós a unha distancia de 0 a 255 formaranse nun grupo, de 256 a 65535, no seguinte, etc.). Dentro de cada grupo, gárdase un número limitado de "mellores" nodos (en termos de ping a eles).
Cada nodo debe soportar varias operacións: almacenando un valor para unha clave, busca de nodos и buscar valores. A procura de nós implica emitir, en función dunha clave determinada, os nodos máis próximos a ela desde a táboa de enrutamento; buscar valores é o mesmo, excepto cando o nodo coñece o valor da clave (entón só o devolve). En consecuencia, se un nodo quere atopar un valor por chave no DHT, envía solicitudes a un pequeno número de nodos máis próximos a esta chave desde a súa táboa de enrutamento. Se o valor requirido non está entre as súas respostas, pero hai outros enderezos de nodos, repítelles a solicitude.
TON DHT pódese usar para varios propósitos, por exemplo, para implementar un almacenamento de ficheiros tipo torrent (ver. Almacenamento TON); determinar os enderezos dos nodos que implementan determinados servizos; para almacenar información sobre os propietarios das contas na cadea de bloques. Pero a aplicación máis importante é o descubrimento de nós polos seus enderezos abstractos. Para iso, o enderezo utilízase como clave cuxo valor é necesario atopar. Como resultado da solicitude, atoparase o propio nodo (se o enderezo buscado era o seu enderezo DHT semipermanente), ou o valor será o enderezo IP e o porto para a conexión, ou outro enderezo que debería usarse como un túnel intermedio.
Redes superpostas en TON
O protocolo ADNL descrito anteriormente implica a capacidade de calquera nodo de intercambiar información entre si, aínda que non necesariamente de forma óptima. Podemos dicir que grazas a ADNL, todos os nodos forman un gráfico TON global (idealmente conectado). Pero tamén é posible crear redes superpostas - subgráficos dentro deste gráfico.
Dentro desta rede, a interacción realízase só directamente, a través de conexións preformadas entre os nodos que participan na rede (a través das canles ADNL descritas anteriormente). A formación deste tipo de conexións entre veciños, a procura dos propios veciños, é un proceso automático que busca manter a conectividade da rede de superposición e minimizar os atrasos no intercambio de datos nela.
Ademais, hai unha forma de distribuír rapidamente grandes actualizacións de emisión dentro da rede: divídense en anacos, complétanse cun código de corrección de erros e todas estas pezas envíanse dun participante a outro. Así, o participante non ten que obter completamente todas as pezas antes de envialas máis lonxe pola rede.
As redes superpostas poden ser públicas ou privadas. Converterse en membro dunha rede pública non é difícil: cómpre atopar unha estrutura TL que a describa (pode ser pública ou accesible mediante unha determinada clave en DHT). No caso dunha rede privada, esta estrutura debe ser coñecida polo nodo previamente.
Continuar
Decidín dividir a revisión TON en varios artigos. Aquí é onde remata esta parte, e Paso a considerar a estrutura da cadea de bloques (máis precisamente, as cadeas de bloques) na que constará TON.
Fonte: www.habr.com