En el campo de la tecnología de blockchain en rápida evolución, TON (The Open Network) está ganando cada vez más atención de los desarrolladores como una plataforma de blockchain eficiente y flexible. La arquitectura y las características únicas de TON proporcionan herramientas poderosas y ricas posibilidades para el desarrollo de aplicaciones descentralizadas.

Sin embargo, con el aumento en la funcionalidad y complejidad, la seguridad de los contratos inteligentes se ha vuelto más crítica. FunC, el lenguaje de programación de contratos inteligentes en TON, es conocido por su flexibilidad y eficiencia, pero también presenta muchos riesgos y desafíos potenciales. Escribir contratos inteligentes seguros y confiables requiere que los desarrolladores tengan un profundo entendimiento de las características de FunC y los riesgos potenciales involucrados.

Este artículo proporcionará un análisis detallado de las características relacionadas con los contratos inteligentes en la cadena de bloques TON, así como las vulnerabilidades en los contratos inteligentes de TON que a menudo pasan desapercibidas.

Análisis de las características asincrónicas y el mecanismo de cuenta de TON

Llamadas asincrónicas en contratos inteligentes

Fragmentación de red y comunicación asincrónica

El blockchain TON está diseñado con tres tipos de cadenas: Masterchain, Workingchains y Shardchains.

La Masterchain es el núcleo de toda la red, responsable de almacenar los metadatos y el mecanismo de consenso de toda la red. Registra los estados de todos los Workingchains y Shardchains y asegura la consistencia y seguridad de la red. Workingchains son blockchains independientes, con un máximo de 2^32 cadenas, responsables de manejar tipos específicos de transacciones y contratos inteligentes. Cada Workingchain puede tener sus propias reglas y características para satisfacer diferentes necesidades de aplicación. Shardchains son subcadenas de Workingchains, utilizadas para dividir aún más la carga de trabajo de Workingchains, mejorando la capacidad de procesamiento y escalabilidad. Cada Workingchain se puede dividir en hasta 2^60 Shardchains, con Shardchains manejando algunas transacciones de forma independiente para lograr un procesamiento paralelo eficiente.

En teoría, cada cuenta puede ocupar exclusivamente un Shardchain, con cada cuenta manteniendo de forma independiente su saldo de COIN/TOKEN. Las transacciones entre cuentas pueden ser completamente paralelizadas. Las cuentas se comunican a través de mensajes asíncronos, y el camino para que los mensajes viajen entre Shardchains es log_16(N) - 1, donde N es el número de Shardchains.

Fuente de imagen: https://frontierlabzh.medium.com/ton-weixin-e1d3ae3b3574En Ton, las interacciones se llevan a cabo mediante el envío y recepción de mensajes. Estos mensajes pueden ser internos (enviados típicamente por contratos inteligentes que interactúan entre sí) o externos (enviados por fuentes externas). El proceso de envío de mensajes no requiere respuestas inmediatas del contrato de destino, lo que permite al remitente continuar ejecutando la lógica restante. Este mecanismo de mensajería asíncrona ofrece una mayor flexibilidad y escalabilidad en comparación con las llamadas sincrónicas de Ethereum, reduciendo los cuellos de botella de rendimiento causados por la espera de respuestas, y también presenta desafíos en el manejo de la concurrencia y las condiciones de carrera.

Formato y estructura del mensaje

En TON, los mensajes suelen incluir información como el remitente, el destinatario, la cantidad y el cuerpo del mensaje. El cuerpo del mensaje puede consistir en llamadas de función, transferencias de datos u otro contenido personalizado. El formato de mensaje de TON está diseñado para ser flexible y extensible, lo que permite una comunicación eficiente de varios tipos de información entre diferentes contratos.

Cola de mensajes y procesamiento de estado

Cada contrato mantiene una cola de mensajes para almacenar los mensajes que aún no se han procesado. Durante la ejecución, el contrato procesa los mensajes uno por uno de la cola. Dado que el procesamiento de mensajes es asíncrono, el estado del contrato no se actualizará inmediatamente al recibir un mensaje.

