Sissejuhatus

function getAbsoluutseltJuhuslikNumber() {
        return 4; // tagastab täiesti juhusliku numbri!
}

Nagu ka täiesti vastupidava krüptograafia kontseptsiooni puhul, püüavad reaalsed "Avalikult Kontrollitavad Juhuslikku Tuli" (edaspidi PVRB) protokollid võimalikult lähedale ideaalsetele skeemidele, kuna reaalsetes võrkudes ei ole puhtal kujul see rakendatav: kokkulepped peavad puudutama rangelt üht bitti, ringe peab olema palju ning kõik sõnumid peavad olema ideaalselt kiired ja alati kohaletoimetatud. Loomulikult ei ole see reaalses elus nii. Seetõttu, kui projekteerida PVRB konkreetsete ülesannete jaoks kaasaegsetes plokiahelates, lisaks juhusliku arvu ja krüptograafilise vastupidavuse kontrollimise võimatusele, tekib palju puhtalt arhitektuurilisi ja tehnilisi probleeme.

Blockchain on PVRB essentially serves as a communication environment where messages represent transactions. This allows for partial abstraction from network issues, message delivery failures, and problems with intermediary software — all these risks are managed by the decentralized network. The primary value for PVRB lies in the impossibility of retracting or corrupting a transaction once it has been sent, which prevents participants from opting out of the protocol unless they have successfully executed an attack on consensus. This level of security is acceptable, thus PVRB must be resilient against collusion among participants to the same degree as the main blockchain. Furthermore, this implies that PVRB should be part of the consensus if the network has reached an agreement on the main block chain, and it should negotiate a single fair resulting randomness at the same time. Alternatively, PVRB can function as a standalone protocol, implemented through a smart contract, operating asynchronously in relation to the blockchain and the blocks. Both methods have their own advantages and disadvantages, and choosing between them is quite non-trivial.

Kaks võimalust PVRB rakendamiseks

Kirjeldame lähemalt kahte PVRB rakenduse varianti — iseseisev versioon, mis töötab sõltumatult plokiahela nutilepinguga, ja konsensusintegratsiooni — süsteemi, mille kohaselt nõustub võrk plokkide ahelate ja kaasatud tehingutega. Kõigis nendes juhtudel mõtlen ma populaarsetele plokiahela mootoritele: Ethereum, EOS ja kõik sellele sarnased nutilepingute paigutamise ja töötlemise viisid.

Iseseisev leping

Selles PVRB variandis on tegemist nutilepinguga, mis võtab vastu juhuslike tootjate (edaspidi RP) tehingud, töötleb neid, kombineerib tulemusi ning jõuab lõppkokkuvõttes teatud väärtuseni, mille igal kasutajal on võimalik sellest lepingust saada. See väärtus ei pruugi lepingus otse olla salvestatud, vaid võib olla esindatud ainult andmetena, millest saab deterministlikult tuletada ühe ja ainsa tulemuse juhuslikkuse. Selles skeemis on RP plokiahela kasutajad, ja protsessi genereerimises võivad osaleda kõik soovijad.

Iseseisva lepingu variant on hea:

• ülekantavuse (lepingud saab üle kanda plokiahelast plokiahelasse)
• lihtsuse rakendamisel ja testimisel (lepinguid on mugav kirjutada ja testida)
• mugavuse osas majanduslike skeemide rakendamisel (on lihtne luua oma token, mille loogika teenib PVRB eesmärke)
• võimaluse osas käivitamiseks juba töötavates plokiahelates

Kuid sellel on ka puudused:

• suured piirangud ressursside osas arvutustes, tehingu maht ja salvestus (lihtsalt öeldes cpu/mem/io)
• piirangud operatsioonidele lepingus (kõik käsud ei ole saadaval, keeruline on ühendada väliseid teeke)
• võimetus korraldada sõnumite vahetust kiiremini, kui tehingud plokiahelasse sisestatakse

See valik sobib PVRB rakendamiseks, mille tuleb käivitada juba olemasolevas võrgus, mis ei sisalda keerulist krüptograafiat ja ei nõua suurt suhtlemiste arvu.

Konsensuse integreeritud

