Inleiding

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

Soos met die konsep van 'n absoluut sterk syfer uit kriptografie, probeer werklike "Publicly Verifiable Random Beacon" (hierna PVRB) protokolle net so na as moontlik aan die ideale skema kom, want in regte netwerke is dit nie in sy suiwer vorm van toepassing nie: dit is nodig om streng oor een bietjie saam te stem, daar moet baie rondtes wees, en alle boodskappe moet perfek vinnig wees en altyd afgelewer word. Dit is natuurlik nie die geval in regte netwerke nie. Daarom, by die ontwerp van PVRB's vir spesifieke take in moderne blokkettings, bykomend tot die onmoontlikheid om die gevolglike ewekansigheid en kriptografiese sterkte te beheer, ontstaan ​​baie meer suiwer argitektoniese en tegniese probleme.

Vir PVRB is die blokketting self in wese 'n kommunikasiemedium waarin boodskappe = transaksies. Dit laat jou toe om gedeeltelik te abstraheer van netwerkprobleme, nie-aflewering van boodskappe, probleme met middelware - al hierdie risiko's word deur die gedesentraliseerde netwerk aanvaar, en die belangrikste waarde daarvan vir PVRB is die onvermoë om 'n reeds gestuurde transaksie te herroep of te korrupteer - dit doen deelnemers nie toelaat om te weier om aan die protokol deel te neem nie, tensy hulle 'n suksesvolle aanval op konsensus uitgevoer het. Hierdie vlak van sekuriteit is aanvaarbaar, so PVRB moet bestand wees teen samespanning deur deelnemers in presies dieselfde mate as die hoof blokkettingketting. Dit dui ook daarop dat die PVRB deel van die konsensus moet wees as die netwerk saamstem oor die hoofblokketting, selfs al stem dit ook saam oor die enigste regverdige gevolglike ewekansigheid. Of, PVRB is bloot 'n selfstandige protokol wat geïmplementeer word deur 'n slim kontrak wat asynchronies werk met betrekking tot die blokketting en blokke. Beide metodes het hul voordele en nadele, en die keuse tussen hulle is uiters nie-triviaal.

Twee maniere om PVRB te implementeer

Kom ons beskryf in meer besonderhede twee opsies vir die implementering van PVRB - die selfstandige weergawe, wat werk met 'n slim kontrak onafhanklik van die blokketting, en die konsensus-geïntegreerde weergawe, ingebou in die protokol, waarvolgens die netwerk ooreenkom oor die blokketting en die transaksies wat ingesluit moet word. In alle gevalle sal ek gewilde blockchain-enjins bedoel: Ethereum, EOS, en almal soortgelyk aan hulle in die manier waarop hulle slim kontrakte huisves en verwerk.

Selfstandige kontrak

In hierdie weergawe is PVRB 'n slim kontrak wat transaksies van ewekansige produsente (hierna na verwys as RP) aanvaar, dit verwerk, die resultate kombineer, en gevolglik by 'n sekere waarde uitkom wat enige gebruiker uit hierdie kontrak kan ontvang. Hierdie waarde mag nie direk in die kontrak gestoor word nie, maar word eerder slegs verteenwoordig deur data waaruit een en slegs een waarde van die gevolglike ewekansigheid deterministies verkry kan word. In hierdie skema is RP's gebruikers van die blokketting, en enigiemand kan toegelaat word om aan die generasieproses deel te neem.

Die opsie met 'n selfstandige kontrak is goed:

• oordraagbaarheid (kontrakte kan van blokketting na blokketting gesleep word)
• gemak van implementering en toetsing (kontrakte is maklik om te skryf en te toets)
• gerief in die implementering van ekonomiese skemas (dit is maklik om jou eie teken te maak, waarvan die logika die doeleindes van PVRB dien)
• moontlikheid om op reeds werkende blokkettings te begin

Dit het ook nadele:

• sterk beperkings op rekenaarhulpbronne, transaksievolume en berging (met ander woorde, cpu/mem/io)
• beperkings op bedrywighede binne die kontrak (nie alle instruksies is beskikbaar nie, dit is moeilik om eksterne biblioteke aan te sluit)
• onvermoë om boodskappe vinniger te organiseer as wat transaksies by die blokketting ingesluit is

Hierdie opsie is geskik vir die implementering van 'n PVRB wat op 'n bestaande netwerk uitgevoer moet word, nie komplekse kriptografie bevat nie en nie 'n groot aantal interaksies vereis nie.

