{"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 nei blockchain basati su account","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ci occupiamo da tempo del tema dell'anonimato nelle criptovalute e cerchiamo di seguire lo sviluppo delle tecnologie in questo campo. Negli articoli abbiamo gi\u00e0 analizzato in dettaglio i principi di funzionamento delle transazioni riservate<\/a><\/noindex> in Monero, e abbiamo anche effettuato un'analisi comparativa<\/a><\/noindex> delle tecnologie esistenti in questo settore. Tuttavia, tutte le criptovalute anonime ad oggi si basano su un modello di dati proposto da Bitcoin \u2014 Unspent Transaction Output (UTXO). Per i blockchain basati su account come Ethereum, le soluzioni esistenti per implementare l'anonimato e la 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 ha pubblicato un preprint<\/a><\/noindex> intitolato \u00abZether: Verso la riservatezza nel mondo dei contratti intelligenti\u00bb. Gli autori hanno proposto per la prima volta un approccio per garantire l'anonimato nei blockchain basati su account e hanno presentato due varianti di contratto intelligente: per transazioni riservate (cancellazione dei saldi e degli importi delle transazioni) e anonime (cancellazione del destinatario e del mittente). Consideriamo interessante la tecnologia proposta e vorremmo condividerne il funzionamento, oltre a discutere del motivo per cui il problema dell'anonimato nei blockchain basati su account sia considerato molto complesso e se gli autori siano riusciti a risolverlo completamente.<\/p>\n

Sullo sviluppo di questi modelli di dati<\/h3>\n

\nNel modello UTXO, una transazione \u00e8 composta da \u00abingressi\u00bb e \u00abuscite\u00bb. Un'analogia diretta alle \u00abuscite\u00bb sono le banconote nel tuo portafoglio: ogni \u00abuscita\u00bb ha un certo valore. Quando paghi qualcuno (creando una transazione), spendi una o pi\u00f9 \u00abuscite\u00bb, che diventano \u00abingressi\u00bb della transazione, e la blockchain le segna come spese. Il destinatario del tuo pagamento (o tu stesso, se hai bisogno di resto) riceve di nuovo le \u00abuscite\u00bb generate. Schema alla mano, si pu\u00f2 rappresentare cos\u00ec:<\/p>\n

\"Sull'anonimato
\n
\nI blockchain basati su account funzionano pi\u00f9 o meno come il tuo conto bancario. Operano solo sull'importo nel tuo conto e sull'importo della transazione. Quando trasferisci un certo importo dal tuo conto, non bruci alcuna \u00abuscita\u00bb, e la rete non ha bisogno di tenere a mente quali monete sono state spese e quali no. In caso pi\u00f9 semplice, la verifica della transazione si riduce al controllo della firma del mittente e dell'importo sul suo saldo:<\/p>\n

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

Analisi della tecnologia<\/h3>\n

\nIn seguito parleremo di come Zether nasconda l'importo delle transazioni, il destinatario e il mittente. Durante la descrizione dei principi di funzionamento, evidenzieremo le differenze tra la variante riservata e quella anonima. Poich\u00e9 garantire la riservatezza nelle blockchain basate su account \u00e8 molto pi\u00f9 semplice, alcune delle limitazioni imposte dall'anonimizzazione non saranno rilevanti per la versione confidenziale della tecnologia.<\/p>\n

Nascondere i saldi e gli importi delle transazioni<\/h4>\n

\nPer crittografare saldi e importi delle transazioni in Zether viene utilizzato uno schema di crittografia di ElGamal<\/a><\/noindex>. Funziona nel seguente modo. Quando Alice vuole inviare a Bob b<\/b><\/i> monete al suo indirizzo (la sua chiave pubblica) Y<\/b><\/i>, sceglie un numero casuale r<\/b><\/i> e crittografa l'importo:<\/p>\n

\"Sull'anonimato
\ndove C<\/b><\/i> \u2014 importo crittografato, D<\/b><\/i> \u2014 valore ausiliario necessario per decriptare questo importo, G<\/b><\/i> \u2014 punto fisso sulla curva ellittica, la cui moltiplicazione per la chiave segreta produce la chiave pubblica.<\/p>\n

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

In modo analogo, Alice sottrae dal suo saldo gli stessi valori, usando invece Y<\/b><\/i> la sua chiave pubblica.<\/p>\n

Nascondere il destinatario e il mittente<\/h4>\n

\nLa miscelazione delle \"uscite\" in UTXO \u00e8 emersa sin dai primi giorni delle criptovalute e aiuta a nascondere il mittente. Per questo, il mittente stesso, durante un trasferimento, seleziona a caso delle \"uscite\" nella blockchain e le mescola con le sue. Poi firma le \"uscite\" con una firma ad anello \u2014 un meccanismo crittografico che consente di convincere il verificatore che tra le \"uscite\" mescolate sono presenti 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 il proprio indirizzo unico, ed \u00e8 crittograficamente legata all'indirizzo del destinatario di queste monete. Al momento non esiste un modo per rivelare il collegamento tra l'indirizzo unico dell'\"uscita\" e l'indirizzo del destinatario, senza conoscere le sue chiavi segrete.<\/p>\n

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

Poich\u00e9 sia il mittente che il destinatario hanno sempre un indirizzo fisso, qui sorge la necessit\u00e0 di utilizzare gli stessi gruppi per il mescolamento quando si effettuano trasferimenti verso gli stessi indirizzi. \u00c8 pi\u00f9 facile considerarlo con un esempio.<\/p>\n

Supponiamo che Alice decida di fare una donazione alla fondazione benefica di Bob, ma preferisca che questo trasferimento rimanga anonimo per un osservatore esterno. Allora, per camuffarsi nel campo del mittente, inserisce anche gli account di Adam e Adele. E per nascondere Bob \u2014 nel campo del destinatario aggiunge gli account di Ben e Bill. Facendo la successiva donazione, Alice decide di accanto a s\u00e9 inserire Alex e Amanda, mentre accanto a Bob \u2014 Bruce e Benja. In questo caso, analizzando la blockchain, in queste due transazioni si trover\u00e0 solo una coppia intersecante di partecipanti \u2014 Alice e Bob, il che deanonimizza queste transazioni.<\/p>\n

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

Corsa alle transazioni<\/h4>\n

\nCome abbiamo gi\u00e0 accennato, per nascondere il proprio saldo nei sistemi basati su account, l'utente cripta il proprio saldo e l'importo della transazione. Allo stesso tempo, deve dimostrare che il saldo sul suo conto rimane non negativo. Il problema \u00e8 che, formattando la transazione, l'utente costruisce una prova rispetto al suo stato attuale del conto. E cosa succede se Bob invia una transazione ad Alice, e questa viene accettata prima di quella inviata da Alice? Allora la transazione di Alice sar\u00e0 considerata non valida, poich\u00e9 la prova del saldo \u00e8 stata costruita 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 all'esecuzione della transazione. Ma questo approccio non \u00e8 praticabile, poich\u00e9, oltre alla complessit\u00e0 di risolvere tale compito in un sistema distribuito, nel modello anonimo non sar\u00e0 chiaro quale account bloccare.<\/p>\n

Per risolvere questo problema, la tecnologia separa le transazioni in entrata e in uscita: la spesa ha un effetto immediato sul saldo, mentre gli incassi hanno un effetto differito. Per questo motivo, viene introdotto il concetto di \u00abepoca\u00bb \u2014 gruppi di blocchi di dimensioni fisse. L'\u00abepoca\u00bb attuale \u00e8 definita dalla divisione dell'altezza del blocco per 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 all'inizio di una nuova \u00abepoca\u00bb.<\/p>\n

Di conseguenza, l'utente pu\u00f2 inviare transazioni indipendentemente da quanto frequentemente riceve fondi (fino a che il suo saldo lo consente, naturalmente). La dimensione dell'epoca viene determinata in base alla velocit\u00e0 con cui i blocchi si propagano nella rete e a quanto velocemente una transazione entra in un blocco. <\/p>\n

Questa soluzione funziona bene in caso di trasferimenti riservati, ma con le transazioni anonime, come vedremo pi\u00f9 avanti, crea seri problemi.<\/p>\n

Protezione dagli attacchi di replay<\/h4>\n

\nNei blockchain basati su account, ogni transazione \u00e8 firmata con la chiave privata del mittente, il che convince il verificatore che la transazione non \u00e8 stata modificata e che \u00e8 stata creata dal possessore di tale chiave. Ma cosa succede se un malintenzionato che ha intercettato il canale di trasmissione cattura questo messaggio e lo invia esattamente per la seconda volta? Il verificatore confronter\u00e0 la firma della transazione e sar\u00e0 convinto della sua autenticit\u00e0, e la rete addebiter\u00e0 la stessa somma dal saldo del mittente di nuovo.<\/p>\n

Questa attacco \u00e8 chiamato attacco di replay. Nella UTXO-model, tali attacchi non sono rilevanti, dato che il malintenzionato cercher\u00e0 di utilizzare le uscite gi\u00e0 spese, il che di per s\u00e9 non \u00e8 valido e viene rifiutato dalla rete.<\/p>\n

Per evitare che ci\u00f2 accada, nella transazione viene incorporato un campo con dati casuali, chiamato nonce o semplicemente \u00absale\u00bb. Durante l'invio ripetuto di una transazione con il \u00absale\u00bb, il verificatore controlla se questo nonce \u00e8 stato utilizzato in precedenza e, se no, considera valida questa transazione. Per non memorizzare nella blockchain l'intera storia dei nonce degli utenti, di solito nella prima transazione viene accettato uguale a zero, e poi aumenta di uno. Alla rete rimane solo da verificare che il nonce della nuova transazione sia diverso da quello precedente di uno.<\/p>\n

Nello schema di trasferimenti anonimi sorge il problema della validazione dei nonce per le transazioni. Non possiamo legare il nonce in modo esplicito all'indirizzo del mittente, poich\u00e9 questo, ovviamente, de-anonimizzerebbe il trasferimento. Non possiamo neanche incrementare di uno i nonce di tutti gli account coinvolti, poich\u00e9 questo potrebbe confliggere con altri trasferimenti in fase di elaborazione. <\/p>\n

Gli autori di Zether propongono di generare il nonce in modo crittografico \u2014 in base all'\"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 essere risolto: non riveliamo il nonce del mittente e non interferiamo con i nonce dei partecipanti non coinvolti. Ma questo approccio impone una seria limitazione: un account pu\u00f2 inviare non pi\u00f9 di una transazione per \"epoca\". Purtroppo, questo problema rimane irrisolto e al momento rende l versione anonima di Zether, a nostro avviso, poco praticabile.<\/p>\n

La difficolt\u00e0 delle prove a zero conoscenza<\/h4>\n

\nIn UTXO, il mittente deve dimostrare alla rete che non sta spendendo un importo negativo, altrimenti diventa possibile generare nuove monete dal nulla (perch\u00e9 questo \u00e8 possibile, ne abbiamo parlato in uno dei precedenti articoli<\/a><\/noindex>). E deve anche firmare gli \"input\" con una firma ad anello, per dimostrare che tra le monete mischiate ci sono fondi che gli appartengono.<\/p>\n

Nella versione anonima del blockchain basato su account, le espressioni per la prova diventano di gran lunga pi\u00f9 complesse. Il mittente deve dimostrare che:<\/p>\n

    \n
  1. L'importo inviato \u00e8 positivo;<\/li>\n
  2. Il saldo rimane non negativo;<\/li>\n
  3. Il mittente ha crittografato correttamente gli importi dei trasferimenti (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 e questa \u00e8 effettivamente presente nell'elenco dei mittenti (tra quelli coinvolti);<\/li>\n
  6. Il nonce utilizzato nella transazione \u00e8 composto correttamente.<\/li>\n<\/ol>\n

    \nPer questa prova complessa, gli autori utilizzano una combinazione Bulletproof<\/a><\/noindex> (uno degli autori, tra l'altro, ha partecipato alla sua creazione) e Sigma protocol<\/a><\/noindex>, chiamata Sigma-bullets. La prova formale di tale affermazione \u00e8 un compito piuttosto complesso e limita notevolmente il numero di persone disposte a occuparsi dell'implementazione della tecnologia.<\/p>\n

    Qual \u00e8 il risultato finale?<\/h4>\n

    \nSecondo noi, la parte di Zether che introduce la riservatezza nei blockchain basati su account pu\u00f2 gi\u00e0 essere utilizzata. Tuttavia, al momento, la versione anonima della tecnologia presenta seri limiti al suo utilizzo, e la sua complessit\u00e0 complica la realizzazione. Non dobbiamo dimenticare che gli autori l'hanno rilasciata solo pochi mesi fa, e potrebbe essere che qualcun altro trovi una soluzione ai problemi attuali. \u00c8 proprio cos\u00ec che si fa 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'anonimit\u00e0 nei blockchain basati su account | ProHoster","description":"Siamo da tempo interessati al tema dell'anonimit\u00e0 nelle criptovalute e ci impegniamo a seguire lo sviluppo delle tecnologie in questo campo.","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.","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","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\/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}]}}