Introduktion

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

Precis som med konceptet för en absolut robust kryptografisk algoritm, försöker verkliga protokoll för "Publicly Verifiable Random Beacon" (nedan kallat PVRB) bara komma så nära den perfekta schemat som möjligt, eftersom det i verkliga nätverk i ren form inte är tillämpligt: man måste strikt enas om en enda bit, antalet rundor måste vara många, och alla meddelanden måste vara perfekta snabba och alltid levererade. Självklart är detta inte fallet i verkliga nätverk. Därför, vid utformningen av PVRB för specifika uppgifter i moderna blockkedjor, uppstår det, utöver oförmågan att kontrollera det genererade slumpnumret och kryptografisk styrka, många rent arkitektoniska och tekniska problem.

Själva blockkedjan fungerar i princip som en kommunikationsmiljö för PVRB, där meddelandena=transaktionerna. Detta gör det möjligt att delvis abstrahera från nätverksproblem, icke-levererade meddelanden, problem med mellanliggande mjukvara — alla dessa risker tar den decentraliserade nätverket på sig, och dess huvudsakliga värde för PVRB är oförmågan att återkalla eller förstöra en redan skickad transaktion — detta förhindrar deltagare från att dra sig ur protokollet, såvida de inte har genomfört en framgångsrik attack på konsensus. En sådan säkerhetsnivå är acceptabel, varför PVRB måste vara resistent mot sammansvärjningar mellan deltagarna i samma utsträckning som den primära blockkedjan. Detta antyder också att PVRB bör vara en del av konsensus, om nätverket har kommit överens om den primära kedjan av block, likväl borde det också komma överens om en enda ärlig resultatande slump. Alternativt kan PVRB vara ett fristående protokoll, implementerat av ett smart kontrakt, som fungerar asynkront i förhållande till blockkedjan och blocken. Båda metoderna har sina för- och nackdelar, och valet mellan dem är mycket komplext.

Två sätt att implementera PVRB

Låt oss titta närmare på två alternativ för implementering av PVRB — en fristående version, som fungerar med hjälp av ett oberoende smart kontrakt utanför blockkedjan, och en konsensusintegrerad version — inbyggd i protokollet, enligt vilket nätverket kommer överens om blockkedjan och de inkluderade transaktionerna. I alla fall kommer jag att ha i åtanke populära blockkedjemotorer: Ethereum, EOS, och alla som liknar dem i hur smarta kontrakt placeras och bearbetas.

Fristående kontrakt

I detta alternativ representerar PVRB ett smart kontrakt som accepterar transaktioner från random-producer (RP), bearbetar dem, kombinerar resultaten och kommer därmed fram till ett värde som alla användare kan hämta från detta kontrakt. Detta värde behöver inte lagras direkt i kontraktet, utan kan endast representeras av data som deterministiskt kan ge ett och endast ett resultat av den slumpmässiga. I detta scenario är RP användare av blockkedjan, och vem som helst kan tillåtas delta i processen för att generera.

Alternativet med fristående kontrakt är bra:

• bärbarhet (kontrakten kan flyttas mellan blockkedjor)
• enkelheten i implementation och testning (kontrakten är lätta att skriva och testa)
• bekvämligheten att implementera ekonomiska scheman (det är lätt att skapa sin egen token vars logik tjänar syftet för PVRB)
• möjligheten att köra i redan befintliga blockkedjor

Det har också nackdelar:

• strikta begränsningar på resurser under beräkningar, transaktionsvolym och lagring (enklare sagt cpu/mem/io)
• begränsningar på operationer inom kontraktet (inte alla instruktioner är tillgängliga, det är svårt att koppla externa bibliotek)
• omöjligheten att organisera meddelandeutbyte snabbare än transaktionerna inkluderas i blockkedjan

Detta alternativ är lämpligt för implementering av PVRB som behöver köras i ett redan existerande nätverk, utan komplex kryptografi och som inte kräver många interaktioner.

Konsensus-integrerad