Selles variandis on PVRB rakendatud plokiahela sõlme koodis, integreeritud või töötades paralleelselt sõlmede vahelise sõnumivahetusega. Protokolli tulemused salvestatakse otse genereeritud plokkidesse ja protokolli sõnumid saadetakse p2p-võrgus sõlmede vahel. Kuna protokoll toodab numbreid, mis peavad olema plokkidesse kirjutatud, peab võrgustik nende osas konsensusele jõudma. See tähendab, et PVRB sõnumid, nagu ka tehingud, peavad olema sõlmede poolt valideeritud ja plokkidesse lisatud, et iga võrgu osaleja saaks PVRB protokolli järgimist valideerida. See viib meid automaatselt ilmse lahenduse juurde: kui võrk jõuab konsensusele ploki ja selles olevate tehingute osas, peab PVRB olema osa konsensusest, mitte eraldi protokoll. Vastasel juhul on võimalik olukord, kus plokk on kehtiv konsensuse seisukohalt, kuid PVRB protokolli ei järgita, ja PVRB seisukohalt ei saa plokki aktsepteerida. Seega, kui valitakse “consensus-integrated” variant, muutub PVRB oluliseks osaks konsensusest.

Konsensusvõrgus PVRB rakenduste kirjeldamisel ei tohiks jätta tähelepanuta lõplikkuse teemasid. Lõplikkus on mehhanism, mida kasutatakse deterministlikes konsensusprotsessides, et fikseerida plokk (ja sellele viiv ahel), mis on lõplik ja ei saa kunagi tagasi lükatud, isegi kui ilmneb paralleelne haru. Näiteks Bitcoinis sellist mehhanismi ei ole — kui postitada keerukama ahelaga plokk, asendab see mistahes vähem keeruka, sõltumata ahelate pikkusest. EOS-is, näiteks, on lõplikud nii nimetatud viimane pöördumatu plokk (Last Irreversible Blocks), mis ilmnevad keskmiselt iga 432 ploki järel (12*21 + 12*15, eelhäälestus + eelkomiteerimine). See protsess on põhimõtteliselt 2/3 allkirjade (block-producers, edaspidi BP) ootamine. Harude puhul, mis on vanemad kui viimane LIB, lihtsalt kõrvaldakse need. See mehhanism tagab, et tehing on kindlalt kinnitatud plokikahelasse ja ei saa kunagi tagasi võetud, sõltumata ründaja ressurssidest. Samuti on lõplikud plokid need, mis on allkirjastatud 2/3 BP Hyperledgeris, Tendermintis ja muudes pBFT-põhistes konsensusprotsessides. Samuti on mõistlik teha finantseerimise protokoll konsensusmehhanismi kohal, kuna see saab töötada asünkroonselt plokkide tootmise ja avaldamisega. See on hea artikkel Ethereum'i lõplikkusest.

Lõplikkus on ülioluline kasutajatele, kes võivad selle puudumisel sattuda 'double spend' rünnaku ohvriks, kus BP 'hoiab' blokke kinni ja avaldab need pärast seda, kui võrk on näinud head tehingut. Kui lõplikkust pole, asendab avaldatud fork bloki 'heas' tehingus 'halva' forki omaga, kus samad vahendid kantakse ründaja aadressile. PVRB puhul muutuvad nõuded lõplikkusele veelgi rangemaks, kuna PVRB forki loomine tähendab, et ründajal on võimalus valmistada mitmeid variatsioone, et avaldada enda jaoks kõige soodsam, ning piirata rünnaku võimalust — hea lahendus.

Seega on parim variant ühendada PVRB ja lõplikkus ühte protokolli — siis on lõplik blok = lõplik juhus, ja see on täpselt see, mida pidi saavutama. Nüüd saavad mängijad garanteeritud juhuse N sekundi jooksul ja võivad olla kindlad, et seda ei saa tagasi kerida ega uuesti mängida.

Konsensusintegratsiooni variant on hea:

• asünkroonse elluviimise võimalus plokkide tootmise osas — plokid valmivad nagu tavaliselt, kuid samal ajal võib töötada PVRB protokoll, mis genereerib mitte iga ploki puhul juhuslikke elemente.
• võimalus rakendada isegi keerulist krüptograafiat ilma piiranguteta, mida smart-lepingud peale panevad.
• võimalus korraldada sõnumivahetust kiiremini, kui tehingud plokkidesse lisatakse; näiteks võib osa protokollist töötada sõlmede vahel juhul, kui sõnumeid ei edastata kogu võrgus.

