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 e recursos únicos do TON fornecem ferramentas poderosas e possibilidades ricas para o desenvolvimento de aplicativos descentralizados.

No entanto, com o aumento da funcionalidade e complexidade, a segurança dos contratos inteligentes se tornou mais crítica. FunC, a linguagem de programação de contratos inteligentes no TON, é conhecida por 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 entendimento profundo das características do FunC e dos riscos potenciais envolvidos.

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

Análise das Funcionalidades Assíncronas e do Mecanismo de Conta da 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.

A Masterchain é o núcleo de toda a rede, responsável por armazenar os metadados e mecanismo de consenso de toda a rede. Registra os estados de todas as Workingchains e Shardchains e garante a consistência e 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 Workingchain pode ter suas próprias regras e recursos para atender a diferentes necessidades de aplicação. Shardchains são sub-cadeias das Workingchains, usadas para dividir ainda mais a carga de trabalho das Workingchains, aumentando a capacidade de processamento e escalabilidade. Cada Workingchain pode ser dividida em até 2^60 Shardchains, com Shardchains lidando com algumas transações de forma independente para alcançar processamento paralelo eficiente.

Na 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 via mensagens assíncronas, e o caminho para as mensagens viajarem entre Shardchains é log_16(N) - 1, onde N é o número de Shardchains.

Fonte da imagem: https://frontierlabzh.medium.com/ton-weixin-e1d3ae3b3574No mundo do web3, as interações são conduzidas através do envio e recebimento de mensagens. Essas mensagens podem ser internas (geralmente enviadas por contratos inteligentes interagindo entre si) ou externas (enviadas por fontes externas). O processo de passagem de mensagens não requer respostas imediatas do contrato de destino, permitindo que o remetente continue executando a lógica restante. Esse 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 manuseio de concorrência e condições de corrida.

Formato e estrutura da mensagem

No TON, as mensagens normalmente incluem informações como o remetente, destinatário, valor 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 de mensagem do TON foi 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 status

Cada contrato mantém uma fila de mensagens para armazenar 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 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. Esse design melhora a capacidade total e escalabilidade da rede.

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

•Tolerância a falhas e confiabilidade: O mecanismo assíncrono de passagem de mensagens aumenta a tolerância a falhas do sistema. Por exemplo, se um contrato não puder responder a uma mensagem de forma oportuna devido a limitações de recursos ou outros motivos, o remetente pode continuar processando outra lógica, evitando que o sistema pare devido a atrasos em um único contrato.

Desafios do design de contrato assíncrono

•Problemas de Consistência de Estado: Devido à natureza assíncrona da passagem de mensagens, os contratos podem receber diferentes mensagens em momentos diferentes, o que requer que os desenvolvedores prestem atenção especial à consistência de estado. Ao projetar contratos, é crucial considerar como diferentes ordens de mensagens 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ção de corrida, onde várias mensagens podem tentar modificar simultaneamente 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: Contratos assíncronos são suscetíveis a riscos, como ataques de intermediários ou ataques de repetição, ao lidar com comunicação entre contratos. Portanto, ao projetar contratos assíncronos, é essencial abordar esses riscos potenciais de segurança e tomar medidas preventivas, como usar carimbos de data/hora, números aleatórios ou abordagens de multi-assinatura.

modelo de contabilidade

TON (The Open Network) emprega um modelo exclusivo de abstração de conta e de livro-razão no design de sua infraestrutura de blockchain. A flexibilidade desse 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. Isso é um pouco semelhante ao modelo de abstração de conta do Ethereum, mas é mais flexível e geral. Na TON, as contas não são meros recipientes para ativos; elas também incluem código de contrato e dados de estado. Cada conta compreende seu código, dados e lógica de manipulação de mensagens.

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

Flexibilidade: Como cada conta pode executar 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é mesmo 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 do livro-razão

A estrutura do livro-razão do TON é projetada para lidar eficientemente com transações concorrentes em grande escala, suportando a passagem assíncrona de mensagens 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 por meio de uma árvore de Merkle para garantir integridade e segurança. Este design também suporta consultas e verificação eficientes de estados, especialmente em transações inter-shard.

Um estado de conta ou contrato inteligente normalmente 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 de bytes brutos 6. Carimbo de data/hora recente dos 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 dessa conta (opcional; por padrão, é igual à account_id em si). Em alguns casos, códigos de verificação de assinatura mais complexos podem ser encontrados aqui, semelhantes às saídas de transações 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 todas as contas devem 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 produto de soma é definido durante a criação de uma cadeia de trabalho, usando diferentes bytes de marcação para distinguir várias "funções construtoras". Em última análise, o estado da conta é salvo como uma coleção de unidades no armazenamento persistente do TVM.

Passagem e processamento de mensagens

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

Modelo de gás

TON (The Open Network) otimiza significativamente a eficiência de execução de contratos inteligentes por meio de seu modelo exclusivo de taxa de gás. Este modelo de taxa de gás é usado para medir e limitar os recursos consumidos durante a execução do contrato inteligente. Em comparação com 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 do contrato.

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 medições detalhadas para recursos como computação, armazenamento e mensagens, o modelo de gás da TON impede que operações com complexidade excessiva consumam muitos recursos. Ao limitar o consumo de gás, a TON garante que cada nó de rede possa alocar justamente recursos computacionais, evitando o uso excessivo de recursos de rede por um único contrato ou operação.

