Sissejuhatus

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

Nagu krüptograafiast pärit absoluutselt tugeva šifri kontseptsiooni puhul, püüavad ka tõelised „avalikult kontrollitava juhusliku majaka” (edaspidi PVRB) protokollid ideaalsele skeemile võimalikult lähedale jõuda, sest reaalsetes võrkudes ei ole see puhtal kujul rakendatav: tuleb rangelt kokku leppida ühes bitis, ringe peab olema palju ning kõik sõnumid peavad olema ideaalselt kiired ja alati edastatud. Päris võrkudes see muidugi nii ei ole. Seetõttu tekib kaasaegsetes plokiahelates spetsiifiliste ülesannete jaoks PVRB-de kujundamisel lisaks sellest tuleneva juhuslikkuse ja krüptograafilise tugevuse kontrollimise võimatusele veel palju puhtalt arhitektuurseid ja tehnilisi probleeme.

PVRB jaoks on plokiahel ise sisuliselt suhtlusmeedium, milles sõnumid = tehingud. See võimaldab teil osaliselt abstraheerida võrguprobleemidest, sõnumite edastamata jätmisest, vahevara probleemidest – kõik need riskid võtab enda peale detsentraliseeritud võrk ja selle põhiväärtus PVRB jaoks on võimetus tühistada või rikkuda juba saadetud tehingut – see teeb. mitte lubada osalejatel protokollis osalemisest keelduda, välja arvatud juhul, kui nad on edukalt rünnanud konsensust. Selline turvalisuse tase on vastuvõetav, seega peaks PVRB olema osalejate kokkumängu suhtes täpselt samal määral vastupidav kui peamine plokiahela ahel. Samuti vihjab see sellele, et PVRB peab olema osa konsensusest, kui võrk lepib kokku peamise plokiahela osas, isegi kui see nõustub ka ainsa õiglase juhusliku tulemusega. Või on PVRB lihtsalt eraldiseisev protokoll, mida rakendab nutikas leping, mis töötab plokiahela ja plokkide suhtes asünkroonselt. Mõlemal meetodil on oma eelised ja puudused ning valik nende vahel on äärmiselt ebaoluline.

Kaks võimalust PVRB rakendamiseks

Kirjeldame lähemalt kahte PVRB juurutamise võimalust - eraldiseisvat versiooni, mis töötab plokiahelast sõltumatu nutika lepingu abil ning protokolli sisseehitatud konsensuspõhist versiooni, mille kohaselt lepib võrk kokku plokiahelas ja tehingud. Kõigil juhtudel pean silmas populaarseid plokiahela mootoreid: Ethereum, EOS ja kõik need, mis on nendega sarnased nutikate lepingute hostimise ja töötlemise viiside poolest.

Iseseisev leping

Selles versioonis on PVRB nutikas leping, mis võtab vastu juhuslike tootjate (edaspidi RP) tehinguid, töötleb neid, kombineerib tulemusi ning saavutab selle tulemusel teatud väärtuse, mille iga kasutaja saab sellest lepingust saada. Seda väärtust ei tohi otse lepingusse salvestada, vaid pigem esitada ainult andmed, millest saab deterministlikult saada ühe ja ainult ühe saadud juhusliku väärtuse. Selles skeemis on RP-d plokiahela kasutajad ja genereerimisprotsessis võib lubada kõigil osaleda.

Eraldiseisva lepinguga variant on hea:

• teisaldatavus (lepinguid saab lohistada plokiahelast plokiahelasse)
• juurutamise ja testimise lihtsus (lepinguid on lihtne kirjutada ja testida)
• mugavus majandusskeemide rakendamisel (lihtne on teha oma token, mille loogika täidab PVRB eesmärke)
• võimalus käivitada juba töötavatel plokiahelatel

Sellel on ka puudusi:

• tugevad piirangud arvutusressurssidele, tehingute mahule ja salvestusruumile (teisisõnu, cpu/mem/io)
• lepingusisesed toimingute piirangud (kõik juhised pole saadaval, väliseid teeke on keeruline ühendada)
• võimetus korraldada sõnumivahetust kiiremini, kui tehingud plokiahelasse kaasatakse

