Introdução: Depois que a Binance lançou o Notcoin, o maior jogo do ecossistema TON, e sua economia de tokens totalmente circulante criou um enorme efeito de riqueza, TON rapidamente ganhou muita atenção. Conversando com amigos, descobri que TON tem uma alta barreira técnica e seu modelo de desenvolvimento DApp é muito diferente dos protocolos blockchain convencionais. Então, passei algum tempo pesquisando este tópico em profundidade e tenho alguns insights para compartilhar com você. Em curto, a filosofia central de design da TON é reconstruir os protocolos tradicionais de blockchain a partir do zero, concentrando-se em alcançar alta simultaneidade e escalabilidade, mesmo que isso signifique sacrificar a interoperabilidade.

TON's Core Design Principles - High Concurrency and Scalability

Pode-se dizer que o objetivo de todas as seleções tecnológicas complexas em TON vem da busca de alta simultaneidade e alta escalabilidade. É claro que não é difícil para nós entender isso desde o contexto de seu nascimento. TON, ou The Open Network, é uma rede de computação descentralizada que inclui um blockchain L1 e vários componentes. TON foi originalmente desenvolvido pelo fundador do Telegram, Nikolai Durov, e sua equipe, e agora é apoiado e mantido por uma comunidade global de colaboradores independentes. Seu nascimento remonta a 2017, quando a equipe do Telegram começou a explorar soluções de blockchain para si mesma. Como nenhum blockchain L1 existente na época poderia suporte a base de usuários de nove dígitos do Telegram, eles decidiram projetar seu próprio blockchain, então chamado Telegram Open Network. A hora chegou em 2018. Em ordem de obter os recursos necessários para implementar TON, o Telegram lançou uma venda de tokens Gram (mais tarde renomeados Toncoin) no primeiro trimestre de 2018. Em 2020, a equipe do Telegram se retirou do projeto TON devido a questões regulatórias. Posteriormente, um pequeno grupo de desenvolvedores de código aberto e vencedores da competição do Telegram assumiu a base de código da TON, renomeou o projeto para The Open Network e continua a desenvolver ativamente o blockchain até hoje, aderindo aos princípios descritos no white paper original do TON.

Como TON foi projetado para ser o ambiente de execução descentralizada do Telegram, ele teve que lidar com dois desafios principais: altas solicitações simultâneas e dados massivos. Mesmo o maior TPS testado (transações por segundo) de Solana, que afirma ser o mais rápido, é de apenas 65.000, muito curto do nível de milhões de TPS necessário para o Telegram. Além disso, a enorme quantidade de dados gerados pelo Telegram não pode ser gerenciada por um blockchain onde cada nó armazena uma cópia completa dos dados.

Para enfrentar esses desafios, TON otimizou os principais protocolos de blockchain de duas maneiras:

l Ele usa um "Paradigma de Fragmentação Infinito" para reduzir a redundância de dados, permitindo lidar com grandes quantidades de dados e aliviar gargalos de desempenho.

l Ao introduzir um ambiente de execução totalmente paralelo baseado no modelo Ator, a TPS da rede é consideravelmente melhorada;

Building a Blockchain of Chains - Providing Each Account with its Own Dedicated Chain Through Infinite Fragmentação Agora

sabemos que o sharding se tornou a solução mainstream para a maioria dos protocolos de blockchain para melhorar o desempenho e reduzir custos, e TON levou isso ao extremo e propôs o paradigma de fragmentação infinita, o chamado paradigma de fragmentação infinita. Refere-se a permitir que o blockchain aumente ou diminua dinamicamente o número de fragmentos com base na carga da rede. Esse paradigma permite que TON lide com transações em grande escala e operações de contratos inteligentes, mantendo o alto desempenho. Em teoria, TON podem estabelecer uma cadeia de conta exclusiva para cada conta e garantir a interoperabilidade entre essas cadeias através de determinadas regras. coerência,

Em essência, a estrutura da cadeia de TON consiste em quatro camadas