I den här varianten är PVRB implementerat i koden för blockchain-noden, integrerat eller fungerar parallellt med meddelandeutbytet mellan blockchain-noderna. Resultaten från protokollet registreras direkt i de producerade blocken, och protokollets meddelanden skickas via p2p-nätverket mellan noderna. Eftersom protokollet resulterar i siffror som måste registreras i blocken, måste nätverket nå konsensus kring dem. Det innebär att PVRB-meddelanden, liksom transaktioner, måste valideras av noderna och inkluderas i blocken så att varje deltagare i nätverket kan validera efterlevnaden av PVRB-protokollet. Detta leder oss automatiskt till den uppenbara lösningen — om nätverket kommer överens om konsensus kring block och transaktioner inom det, så måste PVRB vara en del av konsensus och inte ett fristående protokoll. Annars kan det uppstå en situation där blocket är giltigt ur konsensus synvinkel, men PVRB-protokollet har inte följts, vilket gör att blocket inte kan accepteras ur PVRB:s synvinkel. Så om det valda alternativet är "consensus-integrated" blir PVRB en viktig del av konsensus.

När man beskriver implementationer av PVRB på konsensusnivå i nätverket får man under inga omständigheter hoppa över frågorna kring finalitet. Finalitet är en mekanism som används i deterministiska konsensusförfaranden för att fastställa ett block (och kedjan som leder till det) som är slutgiltigt och aldrig kommer att raderas, även om en parallell gaffel dyker upp. Till exempel finns det ingen sådan mekanism i Bitcoin — om man publicerar en kedja med större svårighetsgrad, kommer den att ersätta vilken mindre svårighetsgrad som helst, oavsett längd på kedjorna. I EOS, å andra sidan, är de så 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 är i grunden en väntan på 2/3 av underskrifterna från blockproducenterna (BP). När forkar dyker upp som är äldre än den senaste LIB, kasseras de helt enkelt. Denna mekanism gör det möjligt att garantera att en transaktion ingår i blockchainen och aldrig kommer att rullas tillbaka, oavsett vilka resurser angriparen har. Dessutom är slutgiltiga block även de block som är signerade av 2/3 av BP i Hyperledger, Tendermint och andra pBFT-baserade konsensuslösningar. Även protokollet för att säkerställa finalitet har meningsfullt att göra som en överbyggnad ovanpå konsensus, eftersom det kan fungera asynkront med produktionen och publiceringen av block. artikeln om slutgiltighet i Ethereum.

Slutgiltighet är extremt viktigt för användare som utan den kan bli offer för "double spend"-attacker, när BP "håller tillbaka" blocken och publicerar dem efter att nätverket "sett" en bra transaktion. Om det inte finns någon slutgiltighet, kommer det publicerade forken att ersätta blocket med den "bra" transaktionen med ett från "dålig" forken, där samma medelöverföringar görs till angriparens adress. I fallet med PVRB skärps kraven på slutgiltighet ytterligare, eftersom byggandet av forkar för PVRB innebär att angriparen kan förbereda flera randomiseringsalternativ för att publicera det mest fördelaktiga för sig själv, och begränsa tiden för en möjlig attack - en bra lösning.

Därför är det bästa alternativet att kombinera PVRB och slutgiltighet i ett enda protokoll - då blir ett slutgiltigt block = slutgiltig randomisering, och det är precis vad som behövdes. Nu kommer spelarna att få garanterad randomisering inom N sekunder, och kan vara säkra på att det inte går att rulla tillbaka eller spela om det.

Alternativet med consensus-integrated är bra:

• möjlighet till asynkron implementering i förhållande till blockproduktion - blocken produceras som vanligt, men samtidigt kan protokollet PVRB arbeta, vilket producerar randomiseringar inte varje block
• möjlighet att implementera även tung kryptografi, utan begränsningar som finns på smarta kontrakt
• möjlighet att organisera meddelandeutbyte snabbare än transaktioner inkluderas i blockchain, till exempel kan en del av protokollet arbeta mellan noder utan att sprida meddelanden genom nätverket

Det har också nackdelar:

• svårigheter vid testning och utveckling - man måste emulera nätverksfel, bortfall av noder, hämta hårt-kotade nätverk
• fel i implementeringen kräver en hård gaffel av nätverket

Båda implementeringsmetoderna för PVRB har rätt att existera, men implementeringen på smarta kontrakt i moderna blockkedjor är ändå ganska kraftigt begränsad av beräkningsresurser, och varje övergång till seriös kryptografi är ofta helt enkelt omöjlig. Och vi kommer att behöva seriös kryptografi, vilket kommer att demonstreras nedan. Även om detta problem har en tydligt temporär karaktär, behövs seriös kryptografi i kontrakt för att lösa många uppgifter, och den dyker gradvis upp (till exempel systemkontrakt för zkSNARKs i Ethereum).

