<\/a><\/noindex><\/p>\nConceptos b\u00e1sicos<\/h3>\n <\/p>\n
Cuenta<\/strong> (account<\/em>). Un conjunto de datos identificado por un n\u00famero de 256 bits account_id<\/em> (m\u00e1s com\u00fanmente, es la clave p\u00fablica del propietario de la cuenta). En el caso b\u00e1sico (ver m\u00e1s abajo cero blockchain<\/em>), estos datos representan el balance del usuario. Cualquiera puede \"tomar\" un determinado account_id<\/em> pero su valor solo puede ser modificado de acuerdo con ciertas reglas.<\/p>\n<\/p>\n
Contrato inteligente<\/strong> (smart contract<\/em>). En esencia, es un caso particular de cuenta, complementado con el c\u00f3digo del smart contract y un almacenamiento de sus variables. Si en el caso de una \"billetera\" se puede depositar y retirar dinero de forma relativamente simple y predefinida, en el caso del smart contract esas reglas est\u00e1n escritas en forma de su c\u00f3digo (en un lenguaje de programaci\u00f3n de Turing completo).<\/p>\n<\/p>\n
Estado de la blockchain<\/strong> (state of blockchain<\/em>). La combinaci\u00f3n de los estados de todas las cuentas\/smart contracts (en un sentido abstracto, es una tabla hash donde las claves son los identificadores de las cuentas y los valores son los datos almacenados en las cuentas).<\/p>\n<\/p>\n
Mensaje<\/strong> (message<\/em>). Anteriormente, utilic\u00e9 la expresi\u00f3n \"depositar y retirar dinero\" \u2014 este es un ejemplo espec\u00edfico de mensaje (\"transferir N gramos<\/em> de la cuenta account_1<\/em> a la cuenta account_2<\/em>\"). Evidentemente, solo un nodo que posea la clave privada de la cuenta puede enviar tal mensaje account_1<\/em> \u2014 y debe confirmar esto con una firma. El resultado de la entrega de tales mensajes a una cuenta normal es el aumento de su saldo, y para un smart contract es la ejecuci\u00f3n de su c\u00f3digo (que procesar\u00e1 la recepci\u00f3n del mensaje). Por supuesto, tambi\u00e9n existen otros mensajes (que transfieren no montos de dinero, sino datos arbitrarios entre smart contracts).<\/p>\n<\/p>\n
La transacci\u00f3n<\/strong> (transacci\u00f3n<\/em>). El hecho de la entrega del mensaje se llama transacci\u00f3n. Las transacciones cambian el estado de la blockchain. Es a partir de las transacciones (registros de entrega de mensajes) de donde se forman los bloques en la blockchain. En este sentido, podemos imaginar el estado de la blockchain como una base de datos incremental: todos los bloques son 'diffs' que deben aplicarse secuencialmente para obtener el estado actual de la base de datos. Sobre los detalles del empaquetado de estos 'diffs' (y la recuperaci\u00f3n del estado completo a partir de ellos) se hablar\u00e1 en el siguiente art\u00edculo.<\/p>\n<\/p>\n
Blockchain en TON: \u00bfqu\u00e9 es y para qu\u00e9 sirve?<\/h3>\n <\/p>\n
Como se mencion\u00f3 en el art\u00edculo anterior, la blockchain es una estructura de datos cuyos elementos (bloques) est\u00e1n organizados en una 'cadena', y cada bloque siguiente en la cadena contiene el hash del anterior<\/em>. En los comentarios se plante\u00f3 la pregunta: \u00bfpara qu\u00e9 necesitamos realmente tal estructura de datos cuando ya tenemos DHT, que es una tabla hash distribuida? Es evidente que algunos datos pueden almacenarse en DHT, pero esto solo es adecuado para informaci\u00f3n que no es demasiado 'sensible'. No se pueden almacenar los saldos de criptomonedas en DHT, principalmente debido a la falta de verificaciones de integridad<\/em>. De hecho, toda la complejidad de la estructura de blockchain surge para evitar interferencias en los datos almacenados en ella.<\/p>\n<\/p>\n
Sin embargo, la blockchain en TON parece ser a\u00fan m\u00e1s compleja que en la mayor\u00eda de los otros sistemas distribuidos, y hay dos razones para ello. La primera es el deseo de minimizar la necesidad de forks<\/em>. En las criptomonedas tradicionales, todos los par\u00e1metros est\u00e1n establecidos en la etapa inicial y cualquier intento de cambiarlos pr\u00e1cticamente conduce a la aparici\u00f3n de un 'universo alternativo de criptomonedas'. La segunda raz\u00f3n es el soporte para el sharding de la blockchain. La blockchain es una estructura que no puede volverse m\u00e1s peque\u00f1a con el tiempo; y normalmente, cada nodo responsable del funcionamiento de la red se ve obligado a almacenarla en su totalidad. En los sistemas tradicionales (centralizados), se utiliza el sharding para resolver tales problemas: parte de los registros en la base de datos se almacena en un servidor, parte en otro, etc. En el caso de las criptomonedas, esta funcionalidad sigue siendo bastante rara, especialmente porque es complicado a\u00f1adir sharding a un sistema donde no fue planeado desde el principio.\u00bfC\u00f3mo planea TON resolver ambos problemas descritos anteriormente?<\/em>, fragmentaci\u00f3n<\/em>) blockchain. El blockchain es una estructura que no puede hacerse m\u00e1s peque\u00f1a con el tiempo; y generalmente, cada nodo responsable del funcionamiento de la red se ve obligado a almacenarlo completamente. En sistemas tradicionales (centralizados), se utiliza la fragmentaci\u00f3n para resolver problemas similares: parte de los registros en la base de datos se encuentra en un servidor, otra parte en otro, etc. En el caso de las criptomonedas, dicha funcionalidad es bastante rara hasta ahora, especialmente porque es complicado a\u00f1adir fragmentaci\u00f3n a un sistema donde no estaba planificada originalmente.<\/p>\n<\/p>\n
\u00bfC\u00f3mo planea TON resolver ambos problemas descritos anteriormente?<\/p>\n
<\/p>\n
Contenido de la blockchain. Workchains.<\/h3>\n <\/p>\n
<\/p>\n
Primero, hablemos sobre qu\u00e9 se planea almacenar en la blockchain. All\u00ed se almacenar\u00e1n los estados de las cuentas (\"billeteras\" en el caso b\u00e1sico) y de los contratos inteligentes (para simplificar, consideraremos que esto es lo mismo que las cuentas). En esencia, ser\u00e1 una simple tabla hash: las claves ser\u00e1n los identificadores account_id<\/strong>, y los valores ser\u00e1n estructuras de datos que contienen elementos como:<\/p>\n<\/p>\n
\nsaldo;<\/li>\n c\u00f3digo del contrato inteligente (solo para contratos inteligentes);<\/li>\n almacenamiento de datos del contrato inteligente (solo para contratos inteligentes);<\/li>\n estad\u00edsticas;<\/li>\n (opcionalmente<\/em>) clave p\u00fablica para transferencias desde la cuenta, por defecto account_id;<\/li>\ncola de mensajes salientes (aqu\u00ed se almacenan para enviar al destinatario);<\/li>\n lista de los \u00faltimos mensajes entregados a esta cuenta.<\/li>\n<\/ul>\n<\/p>\n
Como se mencion\u00f3 anteriormente, los bloques consisten directamente en transacciones: mensajes entregados a diversas cuentas account_id. Sin embargo, adem\u00e1s de account_id, los mensajes tambi\u00e9n contienen un campo de 32 bits workchain_id<\/em> \u2014 el identificador del llamado workchain<\/strong> (workchain<\/em>, blockchain en funcionamiento<\/em>). Esto permite tener m\u00faltiples blockchains independientes entre s\u00ed con diferentes configuraciones. En este caso, workchain_id = 0 se considera un caso especial, workchain nulo<\/strong> \u2014 precisamente los saldos en \u00e9l corresponder\u00e1n a la criptomoneda TON (Grams). Es muy probable que, al principio, no existan otros workchains.<\/p>\n<\/p>\n
Sharding. Paradigma de Sharding Infinito.<\/h3>\n <\/p>\n
Pero la cantidad de blockchains no se detiene aqu\u00ed. Analicemos el sharding. Imaginemos que a cada cuenta (account_id) se le asigna su propia blockchain: en ella reposan todos los mensajes que le llegan, y los estados de todas esas blockchains se almacenan en nodos separados.<\/p>\n
<\/p>\n
Por supuesto, esto es bastante derrochador: probablemente, en cada uno de estos shardchains<\/strong> (shardchain<\/em>, blockchain shard<\/em>) las transacciones llegar\u00e1n muy raramente, y se necesitar\u00e1n muchos nodos potentes (adelantando, se\u00f1alar\u00e9 que no se trata simplemente de clientes en tel\u00e9fonos m\u00f3viles, sino de servidores serios).<\/p>\n<\/p>\n
Por lo tanto, los shardchains agrupan cuentas por los prefijos binarios de sus identificadores: si un shardchain tiene un prefijo 0110, entonces incluir\u00e1 las transacciones de todas las account_id que comienzan con esos d\u00edgitos. Este shard_prefix<\/em> puede tener una longitud de 0 a 60 bits, y lo m\u00e1s importante es que puede cambiar din\u00e1micamente.<\/p>\n<\/p>\n
<\/p>\n
Cuando uno de los shardchains comienza a recibir un n\u00famero excesivo de transacciones, los nodos que trabajan en \u00e9l, siguiendo unas reglas predefinidas, lo \"dividen\" en dos subcomponentes; sus prefijos ser\u00e1n un bit m\u00e1s largos (y para uno de ellos este bit ser\u00e1 0, y para el otro ser\u00e1 1). Por ejemplo, shard_prefix<\/em> = 0110<\/u>b se dividir\u00e1 en 0110<\/u>0b y 0110<\/u>1b. A su vez, si dos shardchains \"vecinos\" comienzan a sentir suficiente tranquilidad (durante alg\u00fan tiempo), se fusionar\u00e1n nuevamente.<\/p>\n <\/p>\n
De esta manera, el sharding se hace \"de abajo hacia arriba\"; asumimos que cada cuenta tiene su propio shard, pero estos est\u00e1n, por un tiempo, \"pegados\" por prefijos. Esto es lo que significa Paradigma de Fragmentaci\u00f3n Infinita<\/strong> (la par\u00e1bola de sharding infinito.<\/em>).<\/p>\n<\/p>\n
Cabe destacar que los workchains existen solo de manera virtual; en realidad, workchain_id<\/em> esto es parte del identificador de un shardchain espec\u00edfico. Hablando en t\u00e9rminos formales, cada shardchain se define por un par de n\u00fameros (workchain_id<\/em>, shard_prefix<\/em>).<\/p>\n<\/p>\n
Correcci\u00f3n de errores. Blockchains verticales.<\/h3>\n <\/p>\n
Tradicionalmente se considera que cualquier transacci\u00f3n en una blockchain est\u00e1 \"esculpida en piedra\". Sin embargo, en el caso de TON se prev\u00e9 la posibilidad de \"reescribir la historia\" \u2014 en caso de que alguien (el llamado nodo \"pescador\"<\/em>) demuestre que uno de los bloques fue firmado incorrectamente. En este caso, se a\u00f1ade un bloque correctivo especial al shardchain correspondiente, que contiene el hash del bloque siendo corregido (y no del \u00faltimo bloque en el shardchain). Al considerar el shardchain como una cadena de bloques dispuesta horizontalmente, se puede decir que el bloque correctivo se adjunta al bloque err\u00f3neo no a la derecha, sino en la parte superior; por tanto, se considera que se convierte en parte de un peque\u00f1o \"blockchain vertical\". As\u00ed, se puede afirmar que los shardchains son blockchains bidimensionales.<\/em>.<\/p>\n<\/p>\n
<\/p>\n
En caso de que, tras un bloque err\u00f3neo, los bloques posteriores hagan referencia a los cambios introducidos (es decir, se hayan realizado nuevas transacciones basadas en datos no v\u00e1lidos), se a\u00f1aden correcciones a esos bloques \"encima\". Si los bloques no afectaron a la informaci\u00f3n \"afectada\", estas \"ondas correctivas\" no se extienden a ellos. Por ejemplo, en la ilustraci\u00f3n anterior, se consider\u00f3 incorrecta la transacci\u00f3n del primer bloque, que aumentaba el saldo de la cuenta C; por lo tanto, la transacci\u00f3n que reduce el saldo de esta cuenta en el tercer bloque tambi\u00e9n debe ser anulada, y se debe a\u00f1adir un bloque correctivo encima del bloque mismo.<\/p>\n
<\/p>\n
Es necesario se\u00f1alar que, aunque los bloques correctivos se muestran colocados \"sobre\" los originales, en realidad se escriben al final de la cadena de bloques correspondiente (donde deben estar cronol\u00f3gicamente). La disposici\u00f3n bidimensional simplemente muestra a qu\u00e9 punto de la cadena de bloques se 'enganchar\u00e1n' (a trav\u00e9s del hash del bloque original que contienen).<\/p>\n
<\/p>\n
Se podr\u00eda reflexionar por separado sobre cu\u00e1n buena es la decisi\u00f3n de \"cambiar el pasado\". Parecer\u00eda que, si permitimos la posibilidad de que aparezca un bloque incorrecto en la shardchain, no se puede evitar la posibilidad de que aparezca un bloque correctivo err\u00f3neo. Aqu\u00ed, tanto como puedo juzgar, la diferencia radica en la cantidad de nodos que deben alcanzar consenso sobre los nuevos bloques: bajo cada shardchain trabajar\u00e1 un relativamente peque\u00f1o \"grupo de trabajo<\/em>de\" nodos (que cambia bastante a menudo), mientras que la introducci\u00f3n de bloques correctivos requerir\u00e1 el consenso de todos los nodos validadores<\/em>. Hablar\u00e9 m\u00e1s sobre validadores, grupos de trabajo y otros roles de los nodos en el siguiente art\u00edculo.<\/p>\n<\/p>\n
Una cadena de bloques para gobernarlos a todos<\/h3>\n <\/p>\n
Se ha mencionado mucha informaci\u00f3n sobre los diferentes tipos de cadenas de bloques, que tambi\u00e9n debe ser almacenada en alg\u00fan lugar. En particular, se trata de la siguiente informaci\u00f3n:<\/p>\n
<\/p>\n
\nsobre la cantidad y configuraciones de los workchains;<\/li>\n sobre la cantidad de shardchains y sus prefijos;<\/li>\n sobre qu\u00e9 nodos son actualmente responsables de qu\u00e9 shardchains;<\/li>\n hashes de los \u00faltimos bloques a\u00f1adidos a todas las shardchains.<\/li>\n<\/ul>\n<\/p>\n
Como ya habr\u00e1n deducido, todas estas cosas se registran en otra cadena de bloques de almacenamiento \u2014 masterchain<\/strong> (masterchain<\/em>, cadena de bloques maestra<\/em>). Gracias a la presencia de hashes de los bloques de todas las cadenas laterales en sus bloques, hace que el sistema est\u00e9 altamente interconectado. Esto significa que la generaci\u00f3n de un nuevo bloque en la cadena principal ocurrir\u00e1 directamente despu\u00e9s de la generaci\u00f3n de bloques en las cadenas laterales, y se espera que los bloques en las cadenas laterales aparezcan casi simult\u00e1neamente cada 5 segundos, mientras que el siguiente bloque en la cadena principal aparecer\u00e1 un segundo despu\u00e9s de esto.<\/p>\n<\/p>\n
Pero, \u00bfqui\u00e9n ser\u00e1 responsable de llevar a cabo todo este tit\u00e1nico trabajo: la transmisi\u00f3n de mensajes, la ejecuci\u00f3n de contratos inteligentes, la formaci\u00f3n de bloques en las cadenas laterales y en la cadena principal, y adem\u00e1s la verificaci\u00f3n de bloques en busca de errores? \u00bfRealmente se encargar\u00e1 de todo esto en silencio los tel\u00e9fonos de millones de usuarios con Telegram instalado? O, tal vez, el equipo de Durov renunciar\u00e1 a las ideas de descentralizaci\u00f3n y ser\u00e1n sus servidores los que lo hagan a la antigua usanza?<\/p>\n
<\/p>\n
De hecho, ninguna de las dos respuestas es correcta. Pero el espacio de este art\u00edculo se est\u00e1 agotando r\u00e1pidamente, por lo que la discusi\u00f3n sobre los diferentes roles de los nodos (ya es posible que haya notado menciones de algunos de ellos), as\u00ed como sobre las mec\u00e1nicas de su funcionamiento, se tratar\u00e1 en la siguiente parte.<\/p>\n
Fuente: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0414\u0430\u043d\u043d\u044b\u0439 \u0442\u0435\u043a\u0441\u0442 \u2014 \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u0441\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0442\u0435\u0439, \u0432 \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u044f \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u044e \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 (\u043f\u0440\u0435\u0434\u043f\u043e\u043b\u043e\u0436\u0438\u0442\u0435\u043b\u044c\u043d\u043e) \u0433\u043e\u0442\u043e\u0432\u044f\u0449\u0435\u0439\u0441\u044f \u043a \u0432\u044b\u0445\u043e\u0434\u0443 \u0432 \u044d\u0442\u043e\u043c \u0433\u043e\u0434\u0443 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438 Telegram Open Network (TON). \u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0447\u0430\u0441\u0442\u0438 \u044f \u043e\u043f\u0438\u0441\u0430\u043b \u0435\u0451 \u0441\u0430\u043c\u044b\u0439 \u0431\u0430\u0437\u043e\u0432\u044b\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u2014 \u0441\u043f\u043e\u0441\u043e\u0431 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u0443\u0437\u043b\u043e\u0432 \u043c\u0435\u0436\u0434\u0443 \u0441\u043e\u0431\u043e\u0439. \u041d\u0430 \u0432\u0441\u044f\u043a\u0438\u0439 \u0441\u043b\u0443\u0447\u0430\u0439 \u043d\u0430\u043f\u043e\u043c\u043d\u044e, \u0447\u0442\u043e \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u044d\u0442\u043e\u0439 \u0441\u0435\u0442\u0438 \u044f \u043e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u043d\u0435 \u0438\u043c\u0435\u044e \u0438 \u0432\u0435\u0441\u044c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26098,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34631","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"TON:](\"\/wp-content\/uploads\/2019\/05\/e2a24aa1dda6a435e60da257af662853.png\")
<\/p>\n