AccountChain: Esta camada representa uma série de transações vinculadas a um conta específico. As transações formam uma cadeia porque, em uma máquina de estado, regras de execução consistentes garantem que a máquina de estado produza os mesmos resultados ao processar instruções no mesmo ordem. Portanto, todos os sistemas de blockchain exigem que as transações sejam vinculadas em uma cadeia, e TON não é diferente. A AccountChain é a unidade mais fundamental da rede TON. Normalmente, o AccountChain é um conceito virtual, e é improvável que exista um AccountChain independente.

ShardChain: Na maioria dos contextos, o ShardChain é a unidade real dentro TON. Um ShardChain é essencialmente uma coleção de AccountChains.

WorkChain: também conhecido como um conjunto de cadeias de estilhaços com regras personalizadas, como a criação de uma WorkChain com base no EVM de executar o Solidity contratos inteligentes. Em teoria, qualquer pessoa na comunidade pode criar sua própria WorkChain. No entanto, a construção de um é bastante complexa e requer o pagamento da (alta) taxa de criação e obtenção de aprovação de 2/3 do validadores.

MasterChain: Em TON, existe uma cadeia única chamada MasterChain, que fornece finalidade para todas as cadeias de fragmentos. Quando o valor hash de um bloco Shard Chain é incluído em um bloco MasterChain, esse bloco Shard Chain e todos os seus blocos pai são considerados finais, o que significa que são fixos e imutáveis, referenciados por todos os blocos Shard Chain subsequentes.

Este paradigma confere à rede TON três características principais:

Fragmentação dinâmico: TON pode dividir e mesclar automaticamente cadeias de estilhaços para se adaptar às mudanças de carga, garantindo que novos blocos sejam gerados rapidamente e que as transações não sofram atrasos longo.

Alta escalabilidade: Com seu paradigma de fragmentação infinita, TON pode suporte quase um número ilimitado de fragmentos, teoricamente até 2^60 WorkChains.

Adaptabilidade: Quando parte da rede experimenta maior carga, ela pode se subdividir em mais fragmentos para lidar com a maior volume de transação. Por outro lado, quando a carga diminui, os fragmentos podem se fundir para melhorar a eficiência.

Num sistema multi-cadeia como este, o principal desafio é cadeia cruzada comunicação. Com a capacidade de fragmentação infinita, quando o número de fragmentos na rede cresce significativamente, o roteamento de informações entre cadeias torna-se complexo. Por exemplo, imagine uma rede com quatro nós, cada um mantendo uma WorkChain independente. Cada nó, além de gerenciar sua própria classificação de transações, também deve monitorar e processar mudanças de estado em outras cadeias. Além TON, isso é feito monitorando mensagens na fila de saída.

Suponha que a Conta A no WorkChain 1 queira enviar uma mensagem para a Conta C no WorkChain 3. Isso requer a criação de uma solução de roteamento de mensagens. Neste exemplo, há dois caminhos de roteamento: WorkChain 1 -> WorkChain 2 -> WorkChain 3 e WorkChain 1 -> WorkChain 4 -> WorkChain 3.

Em cenários mais complexos, um algoritmo de roteamento eficiente e de baixo custo é necessário para uma comunicação rápida de mensagens. TON usa o "algoritmo de roteamento de hipercubo" para cadeia cruzada descoberta de roteamento de mensagens. Uma estrutura de hipercubo é uma topologia de rede especial onde um hipercubo n-dimensional tem 2^n vértices, cada um identificado exclusivamente por um número binário n-bit. Nesta estrutura, quaisquer dois vértices são adjacentes se suas representações binárias diferem por apenas um bit. Por exemplo, em um hipercubo de 3 dimensões, o vértice 000 e o vértice 001 são adjacentes porque diferem apenas no último bit. O exemplo acima é um hipercubo de 2 dimensões.

