No campo em rápida evolução da tecnologia blockchain, TON (The Open Network) está ganhando cada vez mais atenção dos desenvolvedores como uma plataforma blockchain eficiente e flexível. A arquitetura única e as características do TON fornecem ferramentas poderosas e ricas possibilidades para o desenvolvimento de aplicações descentralizadas.

No entanto, com o aumento da funcionalidade e complexidade, a segurança dos contratos inteligentes tornou-se mais crítica. FunC, a linguagem de programação de contratos inteligentes no TON, é conhecida pela sua flexibilidade e eficiência, mas também apresenta muitos riscos e desafios potenciais. Escrever contratos inteligentes seguros e confiáveis requer que os desenvolvedores tenham um profundo entendimento das características do FunC e dos riscos potenciais envolvidos.

Este artigo fornecerá uma análise detalhada das funcionalidades relacionadas com contratos inteligentes na blockchain TON, bem como das vulnerabilidades nos contratos inteligentes TON que muitas vezes são negligenciadas.

Análise das Características Assíncronas e do Mecanismo de Conta do TON

Chamadas Assíncronas em Contratos Inteligentes

Fragmentação de Rede e Comunicação Assíncrona

A blockchain TON é projetada com três tipos de cadeias: Masterchain, Workingchains e Shardchains.

O Masterchain é o núcleo de toda a rede, responsável por armazenar os metadados e o mecanismo de consenso de toda a rede. Ele registra os estados de todas as Workingchains e Shardchains e garante a consistência e a segurança da rede. Workingchains são blockchains independentes, com um máximo de 2^32 cadeias, responsáveis por lidar com tipos específicos de transações e contratos inteligentes. Cada cadeia de trabalho pode ter suas próprias regras e recursos para atender a diferentes necessidades de aplicativos. Shardchains são sub-cadeias de Workingchains, usadas para dividir ainda mais a carga de trabalho de Workingchains, aumentando a capacidade de processamento e escalabilidade. Cada Workingchain pode ser dividido em até 2^60 Shardchains, com Shardchains lidando com algumas transações de forma independente para alcançar um processamento paralelo eficiente.

Em teoria, cada conta pode ocupar exclusivamente um Shardchain, com cada conta mantendo independentemente seu saldo de COIN/TOKEN. As transações entre contas podem ser totalmente paralelizadas. As contas se comunicam por meio de mensagens assíncronas, e o caminho para as mensagens viajarem entre Shardchains é log_16(N) - 1, onde N é o número de Shardchains.

Origem da imagem: https://frontierlabzh.medium.com/ton-weixin-e1d3ae3b3574do mundo web3No Ton, as interações são realizadas através do envio e recebimento de mensagens. Estas mensagens podem ser internas (geralmente enviadas por contratos inteligentes que interagem entre si) ou externas (enviadas por fontes externas). O processo de passagem de mensagens não requer respostas imediatas do contrato alvo, permitindo que o remetente continue executando a lógica restante. Este mecanismo de mensagens assíncronas oferece maior flexibilidade e escalabilidade em comparação com as chamadas síncronas do Ethereum, reduzindo gargalos de desempenho causados pela espera de respostas, enquanto também introduz desafios no tratamento de concorrência e condições de corrida.

Formato e estrutura da mensagem

Na TON, as mensagens normalmente incluem informações como o remetente, destinatário, quantidade e corpo da mensagem. O corpo da mensagem pode consistir em chamadas de função, transferências de dados ou outro conteúdo personalizado. O formato da mensagem da TON é projetado para ser flexível e extensível, permitindo uma comunicação eficiente de vários tipos de informações entre diferentes contratos.

Fila de mensagens e processamento de estado

Cada contrato mantém uma fila de mensagens para armazenar as mensagens que ainda não foram processadas. Durante a execução, o contrato processa as mensagens uma por uma da fila. Como o processamento de mensagens é assíncrono, o estado do contrato não será atualizado imediatamente ao receber uma mensagem.

Vantagens da mensageria assíncrona