Kuid sellel on ka puudused:

• keerukus testimisel ja arendamisel — tuleb emuleerida võrguvead, kadunud sõlmed, võrgu hard-forkid.
• rakendamises esinevad vead nõuavad võrgu hard-forki.

Mõlemad PVRB rakendusviisid on õigustatud, kuid nutilepingute kasutamine tänapäeva plokiahelates on siiski tugevalt piiratud arvutusressursside osas, mistõttu on tõsise krüptograafia kasutamine sageli lihtsalt võimatu. Tõsine krüptograafia on vajalik, nagu allpool demonstreeritakse. Kuigi see probleem on ilmselgelt ajutine, on tõsine krüptograafia lepingutes vajalik paljude ülesannete lahendamiseks ja see ilmub järk-järgult (näiteks süsteemilepingud zkSNARKide jaoks Ethereumis).

Plokiahel, mis tagab protokolli jaoks läbipaistva ja usaldusväärse sõnumivahetuse kanali, ei tee seda tasuta. Iga detsentraliseeritud protokoll peab arvestama Sybil-rünnaku võimalustega; iga tegevust on võimalik teha kooskõlastatud tegevuste abil paljude kontode kaudu, seetõttu tuleb projekteerimisel arvestada ka ründajate võimalusega luua meelevaldne arv osalisi protokolli liikmeid, kes tegutsevad kokkuleppes.

PVRB ja ploki muutujad.

Ma ei valetanud, kui ütlesin, et head PVRB-d, mille on kinnitanud mitmed hasartmängu rakendused, ei ole plokiahelates praegu rakendatud. Kust siis tuleb nii palju hasartmängu rakendusi Ethereumis ja EOS-is? Mind imestab see samuti nagu teid, aga kust on täiesti deterministlikus keskkonnas niisugust „stabiilset” juhuslikkust leidnud?

Lemmikmeetod juhuslikkuse saamiseks plokiahelas on võtta mõni „ennustamatu” teave plokist ja selle põhjal juhuslikkust genereerida — lihtsalt hashides ühe või mitu väärtust. Hea artikkel selliste skeemide probleemidest. siitVõib võtta mõne „ennustamatu” väärtuse plokis, näiteks ploki hash, tehingute arv, võrgutaseme keerukus ja muud, eelnevalt teadmata väärtused. Siis hashida need, üks või mitu, ja idee kohaselt peaks tulemuseks olema päris juhuslikkus. Võib isegi lisada whitepaperisse, et teie skeem on „post-quantum secure” (kuna olemas on kvantitõendavad hash-funktsioonid :)).

Aga isegi post-quantum secure hash'id ei ole piisavad, kahjuks. Saladus peitub nõudmistes PVRB suhtes, meenutan neid eelmisest artiklist:

1. Tulemus peab olema tõestatult ühtlaselt jaotatud, st põhineda tõestatult tugevatel krüptograafiatel.
2. Ükski tulemusbit ei saa olla kontrollitav. Seetõttu ei saa tulemust eelnevalt ennustada.
3. Protokolli genereerimist ei saa saboteerida, osaledes protokollis või koormates võrgustikku ründavate teadetega.
4. Kõik eelpooltoodud peab olema vastupidav kokkulepetele lubatud arvu ebaausate osaliste osas (nt 1/3 osalistest).

Sellisel juhul järgib süsteem ainult nõuet 1, kuid ei järgi nõuet 2. Hashides ettearvamatuid väärtusi plokkidest, saame ühtlase jaotuse ja head juhuslikkust. Kuid BP-l on vähemalt võimalus "plokki avaldada või mitte". Seega saab BP valida vähemalt KAHES variandis juhuslikkuse: "oma" ja selle, mis tekib, kui ploki avaldab keegi teine. BP võib eelnevalt "vaadata", mis juhtub, kui ta avaldab ploki, ja lihtsalt otsustada, kas seda teha või mitte. Nii et näiteks mängides "paar-üks" või "punane/must" ruletti, võib ta ploki avaldada ainult siis, kui ta näeb võitu. See muudab ka ebaefektiivseks strateegia, mis kasutab ploki "tuleviku" hash'i. Sellisel juhul räägitakse, et "kasutatakse juhuslikkust, mis saadakse praeguste andmete ja tulevase ploki, näiteks kõrgusega N + 42 hash'ist, kus N on praeguse ploki kõrgus. See veidi tugevdab skeemi, kuid võimaldab siiski BP-l tulevikus valida, kas plokki kinni hoida või avaldada.

