Introduktion

funktion getAbsolutelyRandomNumer() {
        return 4; // returnerer et absolut tilfældigt tal!
}

Ligesom med konceptet for absolut sikre koder fra kryptografi, forsøger de virkelige protokoller "Publicly Verifiable Random Beacon" (herefter PVRB) kun at nærme sig den ideelle model, da den i ren form ikke er anvendelig i virkelige netværk: der skal udelukkende aftales en enkelt bit, der skal være mange runder, og alle meddelelser skal være ekstremt hurtige og altid leveres. Naturligvis er dette ikke tilfældet i virkelige netværk. Derfor opstår 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ældighed og den kryptografiske modstandskraft.

Selve blockchainen fungerer som en kommunikationsplatform for PVRB, hvor meddelelser = transaktioner. Dette muliggør en delvis abstrahering fra netværksproblemer, manglende meddelelser, og problemer med mellemsoftwaren — alle disse risici påtager det decentraliserede netværk sig, og dens væsentligste værdi for PVRB er umuligheden af at tilbagekalde eller ødelægge en allerede sendt transaktion — det forhindrer deltagerne i at trække sig fra protokollen, medmindre de har udført et vellykket angreb på konsensus. Dette sikkerhedsniveau er acceptabelt, hvorfor PVRB skal være modstandsdygtig over for konspirering blandt deltagerne i samme grad som den primære blockchain. Det antyder også, at PVRB skal være en del af konsensus, hvis netværket har enighed om den primære blokkæde, så må det også finde enighed om en enkelt ærlig resultat tilfældighed. Alternativt kan PVRB være en simpel selvstændig protokol implementeret ved hjælp 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ærdeles komplekst.

To metoder til implementering af PVRB

Lad os se nærmere på to varianter af implementeringen af PVRB — en selvstændig version, der anvender en blockchain-uafhængig smart kontrakt, og en consensus-integreret version — indbygget i protokollen, hvorefter netværket når til enighed om blokkæden og inkluderede transaktioner. I alle tilfælde vil jeg have in mente populære blockchain-motorer: Ethereum, EOS, og alle der ligner dem med hensyn til måde at implementere og behandle smart kontrakter.

Standalone kontrakt

I denne version fungerer PVRB som en smart kontrakt, der modtager transaktioner fra random-producenter (herefter RP), behandler dem, kombinerer resultaterne og når et værdiniveau, som enhver bruger kan få fra denne kontrakt. Denne værdi behøver ikke at være gemt direkte i kontrakten, men kan kun præsenteres gennem data, hvilket muliggør en entydig bestemmelse af det resulterende tilfældige tal. I dette skema er RP brugere af blockchainen, og enhver kan få lov til at deltage i genereringen af tal.

Standalone kontrakt er god:

