Autor original: @Web3 Mário
Introdução: Com o lançamento do Notcoin, o maior jogo do ecossistema TON, na Binance e o enorme efeito riqueza causado pelo modelo econômico de token em plena circulação, o TON atraiu grande atenção em um curto período de tempo. Depois de conversar com um amigo, descobri que o limite técnico do TON é relativamente alto e que o paradigma de desenvolvimento de DApp é muito diferente dos principais protocolos de cadeia pública, por isso passei algum tempo fazendo pesquisas aprofundadas sobre tópicos relacionados e compartilhando alguns insights com vocês. Em suma, o conceito central de design do TON é reconstruir o protocolo blockchain tradicional de maneira "de baixo para cima" e alcançar alta simultaneidade e alta escalabilidade às custas da interoperabilidade.
A ideia central do design do TON é alta simultaneidade e alta escalabilidade
Pode-se dizer que o propósito de todas as seleções tecnológicas complexas na TON vem da busca por alta simultaneidade e alta escalabilidade. É claro que não é difícil para nós entender isso desde o seu nascimento. TON, ou The Open Network, é uma rede de computação descentralizada que inclui um blockchain L1 e vários componentes. O 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 blockchain por conta própria. Como nenhum blockchain L1 existente na época poderia suportar 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. Para obter os recursos necessários para implementar o TON, o Telegram lançou uma venda de tokens Gram (mais tarde renomeados como Toncoin) no primeiro trimestre de 2018. Em 2020, a equipe do Telegram retirou-se do projeto TON devido a questões regulatórias. Posteriormente, um pequeno grupo de desenvolvedores de código aberto e vencedores da competição Telegram assumiram o controle da base de código da 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 da TON.
Portanto, por ser projetado como um ambiente de execução descentralizado para o Telegram, ele naturalmente tem que enfrentar dois problemas, altas solicitações simultâneas e dados massivos. Sabemos que com o desenvolvimento da tecnologia até o presente, Solana, que é conhecido como o TPS mais alto,. tem o TPS medido mais alto, 65.000, o que obviamente não é suficiente para suportar o ecossistema Telegram que requer milhões de TPS. Ao mesmo tempo, com a aplicação em larga escala do Telegram, a quantidade de dados que ele gera já ultrapassou o céu. Como um sistema distribuído extremamente redundante, o blockchain exige que cada nó da rede salve uma cópia completa dos dados. também irrealista.
Portanto, para resolver os dois problemas acima, a TON fez duas otimizações nos principais protocolos blockchain:
Ao usar o “Paradigma de Fragmentação Infinita” para projetar o sistema, resolvemos o problema de redundância de dados para que ele possa transportar big data e aliviar o problema de gargalo de desempenho;
Ao introduzir um ambiente de execução totalmente paralelo baseado no modelo Actor, o TPS da rede é bastante melhorado;
Faça uma cadeia de blockchain - por meio de recursos de fragmentação ilimitados, cada conta tem uma cadeia de contas exclusiva
Sabemos agora que o sharding se tornou a solução principal para a maioria dos protocolos de blockchain para melhorar o desempenho e reduzir custos, e a TON levou isso ao extremo e propôs o paradigma de sharding infinito, o chamado paradigma de sharding infinito. aumentar ou diminuir dinamicamente o número de fragmentos com base na carga da rede. Este paradigma permite que a TON lide com transações em grande escala e operações de contratos inteligentes, mantendo ao mesmo tempo um alto desempenho. Em teoria, a TON pode estabelecer uma cadeia de contas exclusiva para cada conta e garantir a interoperabilidade entre essas cadeias através de certas regras.
Para entender de forma abstrata, existem quatro níveis de estrutura de cadeia no TON:
Cadeia de Contas: Esta cadeia de camadas representa uma cadeia composta por uma série de transações relacionadas a uma conta. A razão pela qual as transações podem formar uma estrutura de cadeia é porque para uma máquina de estado, desde que as regras de execução sejam consistentes, a máquina de estado irá. os resultados obtidos após o recebimento de instruções na mesma sequência são consistentes, portanto, a ordenação de transações em cadeia é necessária em todos os sistemas distribuídos em blockchain, e o TON não é exceção. A cadeia de contas é a unidade componente mais básica da rede TON. Normalmente, a cadeia de contas é um conceito virtual e é improvável que realmente exista uma cadeia de contas independente.
Shard Chain: Na maioria dos contextos, a shard chain é a unidade componente real do TON. A chamada shard chain é uma coleção de cadeias de contas.
WorkChain: Também pode ser chamado de conjunto de cadeias de sharding com regras personalizadas, como a criação de uma cadeia de trabalho baseada em EVM e a execução de contratos inteligentes Solidity nela. Em teoria, todos na comunidade podem criar a sua própria cadeia de trabalho. Na verdade, construí-la é uma tarefa bastante complexa, precedida do pagamento da (cara) taxa para criá-la e da obtenção de 2/3 dos votos dos validadores para aprovar a criação de sua cadeia de trabalho.
MasterChain: Finalmente, existe uma cadeia especial no TON chamada cadeia mestre, que é responsável por trazer finalidade a todas as cadeias de fragmentos. Depois que o hash do bloco de uma cadeia de fragmentos é mesclado no bloco da cadeia principal, esse bloco da cadeia de fragmentos e todos os seus blocos pai são considerados finais, o que significa que podem ser considerados fixos e inquebráveis. O conteúdo alterado é referenciado pelos blocos subsequentes de todos os fragmentos. correntes.
Ao adotar tal paradigma, a rede TON possui as seguintes três características:
Fragmentação dinâmica: o TON pode dividir e mesclar automaticamente cadeias de fragmentos para se adaptar às mudanças na carga. Isto significa que novos blocos são sempre gerados rapidamente e as transações não implicam longos tempos de espera.
Altamente escalável: por meio do paradigma de sharding infinito, o TON pode suportar um número quase ilimitado de shards e pode, teoricamente, atingir 2 elevado à 60ª potência de cadeias de trabalho.
Adaptabilidade: quando a carga aumenta em uma parte da rede, essa parte pode ser subdividida em mais fragmentos para lidar com o aumento do volume de transações. Por outro lado, quando a carga diminui, os fragmentos podem ser mesclados para aumentar a eficiência.
Então, a primeira coisa que esse sistema multi-cadeia precisa enfrentar é o problema da comunicação entre cadeias, especialmente devido à capacidade de fragmentação ilimitada. Quando o número de fragmentos na rede atinge um determinado nível, o roteamento de informações entre as cadeias. se tornará uma coisa difícil de fazer. Imagine que existem 4 nós na rede, e cada nó é responsável por manter uma cadeia de trabalho independente. O relacionamento do link indica que além de ser responsável por classificar as transações em sua própria cadeia de trabalho, o nó também precisa monitorar e processar o estado. mudanças na cadeia de destino, que é implementada especificamente no TON monitorando as mensagens na fila de saída.
Suponha que a conta A na cadeia de trabalho 1 queira enviar uma mensagem para a conta C na cadeia de trabalho 3. Então você precisa projetar o problema de roteamento de mensagens. Neste exemplo, existem dois caminhos de roteamento, cadeia de trabalho 1 -> cadeia de trabalho 2-> cadeia de trabalho 3 e cadeia de trabalho 1 -> cadeia de trabalho 4 -> cadeia de trabalho 3.
Ao enfrentar situações mais complexas, é necessário um algoritmo de roteamento eficiente e de baixo custo para concluir rapidamente a comunicação de mensagens. A TON escolheu o chamado "algoritmo de roteamento hipercubo" para realizar a descoberta de rotas de comunicação de mensagens entre cadeias. A chamada estrutura de hipercubo refere-se a uma topologia de rede especial. Um hipercubo n-dimensional é composto de 2 ^ n vértices e cada vértice pode ser identificado exclusivamente por um número binário de n bits. Nesta estrutura, quaisquer dois vértices são adjacentes se diferirem em apenas um bit na representação binária. 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 bidimensional.
No protocolo de roteamento hipercubo, o processo de roteamento de uma mensagem de uma cadeia de trabalho de origem para uma cadeia de trabalho de destino é executado comparando as representações binárias da cadeia de trabalho de origem e dos endereços da cadeia de trabalho de destino. O algoritmo de roteamento encontra a distância mínima (ou seja, o número de bits diferentes na representação binária) entre esses dois endereços e encaminha progressivamente a informação através de cadeias de trabalho adjacentes até que a cadeia de trabalho alvo seja alcançada. Este método garante que os pacotes de dados sejam transmitidos pelo caminho mais curto, melhorando assim a eficiência da comunicação da rede.
É claro que, para simplificar esse processo, a TON também propôs uma solução técnica otimista. Quando um usuário pode fornecer uma prova válida de um determinado caminho de roteamento, que geralmente é uma raiz merkle trie, o nó pode reconhecer diretamente a credibilidade do caminho. mensagem enviada pelas propriedades do usuário, isso também é conhecido como roteamento de hipercubo instantâneo.
Portanto, podemos ver que existem diferenças óbvias entre os endereços no TON e outros protocolos blockchain. A maioria dos outros protocolos blockchain convencionais usam o hash correspondente à chave pública nas chaves públicas e privadas geradas pelo algoritmo de criptografia elíptica como endereço, porque. o endereço é usado apenas como um endereço exclusivo. Ele não precisa carregar a função de endereçamento de roteamento, e o endereço em TON consiste em duas partes (workchain_id, account_id), onde workchain_id é codificado de acordo com o endereço do algoritmo de roteamento do hipercubo, que não será elaborado aqui.
Há outro ponto que é fácil de levantar dúvidas. Você deve ter notado que a cadeia principal possui um relacionamento de elo com cada cadeia de trabalho, então não seria suficiente que todas as informações da cadeia cruzada fossem retransmitidas através da cadeia principal, apenas? como o Cosmo. No conceito de design da TON, a cadeia principal é utilizada apenas para lidar com as tarefas mais críticas, ou seja, manter a finalidade de muitas cadeias de trabalho. Não é impossível encaminhar mensagens através da cadeia principal, mas as taxas de manuseio resultantes serão muito caras. .
Finalmente, vamos mencionar brevemente seu algoritmo de consenso TON adota o método BFT+PoS, ou seja, qualquer staker tem a oportunidade de participar do pacote de governança eleitoral da TON selecionará aleatoriamente um verificador de empacotamento de todos os Stakers em intervalos regulares. cluster, os nós selecionados como validadores empacotarão e produzirão blocos por meio do algoritmo BFT. Se empacotarem informações incorretas ou fizerem o mal, seus tokens de aposta serão perdidos e, caso contrário, receberão recompensas de bloco. Esta é basicamente uma escolha comum, então não vou apresentá-la aqui.
Contratos inteligentes e ambiente de execução totalmente paralelo baseado no modelo Actor
Outra diferença entre o TON e os protocolos blockchain convencionais é seu ambiente de execução de contrato inteligente. A fim de romper as limitações do TPS dos protocolos blockchain convencionais, a TON adota uma ideia de design bottom-up e usa o modelo Actor para reconstruir contratos inteligentes e seus métodos de execução, para que tenham a capacidade de serem totalmente paralelizados.
Sabemos que a maioria dos protocolos blockchain convencionais usam um ambiente de execução serial de thread único. Tomando o Ethereum como exemplo, seu ambiente de execução EVM é uma máquina de estado com transações como entrada. Quando o nó produtor de blocos conclui a transação empacotando o bloco após a classificação. , as transações serão executadas através do EVM nesta ordem. Todo o processo é totalmente serial e single-threaded, ou seja, apenas uma transação pode ser executada em um determinado momento. confirmado, o resultado da execução será Há consistência em uma ampla gama de clusters distribuídos Ao mesmo tempo, como apenas uma transação é executada serialmente ao mesmo tempo, isso significa que durante o processo de execução é impossível que outras transações sejam executadas. modificar determinados dados de estado a serem acessados, para que a interoperabilidade entre contratos inteligentes seja alcançada. Por exemplo, usamos USDT para comprar ETH através do Uniswap. Quando a transação é executada, a distribuição de LP no par de negociação é um determinado valor. Desta forma, o resultado correspondente pode ser obtido através de determinados modelos matemáticos, mas assumindo que este é. não é o caso, ao realizar o cálculo de uma determinada curva de títulos, se outros LPs adicionarem nova liquidez, o resultado do cálculo será um resultado desatualizado, o que é obviamente inaceitável.
Mas essa arquitetura também tem limitações óbvias, que é o gargalo do TPS, e esse gargalo parece muito antigo nos processadores multi-core atuais, assim como se você usasse o PC mais recente para jogar alguns jogos de computador antigos, como Red Alert, Quando o. número de unidades de combate atingir um determinado nível, você ainda descobrirá que ele está travado. Isso é um problema com a arquitetura do software.
Você pode ouvir que alguns protocolos já estão prestando atenção a esse problema e propuseram suas próprias soluções paralelas. Tomando Solana, que atualmente afirma ter o TPS mais alto, como exemplo, ele também tem a capacidade de executar em paralelo. No entanto, sua ideia de design é diferente da TON, sua ideia central é dividir todas as transações em vários grupos de acordo com as dependências de execução, e nenhum dado de estado é compartilhado entre diferentes grupos. Ou seja, não existem dependências idênticas, portanto as transações em grupos diferentes podem ser executadas em paralelo sem preocupação com conflitos, enquanto as transações dentro do mesmo grupo ainda são executadas da maneira serial tradicional.
No TON, abandona completamente a arquitetura de execução serial e, em vez disso, adota um paradigma de desenvolvimento projetado especificamente para paralelismo, o modelo Ator, para reconstruir o ambiente de execução. O chamado modelo de Ator foi proposto pela primeira vez por Carl Hewitt em 1973 para resolver a complexidade do estado compartilhado em programas simultâneos tradicionais por meio da passagem de mensagens. Cada Ator tem seu próprio estado e comportamento privado, e nenhuma informação de estado é compartilhada com outros Atores. O modelo Ator é um modelo de computação simultânea que implementa computação paralela por meio da passagem de mensagens. Neste modelo, um “Ator” é a unidade básica de trabalho, capaz de processar mensagens recebidas, criar novos Atores, enviar mais mensagens e decidir como responder às mensagens subsequentes. O modelo Ator precisa ter as seguintes características:
Encapsulamento e independência: Cada ator é completamente independente no processamento de mensagens e pode processá-las em paralelo sem interferir entre si.
Passagem de mensagens: os atores interagem entre si apenas enviando e recebendo mensagens, e a passagem de mensagens é assíncrona.
Estrutura dinâmica: os atores podem criar mais atores em tempo de execução. Essa natureza dinâmica permite que o modelo do ator dimensione o sistema conforme necessário.
A TON adota essa arquitetura para projetar modelos de contratos inteligentes, o que significa que na TON, cada contrato inteligente é um modelo de ator com espaço de armazenamento totalmente independente. Porque não depende de nenhum dado externo. Além disso, as chamadas para o mesmo contrato inteligente ainda são executadas de acordo com a ordem das mensagens na fila de recebimento, de modo que as transações em TON podem ser executadas em paralelo de forma eficiente, sem preocupação com conflitos.
No entanto, tal esquema de design também traz alguns novos impactos Para os desenvolvedores de DApp, seu paradigma de desenvolvimento habitual será quebrado, como segue:
1. Chamadas assíncronas entre contratos inteligentes: Não é possível chamar atomicamente contratos externos ou acessar dados de contratos externos dentro dos contratos inteligentes da TON. Sabemos que no Solidity, a função 1 do contrato A chama a função 2 do contrato B. Ou acessar determinados dados de estado. através da função somente leitura n3 do contrato C. Todo o processo é atômico e executado em uma transação. Porém, no TON, isso não será possível. Todas as interações com contratos inteligentes externos serão executadas. de forma assíncrona, empacotando novas transações. Essas transações iniciadas por contratos inteligentes também são chamadas de mensagens internas. E não pode ser bloqueado durante a execução para obter resultados de execução.
Por exemplo, se desenvolvermos um DEX, se adotarmos o paradigma comum em EVM, geralmente haverá um contrato de roteador unificado usado para gerenciar o roteamento de transações, e cada Pool gerencia independentemente os dados LP relacionados a um determinado par de negociação. existem atualmente dois pools USDT-DAI e DAI-ETH. Quando um usuário deseja comprar ETH diretamente através do USDT, ele pode solicitar sequencialmente esses dois pools em uma transação por meio do contrato do roteador para concluir uma transação atômica. Porém, não é tão fácil de implementar no TON. É necessário pensar em um novo paradigma de desenvolvimento. Se este paradigma ainda for reaproveitado, o fluxo de informações poderá ser acompanhado por uma mensagem externa iniciada pelo. usuário e três mensagens internas são concluídas (observe que isso é usado para ilustrar a diferença. No desenvolvimento real, até mesmo o paradigma do ERC 20 terá que ser redesenhado).
2. É necessário considerar cuidadosamente o processo de processamento de erros de execução ao chamar entre contratos e projetar funções de devolução correspondentes para cada chamada entre contratos. Sabemos que no EVM mainstream, quando um problema é encontrado durante a execução da transação, toda a transação será revertida, ou seja, redefinida para o estado inicial de execução. Isso é fácil de entender no modelo serial de thread único. Porém, no TON, como as chamadas entre contratos são executadas de forma assíncrona, mesmo que ocorra um erro em um link subsequente, uma vez que a transação anteriormente executada com sucesso já foi executada e confirmada, isso pode causar problemas. Portanto, um tipo de mensagem especial é configurado no TON, denominado mensagem de bounce. Ou seja, quando ocorre um erro no processo de execução subsequente acionado por uma mensagem interna, o contrato acionado pode acionar um determinado evento no contrato acionando o bounce. função reservada pelo contrato. Algumas redefinições de status.
3. Em algumas situações complexas, a transacção recebida primeiro pode não ser executada primeiro, pelo que esta relação temporal não pode ser predefinida. Em tal sistema de chamadas de contratos inteligentes assíncronas e paralelas, pode ser difícil definir a ordem em que as operações são processadas. É por isso que cada mensagem em TON tem seu tempo lógico, tempo Lamport (doravante denominado lt). É usado para entender qual evento desencadeou outro e o que o validador precisa tratar primeiro. Para um modelo simples, a transação recebida primeiro deve ser executada primeiro.
Neste modelo, A e B representam dois contratos inteligentes respectivamente, e há uma relação de temporização de se msg 1 _lt < msg 2 _lt, então tx 1 _lt < tx 2 _lt.
Porém, em situações mais complexas, esta regra é quebrada. Há um exemplo disso na documentação oficial, assumindo que temos três contratos A, B e C. Em uma transação, A envia duas mensagens internas, mensagem 1 e mensagem 2: uma para B e outra para C. Embora sejam criados na ordem exata (primeiro msg 1 , depois msg 2 ), não podemos ter certeza de que a msg 1 será processada antes da msg 2 . Isso ocorre porque as rotas de A para B e de A para C podem diferir em comprimento e conjunto de validadores. Se esses contratos estiverem em cadeias de fragmentos diferentes, uma das mensagens poderá levar vários blocos para chegar ao contrato de destino. Ou seja, temos duas possíveis trajetórias de negociação, conforme mostra a figura.
4. No TON, o armazenamento persistente de seus contratos inteligentes usa um gráfico acíclico direcionado com Cell como unidade como estrutura de dados. Os dados serão compactados em uma Cell de acordo com as regras de codificação e, ao mesmo tempo, de acordo com o. gráfico acíclico direcionado. O caminho se estende para baixo, o que é diferente da organização estrutural de dados de status baseada em hashmap no EVM. Devido a diferentes algoritmos de solicitação de dados, o TON define diferentes preços de gás para diferentes profundidades de processamento de dados. , quanto mais Gás ele requer, maior, então existe um paradigma de ataque DOS no TON, ou seja, alguns usuários mal-intencionados ocupam todas as células superficiais de um determinado contrato inteligente enviando um grande número de mensagens de spam, o que significa que o o custo de armazenamento dos usuários honestos ficará cada vez mais caro. No EVM, como a complexidade da consulta do hashmap é o(1), ele possui o mesmo Gas e não haverá problemas semelhantes. Portanto, os desenvolvedores do TON Dapp devem tentar evitar tipos de dados ilimitados em contratos inteligentes. Quando tipos de dados ilimitados aparecem, eles devem ser divididos por meio de fragmentação.
5. Existem também alguns recursos menos especiais, como contratos inteligentes que precisam pagar aluguel para armazenamento, contratos inteligentes em TON são naturalmente atualizáveis e funções de conta abstratas nativas, ou seja, todos os endereços de carteira em TON são contratos inteligentes, apenas não inicializado, etc. Isso exige que os desenvolvedores prestem muita atenção.
Acima estão algumas das minhas experiências no aprendizado de tecnologias relacionadas ao TON durante este período. Gostaria de compartilhá-las com vocês. Espero que possam me corrigir se eu cometer algum erro. , o ecossistema TON certamente servirá como uma plataforma para Web3. Trazendo alguns aplicativos totalmente novos, amigos interessados no desenvolvimento de TON DApp também podem entrar em contato comigo e discutir conosco.
Links X: https://x.com/web3_mario
Identificador do telegrama: @MarioChin Web3
