Este texto é a continuación dunha serie de artigos nos que examino a estrutura da rede (presumiblemente) distribuída Telegram Open Network (TON), que se está a preparar para a súa estrea este ano. EN Describín o seu nivel máis básico: a forma en que os nodos interactúan entre si.
Por se acaso, permítanme recordarvos que non teño nada que ver co desenvolvemento desta rede e que todo o material foi recollido dunha fonte aberta (aínda que non verificada). (tamén hai un acompañamento , resumindo brevemente os principais puntos), que apareceron a finais do ano pasado. A cantidade de información deste documento, na miña opinión, indica a súa autenticidade, aínda que non existe unha confirmación oficial diso.
Hoxe veremos o compoñente principal de TON: a cadea de bloques.
Conceptos básicos
Conta (conta). Un conxunto de datos identificados por un número de 256 bits ID_conta (a maioría das veces esta é a chave pública do propietario da conta). No caso base (ver a continuación cadea de traballo cero), estes datos refírese ao saldo do usuario. "Ocupar" específico ID_conta calquera pode, pero o seu valor só se pode cambiar segundo determinadas regras.
Contrato intelixente (contrato intelixente). En esencia, é un caso especial dunha conta, complementado con código de contrato intelixente e almacenamento das súas variables. Se no caso dunha "cartera" pode depositar e retirar diñeiro dela de acordo con regras relativamente sinxelas e predeterminadas, entón no caso dun contrato intelixente estas regras están escritas na forma do seu código (nun certo Turing-completo). linguaxe de programación).
Estado da cadea de bloques (estado da cadea de bloques). O conxunto de estados de todas as contas/contratos intelixentes (nun sentido abstracto, unha táboa hash, onde as claves son os identificadores da conta e os valores son os datos almacenados nas contas).
Mensaxe (mensaxe). Enriba usei a expresión "diñeiro de crédito e débito"; este é un exemplo particular de mensaxe ("transferencia N gramos dende a conta conta_1 dar conta conta_2"). Obviamente, só o nodo que posúe a clave privada da conta pode enviar tal mensaxe conta_1 - e capaz de confirmar isto cunha sinatura. O resultado de entregar tales mensaxes a unha conta normal é un aumento do seu saldo e o resultado do contrato intelixente é a execución do seu código (que procesará a recepción da mensaxe). Por suposto, tamén son posibles outras mensaxes (transferencia non de cantidades monetarias, senón de datos arbitrarios entre contratos intelixentes).
Transacción (transacción). O feito de que se entregue unha mensaxe chámase transacción. As transaccións cambian o estado da cadea de bloques. Son as transaccións (rexistros de entrega de mensaxes) as que compoñen os bloques da cadea de bloques. Neste sentido, podes pensar no estado da cadea de bloques como unha base de datos incremental: todos os bloques son "diferencias" que deben aplicarse secuencialmente para obter o estado actual da base de datos. Os detalles de empaquetar estas "diferencias" (e restaurar o estado completo deles) serán discutidos no seguinte artigo.
Blockchain en TON: que é e por que?
Como se mencionou no artigo anterior, blockchain é unha estrutura de datos, cuxos elementos (bloques) están ordenados nunha "cadea" e cada bloque posterior da cadea contén un hash do anterior.. Os comentarios facían a pregunta: por que necesitamos unha estrutura de datos así cando xa temos un DHT, unha táboa hash distribuída? Obviamente, algúns datos pódense almacenar en DHT, pero isto só é adecuado para información non demasiado "sensible". Os saldos de criptomonedas non se poden almacenar en DHT, principalmente debido á falta de comprobacións integridade. En realidade, toda a complexidade da estrutura da cadea de bloques crece para evitar interferencias cos datos almacenados nela.
Non obstante, a cadea de bloques en TON parece aínda máis complexa que na maioría dos outros sistemas distribuídos, e por dúas razóns. O primeiro é o desexo de minimizar a necesidade de garfos. Nas criptomoedas tradicionais, todos os parámetros establécense na fase inicial e calquera intento de cambialos conduce realmente á aparición dun "universo alternativo de criptomoedas". O segundo motivo é o apoio á trituración (fragmentación, fragmentación) cadea de bloques. Blockchain é unha estrutura que non pode facerse máis pequena co paso do tempo; e normalmente cada nodo responsable do funcionamento da rede vese obrigado a almacenala completamente. Nos sistemas tradicionais (centralizados) utilízase o sharding para resolver este tipo de problemas: algúns dos rexistros da base de datos sitúanse nun servidor, outros noutro, etc. No caso das criptomoedas, tal funcionalidade aínda é bastante rara, en particular, debido ao feito de que é difícil engadir fragmentos a un sistema onde non estaba previsto orixinalmente.
Como pensa TON resolver os dous problemas anteriores?
Contido blockchain. Cadeas de traballo.
En primeiro lugar, imos falar do que se planea almacenar na cadea de bloques. Os estados das contas ("carteras" no caso base) e os contratos intelixentes almacenaranse alí (para simplificar, asumiremos que isto é o mesmo que as contas). En esencia, esta será unha táboa hash normal; as claves nela serán identificadores ID_conta, e os valores son estruturas de datos que conteñen cousas como:
- equilibrio;
- código de contrato intelixente (só para contratos intelixentes);
- almacenamento de datos de contratos intelixentes (só para contratos intelixentes);
- estatísticas;
- (opcional) chave pública para transferencias desde a conta, por defecto account_id;
- cola de mensaxes saíntes (aquí introdúcense para reenviar ao destinatario);
- unha lista das últimas mensaxes enviadas a esta conta.
Como se mencionou anteriormente, os propios bloques consisten en transaccións: mensaxes entregadas a varias contas account_id. Non obstante, ademais de account_id, as mensaxes tamén conteñen un campo de 32 bits workchain_id - o chamado identificador cadea de traballo (cadea de traballo, blockchain funcionando). Isto permítelle ter varias cadeas de bloques independentes entre si con configuracións diferentes. Neste caso, workchain_id = 0 considérase un caso especial, cadea de traballo cero — Son os saldos nel os que corresponderán á criptomoeda TON (Gramos). O máis probable é que, nun principio, non existan outras cadeas de traballo.
Cadenas de fragmentos. Paradigma de fragmentación infinita.
Pero o crecemento do número de blockchains non se detén aí. Ocupémonos do sharding. Imaxinemos que a cada conta (account_id) se lle asigna a súa propia cadea de bloques (contén todas as mensaxes que chegan a ela) e os estados de todas esas cadeas de bloques almacénanse en nós separados.
Por suposto, isto é moi despilfarrador: moi probablemente, en cada un destes cadeas de fragmentos (cadea de fragmentos, cadea de bloques de fragmentos) as transaccións chegarán moi raramente e serán necesarios moitos nodos potentes (de cara ao futuro, observo que non só falamos de clientes en teléfonos móbiles, senón de servidores serios).
Polo tanto, as shardchain combinan contas polos prefixos binarios dos seus identificadores: se unha shardchain ten un prefixo 0110, incluirá as transaccións de todos os account_ids que comezan con estes números. Isto prefixo_shard pode ter unha lonxitude de 0 a 60 bits - e o principal é que pode cambiar de forma dinámica.
En canto unha das cadeas de fragmentos comeza a recibir demasiadas transaccións, os nodos que traballan nela, segundo regras predeterminadas, "divídense" en dous fillos; os seus prefixos serán un pouco máis longos (e para un deles este bit será igual a 0, e para o outro - 1). Por exemplo, prefixo_shard = 0110b dividirase en 01100b e 01101b. Á súa vez, se dúas cadeas de fragmentos "veciños" comezan a sentirse a gusto o suficiente (durante algún tempo), volverán a fusionarse.
Así, o fragmento realízase "de abaixo cara arriba": supoñemos que cada conta ten o seu propio fragmento, pero polo momento están "pegados" por prefixos. Isto é o que significa Paradigma de fragmentación infinita (paradigma de fragmentación infinita).
Por separado, gustaríame enfatizar que as cadeas de traballo só existen virtualmente; de feito, workchain_id forma parte do identificador dunha cadea de fragmentos específica. En termos formais, cada shardchain está definida por un par de números (workchain_id, prefixo_shard).
Corrección de erros. Blockchains verticais.
Tradicionalmente, calquera transacción nunha cadea de bloques considérase "fixada na pedra". Non obstante, no caso de TON, é posible "escribir o historial" - no caso de que alguén (o chamado. nó de pescador) acreditará que un dos bloques estaba asinado incorrectamente. Neste caso, engádese un bloque de corrección especial á cadea de fragmentos correspondente, que contén o hash do propio bloque que se está corrixindo (e non o último bloque da cadea de fragmentos). Pensando na cadea de fragmentos como unha cadea de bloques dispostas horizontalmente, podemos dicir que o bloque corrector está unido ao bloque erróneo non á dereita, senón desde arriba, polo que se considera que pasa a formar parte dunha pequena "cadea de bloques vertical". . Así, podemos dicir que as shardchains son cadeas de bloques bidimensionais.
Se, despois dun bloque erróneo, os cambios realizados por este foron referenciados por bloques posteriores (é dicir, se fixeron novas transaccións baseadas en transaccións non válidas), tamén se engaden a estes bloques "enriba" os correctores. Se os bloques non afectaron á información "afectada", estas "ondas correctoras" non se lles aplican. Por exemplo, na ilustración anterior, a transacción do primeiro bloque, que aumenta o saldo da conta C, foi recoñecida como incorrecta; polo tanto, a transacción que reduce o saldo desta conta no terceiro bloque tamén debe cancelarse e un bloque corrector debe comprometerse enriba do propio bloque.
Nótese que aínda que os bloques correctores se representan como situados "por riba" dos orixinais, de feito engadiranse ao final da cadea de bloques correspondente (onde deberían estar cronoloxicamente). A localización bidimensional só mostra a que punto da cadea de bloques estarán "ligadas" (a través do hash do bloque orixinal situado neles).
Podes filosofar por separado sobre o boa que é a decisión de "cambiar o pasado". Parece que se admitimos a posibilidade de que apareza un bloque incorrecto na cadea de fragmentos, non podemos evitar a posibilidade de que apareza un bloque corrector erróneo. Aquí, polo que podo dicir, a diferenza está no número de nodos que deben chegar a un consenso sobre novos bloques: haberá un número relativamente pequeno de persoas traballando en cada shardchain".grupo de traballo» nodos (que cambia a súa composición con bastante frecuencia), e a introdución de bloques correctores requirirá o consentimento de todos nodos validadores. Falarei máis sobre validadores, grupos de traballo e outros roles de nodos no seguinte artigo.
Unha cadea de bloques para gobernalos a todos
Hai moita información listada anteriormente sobre os diferentes tipos de cadeas de bloques, que tamén deberían almacenarse nalgún lugar. En concreto, estamos a falar da seguinte información:
- sobre o número e configuración das cadeas de traballo;
- sobre o número de shardchains e os seus prefixos;
- sobre cales nodos son actualmente responsables de que shardchains;
- hash dos últimos bloques engadidos a todas as shardchains.
Como poderías adiviñar, todas estas cousas están rexistradas noutro almacenamento blockchain - masterchain (masterchain, master blockchain). Debido á presenza de hash dos bloques de todas as shardchains dos seus bloques, fai que o sistema sexa moi conectado. Isto significa, entre outras cousas, que a xeración dun novo bloque na cadea mestra producirase inmediatamente despois da xeración de bloques nas cadeas de fragmentos; espérase que os bloques nas cadeas de fragmentos aparezan case simultáneamente aproximadamente cada 5 segundos, e o seguinte bloque no masterchain - un segundo despois.
Pero quen será o responsable da implementación de todo este traballo titánico: enviar mensaxes, executar contratos intelixentes, formar bloques en shardchains e masterchain, e mesmo comprobar os bloques para detectar erros? Todo isto será feito en segredo polos teléfonos de millóns de usuarios co cliente de Telegram instalado neles? Ou, quizais, o equipo de Durov abandonará as ideas de descentralización e os seus servidores o farán á antiga usanza?
De feito, nin unha nin outra resposta son correctas. Pero as marxes deste artigo estanse esgotando rapidamente, polo que falaremos sobre os distintos roles dos nodos (pode que xa teñas notado as mencións dalgúns deles), así como a mecánica do seu traballo, na seguinte parte.
Fonte: www.habr.com