Rede aberta de telegrama: teoria e prática do validador de rede

Nos últimos meses, toda a atenção da comunidade mundial de blockchain foi atraída para o lançamento de um dos maiores projetos de criptomoeda - Telegram Open Network (TON).
Como é realmente o blockchain da TON? A rede TON é realmente descentralizada? Qual é a sua real escalabilidade? Como se tornar um validador de rede?

As respostas a essas e outras perguntas foram tentadas encontrar pela equipe do projeto Mercuryo , que participa ativamente da rede de testes desde o início de setembro de 2019.

Em 15 de novembro de 2019, os serviços do Telegram foram transferidos para o testnet 2 e a terceira fase do teste começou. Nossa equipe continuou a participar dos testes, tornando-se os primeiros validadores da rede após o TON.

Para participar do processo de validação, é necessário que o usuário não tenha apenas um número suficiente de moedas (tokens GRAM), mas também um nó de rede completo em execução constante (Nó Completo da TON Blockchain).

Teoricamente, qualquer usuário pode se tornar um validador sujeito à condição de possuir a parcela mínima necessária do ativo (em moedas de grama) na cadeia principal, mas, na prática, surgem várias perguntas que nossa equipe responderá neste artigo.

Além disso, queremos compartilhar experiências sobre o uso do tonlib-cli , como Atualmente, praticamente não há informações documentadas, ao contrário da versão básica descrita em detalhes no HowTo.

TON Blockchain

O principal componente da Telegram Open Network é um sistema flexível de blockchain, a seguir denominado TON Blockchain, que, segundo os próprios desenvolvedores, é capaz de processar milhões de transações por segundo, suportando Turing Complete Smart Contracts, especificações oficiais atualizadas de blockchain, transferências de várias moedas, bem como canais de micropagamentos para redes de pagamento fora da cadeia (fora da cadeia).

“A arquitetura TON Blockchain é única porque possui recursos específicos, como um mecanismo vertical de autocorreção e um Instant Hypercube Routing, que permite que o blockchain seja rápido, confiável escalável e sustentável ".

Como mencionado acima, TON Blockchain é o nome convencional para uma rede descentralizada (um conjunto de cadeias de blocos) ou uma cadeia de blocos 2D que consiste em três tipos principais de cadeias de blocos.

Master blockchain ou Masterchain é uma cadeia única de blocos que contém informações gerais sobre o protocolo e os valores atuais de seus parâmetros, um conjunto de validadores e suas ações, um conjunto de cadeias de trabalho atualmente ativas e seus "shards", além de um conjunto de hashes dos últimos blocos masterchains e shardchaynov.

Blockchains de trabalho ou Workchains - um conjunto (até 232) de blockchains que são "cavalos de trabalho" que contêm transações de transferência de ativos e contratos inteligentes. Ao mesmo tempo, cadeias de trabalho individuais podem ter suas próprias “regras”, formatos de endereço de conta, formatos de transação, várias máquinas virtuais (VMs) para contratos inteligentes, diferentes tokens ou criptomoedas etc. Mas todos eles devem satisfazer alguns critérios básicos de interoperabilidade para garantir uma interação relativamente simples entre si. Portanto, o Blockchain da TON é inerentemente heterogêneo, assim como as blockchains EOS e Polkadot.

Shard blockchains ou Shardchains - um subconjunto de blockchains (até 260) em um conjunto de cadeias de trabalho, garantindo a operação do sistema de sharding e tendo as mesmas regras e formato de bloco que as cadeias de trabalho. Os shardchains contêm apenas um subconjunto de contas, dependendo dos primeiros bits (mais significativos) do endereço de cada conta específica. Como todos os shardchains têm um formato e regras comuns para os blocos de construção, a blockchain TON a esse respeito é homogênea e atende aos requisitos descritos em uma das propostas de dimensionamento da Ethereum.



Cada bloco do shardchain (assim como o masterchain) na verdade não é apenas um bloco, mas uma pequena blockchain. Como regra geral, essa "blockchain blockchain" ou "blockchain vertical" consiste em exatamente um bloco, portanto, pode ser considerado apenas um bloco da blockchain "comum" correspondente (ou "cadeia horizontal de blocos"). No entanto, se for necessário corrigir blocos incorretos, um novo bloco é inserido na "cadeia vertical de blocos", contendo a substituição do bloco "horizontal" existente ou a "diferença de bloco", contendo apenas uma descrição das partes da versão anterior do bloco que precisam ser substituídas. Esse mecanismo específico da TON para substituir blocos inválidos detectados sem a necessidade de um hard fork é chamado de blockchain 2D ou simplesmente 2-blockchain.

