Innledning

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

Som med konseptet med en absolutt sterk chiffer fra kryptografi, prøver ekte "Publicly Verifiable Random Beacon" (heretter PVRB)-protokoller bare å komme så nært som mulig til den ideelle ordningen, fordi i ekte nettverk er det ikke aktuelt i sin rene form: det er nødvendig å bli strengt enige om en bit, det må være mange runder, og alle meldinger må være perfekt raske og alltid levert. Dette er selvsagt ikke tilfelle i ekte nettverk. Derfor, når du designer PVRB-er for spesifikke oppgaver i moderne blokkjeder, i tillegg til umuligheten av å kontrollere den resulterende tilfeldigheten og kryptografisk styrke, oppstår det mange flere rent arkitektoniske og tekniske problemer.

For PVRB er blokkjeden i seg selv et kommunikasjonsmedium der meldinger = transaksjoner. Dette lar deg delvis abstrahere fra nettverksproblemer, manglende levering av meldinger, problemer med mellomvare - alle disse risikoene overtas av det desentraliserte nettverket, og hovedverdien for PVRB er manglende evne til å tilbakekalle eller ødelegge en allerede sendt transaksjon - dette gjør ikke tillate deltakere å nekte å delta i protokollen, med mindre de utførte et vellykket angrep på konsensus. Dette sikkerhetsnivået er akseptabelt, så PVRB bør være motstandsdyktig mot samarbeid fra deltakere i nøyaktig samme grad som hovedblokkkjeden. Dette antyder også at PVRB må være en del av konsensus hvis nettverket er enig om hovedblokkjeden, selv om det også er enig om den eneste rettferdige resulterende tilfeldigheten. Eller, PVRB er ganske enkelt en frittstående protokoll implementert av en smart kontrakt som fungerer asynkront med hensyn til blokkjeden og blokkene. Begge metodene har sine fordeler og ulemper, og valget mellom dem er ekstremt ikke-trivielt.

To måter å implementere PVRB på

La oss beskrive mer detaljert to alternativer for å implementere PVRB - den frittstående versjonen, som fungerer ved hjelp av en smart kontrakt uavhengig av blokkjeden, og den konsensusintegrerte versjonen, innebygd i protokollen, i henhold til hvilken nettverket er enige om blokkjeden og transaksjoner som skal inkluderes. I alle tilfeller vil jeg mene populære blokkjedemotorer: Ethereum, EOS og alle de som ligner på dem i måten de er vert for og behandler smarte kontrakter på.

Frittstående kontrakt

I denne versjonen er PVRB en smart kontrakt som aksepterer transaksjoner fra tilfeldige produsenter (heretter referert til som RP), behandler dem, kombinerer resultatene, og som et resultat kommer frem til en viss verdi som enhver bruker kan motta fra denne kontrakten. Denne verdien kan ikke lagres direkte i kontrakten, men kun representeres av data hvorfra én og bare én verdi av den resulterende tilfeldigheten kan oppnås deterministisk. I denne ordningen er RP-er brukere av blokkjeden, og alle kan få delta i generasjonsprosessen.

Alternativet med frittstående kontrakt er bra:

• portabilitet (kontrakter kan dras fra blokkjede til blokkjede)
• enkel implementering og testing (kontrakter er enkle å skrive og teste)
• praktisk å implementere økonomiske ordninger (det er enkelt å lage din egen token, hvis logikk tjener formålet med PVRB)
• mulighet for lansering på allerede fungerende blokkjeder

Det har også ulemper:

• sterke begrensninger på dataressurser, transaksjonsvolum og lagring (med andre ord cpu/mem/io)
• restriksjoner på operasjoner innenfor kontrakten (ikke alle instruksjoner er tilgjengelige, det er vanskelig å koble til eksterne biblioteker)
• manglende evne til å organisere meldinger raskere enn transaksjoner er inkludert i blokkjeden

Dette alternativet er egnet for å implementere en PVRB som må kjøres på et eksisterende nettverk, som ikke inneholder kompleks kryptografi og ikke krever et stort antall interaksjoner.

