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

Vi har lenge v\u00e6rt interessert i anonymitet i kryptovalutaer og pr\u00f8ver \u00e5 f\u00f8lge med p\u00e5 utviklingen av teknologier innen dette feltet. I artiklene v\u00e5re har vi allerede grundig gjennomg\u00e5tt prinsippene for konfidensielle transaksjoner<\/a><\/noindex> i Monero, samt gjennomf\u00f8rt en sammenlignende oversikt<\/a><\/noindex> over teknologier som eksisterer p\u00e5 dette omr\u00e5det. Alle anonyme kryptovalutaer i dag er imidlertid bygget p\u00e5 datamodellen foresl\u00e5tt av Bitcoin \u2013 Unspent Transaction Output (UTXO). For konto-baserte blokkjeder som Ethereum har eksisterende l\u00f8sninger for implementering av anonymitet og konfidensialitet (for eksempel Mobius<\/a><\/noindex> eller Aztec<\/a><\/noindex>) fors\u00f8kt \u00e5 gjenskape UTXO-modellen i smarte kontrakter.<\/p>\n

I februar 2019 publiserte en gruppe forskere fra Stanford University og Visa Research<\/a><\/noindex> har gitt ut et preprint<\/a><\/noindex> \"Zether: P\u00e5 vei mot konfidensialitet i verden av smarte kontrakter\". Forfatterne foreslo for f\u00f8rste gang en tiln\u00e6rming for \u00e5 sikre anonymitet i konto-baserte blokkjeder og presenterte to typer smarte kontrakter: for konfidensielle (skjuling av saldoer og transaksjonsbel\u00f8p) og anonyme (skjuling av mottaker og avsender) transaksjoner. Vi finner den foresl\u00e5tte teknologien interessant og \u00f8nsker \u00e5 dele dens oppbygning, samt diskutere hvorfor anonymitetsproblemet i konto-baserte blokkjeder anses som veldig komplekst og om forfatterne har klart \u00e5 l\u00f8se det fullt ut.<\/p>\n

Om oppbygningen av disse datamodellene<\/h3>\n

\nI UTXO-modellen best\u00e5r en transaksjon av \"innganger\" og \"utganger\". Den direkte analogen til \"utgangene\" er sedler i lommeboken din: hver \"utgang\" har en viss verdi. N\u00e5r du betaler noen (danner en transaksjon), bruker du en eller flere \"utganger\", som deretter blir \"innganger\" i transaksjonen, og blokkjeden markerer dem som brukt. Mottakeren av betalingen din (eller deg selv, hvis du trenger veksling) mottar deretter ny-genererte \"utganger\". Schematiske kan dette illustreres slik:<\/p>\n

\"Om
\n
\nKonto-baserte blokkjeder fungerer omtrent som bankkontoen din. De h\u00e5ndterer bare bel\u00f8pet p\u00e5 kontoen din og overf\u00f8ringsbel\u00f8pet. N\u00e5r du overf\u00f8rer et bel\u00f8p fra kontoen din, brenner du ikke noen \"utganger\"; nettverket trenger ikke \u00e5 huske hvilke mynter som er brukt og hvilke som ikke er. I det enkleste tilfellet reduseres verifiseringen av transaksjonen til \u00e5 kontrollere avsenderens signatur og bel\u00f8pet p\u00e5 saldoen hans:<\/p>\n

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

Analyse av teknologien<\/h3>\n

\nVidare skal vi snakke om hvordan Zether skjuler bel\u00f8pet for transaksjoner, mottaker og avsender. Underveis i beskrivelsen av prinsippene for hvordan det fungerer, vil vi p\u00e5peke forskjellene mellom den konfidensielle og anonyme varianten. Siden det er mye enklere \u00e5 sikre konfidensialitet i konto-baserte blokkjeder, vil noen av begrensningene som p\u00e5legges anonymisering, v\u00e6re irrelevante for den konfidensielle versjonen av teknologien.<\/p>\n

Skjuling av balanse og overf\u00f8ringsbel\u00f8p<\/h4>\n

\nFor kryptering av balanser og overf\u00f8ringsbel\u00f8p i Zether brukes en krypteringsordning ElGamal<\/a><\/noindex>. Den fungerer p\u00e5 f\u00f8lgende m\u00e5te: N\u00e5r Alice \u00f8nsker \u00e5 sende til Bob b<\/b><\/i> mynter til adressen (hans offentlige n\u00f8kkel) Y<\/b><\/i>, velger hun et tilfeldig tall, r<\/b><\/i> og krypterer bel\u00f8pet:<\/p>\n

