Sarrera

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

Kriptografiako zifratze guztiz sendo baten kontzeptuarekin gertatzen den bezala, benetako "Publicly Verifiable Random Beacon" (aurrerantzean PVRB) protokoloak eskema idealera ahalik eta gehien hurbiltzen saiatzen dira, izan ere. sare errealetan ez da aplikagarria bere forma hutsean: behar da zorrozki ados jarri bit batean, txanda asko egon behar dira, eta mezu guztiak guztiz azkarrak eta beti entregatuak izan behar dira. Jakina, hori ez da benetako sareetan gertatzen. Hori dela eta, blockchain modernoetan zeregin zehatzetarako PVRBak diseinatzean, ondoriozko aleatorioa eta indar kriptografikoa kontrolatzeko ezintasunaz gain, arazo arkitektoniko eta tekniko hutsak gehiago sortzen dira.

PVRBrentzat, bloke-katea bera funtsean mezuak = transakzioak dituen komunikazio-euskarria da. Horrek sareko arazoetatik, mezuak ez bidaltzeari, middlewarearekin lotutako arazoetatik partzialki abstraitzea ahalbidetzen du - arrisku horiek guztiak sare deszentralizatuak bere gain hartzen ditu, eta PVRBrentzat bere balio nagusia dagoeneko bidalitako transakzio bat baliogabetu edo hondatzeko ezintasuna da - hau da. ez utzi parte-hartzaileei protokoloan parte hartzeari uko egitea, adostasunaren aurkako eraso arrakastatsua egin ez badute behintzat. Segurtasun-maila hori onargarria da, beraz, PVRB-k parte-hartzaileen elkarlanarekiko erresistentea izan behar du blockchain kate nagusiaren neurri berean. Era berean, honek PVRB adostasunaren parte izan behar duela iradokitzen du sarea bloke-kate nagusian ados badago, nahiz eta bidezko emaitza ausazko bakarrarekin ados egon. Edo, PVRB bloke-kateari eta blokeei dagokienez modu asinkronoan lan egiten duen kontratu adimendun batek inplementatutako protokolo autonomo bat besterik ez da. Bi metodoek abantailak eta desabantailak dituzte, eta haien artean aukeratzea oso ez da hutsala.

PVRB ezartzeko bi modu

Deskriba ditzagun zehatzago PVRB ezartzeko bi aukera: bertsio autonomoa, bloke-katearen independentea den kontratu adimendun bat erabiliz funtzionatzen duena, eta adostasun integratua protokoloan integratua, sareak bloke-katearen eta sareak adosten dituenaren arabera. sartu beharreko transakzioak. Kasu guztietan, blockchain motor ezagunak esango ditut: Ethereum, EOS eta kontratu adimendunak ostatatzeko eta prozesatzeko moduan antzekoak diren guztiak.

Kontratu autonomoa

Bertsio honetan, PVRB kontratu adimenduna da, ausazko ekoizleen (aurrerantzean RP) transakzioak onartzen dituena, prozesatu, emaitzak konbinatu eta, ondorioz, edozein erabiltzailek kontratu honetatik jaso dezakeen balio jakin batera iristen dena. Baliteke balio hori ez egotea kontratuan zuzenean gordetzea, baizik eta datuen bidez soilik irudikatu ahal izango da, zeinetatik ondorioztatzen den ausazko balio bat eta bakarra deterministikoki lor daitekeen. Eskema honetan, RPak bloke-katearen erabiltzaileak dira, eta edonork parte har dezake sorkuntza prozesuan.

Kontratu autonomoarekin aukera ona da:

• eramangarritasuna (kontratuak blockchainetik blockchainera arrastatu daitezke)
• Ezartzeko eta probatzeko erraztasuna (kontratuak idazteko eta probatzeko errazak dira)
• erosotasuna eskema ekonomikoak ezartzeko (erraza da zure tokena egitea, zeinaren logikak PVRBren helburuak betetzen dituen)
• Dagoeneko lanean dauden bloke-kateetan abiarazteko aukera

Desabantailak ere baditu:

• informatika-baliabideetan, transakzio-bolumenean eta biltegiratze-muga handiak (bestela esanda, cpu/mem/io)
• Kontratuaren barruko eragiketen murrizketak (argibide guztiak ez daude eskuragarri, zaila da kanpoko liburutegiak konektatzea)
• blokeo-katean transakzioak baino azkarrago antolatzeko ezintasuna

Aukera hau egokia da lehendik dagoen sare batean exekutatu behar den PVRB bat ezartzeko, kriptografia konplexurik ez duena eta interakzio kopuru handirik behar ez duena.

Adostasunean integratua

