Is dit moontlik om ewekansige getalle te genereer as ons mekaar nie vertrou nie? Deel 1

Haai Habr!

In hierdie artikel sal ek praat oor die generering van pseudo-ewekansige getalle deur deelnemers wat mekaar nie vertrou nie. Soos ons hieronder sal sien, is die implementering van 'n "amper" goeie kragopwekker redelik eenvoudig, maar 'n baie goeie een is moeilik.

Waarom sou dit nodig wees om ewekansige getalle te genereer onder deelnemers wat mekaar nie vertrou nie? Een toepassingsgebied is gedesentraliseerde toepassings. Byvoorbeeld, 'n toepassing wat 'n weddenskap van 'n deelnemer aanvaar en óf die bedrag verdubbel met 'n 49% waarskynlikheid óf wegneem met 'n 51% waarskynlikheid, sal slegs werk as dit onbevooroordeeld 'n ewekansige nommer kan ontvang. As 'n aanvaller die uitkoms van die ewekansige getalgenerator kan beïnvloed, en selfs sy kans om 'n uitbetaling in die toepassing te ontvang effens verhoog, sal hy dit maklik verwoes.

Wanneer ons 'n verspreide ewekansige getalgenereringsprotokol ontwerp, wil ons hê dit moet drie eienskappe hê:

1. Hy moet onbevooroordeeld wees. Met ander woorde, geen deelnemer behoort op enige manier die resultaat van die ewekansige getalgenerator te beïnvloed nie.

2. Hy moet onvoorspelbaar wees. Met ander woorde, geen deelnemer behoort in staat te wees om te voorspel watter getal gegenereer sal word (of enige van sy eienskappe aflei) voordat dit gegenereer word nie.

3. Die protokol moet lewensvatbaar wees, dit wil sê, bestand teen die feit dat 'n sekere persentasie deelnemers van die netwerk ontkoppel of doelbewus probeer om die protokol te stop.

In hierdie artikel sal ons kyk na twee benaderings: RANDAO + VDF en die uitvee kodes benadering. In die volgende deel gaan ons die benadering wat gebaseer is op drempelhandtekeninge van nader bekyk.

Maar eers, kom ons kyk na 'n eenvoudige en algemeen gebruikte algoritme wat lewensvatbaar, onvoorspelbaar, maar bevooroordeeld is.

RANDAO

RANDAO is 'n baie eenvoudige en daarom redelik algemeen gebruikte benadering om willekeurigheid te genereer. Alle netwerkdeelnemers kies eers plaaslik 'n pseudo-willekeurige nommer, dan stuur elke deelnemer 'n hash van die gekose nommer. Vervolgens maak die deelnemers beurte om hul gekose nommers te openbaar en 'n XOR-bewerking op die geopenbaarde nommers uit te voer, en die resultaat van hierdie bewerking word die resultaat van die protokol.

Die stap om die hashes te publiseer voordat die nommers bekend gemaak word, is nodig sodat die aanvaller nie sy nommer kan kies nadat hy die nommers van die ander deelnemers gesien het nie. Dit sal hom in staat stel om feitlik eiehandig die uitset van die ewekansige getalgenerator te bepaal.

Gedurende die verloop van die protokol moet deelnemers twee keer tot 'n gemeenskaplike besluit (sogenaamde konsensus) kom: wanneer om die geselekteerde getalle te begin openbaar, en dus ophou om hashes te aanvaar, en wanneer om op te hou om die geselekteerde getalle te aanvaar en die gevolglike ewekansige berekening nommer. Om sulke besluite te neem tussen deelnemers wat mekaar nie vertrou nie, is nie 'n maklike taak op sigself nie, en ons sal in toekomstige artikels daarna terugkeer; in hierdie artikel sal ons aanvaar dat so 'n konsensusalgoritme vir ons beskikbaar is.

Watter van die eienskappe wat ons hierbo beskryf het, het RANDAO? Dit is onvoorspelbaar, het dieselfde lewenskragtigheid as die onderliggende konsensusprotokol, maar dit is bevooroordeeld. Spesifiek, 'n aanvaller kan die netwerk waarneem, en nadat ander deelnemers hul nommers bekend gemaak het, kan hy hul XOR bereken, en besluit of hy sy nommer moet openbaar of nie om die uitkoms te beïnvloed. Alhoewel dit die aanvaller verhoed om eiehandig die uitset van die ewekansige getalgenerator te bepaal, gee dit hom steeds 1 bietjie invloed. En as aanvallers verskeie deelnemers beheer, dan sal die aantal stukkies wat hulle beheer gelyk wees aan die aantal deelnemers onder hul beheer.

