Autor: @Web3Mario

Introducción: Con el lanzamiento de Notcoin, el juego más grande del ecosistema TON, en Binance y el enorme efecto riqueza causado por el modelo económico de tokens de circulación total, TON ha ganado gran atención en un corto período de tiempo. Después de conversar con un amigo, descubrí que el umbral técnico de TON es relativamente alto y que el paradigma de desarrollo de DApp es muy diferente de los protocolos de cadena pública convencionales, por lo que dediqué algún tiempo a investigar en profundidad sobre temas relacionados y compartí algunas ideas con ustedes. En resumen, el concepto de diseño central de TON es reconstruir el protocolo blockchain tradicional de manera "ascendente" y lograr una alta concurrencia y una alta escalabilidad a expensas de la interoperabilidad.

La idea central de diseño de TON: alta concurrencia y alta escalabilidad

Se puede decir que el propósito de todas las selecciones de tecnología compleja en TON proviene de la búsqueda de alta concurrencia y alta escalabilidad. Por supuesto, no es difícil para nosotros entender esto desde el contexto de su nacimiento. TON, o The Open Network, es una red informática descentralizada que contiene 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 cuenta con el respaldo y el mantenimiento de 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 soportar la base de usuarios de nueve cifras de Telegram, decidieron diseñar su propia cadena de bloques, entonces llamada Telegram Open Network. Llegó el año 2018. Para obtener los recursos necesarios para implementar TON, Telegram lanzó la 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 del concurso 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 documento técnico original de TON.

Entonces, dado que el objetivo del diseño es el entorno de ejecución descentralizada de Telegram, naturalmente tiene que enfrentar dos problemas: altas solicitudes concurrentes y datos masivos. Sabemos que con el desarrollo de la tecnología hasta el momento, Solana, que se conoce como el TPS más alto, tiene la ventaja. El TPS medido más alto es de solo 65,000, lo que obviamente no es suficiente para respaldar el ecosistema de Telegram que requiere millones de TPS. Al mismo tiempo, con la aplicación a gran escala de Telegram, la cantidad de datos que genera ya ha excedido el cielo. Como sistema distribuido extremadamente redundante, blockchain requiere que cada nodo de la red guarde una copia completa de los datos. también poco realista.

Por lo tanto, para resolver los dos problemas anteriores, TON ha realizado dos optimizaciones en los protocolos blockchain principales:

• Al utilizar el "paradigma de fragmentación infinita" para diseñar el sistema, solucionamos el problema de la redundancia de datos para que pueda transportar grandes datos y aliviar el problema del cuello de botella en el rendimiento;

• Al introducir un entorno de ejecución totalmente paralelo basado en el modelo Actor, el TPS de la red mejora enormemente;

Cree una cadena blockchain: a través de capacidades de fragmentación ilimitadas, cada cuenta tiene una cadena de cuentas exclusiva

Ahora sabemos que la fragmentación se ha convertido en la solución principal para que la mayoría de los protocolos blockchain mejoren el rendimiento y reduzcan los costos, y TON llevó esto al extremo y propuso el paradigma de fragmentación infinita, el llamado paradigma de fragmentación infinita. aumentar o disminuir dinámicamente la cantidad de fragmentos según 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.

Para entenderlo de manera abstracta, hay cuatro niveles de estructura de cadena en TON:

• Cadena de cuentas: esta capa de cadena representa una cadena compuesta por una serie de transacciones relacionadas con una cuenta. La razón por la cual las transacciones pueden formar una estructura de cadena es porque para una máquina de estado, siempre que las reglas de ejecución sean consistentes, la máquina de estado lo hará. Los resultados obtenidos después de recibir instrucciones en la misma secuencia son consistentes. Por lo tanto, el ordenamiento en cadena de las transacciones es necesario en todos los sistemas distribuidos de blockchain, y TON no es una excepción. La cadena de cuentas es la unidad más básica de la red TON. Por lo general, la cadena de cuentas es un concepto virtual y es poco probable que realmente exista una cadena de cuentas independiente.

• Cadena de fragmentos: en la mayoría de los contextos, la cadena de fragmentos es la unidad componente real en TON. La llamada cadena de fragmentos es una colección de cadenas de cuentas.

