Introducción: Después de que Binance lanzó Notcoin, el juego más grande en el ecosistema TON, y su economía de tokens en plena circulación creó un enorme efecto de riqueza, TON rápidamente ganó mucha atención. Hablando con amigos, descubrí que TON tiene una alta barrera técnica y su modelo de desarrollo DApp es muy diferente de los protocolos blockchain convencionales. Por lo tanto, pasé algún tiempo investigando este tema en profundidad y tengo algunas ideas para compartir con ustedes. En coro, la filosofía de diseño central de TON es reconstruir los protocolos tradicionales de blockchain desde cero, centrándose en lograr una alta concurrencia y escalabilidad, incluso si eso significa sacrificar la interoperabilidad.

TON principios básicos de diseño: alta simultaneidad y escalabilidad

Se puede decir que el propósito de todas las selecciones de tecnología compleja en TON proviene de la búsqueda de una alta concurrencia y una alta escalabilidad. Por supuesto, no es difícil para nosotros entender esto desde el trasfondo de su nacimiento. TON, o The Open Network, es una red informática descentralizada que incluye una cadena de bloques L1 y múltiples componentes. TON fue desarrollado originalmente por el fundador de Telegram, Nikolai Durov, y su equipo, y ahora es apoyado y mantenido por una comunidad global de colaboradores independientes. Su nacimiento se remonta a 2017, cuando el equipo de Telegram comenzó a explorar soluciones blockchain por sí mismos. Dado que ninguna cadena de bloques L1 existente en ese momento podía soporte la base de usuarios de nueve cifras de Telegram, decidieron diseñar su propia cadena de bloques, entonces llamada Telegram Open Network. El momento llegó en 2018. Con el orden de obtener los recursos necesarios para implementar TON, Telegram lanzó una venta de tokens Gram (más tarde rebautizados como Toncoin) en el primer trimestre de 2018. En 2020, el equipo de Telegram se retiró del proyecto TON debido a problemas regulatorios. Posteriormente, un pequeño grupo de desarrolladores de código abierto y ganadores de la competencia de Telegram se hicieron cargo del código base de TON, cambiaron el nombre del proyecto a The Open Network y continúan desarrollando activamente la cadena de bloques hasta el día de hoy, adhiriéndose a los principios descritos en el libro blanco original de TON.

Como TON fue diseñado para ser el entorno de ejecución descentralizado de Telegram, tuvo que abordar dos desafíos principales: altas solicitudes concurrentes y datos masivos. Incluso el TPS probado más alto (transacciones por segundo) de Solana, que afirma ser el más rápido, es de solo 65.000, mucho coro del nivel de millón de TPS necesarios para Telegram. Además, la enorme cantidad de datos generados por Telegram no puede ser gestionada por una cadena de bloques en la que cada nodo almacena una copia completa de los datos.

Para abordar estos desafíos, TON optimizó los principales protocolos de blockchain de dos maneras:

Utiliza un "paradigma de fragmentación infinita" para reducir la redundancia de datos, lo que le permite manejar grandes cantidades de datos y aliviar los cuellos de botella de rendimiento.

l Al introducir un entorno de ejecución totalmente paralelo basado en el modelo Actor, el TPS de red se mejora considerablemente;

Construyendo una Cadena de bloques de cadenas: proporcionando a cada cuenta su propia cadena dedicada a través de infinitas Fragmentación

Ahora sabemos que la fragmentación se ha convertido en la solución principal para la mayoría de los protocolos de blockchain para mejorar el rendimiento y reducir los costos, y TON ha llevado esto al extremo y ha propuesto el paradigma de fragmentación infinita, el llamado paradigma de fragmentación infinita. Se refiere a permitir que la cadena de bloques aumente o disminuya dinámicamente el número de fragmentos en función de la carga de la red. Este paradigma permite a TON manejar transacciones a gran escala y operaciones de contratos inteligentes mientras mantiene un alto rendimiento. En teoría, TON puede establecer una cadena de cuentas exclusiva para cada cuenta y garantizar la interoperabilidad entre estas cadenas a través de ciertas reglas. consistencia

En esencia, la estructura de la cadena de TON consta de cuatro capas