Konsensusintegrert

I denne versjonen er PVRB implementert i blockchain-nodekoden, innebygd eller kjører parallelt med utveksling av meldinger mellom blockchain-noder. Resultatene av protokollen skrives direkte inn i de produserte blokkene, og protokollmeldinger sendes over p2p-nettverket mellom noder. Siden protokollen resulterer i tall som skal skrives i blokker, må nettverket oppnå konsensus om dem. Dette betyr at PVRB-meldinger, som transaksjoner, må valideres av noder og inkluderes i blokker slik at enhver nettverksdeltaker kan validere samsvar med PVRB-protokollen. Dette fører oss automatisk til den åpenbare løsningen - hvis nettverket blir enige om en konsensus om en blokk og transaksjoner i den, bør PVRB være en del av konsensus, og ikke en frittstående protokoll. Ellers er det mulig at en blokkering er gyldig fra et konsensussynspunkt, men PVRB-protokollen følges ikke, og fra PVRB-synspunkt kan blokken ikke aksepteres. Så hvis alternativet "konsensusintegrert" velges, blir PVRB en viktig del av konsensus.

Når man beskriver PVRB-implementeringer på nettverkskonsensusnivå, kan man på ingen måte unngå spørsmål om endelighet. Finalitet er en mekanisme som brukes i deterministiske konsensuser som låser fast en blokk (og kjeden som fører til den) som er endelig og aldri vil bli kastet, selv om en parallell gaffel oppstår. For eksempel, i Bitcoin er det ingen slik mekanisme - hvis du publiserer en kjede med større kompleksitet, vil den erstatte en hvilken som helst mindre kompleks, uavhengig av lengden på kjedene. Og i EOS, for eksempel, er de siste de såkalte Last Irreversible Blocks, som vises i gjennomsnitt hver 432. blokk (12*21 + 12*15, forhåndsstemme + forhåndsbekreftelse). Denne prosessen venter i hovedsak på 2/3 av blokkprodusentene (heretter referert til som BP) underskrifter. Når gafler dukker opp som er eldre enn den siste LIB, blir de ganske enkelt kastet. Denne mekanismen gjør det mulig å garantere at transaksjonen er inkludert i blokkjeden og aldri vil bli rullet tilbake, uansett hvilke ressurser angriperen har. De siste blokkene er også blokker signert av 2/3 BP i Hyperledger, Tendermint og andre pBFT-baserte konsensuser. Det er også fornuftig å lage en protokoll for å sikre finalitet et tillegg til konsensus, siden den kan fungere asynkront med produksjon og publisering av blokker. Her er en god en artikkel om finalitet i Ethereum.

Sluttlighet er ekstremt viktig for brukere, som uten det kan bli ofre for et "double spend"-angrep, der BP "holder" blokkerer, og publiserer dem etter at nettverket har "sett" en god transaksjon. Hvis det ikke er noen endelighet, erstatter den publiserte gaffelen blokken med en "god" transaksjon med en annen, fra en "dårlig" gaffel, der de samme midlene overføres til angriperens adresse. Når det gjelder PVRB, er kravene til endelighet enda strengere, siden å bygge gafler for PVRB betyr muligheten for en angriper til å forberede flere tilfeldige alternativer for å publisere den mest lønnsomme, og å begrense tidspunktet for et mulig angrep er en god løsning.

Derfor er det beste alternativet å kombinere PVRB og finality i én protokoll - da er den endelige blokken = sluttført tilfeldig, og dette er akkurat det vi trengte å få. Nå vil spillerne motta en garantert tilfeldighet på N sekunder, og kan være sikre på at det er umulig å rulle den tilbake eller spille den på nytt.

Det konsensusintegrerte alternativet er bra:

