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 um tempo pesquisando esse tema a fundo e tenho alguns insights para compartilhar com vocês. Além curto, a principal filosofia de design da TON é reconstruir os protocolos tradicionais de blockchain do zero, com foco 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 propósito de todas as seleções de tecnologia complexas em TON vem da busca de alta simultaneidade e alta escalabilidade. É claro que não é difícil para nós entender isso a partir do pano de fundo 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 mesmos. Como nenhum blockchain L1 existente na época poderia apoiar a base de usuários de nove dígitos do Telegram, eles decidiram projetar seu próprio blockchain, então chamado de 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 rebatizados de 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 assumiram a base de código de TON, renomearam o projeto para The Open Network e continuam a desenvolver ativamente o blockchain até hoje, aderindo aos princípios descritos no white paper original 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 TPS (transações por segundo) mais alto testado de Solana, que afirma ser o mais rápido, é de apenas 65.000, muito curto do TPS de nível de milhão 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, a TON otimizou os principais protocolos de blockchain de duas maneiras:

l Ele usa um "Infinite Fragmentação Paradigm" 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 Actor, a TPS de rede é muito melhorada;

Construindo uma Blockchain de cadeias - fornecendo a cada conta sua própria cadeia dedicada através de Fragmentação infinitos

Agora sabemos que o sharding se tornou a solução mainstream para a maioria dos protocolos 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 lidem com transações em grande escala e operações de contratos inteligentes, mantendo o alto desempenho. Em teoria, TON pode estabelecer uma cadeia de conta exclusiva para cada conta e garantir a interoperabilidade entre essas cadeias por meio de certas regras. consistência

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

AccountChain: Essa 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 na mesma ordem. Portanto, todos os sistemas blockchain exigem que as transações estejam ligadas 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 fragmentos com regras personalizadas, como a criação de um WorkChain com base no EVM para executar o Solidity contratos inteligentes. Em teoria, qualquer pessoa na comunidade pode criar sua própria WorkChain. No entanto, construir um é bastante complexo e requer o pagamento da (alta) taxa de criação e a obtenção da aprovação de 2/3 dos validadores.

MasterChain: Em TON, existe uma cadeia única chamada MasterChain, que fornece finalidade a todas as cadeias de fragmentos. Quando o valor cerquilha de um bloco cadeia de fragmentos é incluído em um bloco MasterChain, esse bloco cadeia de fragmentos 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 cadeia de fragmentos subsequentes.

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

Fragmentação dinâmico: TON pode dividir e mesclar cadeias de fragmentos automaticamente 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 apoiar um número quase ilimitado de fragmentos, teoricamente até 2^60 WorkChains.

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

Em um sistema multi-chain 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 se torna 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 alterações de estado em outras cadeias. Além TON, isso é feito monitorando as 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 de 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 tridimensional, o vértice 000 e o vértice 001 são adjacentes porque diferem apenas no último bit. O exemplo acima é um hipercubo 2-dimensional.

No protocolo de roteamento do hipercubo, o roteamento de uma mensagem do WorkChain de origem para o WorkChain de destino é feito comparando seus endereços binários. O algoritmo localiza 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 de tentativa Merkle, o nó poderá verificar imediatamente a autenticidade da mensagem. Isso é conhecido como roteamento instantâneo de hipercubo. Como resultado, os endereços TON diferem significativamente daqueles em outros protocolos blockchain. A maioria dos protocolos blockchain usa o cerquilha de uma chave pública gerada por algoritmos de criptografia elípticos como um endereço, com foco 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. Alguém pode se perguntar por que não retransmitir todas as informações cadeia cruzada através do MasterChain, semelhante ao Cosmos. No design de TON, o MasterChain lida apenas com a tarefa mais crítica de manter a finalidade das WorkChains. Embora seja possível rotear mensagens através do 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 (Proof of Stake). 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 todas as partes interessadas. 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 criar blocos válidos com sucesso. Esse método é bastante comum, então não entraremos em mais detalhes aqui.

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

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

A maioria dos protocolos de blockchain convencionais 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. Esse processo totalmente serial, de thread único, significa que apenas uma transação é processada em um determinado momento. A vantagem é que, uma vez que o ordem da transação é estabelecido, os resultados da 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 o 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. Por outro lado, se outros fornecedores de liquidez adicionassem liquidez durante o cálculo do curva de ligação, os resultados estariam desatualizados, o que é claramente inaceitável.

No entanto, essa arquitetura também tem limitações claras, particularmente o gargalo TPS, que parece desatualizado com os processadores multi-core modernos. É 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. Isso se deve a problemas de arquitetura de software.

Alguns protocolos estão abordando esse problema e propuseram suas próprias soluções paralelas. Por exemplo, Solana, que afirma ter o TPS mais alto, também oferece suporte à 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 conflitos. 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 Actor para reconstruir seu ambiente de execução. O modelo Actor, proposto pela primeira vez por Carl Hewitt em 1973, visa resolver a complexidade dos estados compartilhados em programas concorrentes tradicionais através da transmissão de mensagens. Cada Ator tem seu próprio estado e comportamento privado e não compartilha informações estatais com outros Atores. O modelo Actor é um modelo de computação de simultaneidade que alcança processamento paralelo através da passagem de mensagens. Nesse modelo, um "Ator" é uma unidade básica que pode lidar com mensagens recebidas, criar novos Atores, enviar mensagens adicionais e decidir como responder a 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.

Transmissão de mensagens: os atores interagem exclusivamente por meio do envio e recebimento de mensagens, sendo a transmissão 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 em 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 de Contrato inteligente assíncronas: Na 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 por meio 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 por meio da criação de 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 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, esse processo não é tão simples e requer uma abordagem de desenvolvimento diferente. Se tentarmos reutilizar esse paradigma EVM, o fluxo de informações envolveria uma mensagem externa iniciada pelo usuário e três mensagens internas para concluir a transação (note que este exemplo é para destacar as diferenças; no desenvolvimento real, até mesmo 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. Em sistemas EVM convencionais, 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 serial de thread único. 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 anteriormente com êxito 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 poderá usar a função de devolução reservada no contrato de disparo para redefinir determinados estados no contrato de disparo.

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 o 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.

Nesse modelo, A e B representam dois 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 dá um exemplo: suponhamos que tenhamos 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 msg2. Essa incerteza surge porque as rotas de A a B e de A a C podem diferir em comprimento e conjuntos de validadores. Se esses contratos estiverem em cadeias de fragmentos diferentes, uma mensagem pode levar vários blocos para atingir o 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 direcionado (DAG) com células como unidades. Os dados são compactados compactamente em uma célula de acordo com regras de codificação específicas e se estendem para baixo de maneira DAG. Isso contrasta com a estrutura baseada em hashmap usada em EVM para dados de estado. Devido a diferentes algoritmos de acesso a dados, TON atribui preços de gás variados 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 de EVM tem uma complexidade de consulta de O(1), garantindo custos de gás consistentes e evitando problemas semelhantes. Portanto, TON desenvolvedores de Dapp devem evitar o uso de tipos de dados ilimitados no contratos inteligentes. Quando tipos de dados ilimitados são necessários, eles devem ser particionados usando fragmentação.

1. Alguns recursos são menos exclusivos, 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 nativas de conta abstratas, 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 aspectos.

Isenção de responsabilidade:

1. Este artigo foi reproduzido 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 prontamente.
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.