\"Om
\nder C<\/b><\/i> \u2014 det krypterte bel\u00f8pet, D<\/b><\/i> \u2014 et hjelpeverdi som er n\u00f8dvendig for \u00e5 dekryptere dette bel\u00f8pet, G<\/b><\/i> \u2014 et fast punkt p\u00e5 den elliptiske kurven, n\u00e5r man multipliserer den hemmelige n\u00f8kkelen med, f\u00e5r man den offentlige n\u00f8kkelen.<\/p>\n

N\u00e5r Bob mottar disse verdiene, legger han dem enkelt til sin egen krypterte balanse p\u00e5 samme m\u00e5te, noe som gj\u00f8r ordningen praktisk.<\/p>\n

P\u00e5 samme m\u00e5te trekker Alice de samme verdiene fra sin balanse, men bruker Y<\/b><\/i> sin offentlige n\u00f8kkel.<\/p>\n

Skjuling av mottaker og avsender<\/h4>\n

\nBlandingen av \"utganger\" i UTXO kom frem tidlig i kryptovalutaens utvikling og hjelper med \u00e5 skjule avsenderen. For dette form\u00e5let velger avsenderen tilfeldige \"utganger\" i blokkjeden ved overf\u00f8ringen og blander dem med sine egne. Deretter signerer han \"utgangene\" med en ringegodkjenning \u2014 en kryptografisk mekanisme som gj\u00f8r at kontroll\u00f8ren kan overbevises om at blant de blandede \"utgangene\" finnes mynter fra avsenderen. De blandede myntene blir selvsagt ikke brukt.<\/p>\n

Imidlertid vil det ikke v\u00e6re mulig for \u00e5 skjule mottakeren \u00e5 generere falske \"utganger\". Derfor har hver \"utgang\" i UTXO sin unike adresse, og den er kryptografisk knyttet til mottakerens adresse for disse myntene. Per n\u00e5 finnes det ingen m\u00e5te \u00e5 avdekke forholdet mellom den unike adressen p\u00e5 \"utgangen\" og adressen til mottakeren uten \u00e5 kjenne hans hemmelige n\u00f8kler.<\/p>\n

I account-based modellen kan vi ikke bruke engangsadresser (ellers ville det allerede v\u00e6rt en \u00abutgangs\u00bb-modell). Derfor m\u00e5 mottakeren og avsenderen blandes blant andre kontoer i blokkjeden. I denne prosessen trekkes det krypterte 0 mynter fra de blandede kontoene (eller legges til 0 \u2014 i tilfelle av blanding av mottakeren), uten \u00e5 endre deres reelle saldo.<\/p>\n

Siden b\u00e5de avsender og mottaker alltid har en fast adresse, oppst\u00e5r behovet for \u00e5 bruke de samme gruppene for blanding ved overf\u00f8ringer til de samme adressene. Det er enklest \u00e5 se dette med et eksempel.<\/p>\n

La oss si at Alice \u00f8nsker \u00e5 gi et bidrag til Bob sin veldedige stiftelse, men foretrekker at denne overf\u00f8ringen forblir anonym for en utenforst\u00e5ende observat\u00f8r. For \u00e5 maskere seg selv i avsenderfeltet, legger hun til kontoene til Adam og Adele. For \u00e5 skjule Bob i mottakerfeltet, legger hun ogs\u00e5 til kontoene til Ben og Bill. N\u00e5r Alice gj\u00f8r sitt neste bidrag, bestemmer hun seg for \u00e5 legge til Alex og Amanda ved siden av seg selv, og Bruce og Benjen ved siden av Bob. I dette tilfellet, n\u00e5r man analyserer blokkjeden, vil det kun v\u00e6re ett kryssende par deltakere i disse to transaksjonene \u2014 Alice og Bob, som avdekker disse transaksjonene.<\/p>\n

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

Transaksjonsracing<\/h4>\n