• muligheten for asynkron implementering i forhold til produksjon av blokker - blokker produseres som vanlig, men parallelt med dette kan PVRB-protokollen fungere, som ikke produserer tilfeldighet for hver blokk
• muligheten til å implementere selv tung kryptografi, uten restriksjonene som er pålagt smarte kontrakter
• muligheten til å organisere utveksling av meldinger raskere enn transaksjoner er inkludert i blokkjeden, for eksempel kan en del av protokollen fungere mellom noder uten å distribuere meldinger over nettverket

Det har også ulemper:

• Vanskeligheter med testing og utvikling - du må etterligne nettverksfeil, manglende noder, nettverkshardgafler
• Implementeringsfeil krever en nettverkshardfork

Begge metodene for å implementere PVRB har rett til liv, men implementering på smarte kontrakter i moderne blokkjeder er fortsatt ganske begrenset i dataressurser, og enhver overgang til seriøs kryptografi er ofte rett og slett umulig. Og vi vil trenge seriøs kryptografi, som vil bli demonstrert nedenfor. Selv om dette problemet tydeligvis er midlertidig, er det nødvendig med seriøs kryptografi i kontrakter for å løse mange problemer, og det dukker opp gradvis (for eksempel systemkontrakter for zkSNARKs i Ethereum)

Blockchain, som gir en gjennomsiktig og pålitelig protokollmeldingskanal, gjør det ikke gratis. Enhver desentralisert protokoll må ta hensyn til muligheten for et Sybil-angrep; enhver handling kan gjøres av de samordnede styrkene til flere kontoer, derfor er det nødvendig å ta hensyn til angripernes evne til å lage et vilkårlig antall protokoller ved utforming deltakere som handler i samspill.

PVRB og blokkvariabler.

Jeg løy ikke da jeg sa at ingen ennå har implementert en god PVRB, testet av mange gamblingapplikasjoner, i blokkjeder. Hvor kommer så mange gamblingapplikasjoner fra på Ethereum og EOS? Dette overrasker meg like mye som det overrasker deg, hvor fikk de så mange "vedvarende" tilfeldigheter i et fullstendig deterministisk miljø?

Favorittmåten for å få tilfeldighet i blokkjeden er å ta en slags "uforutsigbar" informasjon fra blokken og lage en tilfeldig basert på den - ganske enkelt ved å hashe en eller flere verdier. God artikkel om problemene med slike ordninger her. Du kan ta hvilken som helst av de "uforutsigbare" verdiene i blokken, for eksempel blokkhash, antall transaksjoner, nettverkskompleksitet og andre verdier som er kjent på forhånd. Hash dem deretter, en eller flere, og i teorien bør du få en ekte tilfeldig. Du kan til og med legge til i avisen at opplegget ditt er "post-kvantesikkert" (siden det er kvantesikre hash-funksjoner :)).

Men selv post-kvante sikre hasjer er ikke nok, dessverre. Hemmeligheten ligger i kravene til PVRB, la meg minne deg om dem fra forrige artikkel:

1. Resultatet må ha en beviselig jevn fordeling, det vil si være basert på beviselig sterk kryptografi.
2. Det er ikke mulig å kontrollere noen av bitene av resultatet. Resultatet kan derfor ikke forutsies på forhånd.
3. Du kan ikke sabotere generasjonsprotokollen ved ikke å delta i protokollen eller ved å overbelaste nettverket med angrepsmeldinger
4. Alt det ovennevnte må være motstandsdyktig mot samarbeid mellom et tillatt antall uærlige protokolldeltakere (for eksempel 1/3 av deltakerne).

I dette tilfellet oppfylles kun krav 1, og krav 2 oppfylles ikke. Ved å hashe uforutsigbare verdier fra blokken vil vi få en jevn fordeling og gode tilfeldigheter. Men BP har i det minste muligheten til å "publisere blokkeringen eller ikke." Dermed kan BP i det minste velge mellom TO tilfeldige alternativer: "sin egen" og den som vil vise seg hvis noen andre blokkerer. BP kan "snoope" på forhånd hva som vil skje hvis han publiserer en blokk, og rett og slett bestemmer seg for å gjøre det eller ikke. Når han spiller for eksempel «partall-odd» eller «rød/svart» i rulett, kan han publisere en blokk bare hvis han ser en gevinst. Dette gjør også strategien med å bruke for eksempel en blokkhash "fra fremtiden" ubrukelig. I dette tilfellet sier de at "tilfeldig vil bli brukt, som oppnås ved å hashe gjeldende data og hashen til en fremtidig blokk med en høyde på for eksempel N + 42, der N er gjeldende blokkhøyde. Dette styrker ordningen litt, men lar likevel BP, om enn i fremtiden, velge om de vil holde blokken eller publisere.

