Sissejuhatus

function getAbsoluutseltJuhuslikArv() {
        return 4; \/\/ tagastab täiesti juhusliku arvu!
}

Nii nagu täiesti vastupidava krüptograafilise šifri kontseptsiooni puhul, püüavad tegelikud "Avalikult Kontrollitavad Juhuslikud Beaconid" (edaspidi PVRB) võimalikult lähedale ideaalsetele skeemidele, kuna reaalses võrgus ei saa neid puhtal kujul rakendada: tuleb kokku leppida rangelt ühes bitis, ringe peab olema palju ja kõik sõnumid peavad olema ideaalselt kiirelt edastatavad. Loomulikult ei ole see reaalses võrgus nii. Seega, PVRB kavandamisel konkreetsete ülesannete jaoks tänapäeva plokiahelates, lisaks juhuslike numbrite kontrollimise ja krüptograafilise vastupidavuse võimatusele, esineb veel palju puhtalt arhitektuurilisi ja tehnilisi probleeme.

Ise plokiahel on PVRB jaoks sisuliselt suhtluskeskkond, kus sõnumid = tehingud. See võimaldab osaliselt abstraheerida võrgu probleemidest, sõnumite mitte-tarnimisest, vahepealse tarkvara probleemidest — kõik need riskid võtab enda peale detsentraliseeritud võrk, ja selle peamine väärtus PVRB jaoks — ei ole võimalik tagasi võtta või rikkuda juba saadetud tehingut — see ei võimalda osalistel loobuda protokollist, kui nad ei ole edukalt konsensust rünnanud. Selline turvalisuse tase on vastuvõetav, seetõttu peab PVRB olema vastupidav osaliste vandenõudele täpselt samamoodi nagu põhiblokiahela. See vihjab ka sellele, et PVRB peab olema osa konsensusest, kui võrk on kokku leppinud põhiblokiahela, siis peaks ta samaaegselt kokku leppima ka ainulaadses õiglaselt tulemuses juhuslikus. Või, PVRB on lihtsalt iseseisev protokoll, mis on rakendatud nutilepinguna, töötades asünkroonselt plokiahela ja blokkide suhtes. Mõlemal meetodil on oma eelised ja puudused, ning valik nende vahel on äärmiselt keeruline.

Kaks PVRB rakendamise viisi

Kirjeldame lähemalt kaht PVRB rakendamise võimalust — iseseisvat versiooni, mis töötab sõltumatu plokiahelast nutilepinguga, ja konsensusintegratsiooniga — protokolliga, mille kohaselt võrk lepib kokku plokiahela ja hõlmatud tehingutes. Kõigil juhtudel mõtlen ma populaarsetele plokiahela mootoritele: Ethereum, EOS ja kõik, mis sarnaneb nendele nutilepingute paigutamise ja töötlemise viisil.

Iseseisev leping

Selles variandis esindab PVRB nutileping, mis aktsepteerib random-producer’ite (edaspidi RP) tehinguid, töötleb neid, kombineerib tulemusi ning jõuab lõpuks mõnele väärtusele, mille võib saada mistahes kasutaja sellest lepingust. See väärtus ei pruugi lepingus otse olla talletatud, vaid see võib olla esitatud ainult andmetena, mille põhjal saab määratult kätte ühe ja ainus tulemuse. Selles skeemis on RP plokiahela kasutajad, ja protsessis osalemiseks võib lubada kedagi.

Iseseisva lepinguga variant on hea:

• ülekantavuse tõttu (lepingud saab tõsta ühest plokiahelast teise)
• lihtsuse tõttu rakendamisel ja testimisel (lepingu loomine ja testimine on mugav)
• mugavuse tõttu majanduslike skeemidega (oma tokeni loomine, mille loogika teenib PVRB eesmärke, on lihtne)
• võimaluse tõttu töötada juba olemasolevates plokiahelates

Sellega on ka puuduseid:

• tugevad piirangud ressurssidele arvutustes, tehingu maht ja salvestus (lihtsamalt öeldes cpu/mem/io)
• piirangud lepingus toimuvale tegevusele (kõiki käske ei ole saadaval, keeruline on väliste teeki ühendamine)
• ei ole võimalik korraldada sõnumite vahetust kiiremini, kui tehingud lisatakse plokiahelasse