TON suporta processamento paralelo de contratos inteligentes, permitindo que vários contratos sejam executados simultaneamente em shards diferentes sem bloqueio mútuo. Nesse design, o modelo de gas é integrado de perto com os mecanismos de execução paralela e shard. Ao processar contratos em paralelo em múltiplos shards, o TON pode distribuir o cálculo de gas e o pagamento entre nós e cadeias diferentes, 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 em horários de menor movimento e equilibrando o uso dos recursos da rede. Esse mecanismo não apenas melhora a experiência do usuário, mas também controla o uso de recursos de pico por meio de uma abordagem orientada pelo mercado.

Contratos inteligentes da TON são fáceis de ignorar brechas

Em nosso artigo anterior de análise de segurançano TON, detalhamos as vulnerabilidades comuns de segurança dentro do ecossistema TON. Para mais informações, consulte a tabela abaixo:

Este artigo vai se concentrar nas vulnerabilidades nos contratos TON que muitas vezes são negligenciadas, conforme resumido pela nossa equipe:

(1) Otimização de Legibilidade de 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, é recomendável definir valores numéricos importantes como constantes nomeadas. Por exemplo, defina 0x18comoNON_BOUNCEABLE.

1. verificar_endereço_std(endereço); foi msg = begin_cell() armazenar_uint(0x18, 6) ;; nobounce armazenar_slice(endereço) armazenar_moedas(valor) armazenar_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

Em 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:

Observe queend_parse() é usado para verificar se uma fatia de dados está vazia. Se a fatia não estiver vazia, a função lançará uma exceção. Isso garante que o formato e o conteúdo dos dados estejam conforme o esperado. Se o end_parse()A função detecta dados restantes na fatia, pode indicar que o parsing de dados não prosseguiu conforme o pretendido ou que há um problema com o formato dos dados. Portanto, ao chamar end_parse()Você pode verificar se há alguma omissão ou anomalia durante o processo de análise.

(3) Exceções Causadas por Armazenamento de Dados e Tipos Não Correspondentes

Isso se refere principalmente à correspondência deint e Uinttipos de armazenamento. Por exemplo, no código a seguir, ostore_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 deinline_refeinlineModificadores

Primeiramente, é importante distinguir entre osem linha e inline_refmodificadores:

em linha: Funções com a em linhaOs modificadores têm seu código inserido diretamente no local de 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, a TVM executa o código armazenado na célula através daCALLREFcomando, 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 chamadas, mas esteja ciente da possível duplicação de código. Use inline_ref para funções maiores ou frequentemente chamadas para melhorar a eficiência e evitar a repetição de código.

(5) Determinando a Workchain Correta

TON permite a criação de até 2^32 workchains, cada uma das quais pode ser subdividida em até 2^60 shards. Inicialmente, existem duas workchains: a masterchain (-1) e a basechain (0). Ao computar endereços de destino em contratos, é crucial especificar o ID correto da workchain para garantir que o endereço da carteira gerada esteja na workchain correta. Para evitar a geração de endereços incorretos, é recomendado usar force_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 para garantir consistência e evitar confusão. Para contratos inteligentes TON, certifique-se de que cada código de erro seja único dentro do contrato para evitar conflitos e mensagens de erro ambíguas. Além disso, evite conflitos com os códigos de erro padrão definidos pela plataforma TON ou pelo 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 chamadas return()Após a conclusão da operação

Nos contratos inteligentes TON, o tratamento de mensagens envolve a seleção de lógicas diferentes com base no código operacional. Depois de concluir a lógica correspondente, duas etapas adicionais são necessárias: primeiro, se os dados tiverem sido modificados, chame save_data()para garantir que as alterações sejam armazenadas; caso contrário, as alterações serão ineficazes. Em segundo lugar, chame retorno()para indicar que a operação foi concluída; caso contrário, umlançar(0xffff)será acionada uma exceção.

() recv_internal(int meu_saldo, int valor_msg, cell in_msg_completo, slice in_msg_corpo) impuro {

int flags = cs~load_uint(4);

if (flags & 1) {

;; ignorar todas as mensagens rejeitadas

return ();

}

slice sender_address = cs~load_msg_addr();

carregar_dados();

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 ignoradas. Os desenvolvedores devem entender 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 totalmente realizadas, construindo aplicativos descentralizados mais seguros e confiáveis e salvaguardando o desenvolvimento saudável de todo o ecossistema.

O ecossistema TON está atualmente experimentando um rápido crescimento, atraindo financiamento significativo e usuários ativos. No entanto, as questões de segurança que o acompanham não podem ser ignoradas. Para garantir a segurança e confiabilidade 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 dentro do ecossistema TON. Anteriormente, Beosin conduziu auditorias de segurança minuciosas para o principal projeto de stablecoin descentralizada Aqua Protocol e a infraestrutura DeFi ONTON Finance. A auditoria abrangeu vários aspectos, incluindo a segurança do código de contrato inteligente, correção da implementação lógica de negócios, otimização de gás do código do contrato e detecção e remediação de vulnerabilidades potenciais.

Declaração:

1. Este artigo é reproduzido de [Beosin], título original "Beosin Hard Core Research | Do Risco à Proteção: Riscos de Segurança e Sugestões de Otimização da TON Smart Contracts》, os direitos autorais pertencem ao autor original [Beosina ], se você tiver alguma objeção à reimpressão, entre em contato Equipe Gate LearnA equipe irá cuidar disso o mais rápido possível de acordo com os procedimentos relevantes.

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

3. Outras versões do artigo são traduzidas pela equipe Gate Learn e não são mencionadas em Gate.io, o artigo traduzido não pode ser reproduzido, distribuído ou plagiado.