{"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\/da\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","title":{"rendered":"Om anonymitet i account-baserede blockchains","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vi har l\u00e6nge v\u00e6ret interesserede i emnet anonymitet inden for kryptovalutaer og fors\u00f8ger at f\u00f8lge udviklingen af teknologier p\u00e5 dette omr\u00e5de. I vores artikler har vi allerede grundigt gennemg\u00e5et principperne for konfidentielle transaktioner<\/a><\/noindex> i Monero, samt udf\u00f8rt en sammenlignende oversigt<\/a><\/noindex> over de teknologier, der findes p\u00e5 dette felt. Alle anonymiserede kryptovalutaer i dag er dog baseret p\u00e5 den datamodel, der foresl\u00e5s af Bitcoin \u2014 Unspent Transaction Output (senere UTXO). For account-baserede blockchains som Ethereum har eksisterende l\u00f8sninger til implementering af anonymitet og fortrolighed (for eksempel Mobius<\/a><\/noindex> eller Aztec<\/a><\/noindex>) fors\u00f8gt at genskabe UTXO-modellen i smarte kontrakter.<\/p>\n

I februar 2019 pr\u00e6senterede en gruppe forskere fra Stanford Universitet og Visa Research<\/a><\/noindex> har udgivet et fortryk<\/a><\/noindex> \"Zether: Mod privatliv i smart kontrakters verden\". Forfatterne foreslog for f\u00f8rste gang en tilgang til at sikre anonymitet i account-baserede blockchains og pr\u00e6senterede to varianter af smarte kontrakter: til konfidentielle (skjul balancer og overf\u00f8rselsbel\u00f8b) og anonyme (skjul modtager og afsender) transaktioner. Vi finder den foresl\u00e5ede teknologi interessant og \u00f8nsker at dele, hvordan den fungerer, samt diskutere, hvorfor anonymitetsproblemet i account-baserede blockchains anses for at v\u00e6re meget komplekst, og om forfatterne har form\u00e5et at l\u00f8se det fuldt ud.<\/p>\n

Om hvordan disse datamodeller fungerer<\/h3>\n

\nI UTXO-modellen best\u00e5r en transaktion af \"inputs\" og \"outputs\". Den direkte analog til \"outputs\" er sedlerne i din tegnebog: hver \"output\" har en bestemt v\u00e6rdi. N\u00e5r du betaler for noget (danner en transaktion), bruger du en eller flere \"outputs\", som derefter bliver \"inputs\" i transaktionen, og blockchain markerer dem som brugte. Modtageren af din betaling (eller du selv, hvis du har brug for veksel) modtager ny-genererede \"outputs\". Dette kan skematisk skildres som:<\/p>\n

\"Om
\n
\nAccount-baserede blockchains fungerer omtrent som din bankkonto. De opererer kun med bel\u00f8bet p\u00e5 din konto og overf\u00f8rselsbel\u00f8bet. N\u00e5r du overf\u00f8rer et bel\u00f8b fra din konto, br\u00e6nder du ikke nogen \"outputs\"; netv\u00e6rket beh\u00f8ver ikke at huske, hvilke m\u00f8nter der er brugt, og hvilke der ikke er. I den simpleste form reduceres kontrol af transaktionen til at kontrollere afsenderens signatur og bel\u00f8bet p\u00e5 hans saldo:<\/p>\n

\"Om
\n<\/p>\n

Gennemgang af teknologien<\/h3>\n

\nLad os tale om, hvordan Zether skjuler transaktionsbel\u00f8b, modtager og afsender. I beskrivelsen af dets funktioner vil vi bem\u00e6rke forskellene mellem den fortrolige og anonyme version. Da det er meget lettere at sikre fortrolighed i account-baserede blokke, vil nogle af de begr\u00e6nsninger, der p\u00e5l\u00e6gges anonymisering, ikke v\u00e6re relevante for den fortrolige version af teknologien.<\/p>\n

Skjule saldoer og overf\u00f8rselsbel\u00f8b<\/h4>\n

\nTil kryptering af saldoer og overf\u00f8rselsbel\u00f8b i Zether anvendes en krypteringsskema ElGamal<\/a><\/noindex>. Det fungerer p\u00e5 f\u00f8lgende m\u00e5de. N\u00e5r Alice \u00f8nsker at sende til Bob b<\/b><\/i> m\u00f8nter til adressen (hans offentlige n\u00f8gle) Y<\/b><\/i>, v\u00e6lger hun et tilf\u00e6ldigt tal r<\/b><\/i> og krypterer bel\u00f8bet:<\/p>\n

\"Om
\nhvor C<\/b><\/i> \u2014 det krypterede bel\u00f8b, D<\/b><\/i> \u2014 en hj\u00e6lpev\u00e6rdi, der er n\u00f8dvendig for at dekryptere dette bel\u00f8b, G<\/b><\/i> \u2014 et fast punkt p\u00e5 den elliptiske kurve, der giver den offentlige n\u00f8gle ved at multiplicere den hemmelige n\u00f8gle med det.<\/p>\n

N\u00e5r Bob modtager disse v\u00e6rdier, l\u00e6gger han dem blot til sin krypterede saldo, hvilket g\u00f8r denne ordning praktisk.<\/p>\n

P\u00e5 tilsvarende m\u00e5de tr\u00e6kker Alice de samme v\u00e6rdier fra sin saldo, kun i stedet for Y<\/b><\/i> bruger hun sin offentlige n\u00f8gle.<\/p>\n

Skjule modtager og afsender<\/h4>\n

\nBlanding af \"udgange\" i UTXO opstod allerede i kryptovalutaernes begyndelse og hj\u00e6lper med at skjule afsenderen. Til dette v\u00e6lger afsenderen tilf\u00e6ldige \"udgange\" i blockchainen ved overf\u00f8rsel og blander dem med sine egne. Derefter underskriver han \"udgangene\" med en ringunderskrift \u2014 en kryptografisk mekanisme, der giver mulighed for at overbevise kontrolleren om, at blandt de blandede \"udgange\" er der m\u00f8nter fra afsenderen. De blandede m\u00f8nter bruges naturligvis ikke.<\/p>\n

Men for at skjule modtageren kan vi ikke generere falske \"udgange\". Derfor har hver \"udgang\" i UTXO sin unikke adresse, og den er kryptografisk forbundet med modtagerens adresse for disse m\u00f8nter. I \u00f8jeblikket er der ingen m\u00e5de at afsl\u00f8re forbindelsen mellem den unikke adresse for \"udgangen\" og modtagerens adresse uden at kende dens hemmelige n\u00f8gler.<\/p>\n

I account-baserede modeller kan vi ikke bruge engangsadresser (ellers ville det v\u00e6re en 'udgangs'-model). Derfor skal modtageren og afsenderen blandes blandt andre konti i blockchainen. For de konti, der blandes, tr\u00e6kkes der 0 kryptovaluta (eller tilf\u00f8jes 0 \u2014 i tilf\u00e6lde af at modtageren blandes), hvilket faktisk ikke \u00e6ndrer deres reelle saldo.<\/p>\n

Da b\u00e5de afsender og modtager altid har en fast adresse, opst\u00e5r der behov for at bruge de samme grupper til at blande ved overf\u00f8rsler til de samme adresser. Det er nemmere at forst\u00e5 ved et eksempel.<\/p>\n

Lad os sige, at Alice \u00f8nsker at donere til Bobs velg\u00f8rende organisation, men hun foretr\u00e6kker, at denne overf\u00f8rsel forbliver anonym for en ekstern observat\u00f8r. For at skjule sig i afsenderfeltet skriver hun ogs\u00e5 Adams og Athels konti. For at skjule Bob tilf\u00f8jer hun Ben og Bills konti i modtagerfeltet. Ved den n\u00e6ste donation besluttede Alice at tilf\u00f8je Alex og Amanda ved siden af sig selv, og Bruce og Benji ved siden af Bob. I dette tilf\u00e6lde vil der ved analyse af blockchain kun v\u00e6re \u00e9t krydsende deltagerpar i de to transaktioner \u2014 Alice og Bob, hvilket de-anonymiserer disse transaktioner.<\/p>\n

\"Om
\n<\/p>\n

Transaktionsl\u00f8b<\/h4>\n

\nSom vi allerede har n\u00e6vnt, for at skjule sin saldo i account-baserede systemer krypterer brugeren sin saldo og overf\u00f8rselsbel\u00f8b. Samtidig skal han bevise, at saldoen p\u00e5 hans konto forbliver ikke-negativ. Problemet er, at n\u00e5r brugeren danner en transaktion, bygger han beviset p\u00e5 sin nuv\u00e6rende kontostand. Hvad sker der, hvis Bob sender en transaktion til Alice, og den bliver accepteret, f\u00f8r Alices transaktion? S\u00e5 vil Alices transaktion blive betragtet som ugyldig, da beviset for saldoen blev bygget f\u00f8r modtagelsen af Bobs transaktion.<\/p>\n

\"Om
\n
\nDen f\u00f8rste l\u00f8sning, der kommer til at t\u00e6nke p\u00e5 i en s\u00e5dan situation, er at fryse kontoen indtil transaktionen er gennemf\u00f8rt. Men denne tilgang er ikke brugbar, da det, udover kompleksiteten ved at l\u00f8se en s\u00e5dan opgave i et distribueret system, ikke vil v\u00e6re klart, hvis det vil v\u00e6re, hvis vi skal blokere hvilken konto i et anonymt skema.<\/p>\n

For at l\u00f8se dette problem opdeler teknologien indg\u00e5ende og udg\u00e5ende transaktioner: forbruget af midler har en \u00f8jeblikkelig effekt p\u00e5 balance-statussen, mens indbetalinger har en forsinket effekt. Dette introducerer begrebet \"\u00e6ra\" - en gruppe af blokke i fast st\u00f8rrelse. Den aktuelle \"\u00e6ra\" bestemmes ved at dividere blokh\u00f8jden med gruppens st\u00f8rrelse. Ved at behandle en transaktion opdaterer netv\u00e6rket straks afsenderens balance, mens modtagerens midler akkumuleres. De akkumulerede midler er kun tilg\u00e6ngelige for modtageren af betalingen ved starten af en ny \"\u00e6ra\".<\/p>\n

Som et resultat kan brugeren sende transaktioner uanset hvor ofte midlerne tilg\u00e5r (s\u00e5 l\u00e6nge det er inden for hans balance, naturligvis). St\u00f8rrelsen af \u00e6raen bestemmes ud fra, hvor hurtigt blokke spreder sig gennem netv\u00e6rket, og hvor hurtigt en transaktion kommer ind i en blok. <\/p>\n

Denne l\u00f8sning fungerer godt i tilf\u00e6lde af fortrolige overf\u00f8rsler, men med anonyme transaktioner, som vi vil se senere, skaber den alvorlige problemer.<\/p>\n

Beskyttelse mod replay-angreb<\/h4>\n

\nI konto-baserede blokke er hver transaktion underskrevet med afsenderens private n\u00f8gle, hvilket overbeviser verificeren om, at transaktionen ikke er blevet \u00e6ndret, og at den er skabt af ejer af n\u00f8glen. Men hvad hvis en angriber, der lytter til transmissionskanalen, opsnapper denne meddelelse og sender en identisk kopi? Verificeren vil bekr\u00e6fte transaktionens underskrift og v\u00e6re overbevist om dens autenticitet, og netv\u00e6rket vil tr\u00e6kke det samme bel\u00f8b fra afsenderens balance igen.<\/p>\n

Denne type angreb kaldes et replay-angreb. I UTXO-modellen er s\u00e5danne angreb ikke relevante, da angriberen vil fors\u00f8ge at bruge brugte udgange, hvilket i sig selv ikke er gyldigt og afvises af netv\u00e6rket.<\/p>\n

For at undg\u00e5 dette indarbejdes et felt med tilf\u00e6ldige data i transaktionen, som kaldes nonce eller bare \"salt\". Ved gentagen forsendelse af transaktionen med \"salt\" ser verificeren, om denne nonce er blevet brugt tidligere, og hvis ikke, betragter han denne transaktion som gyldig. For ikke at gemme hele historien om brugernes nonces i blokken, antager man normalt, at den f\u00f8rste transaktion har en nonce lig med nul og \u00f8ger den med \u00e9n enhed derefter. Netv\u00e6rket skal blot kontrollere, at nonce for den nye transaktion adskiller sig fra den tidligere med \u00e9n enhed.<\/p>\n

I en anonym overf\u00f8rselsordning opst\u00e5r problemet med validering af nonce-v\u00e6rdierne for transaktioner. Vi kan ikke entydigt knytte nonce til afsenderens adresse, da dette \u00e5benlyst ville de-anonymisere overf\u00f8rslen. Vi kan heller ikke tilf\u00f8re en enhed til nonce for alle involverede konti, da dette kunne konfliktere med andre overf\u00f8rsler, der er under behandling. <\/p>\n

Forfatterne af Zether foresl\u00e5r at generere nonce kryptografisk \u2014 afh\u00e6ngig af \"\u00e6raen\". For eksempel:<\/p>\n

\"Om
\nHer x<\/i><\/b> \u2014 afsenderens hemmelige n\u00f8gle, og Gepoch<\/i><\/b> \u2014 en ekstra generator for epoker, der genereres ved hash af en streng som ‘Zether + ‘. Nu ser problemet ud til at v\u00e6re l\u00f8st \u2014 vi afsl\u00f8rer ikke afsenderens nonce og blander os ikke i nonces for uafh\u00e6ngige deltagere. Men denne tilgang medf\u00f8rer en alvorlig begr\u00e6nsning: \u00e9n konto kan kun sende \u00e9n transaktion i en \"epoke\". Desv\u00e6rre forbliver dette problem ul\u00f8st, og i \u00f8jeblikket g\u00f8r det den anonyme version af Zether, efter vores mening, n\u00e6sten uanvendelig.<\/p>\n

Sv\u00e6rhedsgraden ved null disclosure proofs<\/h4>\n

\nI UTXO skal afsenderen bevise overfor netv\u00e6rket, at han ikke bruger et negativt bel\u00f8b, ellers bliver det muligt at generere nye m\u00f8nter ud af den bl\u00e5 luft (hvorfor det er muligt, har vi skrevet om i en af vores tidligere artikler<\/a><\/noindex>). Og ogs\u00e5 underskrive \"indgange\" med en ringunderskrift for at bekr\u00e6fte, at blandt de blandede m\u00f8nter er der midler, der tilh\u00f8rer ham.<\/p>\n

I den anonyme version af account-based blockchain bliver udtryk for bevis betydeligt mere komplekse. Afsenderen beviser, at:<\/p>\n

    \n
  1. Det sendte bel\u00f8b er positivt;<\/li>\n
  2. Balancen forbliver ikke-negativ;<\/li>\n
  3. Afsenderen har korrekt krypteret bel\u00f8bene for overf\u00f8rsler (herunder nul);<\/li>\n
  4. Balancen \u00e6ndres kun for afsenderen og modtageren;<\/li>\n
  5. Afsenderen ejer den hemmelige n\u00f8gle til sin konto og er faktisk til stede p\u00e5 listen over afsendere (blandt de blandede);<\/li>\n
  6. Nonce, der bruges i transaktionen, er dannet korrekt.<\/li>\n<\/ol>\n

    \nFor et s\u00e5 komplekst bevis bruger forfatterne en blanding Bulletproof<\/a><\/noindex> (en af forfatterne deltog, forresten, i dens udvikling) og Sigma protocol<\/a><\/noindex>, som kaldes Sigma-bullets. Det formelle bevis for en s\u00e5dan p\u00e5stand er en ret kompleks opgave, og det begr\u00e6nser kraftigt antallet af dem, der \u00f8nsker at implementere teknologien.<\/p>\n

    Hvad ender vi med?<\/h4>\n

    \nEfter vores mening kan Zether, der bringer privatliv til account-baserede blockchains, allerede bruges nu. Men i \u00f8jeblikket p\u00e5l\u00e6gger den anonyme version af teknologien betydelige begr\u00e6nsninger for dens anvendelse, og dens kompleksitet p\u00e5virker implementeringen. V\u00e6r dog opm\u00e6rksom p\u00e5, at forfatterne kun har udgivet den for et par m\u00e5neder siden, og m\u00e5ske vil nogen finde l\u00f8sninger p\u00e5 de nuv\u00e6rende problemer. Det er netop s\u00e5dan, videnskab fungerer.
    \n
    Kilde:     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\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\udd47Om anonymitet i account-baserede blockchains | ProHoster","description":"Vi har l\u00e6nge v\u00e6ret interesserede i emnet anonymitet inden for kryptovalutaer og bestr\u00e6ber os p\u00e5 at f\u00f8lge med i udviklingen af teknologier p\u00e5 dette omr\u00e5de.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","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\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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/34101","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=34101"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/34101\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=34101"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=34101"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=34101"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}