Algoritmos de consenso e mecanismo de proteção de rede

A TON oferece uma blockchain baseada no Paradigma de Fragmento Infinito (Prova de Participação ou PoS). De acordo com a documentação do desenvolvedor:

“Quase todas as implementações de blockchains usando sharding são baseadas no modelo de cima para baixo: primeiro imaginamos uma blockchain e depois decidimos como dividi-la em várias partes interagindo umas com as outras (shardchains) para aumentar a eficiência e a escalabilidade.

A abordagem da TON ao sharding é baseada no princípio de baixo para cima, o que significa que o blockchain original é extremamente escalável e cada shardchain individual contém apenas uma conta ou contrato inteligente. No próximo nível, temos um grande número de "cadeias de contas", cada uma das quais descreve as transições entre os estados de apenas uma conta e envia mensagens contendo informações sobre transações. Ao mesmo tempo, é impraticável ter centenas de milhões de blockchains, atualizações (ou seja, novos blocos) em cada um deles aparecem muito raramente; portanto, para uma implementação mais eficaz, agrupamos essas "cadeias de contas" em "shardchains", cada bloco essencialmente é uma coleção de blocos de cadeias de contas que foram vinculadas a esse fragmento específico. Assim, “cadeias de contas” são na verdade apenas blocos lógicos ou virtuais dentro dos “shardchains” realmente existentes. Esse mecanismo lança luz sobre muitas das decisões de design do blockchain TON e chamamos de "Paradigma do Fragmento Infinito".

A rede de consenso da TON consiste em vários tipos de nós: validadores, nominadores, phishers e coletores.



Os validadores são nós PoS e fabricantes de blocos. Os pescadores monitoram a rede de consenso para encontrar um erro ou identificar um nó de consenso supostamente malicioso e, se o phisher confirmar inequivocamente que o nó é esse, recebe uma recompensa na forma de confisco de parte da parte desse validador.

A tarefa dos coletores é preparar blocos shardchain e fornecê-los para validação em nós PoS, para os quais eles recebem sua parte da recompensa por criar o bloco. Ao mesmo tempo, os coletores são essencialmente participantes adicionais no consenso, uma vez que os validadores quase sempre geram blocos por conta própria.

Os nomeadores emprestam seus ativos (tokens Gram ) aos validadores para obter lucro. De fato, os candidatos não são incluídos na infraestrutura dos validadores, mas apenas compartilham sua grande parte inicial do ativo entre eles em troca de uma porcentagem proporcional da remuneração total. Assim, o esquema e a quantia de remuneração que os indicados recebem dependem inteiramente dos resultados do trabalho dos validadores, enquanto os indicados “votam” nos validadores, emprestando-lhes tokens Gram. Os nomeados podem ser detentores de tokens individuais ou conjuntos que gerenciam os fundos de usuários individuais de TON e, ao mesmo tempo, atuam como validadores, atuando como delegados através do contrato inteligente de TON. Nesse caso, a remuneração total desse pool é distribuída entre seus participantes na proporção de suas contribuições.

O processo de geração de novos blocos é o seguinte: um certo número de validadores seleciona blocos de cadeia mestre (shards) adequados para validação usando um algoritmo especial; em seguida, um subconjunto menor de validadores é selecionado para cada um desses shard na ordem determinada de forma pseudo-aleatória, com um intervalo de aproximadamente a cada 1024 blocos.

Portanto, para cada bloco, existe um conjunto de validadores pseudo-aleatoriamente selecionados para determinar qual bloco candidato tem a maior prioridade. Validadores e outros nós verificam a validade dos candidatos ao bloco proposto. Se o validador assina automaticamente (não intencionalmente) um candidato inválido para os bloqueios, ele é punido com a perda de parte ou de toda a sua remuneração ou com a suspensão da participação na seleção de validadores por algum tempo.

Em seguida, os validadores precisam chegar a um consenso com base no algoritmo BFT (Protocolo de Resiliência Bizantino), semelhante ao protocolo pBFT ou Honey Badger BFT . Depois que o consenso é alcançado, um novo bloco é criado, enquanto as taxas de transação são distribuídas entre os validadores.

Note-se que cada validador pode ser selecionado para participar de vários subconjuntos de validadores; portanto, assume-se que todos os algoritmos de validação e consenso são executados em paralelo.