BP-programvare i dette tilfellet blir mer komplisert, men ikke mye. Ganske enkelt, når du validerer og inkluderer en transaksjon i en blokk, er det en rask sjekk for å se om det blir en gevinst, og muligens valg av én transaksjonsparameter for å oppnå en høy sannsynlighet for å vinne. Samtidig er det nesten umulig å fange en smart BP for slike manipulasjoner; hver gang kan du bruke nye adresser og vinne litt etter litt uten å vekke mistanke.

Så metoder som bruker informasjon fra blokken er ikke egnet som en universell implementering av PVRB. I en begrenset versjon, med begrensninger på innsatsstørrelser, begrensninger på antall spillere og/eller KYC-registrering (for å forhindre at én spiller bruker flere adresser), kan disse ordningene fungere for små spill, men ikke noe mer.

PVRB og forplikte-avsløre.

Ok, takket være hashing og i det minste den relative uforutsigbarheten til blokkhashen og andre variabler. Hvis du løser problemet med front-runing gruvearbeidere, bør du få noe mer passende. La oss legge til brukere i denne ordningen - la dem også påvirke tilfeldigheten: enhver teknisk støttemedarbeider vil fortelle deg at det mest tilfeldige i IT-systemer er brukernes handlinger :)

Et naivt opplegg, når brukere bare sender tilfeldige tall og resultatet beregnes som for eksempel en hash av summen deres, er ikke egnet. I dette tilfellet kan den siste spilleren, ved å velge sin egen tilfeldige, kontrollere hva resultatet blir. Dette er grunnen til at det svært mye brukte commit-reveal-mønsteret brukes. Deltakerne sender først hashes fra tilfeldighetene sine (forplikter), og åpner deretter tilfeldighetene selv (avslører). "Avsløringsfasen" begynner først etter at de nødvendige forpliktelsene er samlet inn, slik at deltakerne kan sende nøyaktig den tilfeldige hashen de sendte fra tidligere. La oss nå sette alt dette sammen med parametrene til en blokk, og bedre enn en hentet fra fremtiden (tilfeldighet kan bare finnes i en av de fremtidige blokkene), og voila - tilfeldigheten er klar! Nå påvirker enhver spiller den resulterende tilfeldigheten, og kan "bekjempe" den ondsinnede BP ved å overstyre den med sin egen, på forhånd ukjente, tilfeldighet... Du kan også legge til beskyttelse mot sabotering av protokollen ved å ikke åpne den på avsløringsstadiet - ganske enkelt ved å kreve et visst beløp knyttet til transaksjonen ved forpliktelse - et sikkerhetsdepositum, som vil bli returnert bare under avsløringsprosedyren. I dette tilfellet vil det å forplikte seg og ikke avsløre være ulønnsomt.

Det var et godt forsøk, og slike ordninger finnes også i gaming DApps, men akk, dette er igjen ikke nok. Nå kan ikke bare gruvearbeideren, men også enhver deltaker i protokollen påvirke resultatet. Det er fortsatt mulig å kontrollere verdien i seg selv, med mindre variasjon og til en kostnad, men, som i tilfellet med gruvearbeideren, hvis resultatene av tegningen er mer verdifulle enn avgiften for deltakelse i PVRB-protokollen, så er det tilfeldige -produsent(RP) kan bestemme om den skal avsløres og kan fortsatt velge mellom minst to tilfeldige alternativer.
Men det ble mulig å straffe de som forplikter seg og ikke røper, og denne ordningen vil komme godt med. Dens enkelhet er en alvorlig fordel - mer seriøse protokoller krever mye kraftigere beregninger.