See variant sobib PVRB rakendamiseks, mis peab olema käivitatud juba olemasolevas võrgus, mis ei sisalda keerulist krüptograafiat ja ei nõua suurt hulka interaktsioone.

Konsensuse integreeritud

Selles variandis on PVRB rakendatud plokiahela sõlmede koodis, integreeritud või töötavad plokiahela sõlmede vahelises sõnumivahetuses paralleelselt. Protokolli tulemused salvestatakse kohe loodavatesse blokki, samal ajal kui protokolli sõnumid saadetakse p2p võrgu kaudu sõlmede vahel. Kuna protokollil on tulemuseks numbrid, mis tuleb salvestada blokkidesse, peab võrk nende osas konsensuseni jõudma. See tähendab, et PVRB sõnumid, nagu ka tehingud, peavad olema sõlmede poolt valideeritud ja lisatud blokkidesse, et iga võrgu osaleja saaks PVRB protokolli vastavust valideerida. See viib meid automaatselt ilmse lahenduse juurde – kui võrk lepib kokku konsensusest bloki ja selle tehingute osas, peab PVRB olema osa konsensusest, mitte eraldi protokoll. Vastasel juhul võib juhtuda, et blokk on konsensuse seisukohalt kehtiv, kuid PVRB protokolli ei ole järgitud, mistõttu PVRB seisukohalt ei saa blokk olla aktsepteeritud. Seega, kui valitakse „konsensuse-integratsiooniga“ variant, muutub PVRB oluliseks osaks konsensusest.

Kirjeldades PVRB implementeerimisi konsensuse tasandil võrgus, ei tohi mingil juhul mööda vaadata lõpuleviimise küsimustest. Lõpuleviimine on mehhanism, mida kasutatakse määratletud konsensustes, mis fikseerib bloki (ja ahela, mis viib sinna), mis on lõplik ja mida kunagi ei visata välja, isegi kui ilmub paralleelne fork. Näiteks Bitcoinis sellist mehhanismi ei ole – kui avaldada keerukam ahel, asendab see iga vähem keeruka, sõltumata ahelate pikkusest. EOSes on näiteks viimased pöördumatud plokid, mis ilmuvad keskmiselt iga 432 ploki järel (12*21 + 12*15, eelhäälestamine + eelkomitee). See protsess on sisuliselt 2/3 allkirjade ootamine blokki tootvatelt tootjatelt (edasi BP). Kui ilmnevad forkid, mis on vanemad kui viimane LIB, visatakse need lihtsalt kõrvale. See mehhanism võimaldab garantii anda, et tehing on plokiahelas ja seda ei tühistata, sõltumata sellest, kui palju ressursse ründajal on. Samuti on lõplikud plokid need, mis on allkirjastatud 2/3 BP poolt Hyperledgeris, Tendermintis ja muudes pBFT-põhistes konsensustes. Samuti on mõistlik, et protokoll lõpuleviimise tagamiseks oleks konsensuse kohalduseks, kuna see võib töötada asünkroonselt plokkide tootmise ja avaldamisega. artikkel Ethereum'i lõplikkus.

Lõplikkus on ülioluline kasutajatele, kes võivad ilma selleta sattuda "topeltkulutamise" rünnaku ohvriks, kui BP "hoiab" plokke ja avaldab need pärast seda, kui võrk on näinud head tehingut. Kui lõplikkust ei ole, asendab avaldatud fork ploki, kus on "hea" tehing, teisega, "halva" forki, kus need samad vahendid kantakse ründaja aadressile. PVRB puhul on nõuded lõplikkuse osas veelgi pingestatud, kuna PVRB jaoks forki ehitamine tähendab ründaja võimalust valmistada ette mitu varianti juhuslikkuse saamiseks, et avaldada talle kõige kasulikum, ja piirata rünnaku aega - hea lahendus.

Seetõttu on parim variant ühendada PVRB ja lõplikkus ühte protokolli - siis on lõplik plokk = lõplik juhuslikkus, ja see on täpselt see, mida tuli saavutada. Nüüd saavad mängijad garanteeritud juhuslikkuse N sekundi jooksul ja võivad olla kindlad, et seda ei saa tagasi võtta ega mängida uuesti.

Konsensus-integratsiooni variant on hea:

• võimalus asünkroonseks rakendamiseks plokkide tootmise osas - plokid toodetakse nagu tavaliselt, kuid selle kõrvale võib töötada PVRB protokoll, mis genereerib juhuslikkust mitte iga ploki puhul
• võimalus rakendada isegi keerukat krüptograafiat, ilma piiranguteta, mida kehtestavad nutilepingud
• võimalus organiseerida sõnumite vahetust kiiremini, kui tehingud lisatakse plokiahelasse, näiteks osa protokollist võib töötada node'ide vahelilma sõnumite levitamiseta võrgus

Sellega on ka puuduseid:

• kompleksus testimisel ja arendamisel - tuleb emuleerida võrgu vigu, kadunud node'e, võrgu kõvad fork'id
• rakenduse vead nõuavad võrgu kõva forki

Mõlemad PVRB rakendamise viisid on elujõulised, kuid nutilepingute rakendamine kaasaegsetes plokiahelates on siiski arvutusressurssidest suuresti piiratud ja tõsistele krüptograafiale üleminek on tihti lihtsalt võimatu. Tõsine krüptograafia on vajalik, nagu näidatakse hiljem. Kuigi see probleem on selgelt ajutine, on tõsine krüptograafia lepingutes vajalik paljude ülesannete lahendamiseks ning see ilmub järk-järgult (näiteks süsteemi lepingud zkSNARKs jaoks Ethereumis).

Plokia, mis tagab läbipaistva ja usaldusväärse suhtluskanali protokollis, ei ole tasuta. Iga detsentraliseeritud protokoll peab arvestama Sybil-rünnaku võimalusega; iga tegevust saab teha kooskõlastatud rühmade kaudu paljude kontode abil, seetõttu tuleb projekteerimisel arvesse võtta ründajate võimet luua suvaline arv osalejaid protokollis, kes tegutsevad koostöös.

PVRB ja ploki muutujad.

Ma ei valetanud, kui ütlesin, et head PVRB-d, mida on testinud paljud hasartmängu rakendused, ei ole plokiahelates seni keegi rakendanud. Kust siis nii palju hasartmängu rakendusi Ethereumis ja EOS-is? See üllatab mind sama palju kui teid; kuidas on täiesti määramatutes tingimustes leitud nii palju "kestävaid" juhuslikkuseid?

Levinud viis juhuslikkuse saamiseks plokiahelas on võtta mingit "ennustamatuks" peetavat teavet plokist ja selle põhjal genereerida juhuslikkust — lihtsalt hajutada ühe või mitu väärtust. Hea artikkel nende skeemide probleemidest. siin. Võib võtta mõne "ennustamatuks" peetava väärtuse plokist, näiteks ploki hash, tehingute arv, võrgu raskusaste ja muud, etteaimamatud väärtused. Seejärel hajutatakse need, üks või mitu, ja idee kohaselt peaksid need andma ehtsat juhuslikkust. Võite isegi oma whitepaperis märkida, et teie skeem on "postkvantitootes turvaline" (sest eksisteerivad kvantitehnoloogia tõestatud hash-funktsioonid :)).

Aga isegi postkvantitootes turvalise hash'i puhul on seda kahjuks liiga vähe. Saladus peitub nõuetes PVRB-le; meenutan neid eelmisest artiklist:

1. Tulemus peab olema tõestatud ühtlaselt jaotunud, s.t. põhinev tõestatud krüptograafial.
2. Mitte ühtegi tulemust bitist ei saa kontrollida. Seetõttu ei saa tulemust ette ennustada.
3. Protokolli genereerimist ei saa saboteerida, osalemat protokollis või koormates võrku ründavate sõnumitega.
4. Kõik ülalnimetatud peab olema vastupidav lubatud arvu ebaausate protokolli osalejate (näiteks 1/3 osalejat) koostööle.

