Indledning

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

Som med konceptet med en absolut stærk chiffer fra kryptografi, forsøger ægte "Publicly Verifiable Random Beacon" (herefter PVRB) protokoller kun at komme så tæt som muligt på den ideelle ordning, fordi i rigtige netværk er det ikke anvendeligt i sin rene form: det er nødvendigt at blive enige om en bit, der skal være mange runder, og alle beskeder skal være perfekt hurtige og altid leveret. Det er selvfølgelig ikke tilfældet i rigtige netværk. Derfor, når man designer PVRB'er til specifikke opgaver i moderne blockchains, opstår der udover umuligheden af ​​at kontrollere den resulterende tilfældighed og kryptografiske styrke mange flere rent arkitektoniske og tekniske problemer.

For PVRB er selve blockchain i det væsentlige et kommunikationsmedium, hvor meddelelser = transaktioner. Dette giver dig mulighed for delvist at abstrahere fra netværksproblemer, manglende levering af meddelelser, problemer med middleware - alle disse risici påtages af det decentraliserede netværk, og dets vigtigste værdi for PVRB er manglende evne til at tilbagekalde eller ødelægge en allerede sendt transaktion - dette gør ikke tillade deltagere at nægte at deltage i protokollen, medmindre de gennemførte et vellykket angreb på konsensus. Dette sikkerhedsniveau er acceptabelt, så PVRB bør være modstandsdygtig over for samordning fra deltagere i nøjagtig samme grad som den primære blockchain-kæde. Dette antyder også, at PVRB skal være en del af konsensus, hvis netværket er enig om den primære blockchain, selvom det også er enige om den eneste retfærdige resulterende tilfældige. Eller PVRB er simpelthen en selvstændig protokol implementeret af en smart kontrakt, der fungerer asynkront med hensyn til blockchain og blokke. Begge metoder har deres fordele og ulemper, og valget mellem dem er ekstremt ikke-trivielt.

To måder at implementere PVRB på

Lad os beskrive mere detaljeret to muligheder for at implementere PVRB - den selvstændige version, der fungerer ved hjælp af en smart kontrakt uafhængig af blockchain, og den konsensus-integrerede version, indbygget i protokollen, ifølge hvilken netværket er enige om blockchain og transaktioner, der skal medtages. I alle tilfælde vil jeg mene populære blockchain-motorer: Ethereum, EOS og alle dem, der ligner dem i den måde, de hoster og behandler smarte kontrakter på.

Enkeltstående kontrakt

I denne version er PVRB en smart kontrakt, der accepterer transaktioner fra tilfældige producenter (herefter benævnt RP), behandler dem, kombinerer resultaterne og som et resultat når frem til en vis værdi, som enhver bruger kan modtage fra denne kontrakt. Denne værdi må ikke lagres direkte i kontrakten, men kun repræsenteres af data, hvorfra én og kun én værdi af den resulterende tilfældige kan opnås deterministisk. I denne ordning er RP'er brugere af blockchain, og alle kan få lov til at deltage i genereringsprocessen.

Muligheden med selvstændig kontrakt er god:

• portabilitet (kontrakter kan trækkes fra blockchain til blockchain)
• let implementering og test (kontrakter er nemme at skrive og teste)
• bekvemmelighed ved at implementere økonomiske ordninger (det er nemt at lave dit eget token, hvis logik tjener formålet med PVRB)
• mulighed for lancering på allerede fungerende blockchains

Det har også ulemper:

• stærke begrænsninger på computerressourcer, transaktionsvolumen og lagring (med andre ord cpu/mem/io)
• begrænsninger for operationer inden for kontrakten (ikke alle instruktioner er tilgængelige, det er svært at forbinde eksterne biblioteker)
• manglende evne til at organisere beskeder hurtigere end transaktioner er inkluderet i blockchain

Denne mulighed er velegnet til at implementere en PVRB, der skal køres på et eksisterende netværk, ikke indeholder kompleks kryptografi og ikke kræver et stort antal interaktioner.