Blockchain, som säkerställer en transparent och pålitlig kommunikationskanal för protokollet, kostar inte gratis. Alla decentraliserade protokoll måste beakta risken för Sybil-attacker, eftersom vilka handlingar som helst kan utföras av en överenskommen mängd konton, därför måste man vid designen ta hänsyn till angriparnas möjligheter att skapa ett godtyckligt antal medlemmar i protokollet som agerar i samförstånd.

PVRB och blockvariabler.

Jag ljög inte när jag sa att en bra PVRB, som testats av många gambling-appar, hittills inte har implementerats i blockkedjor. Varifrån kom då alla dessa gambling-appar i Ethereum och EOS? Det förvånar mig lika mycket som er; hur fick man fram så många ”beständiga” slumpmässigheter i en helt deterministisk miljö?

Det vanligaste sättet att få fram slumpmässighet i blockkedjan är att använda någon form av ”oförutsägbar” information från blocket och skapa slumpmässighet utifrån detta genom att hash-a ett eller flera värden. En bra artikel om problemen med sådana scheman. härMan kan ta något av de ”oförutsägbara” värdena i blocket, som blockhash, antal transaktioner, nätverkets svårighetsgrad och andra värden som inte är kända på förhand. Sedan kan man hash-a dem, ett eller flera, och i teorin borde man få riktig slumpmässighet. Man kan till och med nämna i whitepaper att ens schema är ”post-quantum secure” (eftersom det finns kvantresistenta hash-funktioner :)).

Men även post-quantum resistenta hash-funktioner räcker tyvärr inte. Hemligheten ligger i kraven för PVRB, som jag påminner om från den tidigare artikeln:

1. Resultatet måste ha ett bevisligen jämnt fördelat resultat, dvs baserat på bevisligen säker kryptografi.
2. Ingen bit av resultatet kan kontrolleras. Som en följd kan resultatet inte förutsägas i förväg.
3. Protokollet för generation får inte saboteras genom att inte delta i protokollet eller genom att överbelasta nätverket med attackerande meddelanden.
4. Allt ovanstående måste vara motståndskraftigt mot sammansvärjningar av ett tillåtet antal oärliga deltagare i protokollet (t.ex. 1/3 av deltagarna).

I det här fallet följs endast krav 1, och krav 2 följs inte. Genom att hashera oförutsägbara värden från blocket får vi en jämn fördelning och bra slumpmässighet. Men BP har åtminstone möjligheten att "publicera blocket eller inte". Således kan BP åtminstone välja mellan TVÅ alternativ av slumpmässighet: "sitt" och det som blir om blocket görs av någon annan. BP kan på förhand "tjuvkika" på vad som kommer att hända om han publicerar blocket och helt enkelt besluta att göra det eller inte. Således, genom att spela till exempel "jämnt-ojämnt" eller "röd/svart" i roulette, kan han publicera blocket endast om han ser att det blir en vinst. Detta gör också strategin för att använda, till exempel, hash av blocket "från framtiden" ineffektiv. I detta fall sägs det att "en slumpmässighet kommer att användas, som fås genom att hashera nuvarande data och hashen av det framtida blocket på en höjd, till exempel N + 42, där N är den nuvarande höjden av blocket. Detta förstärker schemat något, men ger fortfarande BP, om än i framtiden, möjligheten att välja att hålla tillbaka blocket eller publicera det.

BP:s mjukvara kompliceras i detta fall, men inte mycket. Vid validering och inkludering av transaktionen i blocket görs en snabb kontroll för att se om det blir en vinst, och möjligtvis justering av en parameter i transaktionen för att få hög sannolikhet för vinst. Samtidigt är det nästan omöjligt att fånga en smart BP med sådana manipulationer, varje gång kan nya adresser användas, och vinna lite åt gången utan att väcka misstankar.

Så sätt som använder information från blocket är inte lämpade som en universell implementation av PVRB. I en begränsad version, med begränsningar på insatsstorlekar, begränsningar på antal spelare och/eller KYC-registrering (för att inte ge en spelare möjlighet att använda flera adresser), kan dessa scheman fungera för små spel, men inte mer än så.

PVRB och commit-reveal.