Bertsio honetan, PVRB bloke-katearen nodoen kodean inplementatuta dago, bloke-katearen nodoen arteko mezuen trukearekin paraleloan integratuta edo exekutatzen da. Protokoloaren emaitzak zuzenean ekoitzitako blokeetan idazten dira, eta protokolo-mezuak p2p sarearen bidez bidaltzen dira nodoen artean. Protokoloak blokeetan idatzi beharreko zenbakiak sortzen dituenez, sareak adostasuna lortu behar du. Horrek esan nahi du PVRB mezuak, transakzioak bezala, nodoen bidez balioztatu eta blokeetan sartu behar direla, sareko edozein parte-hartzaileek PVRB protokoloa betetzen dutela baliozkotu dezan. Horrek automatikoki ageriko irtenbidera garamatza: sareak bloke bati eta transakzioei buruzko adostasuna onartzen badu, orduan PVRB adostasunaren parte izan beharko litzateke, eta ez protokolo autonomo bat. Bestela, baliteke bloke bat adostasunaren ikuspuntutik balio izatea, baina PVRB protokoloa ez da betetzen, eta PVRBren ikuspuntutik ezin da blokea onartu. Beraz, "adostasun integratua" aukera hautatzen bada, PVRB adostasunaren zati garrantzitsu bihurtzen da.

PVRB inplementazioak sarearen adostasun mailan deskribatzean, ezin dira inola ere saihestu behin betiko arazoak. Finalitatea adostasun deterministetan erabiltzen den mekanismoa da, bloke batean (eta hari daraman katea) behin betikoa den eta inoiz botako ez den bloke batean blokeatzen duena, nahiz eta paralelo sardexka bat gertatu. Esaterako, Bitcoin-en ez dago halako mekanismorik - konplexutasun handiagoko kate bat argitaratzen baduzu, konplexu gutxiagoko bat ordezkatuko du, kateen luzera edozein dela ere. Eta EOSen, adibidez, azkenak Azken bloke itzulezinak izenekoak dira, batez beste 432 blokean behin agertzen direnak (12*21 + 12*15, bozketa aurreko + konpromisoa). Prozesu hau bloke-ekoizleen (aurrerantzean BP) sinaduraren 2/3ren zain dago. Azken LIB baino zaharragoak diren sardexkak agertzen direnean, baztertu besterik ez dira egiten. Mekanismo honek posible egiten du transakzioa bloke-katean sartuta dagoela eta ez dela inoiz atzera botako, erasotzaileak zein baliabide dituen ere. Gainera, azken blokeak 2/3 BP-k sinatutako blokeak dira Hyperledger, Tendermint eta pBFTn oinarritutako beste adostasun batzuetan. Era berean, zentzuzkoa da behin betikotasuna bermatzeko protokolo bat egitea adostasunaren gehigarri bat, blokeen ekoizpenarekin eta argitalpenarekin modu asinkronoan lan egin dezakeelako. Hona hemen ona artikuluan Ethereum-en amaierari buruz.

Finalitatea oso garrantzitsua da erabiltzaileentzat, berau gabe "gastu bikoitzeko" eraso baten biktima izan daitezkeenak, non BPk blokeak "eusten" dituen eta sareak transakzio on bat "ikusi" ondoren argitaratzen dituen. Finalitaterik ez badago, argitaratutako forkak blokea transakzio "on" batekin ordezkatzen du beste batekin, fork "txar" batetik, zeinetan funts berdinak erasotzailearen helbidera transferitzen diren. PVRB-ren kasuan, behin betiko baldintzak are zorrotzagoak dira, izan ere, PVRBrako forkak eraikitzeak aukera ematen dio erasotzaileak ausazko hainbat aukera prestatzeko aukera errentagarriena argitaratzeko, eta balizko eraso baten denbora mugatzea da. irtenbide ona.

Hori dela eta, aukerarik onena PVRB eta finalitatea protokolo batean konbinatzea da; ondoren amaitutako blokea = ausazko amaituta, eta horixe da lortu behar genuena. Orain jokalariek ausazko bermatua jasoko dute N segundotan, eta ziur egon daiteke ezinezkoa dela atzera botatzea edo berriro errepikatzea.

Adostasunean integratutako aukera ona da:

• blokeen ekoizpenari dagokionez inplementazio asinkronoa egiteko aukera - blokeak ohi bezala ekoizten dira, baina horrekin batera, PVRB protokoloak funtziona dezake, bloke bakoitzerako ausazkotasuna sortzen ez duena.
• kriptografia astuna ere ezartzeko gaitasuna, kontratu adimendunetan ezarritako murrizketarik gabe
• transakzioak bloke-katean sartzen diren baino azkarrago mezuen trukea antolatzeko gaitasuna, adibidez, protokoloaren zati batek nodoen artean funtziona dezake mezuak sarean banatu gabe.