Konsensus-integreret

I denne version er PVRB implementeret i blockchain-nodekoden, indbygget eller kørende parallelt med udvekslingen af ​​meddelelser mellem blockchain-noder. Resultaterne af protokollen skrives direkte ind i de producerede blokke, og protokolmeddelelser sendes over p2p-netværket mellem noder. Da protokollen resulterer i tal, der skal skrives i blokke, skal netværket nå til enighed om dem. Dette betyder, at PVRB-meddelelser, ligesom transaktioner, skal valideres af noder og inkluderes i blokke, så enhver netværksdeltager kan validere overholdelse af PVRB-protokollen. Dette fører os automatisk til den åbenlyse løsning - hvis netværket bliver enige om en konsensus om en blokering og transaktioner i den, så bør PVRB være en del af konsensus, og ikke en selvstændig protokol. Ellers er det muligt, at en blokering er gyldig fra et konsensussynspunkt, men PVRB-protokollen følges ikke, og fra PVRB-synspunktet kan blokeringen ikke accepteres. Så hvis den "konsensus-integrerede" mulighed vælges, bliver PVRB en vigtig del af konsensus.

Når man beskriver PVRB-implementeringer på netværkskonsensusniveau, kan man på ingen måde undgå spørgsmål om endelighed. Finalitet er en mekanisme, der bruges i deterministiske konsensus, der låser en blok (og kæden, der fører til den), der er endelig og aldrig vil blive smidt væk, selvom der opstår en parallel forgrening. For eksempel er der ingen sådan mekanisme i Bitcoin - hvis du udgiver en kæde med større kompleksitet, vil den erstatte enhver mindre kompleks, uanset længden af ​​kæderne. Og i for eksempel EOS er de sidste de såkaldte Last Irreversible Blocks, som i gennemsnit optræder for hver 432. blokke (12*21 + 12*15, pre-vote + pre-commit). Denne proces venter i det væsentlige på 2/3 af blokproducenternes (herefter benævnt BP) underskrifter. Når gafler dukker op, der er ældre end den sidste LIB, kasseres de simpelthen. Denne mekanisme gør det muligt at garantere, at transaktionen er inkluderet i blockchain og aldrig vil blive rullet tilbage, uanset hvilke ressourcer angriberen har. De sidste blokke er også blokke underskrevet af 2/3 BP i Hyperledger, Tendermint og andre pBFT-baserede konsensus. Det giver også mening at lave en protokol for at sikre endelighed til en tilføjelse til konsensus, da den kan arbejde asynkront med produktion og udgivelse af blokke. Her er en god en artiklen om endelighed i Ethereum.

Finalitet er ekstremt vigtigt for brugere, som uden det kan blive ofre for et "double spend"-angreb, hvor BP "holder" blokeringer og udgiver dem, efter at netværket har "set" en god transaktion. Hvis der ikke er nogen endelighed, erstatter den offentliggjorte gaffel blokken med en "god" transaktion med en anden, fra en "dårlig" fork, hvor de samme midler overføres til angriberens adresse. I tilfælde af PVRB er kravene til endelighed endnu strengere, da bygning af gafler til PVRB betyder muligheden for, at en angriber kan forberede flere tilfældige muligheder for at publicere den mest rentable, og at begrænse tidspunktet for et muligt angreb er en god løsning.

Derfor er den bedste mulighed at kombinere PVRB og finality i én protokol - så er den afsluttede blok = afsluttet tilfældig, og det er præcis, hvad vi skulle have. Nu vil spillere modtage en garanteret tilfældig rækkefølge på N sekunder, og de kan være sikre på, at det er umuligt at rulle det tilbage eller afspille det igen.

Den konsensus-integrerede mulighed er god:

• muligheden for asynkron implementering i forhold til produktion af blokke - blokke produceres som sædvanligt, men sideløbende hermed kan PVRB-protokollen fungere, hvilket ikke producerer tilfældigheder for hver blok
• evnen til at implementere selv tung kryptografi, uden de begrænsninger, der er pålagt smarte kontrakter
• evnen til at organisere udvekslingen af ​​beskeder hurtigere end transaktioner er inkluderet i blockchain, for eksempel kan en del af protokollen fungere mellem noder uden at distribuere beskeder over netværket

Det har også ulemper:

• Vanskeligheder med test og udvikling - du bliver nødt til at efterligne netværksfejl, manglende noder, netværkshardgafler
• Implementeringsfejl kræver en netværkshardfork

Begge metoder til at implementere PVRB har ret til liv, men implementering på smarte kontrakter i moderne blockchains er stadig ret begrænset med hensyn til computerressourcer, og enhver overgang til seriøs kryptografi er ofte ganske enkelt umulig. Og vi har brug for seriøs kryptografi, som det vil blive demonstreret nedenfor. Selvom dette problem tydeligvis er midlertidigt, er der behov for seriøs kryptografi i kontrakter for at løse mange problemer, og det dukker gradvist op (for eksempel systemkontrakter for zkSNARKs i Ethereum)

Blockchain, som giver en gennemsigtig og pålidelig protokolbeskedkanal, gør det ikke gratis. Enhver decentral protokol skal tage højde for muligheden for et Sybil-angreb; enhver handling kan udføres af de samordnede styrker af flere konti, derfor er det, når der designes, nødvendigt at tage højde for angribernes evne til at oprette et vilkårligt antal protokoller deltagere, der handler i samordning.

PVRB og blokvariabler.

Jeg løj ikke, da jeg sagde, at ingen endnu har implementeret en god PVRB, testet af mange gambling-applikationer, i blockchains. Hvor kommer så mange gambling-applikationer fra på Ethereum og EOS? Dette overrasker mig lige så meget, som det overrasker dig, hvor har de fået så mange "vedvarende" tilfældige i et fuldstændig deterministisk miljø?

Den foretrukne måde at få tilfældighed i blockchain er at tage en form for "uforudsigelig" information fra blokken og lave en tilfældig en baseret på den - simpelthen ved at hash en eller flere værdier. God artikel om problemerne med sådanne ordninger her. Du kan tage en hvilken som helst af de "uforudsigelige" værdier i blokken, for eksempel blokhashen, antallet af transaktioner, netværkets kompleksitet og andre værdier, der er ukendte på forhånd. Så hash dem, en eller flere, og i teorien skulle du få en rigtig tilfældig. Du kan endda tilføje til wihitepaperet, at din ordning er "post-kvantesikker" (da der er kvantesikre hash-funktioner :)).

Men selv post-kvante sikre hash er ikke nok, desværre. Hemmeligheden ligger i kravene til PVRB, lad mig minde dig om dem fra den forrige artikel:

1. Resultatet skal have en beviseligt ensartet fordeling, dvs. være baseret på beviselig stærk kryptografi.
2. Det er ikke muligt at kontrollere nogen af ​​bits af resultatet. Resultatet kan derfor ikke forudsiges på forhånd.
3. Du kan ikke sabotere genereringsprotokollen ved ikke at deltage i protokollen eller ved at overbelaste netværket med angrebsmeddelelser
4. Alt ovenstående skal være modstandsdygtigt over for samordning af et tilladt antal uærlige protokoldeltagere (f.eks. 1/3 af deltagerne).

I dette tilfælde er kun krav 1 opfyldt, og krav 2 er ikke opfyldt. Ved at hashe uforudsigelige værdier fra blokken får vi en ensartet fordeling og gode tilfældigheder. Men BP har i det mindste muligheden for at "offentliggøre blokeringen eller ej." Dermed kan BP i det mindste vælge mellem TO tilfældige muligheder: "sin egen" og den, der vil vise sig, hvis en anden laver blokeringen. BP kan "snoop" på forhånd, hvad der vil ske, hvis han udgiver en blok, og simpelthen beslutter sig for at gøre det eller ej. Når han for eksempel spiller "lige-ulige" eller "rød/sort" i roulette, kan han kun udgive en blok, hvis han ser en gevinst. Dette gør også strategien med at bruge for eksempel en blokhash "fra fremtiden" ubrugelig. I dette tilfælde siger de, at "tilfældig vil blive brugt, som opnås ved at hashe de aktuelle data og hashen af ​​en fremtidig blok med en højde på for eksempel N + 42, hvor N er den aktuelle blokhøjde. Det styrker ordningen lidt, men giver stadig BP mulighed for, om end i fremtiden, at vælge om de vil holde blokeringen eller offentliggøre.