Ventajas del mensaje asincrónico

• Mecanismo de fragmentación eficiente: el mecanismo asincrónico de TON es altamente compatible con su diseño de fragmentación. Cada fragmento maneja de forma independiente los mensajes de contrato y los cambios de estado, evitando retrasos causados por la sincronización entre fragmentos. Este diseño mejora el rendimiento general de la red y la escalabilidad.

•Reducción del consumo de recursos: los mensajes asíncronos no requieren respuestas inmediatas, lo que permite que los contratos TON se ejecuten en varios bloques y eviten un consumo excesivo de recursos dentro de un solo bloque. Esto permite que TON admita contratos inteligentes más complejos y que requieren más recursos.

•Tolerancia a fallos y fiabilidad: El mecanismo de paso de mensajes asincrónicos aumenta la tolerancia a fallos del sistema. Por ejemplo, si un contrato no puede responder a un mensaje de manera oportuna debido a limitaciones de recursos u otras razones, el remitente puede continuar procesando otra lógica, evitando que el sistema se detenga debido a retrasos en un solo contrato.

Desafíos del diseño de contratos asincrónicos

•Problemas de Consistencia de Estado: Debido a la naturaleza asincrónica del paso de mensajes, los contratos pueden recibir mensajes diferentes en momentos diferentes, lo que requiere que los desarrolladores presten especial atención a la consistencia del estado. Al diseñar contratos, es crucial considerar cómo diferentes órdenes de mensajes podrían afectar los cambios de estado y asegurar que el sistema mantenga la consistencia en todas las condiciones.

•Condiciones de carrera y protección: El procesamiento asincrónico de mensajes introduce posibles problemas de condiciones de carrera, donde múltiples mensajes podrían intentar modificar simultáneamente el estado del contrato. Los desarrolladores deben implementar mecanismos de bloqueo adecuados o utilizar operaciones transaccionales para evitar conflictos de estado.

•Consideraciones de seguridad: Los contratos asincrónicos son susceptibles a riesgos como ataques de intermediarios o ataques de repetición al manejar la comunicación entre contratos. Por lo tanto, al diseñar contratos asincrónicos, es esencial abordar estos posibles riesgos de seguridad y tomar medidas preventivas, como el uso de marcas de tiempo, números aleatorios o enfoques de firma múltiple.

modelo de contabilidad

TON (The Open Network) emplea un modelo único de abstracción de cuentas y de libro mayor al diseñar su infraestructura de blockchain. La flexibilidad de este modelo se refleja en cómo gestiona los estados de cuenta, el envío de mensajes y la ejecución de contratos.

abstracción de cuenta

El modelo de cuenta de TON utiliza una abstracción basada en contratos, donde cada cuenta se puede ver como un contrato. Esto es algo similar al modelo de abstracción de cuentas de Ethereum pero es más flexible y general. En TON, las cuentas no son simplemente contenedores de activos; también incluyen código de contrato y datos de estado. Cada cuenta está compuesta por su código, datos y lógica de manejo de mensajes.

Estructura de la cuenta: Cada cuenta TON tiene una dirección única, que se genera a partir de una combinación del valor hash del código de la cuenta, los datos iniciales en el despliegue y otros parámetros. Esto significa que el mismo código y los datos iniciales desplegados en diferentes entornos (por ejemplo, diferentes blockchains o shards) pueden producir direcciones diferentes.

Flexibilidad: dado que cada cuenta puede ejecutar su propio código de contrato, las cuentas de TON pueden implementar lógica muy compleja. Las cuentas no son solo titulares de saldo simples, sino que pueden manejar transiciones de estado complejas, comunicación de mensajes entre cuentas e incluso automatización basada en condiciones específicas. Esto hace que el modelo de cuenta de TON sea más escalable y flexible en comparación con los modelos de cuenta de cadena de bloques tradicionales.

Estructura de libro mayor

La estructura del libro mayor de TON está diseñada para manejar de manera eficiente transacciones simultáneas a gran escala, lo que admite el paso de mensajes asíncronos y las operaciones de múltiples fragmentos. El estado de cada cuenta se almacena en una estructura de árbol de Merkle, lo que proporciona capacidades eficientes de validación de estado.

