<\/a><\/noindex><\/p>\nConceitos B\u00e1sicos<\/h3>\n <\/p>\n
Conta<\/strong> (account<\/em>). Um conjunto de dados, identificado por um n\u00famero de 256 bits account_id<\/em> (geralmente, \u00e9 a chave p\u00fablica do propriet\u00e1rio da conta). No caso b\u00e1sico (veja abaixo blockchain zero<\/em>), esses dados referem-se ao saldo do usu\u00e1rio. \"Pegar empr\u00e9stimo\" de um espec\u00edfico account_id<\/em> pode qualquer um, mas seu valor s\u00f3 pode ser alterado de acordo com regras espec\u00edficas.<\/p>\n<\/p>\n
Contrato inteligente<\/strong> (smart-contract<\/em>). Essencialmente, \u00e9 um caso particular de conta, complementado pelo c\u00f3digo do contrato inteligente e pelo armazenamento de suas vari\u00e1veis. Se, no caso de uma \"carteira\", \u00e9 poss\u00edvel depositar e retirar dinheiro dela por regras relativamente simples e predefinidas, no caso do contrato inteligente essas regras est\u00e3o escritas na forma de seu c\u00f3digo (em uma linguagem de programa\u00e7\u00e3o que \u00e9 Turing-completa).<\/p>\n<\/p>\n
Estado do blockchain<\/strong> (state of blockchain<\/em>). Conjunto de estados de todas as contas\/contratos inteligentes (em um sentido abstrato \u2014 uma tabela hash, onde as chaves s\u00e3o identificadores de contas e os valores s\u00e3o os dados armazenados nas contas).<\/p>\n<\/p>\n
Mensagem<\/strong> (message<\/em>). Acima, usei a express\u00e3o \"depositar e retirar dinheiro\" \u2014 este \u00e9 um exemplo espec\u00edfico de mensagem (\"transferir N gramas<\/em> da conta account_1<\/em> para a conta account_2<\/em>\"). Obviamente, apenas um n\u00f3 que possui a chave privada da conta pode enviar tal mensagem. account_1<\/em> \u2014 e capaz de confirmar isso com uma assinatura. O resultado da entrega de tais mensagens a uma conta comum \u00e9 o aumento de seu saldo, enquanto ao contrato inteligente \u2014 a execu\u00e7\u00e3o de seu c\u00f3digo (que processar\u00e1 a recep\u00e7\u00e3o da mensagem). \u00c9 claro que outras mensagens tamb\u00e9m podem ser enviadas (n\u00e3o transferindo quantias monet\u00e1rias, mas dados arbitr\u00e1rios entre contratos inteligentes).<\/p>\n<\/p>\n
A transa\u00e7\u00e3o<\/strong> (transa\u00e7\u00e3o<\/em>). O fato da entrega da mensagem \u00e9 chamado de transa\u00e7\u00e3o. Transa\u00e7\u00f5es alteram o estado da blockchain. \u00c9 exatamente a partir das transa\u00e7\u00f5es (registros de entrega de mensagens) que os blocos na blockchain s\u00e3o formados. Nesse aspecto, pode-se imaginar o estado da blockchain como um banco de dados incremental \u2014 todos os blocos s\u00e3o 'deltas' que precisam ser aplicados sequencialmente para obter o estado atual do BD. Sobre a especificidade da embalagem desses 'deltas' (e a restaura\u00e7\u00e3o do estado completo a partir deles) falaremos no pr\u00f3ximo artigo.<\/p>\n<\/p>\n
Blockchain no TON: o que \u00e9 e para que serve?<\/h3>\n <\/p>\n
Como mencionado no artigo anterior, a blockchain \u00e9 uma estrutura de dados, cujos elementos (blocos) est\u00e3o organizados em uma 'cadeia', e cada bloco subsequente da cadeia cont\u00e9m o hash do bloco anterior<\/em>. Nos coment\u00e1rios, foi feita a pergunta: para que uma tal estrutura de dados \u00e9 necess\u00e1ria, quando j\u00e1 temos o DHT - tabela hash distribu\u00edda? \u00c9 evidente que alguns dados podem ser armazenados no DHT, mas isso s\u00f3 \u00e9 adequado para informa\u00e7\u00f5es que n\u00e3o s\u00e3o muito 'sens\u00edveis'. N\u00e3o se pode armazenar saldos de criptomoedas no DHT \u2014 principalmente devido \u00e0 falta de verifica\u00e7\u00f5es sobre integridade<\/em>. De fato, toda a complexidade da estrutura da blockchain cresce para prevenir interfer\u00eancias nos dados armazenados nela.<\/p>\n<\/p>\n
No entanto, a blockchain no TON parece ainda mais complexa do que na maioria dos outros sistemas distribu\u00eddos \u2014 e isso se deve a duas raz\u00f5es. A primeira \u00e9 a busca por minimizar a necessidade de forks<\/em>. Nas criptomoedas tradicionais, todos os par\u00e2metros s\u00e3o definidos na fase inicial, e qualquer tentativa de alter\u00e1-los resulta, na verdade, na cria\u00e7\u00e3o de um 'universo alternativo de criptomoeda'. A segunda raz\u00e3o \u00e9 o suporte \u00e0 fragmenta\u00e7\u00e3o (sharding<\/em>, shardiza\u00e7\u00e3o<\/em>) do blockchain. O blockchain \u00e9 uma estrutura que n\u00e3o pode diminuir com o tempo; e normalmente, cada n\u00f3 respons\u00e1vel pela opera\u00e7\u00e3o da rede \u00e9 obrigado a armazen\u00e1-lo totalmente. Em sistemas tradicionais (centralizados), para resolver problemas semelhantes, utiliza-se o sharding: parte dos registros no banco de dados fica em um servidor, parte em outro, e assim por diante. No caso das criptomoedas, tal funcionalidade ainda \u00e9 bastante rara \u2014 em particular, devido \u00e0 dificuldade de adicionar sharding a um sistema onde n\u00e3o foi planejado desde o in\u00edcio.<\/p>\n<\/p>\n
Como o TON planeja resolver ambos os problemas descritos acima?<\/p>\n
<\/p>\n
Conte\u00fado do blockchain. Workchains.<\/h3>\n <\/p>\n
<\/p>\n
Primeiramente, vamos falar sobre o que est\u00e1 planejado para ser armazenado no blockchain. Estar\u00e3o l\u00e1 os estados das contas (\u2018carteiras\u2019 no caso b\u00e1sico) e contratos inteligentes (para simplificar, consideraremos que isso \u00e9 o mesmo que contas). Em ess\u00eancia, ser\u00e1 uma tabela hash comum \u2014 suas chaves ser\u00e3o os identificadores account_id<\/strong>, e os valores ser\u00e3o estruturas de dados que cont\u00eam coisas como:<\/p>\n<\/p>\n
\nsaldo;<\/li>\n c\u00f3digo do contrato inteligente (apenas para contratos inteligentes);<\/li>\n armazenamento de dados do contrato inteligente (apenas para contratos inteligentes);<\/li>\n estat\u00edsticas;<\/li>\n (opcionalmente<\/em>) chave p\u00fablica para transfer\u00eancias da conta, por padr\u00e3o account_id;<\/li>\nfila de mensagens de sa\u00edda (aqui elas s\u00e3o armazenadas para envio ao destinat\u00e1rio);<\/li>\n lista das \u00faltimas mensagens entregues a esta conta.<\/li>\n<\/ul>\n<\/p>\n
Como mencionado acima, os blocos consistem diretamente de transa\u00e7\u00f5es \u2014 mensagens enviadas para v\u00e1rias contas account_id. No entanto, al\u00e9m do account_id, as mensagens tamb\u00e9m cont\u00eam um campo de 32 bits workchain_id<\/em> \u2014 identificador do chamado workchain<\/strong> (workchain<\/em>, blockchain de trabalho<\/em>). Isso permite ter v\u00e1rios blockchains independentes uns dos outros com diferentes configura\u00e7\u00f5es. Nesse caso, workchain_id = 0 \u00e9 considerado um caso especial, workchain nulo<\/strong> \u2014 \u00e9 neste que os saldos corresponder\u00e3o \u00e0 criptomoeda TON (Grams). A probabilidade \u00e9 que, nos primeiros tempos, n\u00e3o haver\u00e1 outros workchains.<\/p>\n<\/p>\n
Shardchains. Infinite Sharding Paradigm.<\/h3>\n <\/p>\n
Mas o crescimento no n\u00famero de blockchains n\u00e3o para por a\u00ed. Vamos entender o shard. Vamos imaginar que cada conta (account_id) tenha seu pr\u00f3prio blockchain \u2014 onde est\u00e3o todas as mensagens recebidas \u2014 e o estado de todos esses blockchains \u00e9 armazenado em n\u00f3s separados.<\/p>\n
<\/p>\n
Claro, isso \u00e9 bastante dispendioso: provavelmente, em cada um desses shardchains<\/strong> (shardchain<\/em>, shard blockchain<\/em>) as transa\u00e7\u00f5es ser\u00e3o recebidas com pouca frequ\u00eancia, e ser\u00e1 necess\u00e1rio ter muitos n\u00f3s potentes (adiantando um pouco, vale ressaltar que n\u00e3o se trata apenas de clientes em telefones m\u00f3veis \u2014 mas de servidores robustos).<\/p>\n<\/p>\n
Portanto, os shardchains agrupam contas por prefixos bin\u00e1rios de seus identificadores: se um shardchain tem o prefixo 0110, ent\u00e3o ele incluir\u00e1 transa\u00e7\u00f5es de todos os account_id que come\u00e7am com esses d\u00edgitos. Este shard_prefix<\/em> pode ter um comprimento de 0 a 60 bits \u2014 e o principal \u00e9 que ele pode mudar dinamicamente.<\/p>\n<\/p>\n
<\/p>\n
Assim que um dos shardchains come\u00e7ar a receber uma quantidade excessiva de transa\u00e7\u00f5es, os n\u00f3s trabalhando nele, de acordo com regras previamente definidas, 'dividem' ele em dois filiais \u2014 seus prefixos ser\u00e3o um bit mais longos (e para um deles esse bit ser\u00e1 0, e para o outro ser\u00e1 1). Por exemplo, shard_prefix<\/em> = 0110<\/u>b se dividir\u00e1 em 0110<\/u>0b e 0110<\/u>1b. Por sua vez, se dois shardchains 'vizinhos' come\u00e7arem a se sentir confort\u00e1veis o suficiente (durante um certo per\u00edodo), eles se fundir\u00e3o novamente.<\/p>\n <\/p>\n
Assim, o shard tem uma constru\u00e7\u00e3o 'de baixo para cima' \u2014 presumimos que cada conta possui seu pr\u00f3prio shard, mas eles est\u00e3o, por um tempo, 'colados' por prefixos. Isso \u00e9 o que implica a Infinite Sharding Paradigm<\/strong> (paradigma de sharding infinito<\/em>).<\/p>\n<\/p>\n
\u00c9 importante enfatizar que os workchains existem apenas virtualmente \u2014 na verdade, workchain_id<\/em> isso \u00e9 parte do identificador de um shardchain espec\u00edfico. Em termos formais, cada shardchain \u00e9 definido por um par de n\u00fameros (workchain_id<\/em>, shard_prefix<\/em>).<\/p>\n<\/p>\n
Corre\u00e7\u00e3o de erros. Blockchains verticais.<\/h3>\n <\/p>\n
Tradicionalmente, considera-se que qualquer transa\u00e7\u00e3o em um blockchain \u00e9 'esculpida em pedra'. No entanto, no caso do TON, existe a possibilidade de 'reescrever a hist\u00f3ria' \u2014 caso algu\u00e9m (o chamado n\u00f3 'pescador')<\/em>) comprova que um dos blocos foi assinado incorretamente. Nesse caso, um bloco corretivo especial \u00e9 adicionado \u00e0 respectiva shardchain, contendo o hash do bloco que est\u00e1 sendo corrigido (e n\u00e3o do \u00faltimo bloco na shardchain). Representando a shardchain como uma cadeia de blocos disposta horizontalmente, pode-se dizer que o bloco corretivo \u00e9 anexado ao bloco incorreto n\u00e3o \u00e0 direita, mas por cima \u2014 por isso, \u00e9 considerado parte de um pequeno 'blockchain vertical'. Assim, pode-se dizer que as shardchains s\u00e3o blockchains bidimensionais<\/em>.<\/p>\n<\/p>\n
<\/p>\n
Caso ap\u00f3s o bloco incorreto as mudan\u00e7as que ele fez tenham sido referenciadas por blocos subsequentes (ou seja, novas transa\u00e7\u00f5es foram realizadas com base em dados inv\u00e1lidos), blocos corretivos tamb\u00e9m s\u00e3o adicionados 'por cima' desses blocos. Se os blocos n\u00e3o afetaram as informa\u00e7\u00f5es 'afetadas', essas 'ondas corretivas' n\u00e3o se espalham sobre eles. Por exemplo, na ilustra\u00e7\u00e3o acima, a transa\u00e7\u00e3o do primeiro bloco, que aumenta o saldo da conta C, foi considerada incorreta \u2014 portanto, a transa\u00e7\u00e3o que diminui o saldo dessa conta no terceiro bloco tamb\u00e9m deve ser anulada, e um bloco corretivo deve ser registrado sobre o pr\u00f3prio bloco.<\/p>\n
<\/p>\n
\u00c9 importante notar \u2014 embora os blocos corretivos sejam representados como localizados 'acima' dos originais, na verdade, eles ser\u00e3o adicionados ao final da respectiva blockchain (para onde deveriam estar cronologicamente). A disposi\u00e7\u00e3o bidimensional apenas mostra a que ponto na blockchain eles ser\u00e3o 'anexados' (por meio do hash do bloco original que est\u00e1 neles).<\/p>\n
<\/p>\n
Pode-se filosofar separadamente sobre qu\u00e3o boa \u00e9 a solu\u00e7\u00e3o de 'mudar o passado'. Parece que, se permitimos a possibilidade de um bloco incorreto aparecer na shardchain, n\u00e3o podemos tamb\u00e9m excluir a possibilidade de um bloco corretivo err\u00f4neo surgir. Aqui, pelo que posso julgar, a diferen\u00e7a est\u00e1 no n\u00famero de n\u00f3s que devem alcan\u00e7ar consenso sobre novos blocos \u2014 em cada shardchain, trabalha-se com um relativamente pequeno 'grupo de trabalho<\/em>' de n\u00f3s (que frequentemente altera sua composi\u00e7\u00e3o), enquanto a adi\u00e7\u00e3o de blocos corretivos exigir\u00e1 o consentimento de todos n\u00f3s-validadores<\/em>. Farei mais detalhes sobre validadores, grupos de trabalho e outras fun\u00e7\u00f5es dos n\u00f3s no pr\u00f3ximo artigo.<\/p>\n<\/p>\n
Uma blockchain para governar todas<\/h3>\n <\/p>\n
Acima foi mencionada muita informa\u00e7\u00e3o sobre os diferentes tipos de blockchains, que tamb\u00e9m precisam ser armazenadas em algum lugar. Em particular, fala-se sobre as seguintes informa\u00e7\u00f5es:<\/p>\n
<\/p>\n
\nsobre a quantidade e configura\u00e7\u00f5es de workchains;<\/li>\n sobre a quantidade de shardchains e seus prefixos;<\/li>\n sobre quais n\u00f3s est\u00e3o atualmente respons\u00e1veis por quais shardchains;<\/li>\n os hashes dos \u00faltimos blocos adicionados a todos os shardchains.<\/li>\n<\/ul>\n<\/p>\n
Como voc\u00ea j\u00e1 poderia ter adivinhado, todas essas informa\u00e7\u00f5es s\u00e3o registradas em mais um armazenamento-blockchain \u2014 masterchain<\/strong> (masterchain<\/em>, master blockchain<\/em>). Devido \u00e0 presen\u00e7a de hashes de blocos de todos os shardchains em seus blocos, ele torna o sistema fortemente interconectado. Isso significa que a gera\u00e7\u00e3o de um novo bloco na masterchain ocorrer\u00e1 imediatamente ap\u00f3s a gera\u00e7\u00e3o de blocos nos shardchains \u2014 espera-se que os blocos nos shardchains apare\u00e7am quase simultaneamente a cada 5 segundos, e o pr\u00f3ximo bloco na masterchain \u2014 um segundo depois disso.<\/p>\n<\/p>\n
Mas quem ser\u00e1 respons\u00e1vel pela implementa\u00e7\u00e3o de todo esse trabalho tit\u00e2nico \u2014 pelo envio de mensagens, execu\u00e7\u00e3o de contratos inteligentes, forma\u00e7\u00e3o de blocos nos shardchains e na masterchain, e ainda verificar os blocos quanto a erros? Ser\u00e1 que tudo isso ser\u00e1 feito silenciosamente pelos telefones de milh\u00f5es de usu\u00e1rios com o cliente do Telegram instalado? Ou talvez a equipe dos Durov desista das ideias de descentraliza\u00e7\u00e3o e isso ser\u00e1 feito pelos servidores deles da maneira tradicional?<\/p>\n
<\/p>\n
Na verdade, nem uma nem outra resposta est\u00e1 correta. Mas o espa\u00e7o deste artigo est\u00e1 rapidamente se esgotando, ent\u00e3o a conversa sobre os diferentes pap\u00e9is dos n\u00f3s (voc\u00ea pode j\u00e1 ter notado algumas men\u00e7\u00f5es a eles), bem como sobre os mecanismos de seu funcionamento, ir\u00e1 para a pr\u00f3xima parte.<\/p>\n
Fonte: 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