Introductie

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

Net als bij het concept van een absoluut sterk cijfer uit de cryptografie, proberen echte ‘Publicly Verifiable Random Beacon’ (hierna PVRB)-protocollen alleen zo dicht mogelijk bij het ideale schema te komen, omdat in echte netwerken is het in zijn pure vorm niet toepasbaar: het is noodzakelijk om het strikt over één bit eens te worden, er moeten veel rondes zijn en alle berichten moeten perfect snel zijn en altijd worden afgeleverd. Bij echte netwerken is dit uiteraard niet het geval. Daarom doen zich bij het ontwerpen van PVRB’s voor specifieke taken in moderne blockchains, naast de onmogelijkheid om de resulterende willekeur en cryptografische kracht te beheersen, nog veel meer puur architecturale en technische problemen voor.

Voor PVRB is de blockchain zelf in wezen een communicatiemedium waarin berichten = transacties. Hierdoor kunt u gedeeltelijk abstractie maken van netwerkproblemen, het niet bezorgen van berichten en problemen met middleware - al deze risico's worden overgenomen door het gedecentraliseerde netwerk, en de belangrijkste waarde ervan voor PVRB is het onvermogen om een ​​reeds verzonden transactie in te trekken of te corrumperen - dit doet niet toestaan ​​dat deelnemers weigeren deel te nemen aan het protocol, tenzij ze een succesvolle aanval op de consensus hebben uitgevoerd. Dit beveiligingsniveau is acceptabel, dus PVRB moet in precies dezelfde mate bestand zijn tegen samenzwering door deelnemers als de belangrijkste blockchain-keten. Dit duidt er ook op dat de PVRB deel moet uitmaken van de consensus als het netwerk het eens is over de belangrijkste blockchain, zelfs als het het ook eens is over de enige eerlijke resulterende willekeurige uitkomst. Of PVRB is eenvoudigweg een op zichzelf staand protocol geïmplementeerd door een slim contract dat asynchroon werkt met betrekking tot de blockchain en blokken. Beide methoden hebben hun voor- en nadelen, en de keuze ertussen is uiterst niet triviaal.

Twee manieren om PVRB te implementeren

Laten we twee opties voor de implementatie van PVRB gedetailleerder beschrijven: de stand-alone versie, die werkt met behulp van een slim contract dat onafhankelijk is van de blockchain, en de consensus-geïntegreerde versie, ingebouwd in het protocol, volgens welke het netwerk overeenstemming bereikt over de blockchain en de transacties op te nemen. In alle gevallen bedoel ik populaire blockchain-engines: Ethereum, EOS en al degenen die op hen lijken in de manier waarop ze slimme contracten hosten en verwerken.

Op zichzelf staand contract

In deze versie is PVRB een slim contract dat transacties van willekeurige producenten (hierna RP genoemd) accepteert, deze verwerkt, de resultaten combineert en als resultaat tot een bepaalde waarde komt die elke gebruiker uit dit contract kan ontvangen. Deze waarde wordt mogelijk niet rechtstreeks in het contract opgeslagen, maar wordt alleen weergegeven door gegevens waaruit op deterministische wijze slechts één waarde van de resulterende willekeurige waarde kan worden verkregen. In dit schema zijn RP’s gebruikers van de blockchain en kan iedereen deelnemen aan het generatieproces.

De optie met een zelfstandig contract is goed:

• portabiliteit (contracten kunnen van blockchain naar blockchain worden gesleept)
• gemak van implementatie en testen (contracten zijn eenvoudig te schrijven en te testen)
• gemak bij het implementeren van economische plannen (het is gemakkelijk om uw eigen token te maken, waarvan de logica de doeleinden van PVRB dient)
• mogelijkheid om te lanceren op reeds werkende blockchains

Het heeft ook nadelen:

• sterke beperkingen op computerbronnen, transactievolume en opslag (met andere woorden, cpu/mem/io)
• beperkingen op bewerkingen binnen het contract (niet alle instructies zijn beschikbaar, het is moeilijk om externe bibliotheken aan te sluiten)
• het onvermogen om berichten sneller te organiseren dan transacties is opgenomen in de blockchain

Deze optie is geschikt voor het implementeren van een PVRB die op een bestaand netwerk moet draaien, geen complexe cryptografie bevat en geen groot aantal interacties vereist.

Consensus-geïntegreerd