Okej, tack vare hashning och åtminstone den relativa oförutsägbarheten av blockhash och andra variabler. Om vi kan lösa problemet med minerarnas front-running, borde vi få något mer solid. Låt oss lägga till användare i detta schema - låt dem också påverka slumpen: vilken teknisk supportanställd som helst kommer att säga att det mest slumpmässiga i IT-system är användarnas beteende 🙂

En naiv plan där användare bara skickar slumpmässiga nummer och resultatet beräknas som till exempel hash av deras summa fungerar inte. I det här fallet kan den sista spelaren, genom att välja sin egen slumpmässighet, kontrollera vilket resultat som blir. Därför används ett mycket välkänt mönster, commit-reveal. Deltagarna skickar först hash av sina slumpmässigheter (commits), och sedan öppnar de sina slumpmässigheter (reveal). Fasens "reveal" börjar först efter att nödvändiga commits har samlats in, så deltagarna kan skicka exakt den slumpmässighet vars hash de skickade tidigare. Nu kan vi kombinera allt detta med blockparameterar, gärna hämtat från framtiden (slumptalet kan endast kännedom i ett av framtida block), och voilà – slumptalet är klart! Nu påverkar varje spelare det resulterande slumptalet och kan "vinna" över den illvilliga BP genom att täcka hans slumpmässighet med sin egen, som inte är känd i förväg... Vi kan också lägga till skydd mot sabotage av protokollet genom att inte avslöja i reveal-steget – bara kräva att en viss summa bifogas transaktionen vid commit – en försäkringsdeposition som endast återbetalas vid reveal-processen. I detta fall skulle det vara olönsamt att göra commit och inte göra reveal.

Det var ett bra försök, och sådana planer finns också i spel-DApp:ar, men tyvärr är det återigen inte tillräckligt. Nu kan resultatet påverkas inte bara av miner, utan även av varje deltagare i protokollet. Att kontrollera värdet i sig kan fortfarande göras, med en lägre grad av variation och för pengar, men, precis som i fallet med minern, om resultaten av utlottningen är mer värdefulla än kostnaden för deltagande i PVRB-protokollet, kan random-producer (RP) besluta om han ska göra reveal och kan fortfarande välja mellan minst två alternativ för slumpmässighet.
Men nu finns möjligheten att straffa de som gör commit och inte gör reveal, och detta mönster kommer fortfarande att vara användbart. Dess enkelhet är en stor fördel – mer komplexa protokoll kräver mycket kraftigare beräkningar.

PVRB och deterministiska signaturer.

Det finns ett annat sätt att få RP att ge ett pseudorandomnummer, som hen inte kan påverka, om hen ges en "prototyp" — det är 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ärde med sin privata nyckel, så får hen med RSA ENDAST EN signatur, medan hen med ECS kan generera ett antal olika giltiga signaturer. Detta beror på att vid skapandet av en ECS-signatur används ett slumpmässigt nummer som väljs av signatären, och det kan väljas på vilket sätt som helst, vilket ger signatären möjlighet att välja mellan flera signaturer. I fallet med RSA: "ett indata-värde" + "ett nyckelpar" = "en signatur". Det är omöjligt att förutsäga vilken signatur en annan RP kommer att få, därför kan PVRB med deterministiska signaturer organiseras genom att kombinera RSA-signaturer från flera deltagare som signerat samma värde. Till exempel — en tidigare slump. I ett sådant system sparas många resurser, eftersom signaturerna fungerar både som bekräftelse på korrekt beteende enligt protokollet samt som en källa till slumpen.

Ändå, även med deterministiska signaturer är systemet fortfarande sårbart för problemet "last actor". Den sista deltagaren kan fortfarande bestämma om hen vill publicera sin signatur eller inte, vilket ger hen kontroll över resultatet. Det går att vidareutveckla systemet, lägga till blockhashar, skapa rundor för att förutsäga resultatet i förväg, men alla dessa metoder, trots många förbättringar, lämnar ändå problemet med påverkan från en enskild deltagare på det kollektiva resultatet i en osäker miljö olöst och kan endast fungera under ekonomiska och tidsmässiga begränsningar. Dessutom är storleken på RSA-nycklar (1024 och 2048 bitar) ganska stor, och storleken för blockchain-transaktioner är en extremt viktig parameter. Det verkar som om vi inte enkelt kan lösa problemet, så vi går vidare.

PVRB och secret sharing-system

