Inledning

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

Precis som med konceptet med ett absolut starkt chiffer från kryptografi, försöker verkliga "Publicly Verifiable Random Beacon" (nedan kallade PVRB)-protokoll bara komma så nära det ideala schemat som möjligt, eftersom i riktiga nätverk är det inte tillämpligt i sin rena form: det är nödvändigt att strikt komma överens om en bit, det måste finnas många rundor och alla meddelanden måste vara perfekt snabba och alltid levereras. Så är förstås inte fallet i riktiga nätverk. Därför, när man designar PVRB för specifika uppgifter i moderna blockkedjor, utöver omöjligheten att kontrollera den resulterande slumpmässigheten och kryptografiska styrkan, uppstår många fler rent arkitektoniska och tekniska problem.

För PVRB är själva blockkedjan i huvudsak ett kommunikationsmedium där meddelanden = transaktioner. Detta gör att du delvis kan abstrahera från nätverksproblem, utebliven leverans av meddelanden, problem med mellanprogram - alla dessa risker antas av det decentraliserade nätverket, och dess huvudsakliga värde för PVRB är oförmågan att återkalla eller korrumpera en redan skickad transaktion - detta gör inte tillåta deltagare att vägra att delta i protokollet, såvida de inte genomförde en framgångsrik attack mot konsensus. Denna säkerhetsnivå är acceptabel, så PVRB bör vara resistent mot samverkan från deltagare i exakt samma utsträckning som den huvudsakliga blockkedjan. Detta antyder också att PVRB måste vara en del av konsensus om nätverket kommer överens om huvudblockkedjan, även om det också är överens om den enda rättvisa resulterande slumpen. Eller så är PVRB helt enkelt ett fristående protokoll implementerat av ett smart kontrakt som fungerar asynkront med avseende på blockkedjan och blocken. Båda metoderna har sina fördelar och nackdelar, och valet mellan dem är extremt icke-trivialt.

Två sätt att implementera PVRB

Låt oss beskriva mer detaljerat två alternativ för att implementera PVRB - den fristående versionen, som fungerar med ett smart kontrakt oberoende av blockchain, och den konsensusintegrerade versionen, inbyggd i protokollet, enligt vilken nätverket kommer överens om blockchain och transaktioner som ska inkluderas. I alla fall kommer jag att mena populära blockchain-motorer: Ethereum, EOS och alla de som liknar dem i sättet de är värd för och bearbetar smarta kontrakt.

Fristående kontrakt

I den här versionen är PVRB ett smart kontrakt som accepterar transaktioner från slumpmässiga producenter (hädanefter kallade RP), bearbetar dem, kombinerar resultaten och, som ett resultat, kommer fram till ett visst värde som alla användare kan få från detta kontrakt. Detta värde får inte lagras direkt i kontraktet, utan snarare representeras endast av data från vilka ett och endast ett värde av den resulterande slumpen kan erhållas deterministiskt. I detta schema är RP användare av blockkedjan, och vem som helst kan tillåtas delta i genereringsprocessen.

Alternativet med fristående kontrakt är bra:

• portabilitet (kontrakt kan dras från blockchain till blockchain)
• enkel implementering och testning (kontrakt är lätta att skriva och testa)
• bekvämlighet med att implementera ekonomiska system (det är lätt att göra din egen token, vars logik tjänar syftena med PVRB)
• möjlighet att lansera på redan fungerande blockkedjor

Det har också nackdelar:

• starka begränsningar för datorresurser, transaktionsvolym och lagring (med andra ord cpu/mem/io)
• begränsningar av verksamheten inom kontraktet (alla instruktioner är inte tillgängliga, det är svårt att ansluta externa bibliotek)
• oförmåga att organisera meddelanden snabbare än transaktioner ingår i blockkedjan

Det här alternativet är lämpligt för att implementera en PVRB som behöver köras på ett befintligt nätverk, inte innehåller komplex kryptografi och inte kräver ett stort antal interaktioner.

Konsensusintegrerad