See valik sobib PVRB juurutamiseks, mis vajab töötamist olemasolevas võrgus, ei sisalda keerulist krüptograafiat ega nõua suurt hulka interaktsioone.

Konsensusega integreeritud

Selles versioonis on PVRB rakendatud plokiahela sõlme koodis, mis on sisseehitatud või töötab paralleelselt plokiahela sõlmede vahelise sõnumivahetusega. Protokolli tulemused kirjutatakse otse toodetud plokkidesse ning protokolliteated saadetakse sõlmede vahel üle p2p võrgu. Kuna protokolli tulemuseks on numbrid, mis tuleb kirjutada plokkidesse, peab võrk jõudma nende osas konsensusele. See tähendab, et PVRB-sõnumid, nagu ka tehingud, peavad olema sõlmede poolt kinnitatud ja plokkidesse lülitatud, et iga võrgus osaleja saaks kinnitada vastavust PVRB-protokollile. See viib meid automaatselt ilmse lahenduseni – kui võrk lepib ploki ja selles tehtavate tehingute osas konsensuses kokku, siis peaks PVRB olema osa konsensusest, mitte eraldiseisev protokoll. Vastasel juhul on võimalik, et plokk on konsensuse seisukohalt kehtiv, kuid PVRB protokolli ei järgita ja PVRB seisukohast ei saa plokki aktsepteerida. Nii et kui valitakse konsensusega integreeritud variant, muutub PVRB konsensuse oluliseks osaks.

Võrgu konsensuse tasemel PVRB rakenduste kirjeldamisel ei saa mingil juhul vältida lõplikkuse küsimusi. Lõplikkus on deterministlikes konsensustes kasutatav mehhanism, mis lukustab ploki (ja selleni viiva ahela), mis on lõplik ja mida ei visata kunagi minema, isegi kui tekib paralleelne kahvel. Näiteks Bitcoinis sellist mehhanismi pole - kui avaldate keerukama ahela, asendab see kõik vähem keerukad, olenemata ahelate pikkusest. Ja näiteks EOS-is on lõplikud nn Last Irreversible Blocks, mis ilmuvad keskmiselt iga 432 ploki järel (12*21 + 12*15, eelhääletus + eelkohustus). See protsess ootab sisuliselt 2/3 plokitootjate (edaspidi BP) allkirju. Kui ilmuvad kahvlid, mis on vanemad kui viimane LIB, visatakse need lihtsalt kõrvale. See mehhanism võimaldab garanteerida, et tehing kaasatakse plokiahelasse ja seda ei tühistata kunagi, olenemata sellest, millised ressursid ründajal on. Samuti on viimased plokid plokid, millele on alla kirjutanud 2/3 BP Hyperledgeris, Tendermintis ja muudes pBFT-põhistes konsensustes. Samuti on mõttekas teha lõplikkuse tagamise protokoll konsensuse lisana, kuna see võib töötada asünkroonselt plokkide tootmise ja avaldamisega. Siin on hea artikkel lõplikkuse kohta Ethereumis.

Lõplikkus on äärmiselt oluline kasutajate jaoks, kes ilma selleta võivad sattuda "topeltkulu" rünnaku ohvriks, kus BP "hoiab" blokke ja avaldab need pärast seda, kui võrk on head tehingut "näinud". Kui lõplikkust pole, asendab avaldatud kahvel ploki “hea” tehinguga teisega, “halvast” kahvlist, mille käigus kantakse samad rahalised vahendid ründaja aadressile. PVRB puhul on lõplikkuse nõuded veelgi karmimad, kuna PVRB jaoks on kahvlite ehitamine ründajal võimalus koostada mitu juhuslikku varianti, et avaldada kõige tulusam ning võimaliku ründe aja piiramine on hea lahendus.

Seetõttu on parim variant PVRB ja lõplikkuse ühendamine üheks protokolliks – siis lõpetatud plokk = lõplikult juhuslikult vormistatud ja see on täpselt see, mida meil oli vaja saada. Nüüd saavad mängijad garanteeritud juhuslikkuse N sekundiga ja võivad olla kindlad, et seda on võimatu tagasi kerida ega uuesti mängida.

Konsensusega integreeritud variant on hea:

• asünkroonse realiseerimise võimalus seoses plokkide tootmisega - plokke toodetakse nagu tavaliselt, kuid sellega paralleelselt saab töötada PVRB protokoll, mis ei tekita iga ploki puhul juhuslikkust
• võimalus rakendada isegi rasket krüptograafiat ilma nutikatele lepingutele seatud piiranguteta
• võimalus korraldada sõnumite vahetust kiiremini, kui plokiahelas on tehingud, näiteks võib osa protokollist töötada sõlmede vahel ilma sõnumeid üle võrgu levitamata

Sellel on ka puudusi:

• Raskused testimisel ja arendamisel – peate emuleerima võrguvigu, puuduvaid sõlme, võrgu kõvakahvleid
• Rakendusvead nõuavad võrgu hardforki

Mõlemal PVRB juurutamise meetodil on õigus elule, kuid nutikatel lepingutel rakendamine tänapäevastes plokiahelates on arvutusressursside osas endiselt üsna piiratud ja igasugune üleminek tõsisele krüptograafiale on sageli lihtsalt võimatu. Ja me vajame tõsist krüptograafiat, nagu allpool näidatakse. Kuigi see probleem on ilmselgelt ajutine, on paljude probleemide lahendamiseks vaja tõsist krüptograafiat lepingutes ja see ilmub järk-järgult (näiteks süsteemilepingud zkSNARKide jaoks Ethereumis)

Blockchain, mis pakub läbipaistvat ja usaldusväärset protokollisõnumite kanalit, ei tee seda tasuta. Iga detsentraliseeritud protokoll peab arvestama Sybili rünnaku võimalusega; mis tahes toimingut saavad teha mitme konto kooskõlastatud jõud, seetõttu tuleb projekteerimisel arvestada ründajate võimega luua suvaline arv protokolle kokkumängus osalejad.

PVRB ja ploki muutujad.

Ma ei valetanud, kui ütlesin, et keegi pole veel head PVRB-d, mida paljud hasartmängurakendused on testinud, plokiahelates juurutanud. Kust siis Ethereumist ja EOS-ist nii palju hasartmängurakendusi tuleb? See üllatab mind sama palju kui teid, kust nad said nii palju "püsivaid" juhuslikke täiesti deterministlikus keskkonnas?

Lemmikviis plokiahelas juhuslikkuse saamiseks on võtta plokist mingisugune “ennustamatu” info ja teha selle põhjal juhuslik – lihtsalt üht või mitut väärtust räsides. Hea artikkel selliste skeemide probleemidest siin. Võite võtta plokis mis tahes "ettenägematuid" väärtusi, näiteks ploki räsi, tehingute arvu, võrgu keerukust ja muid eelnevalt teadmata väärtusi. Seejärel räsi neid, üks või mitu, ja teoreetiliselt peaksite saama tõelise juhusliku. Võite isegi paberile lisada, et teie skeem on "kvantijärgne turvaline" (kuna on olemas kvantkindlad räsifunktsioonid :)).

Kuid isegi kvantijärgsetest turvalistest räsidest ei piisa, paraku. Saladus peitub PVRB nõuetes, tuletan neid meelde eelmisest artiklist:

1. Tulemus peab olema tõestatavalt ühtlase jaotusega, st põhinema tõestatavalt tugeval krüptograafial.
2. Tulemuse ühtki bitti pole võimalik juhtida. Seetõttu ei saa tulemust ette ennustada.
3. Te ei saa genereerimisprotokolli saboteerida, kui te protokollis ei osale või võrku ründesõnumitega üle koormates
4. Kõik eelnev peab olema vastupidav lubatava arvu ebaausate protokollis osalejate kokkumängule (näiteks 1/3 osalejatest).

Sel juhul on täidetud ainult nõue 1 ja ei ole täidetud nõue 2. Räsides plokist ettearvamatuid väärtusi, saame ühtlase jaotuse ja head juhuslikud. Kuid BP-l on vähemalt võimalus "plokk avaldada või mitte". Seega saab BP valida vähemalt KAHE juhusliku variandi vahel: “oma” ja see, mis selgub, kui ploki teeb keegi teine. BP võib eelnevalt "nuhkida", mis juhtub, kui ta bloki avaldab, ja lihtsalt otsustab, kas ta teeb seda või mitte. Seega, mängides ruletis näiteks “paaris-paaris” või “punane/must”, saab ta ploki avaldada vaid siis, kui näeb võitu. See muudab ka näiteks plokiräsi kasutamise strateegia "tulevikust" toimimatuks. Sel juhul öeldakse, et "kasutatakse juhuslikku, mis saadakse praeguste andmete ja tulevase ploki räsimisel, mille kõrgus on näiteks N + 42, kus N on praegune ploki kõrgus. See tugevdab skeemi veidi, kuid võimaldab BP-l, ehkki tulevikus, valida, kas hoida blokeeringut või avaldada.