Konsensus-geïntegreerde

In hierdie weergawe word PVRB in die blokkettingnoduskode geïmplementeer, ingebou of parallel loop met die uitruil van boodskappe tussen blokkettingnodusse. Die resultate van die protokol word direk in die vervaardigde blokke geskryf, en protokolboodskappe word oor die p2p-netwerk tussen nodusse gestuur. Aangesien die protokol getalle tot gevolg het wat in blokke geskryf moet word, moet die netwerk 'n konsensus daaroor bereik. Dit beteken dat PVRB-boodskappe, soos transaksies, deur nodusse bekragtig moet word en in blokke ingesluit moet word sodat enige netwerkdeelnemer voldoening aan die PVRB-protokol kan bevestig. Dit lei ons outomaties na die ooglopende oplossing – as die netwerk ooreenkom oor 'n konsensus oor 'n blok en transaksies daarin, dan behoort PVRB deel van die konsensus te wees, en nie 'n alleenstaande protokol nie. Andersins is dit moontlik dat 'n blok geldig is vanuit 'n konsensus-oogpunt, maar die PVRB-protokol word nie gevolg nie, en vanuit die PVRB-oogpunt kan die blok nie aanvaar word nie. As die "konsensus-geïntegreerde" opsie dus gekies word, word die PVRB 'n belangrike deel van die konsensus.

Wanneer PVRB-implementerings op die netwerkkonsensusvlak beskryf word, kan 'n mens geensins kwessies van finaliteit vermy nie. Finaliteit is 'n meganisme wat gebruik word in deterministiese konsensusse wat 'n blok (en die ketting wat daarheen lei) insluit wat finaal is en nooit weggegooi sal word nie, selfs al vind 'n parallelle vurk plaas. Byvoorbeeld, in Bitcoin is daar nie so 'n meganisme nie - as jy 'n ketting van groter kompleksiteit publiseer, sal dit enige minder komplekse een vervang, ongeag die lengte van die kettings. En in EOS, byvoorbeeld, is die laastes die sogenaamde Last Irreversible Blocks, wat gemiddeld elke 432 blokke verskyn (12*21 + 12*15, pre-vote + pre-commit). Hierdie proses wag in wese op 2/3 van blokprodusente (hierna verwys as BP) se handtekeninge. Wanneer vurke verskyn wat ouer as die laaste LIB is, word dit eenvoudig weggegooi. Hierdie meganisme maak dit moontlik om te waarborg dat die transaksie by die blokketting ingesluit is en nooit teruggerol sal word nie, maak nie saak watter hulpbronne die aanvaller het nie. Die laaste blokke is ook blokke wat deur 2/3 BP in Hyperledger, Tendermint en ander pBFT-gebaseerde konsensusse onderteken is. Dit maak ook sin om 'n protokol te maak om finaliteit te verseker, 'n byvoeging tot konsensus, aangesien dit asynchronies kan werk met die produksie en publikasie van blokke. Hier is 'n goeie een статья oor finaliteit in Ethereum.

Finaliteit is uiters belangrik vir gebruikers, wat daarsonder die slagoffers van 'n "double besteding"-aanval kan vind, waar BP blokke "hou", en dit publiseer nadat die netwerk 'n goeie transaksie "gesien" het. As daar geen finaliteit is nie, vervang die gepubliseerde vurk die blok met 'n "goeie" transaksie met 'n ander, vanaf 'n "slegte" vurk, waarin dieselfde fondse na die aanvaller se adres oorgeplaas word. In die geval van PVRB is die vereistes vir finaliteit selfs strenger, aangesien die bou van vurke vir PVRB die geleentheid beteken vir 'n aanvaller om verskeie ewekansige opsies voor te berei om die mees winsgewende een te publiseer, en die beperking van die tyd van 'n moontlike aanval is 'n goeie oplossing.

Daarom is die beste opsie om PVRB en finaliteit in een protokol te kombineer - dan is die gefinaliseerde blok = willekeurig gefinaliseer, en dit is presies wat ons moes kry. Nou sal spelers 'n gewaarborgde ewekansigheid in N sekondes ontvang, en kan seker wees dat dit onmoontlik is om dit terug te rol of dit weer te speel.

Die konsensus-geïntegreerde opsie is goed:

• die moontlikheid van asinchroniese implementering met betrekking tot die produksie van blokke - blokke word soos gewoonlik vervaardig, maar parallel hiermee kan die PVRB-protokol werk, wat nie ewekansigheid vir elke blok produseer nie
• die vermoë om selfs swaar kriptografie te implementeer, sonder die beperkings wat op slim kontrakte opgelê word
• die vermoë om die uitruil van boodskappe vinniger te organiseer as wat transaksies in die blokketting ingesluit is, byvoorbeeld, 'n deel van die protokol kan tussen nodusse werk sonder om boodskappe oor die netwerk te versprei

Dit het ook nadele:

• Probleme met toetsing en ontwikkeling - jy sal netwerkfoute, ontbrekende nodusse, netwerk harde vurke moet naboots
• Implementeringsfoute vereis 'n netwerk hardevurk

Albei metodes om PVRB te implementeer het 'n reg op lewe, maar implementering op slim kontrakte in moderne blokkettings is steeds redelik beperk in rekenaarhulpbronne, en enige oorgang na ernstige kriptografie is dikwels eenvoudig onmoontlik. En ons sal ernstige kriptografie nodig hê, soos hieronder gedemonstreer sal word. Alhoewel hierdie probleem duidelik tydelik is, is ernstige kriptografie in kontrakte nodig om baie probleme op te los, en dit verskyn geleidelik (byvoorbeeld stelselkontrakte vir zkSNARKs in Ethereum)

Blockchain, wat 'n deursigtige en betroubare protokolboodskapkanaal bied, doen dit nie gratis nie. Enige gedesentraliseerde protokol moet die moontlikheid van 'n Sybil-aanval in ag neem; enige aksie kan deur die gesamentlike magte van verskeie rekeninge gedoen word, daarom is dit nodig om die vermoë van aanvallers om 'n arbitrêre aantal protokol te skep, in ag te neem wanneer dit ontwerp word. deelnemers wat in samespanning optree.

PVRB en blok veranderlikes.

Ek het nie gelieg toe ek gesê het dat niemand nog 'n goeie PVRB, wat deur baie dobbeltoepassings getoets is, in blokkettings geïmplementeer het nie. Waar kom so baie dobbeltoepassings dan vandaan op Ethereum en EOS? Dit verbaas my soveel as wat dit jou verras, waar het hulle soveel "aanhoudende" randoms in 'n heeltemal deterministiese omgewing gekry?

Die gunsteling manier om ewekansigheid in die blokketting te kry, is om 'n soort "onvoorspelbare" inligting uit die blok te neem en 'n ewekansige een te maak op grond daarvan - bloot deur een of meer waardes te hash. Goeie artikel oor die probleme van sulke skemas hier. U kan enige van die "onvoorspelbare" waardes in die blok neem, byvoorbeeld die blokhash, die aantal transaksies, netwerkkompleksiteit en ander waardes wat vooraf onbekend is. Hash hulle dan, een of meer, en in teorie behoort jy 'n ware ewekansige te kry. Jy kan selfs by die wihitepaper voeg dat jou skema "post-kwantum veilig" is (aangesien daar kwantumbestande hash-funksies is :)).

Maar selfs post-kwantum veilige hashes is nie genoeg nie, helaas. Die geheim lê in die vereistes vir PVRB, laat ek jou daaraan herinner uit die vorige artikel:

1. Die resultaat moet 'n bewysbaar eenvormige verspreiding hê, dit wil sê gebaseer wees op bewysbaar sterk kriptografie.
2. Dit is nie moontlik om enige van die stukkies van die resultaat te beheer nie. Gevolglik kan die uitkoms nie vooraf voorspel word nie.
3. Jy kan nie die genereringsprotokol saboteer deur nie aan die protokol deel te neem of deur die netwerk met aanvalsboodskappe te oorlaai nie
4. Al die bogenoemde moet bestand wees teen samespanning van 'n toelaatbare aantal oneerlike protokoldeelnemers (byvoorbeeld 1/3 van die deelnemers).

In hierdie geval word net aan vereiste 1 voldoen, en vereiste 2 word nie nagekom nie. Deur onvoorspelbare waardes uit die blok te hash, sal ons 'n eenvormige verspreiding en goeie ewekansiges kry. Maar BP het ten minste die opsie om "die blok te publiseer of nie." BP kan dus ten minste uit TWEE ewekansige opsies kies: "sy eie" en die een wat sal uitdraai as iemand anders die blok maak. BP kan vooraf “snuffel” wat gaan gebeur as hy ’n blok publiseer, en eenvoudig besluit om dit te doen of nie. Dus, wanneer hy byvoorbeeld "ewe-onewe" of "rooi/swart" in roulette speel, kan hy slegs 'n blok publiseer as hy 'n wen sien. Dit maak ook die strategie om byvoorbeeld 'n blokhash "van die toekoms" te gebruik onwerkbaar. In hierdie geval sê hulle dat "willekeurig gebruik sal word, wat verkry word deur die huidige data en die hash van 'n toekomstige blok met 'n hoogte van, byvoorbeeld, N + 42, waar N die huidige blokhoogte is. Dit versterk die skema 'n bietjie, maar laat BP steeds, al is dit in die toekoms, kies of hy die blok wil hou of publiseer.