I denna version är PVRB implementerad i blockkedjenodkoden, inbyggd eller körs parallellt med utbyte av meddelanden mellan blockkedjenoder. Resultaten av protokollet skrivs direkt in i de producerade blocken och protokollmeddelanden skickas över p2p-nätverket mellan noder. Eftersom protokollet resulterar i siffror som ska skrivas i block måste nätverket nå konsensus om dem. Detta innebär att PVRB-meddelanden, liksom transaktioner, måste valideras av noder och inkluderas i block så att alla nätverksdeltagare kan validera överensstämmelse med PVRB-protokollet. Detta leder oss automatiskt till den uppenbara lösningen - om nätverket kommer överens om en konsensus om ett block och transaktioner i det, då bör PVRB vara en del av konsensus, och inte ett fristående protokoll. Annars är det möjligt att ett block är giltigt från en konsensussynpunkt, men PVRB-protokollet följs inte, och från PVRB-synpunkt kan blocket inte accepteras. Så om alternativet "konsensusintegrerade" väljs blir PVRB en viktig del av konsensus.

När man beskriver PVRB-implementeringar på nätverkskonsensusnivå kan man inte på något sätt undvika frågor om finalitet. Finalitet är en mekanism som används i deterministiska konsensus som låser in ett block (och kedjan som leder till det) som är slutgiltigt och som aldrig kommer att kastas bort, även om en parallell gaffel uppstår. Till exempel, i Bitcoin finns det ingen sådan mekanism - om du publicerar en kedja av större komplexitet kommer den att ersätta en mindre komplex, oavsett kedjornas längd. Och i EOS, till exempel, är de sista de så kallade Last Irreversible Blocks, som dyker upp i genomsnitt vart 432:e block (12*21 + 12*15, pre-vote + pre-commit). Denna process väntar i huvudsak på 2/3 av blockproducenternas (nedan kallade BP) underskrifter. När gafflar dyker upp som är äldre än den sista LIB, kasseras de helt enkelt. Denna mekanism gör det möjligt att garantera att transaktionen ingår i blockkedjan och aldrig kommer att rullas tillbaka, oavsett vilka resurser angriparen har. De sista blocken är också block signerade av 2/3 BP i Hyperledger, Tendermint och andra pBFT-baserade konsensus. Det är också vettigt att göra ett protokoll för att säkerställa slutgiltighet ett tillägg till konsensus, eftersom det kan fungera asynkront med produktion och publicering av block. Här är en bra artikel om finalitet i Ethereum.

Finalitet är oerhört viktigt för användare, som utan det kan bli offer för en "double spend"-attack, där BP "håller" blockeringar och publicerar dem efter att nätverket har "sett" en bra transaktion. Om det inte finns någon slutgiltighet, ersätter den publicerade gaffeln blocket med en "bra" transaktion med en annan, från en "dålig" gaffel, där samma medel överförs till angriparens adress. När det gäller PVRB är kraven på finalitet ännu strängare, eftersom att bygga gafflar för PVRB innebär möjligheten för en angripare att förbereda flera slumpmässiga alternativ för att publicera det mest lönsamma, och att begränsa tiden för en eventuell attack är en bra lösning.

Därför är det bästa alternativet att kombinera PVRB och finality till ett protokoll - då det slutförda blocket = slutfört slumpmässigt, och det är precis vad vi behövde få. Nu kommer spelare att få en garanterad slumpmässig slump på N sekunder, och kan vara säkra på att det är omöjligt att rulla tillbaka eller spela om det igen.

Det konsensusintegrerade alternativet är bra:

• möjligheten till asynkron implementering i förhållande till produktion av block - block produceras som vanligt, men parallellt med detta kan PVRB-protokollet fungera, vilket inte ger slumpmässighet för varje block
• möjligheten att implementera även tung kryptografi, utan de restriktioner som ställs på smarta kontrakt
• möjligheten att organisera utbyte av meddelanden snabbare än transaktioner ingår i blockkedjan, till exempel kan en del av protokollet fungera mellan noder utan att distribuera meddelanden över nätverket

Det har också nackdelar:

• Svårigheter med testning och utveckling - du måste emulera nätverksfel, saknade noder, nätverkshårda gafflar
• Implementeringsfel kräver en nätverkshardfork

Båda metoderna för att implementera PVRB har rätt till liv, men implementering på smarta kontrakt i moderna blockkedjor är fortfarande ganska begränsade i datorresurser, 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 visas nedan. Även om detta problem helt klart är tillfälligt, behövs seriös kryptografi i kontrakt för att lösa många problem, och det dyker upp gradvis (till exempel systemkontrakt för zkSNARKs i Ethereum)