AccountChain: Esta capa representa una serie de transacciones vinculadas a una cuenta específica. Las transacciones forman una cadena porque, en una máquina de estados, las reglas de ejecución coherentes garantizan que la máquina de estados produzca los mismos resultados al procesar instrucciones en el mismo orden. Por lo tanto, todos los sistemas blockchain requieren que las transacciones estén vinculadas en una cadena, y TON no es diferente. AccountChain es la unidad más fundamental de la red TON. Normalmente, AccountChain es un concepto virtual y es poco probable que exista un AccountChain independiente.

ShardChain: En la mayoría de los contextos, ShardChain es la unidad real dentro de TON. Un ShardChain es esencialmente una colección de AccountChains.

WorkChain: También conocido como un conjunto de cadenas de fragmentos con reglas personalizadas, como la creación de una WorkChain basada en la EVM para ejecutar contratos inteligentes de Solidity. En teoría, cualquier miembro de la comunidad puede crear su propia cadena de trabajo. Sin embargo, construir uno es bastante complejo y requiere pagar la tarifa de creación (alta) y obtener la aprobación de 2/3 de los validadores.

MasterChain: En TON, hay una cadena única llamada MasterChain, que proporciona finalidad a todas las cadenas de fragmentos. Cuando el valor hash de un bloque shard chain se incluye en un bloque MasterChain, ese bloque shard chain y todos sus bloques principales se consideran finales, lo que significa que son fijos e inmutables, a los que hacen referencia todos los bloques shard chain posteriores.

Este paradigma le da a la red TON tres características clave:

Fragmentación dinámica: TON puede dividir y fusionar automáticamente cadenas de fragmentos para adaptarse a las cargas cambiantes, lo que garantiza que se generen rápidamente nuevos bloques y que las transacciones no experimenten largos retrasos.

Alta escalabilidad: Con su paradigma de fragmentación infinita, TON puede soportar casi un número ilimitado de soporte de fragmentos, teóricamente hasta 2 ^ 60 cadenas de trabajo.

Adaptabilidad: Cuando parte de la red experimenta una mayor carga, puede subdividirse en más fragmentos para manejar el mayor volumen de transacciones. Por el contrario, cuando la carga disminuye, las particiones pueden fusionarse para mejorar la eficiencia.

En un sistema multicadena como este, el principal desafío es la comunicación cross-chain. Con la capacidad de fragmentación infinita, cuando el número de fragmentos en la red crece significativamente, el enrutamiento de información entre cadenas se vuelve complejo. Por ejemplo, imagine una red con cuatro nodos, cada uno de los cuales mantiene una cadena de trabajo independiente. Cada nodo, además de administrar su propia clasificación de transacciones, también debe monitorear y procesar los cambios de estado en otras cadenas. En TON, esto se hace supervisando los mensajes en la cola de salida.

Supongamos que la cuenta A de WorkChain 1 quiere enviar un mensaje a la cuenta C de WorkChain 3. Esto requiere el diseño de una solución de enrutamiento de mensajes. En este ejemplo, hay dos rutas de enrutamiento: WorkChain 1 -> WorkChain 2 -> WorkChain 3 y WorkChain 1 -> WorkChain 4 -> WorkChain 3.

En escenarios más complejos, se necesita un algoritmo de enrutamiento eficiente y de bajo costo para una comunicación rápida de mensajes. TON utiliza el "algoritmo de enrutamiento de hipercubo" para el descubrimiento de enrutamiento de mensajes cross-chain. Una estructura de hipercubo es una topología de red especial en la que un hipercubo n-dimensional tiene 2^n vértices, cada uno identificado de forma única por un número binario de n bits. En esta estructura, dos vértices cualesquiera son adyacentes si sus representaciones binarias difieren solo en un bit. Por ejemplo, en un hipercubo tridimensional, el vértice 000 y el vértice 001 son adyacentes porque difieren solo en el último bit. El ejemplo anterior es un hipercubo bidimensional.