BP software i dette tilfælde bliver mere kompliceret, men ikke meget. Simpelthen, når du validerer og inkluderer en transaktion i en blok, er der en hurtig kontrol for at se, om der vil være en gevinst, og muligvis valg af en transaktionsparametre for at opnå en høj sandsynlighed for at vinde. Samtidig er det næsten umuligt at fange en smart BP for sådanne manipulationer; hver gang kan du bruge nye adresser og vinde lidt efter lidt uden at vække mistanke.

Så metoder, der bruger information fra blokken, er ikke egnede som 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 en spiller i at bruge flere adresser), kan disse ordninger fungere for små spil, men intet mere.

PVRB og commit-reveal.

Okay, takket være hashing og i det mindste den relative uforudsigelighed af blokhashen og andre variabler. Hvis du løser problemet med frontløbende minearbejdere, bør du få noget mere passende. Lad os tilføje brugere til denne ordning - lad dem også påvirke tilfældigheden: enhver teknisk supportmedarbejder vil fortælle dig, at det mest tilfældige i it-systemer er brugernes handlinger :)

Et naivt skema, når brugere blot sender tilfældige tal, og resultatet beregnes som for eksempel en hash af deres sum, er ikke egnet. I dette tilfælde kan den sidste spiller ved at vælge sit eget tilfældige styre, hvad resultatet bliver. Det er grunden til, at det meget udbredte commit-reveal-mønster bruges. Deltagerne sender først hashes fra deres tilfældige (forpligtelser), og åbner derefter selv tilfældige (afslører). "Afsløringsfasen" begynder først, efter at de nødvendige commits er blevet indsamlet, så deltagerne kan sende præcis den tilfældige hash, som de sendte tidligere. Lad os nu sætte alt dette sammen med parametrene for en blok, og bedre end en taget fra fremtiden (tilfældighed kan kun findes i en af ​​de fremtidige blokke), og voila - tilfældigheden er klar! Nu påvirker enhver spiller den resulterende tilfældighed og kan "besejre" den ondsindede BP ved at tilsidesætte den med sin egen, på forhånd ukendte tilfældighed... Du kan også tilføje beskyttelse mod at sabotere protokollen ved ikke at åbne den på afsløringsstadiet - ganske enkelt ved at kræve et bestemt beløb knyttet til transaktionen ved forpligtelse — et depositum, som kun vil blive returneret under afsløringsproceduren. I dette tilfælde vil det være urentabelt at forpligte sig og ikke afsløre.

Det var et godt forsøg, og sådanne ordninger findes også i gaming DApps, men desværre er dette igen ikke nok. Nu kan ikke kun minearbejderen, men også enhver deltager i protokollen påvirke resultatet. Det er stadig muligt at kontrollere selve værdien, med mindre variabilitet og til en pris, men som i tilfældet med minearbejderen, hvis resultaterne af tegningen er mere værdifulde end gebyret for deltagelse i PVRB-protokollen, så er det tilfældige -producer(RP) kan beslutte, om den skal afsløre og kan stadig vælge mellem mindst to tilfældige muligheder.
Men det blev muligt at straffe dem, der begår og ikke afslører, og denne ordning vil komme til nytte. Dens enkelhed er en alvorlig fordel - mere seriøse protokoller kræver meget mere kraftfulde beregninger.

PVRB og deterministiske signaturer.

