TON Blockchain Architecture
TON Blockchain Architecture es un sistema de almacenamiento y gestión de datos en la cadena de bloques TON. La arquitectura incluye organización de datos, mecanismo para dividir datos entre cuentas y bloques (sharding), reglas para verificar y proteger transacciones (condiciones de consenso), así como una masterchain, que gestiona los parámetros principales y coordina el trabajo de shardchains.
Todo es un paquete de celdas
En TON Blockchain todos los datos se representan como una colección (paquete) de celdas (bag of cells). Cada celda contiene hasta 1023 bits de datos y hasta 4 referencias a otras celdas. Estas celdas están organizadas en árboles o gráficos acíclicos orientados (DAGs), lo que permite almacenarlas y procesarlas estructuralmente. Todos los datos de bloques y estado de blockchain se serializan en celdas que representan valores de datos de acuerdo con los esquemas TL-B (Type Language - Binary).
La estructura de una celda incluye dos bites descriptores, datos y referencias a otras celdas representadas por hashes SHA256. Esta representación estándar de celdas se utiliza para serializarlas cuando se almacenan o transmiten los datos a través de la red.
Los componentes principales del bloque y del estado de la cadena de bloques
TON Blockchain utiliza he Infinite Sharding Paradigm (ISP), donde cada cuenta se trata como si estuviera en su propia cuenta (accountchain). Los bloques virtuales de estas accountchains se agrupan en bloques de shardchain para mayor eficiencia. El estado de shardchain incluye los estados de todas sus cuentas, y el bloque de shardchain consiste en una colección de bloques virtuales para algunas cuentas.
Un bloque de shardchain y su estado se dividen en dos partes: dividido (split) y no dividido (non-split). Las partes divididas están vinculadas a cuentas específicas, mientras que las que son no divididas incluyen datos como la descripción de los mensajes entrantes y salientes y el encabezado del bloque.
Componentes de la parte no dividida de la unidad de shardchain:
- InMsgDescr: es la descripción de todos los mensajes entrantes.
- OutMsgDescr: es la descripción de todos los mensajes salientes.
- Encabezado de bloque (block header): es la información general, incluidos los hashes y los parámetros del bloque.
- OutMsgQueue: es una cola de mensajes no entregados que se eliminan después de incluirlos en los shardchains vecinos.
La parte dividida del estado de shardchain consta de un HashMap (hashmap) que asigna cada id de cuenta "específico" al estado de la cuenta correspondiente. El estado de la cuenta incluye el saldo de Grams, el código de contrato inteligente, los datos persistentes del contrato inteligente, las estadísticas de uso de almacenamiento, la descripción formal opcional de la interfaz y la información pública del usuario.
Tenga en cuenta que en TON Blockchain no hay distinción entre "contrato inteligente" y "cuenta".
Bloques de masterchain
Los bloques y el estado de masterchain complementan los bloques de shardchain y sus estados. La masterchain no se divide ni se fusiona; normalmente tiene un predecesor, a excepción del bloque cero con la configuración inicial.
Condiciones de consenso
Un componente importante de la estructura de blockchain son las condiciones de consenso entre los datos almacenados en los bloques. Estas condiciones proporcionan la exactitud y seguridad de la cadena de bloques y garantizan que los datos se modifiquen sólo de manera válida, como resultado de transacciones dentro de los bloques.
Tipos de condiciones de consenso
- Las condiciones globales son invariantes que se aplican a toda la cadena de bloques, como las garantías de entrega de mensajes.
- Las condiciones internas (locales): son condiciones impuestas a los datos dentro de un bloque, como el procesamiento de mensajes entrantes en las transacciones.
- Las condiciones externas (locales): son condiciones relativas a los datos en diferentes bloques, generalmente pertenecientes a shardchains vecinos.
Condiciones de validez para un bloque
Todas las condiciones globales y locales relativas a un bloque constituyen condiciones de validez. Un bloque se considera válido si cumple con estas condiciones. La responsabilidad de generar y verificar la validez de los bloques recae en los validadores. Si un bloque no cumple con las condiciones de validez, no es válido.
Tiempo lógico
El tiempo lógico (LT) en TON Blockchain es un entero no negativo de 64 bits asignado a los eventos específicos. Si un evento depende de otros eventos, su tiempo lógico es mayor que el tiempo de todos los eventos dependientes de él. Por ejemplo, si un evento es independiente de los anteriores, su LT es 0.
TON Blockchain utiliza tiempo lógico e intervalos para diferentes componentes. Por ejemplo, los mensajes salientes creados en una transacción reciben un tiempo de creación lógico. Este tiempo depende de los mensajes anteriores y transacciones de la misma cuenta. A cada transacción se le asigna un intervalo de tiempo lógico, y los bloques que consisten en dichas transacciones y mensajes, también reciben sus intervalos, que se especifican en el encabezado del bloque.
Estado general de blockchain
Cada bloque de masterchain contiene una lista de todos los shards activos actuales y los últimos bloques para cada uno de ellos. En este sentido, cada bloque de masterchain define el estado general correspondiente de TON Blockchain, ya que registra el estado de cada shardchain y masterchain.
Cada bloque de shardchain contiene el hash del último bloque de masterchain en su encabezado. Esto significa que todos los bloques especificados en este bloque de masterchain y sus predecesores se consideran "visibles" para el bloque de shardchain. Un bloque de shardchain debe importar los mensajes de los estados OutMsgQueue de shardchain vecinos visibles y no puede contener mensajes de bloques "invisibles", incluso si son correctos.
Parámetros configurables y contratos inteligentes
En TON Blockchain, existen los llamados parámetros configurables, que pueden ser valores específicos o representar contratos inteligentes que se encuentran en la masterchain.
Los parámetros configurables incluyen:
- Aportación mínima para los validadores.
- Tamaño máximo del grupo de validadores.
- Número máximo de bloques de los que el grupo de validadores es responsable.
- Proceso de elección y castigo de los validadores.
- Conjunto de validadores actual y siguiente.
- Proceso de cambio de parámetros configurables.
Los parámetros configurables se almacenan en los datos persistentes de un contrato inteligente de configuración especial ubicado en la masterchein. Los valores iniciales de la mayoría de los parámetros y el código de los contratos inteligentes fundamentales están presentes en el bloque cero de la masterchain, que forma parte del estado inicial de la cadena de bloques.
Nuevos contratos inteligentes y sus direcciones
Los mecanismos de creación de nuevos contratos inteligentes y de asignación de las direcciones, que se describen a continuación, son válidos sólo para la workchain base y para la masterchain. Otras workchains pueden usar sus propios mecanismos para estos fines.
Los mensajes pueden ser enviados a cuentas no mencionadas anteriormente. Si dicho mensaje contiene un valor, crea una "cuenta no inicializada" con saldo, pero sin código ni datos. El contrato inteligente se crea enviando un mensaje de constructor especial a su dirección. Este mensaje contiene el código inicial y los datos del contrato inteligente. El mensaje constructor también generalmente debe llevar algún valor que se transferirá al saldo del nuevo contrato inteligente. El saldo mínimo depende de la cantidad de almacenamiento utilizado.
Los contratos inteligentes pueden crear automáticamente nuevos contratos inteligentes al procesar las transacciones. El usuario puede compilar el código para el contrato inteligente nuevo, generar el mensaje constructor y utilizar su contrato inteligente de la billetera para enviar ese mensaje y crear un nuevo contrato inteligente.
Modificación y eliminación de contratos inteligentes
Los datos persistentes de un contrato inteligente generalmente cambian como resultado de la ejecución del código de contrato inteligente en TVM cuando se procesa una transacción causada por un mensaje entrante. Si el código de contrato inteligente no requiere cambios en los datos, los datos permanecen sin cambios. El código del contrato inteligente solo se puede cambiar si el código actual permite tales cambios.
El contrato inteligente no puede ser destruido hasta que su saldo sea cero o negativo. Esto puede ocurrir debido a las tarifas de almacenamiento o después de enviar un mensaje saliente que transfiere casi todos los fondos. Por ejemplo, un usuario puede transferir todos los fondos a otra billetera o contrato inteligente para hacer la actualización.
Cuando el saldo de la cuenta se vuelve negativo o inferior a un cierto mínimo, la cuenta se congela, reemplazando su código y datos con un hash de 32 bytes. El hash se guarda por un tiempo para permitir que el propietario restaure la cuenta transfiriendo fondos y enviando un mensaje con el código y los datos.