La arquitectura de TON define cómo se almacenan y gestionan los datos en la red mediante una estructura de celdas, sharding a nivel de cuenta y una cadena maestra que coordina los shardchains y los parámetros de la red.
Representación de datos: bag of cells#
En TON, toda la información se codifica como una colección de celdas (bag of cells). Cada celda puede contener hasta 1023 bits de datos y hasta 4 referencias a otras celdas, organizadas en árboles o grafos acíclicos dirigidos (DAG). La serialización sigue los esquemas TL‑B y utiliza hashes SHA‑256 para referenciar celdas.
Paradigma de sharding infinito (ISP)#
Cada cuenta funciona como una accountchain independiente. Los bloques virtuales de estas accountchains se agrupan en bloques de shardchain para mejorar la eficiencia. El estado de un shardchain es la suma de los estados de todas sus cuentas, y el bloque de shardchain contiene una colección de bloques virtuales de cuentas seleccionadas. No existe distinción entre “smart contract” y “cuenta”; ambos son la misma entidad.
Estructura de los bloques de shardchain#
Los bloques de shardchain se dividen en dos partes:
Parte no dividida (non‑split)
- InMsgDescr: descripción de todos los mensajes entrantes.
- OutMsgDescr: descripción de todos los mensajes salientes.
- Encabezado de bloque: incluye hashes y parámetros del bloque.
- OutMsgQueue: cola de mensajes no entregados que se eliminan tras su inclusión en shardchains vecinos.
Parte dividida (split)
Un HashMap asigna cada account_id al estado de la cuenta, que incluye saldo en Grams, código del contrato, datos persistentes, estadísticas de uso de almacenamiento, descripción formal opcional de la interfaz e información pública del usuario.
Bloques de la masterchain#
La masterchain no se divide ni se fusiona; cada bloque (excepto el bloque cero) tiene un predecesor único. Contiene la lista de todos los shards activos y los últimos bloques de cada uno, además de los parámetros configurables almacenados en un contrato inteligente especial.
Parámetros configurables
- Aportación mínima para los validadores.
- Tamaño máximo del grupo de validadores.
- Número máximo de bloques que el grupo gestiona.
- Procesos de elección y penalización de validadores.
- Conjuntos actual y próximo de validadores.
- Procedimientos para cambiar los parámetros.
Condiciones de consenso#
Un bloque es válido si cumple todas las condiciones de consenso aplicables:
- Globales: invariantes para toda la red (p. ej., garantías de entrega de mensajes).
- Internas (locales): restricciones dentro de un bloque (p. ej., procesamiento de mensajes entrantes).
- Externas (locales): relaciones entre bloques de shardchains vecinos.
Los validadores son responsables de generar y verificar que estas condiciones se cumplan.
Tiempo lógico (LT)#
El tiempo lógico es un entero de 64 bits asignado a cada evento. Un evento dependiente tiene un LT mayor que todos sus predecesores; los eventos independientes tienen LT = 0. Mensajes salientes heredan el LT de la transacción que los genera, y tanto transacciones como bloques poseen intervalos de tiempo lógico registrados en el encabezado del bloque.
Creación y gestión de contratos inteligentes#
- Un mensaje a una dirección no inicializada crea una cuenta no inicializada con saldo pero sin código ni datos.
- Un mensaje constructor incluye el código y los datos iniciales, creando el contrato inteligente.
- Los contratos pueden crear nuevos contratos enviando mensajes constructor.
- Los datos persistentes cambian al ejecutar código en el TVM; el código solo puede modificarse si lo permite el contrato actual.
- Un contrato no puede destruirse mientras su saldo sea positivo; si el saldo cae por debajo del mínimo, la cuenta se congela y su código y datos se reemplazan por un hash de 32 bytes, que puede restaurarse transfiriendo fondos y enviando un mensaje con el código y los datos originales.
Ver tambiénVer también#
- Proof‑of‑Stake
- Nodo
- Validador
- The Open Network