Der er en anden måde at tvinge RP til at give et pseudo-tilfældigt tal, som det ikke kan påvirke, hvis det er forsynet med et "preimage" - dette er en deterministisk signatur. En sådan signatur er for eksempel RSA og er ikke ECS. Hvis RP har et par nøgler: RSA og ECC, og han signerer en bestemt værdi med sin private nøgle, så vil han i tilfælde af RSA få EN OG KUN EN signatur, og i tilfælde af ECS kan han generere et hvilket som helst antal af forskellige gyldige signaturer. Dette skyldes, at der ved oprettelse af en ECS-signatur bruges et tilfældigt tal, valgt af underskriveren, og det kan vælges på enhver måde, hvilket giver underskriveren mulighed for at vælge en af ​​flere signaturer. I tilfælde af RSA: "én inputværdi" + "et nøglepar" = "én signatur". Det er umuligt at forudsige, hvilken signatur en anden RP vil få, så en PVRB med deterministiske signaturer kan organiseres ved at kombinere RSA-signaturerne fra flere deltagere, der underskrev den samme værdi. For eksempel den forrige tilfældige. Denne ordning sparer mange ressourcer, pga signaturer er både bekræftelse af den korrekte adfærd i henhold til protokollen og en kilde til tilfældighed.

Men selv med deterministiske signaturer er ordningen stadig sårbar over for problemet med "sidste aktør". Den sidste deltager kan stadig beslutte, om han vil offentliggøre signaturen eller ej, og derved kontrollere resultatet. Du kan ændre skemaet, tilføje blokhasher til det, lave runder, så resultatet ikke kan forudsiges på forhånd, men alle disse teknikker, selv under hensyntagen til mange ændringer, efterlader stadig problemet med en deltagers indflydelse på kollektivet uløst. resultere i et upålideligt miljø og kan kun arbejde under økonomiske og tidsmæssige begrænsninger. Derudover er størrelsen på RSA-nøgler (1024 og 2048 bit) ret stor, og størrelsen for blockchain-transaktioner er en ekstrem vigtig parameter. Der er tilsyneladende ingen enkel måde at løse problemet på, lad os komme videre.

PVRB og hemmelige deleordninger

Inden for kryptografi er der ordninger, der kan tillade netværket at blive enige om én og kun én PVRB-værdi, mens sådanne ordninger er modstandsdygtige over for eventuelle ondsindede handlinger fra nogle deltagere. En nyttig protokol, der er værd at sætte sig ind i, er Shamirs hemmelige delingsskema. Det tjener til at opdele en hemmelighed (for eksempel en hemmelig nøgle) i flere dele og distribuere disse dele til N deltagere. Hemmeligheden er fordelt på en sådan måde, at M dele ud af N er nok til at genvinde den, og disse kan være hvilke som helst M dele. Hvis på fingre, så har en graf af en ukendt funktion, udveksler deltagerne point på grafen, og efter at have modtaget M point, kan hele funktionen gendannes.
Der gives en god forklaring wiki men at lege med det praktisk for at spille protokollen i dit hoved er nyttigt til demo side.

Hvis FSSS (Fiat-Shamir Secret Sharing)-ordningen var gældende i sin rene form, ville det være en uforgængelig PVRB. I sin enkleste form kan protokollen se sådan ud:

• Hver deltager genererer deres egen tilfældige og distribuerer aktier fra den til andre deltagere
• Hver deltager afslører sin del af de andre deltageres hemmeligheder
• Hvis en deltager har mere end M andele, kan antallet af denne deltager beregnes, og det vil være unikt, uanset antallet af afslørede deltagere
• Kombinationen af ​​afslørede tilfældige er den ønskede PVRB

Her påvirker en individuel deltager ikke længere resultaterne af protokollen, undtagen i tilfælde, hvor opnåelsen af ​​tærsklen for tilfældig afsløring kun afhænger af ham. Derfor fungerer denne protokol, hvis der er en påkrævet andel af RP'er, der arbejder på protokollen og er tilgængelig, og implementerer kravene til kryptografisk styrke og er modstandsdygtig over for problemet med "sidste aktør".