bærbarhed (kontrakter kan flyttes fra blockchain til blockchain)
simpel implementering og testning (det er nemt at skrive og teste kontrakter)
bekvemmelighed i implementering af økonomiske ordninger (det er let at oprette sin egen token, hvis logik tjener PVRB's formål)
muligheden for at køre i allerede eksisterende blockchains

Men den har også ulemper:

store begrænsninger på ressourcer ved beregninger, transaktionsvolumen og opbevaring (kort sagt cpu/mem/io)
begrænsninger på operationer inden for kontrakten (ikke alle instruktioner er tilgængelige, det er vanskeligt at tilslutte eksterne biblioteker)
umulighed af at organisere beskedudveksling hurtigere, end transaktioner bliver inkluderet i blockchainen

Denne version er egnet til implementering af PVRB, som skal køres i et allerede eksisterende netværk, ikke indeholder kompleks kryptografi og ikke kræver mange interaktioner.

Consensus-integreret

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ærket mellem noderne. Da protokollen resulterer i tal, som skal registreres i blokkene, skal netværket nå til enighed om dem. Dette betyder, at PVRB-meddelelser, ligesom transaktioner, skal valideres af noderne og inkluderes i blokkene, så enhver deltager i netværket kan validere overholdelsen af PVRB-protokollen. Dette fører os automatisk til den åbenlyse løsning — hvis netværket indgår enighed om en blok og transaktionerne heri, skal PVRB være en del af enigheden og ikke en separat protokol. Ellers kan der opstå 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å hvis den “consensus-integrated” mulighed vælges, bliver PVRB en vigtig del af enigheden.

Når man beskriver implementeringer af PVRB på enighedsniveau i netværket, må man på ingen måde undgå spørgsmålene om endelighed. Endelighed er en mekanisme, der anvendes i deterministiske konsensusmodeller, som fastsætter en blok (og kæden, der fører til den), der er endelig, og som aldrig vil blive kastet væk, selvom der opstår en parallel gaffel. For eksempel har Bitcoin ikke en sådan mekanisme — hvis der offentliggøres en kæde med større kompleksitet, vil den erstatte enhver mindre kompleks, uanset kædets længde. I EOS er de endelige blokke såkaldte 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å 2/3 af underskrifterne fra block-producerne (BP). Når der opstår gafler, der er ældre end den seneste LIB, bliver de blot forkastet. Denne mekanisme gør det muligt at garantere, at transaktionen er inkluderet i blockchainen og aldrig vil blive tilbageført, uanset hvilke ressourcer angriberen måtte 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å konsensus, da den kan fungere asynkront med produktionen og offentliggørelsen af blokke. Her er en god artikel om finalitet i Ethereum.

Finalitet er ekstremt vigtig for brugerne, der uden den kan blive ofre for en "double spend"-angreb, hvor BP "holder" blokke, og offentliggør dem efter at netværket "har set" en god transaktion. Hvis der ikke er nogen finalitet, så erstatter den offentliggjorte fork blokken med den "gode" transaktion med en anden fra den "dårlige" fork, hvor de samme midler overføres til angriberens adresse. I tilfælde af PVRB bliver kravene til finalitet endnu strammere, da opbygning af forks for PVRB giver angriberen mulighed for at forberede flere tilfældige varianter for at offentliggøre den mest fordelagtige for ham og begrænse muligt angrebstid — en god løsning.

Derfor er den bedste mulighed at kombinere PVRB og finalitet i én protokol — så bliver den finaliserede blok = den finaliserede tilfældighed, og det er præcis, hvad der skulle opnås. Nu vil spillerne få garanteret tilfældighed inden for N sekunder og kan være sikre på, at det hverken kan rulles tilbage eller spilles igen.

Muligheden med consensus-integreret er god:

muligheden for asynkron implementering i forhold til blokkens produktion — blokke produceres som sædvanligt, men parallelt med dette kan PVRB-protokollen fungere, som producerer tilfældigheder ikke for hver blok
muligheden for at implementere selv tung kryptografi uden de begrænsninger, der pålægges smarte kontrakter
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ærket

Men den har også ulemper:

vanskeligheder ved testning og udvikling — det bliver nødvendigt at emulere netværksfejl, forsvundne noder, hard forks i netværket
fejl i implementeringen kræver en hard fork af netværket

Begge måder at implementere PVRB på har ret til at eksistere, men implementeringen på smarte kontrakter i moderne blockchains er stadig ret begrænset i beregningsressourcer, og enhver overgang til seriøs kryptografi er ofte simpelthen umulig. Og vi har brug for seriøs kryptografi, som vil blive demonstreret senere. Selvom dette problem er tydeligt midlertidigt, er seriøs kryptografi i kontrakter nødvendig for at løse mange opgaver, og den dukker gradvist op (for eksempel systemkontrakter til zkSNARKs i Ethereum)

Blockchain, der sikrer et gennemsigtigt og pålideligt kommunikationskanal for protokollen, er ikke gratis. Enhver decentraliseret protokol skal tage højde for muligheden for Sybil-angreb, da enhver handling kan udføres af en sammensværgelse af flere konti. Derfor er det vigtigt at overveje angribernes muligheder for at skabe et vilkårligt antal deltagere i protokollen, der handler i samråd.

PVRB og blokvariabler.

Jeg løj ikke, da jeg sagde, at der ikke eksisterer et godt PVRB, valideret af mange gambling-applikationer, i blockchainer. Hvordan kan der så være så mange gambling-applikationer i Ethereum og EOS? Dette overrasker mig lige så meget som dig. Hvordan kan man finde så mange "modstandsdygtige" tilfældigheder i et fuldstændig deterministisk miljø?

En populær metode til at hente tilfældighed 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ærdier. En god artikel om problemerne ved sådanne ordninger. herMan kan tage en hvilken som helst af de "uventede" værdier i blokken, såsom blokhash, antal transaktioner, netværkets sværhedsgrad og andre, ukendte på forhånd værdier. Derefter kan man hash dem, en eller flere, og i teorien burde det resultere i ægte tilfældighed. Man kan endda tilføje i hvidbogen, at ens skema er "post-quantum secure" (da der findes kvante-sikre hash-funktioner :)).

