{"id":53183,"date":"2019-11-25T00:00:00","date_gmt":"2019-11-24T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/ot-blokchejna-k-dag-izbavlyaemsya-ot-posrednikov"},"modified":"2026-02-15T19:54:48","modified_gmt":"2026-02-15T17:54:48","slug":"ot-blokchejna-k-dag-izbavlyaemsya-ot-posrednikov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ot-blokchejna-k-dag-izbavlyaemsya-ot-posrednikov","title":{"rendered":"Dal blockchain al DAG: liberarsi dagli intermediari","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

In questo articolo parler\u00f2 del DAG (Directed Acyclic Graph, grafico aciclico diretto) e del suo utilizzo nei registri distribuiti, e lo confronteremo con la blockchain.<\/p>\n

\"Dal
\n
\nIl DAG non \u00e8 una novit\u00e0 nel mondo delle criptovalute. Potreste averne sentito parlare come soluzione ai problemi di scalabilit\u00e0 delle blockchain. Ma oggi non parleremo di scalabilit\u00e0, ma di ci\u00f2 che rende le criptovalute diverse da tutto il resto: decentralizzazione, assenza di intermediari e resilienza alla censura.
\n<\/a><\/noindex>
\n\"Dal
\n
\nMostrer\u00f2 anche che il DAG \u00e8 in effetti pi\u00f9 resistente alla censura e non ha intermediari per accedere al registro.<\/p>\n

\"Dal
\n
\nNelle blockchain a noi familiari, gli utenti non hanno accesso diretto al registro stesso. Quando desiderate aggiungere una transazione al registro, dovete 'chiedere' di farlo al produttore di blocchi (block producer, noto anche come 'miner'). Sono infatti i miner a decidere quale transazione aggiungere al prossimo blocco e quale no. Solo i miner hanno accesso esclusivo ai blocchi e il diritto di decidere di quale transazione accettare l'aggiunta al registro.<\/p>\n

I miner sono gli intermediari che si frappongono tra voi e il registro distribuito.<\/p>\n

\"Dal
\n
\nIn pratica, solitamente un numero limitato di pool di miner controlla collettivamente oltre la met\u00e0 della potenza computazionale della rete. Per Bitcoin si tratta di quattro pool, per Ethereum di due. In caso di collusione, possono bloccare qualsiasi transazione desiderino.<\/p>\n

\"Dal
\n
\nNegli ultimi anni sono state proposte numerose variazioni di blockchain, che si differenziano nei principi di selezione dei produttori di blocchi. Tuttavia, i produttori di blocchi non sono scomparsi, restano sempre 'in attesa': ogni transazione deve passare attraverso il produttore di blocchi, e se egli non la accetta, la transazione, di fatto, non esiste.<\/p>\n

\"Dal
\n
\nQuesto \u00e8 un problema inevitabile per la blockchain. E se vogliamo risolverlo, dobbiamo cambiare radicalmente il design ed eliminare completamente blocchi e produttori di blocchi. Invece di costruire una catena di blocchi, collegheremo le transazioni stesse, includendo in ogni transazione gli hash di diverse transazioni precedenti. Di conseguenza, otterremo una struttura nota in matematica come grafo aciclico orientato - DAG.<\/p>\n

Ora ognuno ha accesso diretto al registro, senza intermediari. Quando vuoi aggiungere una transazione al registro, la aggiungi semplicemente. Selezioni alcune transazioni genitore, aggiungi i tuoi dati, firmi e invii la tua transazione alla piramide nella rete. Fatto. Non c'\u00e8 nessuno che possa impedirtelo, quindi la tua transazione \u00e8 gi\u00e0 nel registro.<\/p>\n

Questo \u00e8 il modo pi\u00f9 decentralizzato e resistente alla censura per aggiungere transazioni al registro senza intermediari. Perch\u00e9 chiunque pu\u00f2 semplicemente aggiungere le proprie transazioni al registro, senza chiedere il permesso a nessuno.<\/p>\n

\"Dal
\n
\nIl DAG pu\u00f2 essere considerato la terza fase dell'evoluzione dei registri. Inizialmente c'erano registri centralizzati, dove una parte controllava l'accesso. Poi sono arrivati i blockchain, in cui c'erano gi\u00e0 pi\u00f9 controllori che registravano le transazioni nel registro. E infine, nel DAG non ci sono controllori, gli utenti aggiungono direttamente le proprie transazioni.<\/p>\n

\"Dal
\n
\nOra che abbiamo questa libert\u00e0, non deve portare al caos. Dobbiamo avere un consenso sullo stato del registro. E questo consenso, o consenso, di solito significa accordo su due cose:<\/p>\n

    \n
  1. Cosa \u00e8 successo?\n<\/li>\n
  2. In che ordine \u00e8 avvenuto?\n<\/li>\n<\/ol>\n

    \nAlla prima domanda possiamo rispondere facilmente: una volta che una transazione correttamente creata \u00e8 stata aggiunta al registro, essa \u00e8 avvenuta. E basta. Le informazioni su questo possono giungere a tutti i partecipanti in momenti diversi, ma alla fine tutti i nodi riceveranno questa transazione e sapranno che \u00e8 avvenuta.<\/p>\n

    Se fosse una blockchain, i miner deciderebbero cosa sta avvenendo. Tutto ci\u00f2 che il miner decide di includere nel blocco \u2013 quello avviene. Tutto ci\u00f2 che non include nel blocco \u2013 non avviene.<\/p>\n

    Nelle blockchain, i miner decidono anche il secondo problema del consenso: l'ordine. Sono autorizzati a ordinare le transazioni all'interno del blocco come vogliono.<\/p>\n

    Come possiamo determinare l'ordine delle transazioni nel DAG?<\/p>\n

    \"Dal
    \n
    \nSolo perch\u00e9 il nostro grafo \u00e8 diretto, abbiamo gi\u00e0 un certo ordine. Ogni transazione fa riferimento a una o pi\u00f9 transazioni precedenti, genitoriali. I genitori, a loro volta, si riferiscono ai loro genitori, e cos\u00ec via. I genitori, ovviamente, appaiono prima delle transazioni figlie. Se una qualsiasi delle transazioni pu\u00f2 essere raggiunta tramite i passaggi seguendo i riferimenti \"genitore-figlio\", sappiamo esattamente l'ordine tra le transazioni in questa catena di transazioni.<\/p>\n

    \"Dal
    \n
    \nMa l'ordine tra le transazioni non sempre pu\u00f2 essere determinato solo dalla forma del grafo. Ad esempio, quando due transazioni si trovano su rami paralleli del grafo.<\/p>\n

    \"Dal
    \n
    \nPer risolvere l'ambiguit\u00e0 in tali casi, ci affidiamo a quelli che chiamiamo fornitori di ordine. Li chiamiamo anche \"testimoni\". Sono utenti normali il cui compito \u00e8 inviare costantemente transazioni nella rete mantenendo l'ordine, cio\u00e8 in modo che ciascuna delle loro transazioni precedenti possa essere raggiunta seguendo i riferimenti \"genitore-figlio\". I fornitori di ordine \u2013     utenti fidati<\/a>, e l'intera rete si affida al fatto che non violeranno questa regola. Per far s\u00ec che razionale<\/b> affidarsi a loro; richiediamo che ogni fornitore di ordine sia una persona o un'organizzazione riconosciuta (non anonima) e abbia qualcosa da perdere in caso di violazione delle regole, come ad esempio la reputazione o un business basato sulla fiducia.<\/p>\n

    \"Dal
    \n
    \nI fornitori di ordine vengono scelti dagli utenti e ogni utente include un elenco dei propri fornitori fidati in ogni transazione che invia alla rete. Questo elenco \u00e8 composto da 12 fornitori. \u00c8 un numero piuttosto ridotto che consente alle persone di verificare l'identit\u00e0 e la reputazione di ciascuno di loro, e sufficiente perch\u00e9 la rete continui a funzionare nel caso di problemi inevitabili con una minoranza dei fornitori di ordine.<\/p>\n

    Questo elenco di fornitori varia da utente a utente, ma gli elenchi delle transazioni adiacenti possono differire al massimo per un fornitore.<\/p>\n

    \"Dal
    \n
    \nOra che abbiamo i fornitori di ordine, possiamo evidenziare le loro transazioni in un DAG e ordinare tutte le altre transazioni attorno all'ordine generato da loro. Esiste la possibilit\u00e0 di creare un algoritmo di questo tipo (vedi     Obyte White Paper<\/a><\/noindex> per dettagli tecnici).<\/p>\n

    Tuttavia, l'ordine nell'intera rete non pu\u00f2 essere stabilito immediatamente; ci vuole tempo affinch\u00e9 i provider d'ordine inviino un numero sufficiente delle loro transazioni per verificare l'ordine finale delle transazioni passate.<\/p>\n

    E poich\u00e9 l'ordine \u00e8 determinato solo dalle posizioni delle transazioni dei provider nel DAG, tutte le nodi della rete, prima o poi, riceveranno tutte le transazioni e giungeranno alla stessa conclusione riguardo all'ordine delle transazioni.<\/p>\n

    \"Dal
    \n
    \nQuindi, abbiamo un consenso su ci\u00f2 che consideriamo accaduto: qualsiasi transazione entrata nel DAG \u00e8 avvenuta. Abbiamo anche consenso sull'ordine degli eventi: questo \u00e8 visibile dalle relazioni tra le transazioni o deriva dall'ordine delle transazioni inviate dai provider d'ordine. Pertanto, abbiamo un consenso.<\/p>\n

    \"Dal
    \n
    \nQuesta variante del consenso \u00e8 presente in Obyte. Anche se l'accesso al registro Obyte \u00e8 completamente decentralizzato, il consenso sul ordine delle transazioni rimane comunque centralizzato, poich\u00e9 10 dei 12 fornitori sono controllati dal creatore (Anton Churyumov), e solo due di essi sono indipendenti. Stiamo cercando candidati disposti a diventare uno dei fornitori indipendenti dell'ordine, per aiutare a decentralizzare l'istituzione dell'ordine nel registro.<\/p>\n

    Recentemente \u00e8 emerso un terzo candidato indipendente, desideroso di stabilire e mantenere un nodo del fornitore dell'ordine \u2013 l'Universit\u00e0 di Nicosia.<\/p>\n

    \"Dal
    \n
    \nOra, come controlliamo le doppie spese (double-spends)?<\/p>\n

    Secondo le regole, quando vengono rilevate due transazioni che spendono la stessa moneta, la transazione che risulta prima nell'ordine finale di tutte le transazioni vince. La seconda viene invalidata dall'algoritmo di consenso.<\/p>\n

    \"Dal
    \nNel caso in cui sia possibile stabilire un ordine tra due transazioni che spendono una moneta (secondo le relazioni genitore-figlio), tutte le nodi rifiutano immediatamente tale tentativo di doppia spesa.<\/p>\n

    \"Dal
    \n
    \nSe l'ordine non \u00e8 visibile dalle relazioni parentali tra due transazioni simili, entrambe vengono accettate nel registro e dovremo aspettare il consenso e l'ordinamento tra di esse tramite i fornitori di ordine. In tal caso, vincer\u00e0 la transazione pi\u00f9 precoce, mentre la seconda diventer\u00e0 non valida.<\/p>\n

    \"Dal
    \n
    \nSebbene la seconda transazione diventi non valida, rimane comunque nel registro, poich\u00e9 ha gi\u00e0 delle transazioni successive che la citano, le quali non hanno infranto nulla e non sapevano che in futuro questa transazione sarebbe diventata non valida. Altrimenti, dovremmo rimuovere il genitore dalle buone transazioni successive, compromettendo il principio principale della rete: qualsiasi transazione valida viene accettata nel registro.<\/p>\n

    \"Dal
    \n
    \nQuesta \u00e8 una regola molto importante, che permette all'intero sistema di essere resistente ai tentativi di censura.\u00a0<\/p>\n

    Immagina che tutti i provider di rete si mettano d'accordo per \"censurare\" una transazione specifica. Possono ignorarla e non sceglierla mai come \"genitore\" per le loro transazioni, ma questo non \u00e8 sufficiente; quella transazione potrebbe comunque essere indirettamente inclusa come genitore di un'altra transazione emessa da un qualsiasi utente della rete che non partecipa all'accordo. Nel tempo, tale transazione avr\u00e0 sempre pi\u00f9 \"figli\", \"nipoti\" e \"pronipoti\" da utenti comuni, espandendosi come una palla di neve, e tutti i provider d'accordo dovranno anche ignorare queste nuove transazioni. Alla fine, dovranno censurare l'intera rete, il che equivale a un sabotaggio.<\/p>\n

    \"Dal
    \n
    \nIn questo modo, il DAG rimane resistente alla censura, anche in caso di collusione tra i provider di rete, superando cos\u00ec il blockchain in termini di resilienza alla censura, poich\u00e9 non possiamo fare nulla se i miner decidono di non includere una delle transazioni. E questo deriva dalla principale caratteristica del DAG: la partecipazione al registro \u00e8 completamente indipendente e senza intermediari, e le transazioni sono irreversibili.
    \n
    Fonte:     habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u0432\u0430\u043c \u043e DAG (Directed Acyclic Graph, \u043d\u0430\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u043d\u044b\u0439 \u0430\u0446\u0438\u043a\u043b\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0433\u0440\u0430\u0444) \u0438 \u0435\u0433\u043e \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u0438 \u0432 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u0445 \u0440\u0435\u0435\u0441\u0442\u0440\u0430\u0445, \u0438 \u043c\u044b \u0441\u0440\u0430\u0432\u043d\u0438\u043c \u0435\u0433\u043e \u0441 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u043e\u043c. DAG \u043d\u0435 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0447\u0435\u043c-\u0442\u043e \u043d\u043e\u0432\u044b\u043c \u0432 \u043c\u0438\u0440\u0435 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442. \u0412\u043e\u0437\u043c\u043e\u0436\u043d\u043e \u0432\u044b \u0441\u043b\u044b\u0448\u0430\u043b\u0438 \u043e \u043d\u0451\u043c \u043a\u0430\u043a \u043e \u0440\u0435\u0448\u0435\u043d\u0438\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u043e\u0441\u0442\u0438 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u043e\u0432. \u041d\u043e \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u044b \u0431\u0443\u0434\u0435\u043c \u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044c \u043d\u0435 \u043e \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u043e\u0441\u0442\u0438, \u0430 \u043e […]<\/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-53183","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\udd47Dal blockchain al DAG: liberiamo dalle intermediazioni | ProHoster","description":"In questo articolo parler\u00f2 del DAG (Directed Acyclic Graph, grafo diretto aciclico) e del suo utilizzo nei registri distribuiti, confrontandolo con la blockchain. Il DAG non \u00e8 una novit\u00e0 nel mondo delle criptovalute. Potreste averne sentito parlare come una soluzione ai problemi di scalabilit\u00e0 delle blockchain. Ma oggi non parleremo di scalabilit\u00e0, ma di","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ot-blokchejna-k-dag-izbavlyaemsya-ot-posrednikov","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\u0442 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0430 \u043a DAG: \u0438\u0437\u0431\u0430\u0432\u043b\u044f\u0435\u043c\u0441\u044f \u043e\u0442 \u043f\u043e\u0441\u0440\u0435\u0434\u043d\u0438\u043a\u043e\u0432 | ProHoster","og:description":"\u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u0432\u0430\u043c \u043e DAG (Directed Acyclic Graph, \u043d\u0430\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u043d\u044b\u0439 \u0430\u0446\u0438\u043a\u043b\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0433\u0440\u0430\u0444) \u0438 \u0435\u0433\u043e \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u0438 \u0432 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u0445 \u0440\u0435\u0435\u0441\u0442\u0440\u0430\u0445, \u0438 \u043c\u044b \u0441\u0440\u0430\u0432\u043d\u0438\u043c \u0435\u0433\u043e \u0441 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u043e\u043c. DAG \u043d\u0435 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0447\u0435\u043c-\u0442\u043e \u043d\u043e\u0432\u044b\u043c \u0432 \u043c\u0438\u0440\u0435 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442. \u0412\u043e\u0437\u043c\u043e\u0436\u043d\u043e \u0432\u044b \u0441\u043b\u044b\u0448\u0430\u043b\u0438 \u043e \u043d\u0451\u043c \u043a\u0430\u043a \u043e \u0440\u0435\u0448\u0435\u043d\u0438\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u043e\u0441\u0442\u0438 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u043e\u0432. \u041d\u043e \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u044b \u0431\u0443\u0434\u0435\u043c \u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044c \u043d\u0435 \u043e \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u043e\u0441\u0442\u0438, \u0430 \u043e","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ot-blokchejna-k-dag-izbavlyaemsya-ot-posrednikov","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-11-24T21:00:00+00:00","article:modified_time":"2026-02-15T17:54:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53183","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-02-15 17:55:40","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:29:27","updated":"2026-02-15 17:55:40"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/53183","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=53183"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/53183\/revisions"}],"predecessor-version":[{"id":161174,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/53183\/revisions\/161174"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=53183"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=53183"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=53183"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}