En el protocolo de enrutamiento de hipercubos, el enrutamiento de un mensaje desde la cadena de trabajo de origen a la cadena de trabajo de destino se realiza comparando sus direcciones binarias. El algoritmo encuentra la distancia mínima entre estas direcciones (es decir, el número de bits diferentes) y reenvía el mensaje a través de cadenas de trabajo adyacentes hasta que llega a su destino. Esto garantiza que el paquete de datos siga el camino más corto, lo que mejora la eficiencia de la comunicación de red. Para simplificar este proceso, TON también ofrece una solución optimista. Si un usuario puede proporcionar una prueba válida de una ruta de enrutamiento, normalmente una raíz trie de Merkle, el nodo puede verificar inmediatamente la autenticidad del mensaje. Esto se conoce como enrutamiento instantáneo de hipercubos. Como resultado, las direcciones TON difieren significativamente de las de otros protocolos blockchain. La mayoría de los protocolos de blockchain utilizan el hash de una clave pública generada por algoritmos de encriptación elíptica como una dirección, centrándose en la unicidad sin necesidad de funciones de enrutamiento. En TON, las direcciones constan de dos partes: (workchain_id, cuenta_id), con workchain_id codificadas de acuerdo con el algoritmo de enrutamiento de hipercubo. Uno podría preguntarse por qué no transmitir toda la información cross-chain a través de MasterChain, similar a Cosmos. En el diseño de TON, la MasterChain maneja solo la tarea más crítica de mantener la finalidad de las WorkChains. Si bien es posible enrutar mensajes a través de MasterChain, las tarifas asociadas serían prohibitivamente altas.

Por último, analicemos brevemente su algoritmo de consenso. TON emplea una combinación de BFT (tolerancia a la falla bizantina) y PoS (prueba de participación). Esto significa que cualquier staker puede participar en la creación de bloques. El contrato de gobernanza electoral de TON selecciona periódicamente un grupo de validadores al azar de todos los stakers. Estos validadores seleccionados utilizan el algoritmo BFT para crear bloques. Si un validador crea bloques no válidos o actúa de forma maliciosa, sus tokens apostados son confiscados. Por el contrario, reciben recompensas por crear con éxito bloques válidos. Este método es bastante común, por lo que no entraremos en más detalles aquí.

Contratos inteligentes que utilizan el modelo Actor dentro de un entorno de ejecución totalmente paralelo

Otra diferencia clave en TON en comparación con los principales protocolos de blockchain es su entorno de ejecución de contratos inteligentes. Para superar las limitaciones de TPS que enfrentan los principales protocolos de blockchain, TON utiliza un enfoque de diseño ascendente y emplea el modelo Actor para reconstruir contratos inteligentes y su ejecución, lo que permite capacidades de ejecución totalmente paralelas.

La mayoría de los principales protocolos de cadena de bloques utilizan un entorno de ejecución en serie de un solo hilo. Por ejemplo, el entorno de ejecución de Ethereum, el EVM, funciona como una máquina de estado que procesa las transacciones secuencialmente. Después de que se forma un bloque y se ordenan las transacciones, se ejecutan una por una a través de la EVM. Este proceso completamente en serie y de un solo subproceso significa que solo se procesa una transacción en un momento dado. La ventaja es que una vez que se establece el orden de la transacción, los resultados de la ejecución siguen siendo consistentes en una red distribuida. Además, dado que solo se ejecuta una transacción a la vez, ninguna otra transacción puede alterar los datos de estado a los que se accede, lo que garantiza la interoperabilidad entre contratos inteligentes. Por ejemplo, cuando se usa Uniswap para comprar ETH con USDT, la distribución del fondo de liquidez es un valor fijo durante la ejecución. Esto permite que los modelos matemáticos determinen el resultado exacto. Por el contrario, si otros proveedores de liquidez añadieran liquidez durante el cálculo de la curva de enlace, los resultados estarían desactualizados, lo que es claramente inaceptable.

Sin embargo, esta arquitectura también tiene claras limitaciones, particularmente el cuello de botella TPS, que se siente desactualizado con los procesadores multinúcleo modernos. Es similar a jugar viejos juegos de computadora como Red Alert en una PC nueva; Cuando el número de unidades de combate alcanza un cierto nivel, todavía te encuentras con un retraso significativo. Esto se debe a problemas de arquitectura de software.