Dette kunne være en ideel mulighed, denne PVRB-ordning baseret på Fiat-Shamirs hemmelige deling er beskrevet for eksempel i dette artikel. Men som nævnt ovenfor, hvis du forsøger at anvende det direkte i blockchainen, opstår tekniske begrænsninger. Her er et eksempel på en testimplementering af protokollen i EOS smart-kontrakten og dens vigtigste del - kontrol af den offentliggjorte aktiedeltager: kode. Du kan se på koden, at bevisvalidering kræver flere skalar multiplikationer, og de anvendte tal er meget store. Det skal forstås, at i blockchains forekommer verifikation i det øjeblik, hvor blokproducenten behandler transaktionen, og generelt skal enhver deltager nemt verificere korrektheden af ​​protokollen, så kravene til verifikationsfunktionens hastighed er meget alvorlige . I denne mulighed viste indstillingen sig at være ineffektiv, da verifikationen ikke passede inden for transaktionsgrænsen (0.5 sekunder).

Verifikationseffektivitet er et af de vigtigste krav til brugen af, generelt, eventuelle avancerede kryptografiske skemaer i blockchain. Oprettelse af beviser, forberedelse af beskeder - disse procedurer kan tages ud af kæden og udføres på højtydende computere, men verifikation kan ikke omgås - dette er et andet vigtigt krav til PVRB.

PVRB og tærskelsignaturer

Efter at have stiftet bekendtskab med det hemmelige delingsskema, opdagede vi en hel klasse af protokoller forenet med nøgleordet "tærskel". Når videregivelsen af ​​nogle oplysninger kræver deltagelse af M ærlige deltagere ud af N, og sættet af ærlige deltagere kan være en vilkårlig delmængde af N, taler vi om "tærskel"-ordninger. Det er dem, der tillader os at håndtere "sidste skuespiller"-problemet, nu hvis angriberen ikke afslører sin del af hemmeligheden, vil en anden, ærlig deltager gøre det for ham. Disse ordninger tillader enighed om én og kun én betydning, selvom protokollen saboteres af nogle af deltagerne.

Kombinationen af ​​deterministiske signaturer og tærskelskemaer gjorde det muligt at udvikle et meget bekvemt og lovende skema til implementering af PVRB - disse er deterministiske tærskelsignaturer. Her artiklen om de forskellige anvendelser af tærskelsignaturer, og her er en anden god en longread fra Dash.

Den sidste artikel beskriver BLS-signaturer (BLS står for Boneh-Lynn-Shacham, her artikel), som har en meget vigtig og ekstrem bekvem kvalitet for programmører - offentlige, hemmelige, offentlige nøgler og BLS-signaturer kan kombineres med hinanden ved hjælp af simple matematiske operationer, mens deres kombinationer forbliver gyldige nøgler og signaturer, hvilket giver dig mulighed for nemt at aggregere mange signaturer i én og mange offentlige nøgler i én. De er også deterministiske og producerer det samme resultat for de samme inputdata. Takket være denne kvalitet er kombinationer af BLS-signaturer i sig selv gyldige nøgler, hvilket giver mulighed for implementering af en mulighed, hvor M af N deltagere producerer én og kun én signatur, der er deterministisk, offentligt verificerbar og uforudsigelig, indtil den åbnes af Mth. deltager.

I et skema med tærskel-BLS-signaturer underskriver hver deltager noget ved hjælp af BLS (for eksempel den forrige tilfældige), og den fælles tærskelsignatur er den ønskede tilfældige. BLS-signaturernes kryptografiske egenskaber opfylder kravene til tilfældig kvalitet, tærskeldelen beskytter mod "last-actor", og den unikke kombinerbarhed af nøgler gør det muligt at implementere mange flere interessante algoritmer, der for eksempel muliggør effektiv aggregering af protokolbeskeder .