•Mecanismo de fragmentação eficiente: o mecanismo assíncrono do TON é altamente compatível com o seu design de fragmentação. Cada fragmento lida independentemente com mensagens de contrato e alterações de estado, evitando atrasos causados pela sincronização entre fragmentos. Este design melhora a capacidade geral e escalabilidade da rede.

•Redução do Consumo de Recursos: As mensagens assíncronas não exigem respostas imediatas, permitindo que os contratos TON sejam executados através de vários blocos e evitando um consumo excessivo de recursos dentro de um único bloco. Isso permite que a TON suporte contratos inteligentes mais complexos e intensivos em recursos.

• Tolerância a Falhas e Confiabilidade: O mecanismo de passagem de mensagens assíncrono aumenta a tolerância a falhas do sistema. Por exemplo, se um contrato não puder responder a uma mensagem em tempo hábil devido a limitações de recursos ou outras razões, o remetente pode continuar processando outras lógicas, impedindo que o sistema pare devido a atrasos em um único contrato.

Desafios do design de contratos assíncronos

• Problemas de Consistência de Estado: Devido à natureza assíncrona da passagem de mensagens, os contratos podem receber mensagens diferentes em momentos diferentes, o que exige que os desenvolvedores prestem atenção especial à consistência do estado. Ao projetar contratos, é crucial considerar como diferentes ordens de mensagem podem afetar as mudanças de estado e garantir que o sistema mantenha a consistência em todas as condições.

•Condições de Corrida e Proteção: O processamento assíncrono de mensagens introduz potenciais problemas de condições de corrida, onde várias mensagens podem tentar simultaneamente modificar o estado do contrato. Os desenvolvedores precisam implementar mecanismos de bloqueio apropriados ou usar operações transacionais para evitar conflitos de estado.

•Considerações de segurança: Os contratos assíncronos são suscetíveis a riscos como ataques man-in-the-middle ou ataques de repetição ao lidar com a comunicação entre contratos. Portanto, ao projetar contratos assíncronos, é essencial abordar esses riscos potenciais de segurança e tomar medidas preventivas, como o uso de carimbos de data/hora, números aleatórios ou abordagens com várias assinaturas.

Modelo de livro-razão

TON (The Open Network) utiliza uma abstração de conta única e um modelo de livro-razão exclusivo no design de sua infraestrutura de blockchain. A flexibilidade deste modelo é refletida na forma como ele gerencia os estados de conta, a passagem de mensagens e a execução de contratos.

Abstração de conta

O modelo de conta da TON utiliza uma abstração baseada em contratos, onde cada conta pode ser vista como um contrato. Isto é algo semelhante ao modelo de abstração de contas do Ethereum, mas é mais flexível e geral. Na TON, as contas não são apenas recipientes de ativos; também incluem código de contrato e dados de estado. Cada conta compreende o seu código, dados e lógica de tratamento de mensagens.

Estrutura da Conta: Cada conta TON tem um endereço único, que é gerado a partir de uma combinação de valor de hash do código da conta, dados iniciais na implantação e outros parâmetros. Isso significa que o mesmo código e dados iniciais implantados em diferentes ambientes (por exemplo, diferentes blockchains ou shards) podem produzir endereços diferentes.

Flexibilidade: Uma vez que cada conta pode executar o seu próprio código de contrato, as contas TON podem implementar lógica muito complexa. As contas não são apenas detentoras de saldo simples, mas podem lidar com transições de estado complexas, comunicação de mensagens entre contas e até automação com base em condições específicas. Isso torna o modelo de conta da TON mais escalável e flexível em comparação com os modelos de conta de blockchain tradicionais.

Estrutura de registro

A estrutura do ledger da TON é projetada para lidar eficientemente com transações concorrentes em grande escala, suportando passagem de mensagens assíncronas e operações multi-shard. O estado de cada conta é armazenado em uma estrutura de árvore de Merkle, fornecendo capacidades eficientes de validação de estado.

Armazenamento de Estado

As informações do estado da conta são armazenadas em armazenamento persistente e organizadas através de uma árvore de Merkle para garantir integridade e segurança. Este design também suporta consultas eficientes e verificação de estados, especialmente em transações entre shards.