BP tarkvara muutub sel juhul keerulisemaks, kuid mitte palju. Lihtsalt tehingu valideerimisel ja plokki kaasamisel kontrollitakse kiirelt, kas võit tuleb, ja võimalusel ka ühe tehinguparameetri valimine, et saada suur võidutõenäosus. Samal ajal on selliste manipulatsioonide eest peaaegu võimatu tabada nutikat BP-d, iga kord saab uusi aadresse kasutada ja vähehaaval võita, ilma kahtlust äratamata.

Seega ei sobi plokist saadud teavet kasutavad meetodid PVRB universaalseks teostuseks. Piiratud versioonis, kus on piirangud panuste suurusele, piirangud mängijate arvule ja/või KYC registreerimisele (et üks mängija ei saaks kasutada mitut aadressi), võivad need skeemid töötada väikeste mängude puhul, kuid ei midagi enamat.

PVRB ja commit-reveal.

Okei, tänu räsimisele ja vähemalt ploki räsi ja muude muutujate suhtelisele ettearvamatusele. Kui lahendate eesrindlike kaevurite probleemi, peaksite hankima midagi sobivamat. Lisame sellesse skeemi kasutajad - las nemadki mõjutavad juhuslikkust: iga tehnilise toe töötaja ütleb teile, et IT-süsteemides on kõige juhuslikum kasutajate tegevus :)

Naiivne skeem, kus kasutajad saadavad lihtsalt juhuslikke numbreid ja tulemuseks arvutatakse näiteks nende summa räsi, ei sobi. Sel juhul saab viimane mängija, valides oma juhusliku valiku, kontrollida, milline on tulemus. Seetõttu kasutatakse väga laialdaselt kasutatavat commit-reveal mustrit. Osalejad saadavad esmalt oma juhuslikkusest räsi (commits) ja seejärel avavad need ise (ilmub). "Avaldamise" faas algab alles pärast vajalike kohustuste kogumist, nii et osalejad saavad saata täpselt selle juhusliku räsi, millest nad varem saatsid. Nüüd paneme selle kõik kokku ploki parameetritega ja paremini kui tulevikust võetud (juhuslikkust võib leida ainult ühest tulevasest plokist) ja voilaa - juhuslikkus on valmis! Nüüd mõjutab iga mängija tekkivat juhuslikkust ja saab pahatahtliku BP-st "alistada", alistades selle oma, eelnevalt teadmata juhuslikkusega... Protokolli saboteerimise eest saate kaitset lisada ka sellega, et te ei ava seda avalikustamise etapis – lihtsalt nõudes tehingu tegemisel teatud summa lisamist — tagatisraha, mis tagastatakse alles avalikustamise käigus. Sel juhul on pühendumine ja mitte paljastamine kahjumlik.

See oli hea katse ja sellised skeemid on ka mängude DApp-ides, kuid paraku sellest jälle ei piisa. Nüüd saab tulemust mõjutada mitte ainult kaevandaja, vaid ka iga protokollis osaleja. Väärtust ennast on siiski võimalik, väiksema varieeruvusega ja kuludega kontrollida, kuid nagu kaevandaja puhul, kui loosimise tulemused on väärtuslikumad kui PVRB protokollis osalemise tasu, siis juhuslik -producer(RP) saab otsustada, kas avaldada, ja siiski valida vähemalt kahe juhusliku valiku vahel.
Kuid sai võimalikuks karistada neid, kes kohustuvad ja ei paljasta, ja see skeem tuleb kasuks. Selle lihtsus on tõsine eelis – tõsisemad protokollid nõuavad palju võimsamaid arvutusi.

PVRB ja deterministlikud signatuurid.