• WorkChain: también se le puede llamar un conjunto de cadenas de fragmentación con reglas personalizadas, como crear una cadena de trabajo basada en EVM y ejecutar contratos inteligentes de Solidity en ella. En teoría, todos los miembros de la comunidad pueden crear su propia cadena de trabajo. De hecho, construirlo es una tarea bastante compleja, precedida por pagar la (cara) tarifa para crearlo y obtener 2/3 de los votos de los validadores para aprobar la creación de su cadena de trabajo.

• Cadena principal (MasterChain): Finalmente, hay una cadena especial en TON llamada cadena principal, que es responsable de darle finalidad a todas las cadenas de fragmentos. Una vez que el hash del bloque de una cadena de fragmentos se fusiona con el bloque de la cadena principal, ese bloque de la cadena de fragmentos y todos sus bloques principales se consideran finales, lo que significa que pueden considerarse fijos e irrompibles. Los bloques posteriores de todos los fragmentos hacen referencia al contenido modificado. cadenas.

Al adoptar dicho paradigma, la red TON tiene las siguientes tres características:

• Fragmentación dinámica: TON puede dividir y fusionar automáticamente cadenas de fragmentos para adaptarse a los cambios de carga. Esto significa que siempre se generan nuevos bloques rápidamente y las transacciones no incurren en largos tiempos de espera.

• Altamente escalable: a través del paradigma de fragmentación infinita, TON puede admitir una cantidad casi ilimitada de fragmentos y, en teoría, puede alcanzar 2 elevado a 60 potencias de cadenas de trabajo.

• Adaptabilidad: cuando aumenta la carga en una parte de la red, esa parte se puede subdividir en más fragmentos para manejar el mayor volumen de transacciones. Por el contrario, cuando la carga disminuye, los fragmentos se pueden fusionar para aumentar la eficiencia.

Entonces, lo primero que debe enfrentar un sistema de múltiples cadenas es el problema de la comunicación entre cadenas, especialmente debido a la capacidad de fragmentación ilimitada. Cuando la cantidad de fragmentos en la red alcanza un cierto nivel, la información se enruta entre cadenas. se convertirá en algo difícil de hacer. Imagine que hay 4 nodos en la red. Cada nodo es responsable de mantener una cadena de trabajo independiente. La relación de enlace indica que, además de ser responsable de la clasificación de transacciones en su propia cadena de trabajo, el nodo también necesita monitorear y procesar el estado. cambios en la cadena de destino, implementados en TON específicamente monitoreando los mensajes en la cola de salida.

Supongamos que la cuenta A en la cadena de trabajo 1 quiere enviar un mensaje a la cuenta C en la cadena de trabajo 3. Debe diseñar el problema de enrutamiento de mensajes. En este ejemplo, hay dos rutas de enrutamiento, cadena de trabajo 1 -> cadena de trabajo 2 -> cadena de trabajo 3 y cadena de trabajo 1 -> cadena de trabajo 4 -> cadena de trabajo 3.

Cuando se enfrenta a situaciones más complejas, se necesita un algoritmo de enrutamiento eficiente y de bajo costo para completar rápidamente la comunicación de mensajes. TON eligió el llamado "algoritmo de enrutamiento de hipercubo" para realizar el descubrimiento de rutas de comunicación de mensajes entre cadenas. La llamada estructura de hipercubo se refiere a una topología de red especial. Un hipercubo de n dimensiones se compone de 2 ^ n vértices, y cada vértice se puede identificar de forma única mediante un número binario de n bits. En esta estructura, dos vértices cualesquiera son adyacentes si difieren solo en un bit en la representación binaria. Por ejemplo, en un hipercubo 3D, el vértice 000 y el vértice 001 son adyacentes porque solo difieren en el último bit. El ejemplo anterior es un hipercubo bidimensional.

En el protocolo de enrutamiento de hipercubo, el proceso de enrutamiento de un mensaje desde una cadena de trabajo de origen a una cadena de trabajo de destino se realiza comparando las representaciones binarias de las direcciones de la cadena de trabajo de origen y de destino. El algoritmo de enrutamiento encuentra la distancia mínima (es decir, el número de bits diferentes en la representación binaria) entre estas dos direcciones y reenvía progresivamente la información a través de cadenas de trabajo adyacentes hasta alcanzar la cadena de trabajo objetivo. Este método garantiza que los paquetes de datos se transmitan por la ruta más corta, mejorando así la eficiencia de la comunicación de la red.