PVRB og deterministiske signaturer.

Det er en annen måte å tvinge RP til å gi et pseudo-tilfeldig tall som den ikke kan påvirke hvis den er utstyrt med et "preimage" - dette er en deterministisk signatur. En slik signatur er for eksempel RSA, og er ikke ECS. Hvis RP har et par nøkler: RSA og ECC, og han signerer en viss verdi med sin private nøkkel, vil han i tilfelle RSA få EN OG BARE EN signatur, og i tilfelle ECS kan han generere et hvilket som helst antall forskjellige gyldige signaturer. Dette er fordi når man oppretter en ECS-signatur, brukes et tilfeldig nummer, valgt av underskriveren, og det kan velges på hvilken som helst måte, noe som gir underskriveren mulighet til å velge en av flere signaturer. I tilfellet med RSA: "én inngangsverdi" + "ett nøkkelpar" = "én signatur". Det er umulig å forutsi hvilken signatur en annen RP vil få, så en PVRB med deterministiske signaturer kan organiseres ved å kombinere RSA-signaturene til flere deltakere som signerte samme verdi. For eksempel den forrige tilfeldige. Denne ordningen sparer mye ressurser, pga signaturer er både bekreftelse på riktig oppførsel i henhold til protokollen og en kilde til tilfeldighet.

Men selv med deterministiske signaturer er ordningen fortsatt sårbar for problemet med "siste aktør". Den siste deltakeren kan fortsatt bestemme om han vil publisere signaturen eller ikke, og dermed kontrollere utfallet. Du kan endre skjemaet, legge til blokkhasher til det, lage runder slik at resultatet ikke kan forutsies på forhånd, men alle disse teknikkene, selv med tanke på mange modifikasjoner, lar fortsatt problemet med innflytelsen fra en deltaker på kollektivet være uløst. resultere i et upålitelig miljø og kan bare fungere under økonomiske og tidsmessige begrensninger. I tillegg er størrelsen på RSA-nøkler (1024 og 2048 biter) ganske stor, og størrelsen for blokkjedetransaksjoner er en ekstremt viktig parameter. Tilsynelatende er det ingen enkel måte å løse problemet på, la oss gå videre.

PVRB og hemmelige delingsordninger

I kryptografi er det ordninger som kan tillate nettverket å bli enige om én og bare én PVRB-verdi, mens slike ordninger er motstandsdyktige mot eventuelle ondsinnede handlinger fra enkelte deltakere. En nyttig protokoll som er verdt å gjøre deg kjent med er Shamirs hemmelige delingsopplegg. Den tjener til å dele en hemmelighet (for eksempel en hemmelig nøkkel) i flere deler, og distribuere disse delene til N deltakere. Hemmeligheten er fordelt på en slik måte at M deler av N er nok til å gjenopprette den, og disse kan være alle M-deler. Hvis på fingre, så har en graf av en ukjent funksjon, utveksler deltakerne poeng på grafen, og etter å ha mottatt M poeng, kan hele funksjonen gjenopprettes.
Det er gitt en god forklaring wiki men å leke med det praktisk talt for å spille protokollen i hodet er nyttig for demo side.

Hvis FSSS (Fiat-Shamir Secret Sharing)-ordningen var gjeldende i sin rene form, ville det være en uforgjengelig PVRB. I sin enkleste form kan protokollen se slik ut:

• Hver deltaker genererer sin egen tilfeldige og distribuerer andeler fra den til andre deltakere
• Hver deltaker avslører sin del av hemmelighetene til de andre deltakerne
• Hvis en deltaker har mer enn M aksjer, kan antallet av denne deltakeren beregnes, og det vil være unikt, uavhengig av settet med avslørte deltakere
• Kombinasjonen av avslørte tilfeldigheter er den ønskede PVRB