On veel üks viis sundida RP-d esitama pseudojuhuslikku arvu, mida ta ei saa mõjutada, kui see on varustatud "eelpildiga" - see on deterministlik signatuur. Selline allkiri on näiteks RSA, mitte ECS. Kui RP-l on paar võtmeid: RSA ja ECC ning ta allkirjastab oma privaatvõtmega teatud väärtuse, siis RSA puhul saab ta ÜHE JA AINULT ÜHE allkirja ning ECS-i puhul saab genereerida suvalise arvu erinevad kehtivad allkirjad. Seda seetõttu, et ECS-i allkirja loomisel kasutatakse juhuslikku numbrit, mille valib allkirjastaja ja mida saab valida mis tahes viisil, andes allkirjastajale võimaluse valida mitmest allkirjast üks. RSA puhul: “üks sisendväärtus” + “üks võtmepaar” = “üks allkiri”. On võimatu ennustada, millise allkirja teine ​​RP saab, seega saab deterministlike allkirjadega PVRB korraldada, kombineerides mitme sama väärtusega allkirjastanud osaleja RSA allkirjad. Näiteks eelmine juhuslik. See skeem säästab palju ressursse, sest allkirjad on nii protokollijärgse õige käitumise kinnitus kui ka juhuslikkuse allikas.

Kuid isegi deterministlike allkirjade korral on skeem endiselt haavatav "viimase osaleja" probleemi suhtes. Viimane osaleja saab siiski otsustada, kas ta avaldab allkirja või mitte, kontrollides seeläbi tulemust. Saate muuta skeemi, lisada sellele plokkräsi, teha ringe nii, et tulemust poleks võimalik ette ennustada, kuid kõik need tehnikad jätavad isegi paljusid muudatusi arvesse võttes siiski lahendamata probleemi ühe osaleja mõjust kollektiivile. tulemuseks on ebausaldusväärne keskkond ja see saab töötada ainult majanduslike ja ajaliste piirangute korral. Lisaks on RSA võtmete suurus (1024 ja 2048 bitti) üsna suur ning plokiahela tehingute suurus on äärmiselt oluline parameeter. Ilmselt pole probleemi lahendamiseks lihtsat viisi, liigume edasi.

PVRB ja salajagamise skeemid

Krüptograafias on skeeme, mis võimaldavad võrgul kokku leppida ühes ja ainult ühes PVRB väärtuses, samas kui sellised skeemid on vastupidavad mõne osaleja pahatahtlikule tegevusele. Üks kasulik protokoll, millega tasub end kurssi viia, on Shamiri salajagamisskeem. Selle eesmärk on jagada saladus (näiteks salajane võti) mitmeks osaks ja jagada need osad N osalejale. Saladus on jaotatud nii, et selle taastamiseks piisab M osast N-st ja need võivad olla mis tahes M osad. Kui sõrmedel, siis tundmatu funktsiooni graafiku olemasolul vahetavad osalejad graafikul punkte ja pärast M punkti saamist saab kogu funktsiooni taastada.
Hea selgitus on antud wiki aga sellega mängimine praktiliselt selleks, et peas protokolli mängida, on kasulik demo lehel.

Kui FSSS (Fiat-Shamir Secret Sharing) skeem oleks rakendatav puhtal kujul, oleks see hävimatu PVRB. Kõige lihtsamal kujul võib protokoll välja näha järgmine:

• Iga osaleja genereerib oma juhusliku ja jagab sellest osad teistele osalejatele
• Iga osaleja paljastab oma osa teiste osalejate saladustest
• Kui osalejal on rohkem kui M aktsiat, saab selle osaleja arvu arvutada ja see on kordumatu, olenemata osalejate hulgast
• Ilmunud juhuslikkuse kombinatsioon on soovitud PVRB

Siin ei mõjuta üksikosaleja enam protokolli tulemusi, välja arvatud juhtudel, kui juhuslikkuse avalikustamise läve saavutamine sõltub ainult temast. Seetõttu töötab see protokoll, kui on olemas vajalik osa protokolliga töötavaid ja saadaval olevaid RP-sid, rakendades krüptograafilise tugevuse nõudeid ja olles vastupidav "viimase osaleja" probleemile.