Desabantailak ere baditu:

• Proba eta garapenean zailtasunak - sareko akatsak, falta diren nodoak, sareko bidegurutze gogorrak imitatu beharko dituzu.
• Inplementazio-erroreek sareko hardfork bat behar dute

PVRB ezartzeko bi metodoek bizitzarako eskubidea dute, baina bloke modernoetan kontratu adimendunen ezarpena nahiko mugatua da oraindik baliabide informatikoetan, eta kriptografia seriorako trantsizio oro ezinezkoa da askotan. Eta kriptografia serioa beharko dugu, jarraian frogatuko den bezala. Arazo hau argi eta garbi aldi baterakoa den arren, kontratuetan kriptografia serioa behar da arazo asko konpontzeko, eta pixkanaka agertzen ari da (adibidez, zkSNARK-en sistema-kontratuak Ethereum-en)

Blockchain-ek, protokoloko mezularitza-kanal gardena eta fidagarria eskaintzen duena, ez du doan egiten. Edozein protokolo deszentralizatuak Sybil-en erasoa izateko aukera kontuan hartu behar du; edozein ekintza egin dezakete hainbat konturen indar kontzertatuek, beraz, diseinatzerakoan, kontuan hartu behar da erasotzaileek protokolo kopuru arbitrarioa sortzeko duten gaitasuna. elkarlanean jarduten duten parte-hartzaileak.

PVRB eta bloke aldagaiak.

Ez nuen gezurrik esan esan nuenean inork ez duela oraindik inplementatu PVRB on bat, joko-aplikazio askok probatua, bloke-kateetan. Nondik datoz, orduan, hainbeste joko-aplikazio Ethereum eta EOS-en? Honek harritzen zaituen bezainbat harritzen nau, nondik atera zituzten hainbeste ausazko “iraunkor” ingurune guztiz determinista batean?

Blockchain-en ausazkotasuna lortzeko modurik gogokoena blokeko informazio "ezusteko" moduko bat hartu eta horretan oinarrituta ausazko bat egitea da, balio bat edo gehiago hash eginez. Artikulu ona horrelako eskemen arazoei buruz Hemen. Blokean "ezusteko" edozein balio har dezakezu, adibidez, bloke hash-a, transakzio kopurua, sarearen konplexutasuna eta aldez aurretik ezagutzen ez diren beste balio batzuk. Ondoren hash itzazu, bat edo gehiago, eta, teorian, benetako ausazko bat lortu beharko zenuke. Whitepaper-era zure eskema "post-kuantikoa segurua" dela ere gehi diezaiokezu (kuantikoaren froga hash funtzioak daudelako :)).

Baina post-quantum seguru hashak ere ez dira nahikoa, ai. Sekretua PVRBren eskakizunetan dago, utz iezadazu gogorarazi aurreko artikuluan:

1. Emaitzak banaketa uniformea ​​izan behar du, hau da, kriptografia sendo frogagarrian oinarrituta egon behar du.
2. Ezin da emaitzaren bit bat kontrolatu. Ondorioz, emaitza ezin da aldez aurretik aurreikusi.
3. Ezin duzu sorkuntza-protokoloa saboteatu protokoloan ez parte hartuz edo sarea eraso mezuekin gainkargatuz
4. Aurreko guztiak erresistenteak izan behar ditu protokoloko parte-hartzaile desleialen kopuru onargarri baten (adibidez, parte-hartzaileen 1/3) elkarren aurka.

Kasu honetan, 1. eskakizuna bakarrik betetzen da, eta 2. eskakizuna ez da betetzen. Blokearen ezusteko balioak hash eginez, banaketa uniformea ​​eta ausazko onak lortuko ditugu. Baina BPk behintzat aukera du "blokea argitaratzeko edo ez". Horrela, BPk gutxienez ausazko BI aukeretatik aukeratu ditzake: "bere" eta beste norbaitek blokea egiten badu aterako dena. BP-k aldez aurretik "snoop" dezake zer gertatuko den bloke bat argitaratzen badu, eta besterik gabe, egitea edo ez egitea erabakitzen du. Horrela, erruletan, adibidez, “bikoiti-bakoitia” edo “gorri/beltza” jolasten duenean, bloke bat argitaratu ahal izango du irabazi bat ikusten badu soilik. Horrek, adibidez, bloke hash bat "etorkizunetik" erabiltzeko estrategia ere bideraezina egiten du. Kasu honetan, “ausazkoa erabiliko da, hau da, uneko datuak eta etorkizuneko bloke baten hash-a hatxatuz lortzen dena, adibidez, N + 42 altuera duen, non N uneko blokearen altuera den. Horrek eskema apur bat indartzen du, baina hala ere BPri aukera ematen dio, etorkizunean bada ere, blokeari eutsi edo argitaratu ala ez aukeratzeko.