Almacenamiento de Estado

La información del estado de la cuenta se almacena en almacenamiento persistente y se organiza a través de un árbol de Merkle para garantizar la integridad y seguridad. Este diseño también admite consultas y verificaciones eficientes de los estados, especialmente en transacciones entre fragmentos.

Una cuenta o estado de contrato inteligente típicamente incluye lo siguiente:

1. Saldo de la moneda base 2. Saldo de otras monedas 3. Código de contrato inteligente (o su hash) 4. Datos persistentes del contrato inteligente (o su hash de Merkle) 5. Estadísticas sobre el número de unidades de almacenamiento persistente y el uso de bytes en bruto 6. Marca de tiempo reciente de los pagos al almacenamiento persistente del contrato inteligente (esencialmente, el número de bloque de la cadena principal) 7. Clave pública necesaria para transferir moneda y enviar mensajes desde esta cuenta (opcional; de forma predeterminada, esto es igual al propio account_id). En algunos casos, aquí se pueden encontrar códigos de verificación de firma más complejos, similares a las salidas de transacción de Bitcoin; en tales casos, account_id será el hash de este código.

No toda la información es necesaria para todas las cuentas. Por ejemplo, el código de contrato inteligente solo es relevante para los contratos inteligentes, no para las cuentas "simples". Además, si bien cada cuenta debe tener un saldo distinto de cero de la moneda base (por ejemplo, Gram para la cadena de trabajo base y las cadenas de fragmentos), los saldos de otras monedas pueden ser cero. Para evitar retener datos no utilizados, se define un tipo de suma-producto durante la creación de una cadena de trabajo, utilizando diferentes bytes de marcado para distinguir varias "funciones constructoras". En última instancia, el estado de la cuenta se guarda como una colección de unidades en el almacenamiento persistente de TVM.

Pasando y procesando mensajes

La estructura del libro mayor de TON incluye soporte incorporado para el paso de mensajes asíncronos. Cada cuenta puede procesar de forma independiente los mensajes recibidos y actualizar su estado. Este mecanismo de mensajería asíncrona permite interacciones complejas entre cuentas sin afectar el funcionamiento normal de otras cuentas debido a retrasos en cualquier operación individual.

modelo de gas

TON (The Open Network) optimiza significativamente la eficiencia de ejecución de los contratos inteligentes a través de su modelo único de tarifa de gas. Este modelo de tarifa de gas se utiliza para medir y limitar los recursos consumidos durante la ejecución de contratos inteligentes. En comparación con las blockchains tradicionales como Ethereum, el modelo de TON es más complejo y eficiente, lo que permite una gestión más precisa del consumo de recursos durante la ejecución del contrato.

El modelo de gas de TON puede medir con precisión los recursos computacionales, las operaciones de almacenamiento y los costos de paso de mensajes consumidos durante la ejecución de contratos inteligentes. Al proporcionar mediciones detalladas de recursos como la computación, el almacenamiento y el envío de mensajes, el modelo de gas de TON evita que las operaciones con una complejidad excesiva consuman demasiados recursos. Al limitar el consumo de gas, TON asegura que cada nodo de la red pueda asignar de manera justa los recursos computacionales, evitando el uso excesivo de los recursos de la red por un solo contrato u operación.

TON admite el procesamiento paralelo de contratos inteligentes, lo que permite que múltiples contratos se ejecuten simultáneamente en diferentes fragmentos sin bloquearse entre sí. En este diseño, el modelo de gas está estrechamente integrado con los mecanismos de ejecución paralela y fragmentación. Al procesar contratos en paralelo en múltiples fragmentos, TON puede distribuir el cálculo y el pago de gas entre diferentes nodos y cadenas, evitando la congestión de la red y maximizando la utilización de recursos.