Så hvis du bygger PVRB på din blockchain, vil du højst sandsynligt ende med BLS-tærskelsignaturordningen, flere projekter bruger det allerede. For eksempel, DFinity (her benchmark, der implementerer kredsløbet, og her eksempel implementering af verificerbar hemmelig deling), eller Keep.network (her er deres tilfældige beacon gult papir, Men eksempel smart kontrakt, der betjener protokollen).

Implementering af PVRB

Desværre ser vi stadig ikke en færdigprotokol implementeret i PVRB blockchains, der har bevist sin sikkerhed og stabilitet. Selvom selve protokollerne er klar, er det ikke let teknisk at anvende dem på eksisterende løsninger. For centraliserede systemer giver PVRB ikke mening, og decentraliserede er strengt begrænset i alle computerressourcer: CPU, hukommelse, lager, I/O. At designe en PVRB er en kombination af forskellige protokoller for at skabe noget, der opfylder alle kravene til i det mindste en levedygtig blockchain. Den ene protokol beregner mere effektivt, men kræver flere beskeder mellem RP'er, mens den anden kræver meget få beskeder, men at oprette et bevis kan være en opgave, der tager snesevis af minutter eller endda timer.

Jeg vil liste de faktorer, du skal overveje, når du vælger en kvalitets-PVRB:

• Kryptografisk styrke. Din PVRB skal være strengt upartisk, uden mulighed for at kontrollere en enkelt bit. I nogle ordninger er dette ikke tilfældet, så ring til en kryptograf
• Problemet med "sidste skuespiller".. Din PVRB skal være modstandsdygtig over for angreb, hvor en angriber, der kontrollerer en eller flere RP'er, kan vælge et af to udfald.
• Protokolsabotageproblem. Din PVRB skal være modstandsdygtig over for angreb, hvor en angriber, der kontrollerer en eller flere RP'er, beslutter, om den skal være tilfældig eller ej, og kan enten garanteres eller med en given sandsynlighed for at påvirke dette
• Antal meddelelser problem. Dine RP'er bør sende et minimum af beskeder til blockchain og undgå synkrone handlinger så meget som muligt, såsom situationer som "Jeg har sendt nogle oplysninger, jeg venter på et svar fra en specifik deltager." I p2p-netværk, især geografisk spredte, skal du ikke regne med et hurtigt svar
• Problemet med beregningsmæssig kompleksitet. Verifikation af ethvert trin i PVRB on-chain bør være ekstremt let, da det udføres af alle fulde klienter på netværket. Hvis implementeringen sker ved hjælp af en smart kontrakt, så er hastighedskravene meget strenge
• Problemet med tilgængelighed og livlighed. Din PVRB bør stræbe efter at være modstandsdygtig over for situationer, hvor en del af netværket bliver utilgængeligt i en periode, og en del af RP simpelthen holder op med at fungere
• Problemet med pålidelig opsætning og indledende nøgledistribution. Hvis din PVRB bruger den primære opsætning af protokollen, så er dette en separat stor og seriøs historie. Her eksempel. Hvis deltagerne skal fortælle hinanden deres nøgler, før de starter protokollen, er dette også et problem, hvis sammensætningen af ​​deltagere ændres
• Udviklingsproblemer. Tilgængelighed af biblioteker på de krævede sprog, deres sikkerhed og ydeevne, omtale, komplekse tests osv.