No protocolo de roteamento de hipercubo, o roteamento de uma mensagem da WorkChain de origem para a WorkChain de destino é feito comparando seus endereços binários. O algoritmo encontra a distância mínima entre esses endereços (ou seja, o número de bits diferentes) e encaminha a mensagem através de WorkChains adjacentes até chegar ao seu destino. Isso garante que o pacote de dados siga o caminho mais curto, aumentando a eficiência da comunicação de rede. Para simplificar esse processo, a TON também oferece uma solução otimista. Se um usuário puder fornecer uma prova válida de um caminho de roteamento, normalmente uma raiz Merkle trie, o nó poderá verificar imediatamente a autenticidade da mensagem. Isso é conhecido como roteamento instantâneo de hipercubo. Como resultado, TON endereços diferem significativamente daqueles em outros protocolos blockchain. A maioria dos protocolos blockchain usa o hash de uma chave pública gerada por algoritmos de encriptação elíptica como um endereço, focando na exclusividade sem precisar de funções de roteamento. Em TON, os endereços consistem em duas partes: (workchain_id, conta_id), com workchain_id codificados de acordo com o algoritmo de roteamento do hipercubo. Pode-se perguntar por que não transmitir todas as informações cadeia cruzada através da MasterChain, semelhante ao Cosmos. No projeto de TON, o MasterChain lida apenas com a tarefa mais crítica de manter a finalidade das WorkChains. Embora seja possível encaminhar mensagens através da MasterChain, as taxas associadas seriam proibitivamente altas.

Finalmente, vamos discutir brevemente seu algoritmo de consenso. TON emprega uma combinação de BFT (Falha Bizantina Tolerância) e PoS (Prova de Staking). Isso significa que qualquer staker pode participar da criação de blocos. O contrato de governança eleitoral TON seleciona periodicamente um grupo de validadores aleatoriamente de todos os interessados. Esses validadores selecionados usam o algoritmo BFT para criar blocos. Se um validador criar blocos inválidos ou agir maliciosamente, seus tokens apostados serão confiscados. Por outro lado, eles recebem recompensas por criarem blocos válidos com sucesso. Este método é bastante comum, por isso não entraremos em mais detalhes aqui.

Contratos inteligentes utilizando o modelo Ator dentro de um ambiente de execução totalmente paralelo

Outra diferença fundamental no TON em comparação com os protocolos blockchain convencionais é seu ambiente de execução de contrato inteligente. Para superar as limitações de TPS enfrentadas pelos principais protocolos blockchain, a TON usa uma abordagem de design de baixo para cima e emprega o modelo Ator para reconstruir contratos inteligentes e sua execução, permitindo capacidades de execução totalmente paralelas.

A maioria dos principais protocolos de blockchain usa um ambiente de execução serial de thread único. Por exemplo, o ambiente de execução do Ethereum, o EVM, opera como uma máquina de estado que processa transações sequencialmente. Depois que um bloco é formado e as transações são ordenadas, elas são executadas uma a uma através do EVM. Este processo inteiramente serial, single-threaded, significa que apenas uma transação é processada a qualquer momento. A vantagem é que, uma vez que o ordem de transação é estabelecido, os resultados de execução permanecem consistentes em uma rede distribuída. Além disso, como apenas uma transação é executada por vez, nenhuma outra transação pode alterar os dados de estado que estão sendo acessados, garantindo a interoperabilidade entre contratos inteligentes. Por exemplo, ao usar Uniswap para comprar ETH com USDT, a distribuição do pool de liquidez é um valor fixo durante a execução. Isso permite que modelos matemáticos determinem o resultado exato. Inversamente, se outros fornecedores de liquidez acrescentassem liquidez durante o cálculo curva de ligação, os resultados estariam desatualizados, o que é claramente inaceitável.

No entanto, esta arquitetura também tem limitações claras, particularmente o gargalo TPS, que parece ultrapassado com os modernos processadores multi-core. É semelhante a jogar jogos de computador antigos como Red Alert em um PC novo; Quando o número de unidades de combate atinge um certo nível, você ainda encontra um atraso significativo. Isto deve-se a problemas de arquitetura de software.

