Guia do TON para iniciantes: contas, tokens e segurança
Histórico
A TON (The Open Network) é uma plataforma de blockchain descentralizada, inicialmente projetada e desenvolvida pela equipe do Telegram. O objetivo da TON é fornecer uma plataforma de blockchain escalável e de alto desempenho para dar suporte a aplicativos descentralizados (DApps) e contratos inteligentes em grande escala.
A TON é única por ser fácil de usar, profundamente integrada ao Telegram, permitindo que pessoas comuns usem tokens com facilidade. Ao mesmo tempo, é complexa, com uma arquitetura distinta de outras blockchains, e usa uma linguagem de contrato inteligente não convencional chamada FunC.
Hoje, discutiremos as características do TON e a segurança dos ativos do usuário a partir das perspectivas de contas, tokens e transações.
Características da TON
Geração de contas
O método de geração de um endereço de conta na TON é diferente da maioria das cadeias de blocos; é um endereço de contrato inteligente. Primeiro, tudo começa com uma chave privada. A TON usa principalmente o algoritmo Ed25519 para gerar uma chave pública, com o processo da seguinte forma:
Há duas formas de chave pública: uma é a chave pública bruta calculada a partir da chave privada, que tem a seguinte aparência:
E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D
A outra é uma chave pública “embelezada”, que inclui algumas informações e bits de verificação, e tem a seguinte aparência:
Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2
Se você acha que apenas obter a chave pública permitirá que você obtenha o endereço da conta como na Ethereum, está enganado. O simples fato de ter a chave pública do usuário não é suficiente para calcular o endereço da conta do usuário.
Conforme mencionado, o endereço da conta do usuário é um endereço de contrato inteligente, mas como é possível implementar um contrato inteligente sem ter uma conta?
A sequência correta é primeiro calcular o endereço, receber uma quantidade inicial de tokens e depois implantar o contrato. O processo de cálculo do endereço da conta é mostrado no diagrama a seguir:
O endereço de um usuário também vem em várias formas. Primeiro, há a forma bruta, que se parece com:
0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296
Em seguida, há um formulário fácil de usar, que se parece com:
Rede principal:
- Ressaltável:
EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX - Não resgatável:
UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S
Testnet:
- Ressaltável:
kQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilvhd - Não resgatável:
0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY
Observando cuidadosamente esses endereços, você pode ver que eles diferem apenas no primeiro e no último caractere, sendo que o account_id do meio é o mesmo.
No entanto, ainda não é possível ver a relação entre a chave pública e o endereço da conta.
O segredo está no initial data no início, que contém a chave pública de um usuário, permitindo que ele controle o contrato da carteira. O workchainId é fácil de entender; a TON não é apenas uma cadeia única, mas consiste em muitos fragmentos.
Cada fragmento é uma parte de toda a rede, lidando com contas e transações específicas. Para localizar e gerenciar contratos inteligentes, é necessário especificar em qual shard eles estão. Qual é a diferença entre Bounceable e Non-bounceable?
Isso está relacionado à forma como smart contracts funciona, mas vamos continuar analisando.
Contrato da carteira
Abaixo está um trecho do código-fonte de um contrato de carteira de usuário. Ele mostra que, ao receber uma mensagem do usuário, ele lê quatro parâmetros: stored_seqno, stored_subwallet, public_key e plugins:
wallet-v4-code.fc
() recv_external(slice in_msg) impure {
var signature = in_msg~load_bits(512);
var cs = in_msg;
var (subwallet_id, valid_until, msg_seqno) = (cs~load_uint(32), cs~load_uint(32), cs~load_uint(32));
throw_if(36, valid_until <= now());
var ds = get_data().begin_parse();
var (stored_seqno, stored_subwallet, public_key, plugins) = (ds~load_uint(32), ds~load_uint(32), ds~load_uint(256), ds~load_dict()); ;;##The Initial Data
ds.end_parse();
throw_unless(33, msg_seqno == stored_seqno);
throw_unless(34, subwallet_id == stored_subwallet);
throw_unless(35, check_signature(slice_hash(in_msg), signature, public_key));
//...
}Na verdade, quando esse contrato de carteira de usuário é implantado, ele exige alguns parâmetros iniciais, incluindo um public_key de 256 bits. Isso garante que cada usuário tenha um endereço de contrato exclusivo, mesmo quando estiver usando o mesmo código de contrato.
Toda transação iniciada pelo usuário deve ser assinada com in_msg e, em seguida, verificada pelo contrato da carteira (check_signature), após o que o contrato executará operações no blockchain. A partir disso, podemos deduzir que a chave pública de um usuário pode corresponder a vários endereços de carteira.
A implementação de contratos de carteira diferentes ou o uso de dados de inicialização diferentes resultará em endereços de contrato totalmente diferentes.
Token Jetton
Um token representa um ativo na blockchain, o que o torna um elemento fundamental que precisamos entender. O Jetton é a forma padrão dos tokens TON e é composto de dois contratos: Jetton-minter e Jetton-wallet.
Quando um token é emitido, é criado um contrato Jetton-minter. Essa inicialização do contrato registra informações como o fornecimento total de tokens, o administrador, o código da carteira e outros detalhes.
Quando os tokens são distribuídos aos usuários, o contrato do Minter implementa um contrato de carteira para cada usuário. Durante a inicialização do contrato, ele registra o saldo do usuário, a propriedade, o endereço do contrato Minter do token, o código da carteira do usuário e outras informações relevantes. Cada usuário tem um contrato implantado individualmente.
É importante observar que o contrato criado aqui é um contrato de carteira para gerenciar tokens Jetton específicos, que é diferente do contrato de carteira da conta do usuário. O owner_address registrado aqui é o endereço da carteira da conta do usuário.
Quando a usuária Alice transfere tokens para o usuário Bob, a relação de invocação é a seguinte:
Alice assina a transação por meio de um aplicativo fora da cadeia e envia um comando operacional por meio do contrato de sua carteira. Esses comandos também invocarão sua carteira de tokens para executar a transferência. Quando a carteira de tokens de Bob recebe os tokens, ela notifica o contrato da carteira de Bob (o endereço do proprietário da Jetton-wallet de Bob).
Se houver alguma sobra de gás durante a transação, ela será devolvida ao endereço apropriado, geralmente o contrato da conta de Alice.
Abaixo está um exemplo de uma transferência de token Jetton analisada pelo navegador Tonviewer:
Enquanto uma transferência ERC20 requer apenas uma única invocação de contrato, uma transferência de token Jetton requer pelo menos quatro invocações de contrato. Esse método foi projetado para permitir a simultaneidade na cadeia, melhorando a eficiência da transação.
Transações
Quando um determinado evento ocorre em uma conta TON, ele aciona uma transação. O evento mais comum é “receber uma mensagem”. Uma transação inclui os seguintes elementos:
- A mensagem recebida que aciona inicialmente o contrato (com métodos de acionamento especiais disponíveis).
- Ações do contrato resultantes da mensagem recebida, como a atualização do armazenamento do contrato (opcional).
- Mensagens de saída enviadas a outros participantes (opcional).
Há vários recursos importantes que devem ser observados em relação às transações:
- Assíncrono: As transações TON não são concluídas em uma única chamada; elas podem exigir a passagem de mensagens para vários contratos inteligentes diferentes para executar uma série de chamadas. Devido ao roteamento diferente nas cadeias fragmentadas, a TON não pode garantir a ordem de entrega de mensagens entre vários contratos inteligentes.
- Taxas: A natureza assíncrona das transações introduz um desafio na estimativa das taxas consumidas. Portanto, as carteiras geralmente enviam um pouco mais de token como taxa ao iniciar uma transação. Se o contrato chamado tiver um bom mecanismo de tratamento de taxas, as taxas restantes serão devolvidas à carteira do usuário. Os usuários podem perceber que os tokens de suas carteiras diminuem repentinamente e aumentam novamente após alguns minutos, o que se deve a esse mecanismo.
- Saltar: Bounce é um mecanismo de tratamento de erros em contratos. Se o contrato chamado não existir ou lançar um erro e a transação for definida como passível de devolução, uma mensagem de devolução será retornada ao contrato de chamada. Por exemplo, se um usuário iniciar uma transferência e ocorrer um erro durante o processo, será necessária uma mensagem de devolução para que o contrato da carteira do usuário possa restaurar seu saldo. Quase todas as mensagens internas enviadas entre contratos inteligentes devem ser devolvidas, o que significa que elas devem ter o bit “bounce” definido.
Segurança de ativos
A TON tem muitos recursos que podem levar a problemas de segurança, portanto, os usuários precisam estar cientes de algumas armadilhas comuns.
Ataque à retenção de taxas
Conforme mencionado, as carteiras geralmente precisam enviar uma pequena taxa extra para evitar falhas na transação, o que oferece uma oportunidade para os invasores. Se você é usuário de uma carteira TON, talvez tenha se deparado com uma situação em que sua carteira recebe frequentemente vários NFTs ou tokens.
Inicialmente, esses tokens podem parecer lixo, mas ao verificar os detalhes da transação, você descobre que eles podem ser vendidos por uma quantia significativa de dinheiro. No entanto, ao tentar iniciar uma transação, você percebe que a taxa exigida é extremamente alta (1 TON). Nesse momento, você deve ser cauteloso, pois pode se tratar de um golpe de taxa.
Os invasores criam um contrato de token cuidadosamente elaborado que faz com que a carteira estime uma taxa de transferência excessivamente alta, mas, na realidade, apenas a taxa é retida e nenhuma mensagem de transferência é enviada.
Phishing do primeiro e do último dígito
O phishing de primeiro e último dígitos não é exclusivo da TON; esse ataque de phishing existe em muitas das principais blockchains. Os invasores geram uma conta falsa para cada endereço de usuário na rede com os mesmos primeiro e último dígitos.
Quando um usuário inicia uma transferência, o invasor também envia uma pequena transferência, seguindo a transação do usuário, para deixar um registro no histórico de transações do usuário. Quando o usuário destinatário deseja enviar tokens de volta, ele pode copiar o endereço do histórico de transações, que pode ser o endereço do invasor, levando a uma transferência para o endereço errado. O invasor explorou com precisão o comportamento do usuário.
Comentário Phishing
Ao transferir tokens na TON, os usuários podem adicionar um comentário para anotar a transação. Esse recurso é frequentemente usado ao fazer depósitos em bolsas, onde as bolsas geralmente exigem que os usuários incluam seu ID de usuário no comentário do depósito. No entanto, esse recurso é frequentemente explorado por agentes mal-intencionados, que escrevem informações fraudulentas nos comentários para roubar os ativos dos usuários. Por exemplo:
Os usuários devem ser especialmente cautelosos com o NFT “Anonymous Telegram Number”. Se um usuário ativar sua conta do Telegram com um Número Anônimo do Telegram, mas não ativar a Verificação em Duas Etapas, e esse NFT for vítima de phishing, o hacker poderá fazer login diretamente na conta-alvo do Telegram e prosseguir com o roubo de ativos e atividades fraudulentas subsequentes.
Vulnerabilidades de contratos inteligentes
As vulnerabilidades de segurança em contratos inteligentes podem levar à perda de fundos armazenados no contrato. Os usuários devem escolher projetos que tenham passado por uma auditoria completa. Os contratos inteligentes da TON são programados principalmente usando a linguagem FunC, embora alguns usem o Tact mais avançado ou o Fift de nível inferior.
Todas essas linguagens são altamente originais. As novas linguagens de programação trazem novos riscos de segurança, principalmente para os desenvolvedores, que precisam praticar hábitos de codificação seguros, dominar as práticas recomendadas de segurança e passar por rigorosas auditorias de segurança antes de implantar no ambiente de produção. Devido a restrições de espaço, este artigo não discutirá a segurança de contratos em detalhes.
Ataque de depósito falso
Os usuários de carteiras ou bolsas devem estar cientes dos ataques de depósitos falsos, que geralmente ocorrem de duas formas:
- Tokens falsos: Um invasor emite um token com metadados idênticos ao token de destino. Se o programa de depósito automatizado não verificar se o token é do contrato de mineração correto, isso pode levar a depósitos incorretos.
- Saltar: O processo de transferência da TON requer uma relação de invocação entre os contratos de carteira de dois usuários. Se o contrato de carteira do destinatário não existir e a transação for definida como passível de devolução, a mensagem será devolvida e os fundos originais, menos a taxa, serão devolvidos ao remetente. Os interessados nos detalhes podem consultar nosso artigo anterior sobre depósitos falsos.
Conclusão
Este artigo apresentou alguns princípios técnicos fundamentais da TON a partir das perspectivas de criação de chaves e carteiras, formas de tokens e características de transações. Ele também explorou possíveis problemas de segurança ao usar a TON, esperando inspirar sua jornada de aprendizado.