Blockchain, som tillhandahåller en transparent och pålitlig protokollmeddelandekanal, gör det inte gratis. Varje decentraliserat protokoll måste ta hänsyn till möjligheten av en Sybil-attack; alla åtgärder kan utföras av de samordnade krafterna från flera konton, därför är det nödvändigt att ta hänsyn till angriparnas förmåga att skapa ett godtyckligt antal protokoll. deltagare som agerar i maskopi.

PVRB och blockvariabler.

Jag ljög inte när jag sa att ingen ännu har implementerat en bra PVRB, testad av många spelapplikationer, i blockkedjor. Var kommer så många spelapplikationer ifrån på Ethereum och EOS? Detta förvånar mig lika mycket som det förvånar dig, var fick de så många "beständiga" randoms i en helt deterministisk miljö?

Favoritsättet för att få slumpmässighet i blockkedjan är att ta någon form av "oförutsägbar" information från blocket och göra en slumpmässig sådan baserat på det - helt enkelt genom att hasha ett eller flera värden. Bra artikel om problemen med sådana system här. Du kan ta något av de "oförutsägbara" värdena i blocket, till exempel blockhash, antal transaktioner, nätverkskomplexitet och andra värden som är okända i förväg. Hasha sedan dem, en eller flera, och i teorin bör du få en riktig slumpmässig. Du kan till och med lägga till i wihitepaper att ditt schema är "post-kvantsäkert" (eftersom det finns kvantsäkra hash-funktioner :)).

Men även post-quantum säkra hash räcker tyvärr inte. Hemligheten ligger i kraven för PVRB, låt mig påminna dig om dem från föregående artikel:

1. Resultatet måste ha en bevisligen enhetlig fördelning, det vill säga vara baserat på bevisligen stark kryptografi.
2. Det är inte möjligt att kontrollera någon av bitarna i resultatet. Resultatet kan därför inte förutsägas i förväg.
3. Du kan inte sabotera genereringsprotokollet genom att inte delta i protokollet eller genom att överbelasta nätverket med attackmeddelanden
4. Allt ovanstående måste vara motståndskraftigt mot maskopi av ett tillåtet antal oärliga protokolldeltagare (till exempel 1/3 av deltagarna).

I det här fallet är bara krav 1 uppfyllt och krav 2 är inte uppfyllt. Genom att hasha oförutsägbara värden från blocket får vi en enhetlig fördelning och bra slumpmässiga slumpmässiga värden. Men BP har åtminstone möjligheten att "publicera blocket eller inte." Således kan BP åtminstone välja mellan TVÅ slumpmässiga alternativ: "sin egen" och den som kommer att visa sig om någon annan gör blockeringen. BP kan "snopa" i förväg vad som kommer att hända om han publicerar ett block, och helt enkelt bestämmer sig för att göra det eller inte. När han till exempel spelar "jämnt-udda" eller "röd/svart" i roulette kan han alltså publicera ett block endast om han ser en vinst. Detta gör också strategin att använda till exempel en blockhash "från framtiden" omöjlig att använda. I det här fallet säger de att "slumpmässig kommer att användas, vilket erhålls genom att hasha aktuell data och hash för ett framtida block med en höjd på till exempel N + 42, där N är den aktuella blockhöjden. Detta stärker upplägget en aning, men gör det fortfarande möjligt för BP, om än i framtiden, att välja om det ska hålla blocket eller publicera.

BP programvara i detta fall blir mer komplicerad, men inte mycket. Helt enkelt, när man validerar och inkluderar en transaktion i ett block, finns det en snabb kontroll för att se om det kommer att bli en vinst, och eventuellt val av en transaktionsparametrar för att få en hög sannolikhet att vinna. Samtidigt är det nästan omöjligt att fånga en smart BP för sådana manipulationer; varje gång kan du använda nya adresser och vinna lite i taget utan att väcka misstankar.

Så metoder som använder information från blocket är inte lämpliga som en universell implementering av PVRB. I en begränsad version, med begränsningar för insatsstorlekar, begränsningar av antalet spelare och/eller KYC-registrering (för att förhindra en spelare från att använda flera adresser), kan dessa scheman fungera för små spel, men inget mer.

PVRB och commit-reveal.

Okej, tack vare hash och åtminstone den relativa oförutsägbarheten av blockhash och andra variabler. Om du löser problemet med front-running gruvarbetare, bör du få något mer passande. Låt oss lägga till användare till detta schema - låt dem också påverka slumpmässigheten: alla tekniska supportanställda kommer att berätta för dig att det mest slumpmässiga i IT-system är användarnas handlingar :)