In deze versie is PVRB geïmplementeerd in de blockchain-knooppuntcode, ingebouwd of parallel uitgevoerd met de uitwisseling van berichten tussen blockchain-knooppunten. De resultaten van het protocol worden rechtstreeks in de geproduceerde blokken geschreven en protocolberichten worden via het p2p-netwerk tussen knooppunten verzonden. Omdat het protocol resulteert in getallen die in blokken moeten worden geschreven, moet het netwerk daarover consensus bereiken. Dit betekent dat PVRB-berichten, net als transacties, moeten worden gevalideerd door knooppunten en moeten worden opgenomen in blokken, zodat elke netwerkdeelnemer de naleving van het PVRB-protocol kan valideren. Dit leidt ons automatisch naar de voor de hand liggende oplossing: als het netwerk overeenstemming bereikt over een consensus over een blok en de transacties daarin, dan zou PVRB deel moeten uitmaken van de consensus, en niet een op zichzelf staand protocol. Anders is het mogelijk dat een blokkering geldig is vanuit een consensusoogpunt, maar dat het PVRB-protocol niet wordt gevolgd en dat de blokkering vanuit het PVRB-oogpunt niet kan worden geaccepteerd. Dus als de “consensus-geïntegreerde” optie wordt gekozen, wordt de PVRB een belangrijk onderdeel van de consensus.

Bij het beschrijven van PVRB-implementaties op netwerkconsensusniveau kan men op geen enkele manier kwesties van finaliteit vermijden. Finaliteit is een mechanisme dat wordt gebruikt in deterministische consensuss en dat een blok (en de keten die ernaartoe leidt) vastlegt dat definitief is en nooit zal worden weggegooid, zelfs als er een parallelle vork plaatsvindt. In Bitcoin bestaat een dergelijk mechanisme bijvoorbeeld niet: als je een keten met een grotere complexiteit publiceert, zal deze elke minder complexe keten vervangen, ongeacht de lengte van de ketens. En in EOS zijn de laatste bijvoorbeeld de zogenaamde Last Irreversible Blocks, die gemiddeld elke 432 blokken verschijnen (12*21 + 12*15, pre-vote + pre-commit). Dit proces wacht in wezen op de handtekeningen van tweederde van de blokproducenten (hierna BP genoemd). Wanneer er vorken verschijnen die ouder zijn dan de laatste LIB, worden ze eenvoudigweg weggegooid. Dit mechanisme maakt het mogelijk om te garanderen dat de transactie in de blockchain wordt opgenomen en nooit meer teruggedraaid zal worden, ongeacht over welke middelen de aanvaller beschikt. Bovendien zijn de laatste blokken blokken ondertekend door 2/3 BP in Hyperledger, Tendermint en andere op pBFT gebaseerde consensussen. Het is ook zinvol om van een protocol voor het garanderen van de finaliteit een aanvulling op de consensus te maken, omdat het asynchroon kan werken met de productie en publicatie van blokken. Hier is een goede artikel over finaliteit in Ethereum.

Finaliteit is uiterst belangrijk voor gebruikers, die zonder deze finaliteit het slachtoffer kunnen worden van een ‘double spend’-aanval, waarbij BP blokken ‘vasthoudt’ en deze publiceert nadat het netwerk een goede transactie heeft ‘gezien’. Als er geen finaliteit is, vervangt de gepubliceerde fork het blok door een ‘goede’ transactie door een andere, van een ‘slechte’ fork, waarbij hetzelfde geld wordt overgemaakt naar het adres van de aanvaller. In het geval van PVRB zijn de vereisten voor finaliteit zelfs nog strenger, omdat het bouwen van forks voor PVRB de mogelijkheid voor een aanvaller betekent om verschillende willekeurige opties voor te bereiden om zo de meest winstgevende te publiceren, en het beperken van de tijd van een mogelijke aanval een goede oplossing.

Daarom is de beste optie om PVRB en finaliteit in één protocol te combineren - dan is het voltooide blok = afgerond willekeurig, en dit is precies wat we nodig hadden. Nu ontvangen spelers binnen N seconden een gegarandeerde willekeurige waarde en kunnen ze er zeker van zijn dat het onmogelijk is om deze terug te draaien of opnieuw te spelen.

De op consensus gebaseerde optie is goed:

• de mogelijkheid van asynchrone implementatie met betrekking tot de productie van blokken - blokken worden zoals gewoonlijk geproduceerd, maar parallel hieraan kan het PVRB-protocol werken, wat niet voor elk blok willekeur oplevert
• de mogelijkheid om zelfs zware cryptografie te implementeren, zonder de beperkingen die aan slimme contracten worden opgelegd
• de mogelijkheid om de uitwisseling van berichten sneller te organiseren dan transacties in de blockchain zijn opgenomen. Een deel van het protocol kan bijvoorbeeld tussen knooppunten werken zonder berichten over het netwerk te verspreiden

