{"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 di seguito, realizzare un generatore \"quasi\" buono \u00e8 piuttosto semplice, mentre crearne uno veramente buono \u00e8 difficile.<\/p>\n

Perch\u00e9 \u00e8 necessario generare numeri casuali per i partecipanti che non si fidano l'uno dell'altro? Un'area di applicazione \u00e8 quella delle applicazioni decentralizzate. Ad esempio, un'applicazione che accetta una scommessa da un partecipante e raddoppia l'importo con una probabilit\u00e0 del 49% oppure lo incassa 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 e anche solo aumentare leggermente le proprie possibilit\u00e0 di ricevere un pagamento nell'applicazione, pu\u00f2 facilmente 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 in alcun modo influenzare il risultato del generatore di numeri casuali.<\/p>\n<\/li>\n

  2. \n

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

  3. \n

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

    In questo articolo esamineremo due approcci: RANDAO + VDF e un approccio basato sui codici di cancellazione. Nella prossima sezione approfondiremo l'approccio basato sulle firme soggette a soglia.<\/p>\n

    Ma prima di tutto, esploriamo un algoritmo semplice e comunemente usato che \u00e8 robusto, imprevedibile, ma parziale.<\/p>\n

    RANDAO<\/h3>\n

    RANDAO \u00e8 un approccio molto semplice e, di conseguenza, abbastanza frequentemente utilizzato per ottenere casualit\u00e0. Tutti i partecipanti della rete scelgono inizialmente un numero pseudocasuale a livello locale, poi ogni partecipante invia l'hash del numero selezionato. Successivamente, i partecipanti rivelano a turno i numeri scelti ed effettuano un'operazione XOR sui numeri rivelati, e il risultato di questa operazione diventa l'esito del protocollo.<\/p>\n

    Il passaggio della pubblicazione degli hash prima di rivelare i numeri \u00e8 necessario affinch\u00e9 un attaccante non possa selezionare il proprio numero dopo aver visto i numeri degli altri partecipanti. Questo gli permetterebbe di determinare unilateralmente l'output del generatore di numeri casuali.<\/p>\n

    Durante il protocollo, i partecipanti devono raggiungere un accordo due volte (il cosiddetto consenso): quando iniziare a rivelare i numeri scelti e quindi interrompere la raccolta degli hash, e quando completare la raccolta dei numeri scelti e calcolare il numero casuale risultante. Prendere tali decisioni tra partecipanti che non si fidano l'uno dell'altro \u00e8 di per s\u00e9 un compito complesso, e torneremo su questo in articoli futuri; in questo articolo, presumeremo che un tale algoritmo di consenso sia a nostra disposizione.<\/p>\n

    Quali delle propriet\u00e0 che abbiamo descritto sopra ha RANDAO? \u00c8 imprevedibile, ha la stessa vitalit\u00e0 del protocollo di consenso sottostante, ma \u00e8 comunque di parte. In particolare, un attaccante pu\u00f2 osservare la rete, e dopo che gli altri partecipanti hanno rivelato i loro numeri, pu\u00f2 calcolarne l'XOR e decidere se rivelare o meno il proprio numero per influenzare il risultato. Anche se ci\u00f2 non consente all'attaccante di determinare unilateralmente l'output del generatore di numeri casuali, gli fornisce comunque 1 bit di influenza. E se gli attaccanti controllano pi\u00f9 partecipanti, il numero di bit controllati sar\u00e0 pari al numero di partecipanti sotto il loro controllo.<\/p>\n

    \"\u00c8<\/p>\n

    L'influenza degli attaccanti pu\u00f2 essere fortemente ridotta richiedendo che i partecipanti rivelino i numeri in ordine. In questo modo, l'attaccante pu\u00f2 influenzare l'uscita solo se si rivela per ultimo. Anche se l'influenza \u00e8 significativamente ridotta, l'algoritmo rimane comunque di parte.<\/p>\n

    RANDAO + VDF<\/h3>\n

    Uno dei modi per rendere RANDAO imparziale \u00e8 il seguente: dopo che tutti i numeri sono stati rivelati e l'XOR calcolato, il risultato viene fornito come input a una funzione che richiede molto tempo per essere calcolata, ma consente di verificare la correttezza del calcolo molto rapidamente.<\/p>\n

    (vdf_output, vdf_proof) = VDF_compute(input) \/\/ \u00e8 molto lento\ncorrect = VDF_verify(input, vdf_output, vdf_proof) \/\/ \u00e8 molto veloce<\/code><\/pre>\n
    Questa funzione \u00e8 chiamata Funzione di Ritardo Verificabile, o VDF. Se il calcolo del risultato finale richiede pi\u00f9 tempo rispetto alla fase di rivelazione dei numeri, un malintenzionato non sar\u00e0 in grado di prevedere l'effetto della dimostrazione o della sottrazione del proprio numero, perdendo cos\u00ec la possibilit\u00e0 di influenzare il risultato.<\/p>\n
    Sviluppare buone VDF \u00e8 estremamente complesso. Recentemente sono stati fatti alcuni progressi, ad esempio questo<\/u><\/a><\/noindex> e questo,<\/u><\/a><\/noindex> che hanno reso VDF pi\u00f9 praticabili, ed Ethereum 2.0 prevede a lungo termine di utilizzare RANDAO con VDF come fonte di numeri casuali. Oltre al fatto che questo approccio \u00e8 imprevedibile e imparziale, ha il vantaggio aggiuntivo della sostenibilit\u00e0, a condizione che siano disponibili almeno due partecipanti nella rete (supponendo 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 configurare il VDF in modo che anche un partecipante con attrezzature specializzate molto costose non possa calcolare il VDF prima della fine della fase di rivelazione. In modo ideale, l'algoritmo dovrebbe avere anche una significativa riserva di sicurezza, diciamo 10x. Nella figura sottostante \u00e8 mostrato un attacco da parte di un partecipante con un ASIC specializzato, che gli consente di eseguire VDF pi\u00f9 velocemente del tempo assegnato per la rivelazione della conferma RANDAO. Tale partecipante pu\u00f2 comunque calcolare il risultato finale utilizzando e non utilizzando il proprio numero, e in seguito, sulla base dei calcoli, decidere se mostrarlo o meno.<\/p>\n
    \"\u00c8<\/p>\n
    Per la famiglia VDF menzionata sopra, le prestazioni di un ASIC specializzato possono essere superiori di oltre 100 volte rispetto a quelle delle attrezzature normali. Pertanto, se la fase di svelamento dura 10 secondi, il VDF calcolato su un ASIC di questo tipo dovrebbe richiedere pi\u00f9 di 100 secondi per avere un margine di sicurezza di 10 volte; quindi, lo stesso VDF calcolato su attrezzature comuni dovrebbe richiedere 100 x 100 secondi = ~ 3 ore.<\/p>\n
    La Ethereum Foundation prevede di affrontare questo problema creando propri ASIC pubblici e gratuiti. Una volta fatto ci\u00f2, anche tutti gli altri protocolli potranno beneficiare 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
    Sono disponibili molti articoli, video e altre informazioni su VDF 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 tollerare fino a \u2153 degli attaccanti, rimanendo funzionante, e consente l'esistenza fino a \u2154 degli 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 anche che ogni partecipante abbia localmente una chiave privata e che le chiavi pubbliche di tutti i partecipanti siano note a tutti i partecipanti:<\/p>\n
      \n
    1. \n
      Ogni partecipante inventa localmente una lunga stringa, la suddivide in 67 parti, crea codici erasing per ottenere 100 quote, tali che qualsiasi 67 siano sufficienti per recuperare la stringa, assegna ciascuna delle 100 quote a uno dei partecipanti e le cifra utilizzando la chiave pubblica di quel partecipante. Poi 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, cifrate 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 passo (3), tutti i set concordati possono essere completamente decodificati e ripristinati grazie alle propriet\u00e0 dei codici cancellabili, e il numero finale pu\u00f2 essere ottenuto come XOR delle righe iniziali da cui i partecipanti hanno iniziato 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 non \u00e8 noto a nessuno fino a quando \u2154 dei partecipanti non decodificano le parti criptate con la loro chiave pubblica. Pertanto, il numero casuale \u00e8 definito prima che le informazioni sufficienti per il suo ripristino vengano pubblicate.<\/p>\n
      Cosa succede se, al passo (1), uno dei partecipanti invia agli altri partecipanti delle parti codificate che non sono un codice cancellabile valido di una certa riga? Senza modifiche aggiuntive, i diversi partecipanti potrebbero non essere in grado di ripristinare affatto la riga, oppure ripristinare diverse righe, portando cos\u00ec a risultati diversi tra i partecipanti. Per prevenire questo, ogni partecipante, oltre alle parti codificate, calcola anche albero Merkle<\/a><\/noindex> di tutte queste quote, e invia a ciascun partecipante sia la quota codificata che la radice dell'albero Merkle, insieme alla prova dell'inclusione della quota nell'albero Merkle. Nel consenso, nella fase (2), i partecipanti non si accordano semplicemente su insiemi multipli, ma su molte radici specifiche di questi alberi (se un partecipante si allontana dal protocollo e invia radici diverse dell'albero Merkle a partecipanti diversi, e due di queste radici vengono mostrate durante il consenso, la sua stringa non viene inclusa nell'insieme risultante). Alla fine del consenso avremo 67 stringhe codificate e le rispettive radici degli alberi Merkle tali che ci siano almeno 67 partecipanti (non necessariamente gli stessi che hanno proposto le stringhe corrispondenti) per cui per ognuna delle 67 stringhe ci sia un messaggio con una quota di codice cancellante e la prova dell'inclusione della loro quota nel corrispondente albero Merkle.<\/p>\n
      Quando nella fase (4) un partecipante decodifica 67 quote per una certa stringa e cerca di ricostruire la stringa originale, \u00e8 possibile una delle seguenti opzioni:<\/p>\n
        \n
      1. \n
        La stringa viene ripristinata, e se successivamente viene codificata di nuovo con i codici di cancellazione, e si calcola l'albero Merkle per le quote calcolate localmente, la radice coincide con quella su cui \u00e8 stato raggiunto il consenso.<\/p>\n<\/li>\n
      2. \n
        La stringa viene ripristinata, 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 ripristinata.<\/p>\n<\/li>\n<\/ol>\n
        \u00c8 facile dimostrare che se almeno per un partecipante si verifica l'opzione (1), allora per tutti i partecipanti si verificher\u00e0 l'opzione (1), e viceversa, se almeno per un partecipante si verifica l'opzione (2) o (3), allora per tutti i partecipanti si verificher\u00e0 l'opzione (2) o (3). Pertanto, per ogni stringa nel set, o tutti i partecipanti la ripristineranno con successo, oppure tutti i partecipanti non saranno in grado di ripristinarla. Il numero casuale risultante \u00e8 quindi l'XOR solo delle stringhe che i partecipanti sono riusciti a ripristinare.<\/p>\n
        Firma soglia<\/h3>\n
        Un altro approccio alla casualit\u00e0 consiste nell'utilizzo delle cosiddette firme BLS soglia. Un generatore di numeri casuali basato su firme soglia ha esattamente le stesse garanzie dell'algoritmo descritto sopra basato su codici di cancellazione, ma presenta un'asimptotica significativamente minore del numero di messaggi trasmessi attraverso la rete per ogni numero generato.<\/p>\n
        Le firme BLS sono una struttura che consente a pi\u00f9 partecipanti di creare un'unica firma comune per un messaggio. Tali firme vengono spesso utilizzate per risparmiare spazio e larghezza di banda poich\u00e9 non richiedono l'invio di pi\u00f9 firme. <\/p>\n
        Un uso comune delle firme BLS nei protocolli blockchain, oltre alla generazione di numeri casuali, \u00e8 la firma dei blocchi nei protocolli BFT. Immaginiamo che 100 partecipanti creino blocchi e che un blocco venga considerato finale se 67 di essi lo firmano. Tutti possono presentare le loro parti della firma BLS e utilizzare un certo algoritmo di consenso per concordare 67 di esse e poi combinarle in una singola firma BLS. Qualsiasi combinazione di 67 (o pi\u00f9) parti pu\u00f2 essere utilizzata per creare la firma finale, che dipender\u00e0 da quali specifiche 67 firme siano state unite, e quindi pu\u00f2 variare. Tuttavia, sebbene la scelta di 67 partecipanti diversi generi firme diverse, ogni firma sar\u00e0 corretta per il blocco. Gli altri partecipanti devono quindi solo ricevere e verificare una singola firma per ogni blocco, invece di 67, riducendo notevolmente il carico sulla rete.<\/p>\n
        Si scopre che se le chiavi private utilizzate dai partecipanti vengono generate in un certo modo, allora indipendentemente da quali 67 firme (o pi\u00f9, ma non meno di 67) vengano aggregate, la firma risultante sar\u00e0 la stessa. Questo pu\u00f2 essere utilizzato come fonte di casualit\u00e0: i partecipanti prima convengono su un certo messaggio che firmeranno (pu\u00f2 essere l'output di RANDAO o semplicemente l'hash dell'ultimo blocco, in realt\u00e0 non importa, purch\u00e9 cambi ogni volta e sia concordato), e creano una firma BLS per esso. Il risultato della generazione sar\u00e0 imprevedibile, fino a quando 67 partecipanti non forniranno le loro parti, dopo di che i dati in uscita saranno gi\u00e0 predeterminati e non possono dipendere dalle azioni di alcun partecipante.<\/p>\n
        Questo approccio alla casualit\u00e0 \u00e8 sostenibile se almeno il \u2154 dei partecipanti \u00e8 online e segue il protocollo, ed \u00e8 imparziale e imprevedibile finch\u00e9 almeno \u2153 dei partecipanti segue il protocollo. \u00c8 importante notare che un attaccante che controlla pi\u00f9 del \u2153 ma meno del \u2154 dei partecipanti pu\u00f2 fermare il protocollo, ma non pu\u00f2 prevedere o influenzare il suo output.<\/p>\n
        Le firme soglia sono di per s\u00e9 un argomento molto interessante. Nella seconda parte dell'articolo esamineremo in dettaglio come funzionano e come generare 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 sul blog NEAR<\/a><\/noindex>. NEAR \u00e8 un protocollo blockchain e una piattaforma per sviluppare applicazioni decentralizzate, con un focus sulla semplicit\u00e0 di sviluppo e sull'usabilit\u00e0 per gli utenti finali.<\/p>\n
        Il codice del protocollo \u00e8 open source, l'implementazione \u00e8 scritta in Rust e pu\u00f2 essere trovata qui<\/a><\/noindex>.<\/p>\n
        Puoi vedere come appare lo sviluppo su NEAR e sperimentare nell'IDE online qui<\/a><\/noindex>.<\/p>\n
        Puoi seguire tutte le novit\u00e0 in russo nel gruppo Telegram<\/a><\/noindex> e nel gruppo VKontakte<\/a><\/noindex>, mentre in inglese nel Twitter ufficiale<\/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}]}}