Ett naivt schema, när användare helt enkelt skickar slumpmässiga siffror och resultatet beräknas som till exempel en hash av deras summa, är inte lämpligt. I det här fallet kan den sista spelaren, genom att välja sin egen slumpmässiga, kontrollera vad resultatet blir. Det är därför det mycket använda commit-reveal-mönstret används. Deltagarna skickar först hash från sina randoms (commits) och öppnar sedan själva randoms (avslöjar). “Avslöjningsfasen” börjar först efter att de nödvändiga åtagandena har samlats in, så deltagarna kan skicka exakt den slumpmässiga hash som de skickade från tidigare. Låt oss nu sätta ihop allt detta med parametrarna för ett block, och bättre än en från framtiden (slumpmässighet kan bara hittas i ett av de framtida blocken), och voila - slumpen är klar! Nu påverkar vilken spelare som helst den resulterande slumpmässigheten och kan "besegra" den illvilliga BP genom att åsidosätta den med sin egen, i förväg okända slumpmässighet... Du kan också lägga till skydd mot sabotering av protokollet genom att inte öppna det i avslöjningsstadiet - helt enkelt genom att kräva att ett visst belopp bifogas transaktionen när man begår — en deposition, som kommer att återbetalas först under avslöjningsförfarandet. I det här fallet kommer det att vara olönsamt att begå och inte avslöja.

Det var ett bra försök, och sådana system finns också i spel-DApps, men tyvärr är detta inte tillräckligt. Nu kan inte bara gruvarbetaren, utan även vilken deltagare som helst i protokollet påverka resultatet. Det är fortfarande möjligt att kontrollera själva värdet, med mindre variation och till en kostnad, men, som i fallet med gruvarbetaren, om resultaten av ritningen är mer värdefulla än avgiften för deltagande i PVRB-protokollet, är det slumpmässigt -producent(RP) kan bestämma om den ska avslöjas och kan fortfarande välja mellan minst två slumpmässiga alternativ.
Men det blev möjligt att straffa dem som begår och inte avslöjar, och detta upplägg kommer att vara användbart. Dess enkelhet är en allvarlig fördel - mer seriösa protokoll kräver mycket kraftfullare beräkningar.

PVRB och deterministiska signaturer.

Det finns ett annat sätt att tvinga RP att tillhandahålla ett pseudoslumptal som den inte kan påverka om den är försedd med en "förbild" - detta är en deterministisk signatur. En sådan signatur är till exempel RSA och är inte ECS. Om RP har ett par nycklar: RSA och ECC, och han signerar ett visst värde med sin privata nyckel, kommer han i fallet med RSA att få EN OCH BARA EN signatur, och i fallet med ECS kan han generera valfritt antal olika giltiga signaturer. Detta beror på att när man skapar en ECS-signatur används ett slumpmässigt nummer, valt av undertecknaren, och det kan väljas på vilket sätt som helst, vilket ger undertecknaren möjlighet att välja en av flera signaturer. I fallet med RSA: "ett ingångsvärde" + "ett nyckelpar" = "en signatur". Det är omöjligt att förutsäga vilken signatur en annan RP kommer att få, så en PVRB med deterministiska signaturer kan organiseras genom att kombinera RSA-signaturerna från flera deltagare som skrivit på samma värde. Till exempel den föregående slumpmässiga. Detta system sparar mycket resurser, eftersom Signaturer är både en bekräftelse på det korrekta beteendet enligt protokollet och en källa till slumpmässighet.

Men även med deterministiska signaturer är systemet fortfarande sårbart för problemet med "sista aktör". Den sista deltagaren kan fortfarande bestämma om den ska publicera signaturen eller inte, och därmed styra resultatet. Du kan ändra schemat, lägga till blockhashar till det, göra rundor så att resultatet inte kan förutsägas i förväg, men alla dessa tekniker, även med hänsyn till många ändringar, lämnar fortfarande problemet med en deltagares inflytande på kollektivet olöst. resultera i en opålitlig miljö 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 finns tydligen inget enkelt sätt att lösa problemet, låt oss gå vidare.

PVRB och hemliga delningssystem