Het heeft ook nadelen:

• Moeilijkheden bij het testen en ontwikkelen - u zult netwerkfouten, ontbrekende knooppunten en harde netwerkvorken moeten emuleren
• Implementatiefouten vereisen een netwerkhardfork

Beide methoden om PVRB te implementeren hebben recht op leven, maar de implementatie van slimme contracten in moderne blockchains is nog steeds vrij beperkt in computerbronnen, en elke overgang naar serieuze cryptografie is vaak simpelweg onmogelijk. En we zullen serieuze cryptografie nodig hebben, zoals hieronder zal worden aangetoond. Hoewel dit probleem duidelijk tijdelijk is, is serieuze cryptografie in contracten nodig om veel problemen op te lossen, en dit probleem verschijnt geleidelijk (bijvoorbeeld systeemcontracten voor zkSNARK's in Ethereum)

Blockchain, dat een transparant en betrouwbaar protocol-berichtenkanaal biedt, doet dit niet gratis. Elk gedecentraliseerd protocol moet rekening houden met de mogelijkheid van een Sybil-aanval; elke actie kan worden uitgevoerd door de gezamenlijke krachten van meerdere accounts. Daarom is het bij het ontwerpen noodzakelijk om rekening te houden met het vermogen van aanvallers om een ​​willekeurig aantal protocollen te creëren. deelnemers die in samenspanning handelen.

PVRB- en blokvariabelen.

Ik heb niet gelogen toen ik zei dat nog niemand een goede PVRB, getest door veel gokapplicaties, in blockchains heeft geïmplementeerd. Waar komen dan zoveel gokapplicaties vandaan op Ethereum en EOS? Dit verbaast mij net zoveel als jou: waar haalden ze zoveel ‘aanhoudende’ willekeurige getallen vandaan in een volledig deterministische omgeving?

De favoriete manier om willekeur in de blockchain te krijgen, is door ‘onvoorspelbare’ informatie uit het blok te halen en er een willekeurige informatie van te maken, simpelweg door een of meer waarden te hashen. Goed artikel over de problemen van dergelijke regelingen hier. U kunt elk van de ‘onvoorspelbare’ waarden in het blok nemen, bijvoorbeeld de blok-hash, het aantal transacties, de netwerkcomplexiteit en andere vooraf onbekende waarden. Hash ze dan, een of meer, en in theorie zou je een echte willekeurige moeten krijgen. Je kunt zelfs aan het whitepaper toevoegen dat je schema “post-kwantumveilig” is (aangezien er kwantumbestendige hash-functies zijn :)).

Maar zelfs post-kwantumveilige hashes zijn helaas niet genoeg. Het geheim schuilt in de vereisten voor PVRB, ik wil u eraan herinneren uit het vorige artikel:

1. Het resultaat moet een aantoonbaar uniforme verdeling hebben, dat wil zeggen gebaseerd zijn op aantoonbaar sterke cryptografie.
2. Het is niet mogelijk om de bits van het resultaat te controleren. Het gevolg hiervan is dat de uitkomst niet op voorhand kan worden voorspeld.
3. Je kunt het generatieprotocol niet saboteren door niet mee te doen aan het protocol of door het netwerk te overbelasten met aanvalsberichten
4. Al het bovenstaande moet bestand zijn tegen samenzwering van een toegestaan ​​aantal oneerlijke protocoldeelnemers (bijvoorbeeld 1/3 van de deelnemers).

In dit geval wordt alleen voldaan aan vereiste 1 en niet aan vereiste 2. Door onvoorspelbare waarden uit het blok te hashen, krijgen we een uniforme verdeling en goede randoms. Maar BP heeft in ieder geval de mogelijkheid om ‘het blok te publiceren of niet’. BP kan dus op zijn minst kiezen uit TWEE willekeurige opties: ‘zijn eigen’ en degene die zal blijken als iemand anders de blokkering maakt. BP kan van tevoren ‘snuffelen’ wat er zal gebeuren als hij een blok publiceert, en besluit eenvoudigweg om het wel of niet te doen. Wanneer hij bijvoorbeeld “even-oneven” of “rood/zwart” speelt bij roulette, kan hij dus alleen een blok publiceren als hij een overwinning ziet. Dit maakt ook de strategie om bijvoorbeeld een block-hash ‘uit de toekomst’ te gebruiken onwerkbaar. In dit geval zeggen ze dat er “willekeurig” zal worden gebruikt, wat wordt verkregen door het hashen van de huidige gegevens en de hash van een toekomstig blok met een hoogte van bijvoorbeeld N + 42, waarbij N de huidige blokhoogte is. Dit versterkt de regeling een beetje, maar geeft BP nog steeds de mogelijkheid, zij het in de toekomst, om te kiezen of ze het blok vasthoudt of publiceert.