See võiks olla ideaalne variant, seda Fiat-Shamiri salajagamisel põhinevat PVRB-skeemi on kirjeldatud näiteks artiklis see artiklit. Kuid nagu eespool mainitud, kui proovite seda plokiahelas otsekohe rakendada, ilmnevad tehnilised piirangud. Siin on näide EOS nutilepingu protokolli testrakendusest ja selle kõige olulisemast osast - avaldatud jagamise osaleja kontrollimisest: kood. Koodist on näha, et tõestuse valideerimiseks on vaja mitut skalaarkorrutist ning kasutatavad arvud on väga suured. Tuleb mõista, et plokiahelates toimub kontrollimine hetkel, kui plokitootja tehingut töötleb, ja üldiselt peab iga osaleja lihtsalt kontrollima protokolli õigsust, seega on kontrollifunktsiooni kiiruse nõuded väga tõsised. . Selle valiku puhul osutus valik ebaefektiivseks, kuna kontrollimine ei mahtunud tehingulimiiti (0.5 sekundit).

Kontrollimise tõhusus on üks olulisemaid nõudeid üldiselt kõigi täiustatud krüptograafiliste skeemide kasutamisel plokiahelas. Tõestuste loomine, sõnumite ettevalmistamine – neid protseduure saab ahelast välja võtta ja teha suure jõudlusega arvutites, kuid kontrollimisest ei saa mööda minna – see on veel üks oluline nõue PVRB jaoks.

PVRB ja läve allkirjad

Olles tutvunud salajagamisskeemiga, avastasime terve klassi protokolle, mida ühendab märksõna “lävi”. Kui mõne teabe avaldamine eeldab M ausa osaleja osalust N-st ja ausate osalejate hulk võib olla N suvaline alamhulk, räägime "läve" skeemidest. Just nemad lubavad meil tegeleda “viimase näitleja” probleemiga, nüüd, kui ründaja oma osa saladusest ei avalda, teeb selle tema eest mõni teine, aus osaleja. Need skeemid võimaldavad kokku leppida ühes ja ainult ühes tähenduses, isegi kui mõned osalejad protokolli saboteerivad.

Deterministlike signatuuride ja läviskeemide kombinatsioon võimaldas välja töötada väga mugava ja paljutõotava skeemi PVRB rakendamiseks - need on deterministlikud lävisignatuurid. Siin artikkel läve allkirjade erinevate kasutuste kohta ja siin on veel üks hea kaua lugenud Dashist.

Viimases artiklis kirjeldatakse BLS-i allkirju (BLS tähistab Boneh-Lynn-Shachamit, siin artikkel), millel on programmeerijatele väga oluline ja äärmiselt mugav kvaliteet – avalikke, salajasi, avalikke võtmeid ja BLS-i allkirju saab omavahel kombineerida lihtsate matemaatiliste toimingute abil, kusjuures nende kombinatsioonid jäävad kehtivateks võtmeteks ja signatuurideks, võimaldades hõlpsasti koondada paljusid. allkirjad üheks ja paljud avalikud võtmed üheks. Need on ka deterministlikud ja annavad samade sisendandmete jaoks sama tulemuse. Tänu sellele kvaliteedile on BLS-i allkirjade kombinatsioonid ise kehtivad võtmed, mis võimaldab rakendada võimalust, kus M osalejat N-st annab ühe ja ainult ühe allkirja, mis on deterministlik, avalikult kontrollitav ja ettearvamatu, kuni selle avab Mth. osaleja .

BLS-i lävisignatuuridega skeemis allkirjastab iga osaleja BLS-i abil midagi (näiteks eelmist juhuslikku) ja ühine lävisignatuur on soovitud juhuslik. BLS-i signatuuride krüptograafilised omadused vastavad juhusliku kvaliteedi nõuetele, läveosa kaitseb “viimase tegutseja” eest ning võtmete ainulaadne kombineeritavus võimaldab realiseerida palju huvitavamaid algoritme, mis võimaldavad näiteks tõhusalt protokollisõnumeid koondada. .

Seega, kui ehitate oma plokiahelale PVRB-d, jõuate suure tõenäosusega BLS-i läve allkirjade skeemi, mitmed projektid seda juba kasutavad. Näiteks DFinity ( siin etalon, mis rakendab ahelat ja siin kontrollitava salajagamise näide) või Keep.network (siin on nende juhuslik majakas). kollane paber, Kuid näide protokolli teenindav nutikas leping).