Her påvirker ikke en individuell deltaker resultatene av protokollen lenger, bortsett fra i tilfeller hvor oppnåelsen av terskelen for tilfeldighetsavsløring kun avhenger av ham. Derfor fungerer denne protokollen, hvis det er en nødvendig andel RP-er som jobber med protokollen og er tilgjengelig, og implementerer kravene til kryptografisk styrke og er motstandsdyktig mot "siste aktør"-problemet.

Dette kan være et ideelt alternativ, denne PVRB-ordningen basert på Fiat-Shamir hemmelig deling er beskrevet for eksempel i dette artikkel. Men, som nevnt ovenfor, hvis du prøver å bruke det direkte i blokkjeden, dukker det opp tekniske begrensninger. Her er et eksempel på en testimplementering av protokollen i EOS-smartkontrakten og dens viktigste del - å sjekke den publiserte aksjedeltakeren: kode. Du kan se fra koden at bevisvalidering krever flere skalarmultiplikasjoner, og tallene som brukes er veldig store. Det skal forstås at i blokkjeder skjer verifisering i det øyeblikket blokkprodusenten behandler transaksjonen, og generelt må enhver deltaker enkelt verifisere riktigheten av protokollen, så kravene til hastigheten til verifiseringsfunksjonen er svært alvorlige . I dette alternativet viste alternativet seg å være ineffektivt, siden verifiseringen ikke passet innenfor transaksjonsgrensen (0.5 sekunder).

Verifikasjonseffektivitet er et av de viktigste kravene for bruk av, generelt, eventuelle avanserte kryptografiske ordninger i blokkjeden. Lage bevis, forberede meldinger - disse prosedyrene kan tas utenfor kjeden og utføres på datamaskiner med høy ytelse, men verifisering kan ikke omgås - dette er et annet viktig krav for PVRB.

PVRB og terskelsignaturer

Etter å ha blitt kjent med den hemmelige delingsordningen, oppdaget vi en hel klasse med protokoller forent med nøkkelordet "terskel". Når avsløring av noe informasjon krever deltakelse av M ærlige deltakere ut av N, og settet med ærlige deltakere kan være en vilkårlig delmengde av N, snakker vi om "terskel"-ordninger. Det er de som lar oss håndtere problemet med "siste skuespiller", nå hvis angriperen ikke avslører sin del av hemmeligheten, vil en annen, ærlig deltaker gjøre det for ham. Disse ordningene tillater enighet om én og bare én betydning, selv om protokollen saboteres av noen av deltakerne.

Kombinasjonen av deterministiske signaturer og terskelordninger gjorde det mulig å utvikle et veldig praktisk og lovende opplegg for implementering av PVRB - dette er deterministiske terskelsignaturer. Her artikkel om de ulike bruken av terskelsignaturer, og her er en annen god en longread fra Dash.

Den siste artikkelen beskriver BLS-signaturer (BLS står for Boneh-Lynn-Shacham, her artikkel), som har en veldig viktig og ekstremt praktisk kvalitet for programmerere - offentlige, hemmelige, offentlige nøkler og BLS-signaturer kan kombineres med hverandre ved hjelp av enkle matematiske operasjoner, mens kombinasjonene deres forblir gyldige nøkler og signaturer, slik at du enkelt kan aggregere mange signaturer til én og mange offentlige nøkler til én. De er også deterministiske og gir samme resultat for de samme inndataene. Takket være denne kvaliteten er kombinasjoner av BLS-signaturer i seg selv gyldige nøkler, noe som muliggjør implementering av et alternativ der M av N deltakere produserer én og bare én signatur som er deterministisk, offentlig verifiserbar og uforutsigbar inntil den åpnes av Mth. deltaker.

I et opplegg med terskel-BLS-signaturer signerer hver deltaker noe ved hjelp av BLS (for eksempel den forrige tilfeldige), og den vanlige terskelsignaturen er den ønskede tilfeldige. De kryptografiske egenskapene til BLS-signaturer tilfredsstiller kravene til tilfeldig kvalitet, terskeldelen beskytter mot "siste-aktør", og den unike kombinerbarheten av nøkler gjør det mulig å implementere mange flere interessante algoritmer som tillater for eksempel effektiv aggregering av protokollmeldinger .