Inom kryptografi finns det scheman som kan tillåta nätverket att komma överens om ett och endast ett PVRB-värde, medan sådana scheman är resistenta mot alla skadliga handlingar från vissa deltagare. Ett användbart protokoll som är värt att bekanta dig med är Shamirs hemliga delningsschema. Den tjänar till att dela upp en hemlighet (till exempel en hemlig nyckel) i flera delar och distribuera dessa delar till N deltagare. Hemligheten fördelas på ett sådant sätt att M delar av N räcker för att återställa den, och dessa kan vara vilka M delar som helst. Om på fingrar, sedan med en graf av en okänd funktion, byter deltagarna poäng på grafen, och efter att ha fått M poäng kan hela funktionen återställas.
En bra förklaring ges i wiki men att leka med det praktiskt för att spela protokollet i huvudet är användbart för demo sida.

Om FSSS (Fiat-Shamir Secret Sharing)-schemat var tillämpligt i sin rena form, skulle det vara en oförstörbar PVRB. I sin enklaste form kan protokollet se ut så här:

• Varje deltagare genererar sin egen slumpmässiga och delar ut andelar från den till andra deltagare
• Varje deltagare avslöjar sin del av de andra deltagarnas hemligheter
• Om en deltagare har fler än M aktier, kan antalet av denna deltagare beräknas, och det kommer att vara unikt, oavsett uppsättningen av avslöjade deltagare
• Kombinationen av avslöjade slumpen är den önskade PVRB

Här påverkar inte en enskild deltagare längre resultaten av protokollet, förutom i de fall där uppnåendet av tröskeln för slumpmässig avslöjande enbart beror på honom. Därför fungerar detta protokoll, om det finns en erforderlig andel av RP:er som arbetar med protokollet och är tillgängliga, och implementerar kraven för kryptografisk styrka och är motståndskraftig mot problemet med "sista aktör".

Detta kan vara ett idealiskt alternativ, detta PVRB-schema baserat på Fiat-Shamirs hemlighetsdelning beskrivs till exempel i detta artikel. Men, som nämnts ovan, om du försöker tillämpa det direkt i blockkedjan, dyker det upp tekniska begränsningar. Här är ett exempel på en testimplementering av protokollet i EOS smarta kontrakt och dess viktigaste del - kontroll av den publicerade aktiedeltagaren: код. Du kan se från koden att bevisvalidering kräver flera skalära multiplikationer, och talen som används är mycket stora. Det bör förstås att i blockkedjor sker verifiering i det ögonblick då blockproducenten bearbetar transaktionen, och i allmänhet måste alla deltagare enkelt verifiera protokollets korrekthet, så kraven på verifieringsfunktionens hastighet är mycket allvarliga . I det här alternativet visade sig alternativet vara ineffektivt, eftersom verifieringen inte passade inom transaktionsgränsen (0.5 sekunder).

Verifieringseffektivitet är ett av de viktigaste kraven för användningen av, i allmänhet, alla avancerade kryptografiska system i blockkedjan. Att skapa bevis, förbereda meddelanden - dessa procedurer kan tas utanför kedjan och utföras på högpresterande datorer, men verifiering kan inte kringgås - detta är ett annat viktigt krav för PVRB.

PVRB och tröskelsignaturer

Efter att ha bekantat oss med det hemliga delningsschemat upptäckte vi en hel klass av protokoll förenade av nyckelordet "tröskel". När avslöjandet av viss information kräver deltagande av M ärliga deltagare av N, och uppsättningen av ärliga deltagare kan vara en godtycklig delmängd av N, talar vi om "tröskel"-scheman. Det är de som låter oss ta itu med problemet med "sista skådespelaren", nu om angriparen inte avslöjar sin del av hemligheten kommer en annan, ärlig deltagare att göra det åt honom. Dessa system tillåter enighet om en och endast en mening, även om protokollet saboteras av några av deltagarna.

Kombinationen av deterministiska signaturer och tröskelscheman gjorde det möjligt att utveckla ett mycket bekvämt och lovande system för att implementera PVRB - dessa är deterministiska tröskelsignaturer. Här artikel om de olika användningarna av tröskelsignaturer, och här är en annan bra longread från Dash.