Men selv post-quantum sikre hashes er desværre ikke nok. Hemmeligheden ligger i kravene til PVRB, som jeg mindede om i den tidligere artikel:

Resultatet skal have en beviseligt ensartet fordeling, dvs. baseret på beviseligt robust kryptografi.
Ingen af bits i resultatet kan kontrolleres. Som følge heraf kan resultatet ikke forudses på forhånd.
Man kan ikke saboterer protokollet til generering ved at undlade at deltage i protokollet eller ved at overbelaste netværket med angribermeddelser.
Alt det ovenstående skal være modstandsdygtigt over for sammensvérgelser fra et acceptabelt antal uærlige deltagere i protokollen (f.eks. 1/3 af deltagerne).

I dette tilfælde overholdes kun krav 1, og krav 2 overholdes ikke. Ved at hash'e uforudsigelige værdier fra blokken opnår vi en jævn fordeling og gode randomiseringer. Men BP har i det mindste muligheden for "at offentliggøre blokken eller ej". Dermed kan BP i det mindste vælge mellem TO randomiseringsmuligheder: "sin egen" og den, som vil komme, hvis blokken offentliggøres af en anden part. BP kan på forhånd "kigge ind", hvad der vil ske, hvis han offentliggør blokken, og så træffe en beslutning om at gøre det eller ej. Dermed kan han for eksempel i et spil "lige-ulige" eller "rød/sort" i roulette kun offentliggøre blokken, hvis han ser en gevinst. Dette gør også strategien med at bruge for eksempel blokkens hash "fra fremtiden" ineffektiv. I dette tilfælde siges det, at "der vil blive brugt en randomisering, som opnås ved hash'ing af de aktuelle data og hashen af den fremtidige blok med højden, for eksempel N + 42, hvor N er den nuværende blokhøjde. Det styrker lidt ordningen, men tillader stadig BP, om end i fremtiden, at vælge at tilbageholde blokken eller offentliggøre den.

BP-softwaren kompliceres en smule i dette tilfælde, men ikke voldsomt. Under valideringen og inkluderingen af transaktionen i blokken foretages en hurtig kontrol for at se, om der vil være en gevinst, og muligvis justerer en transaktionsparameter for at opnå en højere sandsynlighed for gevinst. Derudover er det næsten umuligt at fange en smart BP i sådanne manipulationer; man kan hver gang bruge nye adresser og vinde små gevinster uden at vække mistanke.

Derfor egner metoder, der anvender information fra blokken, sig ikke til en universel implementering af PVRB. I en begrænset version, med begrænsninger på indsatsstørrelser, begrænsninger på antallet af spillere og/eller KYC-registrering (for at forhindre én spiller i at bruge flere adresser), kan disse ordninger fungere til små spil, men ikke mere.

PVRB og commit-reveal.

Okay, tak til hashing og i det mindste den relative uforudsigelighed af blokhashen og andre variable. Hvis vi løser problemet med front-running fra minearbejderne, burde der komme noget, der er mere holdbart. Lad os tilføje brugerne til denne ordning — lad dem også påvirke randomiseringen: enhver medarbejder i teknisk support vil fortælle dig, at det mest randomiserede i IT-systemer er brugernes handlinger 🙂