BP tarkvara muutub selles osas keerukamaks, kuid mitte oluliselt. Lihtsalt valideerimise ja tehingu lisamise käigus plokki toimub kiire kontroll, kas võit on võimalik, ja võib-olla ühe tehingu parameetri valimine, et saavutada kõrge tõenäosus võitmiseks. Samuti on peaaegu võimatu püüda nutikat BP-d, kuna selliste manipulatsioonide jaoks võib igal korral kasutada uusi aadresse ja võita vähehaaval, kahtlust äratamata.

Seetõttu ei sobi ploki teabega kasutatavad meetodid PVRB universaalse rakenduse jaoks. Piiratud varianti, kus on piirmäärad panuste suurusele, mängijate arvu piirangud ja/või KYC registreerimine (et mitte lubada ühel mängijal kasutada mitut aadressi), võivad need skeemid töötada väikeste mängude jaoks, kuid mitte rohkemaks.

PVRB ja commit-reveal.

Noh, aitäh, et hashimine ja vähemalt suhteline ettearvamatus ploki hashis ja muudes muutujates. Kui lahendada kaevandajate eesjooksu probleem, peaks tulemus olema midagi paremat. Lisame sellesse skeemi kasutajad — las nadki mõjutavad juhuslikkust: iga tehnilise toe töötaja ütleb teile, et IT-süsteemides on kõige juhuslikum kasutajate tegevus 🙂

Lihtne skeem, kus kasutajad saadavad lihtsalt juhuslikke numbreid ning tulemus arvutatakse näiteks nende summa hash'ina, ei sobi. Sellisel juhul saab viimane mängija, valides oma juhuslikkuse, kontrollida, milline tulemus saadakse. Seetõttu kasutatakse laialdaselt kasutatavat mustrit commit-reveal. Osalejad saadavad esmalt oma juhuslikest (commit’id) hash’id ja avavad seejärel juhuslikud arvud (reveal’id). „Reveal“ faas algab alles pärast seda, kui vajalikud commit’id on kogutud, seega saavad osalejad saata täpselt selle juhuslikkuse, mille hash’i nad varem saatsid. Nüüd ühendame kõik selle ploki parameetritega, eelistatult tulevikust võetud (juhuslikkust saab teada alles ühes tulevastes plokkides), ja voilà — juhuslikkus on valmis! Nüüd mõjutab iga mängija lõplikku juhuslikkust ja võib „võita“ pahatahtliku BP, blokeerides tema juhuslikkuse oma, eelnevalt teadmata, juhuslikkusega... Samuti võib lisada kaitse protokolli saboteerimise eest, nõudes commit'e ajal tehingule teatavat summat — kindlustusdeposiiti, mis tagastatakse ainult reveal’i protseduuri käigus. Sellisel juhul on commit tegemine ja reveal mitte tegemine ebasoodsad.

See oli hea katse, ja sellised skeemid on samuti mängu DApp-ides olemas, kuid kahjuks on seda jälle vähe. Nüüd võivad tulemusele mõju avaldada mitte ainult kaevandajad, vaid ka iga protokolli osaleja. Väärtust saab endiselt kontrollida, kuid väiksema varieerumise astmega ja raha eest. Kuid nagu ka kaevandaja puhul, kui jagamise tulemused on väärtuslikumad kui osalustasu PVRB-protokollis, võib random-producer (RP) otsustada, kas teha reveal, ja tal on endiselt võimalus valida vähemalt kahe juhuslikkuse variandi vahel.
Küll aga on tekkinud võimalus karistada neid, kes teevad commit’i, kuid ei tee reveal’i, ja see skeem osutub veel kasulikuks. Selle lihtsus on tõsine eelis — tõsisemad protokollid nõuavad palju võimsamaid arvutusi.

PVRB ja deterministlikud allkirjad.