BP-software wordt in dit geval ingewikkelder, maar niet veel. Bij het valideren en opnemen van een transactie in een blok vindt er eenvoudigweg een snelle controle plaats om te zien of er sprake zal zijn van een overwinning, en eventueel een selectie van één transactieparameter om een ​​hoge kans op winst te verkrijgen. Tegelijkertijd is het bijna onmogelijk om een ​​slimme borderliner op dergelijke manipulaties te betrappen; elke keer kun je nieuwe adressen gebruiken en beetje bij beetje winnen zonder argwaan te wekken.

Methoden die informatie uit het blok gebruiken, zijn dus niet geschikt als universele implementatie van PVRB. In een beperkte versie, met beperkingen op de inzetgrootte, beperkingen op het aantal spelers en/of KYC-registratie (om te voorkomen dat één speler meerdere adressen gebruikt), kunnen deze schema's werken voor kleine spellen, maar meer niet.

PVRB en commit-reveal.

Oké, dankzij hashing en in ieder geval de relatieve onvoorspelbaarheid van de blok-hash en andere variabelen. Als je het probleem van de vooroplopende mijnwerkers oplost, zou je iets geschikters moeten krijgen. Laten we gebruikers aan dit schema toevoegen - laat ze ook de willekeur beïnvloeden: elke medewerker van de technische ondersteuning zal je vertellen dat het meest willekeurige in IT-systemen de acties van gebruikers zijn :)

Een naïef schema, waarbij gebruikers eenvoudigweg willekeurige getallen sturen en het resultaat wordt berekend als bijvoorbeeld een hash van hun som, is niet geschikt. In dit geval kan de laatste speler, door zijn eigen willekeurige keuze te kiezen, bepalen wat het resultaat zal zijn. Dit is de reden waarom het veelgebruikte commit-reveal-patroon wordt gebruikt. Deelnemers sturen eerst hashes van hun randoms (commits) en openen vervolgens zelf de randoms (reveals). De ‘onthullingsfase’ begint pas nadat de benodigde commits zijn verzameld, zodat deelnemers precies de willekeurige hash kunnen verzenden van waaruit ze eerder hebben verzonden. Laten we dit nu allemaal samenvoegen met de parameters van een blok, en beter dan een blok uit de toekomst (willekeur kan alleen in een van de toekomstige blokken worden gevonden), en voila - de willekeur is klaar! Nu heeft elke speler invloed op de daaruit voortvloeiende willekeur, en kan hij de kwaadwillige borderliner ‘verslaan’ door deze te overschrijven met zijn eigen, van tevoren onbekende, willekeur... Je kunt ook bescherming toevoegen tegen het saboteren van het protocol door het niet te openen tijdens de onthullingsfase – eenvoudigweg door te eisen dat er bij het plegen van de transactie een bepaald bedrag aan de transactie wordt gekoppeld: een borgsom, die alleen tijdens de onthullingsprocedure wordt terugbetaald. In dit geval zal het plegen en niet onthullen niet rendabel zijn.

Het was een goede poging, en dergelijke schema's bestaan ​​ook in gaming-DApps, maar helaas is dit wederom niet genoeg. Nu kan niet alleen de mijnwerker, maar ook elke deelnemer aan het protocol het resultaat beïnvloeden. Het is nog steeds mogelijk om de waarde zelf te controleren, met minder variabiliteit en tegen een kostprijs, maar, zoals in het geval van de mijnwerker, als de resultaten van de trekking waardevoller zijn dan de vergoeding voor deelname aan het PVRB-protocol, dan zal de willekeurige -producer(RP) kan beslissen of hij wil onthullen en kan nog steeds kiezen uit ten minste twee willekeurige opties.
Maar het werd mogelijk om degenen te straffen die plegen en niet onthullen, en dit plan zal van pas komen. De eenvoud ervan is een serieus voordeel: serieuzere protocollen vereisen veel krachtigere berekeningen.