Den naive metode, hvor brugerne bare sender tilfældige tal, og resultatet beregnes som for eksempel hashen af deres sum, er ikke god. I dette tilfælde kan den sidste spiller, ved at vælge sin egen tilfældige værdi, kontrollere hvilket resultat der vil komme. Derfor bruges mønsteret commit-reveal, der er meget udbredt. Deltagerne sender først hasher af deres tilfældige tal (commits), og derefter afslører de de faktiske værdier (reveals). Fasen 'reveal' begynder først, når de nødvendige commits er indsamlet, så deltagerne kan sende præcist den tilfældige værdi, hvis hash de har sendt tidligere. Nu kan vi kombinere alt dette med blokkens parametre, helst taget fra fremtiden (den tilfældige værdi vil først kunne kendt i en af fremtidens blokke), og voila — den tilfældige værdi er klar! Nu kan enhver spiller påvirke det endelige resultat, og kan 'vinde' over den ondsindede BP ved at dække hans tilfældige tal med sin egen, som ikke er kendt på forhånd… Desuden kan vi tilføje beskyttelse mod sabotering af protokollen ved at undgå at afsløre under reveal-fasen — blot ved at kræve, at der ved commit sendes et beløb — en sikkerhedsdepot, som kun returneres ved reveal-processen. I så fald vil det ikke være fordelagtigt at lave en commit og ikke lave en reveal.

Det var et godt forsøg, og sådanne ordninger findes også i spil-DApp'er, men desværre er det stadig ikke tilstrækkeligt. Nu kan resultatet påvirkes ikke kun af minearbejderen, men også af enhver deltager i protokollen. Man kan stadig kontrollere selve værdien, med en lavere grad af variabilitet og mod betaling, men som i tilfældet med minearbejderen, hvis resultaterne af lodtrækningen er mere værdifulde end gebyret for at deltage i PVRB-protokollen, så kan random-producer (RP) beslutte, om han vil afsløre sin værdi og kan stadig vælge mellem mindst to muligheder for en tilfældig værdi.
Der er dog mulighed for at straffe dem, der laver en commit og ikke laver en reveal, og denne ordning vil være nyttig. Dens enkelhed er en stor fordel — mere komplekse protokoller kræver langt mere kraftige beregninger.

PVRB og deterministiske signaturer.

Der er en anden måde at få RP til at levere et pseudotilfældigt tal, som han ikke kan påvirke, hvis han præsenteres for en "prototype" - det er en deterministisk signatur. En sådan signatur er for eksempel RSA, men ikke ECS. Hvis RP har et nøglepar: RSA og ECV, og han underskriver en værdi med sin private nøgle, så får han i tilfælde af RSA ÉN OG KUN ÉN signatur, mens han i tilfælde af ECS kan generere et vilkårligt antal forskellige gyldige signaturer. Dette skyldes, at der ved oprettelsen af en ECS-signatur bruges et tilfældigt tal, valgt af den, der underskriver, og det kan vælges på mange måder, hvilket giver den signerende mulighed for at vælge en af flere signaturer. I tilfælde af RSA: "én inputværdi" + "ét nøglepar" = "én 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ærdi. For eksempel - den forrige tilfældighed. I sådan et system spares der mange ressourcer, da signaturerne fungerer både som en bekræftelse af korrekt adfærd i henhold til protokollen og som en kilde til tilfældighed.

Selvom der stadig er deterministiske signaturer, er ordningen stadig sårbar over for "last actor"-problemet. Den sidste deltager kan stadig beslutte, om han vil offentliggøre sin signatur eller ej, og dermed kontrollere resultatet. Man kan optimere ordningen, tilføje hashes af blokke, lave runder for at forhindre forudsigelighed af resultatet, men alle disse tilgange, selv med mange forbedringer, efterlader stadig problemet med én deltagers indflydelse på det kollektive resultat i et usikkert miljø, og de kan kun fungere under økonomiske og tidsmæssige begrænsninger. Desuden er størrelsen af RSA-nøglerne (1024 og 2048 bit) ret stor, mens størrelsen for blockchain-transaktioner er en ekstremt vigtig parameter. Det ser ud til, at problemet ikke kan løses enkelt, lad os gå videre.