In kryptografi finns det scheman som kan låta nätverket komma överens om ett och endast ett värde av PVRB, och dessa scheman är motståndskraftiga mot alla illvilliga handlingar från vissa deltagare. En av de användbara protokollen som är värt att bekanta sig med är Shamir's hemlighetsdelningsschema. Det används för att dela en hemlighet (till exempel en hemlig nyckel) i flera delar och distribuera dessa delar till N deltagare. Hemligheten fördelas på ett sätt som gör att för att återställa den räcker med M delar av N, och det kan vara vilka som helst av M delar. Om vi förenklar det, så utbyter deltagarna punkter på en graf av en okänd funktion, och efter att ha fått M punkter kan hela funktionen återställas.
En bra förklaring ges i wiki och att faktiskt leka med det för att få protokollet att fastna i huvudet är användbart på demo sidan.

Om FSSS (Fiat-Shamir Secret Sharing) schemat skulle kunna tillämpas i sin renaste form – skulle det vara ett oövervinneligt PVRB. I sin mest grundläggande form kan protokollet se ut så här:

• Varje deltagare genererar sin egen slumpmässiga och ger ut shares från den till de övriga deltagarna
• Varje deltagare avslöjar sin del av de andra deltagarnas hemligheter
• Om det för en deltagare har samlats mer än M shares, kan den deltagarens nummer beräknas och det kommer att vara unikt, oavsett uppsättningen av avslöjade deltagare
• Kombinationen av de avslöjade random-värdena är den eftertraktade PVRB

Här påverkar enskilda deltagare inte protokollets resultat, utom i de fall där det bara beror på dem att uppnå tröskeln för avslöjandet av den slumpmässiga. Därför, om den erforderliga andelen som arbetar enligt protokollet och tillgängliga RP är uppfyllt, fungerar detta protokoll och uppfyller kraven för kryptografisk motståndskraft och är robust mot "last actor"-problemet.

Detta skulle kunna vara det perfekta alternativet, detta PVRB-schema baserat på hemlighetsdelning av Fiat-Shamir beskrivs till exempel i denna artikeln. Men, som nämnts tidigare, om man försöker tillämpa det bokstavligt i blockchain, uppstår tekniska begränsningar. Här är ett exempel på en testimplementering av protokollet i smartkontraktet EOS och den mest viktiga delen av det — kontroll av den publicerade share från deltagaren: kod. Koden visar att valideringen av proofet kräver flera skalära multiplikationer, och siffrorna som används är mycket stora. Det är viktigt att förstå att i blockkedjor sker verifieringen när blockproducenten bearbetar transaktionen, och varje deltagare måste enkelt kunna verifiera korrektheten av protokollet, så kraven på hastighet för verifieringsfunktionen är mycket strikta. I denna version visade sig alternativet vara ofunktionellt, eftersom verifieringen inte höll sig inom transaktionsgränsen (0,5 sek).

Effektiviteten i verifieringen är ett av de viktigaste kraven för användning av i huvudsak alla avancerade kryptografiska scheman i blockkedjan. Att skapa proofs, förbereda meddelanden — dessa procedurer kan utföras off-chain och på högpresterande datorer, men att kringgå verifieringen är inte möjligt — det är ytterligare ett viktigt krav för PVRB.

PVRB och threshold-signaturer

Genom att bekanta oss med schemat för secret sharing har vi öppnat en hel klass av protokoll som förenas av nyckelordet "threshold". När M är antalet ärliga deltagare som krävs av N för att avslöja viss information, och uppsättningen av ärliga deltagare kan vara vilken som helst delmängd av N, talar vi om "threshold"-scheman. Dessa gör det möjligt att lösa problemet med 'last actor', eftersom om en angripare inte avslöjar sin del av hemligheten, kommer en annan ärlig deltagare att göra det. Dessa scheman möjliggör att man enas om ett och endast ett värde, även vid sabotage av protokollet av en del av deltagarna.

Kombinationen av deterministiska signaturer och threshold-scheman har lett till utvecklingen av ett mycket praktiskt och lovande schema för att implementera PVRB — det är deterministiska threshold-signaturer. Här är artikeln om olika tillämpningar av threshold-signaturer, och här är ytterligare en bra långläsning från Dash.