Så hvis du bygger PVRB på blokkjeden din, vil du mest sannsynlig ende opp med BLS-terskelsignaturordningen, flere prosjekter bruker det allerede. For eksempel, DFinity (her benchmark som implementerer kretsen, og her eksempel implementering av verifiserbar hemmelig deling), eller Keep.network (her er deres tilfeldige beacon gult papir, Men eksempel smart kontrakt som betjener protokollen).

Implementering av PVRB

Dessverre ser vi fortsatt ikke en ferdig protokoll implementert i PVRB-blokkjeder som har bevist sin sikkerhet og stabilitet. Selv om selve protokollene er klare, er det ikke lett å teknisk anvende dem på eksisterende løsninger. For sentraliserte systemer gir ikke PVRB mening, og desentraliserte er strengt begrenset i alle dataressurser: CPU, minne, lagring, I/O. Å designe en PVRB er en kombinasjon av forskjellige protokoller for å lage noe som oppfyller alle kravene til i det minste noen levedyktige blokkjeder. Den ene protokollen beregner mer effektivt, men krever flere meldinger mellom RP-er, mens den andre krever svært få meldinger, men å lage et bevis kan være en oppgave som tar titalls minutter, eller til og med timer.

Jeg vil liste opp faktorene du må vurdere når du velger en kvalitets-PVRB:

• Kryptografisk styrke. Din PVRB må være strengt upartisk, uten mulighet til å kontrollere en enkelt bit. I noen ordninger er dette ikke tilfelle, så ring en kryptograf
• Problemet med "siste skuespiller".. Din PVRB må være motstandsdyktig mot angrep der en angriper som kontrollerer en eller flere RP-er kan velge ett av to utfall.
• Protokollsabotasjeproblem. Din PVRB må være motstandsdyktig mot angrep der en angriper som kontrollerer en eller flere RP-er bestemmer om den skal være tilfeldig eller ikke og kan enten garanteres eller med en gitt sannsynlighet for å påvirke dette
• Antall meldinger problem. RP-ene dine bør sende et minimum av meldinger til blokkjeden og unngå synkrone handlinger så mye som mulig, for eksempel situasjoner som "Jeg sendte litt informasjon, jeg venter på svar fra en spesifikk deltaker." I p2p-nettverk, spesielt geografisk spredte, bør du ikke regne med rask respons
• Problemet med beregningsmessig kompleksitet. Verifisering av ethvert stadium av PVRB-kjeden bør være ekstremt enkelt, siden det utføres av alle komplette klienter i nettverket. Hvis implementeringen gjøres ved hjelp av en smart kontrakt, er hastighetskravene svært strenge
• Problemet med tilgjengelighet og livlighet. Din PVRB bør strebe etter å være motstandsdyktig mot situasjoner der en del av nettverket blir utilgjengelig i en periode og en del av RP rett og slett slutter å fungere
• Problemet med pålitelig oppsett og innledende nøkkeldistribusjon. Hvis din PVRB bruker det primære oppsettet av protokollen, så er dette en egen stor og alvorlig historie. Her eksempel. Dersom deltakerne må fortelle hverandre nøklene sine før man starter protokollen, er dette også et problem dersom sammensetningen av deltakere endres
• Utviklingsproblemer. Tilgjengelighet av biblioteker på de nødvendige språkene, deres sikkerhet og ytelse, publisitet, komplekse tester, etc.