Die invloed van aanvallers kan aansienlik verminder word deur te vereis dat deelnemers die getalle in volgorde openbaar. Dan sal die aanvaller slegs die uitkoms kan beïnvloed as dit laaste oopgemaak word. Alhoewel die invloed aansienlik minder is, is die algoritme steeds bevooroordeeld.

RANDAO+VDF

Een manier om RANDAO onbevooroordeeld te maak, is die volgende: nadat al die getalle geopenbaar is en die XOR bereken is, word die resultaat daarvan ingevoer in die invoer van 'n funksie wat baie lank neem om te bereken, maar dit laat jou toe om die korrektheid van die berekening na te gaan baie vinnig.

(vdf_output, vdf_proof) = VDF_compute(input) // это очень медленно
correct = VDF_verify(input, vdf_output, vdf_proof) // это очень быстро

Hierdie funksie word Verifiable Delay Function, of VDF genoem. As die berekening van die finale uitslag langer neem as die nommeropenbaarmakingstadium, sal die aanvaller nie die effek van die wys of verberging van sy nommer kan voorspel nie, en daarom sal hy die geleentheid verloor om die resultaat te beïnvloed.

Dit is uiters moeilik om goeie VDF's te ontwikkel. Daar was onlangs verskeie deurbrake, bv. hierdie и hierdie, wat VDF in die praktyk meer prakties gemaak het, en Ethereum 2.0 beplan om op lang termyn RANDAO met VDF as 'n ewekansige getalbron te gebruik. Afgesien van die feit dat hierdie benadering onvoorspelbaar en onbevooroordeeld is, het dit die bykomende voordeel dat dit lewensvatbaar is as ten minste twee deelnemers op die netwerk beskikbaar is (met die veronderstelling dat die konsensusprotokol wat gebruik word, lewensvatbaar is wanneer daar met so 'n klein aantal deelnemers te make het).

Die grootste uitdaging van hierdie benadering is om die VDF so op te stel dat selfs 'n deelnemer met baie duur gespesialiseerde hardeware nie die VDF sal kan bereken voor die einde van die ontdekkingsfase nie. Ideaal gesproke moet die algoritme selfs 'n beduidende veiligheidsmarge hê, sê 10x. Die figuur hieronder toon 'n aanval deur 'n akteur wat 'n gespesialiseerde ASIC het wat hom toelaat om 'n VDF vinniger te laat loop as die tyd wat toegeken is om die RANDAO-bevestiging te openbaar. So 'n deelnemer kan steeds die finale resultaat bereken deur sy nommer te gebruik of nie, en dan, gebaseer op die berekening, kies of om dit te wys of nie.

Vir die VDF-familie hierbo genoem, kan die werkverrigting van 'n toegewyde ASIC 100+ keer hoër wees as konvensionele hardeware. So as die ontplooiingsfase 10 sekondes duur, dan moet die VDF wat op so 'n ASIC bereken word, meer as 100 sekondes neem om 'n 10x veiligheidsmarge te hê, en dus moet dieselfde VDF wat op kommoditeit hardeware bereken word 100x 100 sekondes = ~3 ure neem.

Die Ethereum Foundation beplan om hierdie probleem op te los deur sy eie publiek beskikbare, gratis ASIC's te skep. Sodra dit gebeur, kan alle ander protokolle ook voordeel trek uit hierdie tegnologie, maar tot dan sal die RANDAO+VDF-benadering nie so lewensvatbaar wees vir protokolle wat nie kan belê in die ontwikkeling van hul eie ASIC's nie.

Baie artikels, video's en ander inligting oor VDF is versamel op hierdie webwerf.

Ons gebruik uitveekodes

In hierdie afdeling, sal ons kyk na 'n ewekansige getal generering protokol wat gebruik kodes uitvee. Dit kan tot ⅓ aanvallers verdra terwyl dit lewensvatbaar bly, en laat tot ⅔ aanvallers toe om te bestaan ​​voordat hulle die uitkoms kan voorspel of beïnvloed.

Die hoofgedagte van die protokol is soos volg. Kom ons neem vir eenvoud aan dat daar presies 100 deelnemers is. Kom ons neem ook aan dat alle deelnemers plaaslik een of ander privaat sleutel het, en die publieke sleutels van alle deelnemers is aan alle deelnemers bekend:

1. Elke deelnemer plaaslik kom met 'n lang string, breek dit in 67 dele op, skep uitveekodes om 100 aandele te verkry sodat enige 67 genoeg is om die string te herwin, ken elk van die 100 aandele aan een van die deelnemers toe en enkripteer dit met dieselfde deelnemer se publieke sleutel. Alle geënkodeerde aandele word dan gepubliseer.

2. Deelnemers gebruik 'n soort konsensus om ooreenkoms te bereik oor gekodeerde stelle van spesifieke 67 deelnemers.

3. Sodra konsensus bereik is, neem elke deelnemer die geënkodeerde aandele in elk van die 67 stelle wat met hul publieke sleutel geïnkripteer is, dekripteer al sulke aandele en publiseer al sulke gedekripteerde aandele.

4. Sodra 67 deelnemers stap (3) voltooi het, kan alle ooreengekome stelle heeltemal gedekodeer en gerekonstrueer word as gevolg van die eienskappe van uitveekodes, en die finale getal kan verkry word as 'n XOR van die aanvanklike rye waarmee die deelnemers in (1) begin het. .

Daar kan getoon word dat hierdie protokol onbevooroordeeld en onvoorspelbaar is. Die gevolglike ewekansige getal word bepaal nadat konsensus bereik is, maar is aan niemand bekend totdat ⅔ van die deelnemers die dele wat met hul publieke sleutel geënkripteer is, dekodeer nie. Die ewekansige getal word dus bepaal voordat inligting wat voldoende is om dit te rekonstrueer, gepubliseer word.

Wat gebeur as in stap (1) een van die deelnemers geënkodeerde aandele aan die ander deelnemers gestuur het wat nie die korrekte uitveekode vir een of ander string is nie? Sonder bykomende veranderinge sal verskillende deelnemers óf glad nie die string kan herwin nie, óf hulle sal verskillende stringe herwin, wat daartoe sal lei dat verskillende deelnemers 'n ander ewekansige nommer sal ontvang. Om dit te voorkom, kan jy die volgende doen: elke deelnemer, benewens die geënkodeerde aandele, bereken ook Merkla boom alle sulke aandele, en stuur vir elke deelnemer beide die geënkodeerde deel self en die wortel van die merkle boom, en bewys van die insluiting van die aandeel in die merkle boom. In die konsensus in stap (2) stem die deelnemers dan nie net oor 'n stel stelle ooreen nie, maar oor 'n stel spesifieke wortels van sulke bome (indien een of ander deelnemer van die protokol afgewyk het, en verskillende merkle-boomwortels aan verskillende deelnemers gestuur het, en twee sulke wortels word tydens konsensus gewys, sy die ry is nie by die resultatestel ingesluit nie). As gevolg van die konsensus sal ons 67 geënkodeerde lyne en die ooreenstemmende wortels van die merkleboom hê sodat daar ten minste 67 deelnemers is (nie noodwendig dieselfde wat die ooreenstemmende lyne voorgestel het nie), wat vir elk van die 67 reëls het 'n boodskap met 'n deel van die uitveekode, en 'n bewys dat die voorkoms van hul aandeel in die ooreenstemmende boom vervaag het.

Wanneer die deelnemer in stap (4) 67 slae vir 'n sekere snaar ontsyfer en die oorspronklike snaar daaruit probeer rekonstrueer, is een van die opsies moontlik:

1. Die string word herstel, en as dit dan weer uitvee-geënkodeer word, en die Merkle-boom word vir die plaaslik berekende aandele bereken, val die wortel saam met die een waaroor konsensus bereik is.

2. Die ry word herstel, maar die plaaslik berekende wortel stem nie ooreen met die een waarteen konsensus bereik is nie.

3. Die ry is nie herstel nie.

Dit is maklik om te wys dat as opsie (1) vir ten minste een deelnemer hierbo gebeur het, dan het opsie (1) vir alle deelnemers gebeur, en omgekeerd, as opsie (2) of (3) vir ten minste een deelnemer gebeur het, dan vir alle deelnemers sal opsie (2) of (3) gebeur. Dus, vir elke ry in die stel, sal óf alle deelnemers dit suksesvol herwin, óf alle deelnemers sal nie daarin slaag om dit te herstel nie. Die gevolglike ewekansige getal is dan 'n XOR van slegs die rye wat deelnemers kon herwin.

Drempelhandtekeninge

Nog 'n benadering tot ewekansigheid is om te gebruik wat BLS-drempelhandtekeninge genoem word. 'n Willekeurige getalgenerator gebaseer op drempelhandtekeninge het presies dieselfde waarborge as die uitvee-kode-gebaseerde algoritme wat hierbo beskryf is, maar het 'n aansienlik laer asimptotiese aantal boodskappe wat oor die netwerk gestuur word vir elke gegenereerde nommer.

BLS-handtekeninge is 'n ontwerp waarmee verskeie deelnemers een gemeenskaplike handtekening vir 'n boodskap kan skep. Hierdie handtekeninge word dikwels gebruik om spasie en bandwydte te bespaar deur nie te vereis dat veelvuldige handtekeninge uitgestuur word nie. 

'N Algemene toepassing vir BLS-handtekeninge in blokkettingprotokolle, benewens die generering van ewekansige getalle, is blokondertekening in BFT-protokolle. Kom ons sê 100 deelnemers skep blokke, en 'n blok word as finaal beskou as 67 van hulle dit onderteken. Hulle kan almal hul dele van die BLS-handtekening indien en die een of ander konsensusalgoritme gebruik om oor 67 van hulle ooreen te stem en dit dan saam te voeg in een BLS-handtekening. Enige 67 (of meer) dele kan gebruik word om die finale handtekening te skep, wat sal afhang van watter 67 handtekeninge gekombineer is en daarom kan verskil, hoewel verskillende keuses deur die 67 deelnemers 'n ander handtekening sal skep, sal enige sodanige handtekening 'n geldige handtekening vir die blok. Die oorblywende deelnemers hoef dan net een handtekening per blok, in plaas van 67, oor die netwerk te ontvang en te verifieer, wat die las op die netwerk aansienlik verminder.

Dit blyk dat as die private sleutels wat deelnemers gebruik op 'n sekere manier gegenereer word, maak nie saak watter 67 handtekeninge (of meer, maar nie minder nie) saamgevoeg word nie, die gevolglike handtekening dieselfde sal wees. Dit kan as 'n bron van ewekansigheid gebruik word: deelnemers stem eers oor een of ander boodskap wat hulle sal onderteken (dit kan die uitvoer van RANDAO wees of net die hash van die laaste blok, dit maak nie regtig saak nie solank dit elke keer verander en is konsekwent) en skep 'n BLS-handtekening daarvoor. Die resultaat van die generasie sal onvoorspelbaar wees totdat 67 deelnemers hul dele verskaf, en daarna is die uitset reeds vooraf bepaal en kan nie afhang van die optrede van enige deelnemer nie.

Hierdie benadering tot ewekansigheid is lewensvatbaar solank minstens ⅔ van die deelnemers aanlyn beide die protokol volg, en is onbevooroordeeld en onvoorspelbaar solank as wat minstens ⅓ van die deelnemers die protokol volg. Dit is belangrik om daarop te let dat 'n aanvaller wat meer as ⅓ maar minder as ⅔ van die deelnemers beheer die protokol kan stop, maar nie die uitset daarvan kan voorspel of beïnvloed nie.

Drempelhandtekeninge self is 'n baie interessante onderwerp. In die tweede deel van die artikel sal ons in detail ontleed hoe hulle werk, en presies hoe dit nodig is om deelnemersleutels te genereer sodat drempelhandtekeninge as 'n ewekansige getalgenerator gebruik kan word.

Ten slotte

Hierdie artikel is die eerste in 'n reeks tegniese blogartikels NEAR. NEAR is 'n blokkettingprotokol en platform vir die ontwikkeling van gedesentraliseerde toepassings met die klem op gemak van ontwikkeling en gemak van gebruik vir eindgebruikers.

Die protokolkode is oop, ons implementering is in Rust geskryf, dit kan gevind word hier.

Jy kan sien hoe ontwikkeling onder NEAR lyk, en jy kan eksperimenteer in die aanlyn IDE hier.

Jy kan al die nuus in Russies volg in groep in telegram en groep op VKontakte, en in Engels in die amptelike Twitter.

О скорых встреч!

Bron: will.com