Den sista artikeln beskriver BLS-signaturer (BLS står för Boneh-Lynn-Shacham, här artikel), som har en mycket viktig och extremt bekväm kvalitet för programmerare - offentliga, hemliga, offentliga nycklar och BLS-signaturer kan kombineras med varandra med enkla matematiska operationer, medan deras kombinationer förblir giltiga nycklar och signaturer, vilket gör att du enkelt kan aggregera många signaturer till en och många publika nycklar till en. De är också deterministiska och ger samma resultat för samma indata. Tack vare denna kvalitet är kombinationer av BLS-signaturer i sig giltiga nycklar, vilket möjliggör implementering av ett alternativ där M av N deltagare producerar en och endast en signatur som är deterministisk, offentligt verifierbar och oförutsägbar tills den öppnas av Mth deltagare .

I ett schema med tröskel-BLS-signaturer undertecknar varje deltagare något med hjälp av BLS (till exempel den föregående slumpen), och den gemensamma tröskelsignaturen är den önskade slumpen. BLS-signaturernas kryptografiska egenskaper tillfredsställer kraven på slumpmässig kvalitet, tröskeldelen skyddar mot "last-actor", och den unika kombinerbarheten av nycklar gör det möjligt att implementera många fler intressanta algoritmer som tillåter till exempel effektiv aggregering av protokollmeddelanden .

Så om du bygger PVRB på din blockchain kommer du troligen att sluta med BLS-tröskelsignaturschemat, flera projekt använder det redan. Till exempel, DFinity (här benchmark som implementerar kretsen, och här exempel implementering av verifierbar hemlig delning), eller Keep.network (här är deras slumpmässiga beacon gult papper, och här exempel smart kontrakt som serverar protokollet).

Implementering av PVRB

Tyvärr ser vi fortfarande inte ett färdigt protokoll implementerat i PVRB-blockkedjor som har bevisat sin säkerhet och stabilitet. Även om själva protokollen är klara är det inte lätt att tekniskt tillämpa dem på befintliga lösningar. För centraliserade system är PVRB inte meningsfullt, och decentraliserade är strikt begränsade i alla datorresurser: CPU, minne, lagring, I/O. Att designa en PVRB är en kombination av olika protokoll för att skapa något som uppfyller alla krav för åtminstone någon gångbar blockkedja. Det ena protokollet beräknar mer effektivt, men kräver fler meddelanden mellan RP, medan det andra kräver väldigt få meddelanden, men att skapa ett bevis kan vara en uppgift som tar tiotals minuter, eller till och med timmar.

Jag kommer att lista de faktorer du måste tänka på när du väljer en kvalitets-PVRB:

• Kryptografisk styrka. Din PVRB måste vara strikt opartisk, utan möjlighet att kontrollera en enda bit. I vissa system är detta inte fallet, så ring en kryptograf
• Problemet med "sista skådespelaren".. Din PVRB måste vara resistent mot attacker där en angripare som kontrollerar en eller flera RP:er kan välja ett av två utfall.
• Protokollsabotageproblem. Din PVRB måste vara resistent mot attacker där en angripare som kontrollerar en eller flera RP:er bestämmer sig för om den ska vara slumpmässig eller inte och kan antingen garanteras eller med en given sannolikhet att påverka detta
• Antal meddelanden problem. Dina RP:er bör skicka ett minimum av meddelanden till blockkedjan och undvika synkrona åtgärder så mycket som möjligt, till exempel situationer som "Jag skickade lite information, jag väntar på svar från en specifik deltagare." I p2p-nätverk, särskilt geografiskt spridda, bör du inte räkna med ett snabbt svar
• Problemet med beräkningskomplexitet. Verifiering av alla steg i PVRB-kedjan bör vara extremt enkel, eftersom den utförs av alla kompletta klienter i nätverket. Om implementeringen görs med ett smart kontrakt är hastighetskraven mycket stränga
• Problemet med tillgänglighet och livlighet. 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 period och en del av RP helt enkelt slutar fungera
• Problemet med pålitlig installation och initial nyckeldistribution. Om din PVRB använder den primära inställningen av protokollet, är detta en separat stor och allvarlig historia. Här exempel. Om deltagarna måste berätta för varandra om sina nycklar innan protokollet påbörjas är detta också ett problem om deltagarnas sammansättning ändras
• Utvecklingsfrågor. Tillgänglighet av bibliotek på de språk som krävs, deras säkerhet och prestanda, publicitet, komplexa tester etc.