Uma conta ou estado de contrato inteligente geralmente inclui o seguinte:

1. Saldo da moeda base 2. Saldo de outras moedas 3. Código de contrato inteligente (ou seu hash) 4. Dados persistentes do contrato inteligente (ou seu hash Merkle) 5. Estatísticas sobre o número de unidades de armazenamento persistentes e o uso bruto de bytes 6. Carimbo de data e hora recente de pagamentos para o armazenamento persistente do contrato inteligente (essencialmente o número do bloco da cadeia principal) 7. Chave pública necessária para transferir moeda e enviar mensagens desta conta (opcional; por padrão, isso é igual ao próprio account_id). Em alguns casos, códigos de verificação de assinatura mais complexos podem ser encontrados aqui, semelhantes às saídas de transação do Bitcoin; nesses casos, account_id será o hash deste código.

Nem todas as informações são necessárias para todas as contas. Por exemplo, o código de contrato inteligente só é relevante para contratos inteligentes, não para contas "simples". Além disso, enquanto toda conta deve ter um saldo não zero da moeda base (por exemplo, Gram para a cadeia de trabalho base e cadeias de fragmentos), os saldos de outras moedas podem ser zero. Para evitar reter dados não utilizados, um tipo de soma-produto é definido durante a criação de uma cadeia de trabalho, usando diferentes bytes de marcação para distinguir várias "funções de construtor". Em última análise, o estado da conta é salvo como uma coleção de unidades no armazenamento persistente de TVM.

Passagem de mensagens e processamento

A estrutura do TON inclui suporte integrado para passagem de mensagens assíncronas. Cada conta pode processar de forma independente as mensagens recebidas e atualizar o seu estado. Este mecanismo de mensagens assíncronas permite interações complexas entre contas sem afetar o funcionamento normal de outras contas devido a atrasos em qualquer operação única.

modelo de gás

TON (A Rede Aberta) otimiza significativamente a eficiência de execução de contratos inteligentes através do seu modelo único de taxa de gás. Este modelo de taxa de gás é usado para medir e limitar os recursos consumidos durante a execução de contratos inteligentes. Comparado a blockchains tradicionais como o Ethereum, o modelo da TON é mais complexo e eficiente, permitindo um gerenciamento mais preciso do consumo de recursos durante a execução de contratos.

O modelo de gás da TON pode medir com precisão os recursos computacionais, operações de armazenamento e custos de passagem de mensagens consumidos durante a execução de contratos inteligentes. Ao fornecer medidas detalhadas para recursos como computação, armazenamento e mensagens, o modelo de gás da TON impede que operações com excessiva complexidade consumam demasiados recursos. Ao limitar o consumo de gás, a TON garante que cada nó da rede possa alocar justamente recursos computacionais, evitando a utilização excessiva de recursos da rede por um único contrato ou operação.

TON suporta o processamento paralelo de contratos inteligentes, permitindo que vários contratos sejam executados simultaneamente em diferentes fragmentos sem bloquear uns aos outros. Nesse design, o modelo de gas é intimamente integrado com os mecanismos de execução paralela e fragmentação. Ao processar contratos em paralelo em vários fragmentos, o TON pode distribuir a computação e o pagamento de gas entre diferentes nós e cadeias, evitando congestionamento de rede ao mesmo tempo em que maximiza a utilização de recursos.

O modelo de gás da TON inclui um mecanismo de ajuste dinâmico que permite ajustar as taxas de gás com base na carga em tempo real da rede. Isso significa que durante períodos de menor carga na rede, os usuários podem executar contratos com taxas de gás mais baixas, incentivando operações durante horários fora de pico e equilibrando o uso dos recursos da rede. Esse mecanismo não apenas aprimora a experiência do usuário, mas também controla o uso máximo de recursos por meio de uma abordagem orientada pelo mercado.

Os contratos inteligentes da TON são fáceis de ignorar as lacunas