BP-sagteware word in hierdie geval meer ingewikkeld, maar nie veel nie. Eenvoudig, wanneer 'n transaksie in 'n blok bekragtig en ingesluit word, is daar 'n vinnige kontrole om te sien of daar 'n oorwinning sal wees, en moontlik die keuse van een transaksieparameters om 'n hoë waarskynlikheid om te wen te verkry. Terselfdertyd is dit amper onmoontlik om 'n slim BP vir sulke manipulasies te vang; elke keer kan jy nuwe adresse gebruik en bietjie vir bietjie wen sonder om agterdog te wek.

So metodes wat inligting uit die blok gebruik, is nie geskik as 'n universele implementering van PVRB nie. In 'n beperkte weergawe, met beperkings op weddenskapgroottes, beperkings op die aantal spelers en/of KYC-registrasie (om te verhoed dat een speler veelvuldige adresse gebruik), kan hierdie skemas vir klein speletjies werk, maar niks meer nie.

PVRB en pleeg-openbaar.

Goed, te danke aan hashing en ten minste die relatiewe onvoorspelbaarheid van die blokhash en ander veranderlikes. As jy die probleem van vooraanstaande mynwerkers oplos, behoort jy iets meer geskik te kry. Kom ons voeg gebruikers by hierdie skema - laat hulle ook die ewekansigheid beïnvloed: enige tegniese ondersteuningswerknemer sal jou vertel dat die mees toevallige ding in IT-stelsels die optrede van gebruikers is :)

'n Naïewe skema, wanneer gebruikers bloot ewekansige getalle stuur en die resultaat bereken word as byvoorbeeld 'n hash van hul som, is nie geskik nie. In hierdie geval kan die laaste speler, deur sy eie ewekansig te kies, beheer wat die resultaat sal wees. Dit is hoekom die baie algemeen gebruikte commit-reveal-patroon gebruik word. Deelnemers stuur eers hashes van hul randoms (commits), en maak dan self die randoms oop (onthul). Die "openbaar"-fase begin eers nadat die nodige commits ingesamel is, sodat deelnemers presies die ewekansige hash kan stuur waaruit hulle vroeër gestuur het. Kom ons sit dit nou alles saam met die parameters van 'n blok, en beter as een wat uit die toekoms geneem is (willekeurigheid kan slegs in een van die toekomstige blokke gevind word), en voila - die willekeurigheid is gereed! Nou beïnvloed enige speler die gevolglike ewekansigheid, en kan die kwaadwillige BP “verslaan” deur dit te ignoreer met sy eie, vooraf onbekende, ewekansigheid... Jy kan ook beskerming byvoeg teen sabotasie van die protokol deur dit nie by die onthullingstadium oop te maak nie - eenvoudig deur te vereis dat 'n sekere bedrag aan die transaksie gekoppel moet word wanneer dit gepleeg word — 'n sekuriteitsdeposito, wat slegs tydens die onthullingsprosedure terugbetaal sal word. In hierdie geval sal dit nie winsgewend wees om te verbind en nie te openbaar nie.

Dit was 'n goeie poging, en sulke skemas bestaan ​​ook in dobbel-DApps, maar helaas, dit is weer nie genoeg nie. Nou kan nie net die mynwerker nie, maar ook enige deelnemer aan die protokol die resultaat beïnvloed. Dit is steeds moontlik om die waarde self te beheer, met minder veranderlikheid en teen 'n koste, maar, soos in die geval van die mynwerker, as die resultate van die tekening meer waardevol is as die fooi vir deelname aan die PVRB-protokol, dan is die ewekansige -vervaardiger(RP) kan besluit of om te openbaar en kan steeds kies uit ten minste twee ewekansige opsies.
Maar dit het moontlik geword om diegene te straf wat pleeg en nie openbaar nie, en hierdie skema sal handig te pas kom. Die eenvoud daarvan is 'n ernstige voordeel - ernstiger protokolle vereis baie kragtiger berekeninge.