PVRB en deterministische handtekeningen.

Er is een andere manier om de RP te dwingen een pseudo-willekeurig getal op te geven waar hij geen invloed op kan uitoefenen als hij wordt voorzien van een “preimage” – dit is een deterministische handtekening. Een dergelijke handtekening is bijvoorbeeld RSA en niet ECS. Als RP een paar sleutels heeft: RSA en ECC, en hij ondertekent een bepaalde waarde met zijn privésleutel, dan krijgt hij in het geval van RSA SLECHTS ÉÉN handtekening, en in het geval van ECS kan hij een willekeurig aantal sleutels genereren. verschillende geldige handtekeningen. Dit komt omdat bij het aanmaken van een ECS-handtekening een willekeurig getal wordt gebruikt, gekozen door de ondertekenaar, en dit kan op elke manier worden gekozen, waardoor de ondertekenaar de mogelijkheid krijgt om uit meerdere handtekeningen te kiezen. In het geval van RSA: “één invoerwaarde” + “één sleutelpaar” = “één handtekening”. Het is onmogelijk om te voorspellen welke handtekening een andere RP zal krijgen, dus een PVRB met deterministische handtekeningen kan worden georganiseerd door de RSA-handtekeningen te combineren van verschillende deelnemers die dezelfde waarde hebben ondertekend. Bijvoorbeeld de vorige willekeurige. Deze regeling bespaart veel middelen, omdat handtekeningen zijn zowel een bevestiging van het juiste gedrag volgens het protocol als een bron van willekeur.

Maar zelfs met deterministische handtekeningen is het plan nog steeds kwetsbaar voor het ‘laatste actor’-probleem. De laatste deelnemer kan nog steeds beslissen of hij de handtekening al dan niet publiceert, waardoor hij de uitkomst bepaalt. Je kunt het schema aanpassen, er blok-hashes aan toevoegen, rondes maken zodat het resultaat niet van tevoren kan worden voorspeld, maar al deze technieken laten, zelfs rekening houdend met vele wijzigingen, nog steeds het probleem van de invloed van één deelnemer op het collectief onopgelost. resulteren in een niet-vertrouwde omgeving en kunnen alleen werken onder economische en tijdsbeperkingen. Bovendien is de grootte van RSA-sleutels (1024 en 2048 bits) behoorlijk groot, en is de grootte voor blockchain-transacties een uiterst belangrijke parameter. Blijkbaar is er geen eenvoudige manier om het probleem op te lossen, laten we verder gaan.

PVRB en geheime deelprogramma's

In de cryptografie zijn er schema's waarmee het netwerk overeenstemming kan bereiken over één en slechts één PVRB-waarde, terwijl dergelijke schema's bestand zijn tegen kwaadwillige acties van sommige deelnemers. Een nuttig protocol dat de moeite waard is om vertrouwd mee te raken is het geheime deelprogramma van Shamir. Het dient om een ​​geheim (bijvoorbeeld een geheime sleutel) in verschillende delen te verdelen en deze delen onder N deelnemers te distribueren. Het geheim wordt op zo'n manier verspreid dat M delen van N voldoende zijn om het te herstellen, en dit kunnen alle M delen zijn. Als ze op de vingers een grafiek met een onbekende functie hebben, wisselen de deelnemers punten uit op de grafiek, en na het ontvangen van M-punten kan de hele functie worden hersteld.
Er staat een goede uitleg in wiki maar praktisch ermee spelen om het protocol in je hoofd af te spelen is handig demonstratie bladzijde.

Als het FSSS-systeem (Fiat-Shamir Secret Sharing) in zijn pure vorm van toepassing zou zijn, zou het een onverwoestbare PVRB zijn. In de eenvoudigste vorm zou het protocol er als volgt uit kunnen zien:

• Elke deelnemer genereert zijn eigen willekeurige waarde en verdeelt daaruit aandelen onder andere deelnemers
• Elke deelnemer onthult zijn deel van de geheimen van de andere deelnemers
• Als een deelnemer meer dan M-aandelen heeft, kan het nummer van deze deelnemer worden berekend en zal dit uniek zijn, ongeacht de set onthulde deelnemers
• De combinatie van onthulde willekeurige getallen is de gewenste PVRB

Hier heeft een individuele deelnemer niet langer invloed op de resultaten van het protocol, behalve in gevallen waarin het behalen van de drempel voor openbaarmaking van willekeur uitsluitend van hem afhangt. Daarom werkt dit protocol, als er een vereist aantal RP's aan het protocol werkt en beschikbaar is, door de vereisten voor cryptografische kracht te implementeren en resistent te zijn tegen het probleem van de "laatste actor".

