Já faz duas semanas que a Runet está agitada com o Telegram e a situação de seu bloqueio sem sentido e implacável pelo Roskomnadzor. Muitos foram afetados indiretamente, mas tudo isso são temas para posts no Geektimes. O que me surpreendeu foi que até agora eu não vi nenhuma análise na Habr sobre a rede TON - Telegram Open Network, que está programada para ser lançada. Quis preencher essa lacuna, pois há muito o que estudar lá - mesmo na ausência de declarações oficiais sobre o tema.
Só para relembrar - há rumores de que o Telegram lançou um ICO fechado muito amplo, já arrecadando quantias incríveis. Supõe-se que ainda este ano será lançada a própria criptomoeda Gram - e cada usuário do Telegram receberá automaticamente uma carteira, o que por si só cria uma grande vantagem em relação às outras criptomoedas.
Infelizmente, como não há declarações oficiais, a partir daqui só posso me basear em , sobre o que já o aviso de imediato. É claro que pode ser uma falsificação muito habilidosa, mas não se descarta a possibilidade de que este seja um verdadeiro whitepaper do futuro sistema, escrito por Nikolai Durov (e vazado, provavelmente, por alguém de seus investidores). Mas mesmo que seja uma farsa, ninguém nos proíbe de estudá-lo e discuti-lo, certo?
O que é dito neste documento? Tentarei resumir com minhas próprias palavras, próximo do texto, mas em português e de uma forma um pouco mais amigável (que Nikolai me perdoe por sua tendência a se aprofundar na matemática formal). Tenha em mente que mesmo se for autêntico, esta é uma descrição preliminar do sistema e é bastante provável que mude até o momento do lançamento público.
Descobrimos que, além da criptomoeda, muitos outros aspectos estão previstos. Vamos analisar isso em ordem.
- TON Blockchain. Esta é a base de todo o sistema. Se você não sabe o que é — recomendo que descubra, pois haverá muitos blockchains aqui. Aninhados uns dentro dos outros, virtualmente fragmentados e até mesmo blockchains "verticais" dentro dos blocos de outros blockchains. Além disso, haverá vários termos que soam legais, como Instant Hypercube Routing e Infinite Sharding Paradigm, mas falaremos sobre isso mais tarde. E, claro, proof-of-stake e contratos inteligentes.
- TON P2P Network. A rede peer-to-peer na qual se baseará o funcionamento do sistema. É sobre isso que falaremos principalmente nesta parte da narrativa.
- TON Storage. Um armazenamento de arquivos que, independentemente da blockchain, será construído na rede peer-to-peer mencionada acima. Pode ser comparado a torrents.
- TON Proxy. Este é um serviço cujo objetivo é aumentar a anonimato dos participantes da rede. Qualquer pacote pode ser enviado de forma indireta, através de túneis intermediários com criptografia adicional — semelhante ao I2P ou TOR.
- TON DHT. Uma tabela hash distribuída para armazenar valores arbitrários. Ela também é construída sobre TON Network (mas utilizando-o) e ajuda a TON Storage encontrar nós 'distribuidores', assim como TON Proxy os retransmissores intermediários. Mas é importante notar que, ao contrário da blockchain, esta tabela hash não é um armazenamento seguro — não se deve armazenar informações importantes nela.
- TON Services. Uma plataforma para serviços variados. Essencialmente, é uma nova internet sobre tudo que foi descrito anteriormente. A troca de dados ocorre através de TON Network/TON Proxy, enquanto a lógica está nos contratos inteligentes do próprio TON Blockchain. E a interface com URLs bastante familiares.
- TON DNS. Já que falamos sobre URLs familiares, também é necessário um conversor para os endereços de 256 bits — contas, contratos, serviços e nós.
- TON Payments. E é aqui que a questão financeira surge. E não será apenas gram — assim como com o Ethereum, qualquer 'token' será possível; os gramas aqui serão apenas a moeda 'padrão'.
Esta é a primeira parte, descrevendo o nível 'superficial' do TON — sua parte de rede, construída sobre protocolos tradicionais. Na próxima parte, falaremos sobre o 'miolo' — a blockchain que será suportada pelo sistema descrito a seguir. Assim, minha ordem de apresentação difere do sistema utilizado no documento mencionado acima (que começa imediatamente com o nível abstrato).
Conceitos Básicos
TL (Type Language). Este é um formato binário abstrato para estruturas de dados arbitrárias. É utilizado no protocolo do Telegram e será ativamente utilizado no TON. Se quiser conhecer os detalhes, .
Hash (hash). Uma função que realiza uma transformação irreversível de uma estrutura de dados arbitrária em um único número de comprimento fixo. No contexto da documentação, sempre se faz referência à função .
Nó da Rede (node). Um nó é um software que garantirá o funcionamento do sistema. Em particular, espera-se que cada aplicativo cliente do Telegram inclua um nó do TON. Em um nível baixo, os nós têm endereços IPv4/IPv6 e se comunicam usando o protocolo UDP; em um nível mais alto, eles possuem endereços abstratos e implementam o protocolo ADNL (sobre endereços abstratos e ADNL — veja abaixo). Quando se fala sobre partes do sistema que fazem algo ou armazenam dados, entende-se que isso é feito pelos nós da rede.
Endereço abstrato (ou apenas endereço, address). O endereço do nó é determinado por sua chave pública. Mais estritamente, é um hash de 256 bits (SHA256) da estrutura de dados que contém a chave pública (o algoritmo criptográfico específico não é especificado — como exemplo, são citadas curvas elípticas e RSA-2048). Para que um nó interaja com outro, ele precisa conhecer não apenas o endereço, mas também essa estrutura de dados. Teoricamente, um único nó físico pode criar qualquer número de endereços (correspondentes a diferentes chaves).
Normalmente, é usada exatamente essa combinação: uma ‘imagem’ na forma de uma estrutura TL (que pode conter praticamente qualquer dado) e um hash de 256 bits dela, utilizado para endereçamento.
Blockchain (blockchain). Blockchain é uma estrutura de dados cujos elementos (blocos) estão organizados em uma 'cadeia', e cada bloco subsequente da cadeia contém o hash do anterior. Dessa forma, alcança-se a integridade — as alterações só podem ser feitas pela adição de novos blocos.
Serviço (serviço). Os serviços dentro do TON podem ser de vários tipos — dependendo de usarem ou não blockchain. Por exemplo, um (ou vários) nós da rede pode processar certas solicitações RPC usando o protocolo ADNL descrito abaixo, sem criar registros na blockchain — semelhante a servidores web tradicionais. Também é considerada a possibilidade de implementar HTTP sobre ADNL, assim como a transição do próprio mensageiro para esse protocolo. Por analogia com o TOR ou I2P, isso o tornaria mais resistente a diversas restrições.
Ao mesmo tempo, vários serviços envolvem tanto a interação com a blockchain quanto o processamento de solicitações fora dela. Por exemplo, para o TON Storage — um armazenamento de arquivos — não é muito sensato armazenar os arquivos em si na blockchain. Apenas os hashes dos arquivos (junto com algumas metainformações sobre eles) estarão nela, enquanto nós especializados na rede servirão como "servidores de arquivos", prontos para entregá-los a outros nós via ADNL.
Serviço em Nuvem (serviço em nuvem). Refere-se a alguns serviços que envolvem descentralização e participação aberta. Por exemplo, o TON Proxy — é um serviço que qualquer participante pode apoiar, desejando fornecer seu nó como intermediário (proxy), retransmitindo pacotes entre outros nós. Se quiser, pode cobrar uma taxa fixa por isso — utilizando o sistema TON Payments para micropagamentos (que, por sua vez, também é um serviço em nuvem).
ADNL: Camada de Rede de Datagramas Abstratos
No nível mais baixo, a interação entre os nós será feita através do protocolo UDP (embora outras opções sejam permitidas).
Como mencionado acima, para que um nó possa enviar um pacote para outro, deve conhecer uma de suas chaves públicas (e, portanto, o endereço que ela define). Ele criptografa o pacote com essa chave e adiciona no início do pacote um endereço de 256 bits do destinatário — uma vez que um nó pode ter vários desses endereços, isso permitirá que ele determine qual chave usar para a descriptografia.
Além disso, em vez do endereço do destinatário, no início do pacote de dados pode haver um chamado identificador de canal. Nesse caso, o processamento do pacote já depende dos acordos específicos entre os nós — por exemplo, os dados enviados para um determinado canal podem ser destinados a outro nó e devem ser redirecionados para ele (este é o serviço TON Proxy). Outro caso especial pode ser a interação direta entre nós, mas com criptografia baseada em um par de chaves individual para esse canal (pré-formadas pelo protocolo Diffie-Hellman).
Finalmente, um caso especial é o canal ‘zero’ — se o nó ainda não conhece as chaves públicas de seus ‘vizinhos’, ele pode enviar pacotes a eles sem criptografia alguma. Isso é destinado apenas para a inicialização — assim que os nós enviarem informações sobre suas chaves, elas devem ser usadas para interação subsequente.
O protocolo descrito acima (256 bits para o identificador do canal + conteúdo do pacote) é chamado de ADNL. A documentação menciona a possibilidade de implementar um análogo do TCP sobre ele ou uma própria camada — RLDP (Reliable Large Datagram Protocol), mas não entra em detalhes sobre suas implementações.
TON DHT: Tabela hash distribuída
Assim como em outros sistemas distribuídos, o TON pressupõe a implementação de DHT — . De maneira mais específica — a tabela é Se você não está familiarizado com esse tipo de tabelas hash — não se preocupe, a seguir vou descrever aproximadamente como elas funcionam.
Em sentido abstrato, a DHT associa chaves de 256 bits a certos valores binários de comprimento arbitrário. Nesse caso, as chaves na tabela são hashes de uma determinada estrutura TL (as próprias estruturas também são armazenadas junto com a DHT). Isso se assemelha muito à formação de endereços de nós — e eles realmente podem estar presentes na DHT (por exemplo, por essa chave pode estar o endereço IP de um nó correspondente ao dado endereço abstrato, se ele não o ocultar). Mas, em geral, os “prototótipos das chaves” (seus descrições, key descriptions) são metadados que apontam para o “proprietário” do registro na tabela hash (ou seja, a chave pública de algum nó), o tipo de valor armazenado e as regras pelas quais esse registro pode ser posteriormente modificado. Por exemplo, uma regra pode permitir que apenas o proprietário altere o valor — ou proibir a diminuição do valor (para se proteger contra ataques de replay).
Além das chaves de 256 bits, introduz-se o conceito de endereços DHT. A diferença em relação aos endereços comuns de nós é que o endereço DHT deve estar necessariamente vinculado a um endereço IP. Se o nó não oculta seu IP, ele pode usar um endereço comum para DHT. Mas, com mais frequência, será criado um endereço separado, “semi-permanente”, para as necessidades da DHT.
Sobre as chaves e endereços DHT, introduz-se o conceito de distância — nisso tudo coincide com as tabelas A distância entre as chaves é igual ao XOR (OU exclusivo bit a bit) delas. Assim como nas tabelas Kademlia, o valor correspondente a uma chave deve ser armazenado em s nós que têm a menor distância a essa chave (s aqui — um número relativamente pequeno).
Para que um nó DHT possa interagir com outros nós semelhantes, ele mantém em memória uma tabela de roteamento DHT — endereços DHT e IP dos nós com os quais interagiu anteriormente, agrupados por distância até eles. Existem 256 grupos (que correspondem ao bit mais significativo no valor da distância — ou seja, nós a uma distância de 0 a 255 caem em um grupo, de 256 a 65535 — no próximo, e assim por diante). Dentro de cada grupo, um número limitado de 'melhores' nós é mantido (em termos de latência para eles).
Cada nó deve suportar várias operações: armazenamento de valor para uma chave, busca de nós e busca de valores. A busca de nós implica em retornar os nós mais próximos na tabela de roteamento de acordo com a chave fornecida; a busca de valores é a mesma coisa, exceto quando o nó já conhece o valor da chave (nesse caso, ele simplesmente o retorna). Portanto, se um nó quiser encontrar um valor DHT por meio de uma chave, ele envia solicitações a um pequeno número de nós mais próximos dessa chave em sua tabela de roteamento. Se entre suas respostas não houver o valor procurado, mas houver outros endereços de nós, a solicitação é repetida para eles.
O DHT do TON pode ser utilizado para diversos fins, como — para implementar um armazenamento de arquivos semelhante ao torrent (veja TON Storage); para determinar endereços de nós que implementam determinados serviços; para armazenar informações sobre proprietários de contas na blockchain. Mas a aplicação mais importante é a descoberta de nós por seus endereços abstratos. Para isso, o endereço é utilizado como chave, o valor que precisa ser encontrado. Como resultado da solicitação, ou o próprio nó será encontrado (se o endereço procurado era seu endereço DHT semi-permanente), ou o valor será o endereço IP e a porta para conexão — ou outro endereço que deve ser usado como um túnel intermediário.
Redes sobrepostas no TON
O protocolo ADNL descrito acima permite que quaisquer nós troquem informações entre si — embora não necessariamente pelos caminhos mais otimais. Pode-se afirmar que, graças ao ADNL, todos os nós formam um gráfico global do TON (idealmente — conexo). Além disso, é possível criar redes sobrepostas — subgrafos dentro desse gráfico.
Dentro de tal rede, a interação ocorre apenas diretamente — através de conexões previamente estabelecidas entre os nós participantes da rede (por meio dos canais ADNL, descritos acima). A formação de tais conexões entre vizinhos e a busca por esses vizinhos é um processo automático, que visa manter a conectividade da rede sobreposta e minimizar atrasos na troca de dados nela.
Além disso, há um método para disseminar rapidamente grandes atualizações de difusão dentro da rede — elas são divididas em partes, complementadas com códigos de correção de erros, e todos esses pedaços são enviados de um participante para outro. Assim, um participante não precisa receber todas as partes completamente antes de encaminhá-las adiante na rede.
As redes sobrepostas podem ser públicas ou privadas. Tornar-se um participante de uma rede pública não é difícil — é necessário encontrar a estrutura TL que a descreva (pode ser pública — ou acessível por uma chave específica no DHT). No caso de uma rede privada, essa estrutura deve ser conhecida pelo nó com antecedência.
Continua
Decidi dividir a análise do TON em vários artigos. Esta parte termina aqui, e eu passarei a discutir a estrutura da blockchain (mais especificamente, as blockchains) das quais o TON será composto.
Fonte: habr.com