On veel veel võimalusi, kuidas panna RP esitama pseudojuhuslikku arvu, millele ta ei saa mõjutada, kui talle antakse 'mudel' — see on deterministlik allkiri. Näiteks on selliseks allkirjaks RSA, mitte ECS. Kui RP-l on võtmepaar: RSA ja ECC, ja ta allkirjastab oma privaatvõtmega mingi väärtuse, siis RSA puhul on tal ÜKS JA AINUÜKS allkiri, aga ECS puhul võib ta genereerida mitmeid erinevaid kehtivaid allkirju. See juhtub seetõttu, et ECS allkirjade loomisel kasutatakse juhuslikku numbrit, mille valib allkirjastaja, ja see võib olla valitud kuidas iganes, andes allkirjastajale võimaluse valida mitme allkirja vahel. RSA puhul: 'üks sisendväärtus' + 'ühe võtmepaar' = 'ühe allkiri'. Ettenägemine, milline allkiri teisel RP-l on, ei ole võimalik, seetõttu võib PVRB-d deterministlike allkirjadega korraldada, kombineerides RSA allkirju mitmelt osaliselt, kes on allkirjastanud sama väärtuse. Näiteks — eelmine juhuslik number. Sellises skeemis säästetakse palju ressursse, kuna allkirjad on samal ajal nii protokolli käitumise õiguspärasuse kinnitamine kui ka juhuslikkuse allikas.

Kuid isegi määratud allkirjadega on skeem endiselt haavatav „viimase osaleja” probleemi suhtes. Viimane osaleja võib endiselt otsustada, kas avaldada oma allkiri või mitte, seega kontrollides tulemust. Skeemi on võimalik täiustada, lisades sinna plokkide hash'id, korraldades voorud, et tulemust ei saaks ette ennustada, kuid kõik need tehnikad, isegi arvestades mitmeid täiustusi, ei lahenda siiski probleemi, kus üks osaleja mõjutab kollektiivset tulemust usaldamatutes keskkondades ja need võivad toimida ainult majanduslike ja ajakohaste piirangute korral. Lisaks on RSA võtmete suurus (1024 ja 2048 bitti) üsna suur ning plokiahela tehingute jaoks on suurus äärmiselt oluline parameeter. Ilmselt ei saa me probleemi lihtsalt lahendada, liigume edasi.

PVRB ja saladuse jagamise skeemid

Krüptograafias on olemas skeeme, mis võimaldavad võrgul kokku leppida ühes ja ainukeses PVRB väärtuses, olles samas igasuguste osaliste pahatahtlike tegevuste suhtes vastupidavad. Üks kasulik protokoll, millega tasub tutvuda, on Shamir'i saladuse jagamise skeem. See on mõeldud saladuse (näiteks salajase võtme) jagamiseks mitmeks osaks ja nende jagamiseks N osalisele. Saladus jagatakse niimoodi, et selle taastamiseks piisab M osast N-st, kusjuures need võivad olla ükskõik millised M osa. Lihtsalt öeldes, omades tundmatu funktsiooni graafikut, jagavad osalised punktid graafikul, ja pärast M punkti saamist on kogu funktsiooni taastamine võimalik.
Hea seletus on toodud wiki ja praktiliselt sellega mängida, et protokolli meelest läbi töötada, on kasulik demos leheküljel.

Kui FSSS (Fiat-Shamir Secrets Sharing) skeem oleks rakendatav puhtal kujul — oleks see hävitamatu PVRB. Lihtsaimas variandis võiks protokoll välja näha järgmiselt:

• Iga osaline genereerib oma random ja jagab selle jagamisi ülejäänud osalistele.
• Iga osaleja paljastab oma osa teiste osalejate saladustest.
• Kui osalejal on rohkem kui M aktsiat, siis saab selle osaleja numbri arvutada, ja see on ainus, olenemata paljastatud osalejatest.
• Paljastatud juhuslike numbrite kombinatsioon on otsitav PVRB.

Siin ei mõjuta eraldi osaleja protokolli tulemusi, välja arvatud juhul, kui tema sõltub juhuslike numbrite paljastamise künnise saavutamine. Seetõttu toimib see protokoll, kui olemas on vajalik osa protokolliga töötajatest ja ligipääsetavad RP, rahuldades krüptograafia tugevuse nõudeid ning olles vastupidav 'viimase tegija' probleemile.