Antud juhul järgitakse ainult nõuet 1 ja nõue 2 ei ole täidetud. Hashides ettearvamatuid väärtusi plokist, saame me ühtlase ja hea juhuslikkuse. Kuid BP-l on vähemalt võimalus "plokki avaldada või mitte". Seega suudab BP vähemalt valida kahe juhuslikkuse variandi vahel: "oma" ja selle, mis tuleb, kui ploki avaldab keegi teine. BP saab eelnevalt "piiluda", mis juhtub, kui ta ploki avaldab, ja lihtsalt otsustada, kas teha seda või mitte. Näiteks mängides "paaritud-ühtlane" või "punane/must" rulett, võib ta ploki avaldada ainult siis, kui näeb võitu. See muudab ka tulevaste plokkide hash'i kasutamise strateegia ebatõhusaks, näiteks öeldakse, et "kasutatakse juhuslikkust, mis tuleneb praeguste andmete ja tulevase ploki hash'ist, mille kõrgus on näiteks N + 42, kus N on praegune ploki kõrgus. See veidi tugevdab skeemi, kuid võimaldab BP-l, isegi tulevikus, valida, kas plokk kinni hoida või avaldada.

BP tarkvara keerukus suureneb antud juhul, kuid mitte oluliselt. Lihtsalt tehingu valideerimise ja plokki lisamise käigus toimub kiire kontroll, kas võit on võimalik, ja võib-olla ühe tehingu parameetri määramine, et saavutada kõrge tõenäosus võitmiseks. Samuti on keeruline tabada nutikat BP-d, kes selliste manipulatsioonide kaudu toimib, iga kord saab kasutada uusi aadresse ja võita natuke, kahtlusi tekitamata.

Seega pole plokist saadud teabe kasutamise meetodid sobivad universaalse PVRB rakenduse jaoks. Piiratud variandis, mis hõlmab panuste suuruse, mängijate arvu ja/või KYC registreerimise piiranguid (et vältida ühe mängija võimalust kasutada mitut aadressi), võivad need skeemid töötada väikeste mängude jaoks, kuid mitte rohkem.

PVRB ja commit-reveal.

Noh, aitäh hashingule ja vähemalt ploki ja teiste muutujate suhtelisele ettearvamatusele. Kui lahendada minerite front-running probleem, peaks tulema midagi paremat. Lisame sellesse skeemi kasutajad - lase neil samuti mõjutada juhuslikkust: iga tehnilise toe töötaja ütleb teile, et IT-süsteemides on kõige juhuslikumad just kasutajate tegevused 🙂

Lihtne skeem, kus kasutajad saadavad lihtsalt juhuslikke numbreid ja tulemus arvutatakse näiteks nende summa hajutamise kaudu, ei sobi. Sellisel juhul võib viimane mängija, valides oma juhuse, kontrollida, milline tulemus saab olema. Seetõttu kasutatakse laialdaselt mustrit commit-reveal. Osalised saadavad esmalt oma juhuslikest numbritest hajutused (commit-id), seejärel avavad oma juhuslikud numbrid (reveal-id). „Reveal“ faas algab alles pärast seda, kui vajalikud commit-id on kogutud, seega saavad osalised saata täpselt selle juhusliku numbri, mille hajutus nad varem saatsid. Nüüd sidume kõik selle ploki parameetritega, olles parem minevikust (juhuslik number on võimalik teada saada ainult mõnes tulevases plokis), ja voilà — juhuslik number on valmis! Nüüd mõjutab iga mängija tulemuseks olevat juhuslikku numbrit ja suudab „võita“ kurja BP-d, asendades tema juhusliku numbri oma, eelnevalt teadmata juhusliku numbriga... Samuti on võimalik lisada kaitse protokolli sabotaaži vastu, mitte avades reveal etapis — nõudes commit-i käigus tehingule teatavat summat — tagatissummat, mis naaseb ainult reveal protseduuri ajal. Sel juhul oleks commit teha ja mitte reveal mitte kasumlik.

See oli hea katse, ja sellised skeemid on ka mängu DApp-ides olemas, kuid kahjuks sellest ei piisa. Nüüd saab tulemust mõjutada mitte ainult kaevandaja, vaid ka iga protokolli osaline. Kontrollida saab endiselt väärtust, kuid vähem variatiivselt ja tasu eest, kuid nagu ka kaevandaja puhul, kui loosimise tulemused on väärtuslikumad kui osalustasu PVRB protokollis, siis random-producer (RP) võib otsustada, kas teha reveal ja võib endiselt valida vähemalt kahest juhuslikust numbrist.
Kuid nüüd on tekkinud võimalus karistada neid, kes teevad commit ja ei tee reveal, ning see skeem osutub veel vajalikuks. Selle lihtsus on tõsine eelis - tõsisemad protokollid nõuavad palju võimsamat arvutust.