Den senaste artikeln beskriver BLS-signaturer (BLS står för Boneh-Lynn-Shacham, här artikel ), som har en mycket viktig och extremt bekväm egenskap för programmerare – publika, hemliga, publika nycklar och BLS-signaturer kan kombineras med varandra genom enkla matematiska operationer, och deras kombinationer förblir giltiga nycklar och signaturer, vilket möjliggör enkel aggregat av många signaturer till en och många publika nycklar till en. De har även determinism och ger samma resultat vid samma ingångsvärden. Tack vare denna egenskap är kombinationerna av BLS-signaturer själva giltiga nycklar, vilket möjliggör en variant där M av N deltagare producerar en och endast en signatur, som är deterministisk, publikt verifierbar och oförutsägbar tills den avslöjas av den M:e deltagaren.

I systemet med threshold BLS-signaturer skriver varje deltagare under något med hjälp av BLS (till exempel den tidigare slumpen), och den totala threshold-signaturen är den eftertraktade slumptal. De kryptografiska egenskaperna hos BLS-signaturer uppfyller kraven för kvaliteten på slump, threshold-delen skyddar mot "last-actor", och den unika kombinerbarheten av nycklar möjliggör implementeringen av många intressanta algoritmer som till exempel effektivt kan aggregera meddelanden från protokollet.

Så om du bygger PVRB i din blockchain, kommer du med stor sannolikhet att landa på en BLS threshold-signaturschema, och flera projekt använder den redan. Till exempel DFinity (här benchmark som implementerar schemat, och ). Ett typiskt exempel på användning: exempel på implementering av verifierbar hemlig delning), eller Keep.network (här är deras slumptal yellowpaper, och här är exempel smartkontraktet som betjänar protokollet).

Implementering av PVRB

Tyvärr ser vi fortfarande inte ett färdigt protokoll, implementerat i blockchain PVRB, som har bevisats vara säkert och robust. Även om protokollen är klara är det tekniskt svårt att tillämpa dem på befintliga lösningar. För centraliserade system är PVRB meningslöst, och decentraliserade system är strikt begränsade i alla beräkningsresurser: CPU, minne, lagring, I/O. Designen av PVRB handlar om att kombinera olika protokoll för att åstadkomma något som uppfyller alla krav för att kunna fungera som ett livskraftigt blockchain. Ett protokoll utför beräkningar effektivare, men kräver fler meddelanden mellan RP, medan ett annat kräver mycket färre meddelanden men skapandet av proof kan ta tiotals minuter, ibland timmar.

Jag kommer att nämna de faktorer som du måste ta hänsyn till när du väljer en kvalitativ PVRB:

• Kryptografisk styrka. Din PVRB måste vara strikt obiaserbar, utan möjlighet att kontrollera en enda bit. I vissa upplägg är det inte så, så kalla på en kryptograf.
• Problemet med "last actor". Din PVRB måste vara motståndskraftig mot attacker där en angripare som kontrollerar en eller flera RP kan välja mellan två resultatalternativ.
• Problemet med sabotage av protokollet. Din PVRB måste vara motståndskraftig mot attacker där en angripare som kontrollerar en eller flera RP beslutar om det ska vara slumpmässigt eller inte och kan garantera, eller med en given sannolikhet påverka detta.
• Problemet med antalet meddelanden. Dina RP måste skicka så få meddelanden som möjligt till blockchain och maximalt undvika synkrona handlingar, som situationer där "jag har skickat viss information, väntar på svar från en specifik deltagare". I p2p-nätverk, särskilt geografiskt spridda, bör man inte räkna med snabba svar.
• Problemet med beräkningskomplexitet. Verifiering av vilket steg som helst i PVRB on-chain måste vara extremt lätt, eftersom det utförs av alla fullständiga noder i nätverket. Om implementeringen görs med hjälp av ett smart kontrakt är kraven på hastighet mycket strikta.
• Problemet med tillgänglighet och livslängd. Din PVRB bör sträva efter att vara motståndskraftig mot situationer där en del av nätverket blir otillgängligt under en tid och en del RP helt enkelt slutar att fungera.
• Problemet med trusted setup och den initiala distributionen av nycklar.. Om din PVRB använder primär setup-protokoll, är detta en helt separat och allvarlig historia. Här är exempel. Om deltagarna måste meddela varandra sina nycklar innan protokollet börjar - är detta också ett problem om deltagarna ändras
• Utvecklingsproblem. Förekomsten av bibliotek på rätt språk, deras säkerhet och prestanda, offentlighet, komplexa tester, etc.