Dit zou een ideale optie kunnen zijn; dit PVRB-schema, gebaseerd op het geheim delen van Fiat-Shamir, wordt bijvoorbeeld beschreven in dit artikel. Maar zoals hierboven vermeld, als je het frontaal probeert toe te passen in de blockchain, verschijnen er technische beperkingen. Hier is een voorbeeld van een testimplementatie van het protocol in het EOS slimme contract en het belangrijkste onderdeel ervan: het controleren van de gepubliceerde deeldeelnemer: code. Je kunt aan de code zien dat voor bewijsvalidatie verschillende scalaire vermenigvuldigingen nodig zijn, en dat de gebruikte getallen erg groot zijn. Het moet duidelijk zijn dat bij blockchains de verificatie plaatsvindt op het moment dat de blokproducent de transactie verwerkt, en dat in het algemeen elke deelnemer gemakkelijk de juistheid van het protocol moet verifiëren, dus de vereisten voor de snelheid van de verificatiefunctie zijn zeer ernstig. . Bij deze optie bleek de optie niet effectief, aangezien de verificatie niet binnen de transactielimiet (0.5 seconde) paste.

Verificatie-efficiëntie is een van de belangrijkste vereisten voor het gebruik van, in het algemeen, geavanceerde cryptografische schema’s in de blockchain. Het maken van proefdrukken, het voorbereiden van berichten - deze procedures kunnen off-chain worden gehaald en worden uitgevoerd op krachtige computers, maar verificatie kan niet worden omzeild - dit is een andere belangrijke vereiste voor PVRB.

PVRB- en drempelhandtekeningen

Nadat we kennis hadden gemaakt met het geheime deelschema, ontdekten we een hele klasse protocollen, verenigd door het trefwoord ‘drempel’. Wanneer de openbaarmaking van bepaalde informatie de deelname vereist van M eerlijke deelnemers uit N, en de verzameling eerlijke deelnemers een willekeurige subset van N kan zijn, spreken we van ‘drempelregelingen’. Zij zijn het die ons in staat stellen het probleem van de ‘laatste actor’ aan te pakken. Als de aanvaller zijn deel van het geheim niet onthult, zal een andere, eerlijke deelnemer het voor hem doen. Deze schema's maken het mogelijk overeenstemming te bereiken over slechts één betekenis, zelfs als het protocol door sommige deelnemers wordt gesaboteerd.

De combinatie van deterministische handtekeningen en drempelschema's maakte het mogelijk om een ​​zeer handig en veelbelovend schema te ontwikkelen voor het implementeren van PVRB - dit zijn deterministische drempelsignaturen. Hier artikel over de verschillende toepassingen van drempelsignaturen, en hier is nog een goede longread van Dash.

Het laatste artikel beschrijft BLS-handtekeningen (BLS staat voor Boneh-Lynn-Shacham, hier artikel), die een zeer belangrijke en uiterst handige kwaliteit hebben voor programmeurs - openbare, geheime, publieke sleutels en BLS-handtekeningen kunnen met elkaar worden gecombineerd met behulp van eenvoudige wiskundige bewerkingen, terwijl hun combinaties geldige sleutels en handtekeningen blijven, waardoor u er gemakkelijk veel kunt samenvoegen handtekeningen in één en vele publieke sleutels in één. Ze zijn ook deterministisch en leveren hetzelfde resultaat op voor dezelfde invoergegevens. Dankzij deze kwaliteit zijn combinaties van BLS-handtekeningen zelf geldige sleutels, wat de implementatie mogelijk maakt van een optie waarbij M van N-deelnemers één en slechts één handtekening produceren die deterministisch, publiekelijk verifieerbaar en onvoorspelbaar is totdat deze wordt geopend door de Mth. deelnemer.

In een schema met drempel-BLS-handtekeningen ondertekent elke deelnemer iets met behulp van BLS (bijvoorbeeld de vorige willekeurige) en de gemeenschappelijke drempelhandtekening is de gewenste willekeurige. De cryptografische eigenschappen van BLS-handtekeningen voldoen aan de eisen voor willekeurige kwaliteit, het drempelgedeelte beschermt tegen ‘laatste actor’ en de unieke combineerbaarheid van sleutels maakt het mogelijk om nog veel meer interessante algoritmen te implementeren die bijvoorbeeld een efficiënte aggregatie van protocolberichten mogelijk maken. .