BP softwarea kasu honetan konplikatuagoa bihurtzen da, baina ez asko. Besterik gabe, transakzio bat balioztatzeko eta bloke batean sartzerakoan, egiaztapen azkar bat dago irabazirik egongo den ikusteko, eta, agian, transakzio bat parametroak hautatzea irabazteko probabilitate handia lortzeko. Aldi berean, ia ezinezkoa da BP adimendun bat harrapatzea horrelako manipulazioengatik; bakoitzean helbide berriak erabil ditzakezu eta pixkanaka irabazi susmoak piztu gabe.

Beraz, blokeko informazioa erabiltzen duten metodoak ez dira egokiak PVRBren inplementazio unibertsal gisa. Bertsio mugatu batean, apustuen tamainaren murrizketak, jokalari kopuruaren murrizketak eta/edo KYC erregistroa (jokalari batek helbide anitz erabiltzea eragozteko), eskema hauek joko txikietarako funtziona dezakete, baina ezer gehiago.

PVRB eta konpromiso-errebela.

Ados, hashing-ari eta gutxienez bloke hash-aren eta beste aldagai batzuen ezusteko erlatiboari esker. Aurrealdeko meatzarien arazoa konpontzen baduzu, zerbait egokiagoa lortu beharko zenuke. Gehi ditzagun erabiltzaileak eskema honetara - utz diezaiegun ausazkotasunari ere eragiten: laguntza teknikoko edozein langilek esango dizu IT sistemetan ausazkoena erabiltzaileen ekintzak direla :)

Eskema inozoa, erabiltzaileek ausazko zenbakiak bidaltzen dituztenean eta emaitza, adibidez, beren baturaren hash gisa kalkulatzen denean, ez da egokia. Kasu honetan, azken jokalariak, bere ausaz aukeratuz, emaitza zein izango den kontrola dezake. Horregatik erabiltzen da oso erabilia den konpromiso-errebela eredua. Parte-hartzaileek lehenengo hash-ak bidaltzen dituzte beren ausazkoetatik (konpromisoak), eta, ondoren, ausazkoak beraiek irekitzen dituzte (agerian). "Agerrarazi" fasea beharrezko konpromisoak bildu ondoren hasten da, beraz, parte-hartzaileek lehenago bidali duten ausazko hash-a bidal dezakete. Orain uztar dezagun hau guztia bloke baten parametroekin, eta etorkizunetik hartutako bat baino hobea (ausazkotasuna etorkizuneko blokeetako batean bakarrik aurki daiteke), eta listo - ausazkotasuna prest dago! Orain edozein jokalarik eragiten du ondoriozko ausazkotasuna, eta BP gaiztoa "garai" dezake berea, aldez aurretik ezezaguna, ausazkotasuna gaindituz... Protokoloa saboteatzearen aurkako babesa ere gehi dezakezu agerian ez irekitzeko fasean - besterik gabe. konpromisoa egiterakoan transakzioari zenbateko jakin bat erantsi behar zaiola eskatuz - segurtasun-gordailua, agerian jartzeko prozeduran soilik itzuliko dena. Kasu honetan, konpromisoa hartzea eta ez agerian jartzea ez da errentagarria izango.

Saiakera ona izan zen, eta horrelako eskemak ere badaude joko-DApps-etan, baina ai, hau ez da nahikoa. Orain meatzariak ez ezik, protokoloko edozein partaidek ere eragin dezake emaitzan. Oraindik ere posible da balioa kontrolatzea, aldakortasun gutxiagorekin eta kostuarekin, baina, meatzariaren kasuan bezala, zozketako emaitzak PVRB protokoloan parte hartzeko kuota baino baliotsuagoak badira, orduan ausazkoak dira. -producer(RP) agerian utzi ala ez erabaki dezake eta hala ere ausazko bi aukeren artean aukera dezake.
Baina posible egin zen konprometitzen dutenak eta agerian uzten ez dutenak zigortzea, eta eskema hau ondo etorriko da. Bere sinpletasuna abantaila larria da - protokolo serioagoek kalkulu askoz indartsuagoak behar dituzte.

PVRB eta sinadura deterministak.