El modelo de gas de TON incluye un mecanismo de ajuste dinámico que permite ajustar las tarifas de gas en función de la carga en tiempo real de la red. Esto significa que durante períodos de menor carga de la red, los usuarios pueden ejecutar contratos a tarifas de gas más bajas, fomentando las operaciones durante los horarios de menor actividad y equilibrando el uso de recursos de la red. Este mecanismo no solo mejora la experiencia del usuario, sino que también controla el uso máximo de recursos a través de un enfoque impulsado por el mercado.

Los contratos inteligentes de Ton son fáciles de ignorar los vacíos legales

En nuestro artículo de análisis de seguridad anterioren TON, hemos detallado las vulnerabilidades comunes de seguridad dentro del ecosistema de TON. Para más referencia, por favor vea la tabla a continuación:

Este artículo se centrará en las vulnerabilidades en los contratos TON que a menudo se pasan por alto, según lo resumido por nuestro equipo:

(1) Optimización de la legibilidad del código

En los contratos inteligentes TON, los números se utilizan a menudo para almacenar datos relacionados con el envío de mensajes. Por ejemplo, en el código siguiente, se utilizan varias instancias de números para representar los identificadores correspondientes y las longitudes de almacenamiento de datos, lo que reduce significativamente la legibilidad y el mantenimiento del código. A otros desarrolladores les puede resultar difícil comprender el significado y el propósito de estos números al leer el código. Para mejorar la legibilidad y la capacidad de mantenimiento, se recomienda definir los valores numéricos clave como constantes con nombre. Por ejemplo, defina 0x18comoNON_BOUNCEABLE.

1. check_std_addr(address);was 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);

Además, para el mensaje de error en las condiciones de juicio del contrato, también se recomienda definir variables correspondientes para reemplazar los códigos de error.

(2) Usando end_parse()Para garantizar la integridad de los datos

En los contratos TON, el análisis de datos sigue un orden fijo, cargando tipos específicos de datos paso a paso a partir de los datos sin procesar. Este método de análisis garantiza la coherencia y la precisión de los datos, como se ilustra a continuación:

Ten en cuenta queend_parse()se utiliza para comprobar si una porción de datos está vacía. Si la porción no está vacía, la función lanzará una excepción. Esto asegura que el formato y el contenido de los datos sean como se espera. Si la end_parse()La función detecta los datos restantes en la rebanada, puede indicar que el análisis de datos no se realizó como se pretendía o que hay un problema con el formato de los datos. Por lo tanto, al llamar end_parse(), puedes verificar si hay alguna omisión o anomalía durante el proceso de análisis.

(3) Excepciones causadas por almacenamiento de datos y tipos incompatibles

Esto se refiere principalmente a la correspondencia de intyuint Tipos de almacenamiento. Por ejemplo, en el código siguiente, el método store_int()La función se utiliza para almacenar un Intvalor de-42, pero load_uint()se utiliza para cargar este valor, lo que puede resultar en una excepción.

(4) Uso adecuado deinline_refyInlineModificadores

En primer lugar, es importante distinguir entre el en líneayinline_refmodificadores:

Inline: Funciones con el atributo en línea tienen su código insertado directamente en el sitio de la llamada cada vez que se les llama. Esto significa que el código real de la función se copia en la ubicación de la llamada en lugar de ejecutarse a través de un salto de función, lo que reduce la sobrecarga de las llamadas a la función, pero puede provocar la duplicación del código.

inline_ref: Funciones con el inline_ref almacenan su código en una celda separada. Cada vez que se llama a la función, TVM ejecuta el código almacenado en la celda a través de la función CALLREFcomando, evitando la duplicación de código y mejorando la eficiencia para funciones más complejas o aquellas llamadas varias veces.

En resumen, usa en líneapara funciones simples para reducir la sobrecarga de llamadas, pero tenga en cuenta la posible duplicación de código. Utilice inline_refpara funciones más grandes o llamadas frecuentes para mejorar la eficiencia y evitar la repetición de código.

(5) Determinación de la cadena de trabajo correcta