Algunos protocolos están abordando este problema y han propuesto sus propias soluciones paralelas. Por ejemplo, Solana, que afirma tener el TPS más alto, también admite la ejecución paralela. Sin embargo, el diseño de Solana difiere del de TON. La idea central de Solana es agrupar todas las transacciones en función de sus dependencias de ejecución, asegurando que los diferentes grupos no compartan ningún dato de estado. Esto significa que no hay dependencias compartidas, lo que permite que las transacciones de diferentes grupos se ejecuten en paralelo sin conflictos. Las transacciones dentro del mismo grupo se siguen ejecutando en serie.

Por el contrario, TON abandona por completo la arquitectura de ejecución en serie y adopta un paradigma de desarrollo diseñado específicamente para el paralelismo, utilizando el modelo Actor para reconstruir su entorno de ejecución. El modelo del actor, propuesto por primera vez por Carl Hewitt en 1973, tiene como objetivo resolver la complejidad de los estados compartidos en los programas concurrentes tradicionales a través de la transmisión de mensajes. Cada actor tiene su propio estado y comportamiento privados y no comparte información de estado con otros actores. El modelo de actor es un modelo de cálculo de simultaneidad que logra el procesamiento paralelo a través del paso de mensajes. En este modelo, un "actor" es una unidad básica que puede manejar los mensajes recibidos, crear nuevos actores, enviar mensajes adicionales y decidir cómo responder a los mensajes posteriores. El modelo Actor debe tener las siguientes características:

Encapsulación e independencia: Cada actor funciona de forma completamente independiente al procesar mensajes, lo que permite el procesamiento paralelo de mensajes sin interferencias.

Paso de mensajes: los actores interactúan únicamente mediante el envío y la recepción de mensajes, siendo el paso de mensajes asincrónico.

Estructura dinámica: los actores pueden crear actores adicionales en tiempo de ejecución, lo que permite que el modelo de actor expanda dinámicamente el sistema según sea necesario.

TON adopta esta arquitectura para su modelo de contrato inteligente, lo que significa que cada contrato inteligente en TON se basa en el modelo Actor y tiene un almacenamiento completamente independiente porque no depende de ningún dato externo. Además, las llamadas al mismo contrato inteligente se ejecutan en el orden de mensajes en la cola de recepción. Esto permite que las transacciones en TON se ejecuten en paralelo de manera eficiente, sin preocupaciones sobre conflictos. Sin embargo, este diseño también presenta algunos desafíos nuevos. Para los desarrolladores de DApp, su paradigma de desarrollo familiar se verá interrumpido de las siguientes maneras:

1. Llamadas asíncronas de contratos inteligentes: En TON, es imposible llamar atómicamente a contratos externos o acceder a datos de contratos externos dentro de contratos inteligentes. En Solidity, por ejemplo, es sencillo para la función del Contrato A1 llamar a la función del Contrato B2 o acceder a ciertos datos de estado a través de la función de solo lectura del Contrato C3, todo en una sola transacción. Sin embargo, en TON, esto no se puede lograr. Cualquier interacción con contratos inteligentes externos se ejecutará de forma asíncrona mediante la creación de nuevas transacciones, denominadas mensajes internos iniciados por contratos inteligentes. El proceso de ejecución no se puede bloquear para esperar el resultado.

Por ejemplo, si estamos desarrollando un DEX y seguimos el paradigma común de EVM, normalmente tenemos un contrato de enrutador unificado para administrar el enrutamiento de transacciones, mientras que cada grupo administra de forma independiente los datos de LP para pares comerciales específicos. Digamos que tenemos dos grupos: USDT-DAI y DAI-ETH. Cuando un usuario desea comprar ETH directamente con USDT, puede usar el contrato del enrutador para interactuar secuencialmente con estos dos grupos en una sola transacción atómica. Sin embargo, en TON, este proceso no es tan sencillo y requiere un enfoque de desarrollo diferente. Si intentamos reutilizar este paradigma EVM, el flujo de información implicaría un mensaje externo iniciado por el usuario y tres mensajes internos para completar la transacción (tenga en cuenta que este ejemplo es para resaltar las diferencias; en el desarrollo real, incluso el paradigma ERC20 necesitaría ser rediseñado).