Dus als u PVRB op uw blockchain bouwt, zult u hoogstwaarschijnlijk eindigen met het BLS-drempelhandtekeningenschema; verschillende projecten maken er al gebruik van. Bijvoorbeeld DFinity (hier benchmark die het circuit implementeert, en hier voorbeeldimplementatie van verifieerbaar geheim delen) of Keep.network (hier is hun willekeurige baken geel papier, Maar voorbeeld slim contract dat het protocol bedient).

Implementatie van PVRB

Helaas zien we nog steeds geen kant-en-klaar protocol geïmplementeerd in PVRB-blockchains dat zijn veiligheid en stabiliteit heeft bewezen. Hoewel de protocollen zelf klaar zijn, is het technisch toepassen ervan op bestaande oplossingen niet eenvoudig. Voor gecentraliseerde systemen heeft PVRB geen zin, en gedecentraliseerde systemen zijn strikt beperkt in alle computerbronnen: CPU, geheugen, opslag, I/O. Het ontwerpen van een PVRB is een combinatie van verschillende protocollen om iets te creëren dat voldoet aan alle vereisten voor tenminste een levensvatbare blockchain. Het ene protocol rekent efficiënter, maar vereist meer berichten tussen RP's, terwijl het andere heel weinig berichten nodig heeft, maar het maken van een proefdruk kan een taak zijn die tientallen minuten of zelfs uren in beslag neemt.

Ik zal de factoren opsommen waarmee u rekening moet houden bij het kiezen van een hoogwaardige PVRB:

• Cryptografische kracht. Uw PVRB moet strikt onbevooroordeeld zijn, zonder de mogelijkheid om ook maar één bit te controleren. Bij sommige schema's is dit niet het geval, dus bel een cryptograaf
• Het ‘laatste acteur’-probleem. Je PVRB moet bestand zijn tegen aanvallen waarbij een aanvaller die een of meer RP's bestuurt, een van de twee uitkomsten kan kiezen.
• Probleem met protocolsabotage. Je PVRB moet bestand zijn tegen aanvallen waarbij een aanvaller die een of meer RP's controleert, besluit of dit willekeurig is of niet en kan worden gegarandeerd of met een bepaalde waarschijnlijkheid om dit te beïnvloeden
• Probleem met aantal berichten. Uw RP’s moeten een minimum aan berichten naar de blockchain sturen en synchrone acties zoveel mogelijk vermijden, zoals situaties als “Ik heb wat informatie gestuurd, ik wacht op een reactie van een specifieke deelnemer.” In p2p-netwerken, vooral geografisch verspreide, moet u niet rekenen op een snelle reactie
• Het probleem van computationele complexiteit. Verificatie van elke fase van de PVRB-on-chain zou uiterst eenvoudig moeten zijn, omdat deze wordt uitgevoerd door alle volledige clients van het netwerk. Als de implementatie via een smart contract gebeurt, zijn de snelheidseisen zeer streng
• Het probleem van bereikbaarheid en levendigheid. Uw PVRB moet ernaar streven veerkrachtig te zijn in situaties waarin een deel van het netwerk gedurende een bepaalde periode niet beschikbaar is en een deel van de RP eenvoudigweg niet meer werkt
• Het probleem van een vertrouwde installatie en initiële sleuteldistributie. Als uw PVRB de primaire opstelling van het protocol gebruikt, dan is dit een apart groot en serieus verhaal. Hier voorbeeld. Als deelnemers elkaar hun sleutels moeten doorgeven voordat het protocol start, is dit ook een probleem als de samenstelling van deelnemers verandert
• Ontwikkelingsproblemen. Beschikbaarheid van bibliotheken in de vereiste talen, hun beveiliging en prestaties, publiciteit, complexe tests, enz.