Alguns protocolos estão a abordar este problema e propuseram as suas próprias soluções paralelas. Por exemplo, Solana, que afirma ter o maior TPS, também suporta execução paralela. No entanto, o design de Solana difere do de TON. A ideia central do Solana é agrupar todas as transações com base em suas dependências de execução, garantindo que diferentes grupos não compartilhem dados de estado. Isso significa que não há dependências compartilhadas, permitindo que transações em diferentes grupos sejam executadas em paralelo sem conflito. As transações dentro do mesmo grupo ainda são executadas em série.

Em contraste, TON abandona completamente a arquitetura de execução serial e adota um paradigma de desenvolvimento projetado especificamente para paralelismo, usando o modelo Ator para reconstruir seu ambiente de execução. O modelo Ator, proposto pela primeira vez por Carl Hewitt em 1973, visa resolver a complexidade dos estados partilhados em programas concorrentes tradicionais através da passagem de mensagens. Cada Ator tem seu próprio estado privado e comportamento e não compartilha informações de estado com outros Atores. O modelo Ator é um modelo de computação simultaneidade que alcança o processamento paralelo através da passagem de mensagens. Neste modelo, um "Ator" é uma unidade básica que pode lidar com mensagens recebidas, criar novos Atores, enviar mensagens adicionais e decidir como responder às mensagens subsequentes. O modelo Ator deve ter as seguintes características:

Encapsulamento e independência: Cada ator opera de forma completamente independente ao processar mensagens, permitindo o processamento paralelo de mensagens sem interferência.

Passagem de mensagens: os atores interagem apenas através do envio e recebimento de mensagens, sendo a passagem de mensagens assíncrona.

Estrutura dinâmica: Os atores podem criar atores adicionais em tempo de execução, permitindo que o modelo de ator expanda dinamicamente o sistema conforme necessário.

TON adota essa arquitetura para seu modelo de contrato inteligente, o que significa que cada contrato inteligente no TON é baseado no modelo Ator e tem armazenamento completamente independente porque não depende de nenhum dado externo. Além disso, as chamadas para o mesmo contrato inteligente são executadas no ordem de mensagens na fila de recebimento. Isso permite que as transações em TON sejam executadas em paralelo de forma eficiente, sem preocupações com conflitos. No entanto, este design também introduz alguns novos desafios. Para DApp desenvolvedores, seu paradigma de desenvolvimento familiar será interrompido das seguintes maneiras:

1. Chamadas Contrato inteligente assíncronas: TON, é impossível chamar atomicamente contratos externos ou acessar dados de contratos externos dentro contratos inteligentes. No Solidity, por exemplo, é simples para a função do Contrato A1 chamar a função do Contrato B2 ou acessar certos dados de estado através da função somente leitura do Contrato C3, tudo em uma única transação. No entanto, em TON, isso não pode ser alcançado. Qualquer interação com contratos inteligentes externos será executada de forma assíncrona, criando novas transações, chamadas de mensagens internas iniciadas por contratos inteligentes. O processo de execução não pode ser bloqueado para aguardar o resultado.

Por exemplo, se estamos desenvolvendo um DEX e seguimos o paradigma de EVM comum, normalmente temos um contrato de roteador unificado para gerenciar o roteamento de transações, enquanto cada pool gerencia independentemente os dados LP para pares de negociação específicos. Digamos que temos duas piscinas: USDT-DAI e DAI-ETH. Quando um usuário deseja comprar ETH diretamente com USDT, ele pode usar o contrato do roteador para interagir sequencialmente com esses dois pools em uma única transação atômica. No entanto, em TON, este processo não é tão simples e requer uma abordagem de desenvolvimento diferente. Se tentarmos reutilizar este paradigma EVM, o fluxo de informação envolveria uma mensagem externa iniciada pelo utilizador e três mensagens internas para concluir a transação (note-se que este exemplo é para destacar as diferenças; no desenvolvimento real, até o paradigma ERC20 precisaria ser redesenhado).