PVRB rakendamine

Kahjuks ei näe me endiselt PVRB plokiahelates rakendatud valmis protokolli, mis oleks tõestanud oma turvalisust ja stabiilsust. Kuigi protokollid ise on valmis, ei ole nende tehniline rakendamine olemasolevatele lahendustele lihtne. Tsentraliseeritud süsteemide jaoks pole PVRB-l mõtet ja detsentraliseeritud süsteemides on rangelt piiratud kõik arvutusressursid: protsessor, mälu, salvestusruum, I/O. PVRB kujundamine on erinevate protokollide kombinatsioon, et luua midagi, mis vastab kõigile vähemalt mõne elujõulise plokiahela nõuetele. Üks protokoll arvutab tõhusamalt, kuid nõuab rohkem sõnumeid RP-de vahel, samas kui teine ​​nõuab väga vähe sõnumeid, kuid tõestuse loomine võib olla ülesanne, mis võtab kümneid minuteid või isegi tunde.

Loetlesin tegurid, mida peate kvaliteetse PVRB valimisel arvestama:

• Krüptograafiline tugevus. Teie PVRB peab olema rangelt erapooletu, ilma et oleks võimalik ühtki bitti juhtida. Mõne skeemi puhul see nii ei ole, seega helistage krüptograafile
• "Viimase näitleja" probleem. Teie PVRB peab olema vastupidav rünnakutele, kus ühte või mitut RP-d kontrolliv ründaja saab valida ühe kahest tulemusest.
• Protokolli sabotaaži probleem. Teie PVRB peab olema vastupidav rünnakutele, mille puhul ühte või mitut RP-d kontrolliv ründaja otsustab, kas olla juhuslik või mitte, ja seda saab garanteerida või teatud tõenäosusega mõjutada.
• Probleem sõnumite arvuga. Teie RP-d peaksid saatma plokiahelale minimaalselt sõnumeid ja vältima nii palju kui võimalik sünkroonseid toiminguid, näiteks olukordi, nagu "Saatsin teavet, ootan konkreetselt osalejalt vastust." P2p-võrkudes, eriti geograafiliselt hajutatud võrkudes, ei tohiks te loota kiirele reageerimisele
• Arvutusliku keerukuse probleem. Ketisisese PVRB mis tahes etapi kontrollimine peaks olema äärmiselt lihtne, kuna seda teevad kõik võrgu täiskliendid. Kui juurutamine toimub nutika lepingu abil, siis kiirusnõuded on väga karmid
• Ligipääsetavuse ja elavuse probleem. Teie PVRB peaks püüdma olla vastupidav olukordadele, kus osa võrgust muutub mõneks ajaks kättesaamatuks ja osa RP-st lihtsalt lakkab töötamast
• Usaldusväärse seadistuse ja esmase võtmejaotuse probleem. Kui teie PVRB kasutab protokolli esmast seadistust, on see eraldi suur ja tõsine lugu. Siin näide. Kui osalejad peavad enne protokolli käivitamist üksteisele oma võtmed ütlema, on see probleem ka osalejate koosseisu muutumisel
• Arenguprobleemid. Teekide saadavus vajalikes keeltes, nende turvalisus ja jõudlus, avalikustamine, komplekstestid jne.

Näiteks on BLS-i läve allkirjade puhul märkimisväärne probleem – enne tööle asumist peavad osalejad üksteisele võtmeid jagama, moodustades grupi, mille piires lävi töötab. See tähendab, et vähemalt üks vahetusvoor detsentraliseeritud võrgus peab ootama ja arvestades, et näiteks genereeritud rand on mängudes vajalik peaaegu reaalajas, tähendab see, et protokolli saboteerimine on selles etapis võimalik. ja läve skeemi eelised lähevad kaotsi. See probleem on juba varasematest lihtsam, kuid nõuab siiski eraldi protseduuri väljatöötamist lävendite rühmade moodustamiseks, mida tuleb kaitsta majanduslikult, hoiuste ja raha väljavõtmisega (slashing) osalejatelt, kes ei järgi nõudeid. protokolli. Samuti ei sobi vastuvõetava turvatasemega BLS-i verifitseerimine lihtsalt näiteks tavalisse EOS-i või Ethereumi tehingusse – kontrollimiseks ei jätku lihtsalt aega. Lepingu kood on WebAssembly või EVM, mida käivitab virtuaalne masin. Krüptograafilisi funktsioone ei rakendata algselt (veel) ja need töötavad kümneid kordi aeglasemalt kui tavalised krüptoteegid. Paljud protokollid ei vasta nõuetele lihtsalt võtmemahu põhjal, näiteks RSA jaoks 1024 ja 2048 bitti, mis on 4–8 korda suurem kui Bitcoini ja Ethereumi standardne tehingusignatuur.