Em o nosso artigo de análise de segurança anteriorNo TON, detalhamos as vulnerabilidades comuns de segurança no ecossistema TON. Para mais informações, consulte a tabela abaixo:

Este artigo incidirá sobre as vulnerabilidades nos contratos TON que muitas vezes são ignoradas, conforme resumido pela nossa equipa:

(1) Otimização da legibilidade do código

Nos contratos inteligentes TON, números são frequentemente usados para armazenar dados relacionados ao envio de mensagens. Por exemplo, no código abaixo, várias instâncias de números são usadas para representar identificadores correspondentes e comprimentos de armazenamento de dados, o que reduz significativamente a legibilidade e a manutenção do código. Outros desenvolvedores podem achar desafiador entender o significado e o propósito desses números ao ler o código. Para melhorar a legibilidade e a manutenção, é recomendado definir valores numéricos-chave como constantes nomeadas. Por exemplo, defina 0x18comoNON_BOUNCEABLE.

1. check_std_addr(address);foi msg = begin_cell() store_uint(0x18, 6) ;; nobounce store_slice(address) store_coins(amount) store_uint(0, 1 + 4 + 4 + 64 + 32 + 1 + 1) end_cell();send_raw_message(msg, 1);

Além disso, para a mensagem de erro nas condições de julgamento do contrato, também é recomendável definir variáveis correspondentes para substituir os códigos de erro.

(2) Usando end_parse()Garantir a Integridade dos Dados

Nos contratos TON, a análise de dados segue uma ordem fixa, carregando tipos especificados de dados passo a passo a partir dos dados brutos. Esse método de análise garante a consistência e a precisão dos dados, conforme ilustrado abaixo:

Note queend_parse()é usada para verificar se uma fatia de dados está vazia. Se a fatia não estiver vazia, a função irá lançar uma exceção. Isso garante que o formato e o conteúdo dos dados estejam como o esperado. Se o end_parse()a função deteta dados restantes na fatia, pode indicar que o parsing dos dados não prosseguiu como pretendido ou que há um problema com o formato dos dados. Portanto, ao chamar end_parse(), você pode verificar se há omissões ou anomalias durante o processo de análise.

(3) Exceções causadas por tipos e armazenamento de dados incompatíveis

Isto diz respeito principalmente à correspondência de int e uinttipos de armazenamento. Por exemplo, no código a seguir, o store_int()A função é usada para armazenar umintvalor de-42, mas load_uint()é usado para carregar esse valor, o que pode resultar em uma exceção.

(4) Uso Adequado de inline_ref e inlineModifiers

Primeiro, é importante distinguir entre o em linha e ainda inline_refmodificadores:

inline: Funções com a inlineos modificadores têm seu código inserido diretamente no local da chamada sempre que são chamados. Isso significa que o código real da função é copiado para o local da chamada em vez de ser executado por meio de um salto de função, o que reduz a sobrecarga da chamada de função, mas pode levar à duplicação de código.

inline_ref: Funções com o inline_refmodificador armazena seu código em uma célula separada. Cada vez que a função é chamada, o TVM executa o código armazenado na célula através do CALLREFcomando, evitando a duplicação de código e melhorando a eficiência para funções mais complexas ou aquelas chamadas várias vezes.

Em resumo, use em linhapara funções simples para reduzir a sobrecarga de chamada, mas esteja ciente da possível duplicação de código. Useinline_ref para funções maiores ou frequentemente chamadas para melhorar a eficiência e evitar a repetição de código.

(5) Determinar a Workchain Correta

TON permite a criação de até 2^32 workchains, cada um dos quais pode ser subdividido ainda mais em até 2^60 shards. Inicialmente, existem duas workchains: a masterchain (-1) e a basechain (0). Ao calcular endereços de destino em contratos, é crucial especificar o ID da workchain correto para garantir que o endereço da carteira gerado esteja na workchain correta. Para evitar a geração de endereços incorretos, é recomendável usarforce_chain()para especificar explicitamente o ID da cadeia.

(6) Evitando Conflitos de Código de Erro