Badago beste modu bat RP-a sasi-ausazko zenbaki bat ematera behartzeko, eta horrek eragin ezin duen "aurreirudi" batekin hornitzen bada - sinadura deterministikoa da. Sinadura hori, adibidez, RSA da, eta ez da ECS. RP-k gako pare bat baditu: RSA eta ECC, eta bere gako pribatuarekin balio jakin bat sinatzen badu, RSAren kasuan sinadura BAT ETA BAKARRIK lortuko du, eta ECSren kasuan edozein kopuru sor dezake. baliozko sinadura desberdinak. Hau da, ECS sinadura sortzean ausazko zenbaki bat erabiltzen delako, sinatzaileak aukeratua, eta edozein modutan aukera daiteke, sinatzaileak hainbat sinaduraren artean bat aukeratzeko aukera emanez. RSAren kasuan: "sarrerako balio bat" + "gako bikote bat" = "sinadura bat". Ezinezkoa da beste RP batek zer sinadura lortuko duen aurreikustea, beraz, sinadura deterministikoak dituen PVRB bat antola daiteke balio bera sinatu duten hainbat parte-hartzaileren RSA sinadurak konbinatuz. Adibidez, aurreko ausazkoa. Eskema honek baliabide asko aurrezten ditu, zeren sinadurak protokoloaren araberako jokabide zuzenaren berrespena eta ausazkotasunaren iturri dira.

Hala ere, sinadura deterministak izan arren, eskema oraindik zaurgarria da "azken aktore" arazoaren aurrean. Azken partaideak oraindik erabaki dezake sinadura argitaratu edo ez, eta horrela emaitza kontrolatzen du. Eskema alda dezakezu, bloke hash-ak gehitu, txandak egin, emaitza aldez aurretik aurreikusi ezin dadin, baina teknika horiek guztiek, aldaketa asko kontuan izanda ere, parte-hartzaile batek kolektiboan duen eraginaren arazoa konpondu gabe uzten dute. fidagarria ez den ingurunea sortzen du eta ekonomiko eta denbora-mugetan soilik funtziona dezake. Horrez gain, RSA gakoen tamaina (1024 eta 2048 bit) nahiko handia da eta blockchain-eko transakzioen tamaina oso parametro garrantzitsua da. Dirudienez, ez dago arazoa konpontzeko modu errazik, goazen aurrera.

PVRB eta sekretuak partekatzeko eskemak

Kriptografian, sareari PVRB balio bakarra eta bakarra adosteko aukera ematen dioten eskemak daude, eskemak parte-hartzaile batzuen ekintza maltzurren aurrean erresistenteak diren bitartean. Ezagutzea merezi duen protokolo erabilgarri bat Shamirren sekretua partekatzeko eskema da. Sekretu bat (adibidez, gako sekretua) hainbat zatitan banatzeko eta zati horiek N parte-hartzaileei banatzeko balio du. Sekretua horrela banatzen da, N-tik ateratako M zatiak nahikoak direla hura berreskuratzeko, eta horiek edozein M zati izan daitezke. Behatzak bada, orduan funtzio ezezagun baten grafikoa edukita, parte-hartzaileek grafikoan puntuak trukatzen dituzte, eta M puntuak jaso ondoren, funtzio osoa berreskuratu daiteke.
Azalpen ona ematen da wiki baina zure buruan protokoloa erreproduzitzeko ia horrekin jolastea erabilgarria da demo orrialdea.

FSSS (Fiat-Shamir Secret Sharing) eskema bere forma hutsean aplikagarria balitz, PVRB suntsiezina izango litzateke. Bere formarik sinpleenean, protokoloa honelakoa izan daiteke:

• Parte-hartzaile bakoitzak bere ausaz sortzen du eta bertatik akzioak banatzen dizkie beste parte-hartzaileei
• Parte-hartzaile bakoitzak gainerako parte-hartzaileen sekretuen zatia agerian uzten du
• Parte-hartzaile batek M akzio baino gehiago baditu, orduan parte-hartzaile honen kopurua kalkula daiteke, eta bakarra izango da, agerian utzitako parte-hartzaileen multzoa edozein dela ere.
• Agertutako ausazkoen konbinazioa nahi den PVRB da

Hemen, parte-hartzaile indibidual batek ez du gehiago eragiten protokoloaren emaitzetan, ausazko dibulgazio-atalasea lortzea beraren menpe dagoen kasuetan izan ezik. Hori dela eta, protokolo honek, protokoloan lan egiten duten eta eskuragarri dauden RPen behar den proportzioa baldin badago, funtzionatzen du, indar kriptografikoaren baldintzak ezarriz eta “azken aktore” arazoarekiko erresistentea izanik.

