Por: Johan

fondo

TON (The Open Network) es una plataforma blockchain descentralizada diseñada y desarrollada originalmente por el equipo de Telegram. El objetivo de TON es proporcionar una plataforma blockchain escalable y de alto rendimiento para admitir aplicaciones descentralizadas (DApps) a gran escala y contratos inteligentes.

TON es muy especial. Es fácil de usar. Está profundamente integrado con Telegram, lo que facilita el uso de tokens para la gente común. También es complejo. Tiene una arquitectura completamente diferente a la de otras cadenas de bloques y utiliza FunC no convencional. lenguaje del contrato. Hoy discutiremos las características de TON y los problemas de seguridad de los activos de los usuarios desde la perspectiva de cuentas, tokens y transacciones.

Características de la tonelada

Generación de cuenta

La dirección de la cuenta TON se genera de manera diferente a la mayoría de las cadenas de bloques. Es una dirección de contrato inteligente. Primero, inicie una clave privada. TON utiliza principalmente el algoritmo Ed25519 para generar una clave pública. El proceso de generación es el siguiente:

Hay dos formas de claves públicas. Una es la clave pública original calculada a partir de la clave privada, que tiene el siguiente aspecto:

E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D

La otra es la clave pública "embellecida", que contiene cierta información y dígitos de verificación de la clave pública, en la forma: Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2

Sería demasiado ingenuo pensar que se puede obtener la dirección de la cuenta como Ethereum obteniendo la clave pública. Simplemente tener la clave pública del usuario no es suficiente para calcular la dirección de la cuenta del usuario. Acabamos de decir que la dirección de la cuenta del usuario es una dirección de contrato inteligente, pero ni siquiera tenemos una cuenta. ¿Cómo podemos implementar un contrato inteligente? La secuencia correcta es calcular primero la dirección, recibir una cantidad inicial de tokens y luego poder implementar el contrato. El proceso de cálculo de la dirección de la cuenta se muestra en la siguiente figura:

La dirección del usuario también viene en muchas formas. La primera es la forma original, que se ve así:

0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296

y un formulario fácil de usar, como:

Red principal: rebotable: EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX No rebotable: UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4STestnet: rebotable: kQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilvhd No rebotable: 0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY

Si observa cuidadosamente estas direcciones, puede ver que solo difieren en el primer y último carácter, y el `account_id` en el medio es el mismo. Sin embargo, todavía no podemos ver la relación entre la clave pública y la dirección de la cuenta. De hecho, el misterio radica en que los "datos iniciales" al principio contienen la clave pública de un usuario, a través de la cual el usuario controla la propiedad del contrato de billetera. `workchainId` es fácil de entender. TON no es solo una cadena única. Está compuesto por muchos fragmentos. Cada fragmento es parte de toda la red y maneja un conjunto específico de cuentas y transacciones. Para poder localizar y gestionar contratos inteligentes, es necesario indicar claramente en qué fragmento se encuentran. ¿Cuál es la diferencia entre "rebotable" y "no rebotable"? Esto está relacionado con el mecanismo de funcionamiento de los contratos inteligentes, sigamos mirando a continuación.

contrato de billetera

El siguiente es el código fuente de un contrato de billetera de usuario. Puede ver que lee 4 parámetros (stored_seqno, almacenado_subwallet, public_key, complementos) al recibir el mensaje del usuario:

código-de-billetera-v4.fc

