{"id":95468,"date":"2020-09-29T19:42:29","date_gmt":"2020-09-29T17:42:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1"},"modified":"2020-09-29T19:42:29","modified_gmt":"2020-09-29T17:42:29","slug":"mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","title":{"rendered":"\u00c8 possibile generare numeri casuali se non ci fidiamo l'uno dell'altro? Parte 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, Habr!<\/p>\n

In questo articolo parler\u00f2 della generazione di numeri pseudo-casuali tra partecipanti che non si fidano l'uno dell'altro. Come vedremo pi\u00f9 avanti, implementare un generatore \u201cquasi\u201d buono \u00e8 abbastanza semplice, mentre realizzarne uno molto buono \u00e8 complicato.<\/p>\n

Perch\u00e9 \u00e8 necessario generare numeri casuali per i partecipanti che non si fidano l'uno dell'altro? Un campo di applicazione \u00e8 costituito dalle applicazioni decentralizzate. Ad esempio, un'applicazione che accetta una scommessa da un partecipante e raddoppia la somma con una probabilit\u00e0 del 49%, oppure la ritira con una probabilit\u00e0 del 51%, funzioner\u00e0 solo se pu\u00f2 ottenere in modo imparziale un numero casuale. Se un malintenzionato pu\u00f2 influenzare il risultato del generatore di numeri casuali, anche solo aumentando leggermente la propria possibilit\u00e0 di ricevere un pagamento nell'applicazione, riuscir\u00e0 facilmente a svuotarla.<\/p>\n

Quando sviluppiamo un protocollo distribuito per la generazione di numeri casuali, vogliamo che abbia tre propriet\u00e0:<\/p>\n

    \n
  1. \n

    Deve essere imparziale. In altre parole, nessun partecipante deve influenzare in alcun modo il risultato del generatore di numeri casuali.<\/p>\n<\/li>\n

  2. \n

    Deve essere imprevedibile. In altre parole, nessun partecipante deve essere in grado di prevedere quale numero verr\u00e0 generato (o di dedurre alcune delle sue propriet\u00e0) prima che venga generato.<\/p>\n<\/li>\n

  3. \n

    Il protocollo deve essere sostenibile, cio\u00e8 resistente al fatto che una certa percentuale di partecipanti si disconnetta dalla rete o tenti deliberatamente di fermare il protocollo.<\/p>\n<\/li>\n<\/ol>\n

    In questo articolo esamineremo due approcci: RANDAO + VDF e un approccio basato su codici di cancellazione. Nella parte successiva analizzeremo in dettaglio l'approccio basato su firme soggettive.<\/p>\n

    Ma prima di tutto, analizziamo un algoritmo semplice e spesso utilizzato, che \u00e8 sostenibile, imprevedibile, ma parziale.<\/p>\n

    RANDAO<\/h3>\n

    RANDAO \u00e8 un approccio molto semplice e quindi piuttosto comunemente utilizzato per ottenere casualit\u00e0. Tutti i partecipanti alla rete iniziano scegliendo localmente un numero pseudocasuale, quindi ciascun partecipante invia l'hash del numero scelto. Successivamente, i partecipanti rivelano a turno i propri numeri scelti e eseguono un'operazione XOR sui numeri rivelati, e il risultato di questa operazione diventa il risultato del protocollo.<\/p>\n

    Il passo di pubblicare gli hash prima di rivelare i numeri \u00e8 essenziale, affinch\u00e9 un malintenzionato non possa scegliere il proprio numero dopo aver visto i numeri degli altri partecipanti. Questo gli consentirebbe di determinare effettivamente da solo l'output del generatore di numeri casuali.<\/p>\n

    Durante il protocollo, i partecipanti devono raggiungere due volte un accordo comune (il cosiddetto consenso): quando iniziare a rivelare i numeri scelti e quindi smettere di accettare gli hash, e quando terminare di accettare i numeri scelti e calcolare il risultato finale. Raggiungere tali decisioni tra partecipanti che non si fidano l'uno dell'altro \u00e8 gi\u00e0 di per s\u00e9 un compito difficile, e torneremo su questo in articoli futuri; in questo articolo daremo per scontato che tale algoritmo di consenso ci sia accessibile.<\/p>\n

    Quali delle propriet\u00e0 che abbiamo descritto sopra ha RANDAO? \u00c8 imprevedibile, ha la stessa capacit\u00e0 di sopravvivenza del protocollo di consenso sottostante, ma \u00e8 sbilanciato. In particolare, un malintenzionato pu\u00f2 osservare la rete, e dopo che gli altri partecipanti rivelano i loro numeri, pu\u00f2 calcolare il loro XOR e decidere se rivelare o meno il proprio numero per influenzare il risultato. Anche se questo non consente al malintenzionato di determinare da solo l'output del generatore di numeri casuali, gli fornisce comunque 1 bit di influenza. E se i malintenzionati controllano pi\u00f9 partecipanti, il numero di bit che controllano sar\u00e0 uguale al numero di partecipanti sotto il loro controllo.<\/p>\n

    \"\u00c8<\/p>\n

    L'influenza dei malintenzionati pu\u00f2 essere significativamente ridotta se si richiede che i partecipanti rivelino i numeri in ordine. In tal caso, il malintenzionato potr\u00e0 influenzare l'esito solo se si rivela per ultimo. Anche se l'influenza \u00e8 significativamente ridotta, l'algoritmo rimane comunque sbilanciato.<\/p>\n

    RANDAO + VDF<\/h3>\n

    Una delle opzioni per rendere RANDAO imparziale \u00e8 la seguente: dopo che tutti i numeri sono stati rivelati e l'XOR calcolato, il suo risultato viene passato come input a una funzione che richiede molto tempo per essere calcolata, ma consente di verificare la correttezza del calcolo in modo molto rapido.<\/p>\n

    (vdf_output, vdf_proof) = VDF_compute(input) \/\/ questo \u00e8 molto lento\ncorrect = VDF_verify(input, vdf_output, vdf_proof) \/\/ questo \u00e8 molto veloce<\/code><\/pre>\n
    Questa funzione si chiama Verifiable Delay Function, o VDF. Se il calcolo del risultato finale richiede pi\u00f9 tempo rispetto alla fase di rivelazione dei numeri, allora un malintenzionato non sar\u00e0 in grado di prevedere l'effetto della sua dimostrazione o della sua reticenza nel rivelare il numero, e quindi perder\u00e0 la possibilit\u00e0 di influenzare il risultato.<\/p>\n
    Sviluppare buoni VDF \u00e8 estremamente complesso. Recentemente sono stati fatti alcuni progressi, ad esempio questo<\/u><\/a><\/noindex> e questo,<\/u><\/a><\/noindex> che ha reso i VDF pi\u00f9 applicabili nella pratica, e Ethereum 2.0 prevede di utilizzare RANDAO con VDF come fonte di numeri casuali a lungo termine. Oltre al fatto che questo approccio \u00e8 imprevedibile e imparziale, ha il vantaggio aggiuntivo di essere sostenibile, se almeno due partecipanti sono disponibili in rete (a condizione che il protocollo di consenso utilizzato sia sostenibile con un numero cos\u00ec ridotto di partecipanti).<\/p>\n
    La maggiore difficolt\u00e0 di questo approccio \u00e8 impostare i VDF in modo tale che anche un partecipante con attrezzature specializzate molto costose non possa calcolare i VDF prima della fase di rivelazione. Idealmente, l'algoritmo dovrebbe avere anche un margine di sicurezza significativo, diciamo 10x. Nella figura sottostante \u00e8 mostrato un attacco di un partecipante che dispone di un ASIC specializzato, il quale gli consente di eseguire il VDF pi\u00f9 rapidamente del tempo assegnato per la rivelazione della conferma RANDAO. Tale partecipante potrebbe comunque calcolare il risultato finale utilizzando o meno il proprio numero, e poi, in base ai calcoli, decidere se mostrarlo o meno.<\/p>\n
    \"\u00c8<\/p>\n
    Per la famiglia di VDF sopra menzionata, le prestazioni di un ASIC specializzato possono essere superiori a 100 volte rispetto a quelle di un'attrezzatura normale. Pertanto, se la fase di rivelazione dura 10 secondi, il VDF calcolato su un tale ASIC dovrebbe richiedere pi\u00f9 di 100 secondi per avere un margine di sicurezza di 10 volte, e cos\u00ec lo stesso VDF, calcolato su attrezzature normali, dovrebbe richiedere 100 x 100 secondi = ~ 3 ore.<\/p>\n
    La Ethereum Foundation intende affrontare questo problema creando i propri ASIC pubblici e gratuiti. Una volta che ci\u00f2 avverr\u00e0, tutti gli altri protocolli potranno anch'essi avvantaggiarsi di questa tecnologia, ma fino ad allora l'approccio RANDAO + VDF non sar\u00e0 altrettanto praticabile per i protocolli che non possono investire nello sviluppo dei propri ASIC.<\/p>\n
    Molti articoli, video e altre informazioni su VDF sono stati raccolti su questo sito<\/u><\/a><\/noindex>.<\/p>\n
    Utilizziamo codici di cancellazione<\/h3>\n
    In questa sezione esamineremo il protocollo di generazione di numeri casuali che utilizza codici di cancellazione<\/a><\/noindex>. Pu\u00f2 sopportare fino a \u2153 di attaccanti rimanendo praticabile e consente l'esistenza fino a \u2154 di attaccanti prima che possano prevedere o influenzare il risultato.<\/p>\n
    L'idea principale del protocollo \u00e8 la seguente. Per semplificare, supponiamo che ci siano esattamente 100 partecipanti. Supponiamo inoltre che tutti i partecipanti abbiano localmente una certa chiave privata e che le chiavi pubbliche di tutti i partecipanti siano conosciute da tutti i partecipanti:<\/p>\n
      \n
    1. \n
      Ogni partecipante genera localmente una stringa lunga, la suddivide in 67 parti, crea codici di cancellazione per ottenere 100 quote, tali che qualsiasi 67 siano sufficienti per ricostruire la stringa, assegna ciascuna delle 100 quote a uno dei partecipanti e le crittografa con la chiave pubblica dello stesso partecipante. Dopodich\u00e9, tutte le quote codificate vengono pubblicate.<\/p>\n<\/li>\n
    2. \n
      I partecipanti utilizzano un certo consenso per raggiungere un accordo sui set codificati di 67 partecipanti specifici.<\/p>\n<\/li>\n
    3. \n
      Una volta raggiunto il consenso, ogni partecipante prende le quote codificate in ciascuno dei 67 set, crittografate con la loro chiave pubblica, decifra tutte queste quote e pubblica tutte queste quote decifrate.<\/p>\n<\/li>\n
    4. \n
      Una volta che 67 partecipanti hanno completato il passaggio (3), tutti i set concordati possono essere completamente decodificati e ripristinati grazie alle propriet\u00e0 dei codici di cancellazione, e il numero finale pu\u00f2 essere ottenuto come XOR delle stringhe iniziali da cui i partecipanti sono partiti nel (1).<\/p>\n<\/li>\n<\/ol>\n
      \"\u00c8<\/p>\n
      Si pu\u00f2 dimostrare che questo protocollo \u00e8 imparziale e imprevedibile. Il numero casuale risultante \u00e8 definito dopo aver raggiunto il consenso, ma nessuno lo conosce fino a quando \u2154 dei partecipanti non decodificano le parti criptate con la loro chiave pubblica. In questo modo, il numero casuale \u00e8 determinato prima che le informazioni necessarie per il suo recupero siano pubblicate.<\/p>\n
      Cosa succede se nel passaggio (1) uno dei partecipanti invia ad altri partecipanti delle parti codificate che non sono un codice di cancellazione corretto per una certa stringa? Senza ulteriori modifiche, i diversi partecipanti non saranno in grado di recuperare la stringa affatto, oppure recupereranno stringhe diverse, il che far\u00e0 s\u00ec che partecipanti diversi ricevano un numero casuale diverso. Per prevenire ci\u00f2, si pu\u00f2 fare quanto segue: ogni partecipante, oltre alle parti codificate, calcola anche l'albero di Merkle<\/a><\/noindex> di tutte queste parti, e invia a ogni partecipante sia la parte codificata stessa, sia la radice dell'albero di Merkle e la prova dell'inclusione della parte nell'albero di Merkle. Nel consenso al passaggio (2), quindi, i partecipanti non si accordano solo su un insieme di set, ma su un insieme di radici specifiche di tali alberi (se un certo partecipante si discosta dal protocollo e invia radici diverse dell'albero di Merkle a partecipanti diversi, e due di tali radici vengono presentate durante il consenso, la sua stringa non viene inclusa nell'insieme risultante). Alla fine del consenso, avremo 67 stringhe codificate e le corrispondenti radici dell'albero di Merkle tali che ci siano almeno 67 partecipanti (non necessariamente gli stessi che hanno proposto le stringhe corrispondenti), per le quali per ciascuna delle 67 stringhe c'\u00e8 un messaggio con una parte del codice di cancellazione e una prova dell'inclusione della loro parte nell'albero di Merkle corrispondente.<\/p>\n
      Quando al passaggio (4) un partecipante decodifica 67 parti per una certa stringa e cerca di recuperare la stringa originale, una delle seguenti opzioni \u00e8 possibile:<\/p>\n
        \n
      1. \n
        La stringa viene recuperata e se viene poi codificata di nuovo con i codici di cancellazione e si calcola l'albero di Merkle per le parti calcolate localmente, la radice coincide con quella su cui \u00e8 stato raggiunto il consenso.<\/p>\n<\/li>\n
      2. \n
        La stringa viene recuperata, ma la radice calcolata localmente non corrisponde a quella su cui \u00e8 stato raggiunto il consenso.<\/p>\n<\/li>\n
      3. \n
        La stringa non viene recuperata.<\/p>\n<\/li>\n<\/ol>\n
        \u00c8 facile dimostrare che se almeno per un partecipante si verifica il caso (1), allora per tutti i partecipanti si verificher\u00e0 il caso (1), e viceversa, se almeno per un partecipante si verifica il caso (2) o (3), allora per tutti i partecipanti si verificher\u00e0 il caso (2) o (3). Pertanto, per ogni riga nel set, o tutti i partecipanti la ripristineranno con successo, oppure tutti i partecipanti non saranno in grado di ripristinarla. Il numero casuale risultante sar\u00e0 quindi l'XOR solo delle righe che i partecipanti sono riusciti a ripristinare.<\/p>\n
        Firme di soglia<\/h3>\n
        Un altro approccio alla casualit\u00e0 consiste nell'utilizzare le cosiddette firme di soglia BLS. Un generatore di numeri casuali basato su firme di soglia ha esattamente le stesse garanzie dell'algoritmo basato su codici di cancellazione descritto sopra, ma ha un'assintotica significativamente minore nel numero di messaggi trasmessi in rete per ogni numero generato.<\/p>\n
        Le firme BLS sono una costruzione che consente a pi\u00f9 partecipanti di creare una singola firma comune per un messaggio. Queste firme sono spesso utilizzate per risparmiare spazio e larghezza di banda in quanto non richiedono l'invio di pi\u00f9 firme. <\/p>\n
        Un'applicazione comune delle firme BLS nei protocolli blockchain, oltre alla generazione di numeri casuali, \u00e8 la firma di blocchi nei protocolli BFT. Supponiamo che 100 partecipanti creino blocchi e un blocco venga considerato definitivo se 67 di essi lo firmano. Tutti possono presentare le proprie parti della firma BLS e utilizzare un certo algoritmo di consenso per concordare 67 di esse, per poi unirle in una singola firma BLS. Qualsiasi 67 (o pi\u00f9) parti possono essere utilizzate per creare la firma finale, che dipender\u00e0 da quali 67 firme sono state unite, e quindi potrebbe variare, ma nonostante ci\u00f2, una selezione diversa di 67 partecipanti creer\u00e0 una firma diversa, qualsiasi di queste firme sar\u00e0 comunque una firma valida per il blocco. Gli altri partecipanti dovranno quindi ricevere tramite rete e verificare solo una firma per ogni blocco, invece di 67, il che riduce notevolmente il carico sulla rete.<\/p>\n
        Si scopre che se le chiavi private utilizzate dai partecipanti sono generate in un certo modo, allora, indipendentemente dalle 67 firme (o pi\u00f9, ma mai meno) aggregate, la firma risultante sar\u00e0 la stessa. Questo pu\u00f2 essere utilizzato come sorgente di casualit\u00e0: i partecipanti prima concordano su un messaggio da firmare (questo pu\u00f2 essere l'output di RANDAO o semplicemente l'hash dell'ultimo blocco, in realt\u00e0 non importa, purch\u00e9 cambi ogni volta ed sia concordato), e creano una firma BLS per esso. Il risultato della generazione sar\u00e0 imprevedibile fino a quando 67 partecipanti non forniscono le loro parti, e dopo di ci\u00f2, i dati in uscita sono gi\u00e0 predeterminati e non possono dipendere dalle azioni di alcun partecipante.<\/p>\n
        Questo approccio alla casualit\u00e0 \u00e8 fattibile se almeno \u2154 dei partecipanti sono online e seguono il protocollo, ed \u00e8 imparziale e imprevedibile finch\u00e9 almeno \u2153 dei partecipanti seguono il protocollo. \u00c8 importante notare che un malintenzionato che controlla pi\u00f9 di \u2153 ma meno di \u2154 dei partecipanti pu\u00f2 fermare il protocollo, ma non pu\u00f2 prevedere o influenzare la sua uscita.<\/p>\n
        Le firme soglia sono di per s\u00e9 un tema molto interessante. Nella seconda parte dell'articolo esamineremo dettagliatamente come funzionano e come devono essere generate le chiavi dei partecipanti affinch\u00e9 le firme soglia possano essere utilizzate come generatore di numeri casuali.<\/p>\n
        In conclusione<\/h3>\n
        Questo articolo \u00e8 il primo di una serie di articoli tecnici nel blog NEAR<\/a><\/noindex>. NEAR \u00e8 un protocollo blockchain e una piattaforma per lo sviluppo di applicazioni decentralizzate con un'enfasi sulla facilit\u00e0 di sviluppo e sulla facilit\u00e0 d'uso per gli utenti finali.<\/p>\n
        Il codice del protocollo \u00e8 aperto, la nostra implementazione \u00e8 scritta in Rust, ed \u00e8 possibile trovarla qui<\/a><\/noindex>.<\/p>\n
        Puoi vedere come appare lo sviluppo su NEAR e sperimentare nell'online IDE qui<\/a><\/noindex>.<\/p>\n
        Puoi seguire tutte le novit\u00e0 in russo nel gruppo su Telegram<\/a><\/noindex> e in gruppo su VKontakte<\/a><\/noindex>, e in inglese nel ufficiale Twitter<\/a><\/noindex>.<\/p>\n
        A presto!<\/p>\n
        Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
        \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043f\u0440\u043e \u0433\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u044e \u043f\u0441\u0435\u0432\u0434\u043e-\u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u044e\u0442 \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443. \u041a\u0430\u043a \u043c\u044b \u0443\u0432\u0438\u0434\u0438\u043c \u043d\u0438\u0436\u0435, \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u0442\u044c \u201c\u043f\u043e\u0447\u0442\u0438\u201d \u0445\u043e\u0440\u043e\u0448\u0438\u0439 \u0433\u0435\u043d\u0435\u0440\u0430\u0442\u043e\u0440 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043f\u0440\u043e\u0441\u0442\u043e, \u0430 \u0432\u043e\u0442 \u043e\u0447\u0435\u043d\u044c \u0445\u043e\u0440\u043e\u0448\u0438\u0439 \u2013 \u0441\u043b\u043e\u0436\u043d\u043e. \u0417\u0430\u0447\u0435\u043c \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0443\u0436\u043d\u043e \u0433\u0435\u043d\u0435\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c, \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u044e\u0449\u0438\u043c \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443? \u041e\u0434\u043d\u0430 \u0438\u0437 \u043e\u0431\u043b\u0430\u0441\u0442\u0435\u0439 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044f — \u044d\u0442\u043e \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435, \u043a\u043e\u0442\u043e\u0440\u043e\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":95469,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-95468","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u00c8 possibile generare numeri casuali se non ci fidiamo l'uno dell'altro? Parte 1 | ProHoster","description":"Ciao, Habr! In questo articolo parler\u00f2 della generazione di numeri pseudo-casuali tra partecipanti che non si fidano l'uno dell'altro.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","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\u041c\u043e\u0436\u043d\u043e \u043b\u0438 \u0433\u0435\u043d\u0435\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430, \u0435\u0441\u043b\u0438 \u043c\u044b \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u0435\u043c \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443? \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440!\u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043f\u0440\u043e \u0433\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u044e \u043f\u0441\u0435\u0432\u0434\u043e-\u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u044e\u0442 \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","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":"2020-09-29T17:42:29+00:00","article:modified_time":"2020-09-29T17:42:29+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"95468","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:05:29","updated":"2022-09-28 01:55:15","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\/95468","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=95468"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/95468\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/95469"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=95468"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=95468"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=95468"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}