{"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\/sv\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","title":{"rendered":"Slumptal och decentraliserade n\u00e4tverk: implementationer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<h1 id=\"vvedenie\">Introduktion<\/h1>\n<p><\/p>\n<pre><code class=\"plaintext\">function getAbsolutelyRandomNumer() {\n        return 4; \/\/ returns absolutely random number!\n}<\/code><\/pre>\n<p><\/p>\n<p>Precis som med konceptet f\u00f6r en absolut robust kryptografisk algoritm, f\u00f6rs\u00f6ker verkliga protokoll f\u00f6r \"Publicly Verifiable Random Beacon\" (nedan kallat PVRB) bara komma s\u00e5 n\u00e4ra den perfekta schemat som m\u00f6jligt, eftersom det i verkliga n\u00e4tverk i ren form inte \u00e4r till\u00e4mpligt: man m\u00e5ste strikt enas om en enda bit, antalet rundor m\u00e5ste vara m\u00e5nga, och alla meddelanden m\u00e5ste vara perfekta snabba och alltid levererade. Sj\u00e4lvklart \u00e4r detta inte fallet i verkliga n\u00e4tverk. D\u00e4rf\u00f6r, vid utformningen av PVRB f\u00f6r specifika uppgifter i moderna blockkedjor, uppst\u00e5r det, ut\u00f6ver of\u00f6rm\u00e5gan att kontrollera det genererade slumpnumret och kryptografisk styrka, m\u00e5nga rent arkitektoniska och tekniska problem.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Sj\u00e4lva blockkedjan fungerar i princip som en kommunikationsmilj\u00f6 f\u00f6r PVRB, d\u00e4r meddelandena=transaktionerna. Detta g\u00f6r det m\u00f6jligt att delvis abstrahera fr\u00e5n n\u00e4tverksproblem, icke-levererade meddelanden, problem med mellanliggande mjukvara \u2014 alla dessa risker tar den decentraliserade n\u00e4tverket p\u00e5 sig, och dess huvudsakliga v\u00e4rde f\u00f6r PVRB \u00e4r of\u00f6rm\u00e5gan att \u00e5terkalla eller f\u00f6rst\u00f6ra en redan skickad transaktion \u2014 detta f\u00f6rhindrar deltagare fr\u00e5n att dra sig ur protokollet, s\u00e5vida de inte har genomf\u00f6rt en framg\u00e5ngsrik attack p\u00e5 konsensus. En s\u00e5dan s\u00e4kerhetsniv\u00e5 \u00e4r acceptabel, varf\u00f6r PVRB m\u00e5ste vara resistent mot sammansv\u00e4rjningar mellan deltagarna i samma utstr\u00e4ckning som den prim\u00e4ra blockkedjan. Detta antyder ocks\u00e5 att PVRB b\u00f6r vara en del av konsensus, om n\u00e4tverket har kommit \u00f6verens om den prim\u00e4ra kedjan av block, likv\u00e4l borde det ocks\u00e5 komma \u00f6verens om en enda \u00e4rlig resultatande slump. Alternativt kan PVRB vara ett frist\u00e5ende protokoll, implementerat av ett smart kontrakt, som fungerar asynkront i f\u00f6rh\u00e5llande till blockkedjan och blocken. B\u00e5da metoderna har sina f\u00f6r- och nackdelar, och valet mellan dem \u00e4r mycket komplext. <\/p>\n<p><\/p>\n<h2 id=\"dva-sposoba-implementacii-pvrb\">Tv\u00e5 s\u00e4tt att implementera PVRB<\/h2>\n<p><\/p>\n<p>L\u00e5t oss titta n\u00e4rmare p\u00e5 tv\u00e5 alternativ f\u00f6r implementering av PVRB \u2014 en frist\u00e5ende version, som fungerar med hj\u00e4lp av ett oberoende smart kontrakt utanf\u00f6r blockkedjan, och en konsensusintegrerad version \u2014 inbyggd i protokollet, enligt vilket n\u00e4tverket kommer \u00f6verens om blockkedjan och de inkluderade transaktionerna. I alla fall kommer jag att ha i \u00e5tanke popul\u00e4ra blockkedjemotorer: Ethereum, EOS, och alla som liknar dem i hur smarta kontrakt placeras och bearbetas. <\/p>\n<p><\/p>\n<h3 id=\"standalone-contract\">Frist\u00e5ende kontrakt<\/h3>\n<p><\/p>\n<p>I detta alternativ representerar PVRB ett smart kontrakt som accepterar transaktioner fr\u00e5n random-producer (RP), bearbetar dem, kombinerar resultaten och kommer d\u00e4rmed fram till ett v\u00e4rde som alla anv\u00e4ndare kan h\u00e4mta fr\u00e5n detta kontrakt. Detta v\u00e4rde beh\u00f6ver inte lagras direkt i kontraktet, utan kan endast representeras av data som deterministiskt kan ge ett och endast ett resultat av den slumpm\u00e4ssiga. I detta scenario \u00e4r RP anv\u00e4ndare av blockkedjan, och vem som helst kan till\u00e5tas delta i processen f\u00f6r att generera.<\/p>\n<p><\/p>\n<p>Alternativet med frist\u00e5ende kontrakt \u00e4r bra:<\/p>\n<p><\/p>\n<ul>\n<li>b\u00e4rbarhet (kontrakten kan flyttas mellan blockkedjor)<\/li>\n<li>enkelheten i implementation och testning (kontrakten \u00e4r l\u00e4tta att skriva och testa)<\/li>\n<li>bekv\u00e4mligheten att implementera ekonomiska scheman (det \u00e4r l\u00e4tt att skapa sin egen token vars logik tj\u00e4nar syftet f\u00f6r PVRB)<\/li>\n<li>m\u00f6jligheten att k\u00f6ra i redan befintliga blockkedjor<\/li>\n<\/ul>\n<p><\/p>\n<p>Det har ocks\u00e5 nackdelar:<\/p>\n<p><\/p>\n<ul>\n<li>strikta begr\u00e4nsningar p\u00e5 resurser under ber\u00e4kningar, transaktionsvolym och lagring (enklare sagt cpu\/mem\/io)<\/li>\n<li>begr\u00e4nsningar p\u00e5 operationer inom kontraktet (inte alla instruktioner \u00e4r tillg\u00e4ngliga, det \u00e4r sv\u00e5rt att koppla externa bibliotek)<\/li>\n<li>om\u00f6jligheten att organisera meddelandeutbyte snabbare \u00e4n transaktionerna inkluderas i blockkedjan<\/li>\n<\/ul>\n<p><\/p>\n<p>Detta alternativ \u00e4r l\u00e4mpligt f\u00f6r implementering av PVRB som beh\u00f6ver k\u00f6ras i ett redan existerande n\u00e4tverk, utan komplex kryptografi och som inte kr\u00e4ver m\u00e5nga interaktioner.<\/p>\n<p><\/p>\n<h3 id=\"consensus-integrated\">Konsensus-integrerad<\/h3>\n<p><\/p>\n<p>I den h\u00e4r varianten \u00e4r PVRB implementerat i koden f\u00f6r blockchain-noden, integrerat eller fungerar parallellt med meddelandeutbytet mellan blockchain-noderna. Resultaten fr\u00e5n protokollet registreras direkt i de producerade blocken, och protokollets meddelanden skickas via p2p-n\u00e4tverket mellan noderna. Eftersom protokollet resulterar i siffror som m\u00e5ste registreras i blocken, m\u00e5ste n\u00e4tverket n\u00e5 konsensus kring dem. Det inneb\u00e4r att PVRB-meddelanden, liksom transaktioner, m\u00e5ste valideras av noderna och inkluderas i blocken s\u00e5 att varje deltagare i n\u00e4tverket kan validera efterlevnaden av PVRB-protokollet. Detta leder oss automatiskt till den uppenbara l\u00f6sningen \u2014 om n\u00e4tverket kommer \u00f6verens om konsensus kring block och transaktioner inom det, s\u00e5 m\u00e5ste PVRB vara en del av konsensus och inte ett frist\u00e5ende protokoll. Annars kan det uppst\u00e5 en situation d\u00e4r blocket \u00e4r giltigt ur konsensus synvinkel, men PVRB-protokollet har inte f\u00f6ljts, vilket g\u00f6r att blocket inte kan accepteras ur PVRB:s synvinkel. S\u00e5 om det valda alternativet \u00e4r \"consensus-integrated\" blir PVRB en viktig del av konsensus.<\/p>\n<p><\/p>\n<p>N\u00e4r man beskriver implementationer av PVRB p\u00e5 konsensusniv\u00e5 i n\u00e4tverket f\u00e5r man under inga omst\u00e4ndigheter hoppa \u00f6ver fr\u00e5gorna kring finalitet. Finalitet \u00e4r en mekanism som anv\u00e4nds i deterministiska konsensusf\u00f6rfaranden f\u00f6r att fastst\u00e4lla ett block (och kedjan som leder till det) som \u00e4r slutgiltigt och aldrig kommer att raderas, \u00e4ven om en parallell gaffel dyker upp. Till exempel finns det ingen s\u00e5dan mekanism i Bitcoin \u2014 om man publicerar en kedja med st\u00f6rre sv\u00e5righetsgrad, kommer den att ers\u00e4tta vilken mindre sv\u00e5righetsgrad som helst, oavsett l\u00e4ngd p\u00e5 kedjorna. I EOS, \u00e5 andra sidan, \u00e4r de s\u00e5 kallade Last Irreversible Blocks slutgiltiga, och de dyker upp i genomsnitt var 432:a block (12*21 + 12*15, pre-vote + pre-commit). Denna process \u00e4r i grunden en v\u00e4ntan p\u00e5 2\/3 av underskrifterna fr\u00e5n blockproducenterna (BP). N\u00e4r forkar dyker upp som \u00e4r \u00e4ldre \u00e4n den senaste LIB, kasseras de helt enkelt. Denna mekanism g\u00f6r det m\u00f6jligt att garantera att en transaktion ing\u00e5r i blockchainen och aldrig kommer att rullas tillbaka, oavsett vilka resurser angriparen har. Dessutom \u00e4r slutgiltiga block \u00e4ven de block som \u00e4r signerade av 2\/3 av BP i Hyperledger, Tendermint och andra pBFT-baserade konsensusl\u00f6sningar. \u00c4ven protokollet f\u00f6r att s\u00e4kerst\u00e4lla finalitet har meningsfullt att g\u00f6ra som en \u00f6verbyggnad ovanp\u00e5 konsensus, eftersom det kan fungera asynkront med produktionen och publiceringen av block. <noindex><a rel=\"nofollow\" href=\"https:\/\/arxiv.org\/pdf\/1710.09437.pdf\">artikeln<\/a><\/noindex> om slutgiltighet i Ethereum.<\/p>\n<p><\/p>\n<p>Slutgiltighet \u00e4r extremt viktigt f\u00f6r anv\u00e4ndare som utan den kan bli offer f\u00f6r \"double spend\"-attacker, n\u00e4r BP \"h\u00e5ller tillbaka\" blocken och publicerar dem efter att n\u00e4tverket \"sett\" en bra transaktion. Om det inte finns n\u00e5gon slutgiltighet, kommer det publicerade forken att ers\u00e4tta blocket med den \"bra\" transaktionen med ett fr\u00e5n \"d\u00e5lig\" forken, d\u00e4r samma medel\u00f6verf\u00f6ringar g\u00f6rs till angriparens adress. I fallet med PVRB sk\u00e4rps kraven p\u00e5 slutgiltighet ytterligare, eftersom byggandet av forkar f\u00f6r PVRB inneb\u00e4r att angriparen kan f\u00f6rbereda flera randomiseringsalternativ f\u00f6r att publicera det mest f\u00f6rdelaktiga f\u00f6r sig sj\u00e4lv, och begr\u00e4nsa tiden f\u00f6r en m\u00f6jlig attack - en bra l\u00f6sning.<\/p>\n<p><\/p>\n<p>D\u00e4rf\u00f6r \u00e4r det b\u00e4sta alternativet att kombinera PVRB och slutgiltighet i ett enda protokoll - d\u00e5 blir ett slutgiltigt block = slutgiltig randomisering, och det \u00e4r precis vad som beh\u00f6vdes. Nu kommer spelarna att f\u00e5 garanterad randomisering inom N sekunder, och kan vara s\u00e4kra p\u00e5 att det inte g\u00e5r att rulla tillbaka eller spela om det.<\/p>\n<p><\/p>\n<p>Alternativet med consensus-integrated \u00e4r bra:<\/p>\n<p><\/p>\n<ul>\n<li>m\u00f6jlighet till asynkron implementering i f\u00f6rh\u00e5llande till blockproduktion - blocken produceras som vanligt, men samtidigt kan protokollet PVRB arbeta, vilket producerar randomiseringar inte varje block<\/li>\n<li>m\u00f6jlighet att implementera \u00e4ven tung kryptografi, utan begr\u00e4nsningar som finns p\u00e5 smarta kontrakt<\/li>\n<li>m\u00f6jlighet att organisera meddelandeutbyte snabbare \u00e4n transaktioner inkluderas i blockchain, till exempel kan en del av protokollet arbeta mellan noder utan att sprida meddelanden genom n\u00e4tverket<\/li>\n<\/ul>\n<p><\/p>\n<p>Det har ocks\u00e5 nackdelar:<\/p>\n<p><\/p>\n<ul>\n<li>sv\u00e5righeter vid testning och utveckling - man m\u00e5ste emulera n\u00e4tverksfel, bortfall av noder, h\u00e4mta h\u00e5rt-kotade n\u00e4tverk<\/li>\n<li>fel i implementeringen kr\u00e4ver en h\u00e5rd gaffel av n\u00e4tverket<\/li>\n<\/ul>\n<p><\/p>\n<p>B\u00e5da implementeringsmetoderna f\u00f6r PVRB har r\u00e4tt att existera, men implementeringen p\u00e5 smarta kontrakt i moderna blockkedjor \u00e4r \u00e4nd\u00e5 ganska kraftigt begr\u00e4nsad av ber\u00e4kningsresurser, och varje \u00f6verg\u00e5ng till seri\u00f6s kryptografi \u00e4r ofta helt enkelt om\u00f6jlig. Och vi kommer att beh\u00f6va seri\u00f6s kryptografi, vilket kommer att demonstreras nedan. \u00c4ven om detta problem har en tydligt tempor\u00e4r karakt\u00e4r, beh\u00f6vs seri\u00f6s kryptografi i kontrakt f\u00f6r att l\u00f6sa m\u00e5nga uppgifter, och den dyker gradvis upp (till exempel systemkontrakt f\u00f6r zkSNARKs i Ethereum).<\/p>\n<p><\/p>\n<p>Blockchain, som s\u00e4kerst\u00e4ller en transparent och p\u00e5litlig kommunikationskanal f\u00f6r protokollet, kostar inte gratis. Alla decentraliserade protokoll m\u00e5ste beakta risken f\u00f6r Sybil-attacker, eftersom vilka handlingar som helst kan utf\u00f6ras av en \u00f6verenskommen m\u00e4ngd konton, d\u00e4rf\u00f6r m\u00e5ste man vid designen ta h\u00e4nsyn till angriparnas m\u00f6jligheter att skapa ett godtyckligt antal medlemmar i protokollet som agerar i samf\u00f6rst\u00e5nd. <\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-peremennye-bloka\">PVRB och blockvariabler.<\/h2>\n<p><\/p>\n<p>Jag lj\u00f6g inte n\u00e4r jag sa att en bra PVRB, som testats av m\u00e5nga gambling-appar, hittills inte har implementerats i blockkedjor. Varifr\u00e5n kom d\u00e5 alla dessa gambling-appar i Ethereum och EOS? Det f\u00f6rv\u00e5nar mig lika mycket som er; hur fick man fram s\u00e5 m\u00e5nga \u201dbest\u00e4ndiga\u201d slumpm\u00e4ssigheter i en helt deterministisk milj\u00f6?<\/p>\n<p><\/p>\n<p>Det vanligaste s\u00e4ttet att f\u00e5 fram slumpm\u00e4ssighet i blockkedjan \u00e4r att anv\u00e4nda n\u00e5gon form av \u201dof\u00f6ruts\u00e4gbar\u201d information fr\u00e5n blocket och skapa slumpm\u00e4ssighet utifr\u00e5n detta genom att hash-a ett eller flera v\u00e4rden. En bra artikel om problemen med s\u00e5dana scheman. <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.positive.com\/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620\">h\u00e4r<\/a><\/noindex>Man kan ta n\u00e5got av de \u201dof\u00f6ruts\u00e4gbara\u201d v\u00e4rdena i blocket, som blockhash, antal transaktioner, n\u00e4tverkets sv\u00e5righetsgrad och andra v\u00e4rden som inte \u00e4r k\u00e4nda p\u00e5 f\u00f6rhand. Sedan kan man hash-a dem, ett eller flera, och i teorin borde man f\u00e5 riktig slumpm\u00e4ssighet. Man kan till och med n\u00e4mna i whitepaper att ens schema \u00e4r \u201dpost-quantum secure\u201d (eftersom det finns kvantresistenta hash-funktioner :)).<\/p>\n<p><\/p>\n<p>Men \u00e4ven post-quantum resistenta hash-funktioner r\u00e4cker tyv\u00e4rr inte. Hemligheten ligger i kraven f\u00f6r PVRB, som jag p\u00e5minner om fr\u00e5n den tidigare artikeln:<\/p>\n<p><\/p>\n<ol>\n<li>Resultatet m\u00e5ste ha ett bevisligen j\u00e4mnt f\u00f6rdelat resultat, dvs baserat p\u00e5 bevisligen s\u00e4ker kryptografi.<\/li>\n<li>Ingen bit av resultatet kan kontrolleras. Som en f\u00f6ljd kan resultatet inte f\u00f6ruts\u00e4gas i f\u00f6rv\u00e4g.<\/li>\n<li>Protokollet f\u00f6r generation f\u00e5r inte saboteras genom att inte delta i protokollet eller genom att \u00f6verbelasta n\u00e4tverket med attackerande meddelanden.<\/li>\n<li>Allt ovanst\u00e5ende m\u00e5ste vara motst\u00e5ndskraftigt mot sammansv\u00e4rjningar av ett till\u00e5tet antal o\u00e4rliga deltagare i protokollet (t.ex. 1\/3 av deltagarna).<\/li>\n<\/ol>\n<p><\/p>\n<p>I det h\u00e4r fallet f\u00f6ljs endast krav 1, och krav 2 f\u00f6ljs inte. Genom att hashera of\u00f6ruts\u00e4gbara v\u00e4rden fr\u00e5n blocket f\u00e5r vi en j\u00e4mn f\u00f6rdelning och bra slumpm\u00e4ssighet. Men BP har \u00e5tminstone m\u00f6jligheten att \"publicera blocket eller inte\". S\u00e5ledes kan BP \u00e5tminstone v\u00e4lja mellan TV\u00c5 alternativ av slumpm\u00e4ssighet: \"sitt\" och det som blir om blocket g\u00f6rs av n\u00e5gon annan. BP kan p\u00e5 f\u00f6rhand \"tjuvkika\" p\u00e5 vad som kommer att h\u00e4nda om han publicerar blocket och helt enkelt besluta att g\u00f6ra det eller inte. S\u00e5ledes, genom att spela till exempel \"j\u00e4mnt-oj\u00e4mnt\" eller \"r\u00f6d\/svart\" i roulette, kan han publicera blocket endast om han ser att det blir en vinst. Detta g\u00f6r ocks\u00e5 strategin f\u00f6r att anv\u00e4nda, till exempel, hash av blocket \"fr\u00e5n framtiden\" ineffektiv. I detta fall s\u00e4gs det att \"en slumpm\u00e4ssighet kommer att anv\u00e4ndas, som f\u00e5s genom att hashera nuvarande data och hashen av det framtida blocket p\u00e5 en h\u00f6jd, till exempel N + 42, d\u00e4r N \u00e4r den nuvarande h\u00f6jden av blocket. Detta f\u00f6rst\u00e4rker schemat n\u00e5got, men ger fortfarande BP, om \u00e4n i framtiden, m\u00f6jligheten att v\u00e4lja att h\u00e5lla tillbaka blocket eller publicera det.<\/p>\n<p><\/p>\n<p>BP:s mjukvara kompliceras i detta fall, men inte mycket. Vid validering och inkludering av transaktionen i blocket g\u00f6rs en snabb kontroll f\u00f6r att se om det blir en vinst, och m\u00f6jligtvis justering av en parameter i transaktionen f\u00f6r att f\u00e5 h\u00f6g sannolikhet f\u00f6r vinst. Samtidigt \u00e4r det n\u00e4stan om\u00f6jligt att f\u00e5nga en smart BP med s\u00e5dana manipulationer, varje g\u00e5ng kan nya adresser anv\u00e4ndas, och vinna lite \u00e5t g\u00e5ngen utan att v\u00e4cka misstankar.<\/p>\n<p><\/p>\n<p>S\u00e5 s\u00e4tt som anv\u00e4nder information fr\u00e5n blocket \u00e4r inte l\u00e4mpade som en universell implementation av PVRB. I en begr\u00e4nsad version, med begr\u00e4nsningar p\u00e5 insatsstorlekar, begr\u00e4nsningar p\u00e5 antal spelare och\/eller KYC-registrering (f\u00f6r att inte ge en spelare m\u00f6jlighet att anv\u00e4nda flera adresser), kan dessa scheman fungera f\u00f6r sm\u00e5 spel, men inte mer \u00e4n s\u00e5.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-commit-reveal\">PVRB och commit-reveal.<\/h2>\n<p><\/p>\n<p>Okej, tack vare hashning och \u00e5tminstone den relativa of\u00f6ruts\u00e4gbarheten av blockhash och andra variabler. Om vi kan l\u00f6sa problemet med minerarnas front-running, borde vi f\u00e5 n\u00e5got mer solid. L\u00e5t oss l\u00e4gga till anv\u00e4ndare i detta schema - l\u00e5t dem ocks\u00e5 p\u00e5verka slumpen: vilken teknisk supportanst\u00e4lld som helst kommer att s\u00e4ga att det mest slumpm\u00e4ssiga i IT-system \u00e4r anv\u00e4ndarnas beteende \ud83d\ude42<\/p>\n<p><\/p>\n<p>En naiv plan d\u00e4r anv\u00e4ndare bara skickar slumpm\u00e4ssiga nummer och resultatet ber\u00e4knas som till exempel hash av deras summa fungerar inte. I det h\u00e4r fallet kan den sista spelaren, genom att v\u00e4lja sin egen slumpm\u00e4ssighet, kontrollera vilket resultat som blir. D\u00e4rf\u00f6r anv\u00e4nds ett mycket v\u00e4lk\u00e4nt m\u00f6nster, commit-reveal. Deltagarna skickar f\u00f6rst hash av sina slumpm\u00e4ssigheter (commits), och sedan \u00f6ppnar de sina slumpm\u00e4ssigheter (reveal). Fasens \"reveal\" b\u00f6rjar f\u00f6rst efter att n\u00f6dv\u00e4ndiga commits har samlats in, s\u00e5 deltagarna kan skicka exakt den slumpm\u00e4ssighet vars hash de skickade tidigare. Nu kan vi kombinera allt detta med blockparameterar, g\u00e4rna h\u00e4mtat fr\u00e5n framtiden (slumptalet kan endast k\u00e4nnedom i ett av framtida block), och voil\u00e0 \u2013 slumptalet \u00e4r klart! Nu p\u00e5verkar varje spelare det resulterande slumptalet och kan \"vinna\" \u00f6ver den illvilliga BP genom att t\u00e4cka hans slumpm\u00e4ssighet med sin egen, som inte \u00e4r k\u00e4nd i f\u00f6rv\u00e4g... Vi kan ocks\u00e5 l\u00e4gga till skydd mot sabotage av protokollet genom att inte avsl\u00f6ja i reveal-steget \u2013 bara kr\u00e4va att en viss summa bifogas transaktionen vid commit \u2013 en f\u00f6rs\u00e4kringsdeposition som endast \u00e5terbetalas vid reveal-processen. I detta fall skulle det vara ol\u00f6nsamt att g\u00f6ra commit och inte g\u00f6ra reveal.<\/p>\n<p><\/p>\n<p>Det var ett bra f\u00f6rs\u00f6k, och s\u00e5dana planer finns ocks\u00e5 i spel-DApp:ar, men tyv\u00e4rr \u00e4r det \u00e5terigen inte tillr\u00e4ckligt. Nu kan resultatet p\u00e5verkas inte bara av miner, utan \u00e4ven av varje deltagare i protokollet. Att kontrollera v\u00e4rdet i sig kan fortfarande g\u00f6ras, med en l\u00e4gre grad av variation och f\u00f6r pengar, men, precis som i fallet med minern, om resultaten av utlottningen \u00e4r mer v\u00e4rdefulla \u00e4n kostnaden f\u00f6r deltagande i PVRB-protokollet, kan random-producer (RP) besluta om han ska g\u00f6ra reveal och kan fortfarande v\u00e4lja mellan minst tv\u00e5 alternativ f\u00f6r slumpm\u00e4ssighet.<br \/>\nMen nu finns m\u00f6jligheten att straffa de som g\u00f6r commit och inte g\u00f6r reveal, och detta m\u00f6nster kommer fortfarande att vara anv\u00e4ndbart. Dess enkelhet \u00e4r en stor f\u00f6rdel \u2013 mer komplexa protokoll kr\u00e4ver mycket kraftigare ber\u00e4kningar.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-determinirovannye-podpisi\">PVRB och deterministiska signaturer.<\/h2>\n<p><\/p>\n<p>Det finns ett annat s\u00e4tt att f\u00e5 RP att ge ett pseudorandomnummer, som hen inte kan p\u00e5verka, om hen ges en \"prototyp\" \u2014 det \u00e4r en deterministisk signatur. Denna signatur kan till exempel vara RSA, men inte ECS. Om RP har ett nyckelpar: RSA och ECC, och hen signerar ett visst v\u00e4rde med sin privata nyckel, s\u00e5 f\u00e5r hen med RSA ENDAST EN signatur, medan hen med ECS kan generera ett antal olika giltiga signaturer. Detta beror p\u00e5 att vid skapandet av en ECS-signatur anv\u00e4nds ett slumpm\u00e4ssigt nummer som v\u00e4ljs av signat\u00e4ren, och det kan v\u00e4ljas p\u00e5 vilket s\u00e4tt som helst, vilket ger signat\u00e4ren m\u00f6jlighet att v\u00e4lja mellan flera signaturer. I fallet med RSA: \"ett indata-v\u00e4rde\" + \"ett nyckelpar\" = \"en signatur\". Det \u00e4r om\u00f6jligt att f\u00f6ruts\u00e4ga vilken signatur en annan RP kommer att f\u00e5, d\u00e4rf\u00f6r kan PVRB med deterministiska signaturer organiseras genom att kombinera RSA-signaturer fr\u00e5n flera deltagare som signerat samma v\u00e4rde. Till exempel \u2014 en tidigare slump. I ett s\u00e5dant system sparas m\u00e5nga resurser, eftersom signaturerna fungerar b\u00e5de som bekr\u00e4ftelse p\u00e5 korrekt beteende enligt protokollet samt som en k\u00e4lla till slumpen.<\/p>\n<p><\/p>\n<p>\u00c4nd\u00e5, \u00e4ven med deterministiska signaturer \u00e4r systemet fortfarande s\u00e5rbart f\u00f6r problemet \"last actor\". Den sista deltagaren kan fortfarande best\u00e4mma om hen vill publicera sin signatur eller inte, vilket ger hen kontroll \u00f6ver resultatet. Det g\u00e5r att vidareutveckla systemet, l\u00e4gga till blockhashar, skapa rundor f\u00f6r att f\u00f6ruts\u00e4ga resultatet i f\u00f6rv\u00e4g, men alla dessa metoder, trots m\u00e5nga f\u00f6rb\u00e4ttringar, l\u00e4mnar \u00e4nd\u00e5 problemet med p\u00e5verkan fr\u00e5n en enskild deltagare p\u00e5 det kollektiva resultatet i en os\u00e4ker milj\u00f6 ol\u00f6st och kan endast fungera under ekonomiska och tidsm\u00e4ssiga begr\u00e4nsningar. Dessutom \u00e4r storleken p\u00e5 RSA-nycklar (1024 och 2048 bitar) ganska stor, och storleken f\u00f6r blockchain-transaktioner \u00e4r en extremt viktig parameter. Det verkar som om vi inte enkelt kan l\u00f6sa problemet, s\u00e5 vi g\u00e5r vidare.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-secret-sharing-shemy\">PVRB och secret sharing-system<\/h2>\n<p><\/p>\n<p>In kryptografi finns det scheman som kan l\u00e5ta n\u00e4tverket komma \u00f6verens om ett och endast ett v\u00e4rde av PVRB, och dessa scheman \u00e4r motst\u00e5ndskraftiga mot alla illvilliga handlingar fr\u00e5n vissa deltagare. En av de anv\u00e4ndbara protokollen som \u00e4r v\u00e4rt att bekanta sig med \u00e4r Shamir's hemlighetsdelningsschema. Det anv\u00e4nds f\u00f6r att dela en hemlighet (till exempel en hemlig nyckel) i flera delar och distribuera dessa delar till N deltagare. Hemligheten f\u00f6rdelas p\u00e5 ett s\u00e4tt som g\u00f6r att f\u00f6r att \u00e5terst\u00e4lla den r\u00e4cker med M delar av N, och det kan vara vilka som helst av M delar. Om vi f\u00f6renklar det, s\u00e5 utbyter deltagarna punkter p\u00e5 en graf av en ok\u00e4nd funktion, och efter att ha f\u00e5tt M punkter kan hela funktionen \u00e5terst\u00e4llas.<br \/>\nEn bra f\u00f6rklaring ges i <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Shamir%27s_Secret_Sharing\">wiki<\/a><\/noindex> och att faktiskt leka med det f\u00f6r att f\u00e5 protokollet att fastna i huvudet \u00e4r anv\u00e4ndbart p\u00e5 <noindex><a rel=\"nofollow\" href=\"http:\/\/point-at-infinity.org\/ssss\/demo.html\">demo<\/a><\/noindex> sidan.<\/p>\n<p><\/p>\n<p>Om FSSS (Fiat-Shamir Secret Sharing) schemat skulle kunna till\u00e4mpas i sin renaste form \u2013 skulle det vara ett o\u00f6vervinneligt PVRB. I sin mest grundl\u00e4ggande form kan protokollet se ut s\u00e5 h\u00e4r:<\/p>\n<p><\/p>\n<ul>\n<li>Varje deltagare genererar sin egen slumpm\u00e4ssiga och ger ut shares fr\u00e5n den till de \u00f6vriga deltagarna<\/li>\n<li>Varje deltagare avsl\u00f6jar sin del av de andra deltagarnas hemligheter<\/li>\n<li>Om det f\u00f6r en deltagare har samlats mer \u00e4n M shares, kan den deltagarens nummer ber\u00e4knas och det kommer att vara unikt, oavsett upps\u00e4ttningen av avsl\u00f6jade deltagare<\/li>\n<li>Kombinationen av de avsl\u00f6jade random-v\u00e4rdena \u00e4r den eftertraktade PVRB<\/li>\n<\/ul>\n<p><\/p>\n<p>H\u00e4r p\u00e5verkar enskilda deltagare inte protokollets resultat, utom i de fall d\u00e4r det bara beror p\u00e5 dem att uppn\u00e5 tr\u00f6skeln f\u00f6r avsl\u00f6jandet av den slumpm\u00e4ssiga. D\u00e4rf\u00f6r, om den erforderliga andelen som arbetar enligt protokollet och tillg\u00e4ngliga RP \u00e4r uppfyllt, fungerar detta protokoll och uppfyller kraven f\u00f6r kryptografisk motst\u00e5ndskraft och \u00e4r robust mot \"last actor\"-problemet.<\/p>\n<p><\/p>\n<p>Detta skulle kunna vara det perfekta alternativet, detta PVRB-schema baserat p\u00e5 hemlighetsdelning av Fiat-Shamir beskrivs till exempel i <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2017\/216.pdf\">denna<\/a><\/noindex> artikeln. Men, som n\u00e4mnts tidigare, om man f\u00f6rs\u00f6ker till\u00e4mpa det bokstavligt i blockchain, uppst\u00e5r tekniska begr\u00e4nsningar. H\u00e4r \u00e4r ett exempel p\u00e5 en testimplementering av protokollet i smartkontraktet EOS och den mest viktiga delen av det \u2014 kontroll av den publicerade share fr\u00e5n deltagaren: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/mixbytes\/eoscraper\/blob\/master\/Proof.hh#L23\">kod<\/a><\/noindex>. Koden visar att valideringen av proofet kr\u00e4ver flera skal\u00e4ra multiplikationer, och siffrorna som anv\u00e4nds \u00e4r mycket stora. Det \u00e4r viktigt att f\u00f6rst\u00e5 att i blockkedjor sker verifieringen n\u00e4r blockproducenten bearbetar transaktionen, och varje deltagare m\u00e5ste enkelt kunna verifiera korrektheten av protokollet, s\u00e5 kraven p\u00e5 hastighet f\u00f6r verifieringsfunktionen \u00e4r mycket strikta. I denna version visade sig alternativet vara ofunktionellt, eftersom verifieringen inte h\u00f6ll sig inom transaktionsgr\u00e4nsen (0,5 sek).<\/p>\n<p><\/p>\n<p>Effektiviteten i verifieringen \u00e4r ett av de viktigaste kraven f\u00f6r anv\u00e4ndning av i huvudsak alla avancerade kryptografiska scheman i blockkedjan. Att skapa proofs, f\u00f6rbereda meddelanden \u2014 dessa procedurer kan utf\u00f6ras off-chain och p\u00e5 h\u00f6gpresterande datorer, men att kringg\u00e5 verifieringen \u00e4r inte m\u00f6jligt \u2014 det \u00e4r ytterligare ett viktigt krav f\u00f6r PVRB. <\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-threshold-signatures\">PVRB och threshold-signaturer<\/h2>\n<p><\/p>\n<p>Genom att bekanta oss med schemat f\u00f6r secret sharing har vi \u00f6ppnat en hel klass av protokoll som f\u00f6renas av nyckelordet \"threshold\". N\u00e4r M \u00e4r antalet \u00e4rliga deltagare som kr\u00e4vs av N f\u00f6r att avsl\u00f6ja viss information, och upps\u00e4ttningen av \u00e4rliga deltagare kan vara vilken som helst delm\u00e4ngd av N, talar vi om \"threshold\"-scheman. Dessa g\u00f6r det m\u00f6jligt att l\u00f6sa problemet med 'last actor', eftersom om en angripare inte avsl\u00f6jar sin del av hemligheten, kommer en annan \u00e4rlig deltagare att g\u00f6ra det. Dessa scheman m\u00f6jligg\u00f6r att man enas om ett och endast ett v\u00e4rde, \u00e4ven vid sabotage av protokollet av en del av deltagarna. <\/p>\n<p><\/p>\n<p>Kombinationen av deterministiska signaturer och threshold-scheman har lett till utvecklingen av ett mycket praktiskt och lovande schema f\u00f6r att implementera PVRB \u2014 det \u00e4r deterministiska threshold-signaturer. H\u00e4r \u00e4r <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2002\/081.pdf\">artikeln<\/a><\/noindex> om olika till\u00e4mpningar av threshold-signaturer, och h\u00e4r \u00e4r ytterligare en bra <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.dash.org\/secret-sharing-and-threshold-signatures-with-bls-954d1587b5f\">l\u00e5ngl\u00e4sning<\/a><\/noindex> fr\u00e5n Dash. <\/p>\n<p><\/p>\n<p>Den senaste artikeln beskriver BLS-signaturer (BLS st\u00e5r f\u00f6r Boneh-Lynn-Shacham, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.iacr.org\/archive\/asiacrypt2001\/22480516.pdf\">h\u00e4r<\/a><\/noindex> artikel ), som har en mycket viktig och extremt bekv\u00e4m egenskap f\u00f6r programmerare \u2013 publika, hemliga, publika nycklar och BLS-signaturer kan kombineras med varandra genom enkla matematiska operationer, och deras kombinationer f\u00f6rblir giltiga nycklar och signaturer, vilket m\u00f6jligg\u00f6r enkel aggregat av m\u00e5nga signaturer till en och m\u00e5nga publika nycklar till en. De har \u00e4ven determinism och ger samma resultat vid samma ing\u00e5ngsv\u00e4rden. Tack vare denna egenskap \u00e4r kombinationerna av BLS-signaturer sj\u00e4lva giltiga nycklar, vilket m\u00f6jligg\u00f6r en variant d\u00e4r M av N deltagare producerar en och endast en signatur, som \u00e4r deterministisk, publikt verifierbar och of\u00f6ruts\u00e4gbar tills den avsl\u00f6jas av den M:e deltagaren.<\/p>\n<p><\/p>\n<p>I systemet med threshold BLS-signaturer skriver varje deltagare under n\u00e5got med hj\u00e4lp av BLS (till exempel den tidigare slumpen), och den totala threshold-signaturen \u00e4r den eftertraktade slumptal. De kryptografiska egenskaperna hos BLS-signaturer uppfyller kraven f\u00f6r kvaliteten p\u00e5 slump, threshold-delen skyddar mot \"last-actor\", och den unika kombinerbarheten av nycklar m\u00f6jligg\u00f6r implementeringen av m\u00e5nga intressanta algoritmer som till exempel effektivt kan aggregera meddelanden fr\u00e5n protokollet.<\/p>\n<p><\/p>\n<p>S\u00e5 om du bygger PVRB i din blockchain, kommer du med stor sannolikhet att landa p\u00e5 en BLS threshold-signaturschema, och flera projekt anv\u00e4nder den redan. Till exempel DFinity (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dfinity\/random-beacon\">h\u00e4r<\/a><\/noindex> benchmark som implementerar schemat, och <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dfinity\/vss\/blob\/master\/docs\/index.md\">). Ett typiskt exempel p\u00e5 anv\u00e4ndning:<\/a><\/noindex> exempel p\u00e5 implementering av verifierbar hemlig delning), eller Keep.network (h\u00e4r \u00e4r deras slumptal <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/keep-network\/random-beacon-yellowpaper\">yellowpaper<\/a><\/noindex>, och h\u00e4r \u00e4r <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/keep-network\/random-beacon-box\">exempel<\/a><\/noindex> smartkontraktet som betj\u00e4nar protokollet).<\/p>\n<p><\/p>\n<h2 id=\"implementaciya-pvrb\">Implementering av PVRB<\/h2>\n<p><\/p>\n<p>Tyv\u00e4rr ser vi fortfarande inte ett f\u00e4rdigt protokoll, implementerat i blockchain PVRB, som har bevisats vara s\u00e4kert och robust. \u00c4ven om protokollen \u00e4r klara \u00e4r det tekniskt sv\u00e5rt att till\u00e4mpa dem p\u00e5 befintliga l\u00f6sningar. F\u00f6r centraliserade system \u00e4r PVRB meningsl\u00f6st, och decentraliserade system \u00e4r strikt begr\u00e4nsade i alla ber\u00e4kningsresurser: CPU, minne, lagring, I\/O. Designen av PVRB handlar om att kombinera olika protokoll f\u00f6r att \u00e5stadkomma n\u00e5got som uppfyller alla krav f\u00f6r att kunna fungera som ett livskraftigt blockchain. Ett protokoll utf\u00f6r ber\u00e4kningar effektivare, men kr\u00e4ver fler meddelanden mellan RP, medan ett annat kr\u00e4ver mycket f\u00e4rre meddelanden men skapandet av proof kan ta tiotals minuter, ibland timmar.<\/p>\n<p><\/p>\n<p>Jag kommer att n\u00e4mna de faktorer som du m\u00e5ste ta h\u00e4nsyn till n\u00e4r du v\u00e4ljer en kvalitativ PVRB:<\/p>\n<p><\/p>\n<ul>\n<li><em>Kryptografisk styrka<\/em>. Din PVRB m\u00e5ste vara strikt obiaserbar, utan m\u00f6jlighet att kontrollera en enda bit. I vissa uppl\u00e4gg \u00e4r det inte s\u00e5, s\u00e5 kalla p\u00e5 en kryptograf.<\/li>\n<li><em>Problemet med \"last actor\"<\/em>. Din PVRB m\u00e5ste vara motst\u00e5ndskraftig mot attacker d\u00e4r en angripare som kontrollerar en eller flera RP kan v\u00e4lja mellan tv\u00e5 resultatalternativ.<\/li>\n<li><em>Problemet med sabotage av protokollet<\/em>. Din PVRB m\u00e5ste vara motst\u00e5ndskraftig mot attacker d\u00e4r en angripare som kontrollerar en eller flera RP beslutar om det ska vara slumpm\u00e4ssigt eller inte och kan garantera, eller med en given sannolikhet p\u00e5verka detta.<\/li>\n<li><em>Problemet med antalet meddelanden<\/em>. Dina RP m\u00e5ste skicka s\u00e5 f\u00e5 meddelanden som m\u00f6jligt till blockchain och maximalt undvika synkrona handlingar, som situationer d\u00e4r \"jag har skickat viss information, v\u00e4ntar p\u00e5 svar fr\u00e5n en specifik deltagare\". I p2p-n\u00e4tverk, s\u00e4rskilt geografiskt spridda, b\u00f6r man inte r\u00e4kna med snabba svar.<\/li>\n<li><em>Problemet med ber\u00e4kningskomplexitet<\/em>. Verifiering av vilket steg som helst i PVRB on-chain m\u00e5ste vara extremt l\u00e4tt, eftersom det utf\u00f6rs av alla fullst\u00e4ndiga noder i n\u00e4tverket. Om implementeringen g\u00f6rs med hj\u00e4lp av ett smart kontrakt \u00e4r kraven p\u00e5 hastighet mycket strikta.<\/li>\n<li><em>Problemet med tillg\u00e4nglighet och livsl\u00e4ngd<\/em>. Din PVRB b\u00f6r str\u00e4va efter att vara motst\u00e5ndskraftig mot situationer d\u00e4r en del av n\u00e4tverket blir otillg\u00e4ngligt under en tid och en del RP helt enkelt slutar att fungera.<\/li>\n<li><em>Problemet med trusted setup och den initiala distributionen av nycklar.<\/em>. Om din PVRB anv\u00e4nder prim\u00e4r setup-protokoll, \u00e4r detta en helt separat och allvarlig historia. H\u00e4r \u00e4r <noindex><a rel=\"nofollow\" href=\"https:\/\/z.cash\/ru\/blog\/the-design-of-the-ceremony\/\">exempel<\/a><\/noindex>. Om deltagarna m\u00e5ste meddela varandra sina nycklar innan protokollet b\u00f6rjar - \u00e4r detta ocks\u00e5 ett problem om deltagarna \u00e4ndras<\/li>\n<li><em>Utvecklingsproblem<\/em>. F\u00f6rekomsten av bibliotek p\u00e5 r\u00e4tt spr\u00e5k, deras s\u00e4kerhet och prestanda, offentlighet, komplexa tester, etc.<\/li>\n<\/ul>\n<p><\/p>\n<p>Till exempel har threshold BLS-signaturer ett betydande problem - innan de b\u00f6rjar arbeta m\u00e5ste deltagarna n\u00f6dv\u00e4ndigtvis dela ut sina nycklar och organisera en grupp inom vilken threshold kommer att fungera. Detta inneb\u00e4r att minst en runda utbyte i ett decentraliserat n\u00e4tverk m\u00e5ste v\u00e4nta, och med tanke p\u00e5 att det genererade slumpm\u00e4ssiga talet, till exempel, beh\u00f6vs i spel, praktiskt taget i realtid, inneb\u00e4r detta att sabotage av protokollet \u00e4r m\u00f6jligt vid detta stadium, och f\u00f6rdelarna med threshold-schemat f\u00f6rloras. Detta problem \u00e4r redan enklare \u00e4n det f\u00f6reg\u00e5ende, men det kr\u00e4ver fortfarande utvecklingen av en separat procedur f\u00f6r att bilda threshold-grupper, som m\u00e5ste skyddas ekonomiskt genom ins\u00e4ttningar och avskr\u00e4ckning av medel (slashing) fr\u00e5n deltagare som inte f\u00f6ljer protokollet. Dessutom ryms verifiering av BLS med acceptabel s\u00e4kerhetsniv\u00e5 helt enkelt inte, till exempel, inom en standardtransaktion i EOS eller Ethereum - det finns helt enkelt inte tillr\u00e4ckligt med tid f\u00f6r verifiering. Koden f\u00f6r kontrakten \u00e4r WebAssembly eller EVM, som k\u00f6rs av en virtuell maskin. Kryptografiska funktioner \u00e4r inte implementerade p\u00e5 ett nativt s\u00e4tt (\u00e4n), och arbetar tiotals g\u00e5nger l\u00e5ngsammare \u00e4n vanliga kryptografiska bibliotek. M\u00e5nga protokoll passar inte kraven helt enkelt baserat p\u00e5 volymen p\u00e5 nycklar, som till exempel 1024 och 2048 bit f\u00f6r RSA, 4-8 g\u00e5nger mer \u00e4n standardsignaturen i Bitcoin och Ethereum.<\/p>\n<p><\/p>\n<p>Det spelar ocks\u00e5 roll om det finns implementeringar p\u00e5 olika programmeringsspr\u00e5k - vilket \u00e4r f\u00e5, s\u00e4rskilt f\u00f6r nya protokoll. Alternativet med integration i konsensus kr\u00e4ver att protokollet skrivs p\u00e5 plattformens spr\u00e5k, s\u00e5 man m\u00e5ste leta efter kod p\u00e5 Go f\u00f6r geth, p\u00e5 Rust f\u00f6r Parity, p\u00e5 C++ f\u00f6r EOS. Koden p\u00e5 JavaScript m\u00e5ste alla leta efter, och eftersom JavaScript och kryptografi inte \u00e4r riktigt n\u00e4ra v\u00e4nner, hj\u00e4lper WebAssembly, som nu definitivt aspirerar p\u00e5 att bli n\u00e4sta viktiga internetstandard.<\/p>\n<p><\/p>\n<h2 id=\"zaklyuchenie\">Slutsats<\/h2>\n<p><\/p>\n<p>Jag hoppas, i det f\u00f6reg\u00e5ende <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/448330\/\">artikeln<\/a><\/noindex> Jag har lyckats \u00f6vertyga er om att generering av slumpm\u00e4ssiga tal p\u00e5 blockkedjan \u00e4r kritiskt viktig f\u00f6r m\u00e5nga aspekter av livet i decentraliserade n\u00e4tverk. Denna artikel visar att denna uppgift \u00e4r extremt ambiti\u00f6s och sv\u00e5r, men bra l\u00f6sningar finns redan. Generellt \u00e4r den slutgiltiga designen av protokollet m\u00f6jlig f\u00f6rst efter omfattande tester som tar h\u00e4nsyn till alla aspekter, fr\u00e5n setup till simulering av fel. D\u00e4rf\u00f6r kommer ni knappast att hitta f\u00e4rdiga recept i whitepapers fr\u00e5n team och artiklar, och inte heller kommer vi under det kommande \u00e5ret eller tv\u00e5 att v\u00e5ga skriva \u201cg\u00f6r s\u00e5 h\u00e4r, s\u00e5 \u00e4r det helt korrekt.\u201d <\/p>\n<p><\/p>\n<p>F\u00f6r v\u00e5r PVRB i den under utveckling blockkedjan <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/mixbytes\/haya\">Haya<\/a><\/noindex>, har vi stannat vid anv\u00e4ndningen av threshold BLS-signaturer. Vi planerar att implementera PVRB p\u00e5 konsensusniv\u00e5, eftersom verifiering i smarta kontrakt med en acceptabel s\u00e4kerhetsniv\u00e5 f\u00f6r n\u00e4rvarande \u00e4r om\u00f6jlig. Det \u00e4r m\u00f6jligt att vi anv\u00e4nder tv\u00e5 system: f\u00f6rst den kostsamma hemliga delningen f\u00f6r att skapa en l\u00e5ngsiktig random_seed, och den anv\u00e4nder vi sedan som grund f\u00f6r h\u00f6gfrekvent slumpgenerering med hj\u00e4lp av deterministiska threshold BLS-signaturer, eller s\u00e5 kan vi begr\u00e4nsa oss till bara ett av systemen. Det \u00e4r tyv\u00e4rr om\u00f6jligt att s\u00e4ga i f\u00f6rv\u00e4g hur protokollet kommer att se ut, men det gl\u00e4der oss att liksom i vetenskap \u00e4r ett negativt resultat ocks\u00e5 ett resultat inom ingenj\u00f6rsuppgifter, och varje nytt f\u00f6rs\u00f6k att l\u00f6sa problemet \u00e4r ett steg fram\u00e5t f\u00f6r alla som arbetar med denna fr\u00e5ga. F\u00f6r att uppfylla krav fr\u00e5n f\u00f6retaget l\u00f6ser vi en konkret praktisk uppgift \u2014 att f\u00f6rse spelapplikationer med en p\u00e5litlig k\u00e4lla till entropi, s\u00e5 vi m\u00e5ste ocks\u00e5 \u00e4gna uppm\u00e4rksamhet \u00e5t sj\u00e4lva blockkedjan, s\u00e4rskilt fr\u00e5gor om kedjans finalitet och n\u00e4tverkets governance. <\/p>\n<p><\/p>\n<p>Och \u00e4ven om vi f\u00f6r n\u00e4rvarande inte ser en bevisat robust PVRB i blockkedjor som har anv\u00e4nts tillr\u00e4ckligt l\u00e4nge f\u00f6r att klara tester av verkliga applikationer, flera revisioner, belastningar, och inte minst verkliga attacker, s\u00e5 bekr\u00e4ftar antalet m\u00f6jliga v\u00e4gar att en l\u00f6sning finns, och n\u00e5gon av dessa algoritmer kommer till slut att l\u00f6sa problemet. Vi ser fram emot att dela resultaten och tackar andra team som ocks\u00e5 arbetar med denna fr\u00e5ga f\u00f6r artiklar och kod som g\u00f6r det m\u00f6jligt f\u00f6r ingenj\u00f6rer att inte snubbla \u00f6ver samma hinder tv\u00e5 g\u00e5nger. <\/p>\n<p><\/p>\n<p>S\u00e5 n\u00e4r du m\u00f6ter en programmerare som designar en decentraliserad slumpgenerator, var uppm\u00e4rksam och omt\u00e4nksam, ge psykologiskt st\u00f6d om det beh\u00f6vs \ud83d\ude42<\/p>\n<p>K\u00e4lla: <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.4 - 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\/sv\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sv_SE\" \/>\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\/sv\/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\udd47Slumptal och decentraliserade n\u00e4tverk: implementationer | ProHoster","description":"Introduktion function getAbsolutelyRandomNumer() { return 4; \/\/ returnerar ett absolut slumpm\u00e4ssigt nummer!","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/33888","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=33888"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/33888\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=33888"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=33888"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=33888"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}