1. Se requiere una cuidadosa consideración para el manejo de errores en las llamadas entre contratos, diseñando funciones de rebote apropiadas para cada interacción entre contratos. En los sistemas EVM convencionales, si se produce un error durante la ejecución de la transacción, toda la transacción se revierte a su estado inicial. Esto es sencillo en un modelo de serie de un solo hilo. Sin embargo, en TON, dado que las llamadas entre contratos se ejecutan de forma asíncrona, si se produce un error en una etapa posterior, las transacciones anteriores ejecutadas correctamente ya se han confirmado, lo que puede causar problemas. Por lo tanto, TON ha introducido un tipo de mensaje especial llamado mensaje de rebote. Si se produce un error en la ejecución posterior de un mensaje interno, el contrato activado puede utilizar la función de rebote reservada en el contrato desencadenante para restablecer ciertos estados en el contrato desencadenante.

2. En escenarios complejos, es posible que las transacciones que se reciben primero no se completen primero, por lo que no puede suponer un orden de ejecución específico. En un sistema de contrato inteligente asíncrono y paralelo, definir el orden de procesamiento puede ser un desafío. Es por eso que cada mensaje en TON tiene su hora lógica, conocida como hora de Lamport (lt). Ayuda a determinar qué evento desencadenó otro y qué validadores deben procesar primero. En un modelo simple, las transacciones recibidas primero se ejecutan primero.

En este modelo, A y B representan dos contratos inteligentes. Si msg1_lt < msg2_lt, entonces tx1_lt < tx2_lt en términos de secuencia.

Sin embargo, en situaciones más complejas, esta regla puede romperse. La documentación oficial proporciona un ejemplo: supongamos que tenemos tres contratos, A, B y C. En una transacción, A envía dos mensajes internos, msg1 y msg2, uno a B y el otro a C. Aunque se crean en un orden específico (msg1 primero, luego msg2), no podemos estar seguros de que msg1 se procesará antes que msg2. Esta incertidumbre surge porque las rutas de A a B y de A a C pueden diferir en longitud y conjuntos de validadores. Si estos contratos están en diferentes cadenas de particiones, un mensaje puede tardar varios bloques en llegar al contrato de destino. Por lo tanto, hay dos posibles rutas de transacción, como se ilustra.

1. En TON, el almacenamiento persistente para contratos inteligentes utiliza una estructura de grafo acíclico dirigido (DAG) con celdas como unidades. Los datos se comprimen de forma compacta en una celda de acuerdo con reglas de codificación específicas y se extienden hacia abajo de manera DAG. Esto contrasta con la estructura basada en mapas hash utilizada en EVM para datos de estado. Debido a los diferentes algoritmos de acceso a datos, TON asigna diferentes precios de gas para procesar datos a diferentes profundidades; El procesamiento de datos celulares más profundo requiere más gases. En consecuencia, TON se enfrenta a un tipo de ataque DOS, donde los usuarios malintencionados inundan un contrato inteligente con una gran cantidad de mensajes basura, llenando todas las celdas poco profundas. Esto aumenta los costos de almacenamiento para los usuarios honestos. Por el contrario, el hashmap de EVM tiene una complejidad de consulta de O(1), lo que garantiza costos de gas consistentes y evita problemas similares. Por lo tanto, los desarrolladores de TON Dapp deben evitar el uso de tipos de datos ilimitados en contratos inteligentes. Cuando se necesitan tipos de datos no enlazados, se deben particionar mediante particionamiento.

1. Algunas características son menos únicas, como el requisito de que los contratos inteligentes paguen el alquiler por el almacenamiento. En TON, los contratos inteligentes son inherentemente actualizables y vienen con funciones de cuentas abstractas nativas, lo que significa que todas las direcciones de billetera en TON son contratos inteligentes, solo que sin inicializar. Los desarrolladores deben prestar mucha atención a estos aspectos.

Disclaimer:

1. Este artículo es una reimpresión de [Theblockbeats]. Todos los derechos de autor pertenecen al autor original [Web3Mario]. Si hay objeciones a esta reimpresión, póngase en contacto con el equipo de Gate Learn, y ellos se encargarán de ello con prontitud.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.