1. É necessária uma consideração cuidadosa para o tratamento de erros em chamadas entre contratos, projetando funções de rejeição apropriadas para cada interação entre contratos. Nos sistemas EVM tradicionais, se ocorrer um erro durante a execução da transação, toda a transação será revertida para seu estado inicial. Isso é simples em um modelo de thread único serial. No entanto, em TON, como as chamadas entre contratos são executadas de forma assíncrona, se ocorrer um erro em um estágio posterior, as transações executadas com êxito anteriormente já foram confirmadas, potencialmente causando problemas. Portanto, TON introduziu um tipo de mensagem especial chamado mensagem de devolução. Se ocorrer um erro na execução subsequente de uma mensagem interna, o contrato acionado pode usar a função de rejeição reservada no contrato de acionamento para redefinir determinados estados no contrato de acionamento.

2. Em cenários complexos, as transações recebidas primeiro podem não ser concluídas primeiro, portanto, você não pode assumir um ordem de execução específico. Em um sistema de contrato inteligente assíncrono e paralelo, definir a ordem de processamento pode ser um desafio. É por isso que cada mensagem em TON tem seu tempo lógico, conhecido como tempo de Lamport (lt). Ele ajuda a determinar qual evento desencadeou outro e o que validadores precisa processar primeiro. Em um modelo simples, as transações recebidas primeiro são executadas primeiro.

Neste modelo, A e B representam duas contratos inteligentes. Se msg1_lt < msg2_lt, então tx1_lt < tx2_lt em termos de sequência.

No entanto, em situações mais complexas, essa regra pode ser quebrada. A documentação oficial fornece um exemplo: suponha que temos três contratos, A, B e C. Em uma transação, A envia duas mensagens internas, msg1 e msg2, uma para B e outra para C. Embora eles sejam criados em um ordem específico (msg1 primeiro, depois msg2), não podemos ter certeza de que msg1 será processado antes de msg2. Esta incerteza surge porque as rotas de A para B e de A para C podem diferir em comprimento e conjuntos de validadores. Se esses contratos estiverem em cadeias de estilhaços diferentes, uma mensagem pode levar vários blocos para chegar ao contrato de destino. Portanto, há dois caminhos de transação possíveis, conforme ilustrado.

1. Em TON, o armazenamento persistente para contratos inteligentes usa uma estrutura gráfico acíclico dirigido (DAG) com células como unidades. Os dados são compactados em uma célula de acordo com regras de codificação específicas e se estendem para baixo de uma maneira DAG. Isso contrasta com a estrutura baseada em hashmap usada em EVM para dados de estado. Devido aos diferentes algoritmos de acesso a dados, TON atribui preços de gás variáveis para o processamento de dados em diferentes profundidades; O processamento mais profundo de dados celulares requer mais gás. Consequentemente, TON enfrenta um tipo de ataque DOS, onde usuários mal-intencionados inundam um contrato inteligente com um grande número de mensagens indesejadas, preenchendo todas as células superficiais. Isso aumenta os custos de armazenamento para usuários honestos. Em contraste, o hashmap do EVM tem uma complexidade de consulta de O(1), garantindo custos de gás consistentes e evitando problemas semelhantes. Portanto, os desenvolvedores do TON Dapp devem evitar o uso de tipos de dados não limitados no contratos inteligentes. Quando tipos de dados não limitados são necessários, eles devem ser particionados usando fragmentação.

1. Algumas características são menos exclusivas, como a exigência de contratos inteligentes pagar aluguel pelo armazenamento. Além TON, contratos inteligentes são inerentemente atualizáveis e vêm com funções conta abstratas nativas, o que significa que todos os endereços de carteira em TON são contratos inteligentes, apenas não inicializados. Os desenvolvedores precisam prestar muita atenção a esses aspetos.

Declaração de exoneração de responsabilidade:

1. Este artigo foi reproduzido a partir de [Theblockbeats]. Todos os direitos autorais pertencem ao autor original [Web3Mario]. Se houver objeções a essa reimpressão, entre em contato com a equipe Gate Learn e eles lidarão com isso imediatamente.
2. Isenção de Responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.