Till exempel har threshold BLS-signaturer ett betydande problem - innan de börjar arbeta måste deltagarna nödvändigtvis dela ut sina nycklar och organisera en grupp inom vilken threshold kommer att fungera. Detta innebär att minst en runda utbyte i ett decentraliserat nätverk måste vänta, och med tanke på att det genererade slumpmässiga talet, till exempel, behövs i spel, praktiskt taget i realtid, innebär detta att sabotage av protokollet är möjligt vid detta stadium, och fördelarna med threshold-schemat förloras. Detta problem är redan enklare än det föregående, men det kräver fortfarande utvecklingen av en separat procedur för att bilda threshold-grupper, som måste skyddas ekonomiskt genom insättningar och avskräckning av medel (slashing) från deltagare som inte följer protokollet. Dessutom ryms verifiering av BLS med acceptabel säkerhetsnivå helt enkelt inte, till exempel, inom en standardtransaktion i EOS eller Ethereum - det finns helt enkelt inte tillräckligt med tid för verifiering. Koden för kontrakten är WebAssembly eller EVM, som körs av en virtuell maskin. Kryptografiska funktioner är inte implementerade på ett nativt sätt (än), och arbetar tiotals gånger långsammare än vanliga kryptografiska bibliotek. Många protokoll passar inte kraven helt enkelt baserat på volymen på nycklar, som till exempel 1024 och 2048 bit för RSA, 4-8 gånger mer än standardsignaturen i Bitcoin och Ethereum.

Det spelar också roll om det finns implementeringar på olika programmeringsspråk - vilket är få, särskilt för nya protokoll. Alternativet med integration i konsensus kräver att protokollet skrivs på plattformens språk, så man måste leta efter kod på Go för geth, på Rust för Parity, på C++ för EOS. Koden på JavaScript måste alla leta efter, och eftersom JavaScript och kryptografi inte är riktigt nära vänner, hjälper WebAssembly, som nu definitivt aspirerar på att bli nästa viktiga internetstandard.

Slutsats

Jag hoppas, i det föregående artikeln Jag har lyckats övertyga er om att generering av slumpmässiga tal på blockkedjan är kritiskt viktig för många aspekter av livet i decentraliserade nätverk. Denna artikel visar att denna uppgift är extremt ambitiös och svår, men bra lösningar finns redan. Generellt är den slutgiltiga designen av protokollet möjlig först efter omfattande tester som tar hänsyn till alla aspekter, från setup till simulering av fel. Därför kommer ni knappast att hitta färdiga recept i whitepapers från team och artiklar, och inte heller kommer vi under det kommande året eller två att våga skriva “gör så här, så är det helt korrekt.”

För vår PVRB i den under utveckling blockkedjan Haya, har vi stannat vid användningen av threshold BLS-signaturer. Vi planerar att implementera PVRB på konsensusnivå, eftersom verifiering i smarta kontrakt med en acceptabel säkerhetsnivå för närvarande är omöjlig. Det är möjligt att vi använder två system: först den kostsamma hemliga delningen för att skapa en långsiktig random_seed, och den använder vi sedan som grund för högfrekvent slumpgenerering med hjälp av deterministiska threshold BLS-signaturer, eller så kan vi begränsa oss till bara ett av systemen. Det är tyvärr omöjligt att säga i förväg hur protokollet kommer att se ut, men det gläder oss att liksom i vetenskap är ett negativt resultat också ett resultat inom ingenjörsuppgifter, och varje nytt försök att lösa problemet är ett steg framåt för alla som arbetar med denna fråga. För att uppfylla krav från företaget löser vi en konkret praktisk uppgift — att förse spelapplikationer med en pålitlig källa till entropi, så vi måste också ägna uppmärksamhet åt själva blockkedjan, särskilt frågor om kedjans finalitet och nätverkets governance.

Och även om vi för närvarande inte ser en bevisat robust PVRB i blockkedjor som har använts tillräckligt länge för att klara tester av verkliga applikationer, flera revisioner, belastningar, och inte minst verkliga attacker, så bekräftar antalet möjliga vägar att en lösning finns, och någon av dessa algoritmer kommer till slut att lösa problemet. Vi ser fram emot att dela resultaten och tackar andra team som också arbetar med denna fråga för artiklar och kod som gör det möjligt för ingenjörer att inte snubbla över samma hinder två gånger.

Så när du möter en programmerare som designar en decentraliserad slumpgenerator, var uppmärksam och omtänksam, ge psykologiskt stöd om det behövs 🙂

Källa: habr.com