{"id":31729,"date":"2019-10-31T21:42:44","date_gmt":"2019-10-31T18:42:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/sluchajnye-chisla-i-detsentralizovannye-seti-prakticheskoe-primenenie\/"},"modified":"2019-10-31T21:42:44","modified_gmt":"2019-10-31T18:42:44","slug":"sluchajnye-chisla-i-detsentralizovannye-seti-prakticheskoe-primenenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-prakticheskoe-primenenie","title":{"rendered":"Numeri casuali e reti decentralizzate: applicazione pratica","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<h2 id=\"vvedenie\">Introduzione<\/h2>\n<p><\/p>\n<p><em>\u00abLa generazione di numeri casuali \u00e8 troppo importante per lasciarla al caso\u00bb<\/em><br \/>\n<em>Robert Cavyu, 1970<\/em><\/p>\n<p><\/p>\n<p>Questo articolo \u00e8 dedicato all'applicazione pratica delle soluzioni che utilizzano la generazione collettiva di numeri casuali in ambienti non fidati. In breve, come e perch\u00e9 viene utilizzato il random nei blockchain, e un po' su come distinguere un \u201cbuon\u201d random da un \u201ccattivo\u201d. Generare un numero veramente casuale \u00e8 un problema estremamente complesso anche su un singolo computer, ed \u00e8 da tempo studiato dai crittografi. Nelle reti decentralizzate, la generazione di numeri casuali \u00e8 ancora pi\u00f9 complicata e importante.<\/p>\n<p><\/p>\n<p>Proprio nelle reti in cui i partecipanti non si fidano l'uno dell'altro, la possibilit\u00e0 di generare un numero casuale innegabile consente di affrontare in modo efficace molte delle questioni pi\u00f9 importanti e migliorare significativamente gli schemi gi\u00e0 esistenti. Inoltre, il gioco d'azzardo e le lotterie non sono affatto l'obiettivo principale, come potrebbe sembrare a un lettore inesperto.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2 id=\"generaciya-sluchaynyh-chisel\">Generazione di numeri casuali<\/h2>\n<p><\/p>\n<p>I computer non possono generare numeri casuali da soli: hanno bisogno di un aiuto esterno. Un computer pu\u00f2 ottenere un certo valore casuale utilizzando, ad esempio, i movimenti del mouse, la quantit\u00e0 di memoria utilizzata, i tassi parasitari sui contatti del processore e molte altre fonti, denominate fonti di entropia. Questi valori non sono del tutto casuali, poich\u00e9 si trovano in un intervallo specifico o presentano un carattere di cambiamento prevedibile. Per trasformare questi numeri in numeri realmente casuali in un determinato intervallo, si applicano criptotrasformazioni, per ottenere valori pseudo-casuali uniformemente distribuiti da valori di entropia non uniformemente distribuiti. I valori ottenuti vengono chiamati pseudo-casuali, poich\u00e9 non sono veramente casuali, ma sono stati deterministicamente generati dall'entropia. Qualsiasi buon algoritmo crittografico, crittografando i dati, produce testi cifrati che statisticamente non dovrebbero essere distinguibili da una sequenza casuale, quindi per generare casualit\u00e0 si pu\u00f2 utilizzare una fonte di entropia che garantisca solo una buona ripetibilit\u00e0 e imprevedibilit\u00e0 dei valori anche in intervalli ridotti, mentre il resto del lavoro di diffusione e mescolamento dei bit nel valore risultante sar\u00e0 svolto dall'algoritmo di crittografia.<\/p>\n<p><\/p>\n<p>Per concludere questo breve chiarimento, aggiungo che la generazione di numeri casuali, anche su un solo dispositivo, \u00e8 uno dei pilastri della sicurezza dei nostri dati. I numeri pseudo-casuali generati vengono utilizzati per stabilire connessioni protette in diverse reti, per generare chiavi crittografiche, per bilanciare il carico, per il controllo dell'integrit\u00e0 e per molte altre applicazioni. La sicurezza di molti protocolli dipende dalla possibilit\u00e0 di generare un casuale affidabile e imprevedibile da fonti esterne, conservarlo e non rivelarlo fino al passo successivo del protocollo, altrimenti la sicurezza sar\u00e0 compromessa. Un attacco al generatore di valori pseudo-casuali \u00e8 estremamente pericoloso e mette a rischio tutto il software che utilizza la generazione di casualit\u00e0. <\/p>\n<p><\/p>\n<p>Tutto ci\u00f2 dovreste saperlo se avete seguito un corso base di crittografia, pertanto continuiamo a parlare di reti decentralizzate.<\/p>\n<p><\/p>\n<h2 id=\"random-v-blokcheynah\">Random nei blockchain<\/h2>\n<p><\/p>\n<p>In primo luogo parler\u00f2 dei blockchain con supporto per smart contract, poich\u00e9 sono in grado di sfruttare appieno le potenzialit\u00e0 offerte da un random di alta qualit\u00e0 e innegabile. In seguito, per brevit\u00e0, chiamer\u00f2 questa tecnologia \u201c<em>Publicly Verifiable Random Beacons<\/em>\u201d o PVRB. Poich\u00e9 i blockchain sono reti le cui informazioni possono essere verificate da qualsiasi partecipante, una parte chiave del nome \u00e8 \u201cPublicly Verifiable\u201d, cio\u00e8 chiunque pu\u00f2, attraverso calcoli, ottenere la prova che il numero ricevuto, registrato nel blockchain, possiede queste caratteristiche:<\/p>\n<p><\/p>\n<ul>\n<li>Il risultato deve avere una distribuzione dimostrabilmente uniforme, cio\u00e8 basata su crittografia dimostrabilmente sicura. <\/li>\n<li>Non \u00e8 possibile controllare alcun bit del risultato. Di conseguenza, il risultato non pu\u00f2 essere previsto in anticipo.<\/li>\n<li>Non \u00e8 possibile sabotare il protocollo di generazione mediante l'astensione dal protocollo o sovraccaricando la rete con messaggi malevoli.<\/li>\n<li>Tutto quanto sopra deve essere resistente a cospirazioni di un numero consentito di partecipanti disonesti al protocollo (ad esempio 1\/3 dei partecipanti).<\/li>\n<\/ul>\n<p><\/p>\n<p>Qualsiasi possibilit\u00e0 che un gruppo minore di partecipanti collusi possa generare anche un random controllato pari\/dispari rappresenta una falla nella sicurezza. Qualsiasi possibilit\u00e0 per il gruppo di fermare l'erogazione del random \u00e8 una falla nella sicurezza. In generale, ci sono molti problemi e questa non \u00e8 una questione semplice...<\/p>\n<p><\/p>\n<p>Sembra che l'applicazione pi\u00f9 importante per i PVRB sia nei vari giochi, lotterie e, in generale, in qualsiasi forma di gioco su blockchain. In effetti, questa \u00e8 una direzione importante, ma il random nei blockchain ha applicazioni pi\u00f9 significative. Esaminiamole.<\/p>\n<p><\/p>\n<h2 id=\"algoritmy-konsensusa\">Algoritmi di consenso<\/h2>\n<p><\/p>\n<p>Il PVRB ha un'importanza enorme per l'organizzazione del consenso di rete. Le transazioni nelle blockchain sono protette da una firma elettronica, quindi un'\"attacco alla transazione\" consiste sempre nell'inclusione\/esclusione di una transazione in un blocco (o in pi\u00f9 blocchi). Il compito principale dell'algoritmo di consenso \u00e8 convenire sull'ordine di queste transazioni e sull'ordine dei blocchi che le includono. Inoltre, una propriet\u00e0 necessaria per le reali blockchain \u00e8 la finalit\u00e0: la possibilit\u00e0 che la rete concordi che la catena fino al blocco finalizzato sia definitiva e non verr\u00e0 mai esclusa a causa della comparsa di un nuovo fork. Di solito, per convenire che un blocco sia valido e, cosa pi\u00f9 importante, finale, \u00e8 necessario raccogliere le firme dalla maggior parte dei produttori di blocchi (BP - block producers), il che richiede almeno di inviare la catena di blocchi a tutti i BP e di distribuire le firme tra tutti i BP. Con l'aumento del numero di BP, il numero di messaggi necessari nella rete cresce esponenzialmente; pertanto, gli algoritmi di consenso che richiedono la finalit\u00e0, come quelli utilizzati nel consenso pBFT di Hyperledger, non funzionano con la velocit\u00e0 necessaria, gi\u00e0 a partire da alcune decine di BP, richiedendo un enorme numero di connessioni. <\/p>\n<p><\/p>\n<p>Se nella rete esiste un PVRB indiscutibile e onesto, \u00e8 possibile, anche nella sua forma pi\u00f9 semplice, selezionare uno dei block producers come \"leader\" per un round del protocollo. Se abbiamo <code>N<\/code> block producer, da cui <code>M: M &gt; 1\/2 N<\/code> sono onesti, non censurano le transazioni e non costruiscono fork della catena per attuare un attacco di \"double spend\", l'uso di un PVRB indiscutibile uniformemente distribuito permetter\u00e0 di scegliere un leader onesto con una probabilit\u00e0 di <code>M \/ N (M \/ N &gt; 1\/2)<\/code>. Se a ciascun leader viene assegnato un proprio intervallo di tempo durante il quale pu\u00f2 creare un blocco e validare la catena, e questi intervalli sono uguali tra loro, allora la catena di blocchi dei BP onesti sar\u00e0 pi\u00f9 lunga della catena formata dai BP malevoli, e l'algoritmo di consenso basato sulla lunghezza della catena scarter\u00e0 semplicemente quella \u201ccattiva\u201d. Questo principio di assegnare intervalli di tempo uguali a ciascun BP \u00e8 stato applicato per la prima volta in Graphene (il predecessore di EOS) e consente a molti blocchi di essere chiusi con una sola firma, riducendo significativamente il carico di rete e permettendo a questo consenso di operare in modo estremamente veloce e stabile. Tuttavia, le reti EOS devono attualmente utilizzare blocchi speciali (Last Irreversible Block), che vengono confermati da firme di 2\/3 dei BP. Questi blocchi servono a garantire la finalit\u00e0 (l'impossibilit\u00e0 di un fork della catena che inizi prima dell'ultimo Last Irreversible Block).<\/p>\n<p><\/p>\n<p>Inoltre, nelle implementazioni reali, lo schema del protocollo \u00e8 pi\u00f9 complesso: le votazioni sui blocchi proposti avvengono su pi\u00f9 fasi, per mantenere attiva la rete in caso di blocchi saltati e problemi di rete, ma anche considerando questo, gli algoritmi di consenso che utilizzano PVRB richiedono sostanzialmente meno messaggi tra i BP, rendendoli pi\u00f9 veloci rispetto al tradizionale P\u0412FT o a varie sue modifiche.<\/p>\n<p><\/p>\n<p>Il pi\u00f9 rappresentativo di tali algoritmi \u00e8: <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2016\/889.pdf\">Ouroboros<\/a><\/noindex> del team di Cardano, che, come dichiarato, possiede una resistenza matematicamente dimostrabile a situazioni di collusione tra i BP. <\/p>\n<p><\/p>\n<p>In Ouroboros, il PVRB viene utilizzato per definire il cosiddetto \u201cBP schedule\u201d \u2014 un programma secondo cui a ciascun BP viene assegnato il proprio slot temporale per la pubblicazione del blocco. Un grande vantaggio dell'uso del PVRB \u00e8 la completa \u201cuguaglianza\u201d dei BP (in base alle dimensioni dei loro saldi). L'onest\u00e0 del PVRB garantisce che i BP malevoli non possano controllare il programma degli slot temporali e, quindi, non possano manipolare la catena, preparando e analizzando in anticipo i fork della catena, e per scegliere un fork basta affidarsi semplicemente alla lunghezza della catena, senza dover fare calcoli complessi sulla \u201cutilit\u00e0\u201d dei BP e sul \u201cpeso\u201d dei loro blocchi. <\/p>\n<p><\/p>\n<p>In tutti i casi in cui \u00e8 necessario scegliere un partecipante casuale in una rete decentralizzata, quasi sempre la scelta migliore sar\u00e0 PVRB, piuttosto che un'opzione deterministica basata, ad esempio, sull'hash di un blocco. Senza PVRB, la possibilit\u00e0 di influenzare la scelta del partecipante porta all'insorgere di attacchi in cui l'attaccante pu\u00f2, scegliendo tra diverse opzioni future, selezionare il partecipante corrotto successivo o addirittura pi\u00f9 di uno, per garantire una porzione maggiore nel processo decisionale. L'utilizzo del PVRB discredita questi tipi di attacchi.<\/p>\n<p><\/p>\n<h2 id=\"masshtabirovanie-i-balansirovka-nagruzki\">Scalabilit\u00e0 e bilanciamento del carico<\/h2>\n<p><\/p>\n<p>Il PVRB pu\u00f2 portare seri vantaggi anche per ridurre il carico e scalare i pagamenti. Innanzitutto, \u00e8 utile prendere confidenza con <noindex><a rel=\"nofollow\" href=\"https:\/\/people.csail.mit.edu\/rivest\/pubs\/Riv97b.pdf\">l'articolo<\/a><\/noindex> Rivista \u201cBiglietti della Lotteria Elettronica come Micropagamenti\u201d. L'idea principale \u00e8 che, invece di effettuare 100 pagamenti da 1 centesimo dal pagante al destinatario, si pu\u00f2 partecipare a una lotteria equa con un premio di 1$ = 100 centesimi, dove il pagante, a ogni pagamento da 1 centesimo, trasferisce alla banca uno dei 100 \u201cbiglietti della lotteria\u201d. Uno di questi biglietti vincer\u00e0 alla banca 1$, e proprio questo biglietto potr\u00e0 essere registrato nel blockchain dal destinatario. La cosa pi\u00f9 importante \u00e8 che gli altri 99 biglietti vengono trasferiti tra il destinatario e il pagante senza alcun intervento esterno, su un canale privato e a qualsiasi velocit\u00e0 necessaria. Una buona descrizione del protocollo basato su questo schema nella rete Emercoin pu\u00f2 essere letta <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@emer.tech\/randpay-6a028f16c82a\">qui<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Questa soluzione presenta alcuni problemi, ad esempio il destinatario potrebbe smettere di servire il pagante subito dopo aver ricevuto il biglietto vincente, ma per molte applicazioni specifiche, come la tariffazione al minuto o gli abbonamenti elettronici ai servizi, questi possono essere trascurati. La principale esigenza, ovviamente, \u00e8 l'onest\u00e0 della lotteria condotta, e per la sua attuazione \u00e8 assolutamente necessario il PVRB.<\/p>\n<p><\/p>\n<p>La selezione casuale di un partecipante \u00e8 estremamente importante anche per i protocolli di sharding, il cui obiettivo \u00e8 la scalabilit\u00e0 orizzontale della catena di blocchi, consentendo ai diversi BP di elaborare solo il proprio ambito di transazioni. Questa \u00e8 un compito molto complesso, soprattutto in termini di sicurezza durante la fusione dei shard. Una corretta selezione casuale del BP per nominare i suoi responsabili per uno specifico shard, come nelle algoritmi di consenso, \u00e8 anch'essa una sfida del PVRB. Nei sistemi centralizzati, gli shard sono assegnati da un bilanciatore, che calcola semplicemente un hash della richiesta e lo invia all'esecutore necessario. Nelle blockchain, la possibilit\u00e0 di influenzare questa assegnazione pu\u00f2 portare a un attacco sul consenso. Ad esempio, il contenuto delle transazioni pu\u00f2 essere controllato da un attaccante, che pu\u00f2 gestire quali transazioni finiscono nel proprio shard controllato e manipolare la catena di blocchi al suo interno. Si pu\u00f2 leggere la discussione sulla questione dell'uso dei numeri casuali per compiti di sharding in Ethereum. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ethereum\/wiki\/wiki\/Sharding-FAQ#how-is-the-randomness-for-random-sampling-generated\">qui<\/a><\/noindex><br \/>\nLo sharding \u00e8 uno dei compiti pi\u00f9 ambiziosi e seri nel campo del blockchain; la sua risoluzione permetter\u00e0 di costruire reti decentralizzate di straordinaria prestazione e volume. Il PVRB \u00e8 solo uno dei blocchi importanti per risolverlo.<\/p>\n<p><\/p>\n<h2 id=\"igry-ekonomicheskie-protokoly-arbitrazh\">Giochi, protocolli economici, arbitraggio<\/h2>\n<p><\/p>\n<p>Il ruolo dei numeri casuali nell'industria dei giochi \u00e8 difficile da sovrastimare. L'uso esplicito nei casin\u00f2 online e l'uso implicito nel calcolo degli effetti delle azioni del giocatore rappresentano tutte questioni estremamente complesse per le reti decentralizzate, dove non \u00e8 possibile fare affidamento su una fonte centrale di casualit\u00e0. Tuttavia, la selezione casuale pu\u00f2 anche risolvere molti problemi economici e contribuire alla costruzione di protocolli pi\u00f9 semplici ed efficienti. Supponiamo che nel nostro protocollo ci siano controversie riguardo al pagamento di servizi a basso costo, e queste controversie si verificano piuttosto raramente. In questo caso, se c'\u00e8 un PVRB indiscutibile, clienti e venditori possono accordarsi per una risoluzione casuale delle controversie, ma con una probabilit\u00e0 prestabilita. Ad esempio, con una probabilit\u00e0 del 60% vince il cliente, mentre con una probabilit\u00e0 del 40% vince il venditore. Questo approccio, che potrebbe sembrare assurdo a prima vista, consente di risolvere automaticamente le controversie con una percentuale di vincite\/perdite esattamente prevedibile, soddisfacente per entrambe le parti senza il coinvolgimento di una terza parte e senza spreco di tempo. Inoltre, il rapporto delle probabilit\u00e0 pu\u00f2 essere dinamico e dipendere da alcune variabili globali. Ad esempio, se l'azienda sta andando bene, si riscontra un basso numero di controversie e un'elevata redditivit\u00e0, l'azienda pu\u00f2 automaticamente spostare la probabilit\u00e0 di risoluzione della controversia verso una maggiore orientamento al cliente, ad esempio 70\/30 o 80\/20, e viceversa, se le controversie comportano grandi spese e sono fraudolente o inadeguate, si pu\u00f2 spostare la probabilit\u00e0 in direzione opposta.<\/p>\n<p><\/p>\n<p>Un gran numero di protocolli decentralizzati interessanti, come i registri curati dai token, i mercati predittivi, le curve di legame e molti altri, rappresentano giochi economici in cui viene premiato il buon comportamento e penalizzato il cattivo. Spesso emergono problemi di sicurezza, le cui soluzioni possono risultare in conflitto tra loro. Ci\u00f2 che \u00e8 protetto da un attacco di \"whale\" con miliardi di token (\"big stake\"), \u00e8 vulnerabile ad attacchi da migliaia di account con piccoli saldi (\"sybil stake\"), e le misure contro un tipo di attacco, come le commissioni non lineari create per rendere svantaggioso il lavoro di un grande stake, vengono solitamente discreditate da un altro attacco. Poich\u00e9 si tratta di un gioco economico, i pesi statistici appropriati possono essere calcolati in anticipo e le commissioni possono essere semplicemente sostituite con commissioni randomizzate secondo una distribuzione appropriata. Tali commissioni probabilistiche sono realizzate in modo estremamente semplice, se nel blockchain esiste una fonte affidabile di casualit\u00e0 e non richiedono calcoli complessi, complicando la vita sia ai whale sia agli attaccanti sybil.<br \/>\n\u00c8 necessario continuare a ricordare che il controllo su un singolo bit in questa casualit\u00e0 consente di ingannare, raddoppiando e dimezzando le probabilit\u00e0, quindi un PVRB onesto \u00e8 una componente fondamentale di tali protocolli. <\/p>\n<p><\/p>\n<h2 id=\"gde-nayti-pravilnyy-random\">Dove trovare la casualit\u00e0 giusta?<\/h2>\n<p><\/p>\n<p>In teoria, una selezione casuale onesta nelle reti decentralizzate consente di garantire la sicurezza dimostrabile di quasi qualsiasi protocollo contro la collusione. La logica \u00e8 piuttosto semplice: se la rete concorda su un singolo bit 0 o 1, e tra i partecipanti meno della met\u00e0 sono disonesti, allora, con un numero sufficiente di iterazioni, la rete garantir\u00e0 di arrivare a un consenso su questo bit con una probabilit\u00e0 fissa. Questo perch\u00e9 un randome onesto selezioner\u00e0 51 su 100 partecipanti nel 51% dei casi. Ma questo \u00e8 solo in teoria, poich\u00e9 nelle reti reali, per garantire un livello di sicurezza come in articoli, \u00e8 necessario scambiare molti messaggi tra gli host, criptografia complessa e multilivello, e qualsiasi complicazione del protocollo introduce immediatamente nuovi vettori di attacco.<br \/>\n\u00c8 proprio per questo che non vediamo ancora in blockchain un PVRB dimostrabilmente resistente, che sia stato utilizzato a lungo abbastanza da superare le prove delle applicazioni reali, molteplici audit, carichi e, naturalmente, veri attacchi, senza i quali \u00e8 difficile definire un prodotto realmente sicuro.<\/p>\n<p><\/p>\n<p>Tuttavia, ci sono diversi approcci promettenti, che si differenziano per molti dettagli, e uno di essi sicuramente risolver\u00e0 il problema. Con le attuali risorse di calcolo, la teoria crittografica pu\u00f2 essere trasformata in applicazioni pratiche abbastanza agilmente. In futuro, saremo lieti di parlare delle implementazioni di PVRB: ce ne sono attualmente diverse, ognuna con il proprio insieme di propriet\u00e0 e caratteristiche importanti, e dietro ognuna c'\u00e8 una buona idea. Non ci sono molte squadre che si occupano di randomizzazione, e l'esperienza di ciascuna di esse \u00e8 estremamente importante per tutte le altre. Speriamo che le nostre informazioni possano aiutare le altre squadre a muoversi pi\u00f9 rapidamente, tenendo conto delle esperienze dei predecessori.<\/p>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/448330\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u00ab\u0413\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u044f \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b \u0441\u043b\u0438\u0448\u043a\u043e\u043c \u0432\u0430\u0436\u043d\u0430, \u0447\u0442\u043e\u0431\u044b \u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0442\u044c \u0435\u0451 \u043d\u0430 \u0432\u043e\u043b\u044e \u0441\u043b\u0443\u0447\u0430\u044f\u00bb \u0420\u043e\u0431\u0435\u0440\u0442 \u041a\u0430\u0432\u044c\u044e, 1970 \u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u043c\u0443 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044e \u0440\u0435\u0448\u0435\u043d\u0438\u0439, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0449\u0438\u0445 \u043a\u043e\u043b\u043b\u0435\u043a\u0442\u0438\u0432\u043d\u0443\u044e \u0433\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u044e \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b \u0432 \u043d\u0435\u0434\u043e\u0432\u0435\u0440\u0435\u043d\u043d\u043e\u0439 \u0441\u0440\u0435\u0434\u0435. \u0415\u0441\u043b\u0438 \u043a\u0440\u0430\u0442\u043a\u043e \u2014 \u043a\u0430\u043a \u0438 \u0434\u043b\u044f \u0447\u0435\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u0440\u0430\u043d\u0434\u043e\u043c \u0432 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0430\u0445, \u0438 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043f\u0440\u043e \u0442\u043e, \u043a\u0430\u043a \u043e\u0442\u043b\u0438\u0447\u0438\u0442\u044c \u201c\u0445\u043e\u0440\u043e\u0448\u0438\u0439\u201d \u0440\u0430\u043d\u0434\u043e\u043c \u043e\u0442 \u201c\u043f\u043b\u043e\u0445\u043e\u0433\u043e\u201d. \u0413\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u044f \u0434\u0435\u0439\u0441\u0442\u0432\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u043e\u0433\u043e \u0447\u0438\u0441\u043b\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31729","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u00ab\u0413\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u044f \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b \u0441\u043b\u0438\u0448\u043a\u043e\u043c \u0432\u0430\u0436\u043d\u0430, \u0447\u0442\u043e\u0431\u044b \u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0442\u044c \u0435\u0451 \u043d\u0430 \u0432\u043e\u043b\u044e \u0441\u043b\u0443\u0447\u0430\u044f\u00bb \u0420\u043e\u0431\u0435\u0440\u0442 \u041a\u0430\u0432\u044c\u044e, 1970 \u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u043c\u0443 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044e.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-prakticheskoe-primenenie\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0421\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0438 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0441\u0435\u0442\u0438: \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0435 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u00ab\u0413\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u044f \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b \u0441\u043b\u0438\u0448\u043a\u043e\u043c \u0432\u0430\u0436\u043d\u0430, \u0447\u0442\u043e\u0431\u044b \u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0442\u044c \u0435\u0451 \u043d\u0430 \u0432\u043e\u043b\u044e \u0441\u043b\u0443\u0447\u0430\u044f\u00bb \u0420\u043e\u0431\u0435\u0440\u0442 \u041a\u0430\u0432\u044c\u044e, 1970 \u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u043c\u0443 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044e.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-prakticheskoe-primenenie\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:42:44+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:42:44+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Numeri casuali e reti decentralizzate: applicazione pratica | ProHoster","description":"Introduzione \u00abLa generazione di numeri casuali \u00e8 troppo importante per essere lasciata al caso\u00bb Robert Cavu, 1970 Questa articolo \u00e8 dedicato all'applicazione pratica.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-prakticheskoe-primenenie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0438 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0441\u0435\u0442\u0438: \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0435 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u0435 | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u00ab\u0413\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u044f \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b \u0441\u043b\u0438\u0448\u043a\u043e\u043c \u0432\u0430\u0436\u043d\u0430, \u0447\u0442\u043e\u0431\u044b \u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0442\u044c \u0435\u0451 \u043d\u0430 \u0432\u043e\u043b\u044e \u0441\u043b\u0443\u0447\u0430\u044f\u00bb \u0420\u043e\u0431\u0435\u0440\u0442 \u041a\u0430\u0432\u044c\u044e, 1970 \u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u043c\u0443 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044e.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-prakticheskoe-primenenie","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:42:44+00:00","article:modified_time":"2019-10-31T18:42:44+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31729","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 07:32:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:04:45","updated":"2026-01-21 07:32:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/31729","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=31729"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/31729\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=31729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=31729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=31729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}