Por supuesto, para simplificar este proceso, TON también ha propuesto una solución técnica optimista: cuando un usuario puede proporcionar una prueba válida de una determinada ruta de enrutamiento, que suele ser una raíz merkle trie, el nodo puede reconocer directamente la credibilidad del mensaje. enviado por las propiedades del usuario, esto también se conoce como enrutamiento de hipercubo instantáneo.

Por lo tanto, podemos ver que las direcciones en TON son significativamente diferentes de otros protocolos de blockchain. La mayoría de los demás protocolos de blockchain convencionales utilizan el hash correspondiente a la clave pública en las claves públicas y privadas generadas por el algoritmo de cifrado elíptico como dirección. solo se usa para ser único. No necesita llevar la función de direccionamiento de enrutamiento. La dirección en TON consta de dos partes (workchain_id, account_id). Workchain_id está codificado de acuerdo con la dirección del algoritmo de enrutamiento del hipercubo, que no se explicará en detalle. aquí.

Hay otro punto que es fácil de generar dudas. Es posible que haya notado que la cadena principal tiene una relación de eslabón con cada cadena de trabajo, por lo que ¿no sería suficiente que toda la información entre cadenas se transmitiera a través de la cadena principal, simplemente? como Cosmos. En el concepto de diseño de TON, la cadena principal solo se usa para manejar las tareas más críticas, es decir, mantener la finalidad de muchas cadenas de trabajo. No es imposible enrutar mensajes a través de la cadena principal, pero las tarifas de manejo resultantes serán muy costosas. .

Finalmente, una breve mención de su algoritmo de consenso. TON adopta el método BFT + PoS, es decir, cualquier participante que tenga la oportunidad de participar en el contrato de gobernanza electoral de TON seleccionará aleatoriamente un verificador de paquete entre todos los participantes en intervalos regulares. En el clúster, los nodos seleccionados como validadores empaquetarán y producirán bloques a través del algoritmo BFT. Si empaquetan información incorrecta o hacen algo malo, perderán sus tokens apostados y, de lo contrario, recibirán recompensas en bloque. Esta es básicamente una opción común, por lo que no la presentaré aquí.

Contratos inteligentes y entorno de ejecución totalmente paralelo basado en el modelo Actor

Otro punto de TON que se diferencia de los protocolos blockchain convencionales es su entorno de ejecución de contratos inteligentes. Para superar las limitaciones del protocolo blockchain TPS, TON adoptó una idea de diseño ascendente y utilizó el modelo Actor para reconstruir contratos inteligentes y sus métodos de ejecución, dándoles la capacidad de estar completamente paralelizados.

Sabemos que la mayoría de los protocolos blockchain convencionales utilizan un entorno de ejecución en serie de un solo subproceso, tomando Ethereum como ejemplo, su entorno de ejecución EVM es una máquina de estado con transacciones como entrada cuando el nodo productor de bloques completa la transacción empaquetando el bloque después de ordenar. , las transacciones se ejecutarán a través de EVM en este orden. Todo el proceso es completamente en serie y de un solo subproceso, es decir, solo se puede ejecutar una transacción en un momento determinado. La ventaja de esto es que siempre que la secuencia de la transacción sea. confirmado, el resultado de la ejecución será consistente en una amplia gama de clústeres distribuidos. Al mismo tiempo, dado que solo se ejecuta una transacción en serie al mismo tiempo, esto significa que durante el proceso de ejecución, es imposible que otras transacciones se realicen. modificar un determinado estado de los datos a los que se accederá, de modo que se logre la interoperabilidad entre contratos inteligentes. Por ejemplo, usamos USDT para comprar ETH a través de Uniswap. Cuando se ejecuta la transacción, la distribución de LP en el par comercial es un valor determinado, de esta manera, el resultado correspondiente se puede obtener a través de algunos modelos matemáticos, pero suponiendo que así sea. No es el caso. Al realizar el cálculo de una determinada curva de bonos, si otros LP agregan nueva liquidez, el resultado del cálculo será un resultado desactualizado, lo que obviamente es inaceptable.

Pero esta arquitectura también tiene limitaciones obvias, que es el cuello de botella del TPS, y este cuello de botella parece muy antiguo con los procesadores multinúcleo actuales, como si usaras la última PC para jugar algunos juegos de computadora antiguos, como Red Alert, cuando el. Si el número de unidades de combate alcanza un cierto nivel, aún encontrará que está atascado. Este es un problema con la arquitectura del software.