\nSom vi allerede har nevnt, for \u00e5 skjule sin saldo i account-based systemer, krypterer brukeren sin saldo og overf\u00f8ringsbel\u00f8pet. I tillegg m\u00e5 han bevise at saldoen p\u00e5 kontoen hans forblir ikke-negativ. Problemet er at n\u00e5r brukeren lager en transaksjon, bygger han bevis rundt sin n\u00e5v\u00e6rende kontobalanse. Hva skjer hvis Bob sender en transaksjon til Alice, og den blir akseptert f\u00f8r den som Alice sendte? Da vil transaksjonen til Alice bli ansett som ugyldig, fordi beviset p\u00e5 saldoen ble bygget f\u00f8r akseptasjonen av transaksjonen til Bob.<\/p>\n

\"Om
\n
\nDen f\u00f8rste l\u00f8sningen som kommer opp i en slik situasjon, er \u00e5 fryse kontoen til transaksjonen er gjennomf\u00f8rt. Men denne tiln\u00e6rmingen er ikke egnet, fordi, i tillegg til kompleksiteten ved \u00e5 l\u00f8se en slik oppgave i et distribuert system, vil det i en anonym ordning v\u00e6re uklart hvis hvilken konto som skal blokkeres.<\/p>\n

For \u00e5 l\u00f8se dette problemet deler teknologien inn i innkommende og utg\u00e5ende transaksjoner: uttak av midler har umiddelbar effekt p\u00e5 saldoen, mens innskudd er forsinket. Dette innf\u00f8rer begrepet \u00abepoker\u00bb \u2014 grupper av blokker med fast st\u00f8rrelse. Den n\u00e5v\u00e6rende \u00abepoken\u00bb bestemmes ved \u00e5 dele blokkh\u00f8yden med st\u00f8rrelsen p\u00e5 gruppen. N\u00e5r en transaksjon behandles, oppdaterer nettverket senderens saldo umiddelbart, mens midlene til mottakeren legges i en lagringskapsel. De akkumulerte midlene blir tilgjengelig for mottakeren f\u00f8rst n\u00e5r en ny \u00abepoke\u00bb inntreffer.<\/p>\n

Som et resultat kan brukeren sende transaksjoner uavhengig av hvor ofte han mottar midler (s\u00e5 langt som balansen hans tillater selvsagt). St\u00f8rrelsen p\u00e5 epoken bestemmes av hvor raskt blokkene sprer seg i nettverket og hvor raskt en transaksjon kommer inn i en blokk. <\/p>\n

Denne l\u00f8sningen fungerer godt for konfidensielle overf\u00f8ringer, men n\u00e5r det gjelder anonyme transaksjoner, som vi vil se senere, skaper den alvorlige problemer.<\/p>\n

Beskyttelse mot replay-angrep<\/h4>\n

\nI konto-baserte blokkjeder signeres hver transaksjon med senderens private n\u00f8kkel, noe som bekrefter for kontroll\u00f8ren at transaksjonen ikke har blitt endret og at den ble laget av eieren av denne n\u00f8kkelen. Men hva hvis en angriper som overv\u00e5ker overf\u00f8ringskanalen, fanger opp denne meldingen og sender n\u00f8yaktig den samme andre? Kontroll\u00f8ren vil verifisere transaksjonens signatur og v\u00e6re overbevist om dens eierskap, og nettverket vil trekke det samme bel\u00f8pet fra senderens saldo igjen.<\/p>\n

Dette angrepet kalles et replay-angrep. I UTXO-modellen er slike angrep ikke relevante, ettersom angriperen vil fors\u00f8ke \u00e5 bruke allerede brukte utganger, noe som i seg selv ikke er gyldig og blir avvist av nettverket.<\/p>\n

For \u00e5 forhindre dette, integreres et felt med tilfeldige data i transaksjonen, kjent som nonce eller bare \u00absalt\u00bb. Ved en gjentatt sending av transaksjonen med \u00absalt\u00bb, kontrollerer verifisereren om denne nonce tidligere har v\u00e6rt brukt, og hvis ikke, anser denne transaksjonen som gyldig. For \u00e5 unng\u00e5 \u00e5 m\u00e5tte lagre hele historien med brukernes noncer i blokkjeden, aksepteres vanligvis nonce som lik null i den f\u00f8rste transaksjonen, og deretter \u00f8kes det med \u00e9n. Nettverket m\u00e5 bare sjekke at nonce for den nye transaksjonen er forskjellig fra den forrige med \u00e9n.<\/p>\n