I kryptografi findes der ordninger, der kan lade et netværk blive enige om én og kun én værdi af PVRB, samtidig med at sådanne ordninger er modstandsdygtige over for enhver ondsindet adfærd 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øgle) op i flere dele og distribuere disse dele til N deltagere. Hemmeligheden fordeles på en måde, så man kun har brug for M dele ud af N for at genoprette den, hvor M kan være hvilke som helst dele. For at forklare det enkelt, så deltagerne udveksler punkter på grafen for en ukendt funktion, og efter at have modtaget M punkter, kan hele funktionen genskabes.
En god forklaring findes i wiki og det er praktisk at lege med det for at få protokollen til at give mening i hovedet på demo siden.

Hvis FSSS (Fiat-Shamir Secret Sharing) ordningen kunne anvendes i sin reneste form — ville det være en uovervindelig PVRB. I det enkleste tilfælde kan protokollen se således ud:

Hver deltager genererer sin egen tilfældige tal og distribuerer andele af det til de andre deltagere
Hver deltager afslører sin del af de andre deltageres hemmeligheder
Hvis en deltager har indsamlet mere end M andele, kan denne deltageres nummer beregnes, og det vil være unikt, uanset hvilke deltagere der afsløres
Kombinationen af de afslørede tilfældige tal er den eftertragtede PVRB

Her påvirker en enkelt deltager ikke resultaterne af protokollen, undtagen i de tilfælde, hvor det kun afhænger af ham at opnå tærsklen for afsløret random. Derfor fungerer denne protokol, så længe der er en nødvendig andel af deltagere, der arbejder iht. protokollen og tilgængelige RP, og opfylder kravene til kryptografisk sikkerhed, samtidig med at den er modstandsdygtig over for "last actor"-problemet.

Det kunne være den ideelle løsning, denne PVRB-ordning baseret på Fiat-Shamir hemmelighedsdeling er beskrevet, for eksempel i denne artiklen. Men, som nævnt tidligere, hvis man forsøger at anvende den direkte på blockchain, opstår der tekniske begrænsninger. Her er et eksempel på en testimplementering af protokollen i EOS smart contracten og dens mest centrale del — kontrollen af den offentliggjorte andel af deltageren: koden. Koden viser, at valideringen af proof kræver flere skalar multiplikationer, og tallene der bruges er meget store. Man skal forstå, at i blockchain-erne sker verifikation på 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ære uarbejdsdygtig, da verifikationen ikke kunne gennemføres inden for transaktionsgrænsen (0,5 sek).

Effektiviteten af verifikation er et af de vigtigste krav til brugen af næsten enhver avanceret kryptografisk ordning i blockchain. Oprettelse af proofs, forberedelse af meddelelser - disse procedurer kan udføres off-chain og køres på højtydende computere, men verifikation kan ikke undgås - det er et andet vigtigt krav til PVRB.

PVRB og threshold-signaturer

Efter at have gjort os bekendt med secret sharing-ordningen, åbnede vi for en hel klasse af protokoller, der er samlet under nøgleordet “threshold”. Når afsløringen af visse oplysninger kræver deltagelse af M ærlige deltagere ud af N, og sættet af ærlige deltagere kan være et vilkårligt delmængde af N, taler man om “threshold” ordninger. Det er netop dem, der gør det muligt at løse problemet med “sidste aktør”, nu hvis angriberen ikke afslører sin del af hemmeligheden, vil en anden ærlig deltager gøre det. Disse ordninger gør det muligt at blive enige om én og kun én værdi, selv ved saboterende opførsel fra en del af deltagerne.

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 artikel om forskellige anvendelser af threshold-signaturer, og her er en god longread fra Dash.

