{"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":"Dalla blockchain al DAG: liberiamoci degli intermediari","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

\"Dalla
\n
\nIl DAG non \u00e8 qualcosa di nuovo nel mondo delle criptovalute. Forse ne avete sentito parlare come soluzione ai problemi di scalabilit\u00e0 delle blockchain. Ma oggi non parleremo di scalabilit\u00e0, bens\u00ec di ci\u00f2 che rende le criptovalute diverse da tutto il resto: decentralizzazione, assenza di intermediari e resistenza alla censura.
\n<\/a><\/noindex>
\n\"Dalla
\n
\nVi mostrer\u00f2 anche che il DAG \u00e8 in realt\u00e0 pi\u00f9 resistente alla censura e non ha intermediari per accedere al registro.<\/p>\n

\"Dalla
\n
\nNelle blockchain che conosciamo, gli utenti non hanno accesso diretto al registro stesso. Quando desideri aggiungere una transazione al registro, devi 'chiedere' al produttore di blocchi (block producer, anche noto come 'miner') di farlo. Sono i miner a decidere quale transazione includere nel prossimo blocco e quale no. Solo i miner hanno accesso esclusivo ai blocchi e il diritto di decidere quale transazione accettare per l'aggiunta al registro.<\/p>\n

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

\"Dalla
\n
\nIn pratica, di solito un numero ridotto di pool di miner controlla collettivamente pi\u00f9 della met\u00e0 della potenza di calcolo della rete. Per Bitcoin sono quattro pool, per Ethereum sono due. In caso di collusione, possono bloccare qualsiasi transazione vogliano.<\/p>\n

\"Dalla
\n
\nNegli ultimi anni sono state proposte numerose variazioni di blockchain, che differiscono nei principi di selezione dei produttori di blocchi. Ma i produttori di blocchi non spariranno; continuano a 'stare al varco': ogni transazione deve passare attraverso il produttore di blocchi e se questo non l'accetta, allora la transazione, di fatto, non esiste.<\/p>\n

\"Dalla
\n
\nQuesto \u00e8 un problema inevitabile nel caso delle blockchain. E se vogliamo risolverlo, dobbiamo cambiare radicalmente il design e liberarci completamente dai blocchi e dai produttori di blocchi. Invece di costruire una catena di blocchi, collegheremo le transazioni stesse, includendo in ogni transazione gli hash di diverse precedenti. Di conseguenza, otterremo una struttura nota in matematica come grafo diretto aciclico \u2013 DAG.<\/p>\n

Ora tutti hanno accesso diretto al registro, senza intermediari. Quando vuoi aggiungere una transazione al registro, la aggiungi semplicemente. Selezioni alcune transazioni parenti, aggiungi i tuoi dati, firmi e invii la tua transazione sulla rete. Fatto. Non c'\u00e8 nessuno che possa impedirti di farlo, 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 desideri pu\u00f2 semplicemente aggiungere le proprie transazioni al registro, senza chiedere il permesso a nessuno.<\/p>\n

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

\"Dalla
\n
\nOra che abbiamo questa libert\u00e0, non deve portare al caos. Dobbiamo avere consenso sullo stato del registro. E questo consenso, o consenso, di solito significa consenso 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 facilmente rispondere: non appena una transazione creata correttamente \u00e8 stata aggiunta al registro, \u00e8 avvenuta. E basta. Le informazioni possono raggiungere tutti i partecipanti in tempi diversi, ma alla fine tutti i nodi riceveranno questa transazione e scopriranno che \u00e8 avvenuta.<\/p>\n

    Se fosse un blockchain, i miner deciderebbero cosa accade. Tutto ci\u00f2 che il miner decide di includere nel blocco \u2013 questo accade. Tutto ci\u00f2 che non include nel blocco \u2013 non accade.<\/p>\n

    Nei blockchain, i miner risolvono anche il secondo problema di consenso: l'ordine. Possono ordinare le transazioni all'interno del blocco come vogliono.<\/p>\n

    Come si determina allora l'ordine delle transazioni nel DAG?<\/p>\n

    \"Dalla
    \n
    \nSolo perch\u00e9 il grafo \u00e8 orientato, abbiamo gi\u00e0 un certo ordine. Ogni transazione si riferisce 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 figlio. Se una delle transazioni pu\u00f2 essere raggiunta attraverso i legami \"genitore-figlio\", sappiamo esattamente l'ordine tra le transazioni in questa catena di transazioni.<\/p>\n

    \"Dalla
    \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

    \"Dalla
    \n
    \nPer risolvere l'ambiguit\u00e0 in tali casi, ci affidiamo ai cosiddetti fornitori di ordine. Li chiamiamo anche \"testimoni\". Sono utenti comuni, il cui compito \u00e8 quello di inviare costantemente transazioni nella rete seguendo un ordine, cio\u00e8 in modo tale che ciascuna delle loro transazioni precedenti possa essere raggiunta attraverso i legami \"genitore-figlio\". I fornitori di ordine sono     utenti fidati<\/a>, e l'intera rete si basa sul fatto che non violeranno questa regola. Affinch\u00e9 si possa avere fiducia in loro, richiediamo che ogni fornitore di ordine sia una persona o un'organizzazione conosciuta (non anonima) e abbia qualcosa da perdere nel caso in cui violi le regole, ad esempio, reputazione o affari basati sulla fiducia.<\/b> I fornitori di ordine sono scelti dagli utenti, e ogni utente include un elenco dei suoi fornitori di fiducia in ogni transazione che invia alla rete. Questo elenco \u00e8 composto da 12 fornitori. Questo numero \u00e8 piuttosto ridotto, permettendo a una persona di verificare le identit\u00e0 e la reputazione di ciascuno di essi, e sufficiente affinch\u00e9 la rete continui a funzionare nel caso di inevitabili problemi con una minoranza di fornitori di ordine.<\/p>\n

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

    Ora che abbiamo i fornitori di ordine, possiamo isolare le loro transazioni nel DAG e ordinare tutte le altre transazioni attorno all'ordine creato da essi. \u00c8 possibile creare un tale algoritmo (vedi<\/p>\n

    \"Dalla
    \n
    \nObyte White Paper     per dettagli tecnici).<\/a><\/noindex> per dettagli tecnici).<\/p>\n

    Ma l'ordine in tutta la rete non pu\u00f2 essere determinato istantaneamente, abbiamo bisogno di tempo affinch\u00e9 i fornitori di 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 fornitori nel DAG, tutti i nodi della rete prima o poi riceveranno tutte le transazioni e giungeranno alla medesima conclusione riguardo all'ordine delle transazioni.<\/p>\n

    \"Dalla
    \n
    \nQuindi, abbiamo un consenso su ci\u00f2 che consideriamo accaduto: qualsiasi transazione che entra nel DAG \u00e8 considerata avvenuta. Abbiamo anche un consenso sull'ordine degli eventi: questo \u00e8 visibile in base alle relazioni parenti-figli delle transazioni, o ricavato dall'ordine delle transazioni inviate dai fornitori di ordine. Pertanto, abbiamo un consenso.<\/p>\n

    \"Dalla
    \n
    \nQuesto tipo di consenso \u00e8 presente in Obyte. Anche se l'accesso al registro di Obyte \u00e8 completamente decentralizzato, il consenso riguardo all'ordine delle transazioni rimane comunque centralizzato, poich\u00e9 10 su 12 fornitori sono controllati dal creatore (Anton Churyumov), e solo due di essi sono indipendenti. Stiamo cercando candidati disposti a diventare uno dei fornitori di ordine indipendenti, per aiutarci a decentralizzare la determinazione dell'ordine nel registro.<\/p>\n

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

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

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

    \"Dalla
    \nNel caso in cui sia possibile stabilire un ordine tra due transazioni che spendono la stessa moneta (in base alle relazioni parenti-figli), tutti i nodi rifiutano immediatamente tale tentativo di doppia spesa.<\/p>\n

    \"Dalla
    \n
    \nTuttavia, se l'ordine non \u00e8 visibile dalle relazioni parenti tra due transazioni simili, entrambe vengono accettate nel registro e dovremo attendere il consenso e la determinazione dell'ordine tra di esse tramite i fornitori di ordine. In tal caso, vincer\u00e0 la transazione pi\u00f9 antecedente, mentre l'altra diventer\u00e0 non valida.<\/p>\n

    \"Dalla
    \n
    \nAnche se la seconda transazione diventa non valida, rimane comunque nel registro poich\u00e9 ha gi\u00e0 transazioni successive ad essa, che non hanno violato nulla e non sapevano che in futuro questa transazione sarebbe diventata non valida. Altrimenti dovremmo eliminare il genitore di buone transazioni successive, il che violerebbe il principio fondamentale della rete: ogni transazione valida \u00e8 accettata nel registro.<\/p>\n

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

    Immaginiamo che tutti i fornitori di ordine si accordino nel tentativo di \"censurare\" una specifica transazione. Possono ignorarla e mai sceglierla come \"genitore\" per le loro transazioni, ma non basta, quella transazione pu\u00f2 comunque essere inclusa indirettamente come genitore di un'altra transazione emessa da qualsiasi utente della rete che non partecipa al complotto. Col tempo, tale transazione inizierebbe a ricevere sempre pi\u00f9 figli, nipoti e pronipoti da normali utenti, espandendosi come una palla di neve, e tutti i fornitori di ordine coinvolti nel complotto dovranno ignorare anche queste transazioni. Alla fine, dovranno censurare l'intera rete, il che equivale a sabotarli.<\/p>\n

    \"Dalla
    \n
    \nIn questo modo, il DAG rimane resistente alla censura, anche in presenza di un accordo tra i fornitori di ordine, superando cos\u00ec la blockchain in termini di resilienza alla censura, nella quale non possiamo fare nulla se i miner decidono di non includere una qualsiasi delle transazioni. E questo deriva dalla caratteristica principale del DAG: la partecipazione al registro \u00e8 assolutamente 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: eliminare gli intermediari | ProHoster","description":"In questo articolo vi parler\u00f2 del DAG (Directed Acyclic Graph, grafo diretto aciclico) e del suo utilizzo nei registri distribuiti, e confronteremo questo con la blockchain.","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.","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","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\/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}]}}