Oma rolli mängib ka rakenduste olemasolu erinevates programmeerimiskeeltes - mida on vähe, eriti uute protokollide puhul. Konsensusse integreerimise võimalus nõuab protokolli kirjutamist platvormi keeles, nii et peate koodi otsima Go for gethis, Rust for Parity's ja C++ EOS-i jaoks. Igaüks peab otsima JavaScripti koodi ja kuna JavaScript ja krüptograafia pole eriti lähedased sõbrad, aitab WebAssembly, mis nüüd kindlasti pretendeerib järgmisele olulisele Interneti-standardile.

Järeldus

Loodan, et eelmisel siit Mul õnnestus teid veenda, et plokiahelas juhuslike numbrite genereerimine on detsentraliseeritud võrkude elu paljude aspektide jaoks kriitilise tähtsusega ning selle artikliga näitasin, et see ülesanne on äärmiselt ambitsioonikas ja keeruline, kuid häid lahendusi on juba olemas. Üldiselt on protokolli lõplik kujundamine võimalik alles pärast ulatuslikke teste, mis võtavad arvesse kõiki aspekte seadistamisest kuni vea emuleerimiseni, nii et tõenäoliselt ei leia meeskondadest ja artiklitest valmisretsepte ning me kindlasti ei leia seda otsustage järgmise aasta või paari jooksul, et kirjutada "tee seda nii, täpselt õige".

Hüvasti, meie PVRB jaoks arendatavas plokiahelas Haya, otsustasime kasutada läviväärtusega BLS-i allkirju, plaanime PVRB-d juurutada konsensuse tasemel, kuna vastuvõetava turvatasemega nutikates lepingutes pole veel võimalik kinnitada. Võimalik, et kasutame kahte skeemi korraga: esiteks kallis salajagamine, et luua pikaajaline random_seed, ja seejärel kasutame seda kõrgsagedusliku juhusliku genereerimise alusena, kasutades deterministlikke lävi BLS-signatuure. Võib-olla piirdume ainult sellega. üks skeemidest. Kahjuks on võimatu ette öelda, mis protokollist saab, hea on ainult see, et nagu teaduses, on ka inseneriprobleemide puhul negatiivne tulemus ja iga uus katse probleemi lahendamiseks on järjekordne samm. kõigi probleemiga seotud inimeste uurimistööd. Ärinõuete täitmiseks lahendame konkreetse praktilise probleemi – mängurakenduste pakkumine usaldusväärse entroopiaallikaga, seega peame tähelepanu pöörama ka plokiahelale endale, eelkõige ahela lõplikkuse ja võrguhalduse küsimustele.

Ja kuigi me ei näe plokiahelates veel tõestatult vastupidavat PVRB-d, mida oleks kasutatud piisavalt kaua, et seda oleks testitud reaalsete rakenduste, mitmete auditite, laadimiste ja loomulikult reaalsete rünnakutega, kuid võimalike teede arv kinnitab, et lahendus on olemas ja milline neist algoritmidest lõpuks probleemi lahendab. Jagame hea meelega tulemusi ja täname teisi meeskondi, kes samuti selle probleemiga tegelevad, artiklite ja koodide eest, mis võimaldavad inseneridel mitte kaks korda samale rehale astuda.

Seega, kui kohtute programmeerijaga, kes projekteerib detsentraliseeritud juhuslikkust, olge tähelepanelik ja hooliv ning vajadusel osutage psühholoogilist abi :)

Allikas: www.habr.com