See võiks olla ideaalne variant, see PVRB skeem, mis põhineb Fiat-Shamiri saladuse jagamisel, on kirjeldatud näiteks. sellest artiklis. Kuid nagu eelnevalt mainitud, kui proovida seda otse rakendada plokiahelas, siis tulevad esile tehnilised piirangud. Siin on näide protokolli katsetamisest EOS-i nutilepingus ja selle kõige olulisem osa — osaleja avaldatud aktsia kontrollimine: kood. Koodi põhjal on näha, et proof’i valideerimine nõuab mitmeid skalaarsed korrutamised ning kasutatavad numbrid on ülimalt suured. Samuti tuleb mõista, et blokikaevandamise protsessis toimub verify hetkel, kui block-producer töötleb tehingut, ning iga osalist peab olema lihtne protokolli õigsust kontrollida, seega on nõuded verify funktsiooni kiirusel äärmiselt ranged. Antud variandi puhul osutus see mitte toimivaks, kuna valideerimine ei mahtunud tehingu piirangusse (0.5 sek).

Valideerimise efektiivsus on üks olulisemaid nõudeid mis tahes edasijõudnud krüptograafiliste skeemide kasutamiseks plokiahelas. Proof’ide loomine, sõnumite ettevalmistamine — need protseduurid saab viia off-chain ning täita kõrge jõudlusega arvutites, kuid valideerimist ei õnnestu mööda minna — see on veel üks oluline nõue PVRB-le.

PVRB ja threshold signatures

Tutvudes saladuse jagamise süsteemiga, avasime terve klass protokolle, mida ühendab võtmesõna „threshold”. Kui teatud teabe avamiseks on vaja M ausat osalejat N-st, ning ausate osalejate kogum võib olla N-st valitud mis tahes alamhulka, räägitakse „threshold” skeemidest. Need võimaldavad lahendada probleemi „viimane tegija”, kuna kui ründaja ei ava oma osa saladusest, teeb seda tema eest teine, aus osaleja. Need skeemid lubavad kokku leppida ühes ja ainsas väärtuses, isegi kui osa osalejatest protokolli saboteerib.

Deterministlike allkirjade ja threshold-skeemide ühendamine võimaldas välja töötada väga mugava ja paljutõotava skeemi PVRB rakendamiseks — need on deterministlikud threshold-allkirjad. Siin on artikkel erinevad threshold-allkiri rakendused, ning siin on veel üks hea näide longread Dashilt.

Viimases artiklis kirjeldatakse BLS allkirju (BLS lahti seletamine on Boneh-Lynn-Shacham, siin on artikkel), millel on väga oluline ja äärmiselt mugav kvaliteet programmeerijatele — BLS-i avalikke, privaatseid, avalikke võtmeid ja allkirju saab omavahel kombineerida lihtsate matemaatiliste toimingute abil, samal ajal kui nende kombinatsioonid jäävad kehtivateks võtmeteks ja allkirjadeks, võimaldades kergesti palju allkirju kokku koguda ühte ja palju avalikke võtmeid ühte. Need omadused on samuti deterministlikud, ning sama sisendi puhul annavad nad alati sama tulemuse. Tänu sellele omadusele on BLS allkirjade kombinatsioonid ise kehtivad võtmed, mis võimaldab rakendada varianti, kus M N-st osalejat teeb ühe ja ainulaadse allkirja, mis on deterministlik, avalikult kontrollitav ja ettearvamatu kuni selle hetkeni, mil M-s osaleja avab selle.

BLS threshold allkirjade skeemis allkirjastab iga osaleja BLS-i abil midagi (näiteks eelneva juhusliku numbri), ning kogutud threshold-allkiri ongi soovitud juhuslik number. BLS allkirjade krüptograafilised omadused vastavad juhuslikkuse kvaliteedi nõuetele, threshold-osa kaitseb 'last-actor' rünnakute eest ning ainulaadne võtmete kombineerimise võimalus võimaldab ellu viia veel palju huvitavaid algoritme, mis näiteks võimaldavad tõhusalt koondada protokolli sõnumeid.

