{"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\/da\/blog\/administrirovanie\/ot-blokchejna-k-dag-izbavlyaemsya-ot-posrednikov","title":{"rendered":"Fra blockchain til DAG: Vi fjerner mellemm\u00e6nd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I denne artikel vil jeg fort\u00e6lle dig om DAG (Directed Acyclic Graph, rettet acyklisk graf) og dets anvendelse i distribuerede registre, og vi vil sammenligne det med blockchain.<\/p>\n

\"Fra
\n
\nDAG er ikke noget nyt i kryptovalutaernes verden. Du har m\u00e5ske h\u00f8rt om det som en l\u00f8sning p\u00e5 blockchainers skalerbarhedsproblemer. Men i dag vil vi ikke tale om skalerbarhed, men om hvad der g\u00f8r kryptovalutaer s\u00e6rlige: decentralisering, frav\u00e6ret af mellemm\u00e6nd og modstandsdygtigheden over for censur.
\n<\/a><\/noindex>
\n\"Fra
\n
\nJeg vil ogs\u00e5 vise dig, at DAG faktisk er mere modstandsdygtig over for censur, og at der ikke er nogen mellemm\u00e6nd for at f\u00e5 adgang til registret.<\/p>\n

\"Fra
\n
\nI de velkendte blockchains har brugerne ikke direkte adgang til selve registret. N\u00e5r du \u00f8nsker at tilf\u00f8je en transaktion til registret, er du n\u00f8dt til at \"anmode\" blokproducenten (block producer, ogs\u00e5 kaldet \"miner\") om at g\u00f8re det. Det er minerne, der beslutter, hvilken transaktion der skal tilf\u00f8jes til den n\u00e6ste blok, og hvilken der skal ignoreres. Det er minerne, der har eksklusiv adgang til blokkene og retten til at beslutte, hvis transaktion der skal accepteres for at blive tilf\u00f8jet til registret.<\/p>\n

Minerne er de mellemm\u00e6nd, der st\u00e5r mellem dig og det distribuerede register.<\/p>\n

\"Fra
\n
\nI praksis kontrollerer et lille antal minedrift-pools kollektivt mere end halvdelen af netv\u00e6rkets regnekraft. For Bitcoin er det fire pools, og for Ethereum er det to. I tilf\u00e6lde af sammensv\u00e6rgelse kan de blokere for enhver transaktion, de \u00f8nsker.<\/p>\n

\"Fra
\n
\nI de seneste \u00e5r er der blevet foresl\u00e5et mange varianter af blockchains, der adskiller sig i principperne for valg af blokproducenter. Men blokproducenterne forsvinder ikke, de \"st\u00e5r stadig ved bommen\": hver transaktion skal g\u00e5 gennem blokproducenten, og hvis han ikke accepterer den, eksisterer transaktionen faktisk ikke.<\/p>\n

\"Fra
\n
\nDette er et uundg\u00e5eligt problem med blockchain. Og hvis vi \u00f8nsker at l\u00f8se det, m\u00e5 vi radikalt \u00e6ndre designet og helt fjerne blokke og blokproducenter. I stedet for at opbygge en k\u00e6de af blokke, vil vi forbinde selve transaktionerne ved at inkludere hash-ene af flere tidligere transaktioner i hver transaktion. Resultatet vil v\u00e6re en struktur, der i matematik kaldes en rettet acyklisk graf \u2013 DAG.<\/p>\n

Nu har alle direkte adgang til registret uden mellemled. N\u00e5r du \u00f8nsker at tilf\u00f8je en transaktion til registret, tilf\u00f8jer du bare den. V\u00e6lg flere for\u00e6ldrepr\u00e6stationer, tilf\u00f8j dine oplysninger, underskriv, og send din transaktion ud i netv\u00e6rket. Klar. Der er ingen, der kan forhindre dig i at g\u00f8re dette, s\u00e5 din transaktion er allerede i registret.<\/p>\n

Dette er den mest decentrale, mest modstandsdygtige metode til at tilf\u00f8je transaktioner til registret uden mellemled. For hver enkelt kan tilf\u00f8je sine transaktioner til registret uden at sp\u00f8rge om tilladelse fra nogen.<\/p>\n

\"Fra
\n
\nDAG kan betragtes som den tredje fase i udviklingen af registre. F\u00f8rst var der centraliserede registre, hvor \u00e9n part kontrollerede adgangen til dem. S\u00e5 kom blockchain, hvor der var flere controllere, der skrev transaktioner ind i registret. Og endelig, i DAG, findes der slet ingen controllere, brugerne tilf\u00f8jer deres transaktioner direkte.<\/p>\n

\"Fra
\n
\nNu hvor vi har s\u00e5dan en frihed, b\u00f8r det ikke f\u00f8re til kaos. Vi skal have enighed om tilstanden af registret. Og denne enighed eller konsensus betyder normalt enighed om to ting:<\/p>\n

    \n
  1. Hvad skete der?\n<\/li>\n
  2. I hvilken r\u00e6kkef\u00f8lge fandt det sted?\n<\/li>\n<\/ol>\n

    \nP\u00e5 det f\u00f8rste sp\u00f8rgsm\u00e5l kan vi nemt svare: s\u00e5 snart en korrekt lavet transaktion er blevet tilf\u00f8jet til registret, fandt den sted. Og punktum. Oplysninger om dette kan n\u00e5 frem til alle deltagere p\u00e5 forskellige tidspunkter, men til sidst vil alle noder modtage denne transaktion og finde ud af, at den har fundet sted.<\/p>\n

    Hvis det havde v\u00e6ret en blockchain, ville minerne have bestemte, hvad der skete. Alt, hvad en miner beslutter at inkludere i blokken, bliver til virkelighed. Alt, hvad han ikke inkluderer i blokken, sker ikke.<\/p>\n

    I blockchain beslutter minerne ogs\u00e5 den anden konsensusproblematik: r\u00e6kkef\u00f8lgen. De har tilladelse til at r\u00e6kkef\u00f8lge transaktioner inden for blokken, som de vil.<\/p>\n

    Hvordan bestemmer man r\u00e6kkef\u00f8lgen af transaktioner i DAG?<\/p>\n

    \"Fra
    \n
    \nKun grafen er rettet, har vi allerede en vis orden. Hver transaktion refererer til en eller flere tidligere, parent-transaktioner. For\u00e6ldre henviser igen til deres for\u00e6ldre, og s\u00e5 videre. For\u00e6ldre optr\u00e6der \u00e5benlyst f\u00f8r deres dattertransaktioner. Hvis en transaktion kan n\u00e5s gennem \"parent-child\"-links, s\u00e5 kender vi pr\u00e6cist r\u00e6kkef\u00f8lgen mellem transaktionerne i denne k\u00e6de.<\/p>\n

    \"Fra
    \n
    \nMen r\u00e6kkef\u00f8lgen mellem transaktionerne kan ikke altid bestemmes kun ud fra grafens struktur. For eksempel, n\u00e5r to transaktioner ligger p\u00e5 parallelle grene af grafen.<\/p>\n

    \"Fra
    \n
    \nFor at opklare tvetydighed i s\u00e5danne tilf\u00e6lde, stoler vi p\u00e5 s\u00e5kaldte r\u00e6kkef\u00f8lgeudbydere. Vi kalder dem ogs\u00e5 \"vidner\". Det er almindelige brugere, hvis opgave er konstant at sende transaktioner til nettet i den rigtige r\u00e6kkef\u00f8lge, s\u00e5 hver af deres tidligere transaktioner kan n\u00e5s gennem \"parent-child\"-links. R\u00e6kkef\u00f8lgeudbydere \u2013     betroede brugere<\/a>, og hele netv\u00e6rket stoler p\u00e5, at de ikke vil overtr\u00e6de denne regel. For at have en rationel<\/b> tillid til dem, kr\u00e6ver vi, at hver r\u00e6kkef\u00f8lgeudbyder er en kendt (ikke-anonym) person eller organisation, der har noget at tabe, hvis de overtr\u00e6der reglerne, s\u00e5som omd\u00f8mme eller en forretning baseret p\u00e5 tillid.<\/p>\n

    \"Fra
    \n
    \nR\u00e6kkef\u00f8lgeudbydere v\u00e6lges af brugerne, og hver bruger inkluderer en liste over sine betroede udbydere i hver transaktion, de sender til netv\u00e6rket. Denne liste best\u00e5r af 12 udbydere. Det er et forholdsvis lille antal, s\u00e5 en person kan verificere identiteten og omd\u00f8mmet for hver af dem, og tilstr\u00e6kkeligt til, at netv\u00e6rket kan forts\u00e6tte med at fungere i tilf\u00e6lde af uundg\u00e5elige problemer med et mindretal af r\u00e6kkef\u00f8lgeudbyderne.<\/p>\n

    Denne liste over udbydere varierer fra bruger til bruger, men listerne for tilst\u00f8dende transaktioner kan maksimalt afvige med \u00e9n udbyder.<\/p>\n

    \"Fra
    \n
    \nNu hvor vi har r\u00e6kkef\u00f8lgeudbydere, kan vi isolere deres transaktioner i DAG og ordne alle andre transaktioner omkring den r\u00e6kkef\u00f8lge, de skaber. Der er mulighed for at skabe en s\u00e5dan algoritme (se for     Obyte White Paper<\/a><\/noindex> for tekniske detaljer).<\/p>\n

    Men orden i hele netv\u00e6rket kan ikke bestemmes \u00f8jeblikkeligt; vi har brug for tid til, at ordensudbyderne sender et tilstr\u00e6kkeligt antal af deres transaktioner for at bekr\u00e6fte den endelige r\u00e6kkef\u00f8lge af de tidligere transaktioner.<\/p>\n

    Og eftersom r\u00e6kkef\u00f8lgen kun bestemmes af ordensudbydernes positioner i DAG, vil alle noder i netv\u00e6rket f\u00f8r eller siden modtage alle transaktioner og n\u00e5 frem til den samme konklusion vedr\u00f8rende r\u00e6kkef\u00f8lgen af transaktioner.<\/p>\n

    \"Fra
    \n
    \nS\u00e5 vi har enighed om, hvad der er sket: enhver transaktion, der kommer ind i DAG, er sket. Vi har ogs\u00e5 enighed om r\u00e6kkef\u00f8lgen af h\u00e6ndelserne: dette er enten synligt fra de relationelle forbindelser mellem transaktionerne eller kan udledes fra r\u00e6kkef\u00f8lgen af transaktioner sendt af ordensudbyderne. Det betyder, at vi har konsensus.<\/p>\n

    \"Fra
    \n
    \nDenne form for konsensus har vi i Obyte. P\u00e5 trods af at adgangen til Obyte-registret er fuldst\u00e6ndig decentraliseret, er konsensus vedr\u00f8rende r\u00e6kkef\u00f8lgen af transaktioner stadig centraliseret, da 10 ud af 12 udbydere kontrolleres af skaberen (Anton Churyumov), og kun to af dem er uafh\u00e6ngige. Vi s\u00f8ger kandidater, der \u00f8nsker at blive en af de uafh\u00e6ngige ordensudbydere for at hj\u00e6lpe os med at decentralisere fasts\u00e6ttelsen af r\u00e6kkef\u00f8lgen i registret.<\/p>\n

    For nylig er der dukket op en tredje uafh\u00e6ngig kandidat, der \u00f8nsker at etablere og opretholde en ordensudbydernode \u2013 Universitetet i Nikosia.<\/p>\n

    \"Fra
    \n
    \nHvordan kontrollerer vi dobbeltudgifter (double-spends)?<\/p>\n

    If\u00f8lge reglerne, n\u00e5r to transaktioner, der bruger den samme m\u00f8nt, opdages, vinder den transaktion, der kom f\u00f8rst i den endelige r\u00e6kkef\u00f8lge af alle transaktioner. Den anden bliver ugyldiggjort af konsensusalgoritmen.<\/p>\n

    \"Fra
    \nHvis det er muligt at fastsl\u00e5 r\u00e6kkef\u00f8lgen mellem to transaktioner, der bruger samme m\u00f8nt (via for\u00e6lder-barn relationer), vil alle noder straks afvise et s\u00e5dant fors\u00f8g p\u00e5 dobbeltudgift.<\/p>\n

    \"Fra
    \n
    \nI tilf\u00e6lde af at r\u00e6kkef\u00f8lgen ikke er synlig fra for\u00e6ldrenes forbindelser mellem de to transaktioner, accepteres begge i registret, og vi bliver n\u00f8dt til at vente p\u00e5 konsensus og fastl\u00e6ggelse af r\u00e6kkef\u00f8lgen mellem dem ved hj\u00e6lp af ordensudbyderne. Da vinder den tidligere transaktion, og den anden bliver ikke-valid.<\/p>\n

    \"Fra
    \n
    \nSelvom den anden transaktion bliver ugyldig, forbliver den stadig i registret, fordi den allerede har efterf\u00f8lgende transaktioner, der refererer til den, som ikke har overtr\u00e5dt noget og ikke vidste, at denne transaktion en dag ville blive ugyldig. Ellers skulle vi fjerne for\u00e6lderen fra de gode efterf\u00f8lgende transaktioner, hvilket ville bryde det grundl\u00e6ggende princip i netv\u00e6rket - enhver gyldig transaktion accepteres i registret.<\/p>\n

    \"Fra
    \n
    \nDette er en meget vigtig regel, der g\u00f8r hele systemet modstandsdygtigt over for fors\u00f8g p\u00e5 censur.\u00a0<\/p>\n

    Lad os forestille os, at alle ordreudbydere indg\u00e5r en sammensv\u00e6rgelse i et fors\u00f8g p\u00e5 at 'censurere' en bestemt transaktion. De kan ignorere den og aldrig v\u00e6lge den som 'for\u00e6lder' til deres transaktioner, men det er ikke nok; denne transaktion kan stadig blive inkluderet indirekte som for\u00e6lder til en anden transaktion sendt af en hvilken som helst bruger i netv\u00e6rket, som ikke deltager i sammensv\u00e6rgelsen. Over tid vil en s\u00e5dan transaktion f\u00e5 flere og flere b\u00f8rn, b\u00f8rneb\u00f8rn og oldeb\u00f8rn fra almindelige brugere, der vokser som en snebold, og alle de aftalte ordreudbydere vil ogs\u00e5 v\u00e6re n\u00f8dt til at ignorere disse transaktioner. Til sidst vil de v\u00e6re n\u00f8dt til at censurere hele netv\u00e6rket, hvilket svarer til sabotage.<\/p>\n

    \"Fra
    \n
    \nDermed forbliver DAG modstandsdygtig over for censur, selvom der er en sammensv\u00e6rgelse blandt ordreudbydere, hvilket g\u00f8r det mere modstandsdygtigt over for censur end blockchain, hvor vi intet kan g\u00f8re, hvis minepersoner beslutter ikke at inkludere nogen af transaktionerne. Og dette f\u00f8lger af den prim\u00e6re egenskab ved DAG: deltagelse i registret er helt uafh\u00e6ngig og uden mellemm\u00e6nd, og transaktioner er irreversible.
    \n
    Kilde:     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\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\udd47Fra blockchain til DAG: Vi slipper af med mellemm\u00e6nd | ProHoster","description":"I denne artikel vil jeg fort\u00e6lle dig om DAG (Directed Acyclic Graph, rettet acyklisk graf) og dets anvendelse i distribuerede registre, og vi vil sammenligne det med blockchain.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ot-blokchejna-k-dag-izbavlyaemsya-ot-posrednikov","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/53183","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=53183"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/53183\/revisions"}],"predecessor-version":[{"id":161174,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/53183\/revisions\/161174"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=53183"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=53183"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=53183"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}