PVRB ja deterministlikud allkirjad.

On veel ühte viisi, kuidas sundida RP-d esitama pseudojuhuslikku arvu, millele ta ei saa mõju avaldada, kui talle antakse "prototüüp" — see on determinantne allkiri. Näiteks on selline allkiri RSA ja see ei ole ECS. Kui RP-l on võtmepaar: RSA ja EСC, ja ta allkirjastab oma privaatsõnumiga mingi väärtuse, siis RSA puhul saab ta ÜHE JA AINUS ALLKIRJA, kuid ECS puhul saab ta luua mis tahes arvu erinevaid kehtivaid allkirju. See juhtub seetõttu, et ECS allkirja loomisel kasutatakse juhuslikku numbrit, mille valib allkirjastaja, ja seda võib valida nagu soovitakse, andes allkirjastajale võimaluse valida ühe mitmest allkirjast. RSA puhul: "üks sisendväärtus" + "üks võtmepaar" = "üks allkiri". Ei saa ennustada, milline allkiri teise RP juures tuleb, seetõttu võib PVRB-d koos determinantsete allkirjadega korraldada mitme osalise RSA allkirjade kombineerimise kaudu, kes on allkirjastanud sama väärtuse. Näiteks — eelmine juhuslik number. Sellises skeemis säästetakse palju ressursse, kuna allkirjad on samal ajal ka tõendiks protokolli nõuetekohasele käitumisele ja juhuslike numbrite allikaks.

Kuid isegi determinantsete allkirjade korral jääb skeem endiselt vastuvõtlikuks "viimase osalise" probleemile. Viimane osaline võib endiselt otsustada, kas avaldada allkiri või mitte, kontrollides seega tulemust. Tuleb skeemi täiendada, lisada sinna ploki hash-e, luua voorusid, et tulemusi ei saaks ette ennustada, kuid kõik need meetodid, isegi arvestades arvukalt täiustusi, jätavad siiski lahendamata ühe osalise mõju kollektiivsele tulemusele usaldamatutes tingimustes ja võivad toimida vaid majanduslike ja ajapiirangute korral. Lisaks on RSA võtmete suurus (1024 ja 2048 bitti) üsna suur, samas kui plokiahela tehingute suurus on äärmiselt oluline parameeter. Tundub, et probleemi lihtne lahendamine ei õnnestu, liigume edasi.

PVRB ja saladuse jagamise skeemid

Krüptograafias on olemas skeeme, mis võimaldavad võrgul kokku leppida ühesainus PVRB väärtuses, samas, kui need skeemid taluvad iga osalise pahatahtlikke tegevusi. Üks kasulik protokoll, millega tasub tutvuda, on Shamir'i saladuse jagamise skeem. See teenib saladuse (näiteks salajase võtme) jagamiseks mitmeks osaks ja nende jagamiseks N osalisele. Saladus jagatakse nii, et selle taastamiseks on vajalik M osa N-st, kusjuures need võivad olla mis tahes M osa. Lihtsustatult öeldes, olles teadmata funktsiooni graafik, vahetavad osalised punkte graafikul ning pärast M punkti saamist on kogu funktsioon taastatav.
Hea seletus on toodud wiki ja selle põhjal katsetamine praktikas, et protokolli peas läbi mängida on kasulik demo lehel.

Kui FSSS (Fiat-Shamir Salajase Jagamise Skeem) rakendataks puhtal kujul — oleks see hävitamatu PVRB. Lihtsaim variand protokollist võiks välja näha järgmiselt:

• Iga osaline genereerib oma vale ja jagab selle osakusi teistele osalistele
• Iga osaline avab oma osa teiste osaliste saladustest
• Kui osalisele on kogunenud rohkem M osakusi, saab tema number arvutada ning see on ainus, sõltumata avanenud osalistest
• Avatud vale kombinatsioon on otsitav PVRB

Siin ei mõjuta üksik osaline protokolli tulemusi, välja arvatud juhul, kui tema poolt sõltub threshold'i saavutamine vale avalikustamiseks. Seetõttu töötab see protokoll, kui on olemas vajalik osakaal protokolli järgijaid ja kättesaadavaid RP, täites krüptograafilise vastupidavuse nõudeid ja olles vastupidav "viimase osalise" probleemile.