() recv_external(slice in_msg) impuro { var firma = in_msg~load_bits(512); var cs = in_msg; var (id_subwallet, válido_hasta, msg_seqno) = (cs~load_uint(32), cs~load_uint(32), cs~load_uint(32)); throw_if(36, válido_hasta <= now()); var ds = get_data().begin_parse(); var (num_seqno_almacenado, subwallet_almacenado, clave_pública, complementos) = (ds~load_uint(32), ds~load_uint(32), ds~load_uint(256), ds~load_dict()); ;;#Losdatos iniciales 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), firma, clave_pública)); //...}

Así es, al implementar el contrato de billetera de este usuario, debe pasar algunos parámetros iniciales, que incluyen información de clave pública de 256 bits. Esto garantiza que cada usuario tenga un contrato independiente cuando use la misma dirección de contrato. Todas las transacciones iniciadas por los usuarios deben firmar `in_msg` y luego, después de verificar la firma (check_signature) a través de su propio contrato de billetera, el contrato llamará a todas las operaciones en la cadena. De aquí también podemos inferir que la clave pública de un usuario en realidad puede corresponder a innumerables direcciones de billetera. Solo necesita implementar billeteras con diferentes códigos fuente o diferentes datos de inicialización para obtener direcciones de contrato completamente diferentes.

Ficha Jetton

El token es la representación de activos en la cadena, por lo que es un elemento básico que debemos comprender. Jetton es la forma estándar de token TON. Jetton consta de dos contratos, Jetton-minter y Jetton-wallet:

Cuando se emite un token, se creará un contrato Jetton-minter. La inicialización del contrato registra la cantidad total de tokens, administradores, códigos de billetera y otra información.

Cuando los tokens se distribuyen a los usuarios, el contrato de Minter implementará un contrato de billetera para el usuario y registrará el saldo del usuario, la propiedad, la dirección del contrato de Minter del token, el código de billetera del usuario y otra información cuando se inicialice el contrato. Cada usuario implementará un contrato. de forma independiente. Tenga en cuenta que el contrato creado aquí es un contrato de billetera que se utiliza para administrar un token Jetton específico, que es diferente del contrato de billetera de la cuenta del usuario. La dirección del propietario aquí registra la dirección de la billetera de la cuenta del usuario.

Cuando la usuaria Alice transfiere dinero al usuario Bob, la relación de llamada es la siguiente:

Alice firma la aplicación fuera de la cadena y emite instrucciones de operación llamando a su contrato de billetera. Estas instrucciones llaman además a su billetera de tokens para realizar la transferencia. Cuando la billetera de tokens de Bob reciba el token, notificará al contrato de billetera de Bob (es decir, la dirección del propietario de la billetera de Bob Jetton). Si queda Gas restante durante la transacción, se devolverá a la dirección de respuesta, generalmente el contrato de cuenta de Alice.

Esta es una transferencia de token Jetton analizada por el navegador Tonviewer:

Una transferencia ERC20 solo necesita llamar al menos a un contrato, mientras que una transferencia de token Jetton necesita llamar al menos a cuatro contratos. Esto se hace para permitir que las transferencias se realicen simultáneamente en la cadena y mejorar la eficiencia de las transacciones.

comercio

Cuando algo le sucede a una cuenta en TON, se activa una transacción. El evento más común es "recibir un mensaje". La transacción incluye lo siguiente:

• El mensaje entrante que activa inicialmente el contrato (existe un método de activación especial)

• Acciones del contrato causadas por mensajes entrantes, como actualizar el almacenamiento del contrato (opcional)

• Mensajes salientes a otros participantes (opcional)

Hay varias características a las que debes prestar atención al operar:

1. Asíncrono: las transacciones TON no se completan en una sola llamada. Es posible que sea necesario pasar mensajes a varios contratos inteligentes diferentes para ejecutar una serie de llamadas. Debido al diferente enrutamiento en las cadenas de fragmentos, TON no puede garantizar el orden de entrega de mensajes entre múltiples contratos inteligentes.

2. Tarifas de manejo: la característica asincrónica también trae un problema, es decir, las tarifas de manejo consumidas son difíciles de estimar. Por lo tanto, al iniciar una transacción, la billetera generalmente envía algunos tokens más como tarifas de manejo. Si el contrato llamado tiene un buen mecanismo de tarifas de manejo, las tarifas de manejo restantes eventualmente se devolverán a la billetera del usuario. Los usuarios pueden observar que sus tokens de billetera repentinamente disminuyen y luego aumentan después de unos minutos, por este motivo.

3. Rebote: el rebote es un mecanismo de manejo de errores del contrato. Cuando el contrato de llamada no existe o arroja un error, si la transacción está configurada para rebotar, el mensaje devuelto se devolverá al contrato de llamada. Por ejemplo, si un usuario inicia una transferencia y se produce un error en el proceso de llamada, se necesita un mensaje de rebote para que el contrato de billetera del usuario pueda restaurar su saldo. Casi todos los mensajes internos enviados entre contratos inteligentes deberían ser rebotables, es decir, su bit de "rebote" debería estar configurado.

Seguridad de activos

TON tiene muchas características que pueden causar problemas de seguridad, por lo que los usuarios también deben ser conscientes de algunos errores comunes.

Ataque de interceptación de tarifas

Como se mencionó anteriormente, las billeteras a menudo necesitan enviar más tarifas de manejo para evitar fallas en la ejecución de transacciones, lo que permite a los atacantes encontrar oportunidades para hacer el mal. Si es usuario de una billetera TON, es posible que se haya encontrado con esta situación. Siempre recibe varios NFT o tokens en su billetera. Pensó que eran solo algunos lanzamientos aéreos de tokens basura, pero cuando verificó la información de la transacción, descubrió que no podía. venderlos. ¿Menos dinero? Sin embargo, al iniciar una transacción, descubre que la tarifa de procesamiento requerida es extremadamente alta (1 TONELADA). En este momento, debe prestar atención. Esto puede ser un fraude en la tarifa de procesamiento.

El atacante utilizó un contrato simbólico cuidadosamente construido para hacer que la tarifa de transferencia estimada de la billetera fuera extremadamente alta, pero durante la ejecución real, solo retuvo la tarifa y no envió un mensaje de transferencia.

Pesca del primer y último número.

El phishing de números de cabeza y cola no es exclusivo de TON. Este tipo de ataque de phishing existe en todas las principales cadenas públicas. El atacante generará una cuenta de alta imitación con el mismo primer y último número para cada dirección de usuario en toda la red. Cuando el usuario envía una transferencia, el atacante también usará la cuenta de alta imitación para enviar una pequeña transferencia en la dirección del usuario. recibo. Dejar constancia en el registro de pago. Cuando el usuario receptor desea devolver un token, puede copiar la dirección del registro histórico. En este momento, es probable que se copie a la dirección del atacante, lo que provocará que la transferencia a la dirección incorrecta pueda predecir con precisión. el comportamiento del usuario.

comentar pesca

TON puede agregar un comentario al transferir dinero para anotar la información de la transacción. Esta función se usa con frecuencia cuando se recarga en intercambios que generalmente requieren que los usuarios anoten la identificación del usuario al recargar. Sin embargo, esta función a menudo se explota de forma maliciosa, y los atacantes defraudan a los usuarios con sus activos escribiendo información fraudulenta en notas. Como se muestra en la imagen:

Los usuarios deben prestar especial atención al NFT del número de Telegram anónimo. Si el usuario utiliza el número de Telegram anónimo para abrir una cuenta de TG pero no abre la verificación en dos pasos, una vez que se elimina el NFT, los piratas informáticos pueden iniciar sesión directamente en el TG de destino. cuenta y realizar posterior sustracción de activos y conductas engañosas.

Vulnerabilidad del contrato inteligente

Las vulnerabilidades de seguridad en los contratos inteligentes dañarán los fondos de los usuarios colocados en los contratos inteligentes. Los usuarios deben elegir proyectos bien auditados al elegir proyectos. Los contratos inteligentes de TON se programan principalmente utilizando el lenguaje FunC, pero también utilizan el Tact más avanzado o el Fift de nivel inferior, todos ellos lenguajes muy originales. Los nuevos lenguajes de programación traerán nuevos riesgos de seguridad. Especialmente para los desarrolladores, deben tener buenos hábitos de programación segura, dominar las mejores prácticas de seguridad y someterse a estrictas auditorías de seguridad antes de implementarlos en el entorno de producción. Debido a limitaciones de espacio, analicemos este artículo. No discutiremos la seguridad del contrato por ahora. El equipo de seguridad de SlowMist ha lanzado el servicio de auditoría de seguridad de contrato inteligente TON, y los amigos con necesidades de auditoría pueden discutirlo.

Ataque de recarga falso

Los usuarios de billeteras o exchanges deben prestar atención a los ataques de depósitos falsos. Generalmente existen dos tipos de ataques de depósitos falsos:

• Para las monedas falsificadas, el atacante emite un token con los mismos metadatos que el token de destino. Si el programa de entrada automatizada no comprueba si se trata del contrato de acuñación correcto, se producirá una entrada incorrecta.

• Rebote, el proceso de transferencia de TON requiere una relación de llamada entre los contratos de billetera de los dos usuarios. Si el contrato de billetera del destinatario no existe y la transacción está configurada como Rebotable, el mensaje será rebotado y los fondos originales se deducirán del. Tarifa de manipulación. Devolución al remitente. Los amigos que estén interesados ​​en los detalles pueden consultar el artículo sobre recargas falsas que hemos revelado anteriormente.

Resumir

Este artículo presenta algunos principios técnicos básicos de TON desde la perspectiva de la creación de claves públicas y privadas, contratos de billetera, formas de tokens, características de transacciones, etc. de TON, y también analiza posibles problemas de seguridad en el proceso de uso de TON. Espero que pueda ayudar. todos aprenden.

Enlaces de referencia:

https://docs.ton.org/

https://github.com/ton-blockchain/wallet-contract