Es posible que escuche que algunos protocolos ya están prestando atención a este problema y han propuesto sus propias soluciones paralelas. Tomando como ejemplo a Solana, que actualmente afirma tener el TPS más alto, también tiene la capacidad de ejecutarse en paralelo. Sin embargo, su idea de diseño es diferente de TON. En Solana, su idea central es dividir todas las transacciones en varios grupos según las dependencias de ejecución, y no se comparten datos de estado entre diferentes grupos. Es decir, no existen dependencias idénticas, por lo que las transacciones en diferentes grupos se pueden ejecutar en paralelo sin preocuparse por conflictos, mientras que las transacciones dentro del mismo grupo aún se ejecutan de la manera tradicional en serie.

En TON, abandona por completo la arquitectura de ejecución en serie y, en su lugar, adopta un paradigma de desarrollo diseñado específicamente para el paralelismo, el modelo Actor, para reconstruir el entorno de ejecución. El llamado modelo Actor fue propuesto por primera vez por Carl Hewitt en 1973 para resolver la complejidad del estado compartido en programas concurrentes tradicionales mediante el paso de mensajes. Cada Actor tiene su propio estado y comportamiento privados y no comparte ninguna información de estado con otros Actores. El modelo Actor es un modelo de computación concurrente que implementa la computación paralela mediante el paso de mensajes. En este modelo, un "Actor" es la unidad básica de trabajo, capaz de procesar mensajes recibidos, crear nuevos Actores, enviar más mensajes y decidir cómo responder a mensajes posteriores. El modelo Actor debe tener las siguientes características:

• Encapsulación e independencia: cada actor es completamente independiente al procesar mensajes y puede procesar mensajes en paralelo sin interferir entre sí.

• Transmisión de mensajes: los actores solo interactúan entre sí enviando y recibiendo mensajes, y la transmisión de mensajes es asincrónica.

• Estructura dinámica: los actores pueden crear más actores en tiempo de ejecución. Esta naturaleza dinámica permite que el modelo de actor expanda el sistema según sea necesario.

TON adopta esta arquitectura para diseñar modelos de contratos inteligentes, lo que significa que en TON, cada contrato inteligente es un modelo de Actor con espacio de almacenamiento completamente independiente. Porque no depende de ningún dato externo. Además, las llamadas al mismo contrato inteligente aún se ejecutan según el orden de los mensajes en la cola de recepción, por lo que las transacciones en TON se pueden ejecutar de manera eficiente en paralelo sin preocuparse por conflictos.

Sin embargo, este esquema de diseño también traerá algunos impactos nuevos para los desarrolladores de DApp, su paradigma de desarrollo habitual se romperá, de la siguiente manera:

1. Llamadas asincrónicas entre contratos inteligentes: no es posible llamar atómicamente a contratos externos o acceder a datos de contratos externos dentro de los contratos inteligentes de TON. Sabemos que en Solidity, la función 1 del contrato A llama a la función 2 del contrato B, o mediante la función de solo lectura. 3 del contrato C accede a ciertos datos de estado. Todo el proceso es atómico y se ejecuta en una transacción. Esto es algo muy fácil. Sin embargo, en TON, esto no será posible y cualquier interacción con el contrato de inteligencia externa se ejecutará de forma asincrónica. empaquetando nuevas transacciones. Estas transacciones iniciadas por contratos inteligentes también se denominan mensajes internos. Y no se puede bloquear durante la ejecución para obtener los resultados de la ejecución.

Por ejemplo, si desarrollamos un DEX, si adoptamos el paradigma común en EVM, generalmente se utilizará un contrato de enrutador unificado para administrar el enrutamiento de transacciones, y cada grupo administra de forma independiente los datos LP relacionados con un determinado par comercial. Actualmente hay dos grupos: USDT-DAI y DAI-ETH. Cuando un usuario desea comprar ETH directamente a través de USDT, puede solicitar secuencialmente estos dos grupos en una transacción a través del contrato del enrutador para completar una transacción atómica. Sin embargo, no es tan fácil de implementar en TON. Necesitamos pensar en un nuevo paradigma de desarrollo. Si aún reutilizamos este paradigma, el flujo de información puede ser así. Esta solicitud irá acompañada de un mensaje externo iniciado por el usuario. y se completan tres mensajes internos (tenga en cuenta que esto se utiliza para ilustrar la diferencia. En el desarrollo real, incluso el paradigma ERC20 debe rediseñarse).