A gestão eficaz dos códigos de erro é crucial para o design de contratos, garantindo consistência e evitando confusões. Para contratos inteligentes TON, certifique-se de que cada código de erro é único dentro do contrato para evitar conflitos e mensagens de erro ambíguas. Além disso, evite conflitos com códigos de erro padrão definidos pela plataforma TON ou sistema subjacente. Por exemplo, o código de erro 333 indica uma incompatibilidade de ID de cadeia. É aconselhável usar códigos de erro entre 400 e 1000 para evitar tais conflitos.

(7) Armazenamento de Dados e Chamadasreturn() Após a conclusão da operação

Nos contratos inteligentes TON, o tratamento de mensagens envolve a seleção de lógica diferente com base no código de operação. Após concluir a lógica correspondente, são necessários dois passos adicionais: Primeiro, se os dados foram modificados, chame save_data()para garantir que as alterações sejam armazenadas; caso contrário, as alterações serão ineficazes. Em segundo lugar, chameretorno()para indicar que a operação está completa; caso contrário, um throw(0xffff)será acionada uma exceção.

() recv_internal(int my_balance, int msg_value, cell in_msg_full, fatia in_msg_body) impuro {

int flags = cs~load_uint(4);

if (flags & 1) {

;; ignorar todas as mensagens devolvidas

return ();

}

slice sender_address = cs~load_msg_addr();

load_data();

int op = in_msg_body~load_op();

if ((op == op::op_1())) {

handle_op1();

save_data();

return ();

}

if ((op == op::op_2())) {

handle_op2();

save_data();

return ();

}

if ((op == op::op_3())) {

handle_op3();

save_data();

return ();

}

throw(0xffff);

}

Em resumo, a blockchain TON, com sua arquitetura inovadora e ambiente de desenvolvimento flexível, está se tornando uma plataforma ideal para desenvolvedores de aplicativos descentralizados. No entanto, à medida que os contratos inteligentes desempenham um papel cada vez mais crucial no ecossistema TON, as questões de segurança não podem ser negligenciadas. Os desenvolvedores devem compreender profundamente as características do ecossistema TON, aderir estritamente às melhores práticas e aprimorar os processos de auditoria de segurança para garantir a robustez e segurança dos contratos. Somente assim as vantagens da plataforma TON podem ser completamente realizadas, construindo aplicativos descentralizados mais seguros e confiáveis e salvaguardando o desenvolvimento saudável de todo o ecossistema.

O ecossistema TON está a crescer rapidamente, atraindo financiamento significativo e utilizadores ativos. No entanto, as questões de segurança associadas não podem ser ignoradas. Para garantir a segurança e fiabilidade do ecossistema TON, a Beosin fornece auditorias de segurança abrangentes e profissionais adaptadas às características das chamadas e operações de contratos inteligentes TON, apoiando o desenvolvimento do ecossistema.

Beosin tem inúmeros casos de sucesso no ecossistema TON. Anteriormente, Beosin realizou auditorias de segurança completas para o principal projeto de stablecoin descentralizado Aqua Protocol e para a infraestrutura DeFi ONTON Finance. A auditoria abrangeu vários aspectos, incluindo a segurança do código do contrato inteligente, a correção da implementação da lógica de negócios, a otimização de gás do código do contrato e a detecção e remediação de possíveis vulnerabilidades.

Declaração:

1. Este artigo é reproduzido a partir de [ Beosina], título original “Beosin Hard Core Research | Dos riscos à proteção: riscos de segurança e sugestões de otimização dos contratos inteligentes TON”, os direitos autorais pertencem ao autor original [Beosin], se você tiver qualquer objeção à reprodução, por favor entre em contato Equipe de Aprendizado da Gate, a equipe irá lidar com isso o mais rápido possível de acordo com os procedimentos relevantes.

2. Aviso legal: As opiniões expressas neste artigo representam apenas as opiniões pessoais do autor e não constituem qualquer conselho de investimento.

3. Outras versões do artigo são traduzidas pela equipe de Aprendizado da Gate e não são mencionadas emGate.ioO artigo traduzido não pode ser reproduzido, distribuído ou plagiado.