See võiks olla ideaalne variant, see PVRB skeem Fiat-Shamir'i saladuse jagamise alusel on kirjeldatud näiteks selle artiklis. Kuid nagu eelnevalt öeldud, kui proovida seda rakendada otse plokiahelas, tekivad juba tehnilised piirangud. Siin on näide protokolli testrakendusest EOS-i nutilepingus ja selle kõige olulisem osa — osalise avaldatud osa kontrollimine: koodiKoodist on näha, et proof'i valideerimine nõuab mitmeid skalaarseid korrutamisi ning kasutatavad numbrid on väga suured. Samuti peab aru saama, et plokiahelas toimub valideerimine hetkel, kui block-producer töötleb tehingut, ja iga osaleja peab hõlpsasti kontrollima protokolli õigsust, seetõttu on valideerimise funktsiooni kiirus nõudmistele väga tõsine. Antud variatiivne lahendus osutus mittefunktsionaalseks, kuna valideerimine ei mahtunud tehingu piirangusse (0,5 sek).

Valideerimise efektiivsus on üks tähtsamaid nõudeid mis tahes edasijõudnud krüptograafiliste skeemide kasutamiseks plokiahelas. Proof'ide loomine, sõnumite ettevalmistamine — neid protseduure saab viia off-chain ja teostada kõrgjõudlike arvutite abil, kuid valideerimist ei saa vältida — see on veel üks oluline nõue PVRB-le.

PVRB ja threshold allkirjad

Tutvudes saladuse jagamise skeemiga, avastasime kogu klass protokolle, mis on seotud võtmesõnaga "threshold". Kui teatud teabe avamiseks on vajalik M ausa osaleja osalemine N-st, ja ausate osalejate komplekt võib olla N-i mis tahes alamkogum, räägitakse "threshold" skeemidest. Need skeemid võimaldavad lahendada "viimase tegija" probleemi; nüüd, kui ründaja ei ava oma osa saladusest, teeb seda tema eest mõni teine, aus osaleja. Need skeemid võimaldavad saavutada üheainsa väärtuse kokkuleppe, isegi kui osa osalejatest saboteerib protokolli.

Deterministlike allkirjade ja threshold-skeemide ühendamine on võimaldanud välja töötada väga mugava ja paljulubava skeemi PVRB rakendamiseks — need on deterministlikud threshold-allkirjad. Siin on artikkel erinevad rakendused threshold-allkirjadest, ja siin on veel üks hea näide pikalt lugemist Dash'ilt.

Viimases artiklis käsitletakse BLS allkirju (BLS tähendab Boneh-Lynn-Shacham, siin on artikkel ), mis omavad programmerijate jaoks väga olulist ja äärmiselt mugavat omadust — avalikud, salajased, avalikud võtmed ja BLS allkirjad saavad omavahel lihtsate matemaatiliste operatsioonide abil kombineerida, jäädes samal ajal kehtivateks võtmeteks ja allkiri, võimaldades hõlpsasti koguda palju allkirju ühte ja palju avalikke võtmeid üheks. Neil on samuti deterministlikkus ning samade sisendandmete puhul annavad nad sama tulemuse. Tänu sellele omadusele on BLS allkirjade kombinatsioonid ise kehtivad võtmed, mis võimaldab rakendada varianti, kus M osa N osalistest genereerib ühe ja ainulaadse allkirja, mis on deterministlik, avalikult kontrollitav ja ennustamatu kuni M-nda osalise paljastamiseni.

Threshold BLS allkirjade skeemis allkirjastab iga osaline BLS abil midagi (näiteks eelmine juhuslik number), ja kogutud threshold-allkiri ongi soovitud juhuslik number. BLS allkirjade krüptograafilised omadused vastavad juhuslikkuse kvaliteedi nõuetele, threshold-osa kaitseb „viimase tegija“ vastu, ning ainulaadne võtmete kombineeritavus võimaldab ellu viia veel palju huvitavaid algoritme, mis võimaldavad näiteks tõhusalt koguda protokolli sõnumeid.