For eksempel har tærskel BLS-signaturer et betydeligt problem - før de begynder at arbejde, skal deltagerne distribuere nøgler til hinanden og organisere en gruppe, inden for hvilken tærskelværdien vil fungere. Det betyder, at mindst en udvekslingsrunde i et decentraliseret netværk skal vente, og givet at den genererede rand for eksempel er nødvendig i spil, næsten i realtid, betyder det, at sabotage af protokollen er mulig på dette stadium , og fordelene ved tærskelordningen går tabt . Dette problem er allerede enklere end de foregående, men kræver stadig udvikling af en separat procedure for dannelse af tærskelgrupper, som skal beskyttes økonomisk gennem indskud og tilbagetrækning af midler (slashing) fra deltagere, der ikke følger protokol. Desuden passer BLS-verifikation med et acceptabelt sikkerhedsniveau simpelthen ikke ind i for eksempel en standard EOS- eller Ethereum-transaktion - der er simpelthen ikke tid nok til verifikation. Kontraktkoden er WebAssembly eller EVM, udført af en virtuel maskine. Kryptografiske funktioner er ikke implementeret indbygget (endnu) og arbejder titusindvis langsommere end konventionelle kryptografiske biblioteker. Mange protokoller opfylder ikke kravene blot baseret på nøglevolumen, for eksempel 1024 og 2048 bit til RSA, 4-8 gange større end standardtransaktionssignaturen i Bitcoin og Ethereum.

Tilstedeværelsen af ​​implementeringer på forskellige programmeringssprog spiller også en rolle - som der er få af, især for nye protokoller. Muligheden med integration i konsensus kræver, at der skrives en protokol i platformsproget, så du bliver nødt til at lede efter kode i Go for geth, i Rust for Parity, i C++ for EOS. Alle bliver nødt til at lede efter JavaScript-kode, og da JavaScript og kryptografi ikke er særligt nære venner, hjælper WebAssembly, som nu helt klart hævder at være den næste vigtige internetstandard.

Konklusion

Jeg håber på den forrige artiklen Det lykkedes mig at overbevise dig om, at generering af tilfældige tal på blockchain er afgørende for mange aspekter af decentraliserede netværks liv, og med denne artikel viste jeg, at denne opgave er ekstremt ambitiøs og vanskelig, men der findes allerede gode løsninger. Generelt er det endelige design af protokollen kun muligt efter at have udført massive tests, der tager højde for alle aspekter fra opsætning til fejlemulering, så det er usandsynligt, at du vil finde færdige opskrifter i team-whitepapers og artikler, og vi vil bestemt ikke beslutte i det næste år eller to, skriv "gør det på denne måde, helt rigtigt."

Farvel, for vores PVRB i blockchain, der udvikles Haya, vi besluttede at bruge tærskel BLS-signaturer, planlægger vi at implementere PVRB på konsensusniveau, da verifikation i smarte kontrakter med et acceptabelt sikkerhedsniveau endnu ikke er mulig. Det er muligt, at vi bruger to skemaer på én gang: For det første, dyr hemmelighedsdeling for at skabe langsigtet random_seed, og derefter bruger vi det som grundlag for højfrekvent tilfældig generering ved hjælp af deterministiske tærskel BLS-signaturer, måske vil vi begrænse os til kun at en af ​​ordningerne. Desværre er det umuligt at sige på forhånd, hvad protokollen vil være; det eneste gode er, at som i videnskaben, i tekniske problemer, er et negativt resultat også et resultat, og hvert nyt forsøg på at løse problemet er endnu et skridt for alle involverede i problemets forskning. For at opfylde forretningskrav løser vi et specifikt praktisk problem - at forsyne spilapplikationer med en pålidelig kilde til entropi, så vi skal også være opmærksomme på selve blockchainen, især spørgsmålene om kædeafslutning og netværksstyring.

Og selvom vi endnu ikke ser en bevist resistent PVRB i blockchains, som ville have været brugt i tilstrækkelig tid til at blive testet af rigtige applikationer, flere revisioner, belastninger og selvfølgelig rigtige angreb, men antallet af mulige stier bekræfter, at der findes en løsning, og hvad af disse algoritmer vil i sidste ende løse problemet. Vi vil med glæde dele resultaterne og takke andre teams, der også arbejder på dette problem, for artikler og kode, der tillader ingeniører ikke at træde på den samme rake to gange.

Så når du møder en programmør, der designer decentraliseret tilfældigt, så vær opmærksom og omsorgsfuld, og giv psykologisk hjælp, hvis det er nødvendigt :)

Kilde: www.habr.com