Depois que todos os novos blocos de shards da cadeia são gerados ou o tempo limite termina, aparece uma mensagem de que um novo bloco da cadeia principal foi criado, o que inclui hashes dos últimos blocos de todos os shards com base no consenso pBFT de todos os validadores.

TON Testnet: experiência prática na rede aberta do telegrama

A equipe do projeto Mercuryo participa ativamente da rede de testes desde setembro de 2019 e, durante o período de testes, adquirimos alguma experiência que gostaríamos de compartilhar com você.

Métodos de acesso à rede

A interação com a rede TON, de uma maneira ou de outra, se resume ao uso de especificações TL que descrevem como interagir com a API. Os arquivos de especificação estão disponíveis aqui .

Existem três tipos de APIs:

ton_api - para interagir com o validator-engine-console do Full Node
lite_api - para trabalhar com lite-client
tonlib - tudo sobre a carteira é coletado aqui e esta é a única API tonlib-cli disponível ao público

Criação de carteira

A maneira mais fácil de criar uma carteira é usar a Test Gram Wallet, disponível no site oficial dos sistemas operacionais Windows, macOS e Linux.




Existem também várias maneiras de interagir através da interface da linha de comandos: básica e usando tonlib-cli . Infelizmente, no momento não há compatibilidade entre eles.

Aqui consideraremos apenas as ferramentas que os próprios desenvolvedores da TON oferecem. Se a versão básica estiver documentada em detalhes no HowTo , as informações sobre o uso do tonlib-cli estarão praticamente ausentes.

Como mencionado acima, em TON existem três APIs para tarefas diferentes. As funções associadas à operação da carteira são responsáveis ​​pelo tonlib .

Para começar a trabalhar com o tonlib-cli , além da própria interface da linha de comandos, você deve ter um arquivo de configuração para conectar-se ao servidor de rede público da TON, disponível aqui .

A conexão é realizada pela equipe

tonlib-cli -c ton-lite-client-test1.config.json -v 0

onde -v 0 é o parâmetro responsável pela saída das informações de depuração.

Lista de comandos:

Para criar um endereço de carteira, use o comando genkey e uma lista de frases mnemônicas que podem ser necessárias para restaurar o acesso ao endereço em caso de perda da chave privada.

Lista de chaves

O comando keys exibe uma lista de chaves. Para operações adicionais ao executar outros comandos, é necessário usar o número de série, ou seja, para a primeira chave, haverá id 0 .

Inicialização de endereço

Depois de criar o endereço, ele deve ser registrado na rede. Para fazer isso, você deve primeiro reabastecer. Inicialmente, um contrato inteligente especial foi usado para isso - testgiver , mas agora é mais fácil e conveniente usar um bot especial no telegrama @test_ton_bot .

Imediatamente após o reabastecimento, o status da conta é definido como uninited_accountState e será alterado somente após o envio de tokens de teste GRM desse endereço.

Se você já possui tokens em sua balança e precisa ativar outra carteira, pode usar o comando transferf e, juntamente com o reabastecimento da carteira, ele será inicializado.



Você pode descobrir o status da carteira usando o comando getstate 0.



Obter histórico de transações usando o comando

gethistory <num_of_key>

onde <num_of_key> é o número de sequência da chave

Base de rede

Como na maioria das blockchains existentes, o TON é baseado em servidores que armazenam um histórico completo de todas as blockchains já criadas na rede.

Para executar um nó completo na rede de teste TON, 8 núcleos produtivos, 4-8 GB de RAM são suficientes, no momento da escrita, os dados ocupavam cerca de 50 GB de disco rígido, mas é melhor ter uma margem de pelo menos 100 GB. Note-se que é melhor usar uma unidade SSD, pois É necessário um grande número de IOPS para a gravação; caso contrário, a sincronização com a rede será muito lenta.

Como sistema operacional ativo, é melhor usar o Ubuntu 18.04, como a maioria dos testes da comunidade é realizada.

Guias de Instalação

README.txt
FullNode-HOWTO.txt
Validator-HOWTO.txt

Sistema validador

Sabe-se que a blockchain TON consiste em blocos shardchain e masterchain, que são criados e verificados por nós designados especiais chamados validadores. Os validadores recebem alguma recompensa por seu "trabalho": manter a saúde da blockchain TON, enquanto a renda é distribuída proporcionalmente dentro da comunidade de validadores.

À primeira vista, tudo está claro, mas, na prática, surgem várias questões relacionadas a isso:

• Existe uma restrição de rede no bife máximo do validador?

O limite do tamanho de um compartilhamento para um validador sempre pode ser verificado com o comando getconfig 17 , que mostrará os tamanhos reais dos bifes permitidos:



A captura de tela mostra que, no momento, o tamanho mínimo de compartilhamento é de 10.000 GRAM. No entanto, se um validador não recebe mais de 100.000 GRAM por uma rodada de votação, ele não tem direito a participar das eleições. Ao mesmo tempo, o número máximo de tokens por validador não pode exceder 10.000.000 GRAM e, para que a votação ocorra, o tamanho mínimo do bife total deve exceder 1.000.000 GRAM.

• Como os validadores são selecionados?

Para se candidatar à participação no processo de validação, você deve ter no mínimo 10.000 GRAM. O algoritmo do processo de eleição é descrito em detalhes no contrato inteligente elector-code.fc
Provavelmente, o contrato será diferente na rede principal, portanto a versão atual é aplicável apenas à rede de teste.

Uma parte de 10.000 GRAM não significa que você pode se tornar um validador, pois o recebimento de tokens de teste pode ser facilmente automatizado por solicitações ao testgiver .

No momento, quase todos os validadores, ao participar da votação, definem o fator máximo no valor de 2,7 e um bife no valor de 120.000 GRAM, uma vez que existem muitas apostas, devido ao seu peso, o bife mínimo sobe para 120.000 / 2,7 = 45.000 GRAM (diferentemente 100.000 de acordo com a documentação oficial). Mas mesmo com um bife tão mínimo, suas chances são quase nulas, pois os três principais validadores têm um fator máximo de 2, o que aumenta a participação mínima para 60.000 GRAM, o que permite que você se torne um validador na rede de teste.

Se todos os validadores atuais aumentassem seu fator máximo ou reduzissem o tamanho do bife, seria possível se tornar um validador com um bife mínimo, uma vez que o número máximo de validadores (1000 nós) não seria excedido.

• Se o sistema validador estiver centralizado, todo o blockchain também?

Não há verificações, ou seja, ninguém controla centralmente os validadores; os próprios nominadores determinam os riscos ao escolher um validador.

• Que tipos de multas são fornecidas aos validadores?

Não há informações no momento, provavelmente haverá um mecanismo de consenso no documento, porque mesmo os nós fora de sincronia receberam prêmios na rede de teste.

• Contratos inteligentes

Para criar contratos inteligentes de TON, duas linguagens de programação especiais são usadas: Fift e FunC . Se o Fift tiver pelo menos documentação geral, é quase impossível encontrar informações sobre o FunC (mesmo nas condições de um concurso de desenvolvimento , é indicado que ele só pode ser obtido analisando seu código-fonte).

Durante o teste, foi possível descobrir que a base de código do FunC não é tão volumosa (em comparação com o Fift ) e permite que você o aprenda muito mais rapidamente, portanto, trabalhar com o FunC é muito mais fácil do que com o Fift .

• Perguntas reais / urgentes / abertas

Sincronização lenta
https://github.com/ton-blockchain/ton/issues/100

Permissões para mecanismo de validação
+0 = consultas usuais de lite-client
+1 = consultas estatísticas completas do nó
+2 = consultas de modificação de configuração de código completo
+4 = consultas potencialmente perigosas (como exportação de chave privada ou assinatura de cadeias arbitrárias)
+8 = reservado para extensões futuras (não faz nada no momento)

• Como fazer o PIPE funcionar com lite-client?

Por padrão, a saída lite-client é enviada ao stderr; portanto, para processá-lo, você deve primeiro redirecionar a saída do stderr para o stdout:

$ lite-client 2 >> (grep ...)

• Quais são as opções para acesso programático à rede?

https://github.com/ton-blockchain/ton/issues/76

• Qual configuração de servidor é necessária para o validador?

O uso de um servidor com processador duplo é oficialmente recomendado (pelo menos 8 núcleos por processador). O software não é muito exigente em RAM, então 16 GB é suficiente. Você deve usar um SSD como unidade principal, cujo tamanho mínimo recomendado é 512 GB. Um disco rígido de 8 TB é suficiente para armazenar dados arquivados.

É essencial que você tenha uma conexão à Internet de alta velocidade: com uma carga média prevista de 100 Mbit / s, você deve poder lidar com cargas de pico de até 1 Gbit / s.