Nii et kui ehitate PVRB oma plokiahelas, jõuate tõenäoliselt BLS threshold allkirjade skeemini, mida kasutavad juba mitmed projektid. Näiteks DFinity (siin benchmark, mis rakendab skeemi, ja siit näide rakendamisest verifiable secret sharing), või Keep.network (siin on nende juhuslik beacon yellowpaper, aga näide smart contract, mis teenindab protokolli).

PVRB rakendamine

Kahjuks ei ole me endiselt näinud valmis PVRB protokolli, mis oleks rakendatud plokiahelates ja tõestanud oma turvalisust ning vastupidavust. Kuigi protokollid on tehniliselt valmis, on nende rakendamine olemasolevates lahendustes keeruline. Keskustatud süsteemide jaoks pole PVRB mõttekas, samas kui detsentraliseeritud lahendused on piiratud kõikides arvutusressurssides: CPU, mälu, salvestamine, I/O. PVRB-i projekteerimine eeldab erinevate protokollide kombineerimist, et luua midagi, mis vastab vähemalt mingitele elujõuliste plokiahelate nõudmistele. Üks protokoll arvutab efektiivsemalt, kuid vajab RP-de vahel rohkem sõnumeid, teine nõuab äärmiselt vähe sõnumeid, kuid tõendi loomine võib võtta kümneid minuteid või isegi tunde.

Loetlen tegurid, mida peate arvesse võtma kvaliteetse PVRB valimisel:

• Krüptograafiline vastupidavus. Teie PVRB peab olema rangelt unbiasable, ilma võimaluseta ühe bitti kontrollida. Mõnedes skeemides see ei ole nii, seega kutsuge krüptograaf.
• Viimase tegija probleem. Teie PVRB peab olema vastupidav rünnakutele, kus ründaja, kes kontrollib ühte või mitut RP-d, võib valida kahe tulemuse variandi vahel.
• Protokolli sabotaaž. Teie PVRB peab olema vastupidav rünnakutele, kus ründaja, kes kontrollib ühte või mitut RP-d, otsustab, kas olla juhuslik või mitte ning võib garanteeritult või määratud tõenäosusega sellele mõju avaldada.
• Sõnumite arv. Teie RP-d peaksid saatma plokiahelasse minimaalselt sõnumeid ja maksimaalselt vältima sünkrone tegevusi, nagu olukorrad "saatsin mingi teabe, ootan vastust konkreetsele osale". P2P võrkudes, eriti geograafiliselt hajutatud, ei tasu loota kiirele vastusele.
• Arvutusalane keerukus. Iga etapi kontrollimine PVRB on-chain peaks olema äärmiselt lihtne, kuna seda teevad kõik võrgu täisklientide. Kui rakendus kasutatakse nutilepinguna, on kiirusnõuded väga ranged.
• Saadavus ja aktiivsus. Teie PVRB peab püüdma jääda vastupidavaks olukordadele, kus osa võrku on ajutiselt kättesaamatu ja osa RP-dest lihtsalt lakka toimimast.
• Usaldusväärse seadistamise ja algsete võtmete jaotamise probleem. Kui teie PVRB kasutab esmase seadistuse protokolli, on see eraldi suur ja tõsine lugu. Siin on näide. Kui osalejad peavad enne protokolli algust üksteisele oma võtmeid teatama — on see ka probleem, kui osalejate koosseis muutub
• Arendusprobleemid. Raamatukogude olemasolu vajalikes keeltes, nende turvalisus ja jõudlus, avalikkus, keerulised testid jne.

Näiteks threshold BLS allkirjade puhul on olemas märkimisväärne probleem — enne tööle asumist peavad osalejad kindlasti üksteisele võtmeid jagama, korraldades rühma, mille raames threshold töötab. See tähendab, et vähemalt üks ringide vahetus detsentraliseeritud võrgus tuleb oodata, ja arvestades, et genereeritud juhuslik number on näiteks mängudes praktiliselt reaalajas vajalik, tähendab see, et protokolli saboteerimine on võimalik sel etapil, ja threshold skeemi eelised kaovad. See probleem on juba lihtsam kui eelmine, kuid nõuab ikkagi eraldi menetluse väljatöötamist threshold-gruppide moodustamiseks, mida tuleb majanduslikult kaitsta, kasutades tagatisi ja osalejatelt, kes protokolli ei järgita, vahendite äravõtmist (slashing). Samuti ei mahu BLS-i verifitseerimine vastuvõetava turvalisuse tasemega näiteks EOS-i või Ethereum’i standardse tehingu aega — lihtsalt ei piisa ajast verifitseerimiseks. Lepingu kood on WebAssembly või EVM, seda täidab virtuaalne masin. Krüptograafilised funktsioonid ei ole natiivsed (praegu), ja töötavad kümneid kordi aeglasemalt kui tavalised krüptograafia raamatukogud. Paljud protokollid ei sobi nõuete tõttu lihtsalt võtmete mahu tõttu, näiteks RSA puhul 1024 ja 2048 bitti, see on 4-8 korda rohkem kui standardne tehingu allkiri Bitcoin’is ja Ethereum’is.