Till exempel har tröskelvärden för BLS-signaturer ett betydande problem - innan de börjar arbeta måste deltagarna dela ut nycklar till varandra och organisera en grupp inom vilken tröskeln kommer att fungera. Detta innebär att minst en bytesrunda i ett decentraliserat nätverk måste vänta, och med tanke på att den genererade randen till exempel är nödvändig i spel, nästan i realtid, innebär detta att sabotage av protokollet är möjligt i detta skede , och fördelarna med tröskelsystemet går förlorade. Detta problem är redan enklare än de tidigare, men kräver fortfarande utveckling av ett separat förfarande för bildande av tröskelgrupper, som måste skyddas ekonomiskt, genom insättningar och uttag av medel (slashing) från deltagare som inte följer protokoll. Dessutom passar BLS-verifiering med en acceptabel säkerhetsnivå helt enkelt inte, till exempel, i en standard EOS- eller Ethereum-transaktion - det finns helt enkelt inte tillräckligt med tid för verifiering. Kontraktskoden är WebAssembly eller EVM, exekveras av en virtuell maskin. Kryptografiska funktioner är inte implementerade (ännu) och fungerar tiotals gånger långsammare än konventionella kryptografiska bibliotek. Många protokoll uppfyller inte kraven helt enkelt baserat på nyckelvolym, till exempel 1024 och 2048 bitar för RSA, 4-8 gånger större än standardtransaktionssignaturen i Bitcoin och Ethereum.

Förekomsten av implementeringar i olika programmeringsspråk spelar också en roll - som det finns få av, särskilt för nya protokoll. Alternativet med integration i konsensus kräver att du skriver ett protokoll på plattformsspråket, så du måste leta efter kod i Go for geth, i Rust for Parity, i C++ för EOS. Alla kommer att behöva leta efter JavaScript-kod, och eftersom JavaScript och kryptografi inte är särskilt nära vänner kommer WebAssembly att hjälpa, som nu definitivt gör anspråk på att vara nästa viktiga internetstandard.

Slutsats

Jag hoppas på den förra artikeln Jag lyckades övertyga dig om att generering av slumpmässiga siffror på blockkedjan är avgörande för många aspekter av livet för decentraliserade nätverk, och med den här artikeln visade jag att denna uppgift är extremt ambitiös och svår, men bra lösningar finns redan. I allmänhet är den slutliga utformningen av protokollet endast möjlig efter att ha genomfört massiva tester som tar hänsyn till alla aspekter från installation till felemulering, så det är osannolikt att du hittar färdiga recept i teamwhitepapers och artiklar, och det kommer vi verkligen inte att bestäm dig inom nästa år eller två och skriv "gör det på det här sättet, exakt rätt."

Hejdå, för vår PVRB i blockkedjan som utvecklas Haya, vi bestämde oss för att använda tröskelvärden för BLS-signaturer, vi planerar att implementera PVRB på konsensusnivå, eftersom verifiering i smarta kontrakt med en acceptabel säkerhetsnivå ännu inte är möjlig. Det är möjligt att vi använder två scheman samtidigt: först, dyr hemlighetsdelning för att skapa långsiktiga random_seed, och sedan använder vi det som grund för högfrekvent slumpgenerering med deterministiska tröskelvärden BLS-signaturer, kanske kommer vi att begränsa oss till att bara ett av systemen. Tyvärr är det omöjligt att säga i förväg vad protokollet kommer att vara; det enda bra är att, som i vetenskapen, i tekniska problem, är ett negativt resultat också ett resultat, och varje nytt försök att lösa problemet är ytterligare ett steg för forskningen av alla inblandade i problemet. För att möta affärskrav löser vi ett specifikt praktiskt problem - att förse spelapplikationer med en pålitlig källa till entropi, så vi måste också vara uppmärksamma på själva blockkedjan, särskilt frågorna om kedjans slutgiltighet och nätverksstyrning.

Och även om vi ännu inte ser en bevisad resistent PVRB i blockkedjor, som skulle ha använts tillräckligt med tid för att testas av riktiga applikationer, flera granskningar, belastningar och naturligtvis riktiga attacker, men antalet möjliga vägar bekräftar att en lösning finns, och vad av dessa algoritmer kommer så småningom att lösa problemet. Vi delar gärna med oss ​​av resultaten och tackar andra team som också arbetar med den här frågan för artiklar och kod som tillåter ingenjörer att inte kliva på samma rake två gånger.

Så när du möter en programmerare som designar decentraliserat slumpmässigt, var uppmärksam och omtänksam och ge psykologisk hjälp om det behövs :)

Källa: will.com