Aukera ezin hobea izan daiteke, Fiat-Shamir sekretua partekatzean oinarritutako PVRB eskema hau adibidez deskribatzen da. hau Artikulu. Baina, goian esan bezala, blokeo-katean aurrez aurre aplikatzen saiatzen bazara, muga teknikoak agertzen dira. Hona hemen EOS kontratu adimendunean protokoloaren inplementazio proba baten adibidea eta bere zati garrantzitsuena: argitaratutako parte-hartzailea egiaztatzea: kodea. Kodetik ikus dezakezu frogak baliozkotzeak hainbat biderketa eskalar behar dituela eta erabiltzen diren zenbakiak oso handiak direla. Ulertu behar da bloke-kateetan egiaztatzea bloke-ekoizleak transakzioa prozesatzen duen unean gertatzen dela, eta, oro har, edozein parte-hartzaileek erraz egiaztatu behar du protokoloaren zuzentasuna, beraz, egiaztapen-funtzioaren abiaduraren eskakizunak oso larriak dira. . Aukera honetan, aukera ez da eraginkorra izan, egiaztapena ez baita sartzen transakzio-mugan (0.5 segundo).

Egiaztapenaren eraginkortasuna da, oro har, blockchain-eko edozein eskema kriptografiko aurreratuen erabiltzeko baldintza garrantzitsuenetako bat. Frogak sortzea, mezuak prestatzea - ​​prozedura hauek katetik kanpo atera daitezke eta errendimendu handiko ordenagailuetan egin daitezke, baina egiaztapena ezin da saihestu - hau da PVRBren beste baldintza garrantzitsu bat.

PVRB eta atalasearen sinadurak

Ezkutuko partekatze-eskema ezagutu ondoren, "atalasea" gako-hitzarekin batutako protokolo-klase oso bat aurkitu genuen. Informazio batzuk zabaltzeak N-ko M parte-hartzaile zintzoen parte hartzea eskatzen duenean eta parte-hartzaile zintzoen multzoa N-ren azpimultzo arbitrarioa izan daitekeenean, "atalase" eskemez hitz egiten dugu. Haiek dira “azken aktorea” arazoari aurre egiteko aukera ematen digutenak, orain erasotzaileak ez badu sekretuaren zatia agerian uzten, beste parte hartzaile zintzo batek egingo du. Eskema hauek esanahi bakarrean eta bakar batean adostea ahalbidetzen dute, nahiz eta protokoloa saboteatzen duten parte-hartzaile batzuek.

Sinadura deterministen eta atalase-eskemen konbinazioak PVRB ezartzeko eskema oso eroso eta itxaropentsu bat garatzea ahalbidetu zuen - atalase-sinadura deterministikoak dira. Hemen artikuluan atalaseen sinaduren hainbat erabilerari buruz, eta hona hemen beste on bat luze irakurri Dash-etik.

Azken artikuluak BLS sinadurak deskribatzen ditu (BLS Boneh-Lynn-Shacham esan nahi du, Hemen artikulua), programatzaileentzat kalitate oso garrantzitsua eta oso erosoa dutenak: gako publikoak, sekretuak, publikoak eta BLS sinadurak elkarren artean konbina daitezke eragiketa matematiko sinpleak erabiliz, haien konbinazioak gako eta sinadura baliozkoak izaten jarraitzen duten bitartean, asko erraz batu ditzakezu. sinadurak bakarrean eta hainbat gako publiko batean. Gainera, deterministikoak dira eta sarrerako datu berdinetarako emaitza bera sortzen dute. Kalitate horri esker, BLS sinaduren konbinazioak berez baliozko gakoak dira, eta horrek aukera bat inplementatzeko aukera ematen du, zeinetan N parte-hartzaile Mk sinadura bat eta bakarra ekoizten duten, determinista, publikoki egiazta daitekeena eta ezustekoa, Mth-ek ireki arte. parte-hartzailea.

Atalase BLS sinadurak dituen eskema batean, parte-hartzaile bakoitzak zerbait sinatzen du BLS erabiliz (adibidez, aurreko ausazkoa), eta atalasearen sinadura arrunta nahi den ausazkoa da. BLS sinaduren propietate kriptografikoek ausazko kalitatearen eskakizunak betetzen dituzte, atalasearen zatiak "azken aktorearen aurka" babesten du eta gakoen konbinazio bereziak algoritmo interesgarri gehiago ezartzea ahalbidetzen du, adibidez, protokolo-mezuen agregazio eraginkorra ahalbidetzen dutenak. .