For eksempel har terskel BLS-signaturer et betydelig problem - før de begynner å jobbe, må deltakerne distribuere nøkler til hverandre, og organisere en gruppe som terskelen vil fungere innenfor. Dette betyr at minst én utvekslingsrunde i et desentralisert nettverk må vente, og gitt at den genererte randen for eksempel er nødvendig i spill, nesten i sanntid, betyr dette at sabotasje av protokollen er mulig på dette stadiet , og fordelene med terskelordningen går tapt . Dette problemet er allerede enklere enn de forrige, men krever fortsatt utvikling av en egen prosedyre for dannelse av terskelgrupper, som må beskyttes økonomisk, gjennom innskudd og uttak av midler (slashing) fra deltakere som ikke følger protokoll. Dessuten passer BLS-verifisering med et akseptabelt sikkerhetsnivå rett og slett ikke inn i for eksempel en standard EOS- eller Ethereum-transaksjon - det er rett og slett ikke nok tid til verifisering. Kontraktskoden er WebAssembly eller EVM, utført av en virtuell maskin. Kryptografiske funksjoner er ikke implementert naturlig (ennå), og fungerer titalls ganger tregere enn konvensjonelle kryptografiske biblioteker. Mange protokoller oppfyller ikke kravene bare basert på nøkkelvolum, for eksempel 1024 og 2048 bits for RSA, 4-8 ganger større enn standard transaksjonssignatur i Bitcoin og Ethereum.

Tilstedeværelsen av implementeringer på forskjellige programmeringsspråk spiller også en rolle - som det er få av, spesielt for nye protokoller. Alternativet med integrering i konsensus krever at du skriver en protokoll på plattformspråket, så du må se etter kode i Go for geth, i Rust for Parity, i C++ for EOS. Alle må lete etter JavaScript-kode, og siden JavaScript og kryptografi ikke er spesielt nære venner, vil WebAssembly hjelpe, som nå definitivt hevder å være den neste viktige internettstandarden.

Konklusjon

Jeg håper på den forrige artikkel Jeg klarte å overbevise deg om at å generere tilfeldige tall på blokkjeden er avgjørende for mange aspekter av livet til desentraliserte nettverk, og med denne artikkelen viste jeg at denne oppgaven er ekstremt ambisiøs og vanskelig, men gode løsninger finnes allerede. Generelt er den endelige utformingen av protokollen bare mulig etter å ha utført massive tester som tar hensyn til alle aspekter fra oppsett til feilemulering, så det er usannsynlig at du vil finne ferdige oppskrifter i team whitepapers og artikler, og vi vil absolutt ikke bestem deg for i løpet av de neste årene eller to og skriv "gjør det på denne måten, helt riktig."

Hei, for vår PVRB i blokkjeden som utvikles Haya, vi bestemte oss for å bruke terskel BLS-signaturer, vi planlegger å implementere PVRB på konsensusnivå, siden verifisering i smarte kontrakter med et akseptabelt sikkerhetsnivå ennå ikke er mulig. Det er mulig at vi bruker to skjemaer samtidig: først, dyr hemmelig deling for å lage langsiktig random_seed, og deretter bruker vi det som grunnlag for høyfrekvent tilfeldig generering ved å bruke deterministiske terskel BLS-signaturer, kanskje vi vil begrense oss til kun en av ordningene. Dessverre er det umulig å si på forhånd hva protokollen vil være; det eneste gode er at, som i vitenskap, i tekniske problemer, er et negativt resultat også et resultat, og hvert nytt forsøk på å løse problemet er et nytt skritt for forskningen til alle som er involvert i problemet. For å møte forretningskrav løser vi et spesifikt praktisk problem - å gi spillapplikasjoner en pålitelig kilde til entropi, så vi må også ta hensyn til selve blokkjeden, spesielt spørsmålene om kjedefinalitet og nettverksstyring.

Og selv om vi ennå ikke ser en påvist resistent PVRB i blokkjeder, som ville blitt brukt i nok tid til å bli testet av ekte applikasjoner, flere revisjoner, belastninger og selvfølgelig ekte angrep, men antallet mulige veier bekrefter at en løsning finnes, og hva -av disse algoritmene vil til slutt løse problemet. Vi vil gjerne dele resultatene og takke andre team som også jobber med denne saken for artikler og kode som lar ingeniører ikke tråkke på samme rake to ganger.

Så når du møter en programmerer som designer desentralisert tilfeldig, vær oppmerksom og omsorgsfull, og gi psykologisk hjelp om nødvendig :)

Kilde: www.habr.com