Drempel-BLS-handtekeningen hebben bijvoorbeeld een aanzienlijk probleem: voordat ze beginnen te werken, moeten deelnemers sleutels aan elkaar uitdelen, waarbij ze een groep organiseren waarbinnen de drempel zal werken. Dit betekent dat er minstens één uitwisselingsronde in een gedecentraliseerd netwerk zal moeten wachten, en aangezien de gegenereerde rand bijvoorbeeld nodig is in games, bijna in realtime, betekent dit dat sabotage van het protocol in dit stadium mogelijk is. en de voordelen van de drempelregeling gaan verloren. Dit probleem is al eenvoudiger dan de vorige, maar vereist nog steeds de ontwikkeling van een aparte procedure voor de vorming van drempelgroepen, die economisch beschermd zullen moeten worden, door middel van stortingen en opnames van geld (slashing) van deelnemers die de regels niet volgen. protocol. Bovendien past BLS-verificatie met een acceptabel beveiligingsniveau eenvoudigweg niet in een standaard EOS- of Ethereum-transactie - er is simpelweg niet genoeg tijd voor verificatie. De contractcode is WebAssembly of EVM, uitgevoerd door een virtuele machine. Cryptografische functies zijn (nog) niet native geïmplementeerd en werken tientallen keren langzamer dan conventionele cryptografische bibliotheken. Veel protocollen voldoen niet aan de eisen die simpelweg op sleutelvolume zijn gebaseerd, bijvoorbeeld 1024 en 2048 bits voor RSA, 4-8 keer groter dan de standaard transactiehandtekening in Bitcoin en Ethereum.

Ook de aanwezigheid van implementaties in verschillende programmeertalen speelt een rol – en dat zijn er weinig, vooral bij nieuwe protocollen. De optie met integratie in consensus vereist het schrijven van een protocol in de platformtaal, dus je zult naar code moeten zoeken in Go voor geth, in Rust voor Parity, in C++ voor EOS. Iedereen zal op zoek moeten naar JavaScript-code, en aangezien JavaScript en cryptografie niet bepaald goede vrienden zijn, zal WebAssembly daarbij helpen, dat nu definitief beweert de volgende belangrijke internetstandaard te zijn.

Conclusie

Ik hoop op de vorige статье Ik heb je ervan kunnen overtuigen dat het genereren van willekeurige getallen op de blockchain van cruciaal belang is voor veel aspecten van het leven van gedecentraliseerde netwerken, en met dit artikel heb ik laten zien dat deze taak buitengewoon ambitieus en moeilijk is, maar dat er al goede oplossingen bestaan. Over het algemeen is het definitieve ontwerp van het protocol alleen mogelijk na het uitvoeren van omvangrijke tests waarbij alle aspecten in aanmerking worden genomen, van installatie tot foutemulatie. Het is dus onwaarschijnlijk dat u kant-en-klare recepten zult vinden in whitepapers en artikelen van het team, en dat zullen wij zeker niet doen. Beslis in de komende twee jaar en schrijf: ‘Doe het op deze manier, precies goed.’

Dag, voor onze PVRB in de blockchain die wordt ontwikkeld HayaAls we besloten hebben om drempel-BLS-handtekeningen te gebruiken, zijn we van plan PVRB op consensusniveau te implementeren, aangezien verificatie in slimme contracten met een acceptabel beveiligingsniveau nog niet mogelijk is. Het is mogelijk dat we twee schema's tegelijk gebruiken: eerst het duur delen van geheimen om random_seed voor de lange termijn te creëren, en dan gebruiken we het als basis voor hoogfrequente willekeurige generatie met behulp van deterministische drempel-BLS-signaturen. Misschien beperken we ons tot alleen een van de schema's. Helaas is het onmogelijk om op voorhand te zeggen wat het protocol zal zijn; het enige goede is dat, net als in de wetenschap, bij technische problemen een negatief resultaat ook een resultaat is, en elke nieuwe poging om het probleem op te lossen een nieuwe stap is voor de toekomst. het onderzoek van iedereen die bij het probleem betrokken is. Om aan de zakelijke eisen te voldoen, lossen we een specifiek praktisch probleem op: gaming-applicaties voorzien van een betrouwbare bron van entropie, dus we moeten ook aandacht besteden aan de blockchain zelf, in het bijzonder de kwesties van ketenfinaliteit en netwerkbeheer.

En ook al zien we nog geen bewezen resistente PVRB in blockchains, die lang genoeg zou zijn gebruikt om te worden getest door echte applicaties, meerdere audits, ladingen en natuurlijk echte aanvallen, maar het aantal mogelijke paden bevestigt dat er bestaat een oplossing, en welke van deze algoritmen zullen het probleem uiteindelijk oplossen? We zullen de resultaten graag delen en andere teams die ook aan dit probleem werken bedanken voor artikelen en code waarmee ingenieurs niet twee keer op dezelfde hark hoeven te stappen.

Dus als je een programmeur tegenkomt die gedecentraliseerd willekeurig ontwerp ontwerpt, wees dan attent en zorgzaam en bied indien nodig psychologische hulp :)

Bron: www.habr.com