PVRB en deterministiese handtekeninge.

Daar is 'n ander manier om die RP te dwing om 'n pseudo-ewekansige getal te verskaf wat dit nie kan beïnvloed as dit van 'n "voorbeeld" voorsien word nie - dit is 'n deterministiese handtekening. So 'n handtekening is byvoorbeeld RSA, en is nie ECS nie. As RP 'n paar sleutels het: RSA en ECC, en hy teken 'n sekere waarde met sy private sleutel, dan sal hy in die geval van RSA EEN EN SLEGS EEN handtekening kry, en in die geval van ECS kan hy enige aantal verskillende geldige handtekeninge. Dit is omdat wanneer 'n ECS-handtekening geskep word, 'n ewekansige nommer gebruik word, gekies deur die ondertekenaar, en dit kan op enige manier gekies word, wat die ondertekenaar die geleentheid gee om een ​​van verskeie handtekeninge te kies. In die geval van RSA: “een invoerwaarde” + “een sleutelpaar” = “een handtekening”. Dit is onmoontlik om te voorspel watter handtekening 'n ander RP sal kry, so 'n PVRB met deterministiese handtekeninge kan georganiseer word deur die RSA-handtekeninge van verskeie deelnemers wat dieselfde waarde onderteken het, te kombineer. Byvoorbeeld, die vorige ewekansige. Hierdie skema spaar baie hulpbronne, want handtekeninge is beide bevestiging van die korrekte gedrag volgens die protokol en 'n bron van willekeurigheid.

Selfs met deterministiese handtekeninge is die skema egter steeds kwesbaar vir die "laaste akteur"-probleem. Die laaste deelnemer kan steeds besluit of hy die handtekening wil publiseer of nie, en sodoende die uitkoms beheer. U kan die skema verander, blokhase daarby voeg, rondtes maak sodat die resultaat nie vooraf voorspel kan word nie, maar al hierdie tegnieke, selfs met inagneming van baie wysigings, laat steeds die probleem van die invloed van een deelnemer op die kollektief onopgelos. lei tot 'n onbetroubare omgewing en kan slegs onder ekonomiese en tydsbeperkings werk. Daarbenewens is die grootte van RSA-sleutels (1024 en 2048 bisse) redelik groot, en die grootte vir blokkettingtransaksies is 'n uiters belangrike parameter. Daar is blykbaar geen eenvoudige manier om die probleem op te los nie, kom ons gaan aan.

PVRB en geheime deelskemas

In kriptografie is daar skemas wat die netwerk kan toelaat om oor een en slegs een PVRB-waarde saam te stem, terwyl sulke skemas bestand is teen enige kwaadwillige optrede van sommige deelnemers. Een nuttige protokol wat die moeite werd is om jouself mee vertroud te maak, is Shamir se geheime deelskema. Dit dien om 'n geheim (byvoorbeeld 'n geheime sleutel) in verskeie dele te verdeel, en hierdie dele aan N deelnemers te versprei. Die geheim word op so 'n manier versprei dat M dele uit N genoeg is om dit te herwin, en dit kan enige M dele wees. As op vingers, dan met 'n grafiek van 'n onbekende funksie, ruil die deelnemers punte op die grafiek, en nadat hulle M punte ontvang het, kan die hele funksie herstel word.
'n Goeie verduideliking word gegee wiki maar om prakties daarmee te speel om die protokol in jou kop te speel, is nuttig vir demo bladsy.

As die FSSS (Fiat-Shamir Secret Sharing)-skema in sy suiwer vorm van toepassing was, sou dit 'n onvernietigbare PVRB wees. In sy eenvoudigste vorm kan die protokol soos volg lyk:

• Elke deelnemer genereer hul eie ewekansige en versprei aandele daaruit na ander deelnemers
• Elke deelnemer openbaar sy deel van die geheime van die ander deelnemers
• As 'n deelnemer meer as M aandele het, kan die getal van hierdie deelnemer bereken word, en dit sal uniek wees, ongeag die stel geopenbaarde deelnemers
• Die kombinasie van geopenbaarde randoms is die gewenste PVRB

Hier beïnvloed 'n individuele deelnemer nie meer die resultate van die protokol nie, behalwe in gevalle waar die bereiking van die randomness-openbaarmakingsdrempel slegs van hom afhang. Daarom werk hierdie protokol, as daar 'n vereiste proporsie RP's is wat aan die protokol werk en beskikbaar is, en dit implementeer die vereistes vir kriptografiese sterkte en is bestand teen die "laaste akteur"-probleem.