Mängib rolli ka rakenduste olemasolu erinevates programmeerimiskeeltes — neid on vähe, eriti uute protokollide jaoks. Integreerimise variandiga konsensuses peab protokoll olema kirjutatud platvormi keeles, seega tuleb otsida koodi Go jaoks geth, Rust’i jaoks Parity, C++’i jaoks EOS. Kõik peavad otsima JavaScripti koodi, ja kuna JavaScript ja krüptograafia ei ole just parimad sõbrad, aitab WebAssembly, mis pretenderib nüüd juba kindlasti järgmise tähtsa internetistandardi rolli.

Kokkuvõte

Loodan, et eelnevas artiklis Mul on õnnestunud veenda teid, et juhuslike arvude genereerimine plokiahelal on hädavajalik paljude detsentraliseeritud võrkude elu aspektide jaoks. Selle artikliga näitasin, et see ülesanne on äärmiselt ambitsioonikas ja keeruline, kuid olemas on juba head lahendused. Lõplik protokolli disain on võimalik alles pärast põhjalikke teste, mis arvesse võtavad kõiki aspekte alates seadistamisest kuni rikkeemulatsioonini, seega ei leia te tõenäoliselt valmis retsepte meeskondade whitepaper'itest ega artiklitest, ja meie ei hakka kindlasti järgmise aasta või kahe jooksul kirjutama "tehke nii, nii on kindlasti õige".

Praegu, meie PVRB jaoks arendatavas plokiahelas Haya, oleme peatunud threshold BLS allkirjade kasutamisel, plaanime rakendada PVRB konsensuse tasemel, kuna smart lepingutes tõhusa taseme ohutusega verifitseerimine ei ole praegu võimalik. Võimalik, et kasutame korraga kahte skeemi: alguses kallist saladuse jagamise meetodit pikaajalise random_seed loomiseks, ning kasutame seda seejärel alusena kõrgsageduslike juhuslike arvude genereerimiseks kindlaksmääratud threshold BLS allkirjade abil, kuigi võib-olla piirdume vaid ühe skeemi kasutamisega. Kahjuks ei ole võimalik ette öelda, milline protokoll välja kujuneb, rõõmuks on aga see, et nagu teaduses, on ka inseneritehnilistes ülesannetes negatiivne tulemus samuti tulemus, ja iga uus katse probleemi lahendada on uus aste kõigi uurijate jaoks, kes seda küsimust käsitlevad. Äri nõuete täitmiseks lahendame konkreetset praktilist ülesannet — mängu rakenduste kindla entropiaallika tagamine, seetõttu peame samuti pöörama tähelepanu plokiahelale, sealhulgas ahela lõplikkuse ja võrgu haldamise küsimustele.

Ja kuigi me ei näe veel plokiahelates tõestatud usaldusväärset PVRB-d, mida oleks piisavalt kaua kasutatud, et see taluks reaalseid rakendusi, mitmeid auditeid, koormusi ja loomulikult ka reaalsetest rünnakutest, siis olemasolevate võimalike teede arv kinnitab, et lahendus eksisteerib, ja mõni neist algoritmidest lahendab lõpuks probleemi. Jagame hea meelega tulemusi ja täname teisi meeskondi, kes samuti selle küsimusega tegelevad, artiklite ja koodi eest, mis võimaldavad inseneridel mitte astuda kaks korda samadele kivitõkkele.

Nii et kui kohtate programmeerijat, kes disainib detsentraliseeritud juhuslikkust, olge ettevaatlik ja hooliv, pakkudes vajadusel psühholoogilist abi 🙂

Allikas: habr.com