{"id":34101,"date":"2019-10-31T21:56:25","date_gmt":"2019-10-31T18:56:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ob-anonimnosti-v-account-based-blokchejnah\/"},"modified":"2019-10-31T21:56:25","modified_gmt":"2019-10-31T18:56:25","slug":"ob-anonimnosti-v-account-based-blokchejnah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","title":{"rendered":"Sull'anonimato nelle blockchain basate su account","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ci siamo interessati da tempo al tema dell'anonimato nelle criptovalute e cerchiamo di seguire lo sviluppo delle tecnologie in questo campo. Nei nostri articoli abbiamo gi\u00e0 approfondito i principi di funzionamento delle transazioni riservate<\/a><\/noindex> in Monero, e abbiamo anche condotto un'analisi comparativa<\/a><\/noindex> delle tecnologie esistenti in questo settore. Tuttavia, tutte le criptovalute anonime fino ad oggi si basano su un modello di dati proposto da Bitcoin \u2014 Unspent Transaction Output (UTXO). Per le blockchain basate su account come Ethereum, le soluzioni esistenti per implementare anonimato e riservatezza (ad esempio, Mobius<\/a><\/noindex> o Aztec<\/a><\/noindex>) hanno cercato di replicare il modello UTXO nei contratti intelligenti.<\/p>\n

Nel febbraio 2019, un gruppo di ricercatori dell'Universit\u00e0 di Stanford e di Visa Research<\/a><\/noindex> hanno rilasciato preprint<\/a><\/noindex> \u00abZether: Verso la privacy nel mondo dei contratti intelligenti\u00bb. Gli autori hanno proposto per la prima volta un approccio per garantire l'anonimato nelle blockchain basate su account e presentato due varianti di smart contract: per transazioni confidenziali (concealment of balances and amounts) e anonime (concealment of sender and recipient). Riteniamo che la tecnologia proposta sia interessante e vorremmo condividerne il funzionamento, oltre a discutere perch\u00e9 la questione dell'anonimato nelle blockchain basate su account \u00e8 considerata molto complessa e se gli autori siano riusciti a risolverla completamente.<\/p>\n

Sul funzionamento di questi modelli di dati<\/h3>\n

\nNella modello UTXO, la transazione \u00e8 composta da \u00abinput\u00bb e \u00aboutput\u00bb. Un diretto analogo agli \u00aboutput\u00bb sono le banconote nel tuo portafoglio: ogni \u00aboutput\u00bb ha un certo valore nominale. Quando paghi qualcuno (formi una transazione), spendi uno o pi\u00f9 \u00aboutput\u00bb, che diventano \u00abinput\u00bb della transazione e la blockchain li segna come spesi. Nel frattempo, il destinatario del tuo pagamento (o tu stesso, se hai bisogno di resto) riceve nuovamente \u00aboutput\u00bb generati. Schmaticamente, questo pu\u00f2 essere rappresentato cos\u00ec:<\/p>\n

\"Sull'anonimato
\n
\nI blocchi basati su account funzionano in modo simile al tuo conto bancario. Operano solo sulla somma presente nel tuo conto e sulla somma del trasferimento. Quando trasferisci una somma dal tuo conto, non bruci nessun \"output\"; la rete non deve ricordare quali monete siano state spese e quali no. Nel caso pi\u00f9 semplice, il controllo della transazione si riduce a verificare la firma del mittente e l'importo disponibile sul suo saldo:<\/p>\n

\"Sull'anonimato
\n<\/p>\n

Approfondimento della tecnologia<\/h3>\n

\nOra parleremo di come Zether nasconda l'importo delle transazioni, il destinatario e il mittente. Durante la descrizione dei principi del suo funzionamento, annoteremo le differenze tra le versioni confidenziale e anonima. Poich\u00e9 garantire la riservatezza nei blocchi basati su account \u00e8 molto pi\u00f9 semplice, alcune delle limitazioni imposte dall'anonimizzazione saranno irrilevanti per la versione confidenziale della tecnologia.<\/p>\n

Nascondere i saldi e gli importi dei trasferimenti<\/h4>\n

\nPer la criptazione dei saldi e degli importi dei trasferimenti in Zether si utilizza uno schema di criptazione di El-Gamal<\/a><\/noindex>. Funziona nel seguente modo: quando Alice vuole inviare a Bob b<\/b><\/i> monete all'indirizzo (al suo chiave pubblica) Y<\/b><\/i>, sceglie un numero casuale r<\/b><\/i> e cripta l'importo:<\/p>\n

\"Sull'anonimato
\ndove C<\/b><\/i> \u2014 importo criptato, D<\/b><\/i> \u2014 un valore ausiliario necessario per decifrare questa somma, G<\/b><\/i> \u2014 un punto fisso su una curva ellittica, nel quale moltiplicando la chiave segreta si ottiene la chiave pubblica.<\/p>\n

Quando Bob riceve questi valori, li somma semplicemente al suo saldo crittografato allo stesso modo, il che rende questo schema conveniente.<\/p>\n

Analogamente, Alice sottrae dal suo saldo gli stessi valori, solo che utilizza la sua Y<\/b><\/i> chiave pubblica.<\/p>\n

Nascondere destinatario e mittente<\/h4>\n

\nIl mescolamento delle \"uscite\" nell'UTXO \u00e8 nato all'inizio delle criptovalute ed \u00e8 utile per nascondere il mittente. Per questo, il mittente durante il trasferimento seleziona casualmente \"uscite\" nella blockchain e le mescola con le proprie. Successivamente, firma le \"uscite\" con una firma ad anello - un meccanismo crittografico che permette di convincere il verificatore che tra le \"uscite\" mescolate siano presenti le monete del mittente. Le monete mescolate, ovviamente, non vengono spese.<\/p>\n

Tuttavia, per nascondere il destinatario, non possiamo generare uscite false. Pertanto, in UTXO ogni \"uscita\" ha un suo indirizzo unico, che \u00e8 crittograficamente collegato all'indirizzo del destinatario di queste monete. Attualmente non esiste un modo per rivelare la connessione tra l'indirizzo unico dell'uscita e l'indirizzo del destinatario senza conoscere le sue chiavi segrete.<\/p>\n

Nella modello basato su account non possiamo utilizzare indirizzi monouso (altrimenti si tratterebbe gi\u00e0 di un modello di \"uscite\"). Pertanto, destinatario e mittente devono essere mescolati tra altri account nella blockchain. In questo modo, dagli account mescolati viene detratti 0 monete crittografate (o viene aggiunto 0 \u2014 nel caso del mescolamento del destinatario), senza modificare effettivamente il loro saldo reale.<\/p>\n

Poich\u00e9 sia il mittente che il destinatario hanno sempre un indirizzo costante, qui sorge la necessit\u00e0, nei trasferimenti verso gli stessi indirizzi, di utilizzare gli stessi gruppi per mescolare. \u00c8 pi\u00f9 facile considerare questo con un esempio.<\/p>\n

Immagina che Alice decida di fare una donazione al fondo di Bob, ma preferisca che questa transazione rimanga anonima per un osservatore esterno. Allora, per mascherare la sua identit\u00e0 nel campo del mittente, inserisce anche gli account di Adam e Adele. E per nascondere Bob, nel campo del destinatario aggiunge gli account di Ben e Bill. Per la successiva donazione, Alice decide di inserire accanto a s\u00e9 Alex e Amanda, e accanto a Bob Bruce e Benjamen. In questo caso, analizzando la blockchain, in queste due transazioni ci sar\u00e0 solo una coppia di partecipanti in comune: Alice e Bob, il che de-anonimizza queste transazioni.<\/p>\n

\"Sull'anonimato
\n<\/p>\n

Corse delle transazioni<\/h4>\n

\nCome gi\u00e0 accennato, per nascondere il proprio saldo nei sistemi basati su account, l'utente crittografa il proprio saldo e l'importo della transazione. Deve per\u00f2 dimostrare che il saldo sul proprio conto rimane non negativo. Il problema \u00e8 che nel formare una transazione, l'utente costruisce una prova relativa al suo stato attuale del conto. E se Bob inviasse una transazione a Alice, e questa venisse accettata prima di quella inviata da Alice? In tal caso, la transazione di Alice sarebbe considerata non valida, poich\u00e9 la prova del saldo \u00e8 stata elaborata prima dell'accettazione della transazione di Bob.<\/p>\n

\"Sull'anonimato
\n
\nLa prima soluzione che viene in mente in una situazione del genere \u00e8 congelare l'account fino al completamento della transazione. Ma questo approccio non \u00e8 praticabile, perch\u00e9 oltre alla complessit\u00e0 di risolvere un problema del genere in un sistema distribuito, in uno schema anonimo non \u00e8 chiaro quale account bloccare.<\/p>\n

Per affrontare questo problema, la tecnologia separa le transazioni in entrata e in uscita: la spesa ha un effetto immediato sul saldo, mentre le entrate sono differite. Viene introdotto il concetto di \u00abepoca\u00bb \u2014 gruppi di blocchi di dimensioni fisse. L\u2019attuale \u00abepoca\u00bb \u00e8 determinata dal rapporto tra l\u2019altezza del blocco e la dimensione del gruppo. Elaborando una transazione, la rete aggiorna immediatamente il saldo del mittente, mentre i fondi del destinatario vengono accumulati. I fondi accumulati diventano disponibili per il destinatario del pagamento solo quando si verifica una nuova \u00abepoca\u00bb.<\/p>\n

Di conseguenza, l'utente pu\u00f2 inviare transazioni indipendentemente dalla frequenza con cui riceve fondi (ovviamente nel limite del proprio saldo). La dimensione dell'epoca \u00e8 determinata dalla velocit\u00e0 con cui i blocchi si propagano nella rete e quanto velocemente una transazione entra in un blocco. <\/p>\n

Questa soluzione funziona bene per le transazioni riservate, ma con le transazioni anonime, come vedremo pi\u00f9 avanti, genera seri problemi.<\/p>\n

Protezione contro gli attacchi di replay<\/h4>\n

\nNei blocchi basati su account, ogni transazione \u00e8 firmata con la chiave privata del mittente, il che garantisce al validatore che la transazione non sia stata modificata e che sia stata creata dal proprietario di quella chiave. Ma cosa succede se un malintenzionato, che sta ascoltando il canale di trasmissione, intercetta questo messaggio e invia un secondo messaggio identico? Il validatore confronter\u00e0 la firma della transazione e sar\u00e0 convinto della sua autenticit\u00e0, e la rete detrarr\u00e0 nuovamente la stessa somma dal saldo del mittente.<\/p>\n

Questa attacco viene chiamato attacco di replay. Nel modello UTXO, tali attacchi non sono rilevanti, poich\u00e9 il malintenzionato cercherebbe di utilizzare uscite gi\u00e0 spese, il che non \u00e8 valido e viene rifiutato dalla rete.<\/p>\n

Per evitare che ci\u00f2 accada, nella transazione viene inserito un campo con dati casuali, chiamato nonce o semplicemente \"sale\". Quando viene reinviata la transazione con il \"sale\", il soggetto che verifica controlla se questo nonce \u00e8 stato utilizzato in precedenza e, se non lo \u00e8, considera la transazione valida. Per non memorizzare nella blockchain tutta la storia dei nonce degli utenti, di solito nella prima transazione viene accettato come uguale a zero, e poi viene incrementato di uno. Resta solo da controllare che il nonce della nuova transazione differisca da quello precedente di uno.<\/p>\n

Nello schema di trasferimento anonimo emerge il problema della validazione dei nonce delle transazioni. Non possiamo associare i nonce in modo esplicito all'indirizzo del mittente, poich\u00e9 ci\u00f2 svelerebbe chiaramente l'identit\u00e0 del trasferimento. Non possiamo nemmeno aumentare di uno i nonce di tutti gli account coinvolti, poich\u00e9 ci\u00f2 potrebbe entrare in conflitto con altre transazioni in fase di elaborazione. <\/p>\n

Gli autori di Zether propongono di generare i nonce in modo crittografico, a seconda dell'\"epoca\". Ad esempio:<\/p>\n

\"Sull'anonimato
\nQui x<\/i><\/b> \u2014 la chiave segreta del mittente, e Gepoch<\/i><\/b> \u2014 un generatore aggiuntivo per l'epoca, ottenuto attraverso l'hashing di una stringa del tipo 'Zether + '. Ora il problema sembra risolto: non riveliamo il nonce del mittente e non interferiamo con i nonce dei partecipanti non coinvolti. Tuttavia, questo approccio impone una seria restrizione: un account pu\u00f2 inviare non pi\u00f9 di una transazione per \"epoca\". Sfortunatamente, questo problema rimane irrisolto e al momento rende la versione anonima di Zether, a nostro avviso, poco praticabile.<\/p>\n

Difficolt\u00e0 delle prove a zero conoscenze<\/h4>\n

\nNel sistema UTXO, il mittente deve dimostrare alla rete che non sta spendendo un importo negativo, altrimenti \u00e8 possibile generare nuove monete dal nulla (perch\u00e9 ci\u00f2 sia possibile, ne abbiamo parlato in uno dei precedenti articoli<\/a><\/noindex>). Deve inoltre firmare gli 'ingressi' con una firma ad anello, per dimostrare che tra le monete miscelate ci sono fondi che gli appartengono.<\/p>\n

Nella versione anonima della blockchain basata su account, le espressioni per la prova diventano molto pi\u00f9 complesse. Il mittente dimostra che:<\/p>\n

    \n
  1. L'importo inviato \u00e8 positivo;<\/li>\n
  2. Il saldo rimane non negativo;<\/li>\n
  3. Il mittente ha correttamente criptato gli importi delle transazioni (compresi quelli nulli);<\/li>\n
  4. Il saldo cambia solo per il mittente e il destinatario;<\/li>\n
  5. Il mittente possiede la chiave segreta del proprio account ed \u00e8 effettivamente presente nell'elenco dei mittenti (tra i coinvolti);<\/li>\n
  6. Il nonce utilizzato nella transazione \u00e8 stato composto correttamente.<\/li>\n<\/ol>\n

    \nPer una prova cos\u00ec complessa, gli autori utilizzano una miscela Sicuro<\/a><\/noindex> (uno degli autori, per inciso, ha partecipato alla sua creazione) e il protocollo Sigma<\/a><\/noindex>, chiamato Sigma-bullets. La prova formale di tale affermazione \u00e8 un compito piuttosto complesso e limita notevolmente il numero di persone intenzionate a implementare la tecnologia.<\/p>\n

    Quali sono i risultati finali?<\/h4>\n

    \nA nostro avviso, la parte Zether che introduce la riservatezza nei blockchain basati su account pu\u00f2 essere utilizzata gi\u00e0 adesso. Tuttavia, l'attuale versione anonima della tecnologia impone gravi limitazioni al suo utilizzo, e la sua complessit\u00e0 complica l'implementazione. Tuttavia, non si deve sottovalutare che gli autori l'hanno rilasciata solo pochi mesi fa e, forse, qualcun altro trover\u00e0 una soluzione ai problemi esistenti oggi. Infatti, \u00e8 cos\u00ec che si sviluppa la scienza.
    \n
    Fonte:     habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u041c\u044b \u0443\u0436\u0435 \u0434\u0430\u0432\u043d\u043e \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u0443\u0435\u043c\u0441\u044f \u0442\u0435\u043c\u043e\u0439 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u043e\u0441\u0442\u0438 \u0432 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442\u0430\u0445 \u0438 \u0441\u0442\u0430\u0440\u0430\u0435\u043c\u0441\u044f \u0441\u043b\u0435\u0434\u0438\u0442\u044c \u0437\u0430 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0435\u043c \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 \u044d\u0442\u043e\u0439 \u043e\u0431\u043b\u0430\u0441\u0442\u0438. \u0412 \u0441\u0432\u043e\u0438\u0445 \u0441\u0442\u0430\u0442\u044c\u044f\u0445 \u043c\u044b \u0443\u0436\u0435 \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u043e \u0440\u0430\u0437\u0431\u0438\u0440\u0430\u043b\u0438 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0440\u0430\u0431\u043e\u0442\u044b \u043a\u043e\u043d\u0444\u0438\u0434\u0435\u043d\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u0445 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0439 \u0432 Monero, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u043b\u0438 \u0441\u0440\u0430\u0432\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043e\u0431\u0437\u043e\u0440 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439, \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u043d\u0430 \u044d\u0442\u043e\u043c \u043f\u043e\u043b\u0435. \u041e\u0434\u043d\u0430\u043a\u043e \u0436\u0435 \u0432\u0441\u0435 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u044b\u0435 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442\u044b \u043d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u043f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u044b \u043d\u0430 \u043c\u043e\u0434\u0435\u043b\u0438 \u0434\u0430\u043d\u043d\u044b\u0445, \u043f\u0440\u0435\u0434\u043b\u043e\u0436\u0435\u043d\u043d\u043e\u0439 Bitcoin \u2014 […]<\/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-34101","post","type-post","status-publish","format-standard","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\udd47Sull'anonimato nei blockchain basati su account | ProHoster","description":"Da tempo ci interessa il tema dell'anonimato nelle criptovalute e cerchiamo di seguire l'evoluzione delle tecnologie in questo campo. Nei nostri articoli abbiamo gi\u00e0 esaminato in dettaglio i principi delle transazioni riservate in Monero e abbiamo condotto una panoramica comparativa delle tecnologie esistenti in questo settore. Tuttavia, tutte le criptovalute anonime attualmente sono basate sul modello di dati proposto da Bitcoin \u2014","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","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\u041e\u0431 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u043e\u0441\u0442\u0438 \u0432 account-based \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0430\u0445 | ProHoster","og:description":"\u041c\u044b \u0443\u0436\u0435 \u0434\u0430\u0432\u043d\u043e \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u0443\u0435\u043c\u0441\u044f \u0442\u0435\u043c\u043e\u0439 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u043e\u0441\u0442\u0438 \u0432 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442\u0430\u0445 \u0438 \u0441\u0442\u0430\u0440\u0430\u0435\u043c\u0441\u044f \u0441\u043b\u0435\u0434\u0438\u0442\u044c \u0437\u0430 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0435\u043c \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 \u044d\u0442\u043e\u0439 \u043e\u0431\u043b\u0430\u0441\u0442\u0438. \u0412 \u0441\u0432\u043e\u0438\u0445 \u0441\u0442\u0430\u0442\u044c\u044f\u0445 \u043c\u044b \u0443\u0436\u0435 \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u043e \u0440\u0430\u0437\u0431\u0438\u0440\u0430\u043b\u0438 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0440\u0430\u0431\u043e\u0442\u044b \u043a\u043e\u043d\u0444\u0438\u0434\u0435\u043d\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u0445 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0439 \u0432 Monero, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u043b\u0438 \u0441\u0440\u0430\u0432\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043e\u0431\u0437\u043e\u0440 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439, \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u043d\u0430 \u044d\u0442\u043e\u043c \u043f\u043e\u043b\u0435. \u041e\u0434\u043d\u0430\u043a\u043e \u0436\u0435 \u0432\u0441\u0435 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u044b\u0435 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442\u044b \u043d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u043f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u044b \u043d\u0430 \u043c\u043e\u0434\u0435\u043b\u0438 \u0434\u0430\u043d\u043d\u044b\u0445, \u043f\u0440\u0435\u0434\u043b\u043e\u0436\u0435\u043d\u043d\u043e\u0439 Bitcoin \u2014","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","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:56:25+00:00","article:modified_time":"2019-10-31T18:56:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34101","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 17:56:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:28:34","updated":"2026-01-21 17:56:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/34101","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=34101"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/34101\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=34101"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=34101"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=34101"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}