Dit kan 'n ideale opsie wees, hierdie PVRB-skema gebaseer op Fiat-Shamir geheime deel word byvoorbeeld beskryf in hierdie artikel. Maar, soos hierbo genoem, as jy probeer om dit reguit in die blokketting toe te pas, verskyn tegniese beperkings. Hier is 'n voorbeeld van 'n toetsimplementering van die protokol in die EOS-slimkontrak en die belangrikste deel daarvan - kontrolering van die gepubliseerde aandeeldeelnemer: kode. U kan uit die kode sien dat bewysvalidering verskeie skalêre vermenigvuldiging vereis, en die getalle wat gebruik word, is baie groot. Dit moet verstaan ​​word dat in blokkettings, verifikasie plaasvind op die oomblik wanneer die blokprodusent die transaksie verwerk, en in die algemeen moet enige deelnemer maklik die korrektheid van die protokol verifieer, so die vereistes vir die spoed van die verifieerfunksie is baie ernstig . In hierdie opsie het die opsie geblyk ondoeltreffend te wees, aangesien die verifikasie nie binne die transaksielimiet (0.5 sekondes) gepas het nie.

Verifikasiedoeltreffendheid is een van die belangrikste vereistes vir die gebruik van, in die algemeen, enige gevorderde kriptografiese skemas in die blokketting. Die skep van bewyse, die voorbereiding van boodskappe - hierdie prosedures kan van die ketting af geneem word en op hoëprestasie-rekenaars uitgevoer word, maar verifikasie kan nie omseil word nie - dit is nog 'n belangrike vereiste vir PVRB.

PVRB en drempelhandtekeninge

Nadat ons met die geheime deelskema kennis gemaak het, het ons 'n hele klas protokolle ontdek wat verenig is deur die sleutelwoord "drempel". Wanneer die openbaarmaking van sommige inligting die deelname van M eerlike deelnemers uit N vereis, en die stel eerlike deelnemers 'n arbitrêre subset van N kan wees, praat ons van "drempel"-skemas. Dit is hulle wat ons toelaat om die “laaste akteur”-probleem te hanteer, as die aanvaller nou nie sy deel van die geheim openbaar nie, sal 'n ander, eerlike deelnemer dit vir hom doen. Hierdie skemas laat ooreenstemming oor een en slegs een betekenis toe, selfs al word die protokol deur sommige van die deelnemers gesaboteer.

Die kombinasie van deterministiese handtekeninge en drempelskemas het dit moontlik gemaak om 'n baie gerieflike en belowende skema vir die implementering van PVRB te ontwikkel - dit is deterministiese drempelhandtekeninge. Hier статья oor die verskillende gebruike van drempelhandtekeninge, en hier is nog 'n goeie een langlees van Dash.

Die laaste artikel beskryf BLS-handtekeninge (BLS staan ​​vir Boneh-Lynn-Shacham, hier artikel), wat 'n baie belangrike en uiters gerieflike kwaliteit vir programmeerders het - publieke, geheime, publieke sleutels en BLS-handtekeninge kan met mekaar gekombineer word deur eenvoudige wiskundige bewerkings te gebruik, terwyl hul kombinasies geldige sleutels en handtekeninge bly, sodat jy baie maklik kan saamvoeg. handtekeninge in een en baie publieke sleutels in een. Hulle is ook deterministies en lewer dieselfde resultaat vir dieselfde insetdata. Danksy hierdie kwaliteit is kombinasies van BLS-handtekeninge self geldige sleutels, wat die implementering van 'n opsie moontlik maak waarin M van N deelnemers een en slegs een handtekening produseer wat deterministies, publiek verifieerbaar en onvoorspelbaar is totdat dit deur die Mth oopgemaak word. deelnemer .

In 'n skema met drempel-BLS-handtekeninge teken elke deelnemer iets met BLS (byvoorbeeld die vorige ewekansige), en die gemeenskaplike drempelhandtekening is die verlangde ewekansige. Die kriptografiese eienskappe van BLS-handtekeninge voldoen aan die vereistes vir ewekansige kwaliteit, die drempelgedeelte beskerm teen "laaste-akteur", en die unieke kombineerbaarheid van sleutels maak dit moontlik om baie meer interessante algoritmes te implementeer wat byvoorbeeld doeltreffende samevoeging van protokolboodskappe moontlik maak .

