<\/a><\/noindex><\/p>\nConcetti di base<\/h3>\n <\/p>\n
Account<\/strong> (account<\/em>). Un insieme di dati, identificato da un numero a 256 bit account_id<\/em> (di solito si tratta della chiave pubblica del proprietario dell'account). Nel caso di base (vedi sotto blockchain nullo<\/em>), questi dati rappresentano il saldo dell'utente. Chiunque pu\u00f2 \"prendere in prestito\" un determinato account_id<\/em> ma il suo valore pu\u00f2 essere modificato solo secondo determinate regole.<\/p>\n<\/p>\n
Smart contract<\/strong> (smart-contract<\/em>). In effetti, \u00e8 un caso particolare di account, arricchito da codice di smart contract e da una repository delle sue variabili. Nel caso del \"wallet\" si possono accreditare e addebitare soldi da esso secondo regole relativamente semplici e prestabilite, mentre nel caso dello smart contract queste regole sono scritte sotto forma del suo codice (in un linguaggio di programmazione Turing completo).<\/p>\n<\/p>\n
Stato della blockchain<\/strong> (state of blockchain<\/em>). Insieme degli stati di tutti gli account\/smart contracts (in senso astratto \u2014 una tabella hash, dove le chiavi sono gli identificatori degli account e i valori sono i dati memorizzati negli account).<\/p>\n<\/p>\n
Messaggio<\/strong> (message<\/em>). Ho utilizzato sopra l'espressione \"accreditare e addebitare soldi\" \u2014 questo \u00e8 un esempio particolare di messaggio (\"trasferire N grammi<\/em> da account account_1<\/em> a account account_2<\/em>\"). \u00c8 evidente che solo un nodo in possesso della chiave privata dell'account pu\u00f2 inviare un tale messaggio. account_1<\/em> \u2014 e in grado di confermarlo con la propria firma. Il risultato della consegna di tali messaggi a un account normale \u00e8 l'aumento del suo saldo, mentre per il contratto intelligente \u00e8 l'esecuzione del suo codice (che gestir\u00e0 la ricezione del messaggio). Ovviamente, possono esistere anche altri messaggi (che trasferiscono dati arbitrari tra contratti intelligenti, non somme di denaro).<\/p>\n<\/p>\n
La transazione<\/strong> (transazione<\/em>). Il fatto che un messaggio venga consegnato \u00e8 chiamato transazione. Le transazioni modificano lo stato della blockchain. \u00c8 proprio dalle transazioni (registrazioni di consegna dei messaggi) che sono costituiti i blocchi nella blockchain. In questo senso, si pu\u00f2 considerare lo stato della blockchain come un database incrementale: tutti i blocchi sono \"diff\" che devono essere applicati in sequenza per ottenere lo stato attuale del DB. Si parler\u00e0 della specificit\u00e0 dell'imballaggio di questi \"diff\" (e del ripristino dello stato completo da essi) nel prossimo articolo.<\/p>\n<\/p>\n
Blockchain in TON: che cos'\u00e8 e a cosa serve?<\/h3>\n <\/p>\n
Come accennato nell'articolo precedente, la blockchain \u00e8 una struttura dati i cui elementi (blocchi) sono disposti in una \"catena\", e ogni blocco successivo della catena contiene l'hash di quello precedente<\/em>. Nei commenti \u00e8 stata posta la domanda: a cosa serve questa struttura dati, quando abbiamo gi\u00e0 una DHT \u2014 una tabella hash distribuita? \u00c8 chiaro che alcuni dati possono essere memorizzati anche nella DHT, ma questo \u00e8 adatto solo per informazioni non troppo \"sensibili\". Non si possono memorizzare i saldi delle criptovalute nella DHT, prima di tutto a causa dell'assenza di controlli su integrit\u00e0<\/em>. In effetti, tutta la complessit\u00e0 della struttura della blockchain si sviluppa per prevenire interferenze nei dati memorizzati al suo interno.<\/p>\n<\/p>\n
Tuttavia, la blockchain in TON appare ancora pi\u00f9 complessa rispetto alla maggior parte degli altri sistemi distribuiti \u2014 e ci sono due motivi per questo. Il primo \u00e8 la volont\u00e0 di ridurre al minimo la necessit\u00e0 di fork<\/em>. Nelle criptovalute tradizionali, tutti i parametri sono definiti all'inizio e qualsiasi tentativo di cambiarli porta di fatto alla creazione di un \"universo alternativo della criptovaluta\". Il secondo motivo \u00e8 il supporto del partizionamento (sharding<\/em>, )<\/em>) blockchain. Il blockchain \u00e8 una struttura che non pu\u00f2 ridursi nel tempo; e di solito ogni nodo responsabile del funzionamento della rete \u00e8 costretto a conservarlo completamente. Nelle tradizionali (centralizzate) sistemi, per affrontare simili problemi si utilizza lo sharding: parte dei record nel database risiede su un server, parte su un altro, e cos\u00ec via. Nel caso delle criptovalute, questa funzionalit\u00e0 \u00e8 ancora piuttosto rara, soprattutto perch\u00e9 \u00e8 difficile implementare lo sharding in un sistema dove non era stato pianificato fin dall'inizio.<\/p>\n<\/p>\n
In che modo TON intende affrontare entrambe le problematiche descritte sopra?<\/p>\n
<\/p>\n
Contenuto del blockchain. Workchains.<\/h3>\n <\/p>\n
<\/p>\n
Per cominciare, parliamo di cosa si prevede si conservi nel blockchain. Qui saranno memorizzati gli stati degli account (i 'portafogli' nel caso base) e dei contratti intelligenti (per semplicit\u00e0 consideriamo che siano la stessa cosa degli account). In sostanza, sar\u00e0 una normale tabella hash \u2014 le chiavi saranno gli identificatori account_id<\/strong>, e i valori saranno strutture dati contenenti cose come:<\/p>\n<\/p>\n
\nsaldo;<\/li>\n codice del contratto intelligente (solo per i contratti intelligenti);<\/li>\n memoria dei dati del contratto intelligente (solo per i contratti intelligenti);<\/li>\n statistiche;<\/li>\n (opzionalmente<\/em>) chiave pubblica per trasferimenti dall'account, per impostazione predefinita account_id;<\/li>\ncoda dei messaggi in uscita (qui vengono messi per essere inviati ai destinatari);<\/li>\n lista degli ultimi messaggi recapitati a questo account.<\/li>\n<\/ul>\n<\/p>\n
Come detto sopra, i blocchi consistono essenzialmente in transazioni \u2014 messaggi inviati a diversi account account_id. Tuttavia, oltre a account_id, i messaggi contengono anche un campo a 32 bit workchain_id<\/em> \u2014 identificatore del cosiddetto workchain<\/strong> (workchain<\/em>, working blockchain<\/em>). Questo consente di avere diversi blockchain indipendenti l'uno dall'altro con configurazioni diverse. In questo contesto, workchain_id = 0 \u00e8 considerato un caso speciale, workchain nullo<\/strong> \u2014 infatti i saldi in esso corrisponderanno alla criptovaluta TON (Grams). \u00c8 probabile che inizialmente non esisteranno altri workchains.<\/p>\n<\/p>\n
Shardchains. Infinite Sharding Paradigm.<\/h3>\n <\/p>\n
Ma la crescita del numero di blockchain non si ferma qui. Approfondiamo il concetto di sharding. Immaginiamo che a ciascun account (account_id) sia assegnata la propria blockchain \u2014 in essa si trovano tutti i messaggi in arrivo \u2014 e lo stato di tutte queste blockchain \u00e8 conservato su nodi separati.<\/p>\n
<\/p>\n
Certo, questo \u00e8 piuttosto dispendioso: \u00e8 probabile che in ciascuna di queste shardchain<\/strong> (shardchain<\/em>, blockchain shard<\/em>) le transazioni arriveranno molto raramente, e ci saranno bisogno di molti nodi potenti (anticipando, segnalo che non si parla semplicemente di client su telefoni cellulari, ma di server seri).<\/p>\n<\/p>\n
Pertanto, le shardchain raggruppano gli account in base ai prefissi binari dei loro identificatori: se una shardchain ha un prefisso 0110, allora ricever\u00e0 le transazioni di tutti gli account che iniziano con queste cifre. Questo shard_prefix<\/em> pu\u00f2 avere una lunghezza da 0 a 60 bit \u2014 e la cosa principale \u00e8 che pu\u00f2 cambiare dinamicamente.<\/p>\n<\/p>\n
<\/p>\n
Non appena una delle shardchain inizia a ricevere un numero eccessivo di transazioni, i nodi che operano su di essa \"dividono\" la shardchain in due figlie secondo regole predefinite \u2014 i loro prefissi saranno pi\u00f9 lunghi di un bit (e per uno di essi questo bit sar\u00e0 0, mentre per l'altro sar\u00e0 1). Ad esempio, shard_prefix<\/em> = 0110<\/u>b si divider\u00e0 in 0110<\/u>0b e 0110<\/u>1b. A sua volta, se due shardchain \"vicine\" iniziano a sentirsi abbastanza a loro agio (per un certo periodo di tempo), si fonderanno di nuovo.<\/p>\n <\/p>\n
In questo modo, lo sharding viene fatto \"dal basso verso l'alto\" \u2014 presumiamo che ciascun account possieda il proprio shard, ma essi sono - fino a un certo punto - \"incollati\" dai prefissi. Questo implica Infinite Sharding Paradigm<\/strong> (paradigma di sharding infinito<\/em>).<\/p>\n<\/p>\n
Voglio sottolineare che le workchain esistono solo virtualmente \u2014 in realt\u00e0, workchain_id<\/em> \u00e8 parte dell\u2019identificatore di una specifica shardchain. Parlando in termini formali, ogni shardchain \u00e8 definita da una coppia di numeri (workchain_id<\/em>, shard_prefix<\/em>).<\/p>\n<\/p>\n
Correzione degli errori. Blockchain verticali.<\/h3>\n <\/p>\n
Tradizionalmente si considera che ogni transazione in una blockchain sia \"incisa nella pietra\". Tuttavia, nel caso di TON \u00e8 prevista la possibilit\u00e0 di \"riscrivere la storia\" \u2014 nel caso in cui qualcuno (il cosiddetto nodo \"pescatore\"<\/em>) dimostrer\u00e0 che uno dei blocchi \u00e8 stato firmato in modo errato. In questo caso, un blocco correttivo speciale viene aggiunto al corrispondente sharding chain, contenente l'hash del blocco stesso da correggere (e non dell'ultimo blocco nello sharding chain). Rappresentando lo sharding chain come una catena di blocchi disposta orizzontalmente, si pu\u00f2 dire che il blocco correttivo si attacca al blocco errato non a destra, ma sopra \u2014 pertanto si considera che diventi parte di un piccolo 'blockchain verticale'. Cos\u00ec, si pu\u00f2 dire che gli sharding chain sono blockchain bidimensionali<\/em>.<\/p>\n<\/p>\n
<\/p>\n
Nel caso in cui dopo un blocco errato le modifiche apportate da esso siano state richiamate da blocchi successivi (cio\u00e8, siano state effettuate nuove transazioni basate su dati non validi), a questi blocchi vengono anche aggiunti correttivi 'dall'alto'. Se i blocchi non hanno toccato le informazioni 'colpite', le 'onde correttive' non si diffondono su di essi. Ad esempio, nell'illustrazione sopra, la transazione del primo blocco, che aumenta il saldo dell'account C, \u00e8 stata riconosciuta come errata \u2014 quindi la transazione che diminuisce il saldo di questo account nel terzo blocco deve anch'essa essere annullata e un blocco correttivo deve essere registrato sopra il blocco stesso.<\/p>\n
<\/p>\n
Va notato che, sebbene i blocchi correttivi siano rappresentati come posizionati 'sopra' gli originali, in realt\u00e0 saranno aggiunti alla fine del corrispondente blockchain (l\u00ec dove dovrebbero trovarsi cronologicamente). La disposizione bidimensionale mostra solo a quale punto nella blockchain saranno 'agganciati' (tramite l'hash del blocco originale contenuto in essi).<\/p>\n
<\/p>\n
Si pu\u00f2 filosofeggiare separatamente su quanto sia buona la decisione di 'cambiare il passato'. Sembrerebbe che, se tolleriamo la possibilit\u00e0 che si verifichi un blocco errato nello sharding chain, non si possa escludere nemmeno la possibilit\u00e0 di un blocco correttivo errato. Qui, per quanto posso giudicare, la differenza sta nel numero di nodi che devono raggiungere il consenso riguardo ai nuovi blocchi \u2014 su ogni sharding chain lavorer\u00e0 un relativamente piccolo 'gruppo di lavoro<\/em>' di nodi (che cambia abbastanza frequentemente), mentre l'inserimento di blocchi correttivi richieder\u00e0 il consenso di tutti i nodi validatori<\/em>. Parler\u00f2 di pi\u00f9 sui validatori, gruppi di lavoro e altri ruoli dei nodi nel prossimo articolo.<\/p>\n<\/p>\n
Un blockchain per governarli tutti<\/h3>\n <\/p>\n
Le informazioni varie sui diversi tipi di blockchain sopra citate devono essere anch'esse archiviate da qualche parte. In particolare, si tratta delle seguenti informazioni:<\/p>\n
<\/p>\n
\nsul numero e le configurazioni dei workchains;<\/li>\n s sul numero di shardchains e i loro prefissi;<\/li>\n sui nodi attualmente responsabili di quali shardchains;<\/li>\n hash degli ultimi blocchi aggiunti a tutti gli shardchains.<\/li>\n<\/ul>\n<\/p>\n
Come potreste aver intuito, tutte queste informazioni vengono registrate in un altro blockchain di archiviazione\u2014 masterchain<\/strong> (masterchain<\/em>, master blockchain<\/em>). Grazie alla presenza negli suoi blocchi degli hash di tutti i blocchi degli shardchains, rende il sistema fortemente interconnesso. Ci\u00f2 significa anche che la generazione di un nuovo blocco nel masterchain avverr\u00e0 immediatamente dopo la generazione dei blocchi negli shardchains, con l'aspettativa che i blocchi negli shardchains compaiano quasi simultaneamente circa ogni 5 secondi, e il successivo blocco nel masterchain un secondo dopo.<\/p>\n<\/p>\n
Ma chi sar\u00e0 responsabile per l'implementazione di tutto questo lavoro titanico - per l'invio di messaggi, l'esecuzione di contratti smart, la formazione di blocchi negli shardchains e nel masterchain, e persino il controllo dei blocchi per errori? Saranno davvero i telefoni di milioni di utenti con il client di Telegram installato a farlo in silenzio? O forse il team di Durov rinuncer\u00e0 alle idee di decentralizzazione e lo faranno i loro server in modo tradizionale?<\/p>\n
<\/p>\n
In realt\u00e0, nessuna delle due risposte \u00e8 corretta. Ma gli spazi di questo articolo stanno rapidamente esaurendosi, quindi la discussione sui vari ruoli dei nodi (avrete gi\u00e0 notato alcuni riferimenti a loro) e sulle meccaniche del loro funzionamento proseguir\u00e0 nella prossima 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