Nii et kui sa ehitad PVRB-d oma plokiahelas, siis jõuad tõenäoliselt BLS threshold allkirjade skeemini, mida kasutab juba mitu projekti. Näiteks DFinity (siit benchmark, mis rakendab skeemi, ning siin näide verifiable secret sharing'i rakendamisest), või Keep.network (siin on nende random beacon yellowpaper, aga an example nutileping, mis teenindab protokolli).

PVRB rakendamine

Kahjuks ei ole me siiani näinud valmis, PVRB plokiahelates rakendatud protokolli, mis tõestaks oma turvalisust ja vastupidavust. Kuigi protokollid on tehniliselt valmis, on nende rakendamine olemasolevates lahendustes keeruline. Kesksete süsteemide jaoks pole PVRB mõtet, samas kui detsentraliseeritud lahendused on kõigis arvutusressurssides rangelt piiratud: CPU, mälu, salvestus, I/O. PVRB projekteerimine hõlmab erinevate protokollide ühendamist, et luua lõpuks midagi, mis sobib vähemalt ühe elujõulise plokiahela kõigile nõudmistele. Üks protokoll arvutab efektiivsemalt, kuid vajab rohkem teateid RP vahel, samas kui teine vajab äärmiselt vähe teateid, kuid proof'i loomine võib olla ülesanne, mis kestab kümneid minuteid või koguni tunde.

Loetlen tegurid, mida peate arvestama kvaliteetse PVRB valimisel:

• Krüptograafiline vastupidavus. Teie PVRB peab olema rangelt unbiasable, ilma võimaluseta kontrollida ühtegi bitti. Mõnedes skeemides ei ole see nii, seega kutsuge krüptograaf.
• Probleem "last actor". Teie PVRB peaks olema rünnakute suhtes vastupidav, kui ründaja, kes kontrollib ühte või mitut RP-d, võib valida kahe tulemuse vahel.
• Protokolli saboteerimise probleem. Teie PVRB peab olema vastupidav rünnakutele, kui ründaja, kes kontrollib ühte või mitut RP-d, otsustab, kas olla juhuslik või mitte, ja võib garanteeritult või kindla tõenäosusega selle üle mõjutada.
• Sõnumite arvukuse probleem. Teie RP-d peavad saadma plokiahelasse minimaalselt sõnumeid ja vältima maksimaalselt sümbiootilisi toiminguid nagu 'olen saatnud teavet, ootan vastust konkreetselt osalejalt'. P2P võrkudes, eriti geograafiliselt hajutatud, ei tasu loota kiirele vastusele.
• Arvutusliku keerukuse probleem. Iga PVRB etapi on-chain kinnitamine peaks olema äärmiselt lihtne, kuna seda teevad kõik võrgu täis kliendid. Kui rakendamine toimub nutilepinguga, on kiirusnõuded väga ranged.
• Kättesaadavuse ja elujõu probleem. Teie PVRB peaks püüdma olla rünnakute suhtes vastupidav olukordades, kus osa võrgust on teatud aja jooksul kättesaamatu ja osa RP-d on lihtsalt lõpetanud töötamise.
• Usaldusväärse seadistuse ja algsete võtmete jaotamise probleem. Kui teie PVRB kasutab protokolli esmast seadistust, siis on see eraldi suur ja tõsine teema. Siin an example. Kui osalejad peavad protokolli alustamiseks omavahel oma võtmeid jagama — on see samuti probleem, kui osalejate koosseis muutub
• Arendamise probleemid. Raamatukogude olemasolu vajalikus keeles, nende turvalisus ja jõudlus, avalikkus, keerulised testid jne.

Näiteks on threshold BLS allkiri peamine probleem - enne töö alustamist peavad osalejad tingimata üksteisele võtmed jagama, moodustades rühma, milles threshold toimib. See tähendab, et vähemalt ühe vahetuse vooru peab ootama detsentraliseeritud võrgus, ja arvestades, et genereeritud juhuslik number, näiteks, on mängudes vajalik praktiliselt reaalajas, tähendab see, et protokolli sabotaaž on selles etapis võimalik, ja threshold skeemi eelised kaovad. See probleem on juba lihtsam eelmistest, kuid vajab ikkagi eraldi protseduuri arendamist threshold-rühmade moodustamiseks, mille kaitseks tuleb rakendada majanduslikke meetmeid, näiteks hoiuseid ja osalejate vahendite äravõtmist (slashing), kes ei järgita protokolli. Samuti ei mahu BLS-iga tõendamine vastuvõetava turvalisuse tasemega näiteks standardse EOS või Ethereum tehingusse - lihtsalt ei ole piisavalt aega tõendamiseks. Lepingu kood on WebAssembly või EVM, mida täidab virtuaalne masin. Krüptograafilised funktsioonid ei ole veel natiivsetena rakendatud ja töötavad kümneid kordi aeglasemalt kui tavalised krüptograafilised raamatukogud. Paljud protokollid ei vasta nõuetele lihtsalt võtmete mahu tõttu, näiteks RSA jaoks on see 1024 ja 2048 bitti, mis on 4-8 korda rohkem kui tavaline allkirjastamise tehing Bitcoinis ja Ethereumis.

Mängib rolli ja eri programmeerimiskeelte rakenduste olemasolu — neid on vähe, eriti uute protokollide puhul. Integreerimise variant konsensuses nõuab protokolli kirjutamist platvormi keeles, seetõttu tuleb Go jaoks otsida koodi geth'le, Rust'i jaoks Parity jaoks, C++ jaoks EOS'ile. JavaScript'i koodi tuleb kõigil otsida ja kuna JavaScript ja krüptograafia ei ole just parimad sõbrad, aitab WebAssembly, mis nüüd juba kindlasti pretendeerib järgmise olulise internetistandardi rollile.

Kokkuvõte

Loodan, et eelnevas artiklis suutsin veenda teid, et juhuslike arvude genereerimine plokiahelas on kriitilise tähtsusega paljude detsentraliseeritud võrkude eluaspektide jaoks, ja selle artikli kaudu näitasin, et see ülesanne on äärmiselt ambitsioonikas ja keeruline, kuid head lahendused juba eksisteerivad. Üldiselt on lõplik protokollide disain võimalik ainult pärast ulatuslikke teste, mis arvestavad kõiki aspekte alates seadistamisest kuni tõrgete simuleerimiseni, seetõttu te ei leia tõenäoliselt valmis retsepte meeskondade whitepaper'itest ja artiklitest, ja me järgmise aasta-kahe jooksul kindlasti ei julge kirjutada, et “tehke nii, nii on kindlasti õige”.

Praegu, meie PVRB jaoks välja arendatavas plokiahelas Haya, me oleme keskendunud threshold BLS allkirjade kasutamisele ja kavatseme rakendada PVRB konsensuse tasemel, kuna smart lepingutes on vastuvõetava turbelisuse tasemega autentimine praegu veel võimalik. Võimalik, et võtame kasutusele kaks skeemi: esmalt kuluka saladuse jagamise meetodi pikaajalise random_seed'i genereerimiseks, mida hiljem kasutame kõrge sagedusega juhuslikkuse genereerimiseks määratletud threshold BLS allkirjade abil, võivad piirangud jääda ka ainult ühe skeemi juurde. Kahjuks ei ole võimalik eelnevalt öelda, milliseks protokolliks see kujuneb, kuid rõõmustav on see, et nagu teaduses, on inseneritegevuses negatiivne tulemus samuti tulemus, ja iga uus katse probleemi lahendamiseks on järgmine samm kõikidele, kes tegelevad selle probleemiga. Ärinõudmiste täitmiseks lahendame konkreetset praktilist ülesannet - mängurakenduste varustamine usaldusväärse entropiaallikaga, seetõttu peame pöörama tähelepanu ka plokiahela enda probleemidele, sealhulgas ahela lõpuleviimisele ja võrgu juhtimisele.

Ja kuigi me ei näe praegu plokiahelates tõeliselt usaldusväärset PVRB-d, mis oleks piisavalt kaua kasutusel olnud, et läbida reaalseid rakenduste teste, mitmekordseid auditeid, koormusi ja loomulikult ka reaalseid rünnakuid, näitab võimalikute tee arv, et lahendus eksisteerib ja mõni neist algoritmidest lõpuks probleemi lahendab. Jagame meeleldi tulemusi ja täname teisi meeskondi, kes samuti selle küsimusega tegelevad artiklite ja koodide eest, mis aitavad inseneridel mitte astuda sama rikkaid mune kaks korda.

Nii et kui kohtate programmeerijat, kes projekteerib detsentraliseeritud juhuslikkust, olge ettevaatlikud ja hoolivad, pakkudes vajadusel psühholoogilist abi 🙂

Allikas: habr.com