Dus, as jy PVRB op jou blokketting bou, sal jy heel waarskynlik met die BLS-drempelhandtekeningskema eindig, verskeie projekte gebruik dit reeds. Byvoorbeeld, DFinity (hier maatstaf wat die stroombaan implementeer, en hier voorbeeld implementering van verifieerbare geheime deel), of Keep.network (hier is hul ewekansige baken geelpapier, en hier Byvoorbeeld slim kontrak wat die protokol bedien).

Implementering van PVRB

Ongelukkig sien ons steeds nie 'n klaargemaakte protokol wat in PVRB-blokkettings geïmplementeer is wat sy sekuriteit en stabiliteit bewys het nie. Alhoewel die protokolle self gereed is, is dit nie maklik om dit tegnies op bestaande oplossings toe te pas nie. Vir gesentraliseerde stelsels maak PVRB nie sin nie, en gedesentraliseerde stelsels is streng beperk in alle rekenaarhulpbronne: SVE, geheue, berging, I/O. Die ontwerp van 'n PVRB is 'n kombinasie van verskillende protokolle om iets te skep wat aan al die vereistes vir ten minste 'n lewensvatbare blokketting voldoen. Een protokol bereken meer doeltreffend, maar vereis meer boodskappe tussen RP'e, terwyl die ander baie min boodskappe vereis, maar die skep van 'n bewys kan 'n taak wees wat tien minute, of selfs ure neem.

Ek sal die faktore lys wat jy sal moet oorweeg wanneer jy 'n kwaliteit PVRB kies:

• Kriptografiese sterkte. Jou PVRB moet streng onbevooroordeeld wees, met geen vermoë om 'n enkele bietjie te beheer nie. In sommige skemas is dit nie die geval nie, so bel 'n kriptograaf
• Die "laaste akteur" probleem. Jou PVRB moet bestand wees teen aanvalle waar 'n aanvaller wat een of meer RP's beheer een van twee uitkomste kan kies.
• Protokol sabotasie probleem. Jou PVRB moet bestand wees teen aanvalle waar 'n aanvaller wat een of meer RP'e beheer, besluit of dit lukraak moet wees of nie en kan óf gewaarborg word óf met 'n gegewe waarskynlikheid om dit te beïnvloed
• Aantal boodskappe probleem. Jou RP's moet 'n minimum van boodskappe na die blokketting stuur en sinchroniese aksies so veel as moontlik vermy, soos situasies soos "Ek het inligting gestuur, ek wag vir 'n antwoord van 'n spesifieke deelnemer." In p2p-netwerke, veral geografies verspreide, moet jy nie op 'n vinnige reaksie staatmaak nie
• Die probleem van berekeningskompleksiteit. Verifikasie van enige stadium van die PVRB on-chain behoort uiters maklik te wees, aangesien dit deur alle volle kliënte van die netwerk uitgevoer word. As die implementering met 'n slim kontrak gedoen word, is die spoedvereistes baie streng
• Die probleem van toeganklikheid en lewendigheid. Jou PVRB moet daarna streef om veerkragtig te wees teen situasies waar 'n deel van die netwerk vir 'n tydperk onbeskikbaar raak en 'n deel van die RP eenvoudig ophou werk
• Die probleem van betroubare opstelling en aanvanklike sleutelverspreiding. As jou PVRB die primêre opstelling van die protokol gebruik, dan is dit 'n aparte groot en ernstige storie. Hier Byvoorbeeld. As deelnemers mekaar hul sleutels moet vertel voordat die protokol begin, is dit ook 'n probleem as die samestelling van deelnemers verander
• Ontwikkelingsprobleme. Beskikbaarheid van biblioteke in die vereiste tale, hul sekuriteit en werkverrigting, publisiteit, komplekse toetse, ens.

