{"id":33888,"date":"2019-10-31T21:55:15","date_gmt":"2019-10-31T18:55:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\/"},"modified":"2019-10-31T21:55:15","modified_gmt":"2019-10-31T18:55:15","slug":"sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","title":{"rendered":"Tilf\u00e6ldige tal og decentrale netv\u00e6rk: implementeringer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<h1 id=\"vvedenie\">Introduktion<\/h1>\n<p><\/p>\n<pre><code class=\"plaintext\">funktion getAbsolutelyRandomNumer() {\n        return 4; \/\/ returnerer et absolut tilf\u00e6ldigt tal!\n}<\/code><\/pre>\n<p><\/p>\n<p>Ligesom med konceptet for absolut sikre koder fra kryptografi, fors\u00f8ger de virkelige protokoller \"Publicly Verifiable Random Beacon\" (herefter PVRB) kun at n\u00e6rme sig den ideelle model, da den i ren form ikke er anvendelig i virkelige netv\u00e6rk: der skal udelukkende aftales en enkelt bit, der skal v\u00e6re mange runder, og alle meddelelser skal v\u00e6re ekstremt hurtige og altid leveres. Naturligvis er dette ikke tilf\u00e6ldet i virkelige netv\u00e6rk. Derfor opst\u00e5r der mange arkitektoniske og tekniske problemer ved design af PVRB til specifikke opgaver i moderne blockchain, oven i muligheden for at kontrollere den modtagne tilf\u00e6ldighed og den kryptografiske modstandskraft.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Selve blockchainen fungerer som en kommunikationsplatform for PVRB, hvor meddelelser = transaktioner. Dette muligg\u00f8r en delvis abstrahering fra netv\u00e6rksproblemer, manglende meddelelser, og problemer med mellemsoftwaren \u2014 alle disse risici p\u00e5tager det decentraliserede netv\u00e6rk sig, og dens v\u00e6sentligste v\u00e6rdi for PVRB er umuligheden af at tilbagekalde eller \u00f8del\u00e6gge en allerede sendt transaktion \u2014 det forhindrer deltagerne i at tr\u00e6kke sig fra protokollen, medmindre de har udf\u00f8rt et vellykket angreb p\u00e5 konsensus. Dette sikkerhedsniveau er acceptabelt, hvorfor PVRB skal v\u00e6re modstandsdygtig over for konspirering blandt deltagerne i samme grad som den prim\u00e6re blockchain. Det antyder ogs\u00e5, at PVRB skal v\u00e6re en del af konsensus, hvis netv\u00e6rket har enighed om den prim\u00e6re blokk\u00e6de, s\u00e5 m\u00e5 det ogs\u00e5 finde enighed om en enkelt \u00e6rlig resultat tilf\u00e6ldighed. Alternativt kan PVRB v\u00e6re en simpel selvst\u00e6ndig protokol implementeret ved hj\u00e6lp af en smart kontrakt, der fungerer asynkront i forhold til blockchainen og blokkene. Begge metoder har deres fordele og ulemper, og valget mellem dem er s\u00e6rdeles komplekst. <\/p>\n<p><\/p>\n<h2 id=\"dva-sposoba-implementacii-pvrb\">To metoder til implementering af PVRB<\/h2>\n<p><\/p>\n<p>Lad os se n\u00e6rmere p\u00e5 to varianter af implementeringen af PVRB \u2014 en selvst\u00e6ndig version, der anvender en blockchain-uafh\u00e6ngig smart kontrakt, og en consensus-integreret version \u2014 indbygget i protokollen, hvorefter netv\u00e6rket n\u00e5r til enighed om blokk\u00e6den og inkluderede transaktioner. I alle tilf\u00e6lde vil jeg have in mente popul\u00e6re blockchain-motorer: Ethereum, EOS, og alle der ligner dem med hensyn til m\u00e5de at implementere og behandle smart kontrakter. <\/p>\n<p><\/p>\n<h3 id=\"standalone-contract\">Standalone kontrakt<\/h3>\n<p><\/p>\n<p>I denne version fungerer PVRB som en smart kontrakt, der modtager transaktioner fra random-producenter (herefter RP), behandler dem, kombinerer resultaterne og n\u00e5r et v\u00e6rdiniveau, som enhver bruger kan f\u00e5 fra denne kontrakt. Denne v\u00e6rdi beh\u00f8ver ikke at v\u00e6re gemt direkte i kontrakten, men kan kun pr\u00e6senteres gennem data, hvilket muligg\u00f8r en entydig bestemmelse af det resulterende tilf\u00e6ldige tal. I dette skema er RP brugere af blockchainen, og enhver kan f\u00e5 lov til at deltage i genereringen af tal.<\/p>\n<p><\/p>\n<p>Standalone kontrakt er god:<\/p>\n<p><\/p>\n<ul>\n<li>b\u00e6rbarhed (kontrakter kan flyttes fra blockchain til blockchain)<\/li>\n<li>simpel implementering og testning (det er nemt at skrive og teste kontrakter)<\/li>\n<li>bekvemmelighed i implementering af \u00f8konomiske ordninger (det er let at oprette sin egen token, hvis logik tjener PVRB's form\u00e5l)<\/li>\n<li>muligheden for at k\u00f8re i allerede eksisterende blockchains<\/li>\n<\/ul>\n<p><\/p>\n<p>Men den har ogs\u00e5 ulemper:<\/p>\n<p><\/p>\n<ul>\n<li>store begr\u00e6nsninger p\u00e5 ressourcer ved beregninger, transaktionsvolumen og opbevaring (kort sagt cpu\/mem\/io)<\/li>\n<li>begr\u00e6nsninger p\u00e5 operationer inden for kontrakten (ikke alle instruktioner er tilg\u00e6ngelige, det er vanskeligt at tilslutte eksterne biblioteker)<\/li>\n<li>umulighed af at organisere beskedudveksling hurtigere, end transaktioner bliver inkluderet i blockchainen<\/li>\n<\/ul>\n<p><\/p>\n<p>Denne version er egnet til implementering af PVRB, som skal k\u00f8res i et allerede eksisterende netv\u00e6rk, ikke indeholder kompleks kryptografi og ikke kr\u00e6ver mange interaktioner.<\/p>\n<p><\/p>\n<h3 id=\"consensus-integrated\">Consensus-integreret<\/h3>\n<p><\/p>\n<p>I denne variant er PVRB implementeret i koden til blockchain-noden, indbygget eller fungerer parallel med meddelelsesudvekslingen mellem blockchain-noderne. Resultaterne af protokollen registreres direkte i de producerede blokke, og protokolmeddelelser sendes over p2p-netv\u00e6rket mellem noderne. Da protokollen resulterer i tal, som skal registreres i blokkene, skal netv\u00e6rket n\u00e5 til enighed om dem. Dette betyder, at PVRB-meddelelser, ligesom transaktioner, skal valideres af noderne og inkluderes i blokkene, s\u00e5 enhver deltager i netv\u00e6rket kan validere overholdelsen af PVRB-protokollen. Dette f\u00f8rer os automatisk til den \u00e5benlyse l\u00f8sning \u2014 hvis netv\u00e6rket indg\u00e5r enighed om en blok og transaktionerne heri, skal PVRB v\u00e6re en del af enigheden og ikke en separat protokol. Ellers kan der opst\u00e5 en situation, hvor blokken er gyldig set fra enighedens perspektiv, men PVRB-protokollen ikke er overholdt, og fra PVRB's perspektiv kan blokken ikke accepteres. S\u00e5 hvis den \u201cconsensus-integrated\u201d mulighed v\u00e6lges, bliver PVRB en vigtig del af enigheden.<\/p>\n<p><\/p>\n<p>N\u00e5r man beskriver implementeringer af PVRB p\u00e5 enighedsniveau i netv\u00e6rket, m\u00e5 man p\u00e5 ingen m\u00e5de undg\u00e5 sp\u00f8rgsm\u00e5lene om endelighed. Endelighed er en mekanisme, der anvendes i deterministiske konsensusmodeller, som fasts\u00e6tter en blok (og k\u00e6den, der f\u00f8rer til den), der er endelig, og som aldrig vil blive kastet v\u00e6k, selvom der opst\u00e5r en parallel gaffel. For eksempel har Bitcoin ikke en s\u00e5dan mekanisme \u2014 hvis der offentligg\u00f8res en k\u00e6de med st\u00f8rre kompleksitet, vil den erstatte enhver mindre kompleks, uanset k\u00e6dets l\u00e6ngde. I EOS er de endelige blokke s\u00e5kaldte Last Irreversible Blocks, der vises i gennemsnit hver 432 blokke (12*21 + 12*15, pre-vote + pre-commit). Denne proces handler i bund og grund om at vente p\u00e5 2\/3 af underskrifterne fra block-producerne (BP). N\u00e5r der opst\u00e5r gafler, der er \u00e6ldre end den seneste LIB, bliver de blot forkastet. Denne mekanisme g\u00f8r det muligt at garantere, at transaktionen er inkluderet i blockchainen og aldrig vil blive tilbagef\u00f8rt, uanset hvilke ressourcer angriberen m\u00e5tte have. Desuden er endelige blokke dem, der er underskrevet af 2\/3 af BP i Hyperledger, Tendermint og andre pBFT-baserede konsensusmodeller. Derudover giver det mening at lave en protokol for at sikre endelighed som en overbygning ovenp\u00e5 konsensus, da den kan fungere asynkront med produktionen og offentligg\u00f8relsen af blokke. Her er en god <noindex><a rel=\"nofollow\" href=\"https:\/\/arxiv.org\/pdf\/1710.09437.pdf\">artikel<\/a><\/noindex> om finalitet i Ethereum.<\/p>\n<p><\/p>\n<p>Finalitet er ekstremt vigtig for brugerne, der uden den kan blive ofre for en \"double spend\"-angreb, hvor BP \"holder\" blokke, og offentligg\u00f8r dem efter at netv\u00e6rket \"har set\" en god transaktion. Hvis der ikke er nogen finalitet, s\u00e5 erstatter den offentliggjorte fork blokken med den \"gode\" transaktion med en anden fra den \"d\u00e5rlige\" fork, hvor de samme midler overf\u00f8res til angriberens adresse. I tilf\u00e6lde af PVRB bliver kravene til finalitet endnu strammere, da opbygning af forks for PVRB giver angriberen mulighed for at forberede flere tilf\u00e6ldige varianter for at offentligg\u00f8re den mest fordelagtige for ham og begr\u00e6nse muligt angrebstid \u2014 en god l\u00f8sning.<\/p>\n<p><\/p>\n<p>Derfor er den bedste mulighed at kombinere PVRB og finalitet i \u00e9n protokol \u2014 s\u00e5 bliver den finaliserede blok = den finaliserede tilf\u00e6ldighed, og det er pr\u00e6cis, hvad der skulle opn\u00e5s. Nu vil spillerne f\u00e5 garanteret tilf\u00e6ldighed inden for N sekunder og kan v\u00e6re sikre p\u00e5, at det hverken kan rulles tilbage eller spilles igen.<\/p>\n<p><\/p>\n<p>Muligheden med consensus-integreret er god:<\/p>\n<p><\/p>\n<ul>\n<li>muligheden for asynkron implementering i forhold til blokkens produktion \u2014 blokke produceres som s\u00e6dvanligt, men parallelt med dette kan PVRB-protokollen fungere, som producerer tilf\u00e6ldigheder ikke for hver blok<\/li>\n<li>muligheden for at implementere selv tung kryptografi uden de begr\u00e6nsninger, der p\u00e5l\u00e6gges smarte kontrakter<\/li>\n<li>muligheden for at organisere hurtigere meddelelser end transaktioner, der inkluderes i blockchain, for eksempel kan en del af protokollen fungere mellem noder uden at sprede meddelelser over netv\u00e6rket<\/li>\n<\/ul>\n<p><\/p>\n<p>Men den har ogs\u00e5 ulemper:<\/p>\n<p><\/p>\n<ul>\n<li>vanskeligheder ved testning og udvikling \u2014 det bliver n\u00f8dvendigt at emulere netv\u00e6rksfejl, forsvundne noder, hard forks i netv\u00e6rket<\/li>\n<li>fejl i implementeringen kr\u00e6ver en hard fork af netv\u00e6rket<\/li>\n<\/ul>\n<p><\/p>\n<p>Begge m\u00e5der at implementere PVRB p\u00e5 har ret til at eksistere, men implementeringen p\u00e5 smarte kontrakter i moderne blockchains er stadig ret begr\u00e6nset i beregningsressourcer, og enhver overgang til seri\u00f8s kryptografi er ofte simpelthen umulig. Og vi har brug for seri\u00f8s kryptografi, som vil blive demonstreret senere. Selvom dette problem er tydeligt midlertidigt, er seri\u00f8s kryptografi i kontrakter n\u00f8dvendig for at l\u00f8se mange opgaver, og den dukker gradvist op (for eksempel systemkontrakter til zkSNARKs i Ethereum)<\/p>\n<p><\/p>\n<p>Blockchain, der sikrer et gennemsigtigt og p\u00e5lideligt kommunikationskanal for protokollen, er ikke gratis. Enhver decentraliseret protokol skal tage h\u00f8jde for muligheden for Sybil-angreb, da enhver handling kan udf\u00f8res af en sammensv\u00e6rgelse af flere konti. Derfor er det vigtigt at overveje angribernes muligheder for at skabe et vilk\u00e5rligt antal deltagere i protokollen, der handler i samr\u00e5d. <\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-peremennye-bloka\">PVRB og blokvariabler.<\/h2>\n<p><\/p>\n<p>Jeg l\u00f8j ikke, da jeg sagde, at der ikke eksisterer et godt PVRB, valideret af mange gambling-applikationer, i blockchainer. Hvordan kan der s\u00e5 v\u00e6re s\u00e5 mange gambling-applikationer i Ethereum og EOS? Dette overrasker mig lige s\u00e5 meget som dig. Hvordan kan man finde s\u00e5 mange \"modstandsdygtige\" tilf\u00e6ldigheder i et fuldst\u00e6ndig deterministisk milj\u00f8?<\/p>\n<p><\/p>\n<p>En popul\u00e6r metode til at hente tilf\u00e6ldighed i blockchainen er at tage en eller anden \"uventet\" information fra blokken og bruge den som basis for randomisering, blot ved at hashe en eller flere v\u00e6rdier. En god artikel om problemerne ved s\u00e5danne ordninger. <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.positive.com\/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620\">her<\/a><\/noindex>Man kan tage en hvilken som helst af de \"uventede\" v\u00e6rdier i blokken, s\u00e5som blokhash, antal transaktioner, netv\u00e6rkets sv\u00e6rhedsgrad og andre, ukendte p\u00e5 forh\u00e5nd v\u00e6rdier. Derefter kan man hash dem, en eller flere, og i teorien burde det resultere i \u00e6gte tilf\u00e6ldighed. Man kan endda tilf\u00f8je i hvidbogen, at ens skema er \"post-quantum secure\" (da der findes kvante-sikre hash-funktioner :)).<\/p>\n<p><\/p>\n<p>Men selv post-quantum sikre hashes er desv\u00e6rre ikke nok. Hemmeligheden ligger i kravene til PVRB, som jeg mindede om i den tidligere artikel:<\/p>\n<p><\/p>\n<ol>\n<li>Resultatet skal have en beviseligt ensartet fordeling, dvs. baseret p\u00e5 beviseligt robust kryptografi.<\/li>\n<li>Ingen af bits i resultatet kan kontrolleres. Som f\u00f8lge heraf kan resultatet ikke forudses p\u00e5 forh\u00e5nd.<\/li>\n<li>Man kan ikke saboterer protokollet til generering ved at undlade at deltage i protokollet eller ved at overbelaste netv\u00e6rket med angribermeddelser.<\/li>\n<li>Alt det ovenst\u00e5ende skal v\u00e6re modstandsdygtigt over for sammensv\u00e9rgelser fra et acceptabelt antal u\u00e6rlige deltagere i protokollen (f.eks. 1\/3 af deltagerne).<\/li>\n<\/ol>\n<p><\/p>\n<p>I dette tilf\u00e6lde overholdes kun krav 1, og krav 2 overholdes ikke. Ved at hash'e uforudsigelige v\u00e6rdier fra blokken opn\u00e5r vi en j\u00e6vn fordeling og gode randomiseringer. Men BP har i det mindste muligheden for \"at offentligg\u00f8re blokken eller ej\". Dermed kan BP i det mindste v\u00e6lge mellem TO randomiseringsmuligheder: \"sin egen\" og den, som vil komme, hvis blokken offentligg\u00f8res af en anden part. BP kan p\u00e5 forh\u00e5nd \"kigge ind\", hvad der vil ske, hvis han offentligg\u00f8r blokken, og s\u00e5 tr\u00e6ffe en beslutning om at g\u00f8re det eller ej. Dermed kan han for eksempel i et spil \"lige-ulige\" eller \"r\u00f8d\/sort\" i roulette kun offentligg\u00f8re blokken, hvis han ser en gevinst. Dette g\u00f8r ogs\u00e5 strategien med at bruge for eksempel blokkens hash \"fra fremtiden\" ineffektiv. I dette tilf\u00e6lde siges det, at \"der vil blive brugt en randomisering, som opn\u00e5s ved hash'ing af de aktuelle data og hashen af den fremtidige blok med h\u00f8jden, for eksempel N + 42, hvor N er den nuv\u00e6rende blokh\u00f8jde. Det styrker lidt ordningen, men tillader stadig BP, om end i fremtiden, at v\u00e6lge at tilbageholde blokken eller offentligg\u00f8re den.<\/p>\n<p><\/p>\n<p>BP-softwaren kompliceres en smule i dette tilf\u00e6lde, men ikke voldsomt. Under valideringen og inkluderingen af transaktionen i blokken foretages en hurtig kontrol for at se, om der vil v\u00e6re en gevinst, og muligvis justerer en transaktionsparameter for at opn\u00e5 en h\u00f8jere sandsynlighed for gevinst. Derudover er det n\u00e6sten umuligt at fange en smart BP i s\u00e5danne manipulationer; man kan hver gang bruge nye adresser og vinde sm\u00e5 gevinster uden at v\u00e6kke mistanke.<\/p>\n<p><\/p>\n<p>Derfor egner metoder, der anvender information fra blokken, sig ikke til en universel implementering af PVRB. I en begr\u00e6nset version, med begr\u00e6nsninger p\u00e5 indsatsst\u00f8rrelser, begr\u00e6nsninger p\u00e5 antallet af spillere og\/eller KYC-registrering (for at forhindre \u00e9n spiller i at bruge flere adresser), kan disse ordninger fungere til sm\u00e5 spil, men ikke mere.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-commit-reveal\">PVRB og commit-reveal.<\/h2>\n<p><\/p>\n<p>Okay, tak til hashing og i det mindste den relative uforudsigelighed af blokhashen og andre variable. Hvis vi l\u00f8ser problemet med front-running fra minearbejderne, burde der komme noget, der er mere holdbart. Lad os tilf\u00f8je brugerne til denne ordning \u2014 lad dem ogs\u00e5 p\u00e5virke randomiseringen: enhver medarbejder i teknisk support vil fort\u00e6lle dig, at det mest randomiserede i IT-systemer er brugernes handlinger \ud83d\ude42<\/p>\n<p><\/p>\n<p>Den naive metode, hvor brugerne bare sender tilf\u00e6ldige tal, og resultatet beregnes som for eksempel hashen af deres sum, er ikke god. I dette tilf\u00e6lde kan den sidste spiller, ved at v\u00e6lge sin egen tilf\u00e6ldige v\u00e6rdi, kontrollere hvilket resultat der vil komme. Derfor bruges m\u00f8nsteret commit-reveal, der er meget udbredt. Deltagerne sender f\u00f8rst hasher af deres tilf\u00e6ldige tal (commits), og derefter afsl\u00f8rer de de faktiske v\u00e6rdier (reveals). Fasen 'reveal' begynder f\u00f8rst, n\u00e5r de n\u00f8dvendige commits er indsamlet, s\u00e5 deltagerne kan sende pr\u00e6cist den tilf\u00e6ldige v\u00e6rdi, hvis hash de har sendt tidligere. Nu kan vi kombinere alt dette med blokkens parametre, helst taget fra fremtiden (den tilf\u00e6ldige v\u00e6rdi vil f\u00f8rst kunne kendt i en af fremtidens blokke), og voila \u2014 den tilf\u00e6ldige v\u00e6rdi er klar! Nu kan enhver spiller p\u00e5virke det endelige resultat, og kan 'vinde' over den ondsindede BP ved at d\u00e6kke hans tilf\u00e6ldige tal med sin egen, som ikke er kendt p\u00e5 forh\u00e5nd\u2026 Desuden kan vi tilf\u00f8je beskyttelse mod sabotering af protokollen ved at undg\u00e5 at afsl\u00f8re under reveal-fasen \u2014 blot ved at kr\u00e6ve, at der ved commit sendes et bel\u00f8b \u2014 en sikkerhedsdepot, som kun returneres ved reveal-processen. I s\u00e5 fald vil det ikke v\u00e6re fordelagtigt at lave en commit og ikke lave en reveal.<\/p>\n<p><\/p>\n<p>Det var et godt fors\u00f8g, og s\u00e5danne ordninger findes ogs\u00e5 i spil-DApp'er, men desv\u00e6rre er det stadig ikke tilstr\u00e6kkeligt. Nu kan resultatet p\u00e5virkes ikke kun af minearbejderen, men ogs\u00e5 af enhver deltager i protokollen. Man kan stadig kontrollere selve v\u00e6rdien, med en lavere grad af variabilitet og mod betaling, men som i tilf\u00e6ldet med minearbejderen, hvis resultaterne af lodtr\u00e6kningen er mere v\u00e6rdifulde end gebyret for at deltage i PVRB-protokollen, s\u00e5 kan random-producer (RP) beslutte, om han vil afsl\u00f8re sin v\u00e6rdi og kan stadig v\u00e6lge mellem mindst to muligheder for en tilf\u00e6ldig v\u00e6rdi.<br \/>\nDer er dog mulighed for at straffe dem, der laver en commit og ikke laver en reveal, og denne ordning vil v\u00e6re nyttig. Dens enkelhed er en stor fordel \u2014 mere komplekse protokoller kr\u00e6ver langt mere kraftige beregninger.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-determinirovannye-podpisi\">PVRB og deterministiske signaturer.<\/h2>\n<p><\/p>\n<p>Der er en anden m\u00e5de at f\u00e5 RP til at levere et pseudotilf\u00e6ldigt tal, som han ikke kan p\u00e5virke, hvis han pr\u00e6senteres for en \"prototype\" - det er en deterministisk signatur. En s\u00e5dan signatur er for eksempel RSA, men ikke ECS. Hvis RP har et n\u00f8glepar: RSA og ECV, og han underskriver en v\u00e6rdi med sin private n\u00f8gle, s\u00e5 f\u00e5r han i tilf\u00e6lde af RSA \u00c9N OG KUN \u00c9N signatur, mens han i tilf\u00e6lde af ECS kan generere et vilk\u00e5rligt antal forskellige gyldige signaturer. Dette skyldes, at der ved oprettelsen af en ECS-signatur bruges et tilf\u00e6ldigt tal, valgt af den, der underskriver, og det kan v\u00e6lges p\u00e5 mange m\u00e5der, hvilket giver den signerende mulighed for at v\u00e6lge en af flere signaturer. I tilf\u00e6lde af RSA: \"\u00e9n inputv\u00e6rdi\" + \"\u00e9t n\u00f8glepar\" = \"\u00e9n signatur\". Det er ikke muligt at forudsige, hvilken signatur der vil blive genereret af en anden RP, derfor kan PVRB med deterministiske signaturer organiseres ved at kombinere RSA-signaturer fra flere deltagere, der har underskrevet den samme v\u00e6rdi. For eksempel - den forrige tilf\u00e6ldighed. I s\u00e5dan et system spares der mange ressourcer, da signaturerne fungerer b\u00e5de som en bekr\u00e6ftelse af korrekt adf\u00e6rd i henhold til protokollen og som en kilde til tilf\u00e6ldighed.<\/p>\n<p><\/p>\n<p>Selvom der stadig er deterministiske signaturer, er ordningen stadig s\u00e5rbar over for \"last actor\"-problemet. Den sidste deltager kan stadig beslutte, om han vil offentligg\u00f8re sin signatur eller ej, og dermed kontrollere resultatet. Man kan optimere ordningen, tilf\u00f8je hashes af blokke, lave runder for at forhindre forudsigelighed af resultatet, men alle disse tilgange, selv med mange forbedringer, efterlader stadig problemet med \u00e9n deltagers indflydelse p\u00e5 det kollektive resultat i et usikkert milj\u00f8, og de kan kun fungere under \u00f8konomiske og tidsm\u00e6ssige begr\u00e6nsninger. Desuden er st\u00f8rrelsen af RSA-n\u00f8glerne (1024 og 2048 bit) ret stor, mens st\u00f8rrelsen for blockchain-transaktioner er en ekstremt vigtig parameter. Det ser ud til, at problemet ikke kan l\u00f8ses enkelt, lad os g\u00e5 videre.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-secret-sharing-shemy\">PVRB og hemmelig delingsskemaer<\/h2>\n<p><\/p>\n<p>I kryptografi findes der ordninger, der kan lade et netv\u00e6rk blive enige om \u00e9n og kun \u00e9n v\u00e6rdi af PVRB, samtidig med at s\u00e5danne ordninger er modstandsdygtige over for enhver ondsindet adf\u00e6rd fra dele af deltagerne. Et nyttigt protokol at kendskab til er Shamir's hemmelighedsdeling. Det bruges til at dele en hemmelighed (for eksempel en hemmelig n\u00f8gle) op i flere dele og distribuere disse dele til N deltagere. Hemmeligheden fordeles p\u00e5 en m\u00e5de, s\u00e5 man kun har brug for M dele ud af N for at genoprette den, hvor M kan v\u00e6re hvilke som helst dele. For at forklare det enkelt, s\u00e5 deltagerne udveksler punkter p\u00e5 grafen for en ukendt funktion, og efter at have modtaget M punkter, kan hele funktionen genskabes.<br \/>\nEn god forklaring findes i <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Shamir%27s_Secret_Sharing\">wiki<\/a><\/noindex> og det er praktisk at lege med det for at f\u00e5 protokollen til at give mening i hovedet p\u00e5 <noindex><a rel=\"nofollow\" href=\"http:\/\/point-at-infinity.org\/ssss\/demo.html\">demo<\/a><\/noindex> siden.<\/p>\n<p><\/p>\n<p>Hvis FSSS (Fiat-Shamir Secret Sharing) ordningen kunne anvendes i sin reneste form \u2014 ville det v\u00e6re en uovervindelig PVRB. I det enkleste tilf\u00e6lde kan protokollen se s\u00e5ledes ud:<\/p>\n<p><\/p>\n<ul>\n<li>Hver deltager genererer sin egen tilf\u00e6ldige tal og distribuerer andele af det til de andre deltagere<\/li>\n<li>Hver deltager afsl\u00f8rer sin del af de andre deltageres hemmeligheder<\/li>\n<li>Hvis en deltager har indsamlet mere end M andele, kan denne deltageres nummer beregnes, og det vil v\u00e6re unikt, uanset hvilke deltagere der afsl\u00f8res<\/li>\n<li>Kombinationen af de afsl\u00f8rede tilf\u00e6ldige tal er den eftertragtede PVRB<\/li>\n<\/ul>\n<p><\/p>\n<p>Her p\u00e5virker en enkelt deltager ikke resultaterne af protokollen, undtagen i de tilf\u00e6lde, hvor det kun afh\u00e6nger af ham at opn\u00e5 t\u00e6rsklen for afsl\u00f8ret random. Derfor fungerer denne protokol, s\u00e5 l\u00e6nge der er en n\u00f8dvendig andel af deltagere, der arbejder iht. protokollen og tilg\u00e6ngelige RP, og opfylder kravene til kryptografisk sikkerhed, samtidig med at den er modstandsdygtig over for \"last actor\"-problemet.<\/p>\n<p><\/p>\n<p>Det kunne v\u00e6re den ideelle l\u00f8sning, denne PVRB-ordning baseret p\u00e5 Fiat-Shamir hemmelighedsdeling er beskrevet, for eksempel i <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2017\/216.pdf\">denne<\/a><\/noindex> artiklen. Men, som n\u00e6vnt tidligere, hvis man fors\u00f8ger at anvende den direkte p\u00e5 blockchain, opst\u00e5r der tekniske begr\u00e6nsninger. Her er et eksempel p\u00e5 en testimplementering af protokollen i EOS smart contracten og dens mest centrale del \u2014 kontrollen af den offentliggjorte andel af deltageren: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/mixbytes\/eoscraper\/blob\/master\/Proof.hh#L23\">koden<\/a><\/noindex>. Koden viser, at valideringen af proof kr\u00e6ver flere skalar multiplikationer, og tallene der bruges er meget store. Man skal forst\u00e5, at i blockchain-erne sker verifikation p\u00e5 det tidspunkt, hvor block-produceren processerer transaktionen, og enhver deltager skal let kunne verificere korrektheden af protokollen, derfor er kravene til hastigheden af verifikationsfunktionen meget strenge. I denne version viste sig varianten at v\u00e6re uarbejdsdygtig, da verifikationen ikke kunne gennemf\u00f8res inden for transaktionsgr\u00e6nsen (0,5 sek).<\/p>\n<p><\/p>\n<p>Effektiviteten af verifikation er et af de vigtigste krav til brugen af n\u00e6sten enhver avanceret kryptografisk ordning i blockchain. Oprettelse af proofs, forberedelse af meddelelser - disse procedurer kan udf\u00f8res off-chain og k\u00f8res p\u00e5 h\u00f8jtydende computere, men verifikation kan ikke undg\u00e5s - det er et andet vigtigt krav til PVRB. <\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-threshold-signatures\">PVRB og threshold-signaturer<\/h2>\n<p><\/p>\n<p>Efter at have gjort os bekendt med secret sharing-ordningen, \u00e5bnede vi for en hel klasse af protokoller, der er samlet under n\u00f8gleordet \u201cthreshold\u201d. N\u00e5r afsl\u00f8ringen af visse oplysninger kr\u00e6ver deltagelse af M \u00e6rlige deltagere ud af N, og s\u00e6ttet af \u00e6rlige deltagere kan v\u00e6re et vilk\u00e5rligt delm\u00e6ngde af N, taler man om \u201cthreshold\u201d ordninger. Det er netop dem, der g\u00f8r det muligt at l\u00f8se problemet med \u201csidste akt\u00f8r\u201d, nu hvis angriberen ikke afsl\u00f8rer sin del af hemmeligheden, vil en anden \u00e6rlig deltager g\u00f8re det. Disse ordninger g\u00f8r det muligt at blive enige om \u00e9n og kun \u00e9n v\u00e6rdi, selv ved saboterende opf\u00f8rsel fra en del af deltagerne. <\/p>\n<p><\/p>\n<p>Sammenkoblingen af determinerede signaturer og threshold-ordninger har gjort det muligt at udvikle en meget praktisk og lovende ordning til implementering af PVRB - det er de determinerede threshold-signaturer. Her <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2002\/081.pdf\">artikel<\/a><\/noindex> om forskellige anvendelser af threshold-signaturer, og her er en god <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.dash.org\/secret-sharing-and-threshold-signatures-with-bls-954d1587b5f\">longread<\/a><\/noindex> fra Dash. <\/p>\n<p><\/p>\n<p>I den sidste artikel beskrives BLS-signaturer (BLS st\u00e5r for Boneh-Lynn-Shacham, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.iacr.org\/archive\/asiacrypt2001\/22480516.pdf\">her<\/a><\/noindex> Den artikel, som har en meget vigtig og yderst praktisk kvalitet for programm\u00f8rer \u2014 offentlige, hemmelige, offentlige n\u00f8gler og BLS-signaturer kan kombineres med hinanden ved hj\u00e6lp af enkle matematiske operationer, samtidig med at deres kombinationer forbliver gyldige n\u00f8gler og signaturer, hvilket muligg\u00f8r nem aggregasjon af mange signaturer til \u00e9n og mange offentlige n\u00f8gler til \u00e9n. De har ogs\u00e5 determinisme og giver det samme resultat p\u00e5 de samme inputdata. Takket v\u00e6re denne egenskab er kombinationer af BLS-signaturer selv gyldige n\u00f8gler, hvilket muligg\u00f8r et scenario, hvor M ud af N deltagere producerer \u00e9n og kun \u00e9n signatur, der er deterministisk, offentligt verificerbar og uforudsigelig, indtil den afsl\u00f8res af den M-te deltager.<\/p>\n<p><\/p>\n<p>I ordningen med threshold BLS-signaturer underskriver hver deltager med BLS noget (for eksempel den tidligere tilf\u00e6ldige v\u00e6rdi), og den samlede threshold-signatur er den \u00f8nskede tilf\u00e6ldige v\u00e6rdi. De kryptografiske egenskaber ved BLS-signaturer opfylder kravene til kvaliteten af tilf\u00e6ldige v\u00e6rdier, threshold-delen beskytter mod \u201clast-actor\u201d, og den unikke kombinerbarhed af n\u00f8gler muligg\u00f8r implementering af mange interessante algoritmer, som for eksempel effektivt kan aggregere meddelelser i protokollen.<\/p>\n<p><\/p>\n<p>S\u00e5 hvis du bygger PVRB i din blockchain, vil du med stor sandsynlighed ende med en ordning med BLS-threshold-signaturer; den anvendes allerede af flere projekter. For eksempel DFinity (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dfinity\/random-beacon\">her<\/a><\/noindex> benchmarket, der implementerer ordningen, og <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dfinity\/vss\/blob\/master\/docs\/index.md\">her<\/a><\/noindex> et eksempel p\u00e5 implementeringen af verificerbar hemmelig deling), eller Keep.network (her er deres tilf\u00e6ldige beacon <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/keep-network\/random-beacon-yellowpaper\">yellowpaper<\/a><\/noindex>, men her er <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/keep-network\/random-beacon-box\">eksempel<\/a><\/noindex> smart-kontrakten, der betjener protokollen).<\/p>\n<p><\/p>\n<h2 id=\"implementaciya-pvrb\">Implementeringen af PVRB<\/h2>\n<p><\/p>\n<p>Desv\u00e6rre ser vi stadig ikke et f\u00e6rdigt, implementeret PVRB-protokol i blockchains, der har bevist sin sikkerhed og robusthed. Selvom protokollerne er klar, er det teknisk vanskeligt at anvende dem p\u00e5 eksisterende l\u00f8sninger. For centraliserede systemer giver PVRB ikke mening, og decentraliserede systemer er strengt begr\u00e6nset i alle computerressourcer: CPU, hukommelse, lager, I\/O. Designet af PVRB handler om at kombinere forskellige protokoller for at skabe noget, der opfylder kravene til en eller anden levedygtig blockchain. En protokol beregner effektivt, men kr\u00e6ver flere beskeder mellem RP, mens en anden kr\u00e6ver meget f\u00e5 beskeder, men at generere proof kan v\u00e6re en opgave, der tager mange minutter eller endda timer.<\/p>\n<p><\/p>\n<p>Jeg vil n\u00e6vne faktorer, som du skal overveje, n\u00e5r du v\u00e6lger et kvalitets PVRB:<\/p>\n<p><\/p>\n<ul>\n<li><em>Kryptografisk modstandsdygtighed<\/em>. Dit PVRB skal v\u00e6re strengt unbiasable, uden mulighed for at kontrollere en enkelt bit. I nogle ordninger er dette ikke tilf\u00e6ldet, s\u00e5 ring efter en kryptograf.<\/li>\n<li><em>Problemet med 'last actor'<\/em>. Dit PVRB skal v\u00e6re modstandsdygtigt over for angreb, hvor en angriber, der kontrollerer en eller flere RP, kan v\u00e6lge mellem to resultatmuligheder.<\/li>\n<li><em>Problemet med sabotage af protokollen<\/em>. Dit PVRB skal v\u00e6re modstandsdygtigt over for angreb, hvor en angriber, der kontrollerer en eller flere RP, beslutter, om der skal v\u00e6re randomisering eller ej, og kan garantere, eller med en given sandsynlighed p\u00e5virke dette.<\/li>\n<li><em>Problemet med antallet af beskeder<\/em>. Dine RP skal sende et minimum af beskeder til blockchain og undg\u00e5 synkrone handlinger som situationer med \"jeg har sendt noget information, st\u00e5r og venter p\u00e5 svar fra en specifik deltager\". I p2p-netv\u00e6rk, is\u00e6r geografisk adskilt, b\u00f8r man ikke forvente hurtige svar.<\/li>\n<li><em>Problemet med beregningsm\u00e6ssig kompleksitet<\/em>. Verifikationen af enhver fase af PVRB on-chain skal v\u00e6re ekstremt let, da den udf\u00f8res af alle full clients i netv\u00e6rket. Hvis implementeringen sker via en smart kontrakt, er kravene til hastighed meget strenge.<\/li>\n<li><em>Problemet med tilg\u00e6ngelighed og liveness<\/em>. Dit PVRB b\u00f8r str\u00e6be efter at v\u00e6re modstandsdygtigt over for situationer, hvor en del af netv\u00e6rket er blevet utilg\u00e6ngeligt i et stykke tid, og nogle RP simpelthen er stoppet med at fungere.<\/li>\n<li><em>Problemet med trusted setup og den indledende distribution af n\u00f8gler<\/em>. Hvis din PVRB bruger prim\u00e6re ops\u00e6tningsprotokoller, er det en stor og seri\u00f8s sag. Her er <noindex><a rel=\"nofollow\" href=\"https:\/\/z.cash\/ru\/blog\/the-design-of-the-ceremony\/\">eksempel<\/a><\/noindex>. Hvis deltagerne skal meddele hinanden deres n\u00f8gler f\u00f8r starten af protokollen - er det ogs\u00e5 et problem, hvis deltagerne skifter<\/li>\n<li><em>Udviklingsproblemer<\/em>. Tilstedev\u00e6relsen af biblioteker p\u00e5 de n\u00f8dvendige sprog, deres sikkerhed og ydeevne, offentligg\u00f8relse, komplekse tests osv.<\/li>\n<\/ul>\n<p><\/p>\n<p>For eksempel har threshold BLS signaturer et v\u00e6sentligt problem - f\u00f8r de kan begynde at arbejde, skal deltagerne n\u00f8dvendigvis udveksle n\u00f8gler med hinanden, hvilket organiserer en gruppe, som threshold skal fungere indenfor. Det betyder, at man mindst skal vente p\u00e5 \u00e9n runde af udveksling i et decentralt netv\u00e6rk, og da den genererede tilf\u00e6ldighed, eksempelvis, er n\u00f8dvendig i spil, n\u00e6sten i realtime, betyder det, at protokollens sabotage er mulig p\u00e5 dette stadium, og fordelene ved threshold-skemaet g\u00e5r tabt. Dette problem er allerede lettere end de tidligere, men kr\u00e6ver stadig udviklingen af en separat procedure for dannelse af threshold-grupper, som \u00f8konomisk skal beskyttes gennem indskud og frat\u00e6nkning af midler (slashing) fra deltagere, der ikke f\u00f8lger protokollen. Derudover kan verifikation af BLS med et acceptabelt sikkerhedsniveau simpelthen ikke finde plads i for eksempel en standard EOS- eller Ethereum-transaktion - der er simpelthen ikke tid til verifikationen. Kontrakternes kode - er WebAssembly eller EVM, der udf\u00f8res af en virtuel maskine. Kryptografiske funktioner er ikke implementeret nativt (endnu) og arbejder ti gange langsommere end almindelige kryptografiske biblioteker. Mange protokoller passer ikke til kravene blot baseret p\u00e5 st\u00f8rrelsen af n\u00f8glerne, eksempelvis 1024 og 2048 bit for RSA, hvilket er 4-8 gange mere end den standard signatur, der findes i Bitcoin og Ethereum.<\/p>\n<p><\/p>\n<p>Det spiller ogs\u00e5 en rolle, om der findes implementeringer p\u00e5 forskellige programmeringssprog - hvilket er begr\u00e6nset, is\u00e6r for nye protokoller. Muligheden for integration i konsensus kr\u00e6ver, at protokollen skrives p\u00e5 platformssproget, s\u00e5 man skal finde kode i Go til geth, i Rust til Parity, i C++ til EOS. Kode i JavaScript skal alle lede efter, og da JavaScript og kryptografi ikke er helt gode venner, vil WebAssembly, som nu helt sikkert stiller sig i k\u00f8 til at blive den n\u00e6ste vigtige internetstandard, v\u00e6re til hj\u00e6lp.<\/p>\n<p><\/p>\n<h2 id=\"zaklyuchenie\">Konklusion<\/h2>\n<p><\/p>\n<p>Jeg h\u00e5ber, at det i det foreg\u00e5ende <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/448330\/\">artikel<\/a><\/noindex> Jeg har form\u00e5et at overbevise jer om, at generering af tilf\u00e6ldige tal p\u00e5 blockchainen er kritisk vigtig for mange aspekter af livet i decentraliserede netv\u00e6rk. Denne artikel viser, at opgaven er meget ambiti\u00f8s og udfordrende, men gode l\u00f8sninger eksisterer allerede. Generelt kan det endelige design af protokollen kun komme efter omfattende tests, der tager h\u00f8jde for alle aspekter fra ops\u00e6tning til simulering af fejl, s\u00e5 I vil n\u00e6ppe finde klare opskrifter i whitepapers fra teams eller i artikler. Vi vil heller ikke i det n\u00e6ste \u00e5r eller to have mod p\u00e5 at skrive 'g\u00f8r s\u00e5dan, s\u00e5 er det helt rigtigt'. <\/p>\n<p><\/p>\n<p>Indtil videre, for vores PVRB i den under udvikling blockchain <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/mixbytes\/haya\">Haya<\/a><\/noindex>, har vi besluttet at anvende threshold BLS-signaturer. Vi planl\u00e6gger at implementere PVRB p\u00e5 konsensusniveau, da verifikation i smart contracts med et acceptabelt sikkerhedsniveau endnu ikke er mulig. Det kan v\u00e6re, at vi bruger to ordninger: f\u00f8rst en dyr secret sharing for at skabe en langsigtet random_seed, som vi senere bruger som grundlag for h\u00f8jfrekvent tilf\u00e6ldighedsgenerering ved hj\u00e6lp af deterministiske threshold BLS-signaturer, eller m\u00e5ske begr\u00e6nser vi os til kun \u00e9n af ordningerne. At sige p\u00e5 forh\u00e5nd, hvordan protokollen vil v\u00e6re, er desv\u00e6rre umuligt. Det gl\u00e6der dog, at ligesom inden for videnskab, i ingeni\u00f8roppgaver, er et negativt resultat ogs\u00e5 et resultat, og hvert nyt fors\u00f8g p\u00e5 at l\u00f8se problemet er et skridt fremad for alle, der besk\u00e6ftiger sig med denne problemstilling. For at opfylde erhvervslivets krav l\u00f8ser vi et konkret praktisk problem \u2014 sikring af gaming-applikationer med en p\u00e5lidelig kilde til entropi. Derfor er vi ogs\u00e5 n\u00f8dt til at tage hensyn til selve blockchainen, is\u00e6r sp\u00f8rgsm\u00e5l om k\u00e6dens finalitet og netv\u00e6rkets governance. <\/p>\n<p><\/p>\n<p>Og selvom vi endnu ikke ser et beviseligt robust PVRB i blockchains, der har v\u00e6ret i brug l\u00e6nge nok til at best\u00e5 testen fra virkelige applikationer, flere audits, belastninger og naturligvis reelle angreb, bekr\u00e6fter antallet af mulige veje, at l\u00f8sningen eksisterer, og en af disse algoritmer vil til sidst l\u00f8se problemet. Vi vil med gl\u00e6de dele resultaterne og takker andre teams, der ogs\u00e5 arbejder med dette emne, for artikler og kode, der g\u00f8r det muligt for ingeni\u00f8rer ikke at tr\u00e6de to gange p\u00e5 de samme mine. <\/p>\n<p><\/p>\n<p>N\u00e5r du m\u00f8der en programm\u00f8r, der designer et decentraliseret tilf\u00e6ldigt system, skal du v\u00e6re opm\u00e6rksom og omsorgsfuld; tilbyd psykologisk hj\u00e6lp, hvis n\u00f8dvendigt \ud83d\ude42<\/p>\n<p>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/452340\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number! } \u041a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0441 \u043a\u043e\u043d\u0446\u0435\u043f\u0446\u0438\u0435\u0439 \u0430\u0431\u0441\u043e\u043b\u044e\u0442\u043d\u043e \u0441\u0442\u043e\u0439\u043a\u043e\u0433\u043e \u0448\u0438\u0444\u0440\u0430 \u0438\u0437 \u043a\u0440\u0438\u043f\u0442\u043e\u0433\u0440\u0430\u0444\u0438\u0438, \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u044b \u201cPublicly Verifiable Random Beacon\u201d (\u0434\u0430\u043b\u0435\u0435 PVRB) \u043b\u0438\u0448\u044c \u043f\u044b\u0442\u0430\u044e\u0442\u0441\u044f \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e \u043f\u0440\u0438\u0431\u043b\u0438\u0437\u0438\u0442\u044c\u0441\u044f \u043a \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u043e\u0439 \u0441\u0445\u0435\u043c\u0435, \u0442.\u043a. \u0432 \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0445 \u0441\u0435\u0442\u044f\u0445 \u0432 \u0447\u0438\u0441\u0442\u043e\u043c \u0432\u0438\u0434\u0435 \u043e\u043d\u0430 \u043d\u0435\u043f\u0440\u0438\u043c\u0435\u043d\u0438\u043c\u0430: \u0434\u043e\u0433\u043e\u0432\u0430\u0440\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u043d\u0430\u0434\u043e \u0441\u0442\u0440\u043e\u0433\u043e \u043e\u0431 \u043e\u0434\u043d\u043e\u043c \u0431\u0438\u0442\u0435, \u0440\u0430\u0443\u043d\u0434\u043e\u0432 \u0434\u043e\u043b\u0436\u043d\u043e [&hellip;]<\/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-33888","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0421\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0438 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0441\u0435\u0442\u0438: \u0438\u043c\u043f\u043b\u0435\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:55:15+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:55:15+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Tilf\u00e6ldige tal og decentrale netv\u00e6rk: implementeringer | ProHoster","description":"Introduktion function getAbsolutelyRandomNumber() { return 4; \/\/ returnerer et helt tilf\u00e6ldigt tal!","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","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\u0421\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0438 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0441\u0435\u0442\u0438: \u0438\u043c\u043f\u043b\u0435\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","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:55:15+00:00","article:modified_time":"2019-10-31T18:55:15+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33888","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:06:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:31:23","updated":"2026-01-21 17:06: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\/33888","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=33888"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/33888\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=33888"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=33888"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=33888"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}