{"id":95468,"date":"2020-09-29T19:42:29","date_gmt":"2020-09-29T17:42:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1"},"modified":"2020-09-29T19:42:29","modified_gmt":"2020-09-29T17:42:29","slug":"mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","title":{"rendered":"Kan vi generere tilf\u00e6ldige tal, hvis vi ikke stoler p\u00e5 hinanden? Del 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hello, Habr!<\/p>\n

I denne artikel vil jeg fort\u00e6lle om generering af pseudo-tilf\u00e6ldige tal blandt deltagere, der ikke stoler p\u00e5 hinanden. Som vi vil se nedenfor, er det relativt simpelt at implementere en \"n\u00e6sten\" god generator, men en virkelig god er sv\u00e6r.<\/p>\n

Hvorfor er det overhovedet n\u00f8dvendigt at generere tilf\u00e6ldige tal for deltagere, der ikke stoler p\u00e5 hinanden? Et af anvendelsesomr\u00e5derne er decentraliserede applikationer. For eksempel vil en applikation, der tager en indsats fra en deltager og enten fordobler bel\u00f8bet med en sandsynlighed p\u00e5 49% eller tager det med 51%, kun fungere, hvis den kan modtage et tilf\u00e6ldigt tal uden bias. Hvis en ondsindet akt\u00f8r kan p\u00e5virke resultatet af tilf\u00e6ldighedsgeneratorens funktion og endda let \u00f8ge sin chance for udbetaling i applikationen, kan de nemt t\u00f8mme den.<\/p>\n

N\u00e5r vi udvikler en distribueret protokol til generering af tilf\u00e6ldige tal, \u00f8nsker vi, at den har tre egenskaber:<\/p>\n

    \n
  1. \n

    Den skal v\u00e6re upartisk. Med andre ord skal ingen deltager p\u00e5 nogen m\u00e5de p\u00e5virke resultatet af den tilf\u00e6ldige talgenerator.<\/p>\n<\/li>\n

  2. \n

    Den skal v\u00e6re uforudsigelig. Med andre ord skal ingen deltager v\u00e6re i stand til at forudsige, hvilket tal der vil blive genereret (eller udlede nogen af dens egenskaber) f\u00f8r det bliver genereret.<\/p>\n<\/li>\n

  3. \n

    Protokollen skal v\u00e6re levedygtig, det vil sige modstandsdygtig overfor, at en vis procentdel af deltagerne frakobles netv\u00e6rket eller med vilje fors\u00f8ger at stoppe protokollen.<\/p>\n<\/li>\n<\/ol>\n

    I denne artikel vil vi se p\u00e5 to tilgange: RANDAO + VDF og en tilgang baseret p\u00e5 udslettende koder. I den n\u00e6ste del vil vi grundigt gennemg\u00e5 tilgangen baseret p\u00e5 t\u00e6rskelsignaturer.<\/p>\n

    Men lad os f\u00f8rst gennemg\u00e5 en simpel og ofte anvendt algoritme, der er levedygtig, uforudsigelig, men partisk.<\/p>\n

    RANDAO<\/h3>\n

    RANDAO er en meget simpel og dermed ret ofte anvendt tilgang til at opn\u00e5 tilf\u00e6ldighed. Alle deltagere i netv\u00e6rket v\u00e6lger f\u00f8rst lokalt et pseudotilf\u00e6ldigt tal, og derefter sender hver deltager hash af det valgte tal. Derefter afsl\u00f8rer deltagerne skiftesvis deres valgte tal og udf\u00f8rer en XOR-operation p\u00e5 de afsl\u00f8rede tal, og resultatet af denne operation bliver resultatet af protokolens funktion.<\/p>\n

    Trin med at offentligg\u00f8re hasher f\u00f8r afsl\u00f8ringen af numrene er n\u00f8dvendig for at sikre, at en angriber ikke kan v\u00e6lge sit eget nummer efter at have set de andre deltageres numre. Dette ville give dem mulighed for faktisk at bestemme resultatet af den tilf\u00e6ldige talgenerator alene.<\/p>\n

    Under protokollen skal deltagerne n\u00e5 til enighed to gange (den s\u00e5kaldte konsensus): hvorn\u00e5r de skal begynde at afsl\u00f8re de valgte numre og dermed stoppe med at modtage hasher, og hvorn\u00e5r de skal afslutte modtagelsen af de valgte numre og beregne det resulterende tilf\u00e6ldige tal. At tr\u00e6ffe s\u00e5danne beslutninger blandt deltagere, der ikke stoler p\u00e5 hinanden, er i sig selv en udfordrende opgave, og vi vil vende tilbage til det i fremtidige artikler; i denne artikel antager vi, at en s\u00e5dan konsensusalgoritme er tilg\u00e6ngelig.<\/p>\n

    Hvilke af de egenskaber, vi har beskrevet ovenfor, har RANDAO? Den er uforudsigelig, har samme levedygtighed som den underliggende konsensusprotokol, men den er sk\u00e6v. Is\u00e6r kan en angriber overv\u00e5ge netv\u00e6rket, og efter at de andre deltagere har afsl\u00f8ret deres numre, kan han beregne deres XOR og beslutte, om han vil afsl\u00f8re sit eget nummer for at p\u00e5virke resultatet. Selvom dette ikke tillader angriberen at bestemme resultatet af den tilf\u00e6ldige talgenerator, giver det ham stadig 1 bit indflydelse. Og hvis angriberne kontrollerer flere deltagere, vil antallet af bits, de kontrollerer, v\u00e6re lig med antallet af deltagere under deres kontrol.<\/p>\n

    \"Kan<\/p>\n

    Indflydelsen fra angribere kan reduceres betydeligt, hvis det kr\u00e6ves, at deltagerne afsl\u00f8rer numrene i r\u00e6kkef\u00f8lge. S\u00e5 vil angriberen kun kunne p\u00e5virke udfaldet, hvis han afsl\u00f8rer sidst. Selvom indflydelsen er meget mindre, er algoritmen stadig sk\u00e6v.<\/p>\n

    RANDAO + VDF<\/h3>\n

    En af metoderne til at g\u00f8re RANDAO sk\u00e6v er f\u00f8lgende: efter at alle numre er afsl\u00f8ret, og XOR er beregnet, sendes resultatet som input til en funktion, der tager meget lang tid at beregne, men som muligg\u00f8r hurtig verifikation af beregningens korrekthed.<\/p>\n

    (vdf_output, vdf_proof) = VDF_compute(input) \/\/ dette er meget langsomt\ncorrect = VDF_verify(input, vdf_output, vdf_proof) \/\/ dette er meget hurtigt<\/code><\/pre>\n
    Denne funktion kaldes Verifiable Delay Function, eller VDF. Hvis beregningen af det endelige resultat tager l\u00e6ngere tid, end trinnet med at afsl\u00f8re tallene, s\u00e5 kan en angriber ikke forudsige effekten af at demonstrere eller skjule sit tal, og v\u00e6lger derfor at miste muligheden for at p\u00e5virke resultatet.<\/p>\n
    Udviklingen af gode VDF'er er utrolig kompleks. I de seneste \u00e5r er der gjort flere gennembrud, som for eksempel denne<\/u><\/a><\/noindex> og dette,<\/u><\/a><\/noindex> som har gjort VDF'er mere anvendelige i praksis, og Ethereum 2.0 planl\u00e6gger p\u00e5 lang sigt at bruge RANDAO sammen med VDF som en kilde til tilf\u00e6ldige tal. Udover at denne tilgang er uforudsigelig og objektiv, har den den ekstra fordel, at den er levedygtig, s\u00e5 l\u00e6nge mindst to deltagere er tilg\u00e6ngelige i netv\u00e6rket (forudsat at den anvendte konsensusprotokol er levedygtig ved en s\u00e5 lille deltagergruppe).<\/p>\n
    Den st\u00f8rste udfordring ved denne tilgang er at indstille VDF korrekt, s\u00e5 selv en deltager med meget dyrt specialudstyr ikke kan beregne VDF'en f\u00f8r afslutningsfasen. Ideelt set b\u00f8r algoritmen have en betydelig sikkerhedsmargin, lad os sige 10x. I figuren nedenfor ses et angreb fra en deltager med specialiseret ASIC, som g\u00f8r det muligt for ham at k\u00f8re VDF hurtigere end den tid, der er afsat til at afsl\u00f8re bekr\u00e6ftelsen fra RANDAO. En s\u00e5dan deltager kan stadig beregne det endelige resultat ved at bruge og ikke bruge sit tal, og derefter v\u00e6lge at vise det eller ej, baseret p\u00e5 beregningerne.<\/p>\n
    \"Kan<\/p>\n
    For den ovenn\u00e6vnte familie af VDF'er kan pr\u00e6stationen af en specialiseret ASIC v\u00e6re mere end 100 gange h\u00f8jere end almindeligt udstyr. S\u00e5 hvis afsl\u00f8ringsfasen varer 10 sekunder, skal VDF'en, der beregnes p\u00e5 en s\u00e5dan ASIC, tage mere end 100 sekunder for at have en 10 gange sikkerhedsmargin, og derfor skal den samme VDF, der beregnes p\u00e5 almindeligt udstyr, tage 100 x 100 sekunder = ~ 3 timer.<\/p>\n
    Ethereum Foundation planl\u00e6gger at l\u00f8se dette problem ved at skabe deres egne offentligt tilg\u00e6ngelige gratis ASIC. S\u00e5 snart det sker, kan alle andre protokoller ogs\u00e5 drage fordel af denne teknologi, men indtil da vil RANDAO + VDF-tilgangen ikke v\u00e6re lige s\u00e5 levedygtig for protokoller, der ikke kan investere i udviklingen af deres egne ASIC.<\/p>\n
    Masser af artikler, videoer og andre oplysninger om VDF er samlet p\u00e5 denne hjemmeside<\/u><\/a><\/noindex>.<\/p>\n
    Vi bruger fejkoder<\/h3>\n
    I dette afsnit vil vi se p\u00e5 protokollen til generering af tilf\u00e6ldige tal, der bruger fejkoder<\/a><\/noindex>. Den kan modst\u00e5 op til \u2153 ondsindede akt\u00f8rer og tillader eksistensen af op til \u2154 ondsindede akt\u00f8rer, f\u00f8r de kan forudsige eller p\u00e5virke resultatet.<\/p>\n
    Hovedideen i protokollen er som f\u00f8lger. For enkelheds skyld antager vi, at der pr\u00e6cist er 100 deltagere. Lad os ogs\u00e5 antage, at alle deltagere har en privat n\u00f8gle lokalt, og de offentlige n\u00f8gler for alle deltagere er kendt af alle deltagere:<\/p>\n
      \n
    1. \n
      Hver deltager opdager lokalt en lang streng, opdeler den i 67 dele, skaber fejkoder for at f\u00e5 100 andele, s\u00e5dan at 67 af dem er tilstr\u00e6kkelige til at genoprette strengen, tildeler hver af de 100 andele til en deltager og krypterer dem med den p\u00e5g\u00e6ldende deltagers offentlige n\u00f8gle. Derefter offentligg\u00f8res alle kodede andele.<\/p>\n<\/li>\n
    2. \n
      Deltagerne bruger en form for konsensus for at n\u00e5 til enighed om de kodede s\u00e6t fra specificerede 67 deltagere.<\/p>\n<\/li>\n
    3. \n
      N\u00e5r konsensus er n\u00e5et, tager hver deltager de kodede andele fra hvert af de 67 s\u00e6t, krypteret med deres offentlige n\u00f8gle, dekrypterer alle s\u00e5danne andele og offentligg\u00f8r alle s\u00e5danne dekrypterede andele.<\/p>\n<\/li>\n
    4. \n
      N\u00e5r de 67 deltagere har udf\u00f8rt trin (3), kan alle de aftalte s\u00e6t fuldt ud dekodes og genoprettes takket v\u00e6re egenskaberne ved fejkoder, og det endelige tal kan opn\u00e5s som XOR af de oprindelige strenge, som deltagerne startede med i (1).<\/p>\n<\/li>\n<\/ol>\n
      \"Kan<\/p>\n
      Det kan vises, at denne protokol er upartisk og uforudsigelig. Det resulterende tilf\u00e6ldige tal defineres efter opn\u00e5else af konsensus, men ingen kender det, f\u00f8r \u2154 af deltagerne har dekodet de dele, der er krypteret med deres offentlige n\u00f8gle. S\u00e5ledes er det tilf\u00e6ldige tal defineret tidligere end den information, der er tilstr\u00e6kkelig til at genetablere det, offentligg\u00f8res.<\/p>\n
      Hvad sker der, hvis i trin (1) en af deltagerne sender krypterede andele til de andre deltagere, som ikke er en korrekt slettekode for en bestemt r\u00e6kke? Uden yderligere \u00e6ndringer vil forskellige deltagere enten ikke kunne genskabe r\u00e6kken overhovedet, eller genskabe forskellige r\u00e6kker, hvilket vil f\u00f8re til, at forskellige deltagere f\u00e5r forskellige tilf\u00e6ldige tal. For at forhindre dette kan man g\u00f8re f\u00f8lgende: hver deltager, ud over de krypterede andele, beregner ogs\u00e5 Merkle-tr\u00e6et<\/a><\/noindex> for alle s\u00e5danne andele, og hver deltager sender b\u00e5de den krypterede andel og roden af Merkle-tr\u00e6et samt et bevis for inkluderningen af andelen i Merkle-tr\u00e6et. I konsensus skal i trin (2) deltagerne ikke bare blive enige om en m\u00e6ngde s\u00e6t, men om en m\u00e6ngde konkrete r\u00f8dder af s\u00e5danne tr\u00e6er (hvis en deltager er g\u00e5et v\u00e6k fra protokollen og har sendt forskellige r\u00f8dder af Merkle-tr\u00e6et til forskellige deltagere, og to s\u00e5danne r\u00f8dder vises under konsensus, inkluderes hans r\u00e6kke ikke i det resulterende s\u00e6t). Efter konsensus vil vi have 67 krypterede r\u00e6kker og de tilsvarende r\u00f8dder af Merkle-tr\u00e6et, s\u00e5ledes at der er mindst 67 deltagere (ikke n\u00f8dvendigvis de samme, der foreslog de tilsvarende r\u00e6kker), der for hver af de 67 r\u00e6kker har en besked med en andel af slettekoden og et bevis for, at deres andel er inkluderet i det tilsvarende Merkle-tr\u00e6.<\/p>\n
      N\u00e5r i trin (4) en deltager dekrypterer 67 andele for en bestemt r\u00e6kke og fors\u00f8ger at genskabe den oprindelige r\u00e6kke, er en af mulighederne:<\/p>\n
        \n
      1. \n
        R\u00e6kken genskabes, og hvis den derefter krypteres med slettekoder igen og Merkle-tr\u00e6et beregnes for de beregnede lokale andele, stemmer roden overens med den, hvor konsensus er opn\u00e5et.<\/p>\n<\/li>\n
      2. \n
        R\u00e6kken genskabes, men den beregnede lokale rod svarer ikke til den, hvor konsensus er opn\u00e5et.<\/p>\n<\/li>\n
      3. \n
        R\u00e6kken kan ikke genskabes.<\/p>\n<\/li>\n<\/ol>\n
        Det er let at vise, at hvis mindst \u00e9n deltager har oplevet situation (1), s\u00e5 vil alle deltagere ogs\u00e5 opleve situation (1), og omvendt, hvis mindst \u00e9n deltager har oplevet situation (2) eller (3), s\u00e5 vil alle deltagere opleve situation (2) eller (3). P\u00e5 den m\u00e5de vil hver r\u00e6kke i s\u00e6ttet enten blive genoprettet af alle deltagere, eller alle deltagere vil ikke kunne genoprette den. Det resulterende tilf\u00e6ldige tal er dermed XOR kun af de r\u00e6kker, som deltagerne kunne genoprette.<\/p>\n
        Terskelsignaturer<\/h3>\n
        En anden tilgang til tilf\u00e6ldighed involverer brugen af s\u00e5kaldte BLS-terskelsignaturer. En tilf\u00e6ldig talgenerator, der er baseret p\u00e5 terskelsignaturer, har n\u00f8jagtig de samme garantier som den ovenfor beskrevne algoritme baseret p\u00e5 udviskende koder, men har en betydeligt lavere asymptotisk m\u00e6ngde meddelelser, der sendes over netv\u00e6rket for hvert genereret tal.<\/p>\n
        BLS-signaturer er en konstruktion, der muligg\u00f8r, at flere deltagere kan oprette \u00e9n f\u00e6lles signatur for en meddelelse. S\u00e5danne signaturer bruges ofte til at spare plads og b\u00e5ndbredde, da de ikke kr\u00e6ver udsendelse af flere signaturer. <\/p>\n
        En almindelig anvendelse af BLS-signaturer i blockchain-protokoller, ud over generering af tilf\u00e6ldige tal, er signering af blokke i BFT-protokoller. Lad os sige, at 100 deltagere opretter blokke, og en blok betragtes som endelig, hvis 67 af dem signerer den. Alle kan pr\u00e6senterer deres dele af BLS-signaturen og bruge en eller anden konsensus-algoritme til at enes om 67 af dem og derefter kombinere dem til \u00e9n BLS-signatur. Enhver gruppe med 67 (eller flere) dele kan bruges til at skabe den endelige signatur, som afh\u00e6nger af, hvilke 67 signaturer der er blevet kombineret, og derfor kan variere; men p\u00e5 trods af at forskellige valg af de 67 deltagere vil skabe forskellige signaturer, vil enhver s\u00e5dan signatur v\u00e6re en gyldig signatur for blokken. De \u00f8vrige deltagere skal derefter blot modtage og verificere \u00e9n signatur pr. blok over netv\u00e6rket, i stedet for 67, hvilket markant reducerer belastningen p\u00e5 netv\u00e6rket.<\/p>\n
        Det viser sig, at hvis de private n\u00f8gler, som deltagerne bruger, genereres p\u00e5 en bestemt m\u00e5de, vil den resulterende signatur v\u00e6re den samme, uanset hvilke 67 underskrifter (eller flere, men ikke mindre) der er aggregeret. Dette kan bruges som en kilde til tilf\u00e6ldighed: deltagerne aftaler f\u00f8rst et bestemt budskab, som de vil underskrive (det kan v\u00e6re output fra RANDAO eller blot hashen fra den seneste blok, det betyder ikke noget, s\u00e5 l\u00e6nge det \u00e6ndrer sig hver gang og er aftalt), og skaber en BLS-signatur for det. Resultatet af genereringen vil v\u00e6re uforudsigeligt, indtil 67 deltagere leverer deres bidder, hvorefter output allerede er forudbestemt og ikke kan afh\u00e6nge af nogen deltageres handlinger.<\/p>\n
        Denne tilgang til tilf\u00e6ldighed er levedygtig, hvis mindst \u2154 af deltagerne er online og f\u00f8lger protokollen, og er upartisk og uforudsigelig, s\u00e5 l\u00e6nge mindst \u2153 af deltagerne f\u00f8lger protokollen. Det er vigtigt at bem\u00e6rke, at en angriber, der kontrollerer mere end \u2153, men mindre end \u2154 af deltagerne, kan stoppe protokollen, men ikke kan forudsige eller p\u00e5virke dens output.<\/p>\n
        T\u00e6rskelsignaturer i sig selv er et meget interessant emne. I den anden del af artiklen vil vi detaljeret gennemg\u00e5, hvordan de fungerer, og hvordan det n\u00f8jagtigt er n\u00f8dvendigt at generere deltageres n\u00f8gler for at kunne bruge t\u00e6rskelsignaturerne som generator af tilf\u00e6ldige tal.<\/p>\n
        Afslutningsvis<\/h3>\n
        Denne artikel er den f\u00f8rste i en serie tekniske artikler i bloggen. NEAR<\/a><\/noindex>. NEAR er en blockchain-protokol og platform til udvikling af decentraliserede applikationer med fokus p\u00e5 enkel udvikling og brugervenlighed for slutbrugere.<\/p>\n
        Protokolens kode er \u00e5ben, vores implementering er skrevet i Rust, og den kan findes her<\/a><\/noindex>.<\/p>\n
        Du kan se, hvordan udviklingen under NEAR ser ud, og eksperimentere i online-IDE'en. her<\/a><\/noindex>.<\/p>\n
        Hold dig opdateret med alle nyheder p\u00e5 russisk i gruppen i Telegram.<\/a><\/noindex> og i gruppen p\u00e5 VKontakte,<\/a><\/noindex>mens du kan finde nyheder p\u00e5 engelsk i det officielle Twitter.<\/a><\/noindex>.<\/p>\n
        Vi ses snart!<\/p>\n
        Kilde: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
        \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043f\u0440\u043e \u0433\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u044e \u043f\u0441\u0435\u0432\u0434\u043e-\u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u044e\u0442 \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443. \u041a\u0430\u043a \u043c\u044b \u0443\u0432\u0438\u0434\u0438\u043c \u043d\u0438\u0436\u0435, \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u0442\u044c \u201c\u043f\u043e\u0447\u0442\u0438\u201d \u0445\u043e\u0440\u043e\u0448\u0438\u0439 \u0433\u0435\u043d\u0435\u0440\u0430\u0442\u043e\u0440 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043f\u0440\u043e\u0441\u0442\u043e, \u0430 \u0432\u043e\u0442 \u043e\u0447\u0435\u043d\u044c \u0445\u043e\u0440\u043e\u0448\u0438\u0439 \u2013 \u0441\u043b\u043e\u0436\u043d\u043e. \u0417\u0430\u0447\u0435\u043c \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0443\u0436\u043d\u043e \u0433\u0435\u043d\u0435\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c, \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u044e\u0449\u0438\u043c \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443? \u041e\u0434\u043d\u0430 \u0438\u0437 \u043e\u0431\u043b\u0430\u0441\u0442\u0435\u0439 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044f — \u044d\u0442\u043e \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435, \u043a\u043e\u0442\u043e\u0440\u043e\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":95469,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-95468","post","type-post","status-publish","format-standard","has-post-thumbnail","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\udd47Kan vi generere tilf\u00e6ldige tal, hvis vi ikke stoler p\u00e5 hinanden? Del 1 | ProHoster","description":"Hej, Habr! I denne artikel vil jeg fort\u00e6lle om genereringen af pseudo-tilf\u00e6ldige tal blandt deltagere, der ikke stoler p\u00e5 hinanden.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","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\u041c\u043e\u0436\u043d\u043e \u043b\u0438 \u0433\u0435\u043d\u0435\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430, \u0435\u0441\u043b\u0438 \u043c\u044b \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u0435\u043c \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443? \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440!\u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043f\u0440\u043e \u0433\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u044e \u043f\u0441\u0435\u0432\u0434\u043e-\u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u044e\u0442 \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","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":"2020-09-29T17:42:29+00:00","article:modified_time":"2020-09-29T17:42:29+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"95468","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:05:29","updated":"2022-09-28 01:55:15","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\/95468","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=95468"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/95468\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/95469"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=95468"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=95468"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=95468"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}