Byvoorbeeld, drempel-BLS-handtekeninge het 'n beduidende probleem - voordat hulle begin werk, moet deelnemers sleutels aan mekaar versprei en 'n groep organiseer waarbinne die drempel sal werk. Dit beteken dat ten minste een ruilronde in 'n gedesentraliseerde netwerk sal moet wag, en aangesien die gegenereerde rand byvoorbeeld nodig is in speletjies, amper intyds, beteken dit dat sabotasie van die protokol op hierdie stadium moontlik is , en die voordele van die drempelskema gaan verlore. Hierdie probleem is reeds eenvoudiger as die voriges, maar vereis steeds die ontwikkeling van 'n aparte prosedure vir die vorming van drempelgroepe, wat ekonomies beskerm sal moet word, deur deposito's en onttrekking van fondse (slashing) van deelnemers wat nie die protokol. Ook, BLS-verifikasie met 'n aanvaarbare vlak van sekuriteit pas eenvoudig nie, byvoorbeeld, in 'n standaard EOS- of Ethereum-transaksie nie - daar is eenvoudig nie genoeg tyd vir verifikasie nie. Die kontrakkode is WebAssembly of EVM, uitgevoer deur 'n virtuele masjien. Kriptografiese funksies word (nog) nie oorspronklik geïmplementeer nie, en werk tientalle keer stadiger as konvensionele kriptografiese biblioteke. Baie protokolle voldoen nie aan die vereistes bloot gebaseer op sleutelvolume nie, byvoorbeeld 1024 en 2048 bisse vir RSA, 4-8 keer groter as die standaard transaksiehandtekening in Bitcoin en Ethereum.

Die teenwoordigheid van implementering in verskillende programmeertale speel ook 'n rol - waarvan daar min is, veral vir nuwe protokolle. Die opsie met integrasie in konsensus vereis die skryf van 'n protokol in die platformtaal, so jy sal moet soek vir kode in Go for geth, in Rust for Parity, in C++ vir EOS. Almal sal JavaScript-kode moet soek, en aangesien JavaScript en kriptografie nie besonder goeie vriende is nie, sal WebAssembly help, wat nou beslis beweer dat dit die volgende belangrike internetstandaard is.

Gevolgtrekking

Ek hoop in die vorige een Artikel Ek het daarin geslaag om jou te oortuig dat die generering van ewekansige getalle op die blokketting krities is vir baie aspekte van die lewe van gedesentraliseerde netwerke, en met hierdie artikel het ek gewys dat hierdie taak uiters ambisieus en moeilik is, maar goeie oplossings bestaan ​​reeds. Oor die algemeen is die finale ontwerp van die protokol slegs moontlik nadat massiewe toetse uitgevoer is wat alle aspekte van opstelling tot foutemulasie in ag neem, so dit is onwaarskynlik dat u klaargemaakte resepte in spanwitskrifte en artikels sal vind, en ons sal beslis nie besluit in die volgende jaar of twee skryf "doen dit op hierdie manier, presies reg."

Totsiens, vir ons PVRB in die blokketting wat ontwikkel word Haya, Ons het besluit om drempel-BLS-handtekeninge te gebruik, ons beplan om PVRB op konsensusvlak te implementeer, aangesien verifikasie in slim kontrakte met 'n aanvaarbare vlak van sekuriteit nog nie moontlik is nie. Dit is moontlik dat ons twee skemas gelyktydig gebruik: eerstens, duur geheime deel om langtermyn random_seed te skep, en dan gebruik ons ​​dit as die basis vir hoëfrekwensie ewekansige generering deur deterministiese drempel BLS handtekeninge te gebruik, miskien sal ons onsself beperk tot slegs een van die skemas. Ongelukkig is dit onmoontlik om vooraf te sê wat die protokol sal wees; die enigste goeie ding is dat, soos in die wetenskap, in ingenieursprobleme, 'n negatiewe resultaat ook 'n resultaat is, en elke nuwe poging om die probleem op te los is nog 'n stap vir die navorsing van almal wat by die probleem betrokke is. Om aan besigheidsvereistes te voldoen, los ons 'n spesifieke praktiese probleem op - die verskaffing van speltoepassings met 'n betroubare bron van entropie, so ons moet ook aandag gee aan die blokketting self, veral die kwessies van kettingfinaliteit en netwerkbestuur.

En al sien ons nog nie 'n bewese weerstandbiedende PVRB in blokkettings nie, wat genoeg tyd gebruik sou word om deur regte toepassings, veelvuldige oudits, vragte en natuurlik regte aanvalle getoets te word, maar die aantal moontlike paaie bevestig dat 'n oplossing bestaan, en watter -van hierdie algoritmes sal uiteindelik die probleem oplos. Ons deel graag die resultate en bedank ander spanne wat ook aan hierdie kwessie werk vir artikels en kode wat ingenieurs toelaat om nie twee keer op dieselfde hark te trap nie.

Dus, wanneer jy 'n programmeerder ontmoet wat gedesentraliseerde ewekansig ontwerp, wees oplettend en sorgsaam, en verskaf sielkundige hulp indien nodig :)

Bron: will.com