TON permite la creación de hasta 2^32 workchains, cada una de las cuales se puede subdividir aún más en hasta 2^60 shards. Inicialmente, hay dos workchains: el masterchain (-1) y el basechain (0). Al calcular las direcciones de destino en los contratos, es crucial especificar el ID de workchain correcto para asegurarse de que la dirección de billetera generada esté en el workchain correcto. Para evitar generar direcciones incorrectas, se recomienda utilizar force_chain()para especificar explícitamente el ID de la cadena.

(6) Evitar conflictos de códigos de error

La gestión efectiva de los códigos de error es crucial para el diseño de contratos para garantizar la coherencia y evitar confusiones. Para los contratos inteligentes de TON, asegúrese de que cada código de error sea único dentro del contrato para evitar conflictos y mensajes de error ambiguos. Además, evite conflictos con los códigos de error estándar definidos por la plataforma TON o el sistema subyacente. Por ejemplo, el código de error 333 indica una incompatibilidad de ID de cadena. Es recomendable utilizar códigos de error entre 400 y 1000 para evitar tales conflictos.

(7) Almacenamiento de datos y llamadasreturn()Después de completar la operación

En los contratos inteligentes de TON, el manejo de mensajes implica seleccionar diferentes lógicas basadas en el op-code. Después de completar la lógica correspondiente, son necesarios dos pasos adicionales: Primero, si los datos han sido modificados, llamar save_data()para asegurarse de que los cambios se guarden; de lo contrario, los cambios serán ineficaces. En segundo lugar, llamar return()para indicar que la operación está completa; de lo contrario, un throw(0xffff)se desencadenará una excepción.

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

int flags = cs~load_uint(4);

if (flags & 1) {

;; ignore all bounced messages

return ();

}

rebanada 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();

guardar_datos();

return ();

}

tirar(0xffff);

}

En resumen, la cadena de bloques TON, con su arquitectura innovadora y entorno de desarrollo flexible, se está convirtiendo en una plataforma ideal para los desarrolladores de aplicaciones descentralizadas. Sin embargo, a medida que los contratos inteligentes juegan un papel cada vez más crucial en el ecosistema TON, no se pueden pasar por alto los problemas de seguridad. Los desarrolladores deben comprender profundamente las características del ecosistema TON, adherirse estrictamente a las mejores prácticas y mejorar los procesos de auditoría de seguridad para garantizar la solidez y seguridad de los contratos. Solo así se pueden aprovechar plenamente las ventajas de la plataforma TON, construyendo aplicaciones descentralizadas más seguras y confiables y salvaguardando el desarrollo saludable de todo el ecosistema.

El ecosistema TON está experimentando un rápido crecimiento, atrayendo una financiación significativa y usuarios activos. Sin embargo, no se pueden ignorar los problemas de seguridad que lo acompañan. Para garantizar la seguridad y confiabilidad del ecosistema TON, Beosin proporciona auditorías de seguridad integrales y profesionales adaptadas a las características de las llamadas y operaciones de contratos inteligentes de TON, apoyando el desarrollo del ecosistema.

Beosin tiene numerosos casos exitosos dentro del ecosistema TON. Anteriormente, Beosin realizó auditorías de seguridad exhaustivas para el proyecto líder de stablecoin descentralizada Aqua Protocol y la infraestructura DeFi ONTON Finance. La auditoría abarcó múltiples aspectos, incluida la seguridad del código de contrato inteligente, la corrección de la implementación de la lógica empresarial, la optimización del gas del código del contrato y la detección y solución de posibles vulnerabilidades.

Declaración:

1. Este artículo es reproducido de [ Beosin], título original "Beosin Hard Core Research | Del riesgo a la protección: riesgos de seguridad y sugerencias de optimización de los contratos inteligentes de TON》, los derechos de autor pertenecen al autor original [Beosin], si tiene alguna objeción a la reimpresión, por favor contacteEquipo Gate Learn, el equipo lo manejará lo antes posible de acuerdo con los procedimientos relevantes.

2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo representan solo los puntos de vista personales del autor y no constituyen ningún consejo de inversión.

3. Otras versiones del artículo en otros idiomas son traducidas por el equipo de Gate Learn y no se mencionan en Gate.io, el artículo traducido no puede ser reproducido, distribuido o plagiado.