I den anonyme overf\u00f8ringsordning oppst\u00e5r problemet med validering av nonce for transaksjoner. Vi kan ikke knytte nonce eksplisitt til avsenders adresse, da dette \u00e5penbart ville de-anonymisere overf\u00f8ringen. Vi kan heller ikke legge til en enhet til nonce for alle involverte kontoer, ettersom dette kan komme i konflikt med andre overf\u00f8ringer som er under behandling. <\/p>\n

Forfatterne av Zether foresl\u00e5r \u00e5 generere nonce kryptografisk \u2014 avhengig av \"\u00e6ra\". For eksempel:<\/p>\n

\"Om
\nHer x<\/i><\/b> \u2014 den hemmelige n\u00f8kkelen til avsenderen, og Gepoch<\/i><\/b> \u2014 en ekstra generator for epoker, oppn\u00e5dd ved \u00e5 hashe strengen 'Zether + '. N\u00e5 ser det ut til at problemet er l\u00f8st \u2014 vi avsl\u00f8rer ikke avsenders nonce og blander oss ikke inn i nonce-ene til involverte parter. Men denne tiln\u00e6rmingen har en alvorlig begrensning: \u00e9n konto kan sende ikke mer enn \u00e9n transaksjon i en \u00abepoke\u00bb. Dette problemet forblir dessverre ul\u00f8st, og for \u00f8yeblikket gj\u00f8r det anonyme Zether-niv\u00e5et, etter v\u00e5r mening, knapt brukbart.<\/p>\n

Vanskeligheten med null-oppl\u00f8sningsbevis<\/h4>\n

\nI UTXO m\u00e5 avsenderen bevise for nettverket at de ikke bruker en negativ sum, ellers blir det mulig \u00e5 generere nye mynter ut av intet (hvorfor dette er mulig, har vi skrevet om i en av de tidligere artiklene<\/a><\/noindex>). Og de m\u00e5 ogs\u00e5 signere \"innganger\" med en ring signatur for \u00e5 bevise at det er midler som tilh\u00f8rer dem blant de blandede myntene.<\/p>\n

I den anonyme versjonen av account-based blokkjeden blir uttrykkene for bevisene mye mer kompliserte. Avsenderen m\u00e5 bevise at:<\/p>\n

    \n
  1. Den sendte summen er positiv;<\/li>\n
  2. Salden forblir ikke-negativ;<\/li>\n
  3. Avsenderen har korrekt kryptert overf\u00f8ringsbel\u00f8pene (inkludert null);<\/li>\n
  4. Saldoen endres kun hos avsenderen og mottakeren;<\/li>\n
  5. Avsenderen eier den hemmelige n\u00f8kkelen til kontoen sin, og den er faktisk p\u00e5 listen over sendere (blant de blandede);<\/li>\n
  6. Nonce brukt i transaksjonen er korrekt sammensatt.<\/li>\n<\/ol>\n

    \nFor s\u00e5 komplekse bevis bruker forfatterne en blanding Kulepunkter<\/a><\/noindex> (en av forfatterne har forresten deltatt i utviklingen av dette) og Sigma-protokollen<\/a><\/noindex>, som de kaller Sigma-bullets. Det formelle beviset for et slikt utsagn er en ganske komplisert oppgave, og det begrenser sterkt antall som \u00f8nsker \u00e5 implementere teknologien.<\/p>\n

    Hva ble resultatet?<\/h4>\n

    \nEtter v\u00e5rt syn kan delen av Zether som bringer personvern til konto-baserte blokkjeder, absolutt brukes allerede n\u00e5. Men for \u00f8yeblikket p\u00e5legger den anonyme versjonen av teknologien betydelige begrensninger p\u00e5 bruken, og dens kompleksitet p\u00e5virker implementeringen. Det er imidlertid verdt \u00e5 huske p\u00e5 at forfatterne kun har lansert den for noen m\u00e5neder siden, og kanskje noen andre vil finne l\u00f8sninger p\u00e5 de utfordringene som eksisterer i dag. Tross alt er det nettopp slik vitenskap 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 konto-baserte blokkjeder | ProHoster","description":"Vi har lenge v\u00e6rt interessert i anonymitet i kryptovalutaer og pr\u00f8ver \u00e5 holde oss oppdatert p\u00e5 utviklingen av teknologiene innen dette feltet.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","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\/no\/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\/no\/wp-json\/wp\/v2\/posts\/34101","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=34101"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/34101\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=34101"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=34101"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=34101"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}