2. Es necesario considerar cuidadosamente el proceso de procesamiento de errores de ejecución al realizar llamadas entre contratos y diseñar las funciones de rebote correspondientes para cada llamada entre contratos. Sabemos que en el EVM convencional, cuando se encuentra un problema durante la ejecución de la transacción, toda la transacción se revertirá, es decir, se restablecerá al estado de ejecución inicial. Esto es fácil de entender en el modelo serial de un solo subproceso. Sin embargo, en TON, dado que las llamadas entre contratos se ejecutan de forma asincrónica, incluso si ocurre un error en algún enlace posterior, dado que la transacción ejecutada anteriormente con éxito ya se ejecutó y confirmó, esto puede causar problemas. Por lo tanto, se configura un tipo de mensaje especial en TON, llamado mensaje de rebote. Es decir, cuando ocurre un error en el proceso de ejecución posterior desencadenado por un mensaje interno, el contrato desencadenado puede activar un determinado mensaje en el contrato a través de la función de rebote. reservado por el contrato de activación. Algunos restablecimientos de estado.

3. En algunas situaciones complejas, es posible que la transacción recibida primero no se ejecute primero, por lo que esta relación de tiempo no se puede preestablecer. En un sistema de este tipo de llamadas de contratos inteligentes asíncronas y paralelas, definir el orden en el que se procesan las operaciones puede resultar difícil. Es por eso que cada mensaje en TON tiene su tiempo lógico Lamport (en adelante, lt). Se utiliza para comprender qué evento desencadenó otro y qué debe manejar primero el validador. Para un modelo simple, la transacción recibida primero debe ejecutarse primero.

En este modelo, A y B representan dos contratos inteligentes respectivamente, y existe una relación de tiempo de si msg1_lt < msg2_lt, entonces tx1_lt < tx2_lt.

Sin embargo, en situaciones más complejas, esta regla se infringe. Hay un ejemplo de esto en la documentación oficial. 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 el orden exacto (msg1 primero, luego msg2), no podemos estar seguros de que msg1 se procese antes que msg2. Esto se debe a que las rutas de A a B y de A a C pueden diferir en longitud y conjunto de validadores. Si estos contratos están en diferentes cadenas de fragmentos, uno de los mensajes puede tardar varios bloques en llegar al contrato de destino. Es decir, tenemos dos posibles rutas comerciales, como se muestra en la figura.

4. En TON, el almacenamiento persistente de sus contratos inteligentes utiliza un gráfico acíclico dirigido con Cell como unidad como estructura de datos. Los datos se comprimirán de forma compacta en una Cell de acuerdo con las reglas de codificación y, al mismo tiempo, de acuerdo con el. El gráfico acíclico dirigido se extiende hacia abajo, lo que es diferente de la organización estructural de datos de estado basada en hashmap en EVM. Debido a diferentes algoritmos de solicitud de datos, TON establece diferentes precios de gas para diferentes profundidades de procesamiento de datos. , cuanto más gas requiere, mayor es, por lo que existe un paradigma de ataque DOS en TON, es decir, algunos usuarios malintencionados ocupan todas las celdas poco profundas en un determinado contrato inteligente al enviar una gran cantidad de mensajes de spam, lo que significa que el. El costo de almacenamiento de los usuarios honestos será cada vez más caro. En EVM, dado que la complejidad de la consulta de hashmap es o (1), tiene el mismo Gas y no habrá problemas similares. Por lo tanto, los desarrolladores de TON Dapp deberían intentar evitar tipos de datos ilimitados en los contratos inteligentes. Cuando aparecen tipos de datos ilimitados, se deben dividir mediante fragmentación.

5. También hay algunas características que son menos especiales, como contratos inteligentes que deben pagar el alquiler por el almacenamiento, los contratos inteligentes en TON se pueden actualizar de forma natural y funciones de cuenta abstractas nativas, es decir, todas las direcciones de billetera en TON son contratos inteligentes. simplemente no inicializado, etc. Esto requiere que los desarrolladores presten mucha atención.

Las anteriores son algunas de mis experiencias en el aprendizaje de tecnologías relacionadas con TON durante este período. Me gustaría compartirlas con ustedes. Espero que puedan corregirme si cometo algún error. Al mismo tiempo, creo que con el enorme tráfico de Telegram. Recursos, el ecosistema TON definitivamente proporcionará la base para Web3. Al traer algunas aplicaciones nuevas, los amigos que estén interesados ​​en el desarrollo de TON DApp también pueden contactarme y discutir con nosotros.

Enlaces X: https://x.com/web3_mario