Beraz, zure bloke-katean PVRB eraikitzen ari bazara, ziurrenik BLS atalasearen sinadura eskemarekin amaituko duzu, hainbat proiektu dagoeneko erabiltzen ari dira. Adibidez, DFinity (Hemen zirkuitua ezartzen duen erreferentea, eta Hemen sekretua partekatzeko egiaztagarriaren ezarpenaren adibidea) edo Keep.network (hemen dago haien ausazko baliza paper horia, eta hemen Adibidez protokoloa zerbitzatzen duen kontratu adimenduna).

PVRBren ezarpena

Zoritxarrez, oraindik ez dugu ikusten bere segurtasuna eta egonkortasuna frogatu duen PVRB bloke-kateetan inplementatutako prest dagoen protokolorik. Protokoloak beraiek prest dauden arren, teknikoki lehendik dauden soluzioetan aplikatzea ez da erraza. Sistema zentralizatuetarako, PVRBk ez du zentzurik, eta deszentralizatuak zorrozki mugatuta daude informatika-baliabide guztietan: CPU, memoria, biltegiratzea, I/O. PVRB bat diseinatzea protokolo ezberdinen konbinazioa da, gutxienez blockchain bideragarri batzuen baldintza guztiak betetzen dituen zerbait sortzeko. Protokolo batek modu eraginkorragoan kalkulatzen du, baina RPen arteko mezu gehiago behar ditu, eta bestean, berriz, oso mezu gutxi behar dira, baina froga bat sortzea hamarnaka minutu edo ordu behar dituen zeregina izan daiteke.

Kalitatezko PVRB bat aukeratzerakoan kontuan hartu beharko dituzun faktoreak zerrendatuko ditut:

• Indar kriptografikoa. Zure PVRB erabat alboraezina izan behar da, bit bakar bat kontrolatzeko gaitasunik gabe. Eskema batzuetan hori ez da horrela, beraz deitu kriptografo bati
• “Azken aktorea” arazoa. Zure PVRB-ak erasoekiko erresistentea izan behar du, non RP bat edo gehiago kontrolatzen dituen erasotzaileak bi emaitzetako bat aukera dezakeen.
• Protokoloaren sabotajearen arazoa. Zure PVRB-ak erasoekiko erresistentea izan behar du, non RP bat edo gehiago kontrolatzen dituen erasotzaile batek ausaz izan ala ez erabakitzen duen eta horretan eragiteko bermatuta egon daitekeen edo probabilitate jakin batekin.
• Mezu kopuruaren arazoa. Zure RPek bloke-kateari gutxieneko mezuak bidali beharko lituzkete eta ekintza sinkronoak ahalik eta gehien saihestu beharko lituzkete, esate baterako, "Informazio batzuk bidali ditut, parte-hartzaile zehatz baten erantzunaren zain nago". P2p sareetan, batez ere geografikoki sakabanatuta daudenetan, ez duzu erantzun azkar batekin kontatu behar
• Konplexutasun konputazionalaren arazoa. PVRB katearen edozein etapa egiaztatzea oso erraza izan behar da, sareko bezero osoek egiten baitute. Inplementazioa kontratu adimendun bat erabiliz egiten bada, orduan abiadura-eskakizunak oso zorrotzak dira
• Irisgarritasunaren eta bizitasunaren arazoa. Zure PVRBk erresistentea izaten ahalegindu behar du sarearen zati bat denbora-tarte batean erabilgarri ez dagoen eta RPren zati bat funtzionatzeari uzten dion egoeretan.
• Konfigurazio fidagarriaren eta hasierako gakoen banaketaren arazoa. Zure PVRB-k protokoloaren konfigurazio nagusia erabiltzen badu, istorio handi eta serio bat da hau. Hemen Adibidez. Parte-hartzaileek protokoloa hasi baino lehen elkarri giltzak kontatu behar badituzte, hori ere arazo bat da parte-hartzaileen osaera aldatzen bada
• Garapen arazoak. Liburutegien erabilgarritasuna eskatutako hizkuntzetan, haien segurtasuna eta errendimendua, publizitatea, proba konplexuak, etab.