É recomendável usar o XFS como sistema de arquivos, pois as informações sobre cada bloco são armazenadas em um arquivo separado. Sabe-se que, por exemplo, o ext4 não funciona muito bem com um grande número de arquivos pequenos e pode levar a uma situação em que você simplesmente não possui inodes livres com espaço em disco suficiente.

• Como sei que um nó está sincronizado?

O log concluirá a mensagem de sincronização ou o uso do validator-engine-console -c "getstats" unixtime e o masterchainblocktime devem ser quase os mesmos.

• Quantos validadores podem estar online?

Getconfig 16
max_validators: 1000 max_main_validators: 100 min_validators: 5

• Como descobrir os validadores ativos atuais?

Getconfig 34

Conjunto de validadores getconfig 32 anterior

• Hora em que validadores são selecionados?

O whitepaper indica que os validadores são selecionados por um mês, mas no testnet esse tempo é muito menor e você pode descobrir isso na configuração do getconfig 15.

Após reiniciar o testnet, os intervalos de tempo para os validadores foram alterados:

ConfigParam (15) = (validators_elected_for: 65536 eleições_start_before: 32768 eleições_end_before: 8192 stake_held_for: 32768)

A partir do qual se conclui que um grupo de validadores é selecionado por 65536 segundos.

• ?

Validator-HOWTO . -, getconfig 1 . .



result: [ 0 ], , timestamp, . , :

> runmethod -1:A4C2C7C05B093D470DE2316DBA089FA0DD775FD9B1EBFC9DC9D04B498D3A2DDA participant_list

• TON?

Apesar do design complexo da pilha de rede baseada em redes de sobreposição, o UDP e o TCP ainda são usados ​​como protocolos de transporte TON. Sabe-se que hoje os bloqueios de telegrama não são bem-sucedidos, porque É possível alterar endereços IP, usar proxies e atualizar configurações por push. No entanto, a TON não terá essas oportunidades: não é possível mover os nós rapidamente, enquanto os validadores não desejam arriscar suas ações. Portanto, provavelmente, em um futuro próximo, os desenvolvedores do Telegram introduzirão novas soluções para ignorar bloqueios, por exemplo, usando o ADNL Proxy.

Abaixo está o tráfego de um nó completo após o processamento de 10 milhões de pacotes. Uma lista de 159 endereços IP executando nós de rede de teste completos é a seguinte:

126 DIGITAL OCEAN ( TON)
13 AMAZON
4 GOOGLE
3 HETZNER
3 ALIBABA CLOUD
2 OVH
2 SELECTEL
2 ONLINE.NET
1 LINODE
1 hosteurope.de
1 contabo.de
and 1 person possibly hosting it at home in Italy telecomitalia.it

IP- . , TON, -.

, Telegram Open Network WEB 3.0 , Telegram.

TON , « », . , :

• , ;
• - (Fift FunC), ;
• , ;
• telegram-, TON;

TON

(Infinite Sharding Paradigm) , , .. , , , , , , . TON , « » . , , TON .

, , TON , , « » , , , .

, , TON ( Gram). , , , TON PoS, , -.

PoS . , - , PoS , . PoS, , . , PoS , .

Grams Wallet — Gram

- TON Grams Wallet , Telegram, - , Telegram FZ-LLC ( ).

, , , , , 18 , , , , Telegram FZ-LLC .

, , (. Linux). , (. 4, . 4.3), , Telegram Open Network:

« TON Blockchain ».

Our open source

Go-binding library

, TON TONLIB.

Mercuryo Go, , -, .
https://github.com/mercuryoio/tonlib-go

tonlib api , , :

• (//// );
• /gram/boc- ;
• Obtendo o status da carteira e informações sobre ela;
• Obtendo uma lista de transações por carteira;
• Tongo é um utilitário de carteira leve;

Atualmente, as prioridades no desenvolvimento da biblioteca são:

• Monitoramento de rede. A capacidade de receber informações sobre cada transação de todos os blocos de rede. Estamos realmente ansiosos para apoiar o próprio tonlib;
• Interações com contratos. O trabalho já está em andamento;
• Estendendo a funcionalidade do assistente do console tongo. Estamos tentando adicionar algo novo a cada versão;
• Geração de estruturas de interface conforme especificação tl. Isso nos permitirá ser mais móveis e lançar atualizações com atrasos mínimos;

Continuaremos uma série de posts sobre o teste da Rede Aberta do Telegrama, da Carteira Grams e compartilharemos nossas observações.