I den sidste artikel beskrives BLS-signaturer (BLS står for Boneh-Lynn-Shacham, her Den artikel, som har en meget vigtig og yderst praktisk kvalitet for programmører — offentlige, hemmelige, offentlige nøgler og BLS-signaturer kan kombineres med hinanden ved hjælp af enkle matematiske operationer, samtidig med at deres kombinationer forbliver gyldige nøgler og signaturer, hvilket muliggør nem aggregasjon af mange signaturer til én og mange offentlige nøgler til én. De har også determinisme og giver det samme resultat på de samme inputdata. Takket være denne egenskab er kombinationer af BLS-signaturer selv gyldige nøgler, hvilket muliggør et scenario, hvor M ud af N deltagere producerer én og kun én signatur, der er deterministisk, offentligt verificerbar og uforudsigelig, indtil den afsløres af den M-te deltager.

I ordningen med threshold BLS-signaturer underskriver hver deltager med BLS noget (for eksempel den tidligere tilfældige værdi), og den samlede threshold-signatur er den ønskede tilfældige værdi. De kryptografiske egenskaber ved BLS-signaturer opfylder kravene til kvaliteten af tilfældige værdier, threshold-delen beskytter mod “last-actor”, og den unikke kombinerbarhed af nøgler muliggør implementering af mange interessante algoritmer, som for eksempel effektivt kan aggregere meddelelser i protokollen.

Så 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 (her benchmarket, der implementerer ordningen, og her et eksempel på implementeringen af verificerbar hemmelig deling), eller Keep.network (her er deres tilfældige beacon yellowpaper, men her er eksempel smart-kontrakten, der betjener protokollen).

Implementeringen af PVRB

Desværre ser vi stadig ikke et færdigt, implementeret PVRB-protokol i blockchains, der har bevist sin sikkerhed og robusthed. Selvom protokollerne er klar, er det teknisk vanskeligt at anvende dem på eksisterende løsninger. For centraliserede systemer giver PVRB ikke mening, og decentraliserede systemer er strengt begrænset 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æver flere beskeder mellem RP, mens en anden kræver meget få beskeder, men at generere proof kan være en opgave, der tager mange minutter eller endda timer.

Jeg vil nævne faktorer, som du skal overveje, når du vælger et kvalitets PVRB:

Kryptografisk modstandsdygtighed. Dit PVRB skal være strengt unbiasable, uden mulighed for at kontrollere en enkelt bit. I nogle ordninger er dette ikke tilfældet, så ring efter en kryptograf.
Problemet med 'last actor'. Dit PVRB skal være modstandsdygtigt over for angreb, hvor en angriber, der kontrollerer en eller flere RP, kan vælge mellem to resultatmuligheder.
Problemet med sabotage af protokollen. Dit PVRB skal være modstandsdygtigt over for angreb, hvor en angriber, der kontrollerer en eller flere RP, beslutter, om der skal være randomisering eller ej, og kan garantere, eller med en given sandsynlighed påvirke dette.
Problemet med antallet af beskeder. Dine RP skal sende et minimum af beskeder til blockchain og undgå synkrone handlinger som situationer med "jeg har sendt noget information, står og venter på svar fra en specifik deltager". I p2p-netværk, især geografisk adskilt, bør man ikke forvente hurtige svar.
Problemet med beregningsmæssig kompleksitet. Verifikationen af enhver fase af PVRB on-chain skal være ekstremt let, da den udføres af alle full clients i netværket. Hvis implementeringen sker via en smart kontrakt, er kravene til hastighed meget strenge.
Problemet med tilgængelighed og liveness. Dit PVRB bør stræbe efter at være modstandsdygtigt over for situationer, hvor en del af netværket er blevet utilgængeligt i et stykke tid, og nogle RP simpelthen er stoppet med at fungere.
Problemet med trusted setup og den indledende distribution af nøgler. Hvis din PVRB bruger primære opsætningsprotokoller, er det en stor og seriøs sag. Her er eksempel. Hvis deltagerne skal meddele hinanden deres nøgler før starten af protokollen - er det også et problem, hvis deltagerne skifter
Udviklingsproblemer. Tilstedeværelsen af biblioteker på de nødvendige sprog, deres sikkerhed og ydeevne, offentliggørelse, komplekse tests osv.

For eksempel har threshold BLS signaturer et væsentligt problem - før de kan begynde at arbejde, skal deltagerne nødvendigvis udveksle nøgler med hinanden, hvilket organiserer en gruppe, som threshold skal fungere indenfor. Det betyder, at man mindst skal vente på én runde af udveksling i et decentralt netværk, og da den genererede tilfældighed, eksempelvis, er nødvendig i spil, næsten i realtime, betyder det, at protokollens sabotage er mulig på dette stadium, og fordelene ved threshold-skemaet går tabt. Dette problem er allerede lettere end de tidligere, men kræver stadig udviklingen af en separat procedure for dannelse af threshold-grupper, som økonomisk skal beskyttes gennem indskud og fratænkning af midler (slashing) fra deltagere, der ikke følger 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øres 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å størrelsen af nøglerne, eksempelvis 1024 og 2048 bit for RSA, hvilket er 4-8 gange mere end den standard signatur, der findes i Bitcoin og Ethereum.

Det spiller også en rolle, om der findes implementeringer på forskellige programmeringssprog - hvilket er begrænset, især for nye protokoller. Muligheden for integration i konsensus kræver, at protokollen skrives på platformssproget, så 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ø til at blive den næste vigtige internetstandard, være til hjælp.

Konklusion

Jeg håber, at det i det foregående artikel Jeg har formået at overbevise jer om, at generering af tilfældige tal på blockchainen er kritisk vigtig for mange aspekter af livet i decentraliserede netværk. Denne artikel viser, at opgaven er meget ambitiøs og udfordrende, men gode løsninger eksisterer allerede. Generelt kan det endelige design af protokollen kun komme efter omfattende tests, der tager højde for alle aspekter fra opsætning til simulering af fejl, så I vil næppe finde klare opskrifter i whitepapers fra teams eller i artikler. Vi vil heller ikke i det næste år eller to have mod på at skrive 'gør sådan, så er det helt rigtigt'.

Indtil videre, for vores PVRB i den under udvikling blockchain Haya, har vi besluttet at anvende threshold BLS-signaturer. Vi planlægger at implementere PVRB på konsensusniveau, da verifikation i smart contracts med et acceptabelt sikkerhedsniveau endnu ikke er mulig. Det kan være, at vi bruger to ordninger: først en dyr secret sharing for at skabe en langsigtet random_seed, som vi senere bruger som grundlag for højfrekvent tilfældighedsgenerering ved hjælp af deterministiske threshold BLS-signaturer, eller måske begrænser vi os til kun én af ordningerne. At sige på forhånd, hvordan protokollen vil være, er desværre umuligt. Det glæder dog, at ligesom inden for videnskab, i ingeniøroppgaver, er et negativt resultat også et resultat, og hvert nyt forsøg på at løse problemet er et skridt fremad for alle, der beskæftiger sig med denne problemstilling. For at opfylde erhvervslivets krav løser vi et konkret praktisk problem — sikring af gaming-applikationer med en pålidelig kilde til entropi. Derfor er vi også nødt til at tage hensyn til selve blockchainen, især spørgsmål om kædens finalitet og netværkets governance.

Og selvom vi endnu ikke ser et beviseligt robust PVRB i blockchains, der har været i brug længe nok til at bestå testen fra virkelige applikationer, flere audits, belastninger og naturligvis reelle angreb, bekræfter antallet af mulige veje, at løsningen eksisterer, og en af disse algoritmer vil til sidst løse problemet. Vi vil med glæde dele resultaterne og takker andre teams, der også arbejder med dette emne, for artikler og kode, der gør det muligt for ingeniører ikke at træde to gange på de samme mine.

Når du møder en programmør, der designer et decentraliseret tilfældigt system, skal du være opmærksom og omsorgsfuld; tilbyd psykologisk hjælp, hvis nødvendigt 🙂

Kilde: habr.com