Esate baterako, atalase BLS sinadurak arazo nabarmen bat dute - lanean hasi aurretik, parte-hartzaileek giltzak banatu behar dituzte elkarren artean, atalaseak lan egingo duen talde bat antolatuz. Horrek esan nahi du sare deszentralizatu batean gutxienez truke txanda batek itxaron beharko duela, eta sortutako randa, adibidez, jokoetan beharrezkoa dela kontuan hartuta, ia denbora errealean, horrek esan nahi du fase honetan protokoloaren sabotajea posible dela. , eta atalasearen eskemaren abantailak galtzen dira . Arazo hau aurrekoak baino sinpleagoa da dagoeneko, baina oraindik atalase-taldeak eratzeko prozedura bereizi bat garatzea eskatzen du, zeina ekonomikoki babestu beharko dena, gordailuak eta funtsak (mozketa) erretiratuz (mozketa) betetzen ez dituzten parte-hartzaileei. protokoloa. Gainera, segurtasun-maila onargarria duen BLS egiaztapena ez da sartzen, adibidez, EOS edo Ethereum transakzio estandar batean; besterik gabe, ez dago egiaztapenerako denbora nahikorik. Kontratuaren kodea WebAssembly edo EVM da, makina birtual batek exekutatua. Funtzio kriptografikoak ez dira jatorrizko moduan inplementatzen (oraindik), eta ohiko liburutegi kriptografikoak baino hamar aldiz motelago funtzionatzen dute. Protokolo askok ez dituzte gako-bolumenean oinarritutako baldintzak betetzen, adibidez, RSArako 1024 eta 2048 bit, Bitcoin eta Ethereum-en transakzio-sinadura estandarra baino 4-8 aldiz handiagoa.

Programazio-lengoaia desberdinetan inplementazioen presentzia ere badu zeresana - gutxi daude, batez ere protokolo berrietarako. Adostasunean integratzeko aukerak plataformako hizkuntzan protokolo bat idaztea eskatzen du, beraz, kodea bilatu beharko duzu Go for geth-en, Rust for Parity-n, C++-n EOS-en. Guztiek JavaScript kodea bilatu beharko dute, eta JavaScript eta kriptografia bereziki lagun minak ez direnez, WebAssembly-k lagunduko du, eta orain, zalantzarik gabe, Interneteko hurrengo estandar garrantzitsua dela dio.

Ondorioa

Espero dut aurrekoan Artikulu Blokeoan ausazko zenbakiak sortzea sare deszentralizatuen bizitzako hainbat alderditarako ezinbestekoa dela konbentzitzea lortu nuen, eta artikulu honekin erakutsi nuen zeregin hau oso asmo handikoa eta zaila dela, baina dagoeneko irtenbide onak daudela. Oro har, protokoloaren azken diseinua posible da konfiguraziotik akatsen emulaziora arteko alderdi guztiak kontuan hartzen dituzten proba masiboak egin ondoren soilik, beraz, nekez aurkituko dituzu prest egindako errezeta taldeen liburu zurietan eta artikuluetan, eta, zalantzarik gabe, ez dugu egingo. erabaki hurrengo urtean edo bitan idatzi "egin ezazu horrela, oso ondo".

Agur, garatzen ari den blockchain-eko gure PVRBrentzat Haya, atalase BLS sinadurak erabiltzea erabaki genuen, PVRB adostasun mailan ezartzeko asmoa dugu, oraindik ez baita posible segurtasun-maila onargarria duten kontratu adimendunetan egiaztatzea. Baliteke bi eskema aldi berean erabiltzea: lehenik eta behin, isilpeko partekatze garestia epe luzerako ausazko_hazia sortzeko, eta, ondoren, maiztasun handiko ausazko sorkuntzarako oinarri gisa erabiltzen dugu atalase deterministiko BLS sinadurak erabiliz, agian bakarrik mugatuko gara. eskemetako bat. Zoritxarrez, ezinezkoa da aldez aurretik esan zein izango den protokoloa; gauza on bakarra zera da, zientzian bezala, ingeniaritza-problemetan ere emaitza negatiboa dela eta arazoa konpontzeko saiakera berri bakoitza beste urrats bat dela. arazoan parte hartzen duten guztien ikerketa. Negozio-eskakizunak betetzeko, arazo praktiko zehatz bat konpontzen dugu: joko-aplikazioei entropia-iturri fidagarri bat eskaintzea, beraz, bloke-kateari berari ere arreta jarri behar diogu, batez ere katearen finaltasunari eta sarearen gobernantzari buruzko gaiei.

Eta bloke-kateetan oraindik frogatutako PVRB erresistenterik ikusten ez dugun arren, benetako aplikazioek, auditoria anitzek, kargak eta, jakina, benetako erasoek probatzeko denbora nahikoa erabiliko zutena, baina bide posibleen kopuruak baieztatzen du hori. irtenbide bat existitzen da, eta algoritmo horietatik zerk konponduko du azkenean arazoa. Emaitzak partekatuko ditugu eta gai honetan ere lanean ari diren beste taldeei eskerrak emango dizkiegu ingeniariei bi aldiz arrasto bera ez zapaltzea ahalbidetzen dieten artikulu eta kodeengatik.

Beraz, ausazko deszentralizatua diseinatzen duen programatzaile batekin topo egiten duzunean, egon adi eta zaindua, eta eman laguntza psikologikoa behar izanez gero :)

Iturria: www.habr.com