Esittely

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

Kuten kryptografian ehdottoman vahvan salauksen käsite, todelliset "julkisesti varmennettavissa oleva satunnainen majakka" (jäljempänä PVRB) -protokollat ​​yrittävät vain päästä mahdollisimman lähelle ihannejärjestelmää, koska todellisissa verkoissa sitä ei voida soveltaa puhtaassa muodossaan: täytyy sopia tiukasti yhdestä bitistä, kierroksia on oltava useita ja kaikkien viestien tulee olla täydellisen nopeita ja aina toimitettuja. Näin ei tietenkään ole todellisissa verkoissa. Siksi, kun suunnitellaan PVRB:itä tiettyihin tehtäviin nykyaikaisissa lohkoketjuissa, sen lisäksi, että tuloksena olevaa satunnaisuutta ja kryptografista vahvuutta ei voida hallita, syntyy monia muita puhtaasti arkkitehtonisia ja teknisiä ongelmia.

PVRB:lle itse lohkoketju on olennaisesti viestintäväline, jossa viestit = tapahtumat. Tämä mahdollistaa osittaisen irtautumisen verkkoongelmista, viestien toimittamatta jättämisestä, väliohjelmistoongelmista - hajautettu verkko ottaa kaikki nämä riskit, ja sen tärkein arvo PVRB:lle on kyvyttömyys peruuttaa tai korruptoida jo lähetettyä tapahtumaa - tämä tekee eivät anna osallistujien kieltäytyä osallistumasta pöytäkirjaan, elleivät he ole onnistuneet hyökkäämään konsensusta vastaan. Tämä suojaustaso on hyväksyttävä, joten PVRB:n tulisi kestää osallistujien salaista yhteistyötä täsmälleen samassa määrin kuin päälohkoketjun ketju. Tämä vihjaa myös, että PVRB:n on oltava osa konsensusta, jos verkko sopii päälohkoketjusta, vaikka se olisi myös samaa mieltä ainoasta reilusta tuloksena olevasta satunnaisesta. Tai PVRB on yksinkertaisesti erillinen protokolla, joka on toteutettu älykkäällä sopimuksella ja joka toimii asynkronisesti lohkoketjun ja lohkojen suhteen. Molemmilla tavoilla on hyvät ja huonot puolensa, ja valinta niiden välillä on erittäin ei-triviaali.

Kaksi tapaa toteuttaa PVRB

Kuvataanpa tarkemmin kahta vaihtoehtoa PVRB:n toteuttamiselle - itsenäinen versio, joka toimii lohkoketjusta riippumattomalla älysopimuksella, ja protokollaan sisäänrakennettu konsensus-integroitu versio, jonka mukaan verkko sopii lohkoketjusta ja sisällytettävät liiketoimet. Kaikissa tapauksissa tarkoitan suosittuja lohkoketjumoottoreita: Ethereumia, EOS:ää ja kaikkia niitä vastaavia älykkäiden sopimusten isännöinti- ja käsittelytavoissa.

Itsenäinen sopimus

Tässä versiossa PVRB on älykäs sopimus, joka hyväksyy satunnaisten tuottajien tapahtumat (jäljempänä RP), käsittelee ne, yhdistää tulokset ja saavuttaa sen seurauksena tietyn arvon, jonka kuka tahansa käyttäjä voi saada tästä sopimuksesta. Tätä arvoa ei saa tallentaa suoraan sopimukseen, vaan sitä edustaa vain data, josta saadaan deterministisesti yksi ja vain yksi tuloksena olevan satunnaisen arvo. Tässä järjestelmässä RP:t ovat lohkoketjun käyttäjiä, ja kuka tahansa voidaan sallia osallistua luomisprosessiin.

Vaihtoehto erillissopimuksella on hyvä:

• siirrettävyys (sopimukset voidaan vetää lohkoketjusta lohkoketjuun)
• toteutuksen ja testauksen helppous (sopimukset on helppo kirjoittaa ja testata)
• mukavuus taloudellisten suunnitelmien toteuttamisessa (on helppo tehdä oma token, jonka logiikka palvelee PVRB:n tarkoitusperiä)
• mahdollisuus käynnistää jo toimivilla lohkoketjuilla

Sillä on myös haittoja:

• vahvat rajoitukset laskentaresursseille, tapahtumavolyymille ja tallennustilalle (toisin sanoen cpu/mem/io)
• rajoitukset sopimuksen sisällä (kaikki ohjeet eivät ole saatavilla, ulkoisten kirjastojen yhdistäminen on vaikeaa)
• kyvyttömyys järjestää viestit nopeammin kuin tapahtumat sisällytetään lohkoketjuun

Tämä vaihtoehto sopii sellaisen PVRB:n toteuttamiseen, joka on ajettava olemassa olevassa verkossa, ei sisällä monimutkaista kryptografiaa eikä vaadi suurta määrää vuorovaikutuksia.

Konsensus-integroitu

Tässä versiossa PVRB on toteutettu lohkoketjusolmukoodissa, sisäänrakennettuna tai käynnissä rinnakkain lohkoketjusolmujen välisen viestien vaihdon kanssa. Protokollan tulokset kirjoitetaan suoraan tuotettuihin lohkoihin ja protokollaviestit lähetetään p2p-verkon yli solmujen välillä. Koska protokolla johtaa lukuihin, jotka kirjoitetaan lohkoihin, verkon on päästävä niistä yksimielisyyteen. Tämä tarkoittaa, että PVRB-viestit, kuten tapahtumat, on vahvistettava solmuissa ja sisällytettävä lohkoihin, jotta kuka tahansa verkon osallistuja voi vahvistaa PVRB-protokollan noudattamisen. Tämä johtaa meidät automaattisesti ilmeiseen ratkaisuun - jos verkko sopii yksimielisyyteen lohkosta ja siinä tapahtuvista tapahtumista, PVRB:n tulisi olla osa konsensusta, ei erillinen protokolla. Muuten on mahdollista, että lohko on konsensusnäkökulmasta kelvollinen, mutta PVRB-protokollaa ei noudateta, eikä PVRB:n näkökulmasta lohkoa voida hyväksyä. Joten jos "konsensusintegroitu" vaihtoehto valitaan, PVRB:stä tulee tärkeä osa konsensusta.

Kuvattaessa PVRB-toteutuksia verkon konsensustasolla, ei voi mitenkään välttää lopullisuusongelmia. Lopullisuus on deterministisissa konsensuksissa käytetty mekanismi, joka lukitsee lohkoon (ja siihen johtavaan ketjuun), joka on lopullinen ja jota ei koskaan heitettäisi pois, vaikka rinnakkainen haarukka tapahtuisi. Esimerkiksi Bitcoinissa ei ole tällaista mekanismia - jos julkaiset monimutkaisemman ketjun, se korvaa vähemmän monimutkaisen ketjujen pituudesta riippumatta. Ja esimerkiksi EOS:ssä viimeiset ovat ns. Last Irreversible Blocks, jotka ilmestyvät keskimäärin 432 lohkon välein (12*21 + 12*15, ennakkoäänestys + pre-commit). Tämä prosessi odottaa olennaisesti 2/3 lohkotuottajien (jäljempänä BP) allekirjoituksia. Kun näkyviin tulee haarukoita, jotka ovat vanhempia kuin viimeinen LIB, ne yksinkertaisesti hylätään. Tämän mekanismin avulla voidaan taata, että tapahtuma sisältyy lohkoketjuun ja että sitä ei koskaan palauteta, olipa hyökkääjällä mitä resursseja tahansa. Myös viimeiset lohkot ovat lohkoja, jotka on allekirjoitettu 2/3 BP:llä Hyperledgerissä, Tendermintissa ja muissa pBFT-pohjaisissa konsensuksissa. On myös järkevää tehdä protokolla lopullisuuden varmistamiseksi konsensuksen lisäosaksi, koska se voi toimia asynkronisesti lohkojen tuotannon ja julkaisemisen kanssa. Tässä on hyvä artikkeli lopullisuudesta Ethereumissa.

Lopullisuus on erittäin tärkeää käyttäjille, jotka ilman sitä voivat joutua "kaksinkertaisen kulutuksen" hyökkäyksen uhriksi, jossa BP "pitää" estoja ja julkaisee ne sen jälkeen, kun verkko on "nähnyt" hyvän tapahtuman. Jos lopullisuutta ei ole, julkaistu haarukka korvaa lohkon "hyvällä" tapahtumalla toisella "huonosta" haarukasta, jossa samat varat siirretään hyökkääjän osoitteeseen. PVRB:n tapauksessa lopullisuuden vaatimukset ovat vielä tiukemmat, koska PVRB:n rakentaminen tarkoittaa hyökkääjälle mahdollisuutta valmistella useita satunnaisia ​​vaihtoehtoja julkaistakseen kannattavimman, ja mahdollisen hyökkäyksen ajan rajoittaminen on hyvä ratkaisu.

Siksi paras vaihtoehto on yhdistää PVRB ja lopullisuus yhdeksi protokollaksi - sitten viimeistelty lohko = viimeistelty satunnainen, ja tämä on juuri se, mitä meidän piti saada. Nyt pelaajat saavat taatun satunnaisen N sekunnissa ja voivat olla varmoja, että sitä on mahdotonta rullata takaisin tai toistaa sitä uudelleen.

Konsensukseen integroitu vaihtoehto on hyvä:

• asynkronisen toteutuksen mahdollisuus lohkojen tuottamiseen - lohkoja tuotetaan tavalliseen tapaan, mutta rinnakkain tämän kanssa voi toimia PVRB-protokolla, joka ei tuota satunnaisuutta jokaiselle lohkolle
• kyky toteuttaa jopa raskasta kryptografiaa ilman älykkäille sopimuksille asetettuja rajoituksia
• kyky järjestää viestien vaihto nopeammin kuin tapahtumat sisältyvät lohkoketjuun, esimerkiksi osa protokollasta voi toimia solmujen välillä jakamatta viestejä verkon yli

Sillä on myös haittoja:

• Testauksen ja kehityksen vaikeudet - joudut emuloimaan verkkovirheitä, puuttuvia solmuja, verkon kiintohaarukoita
• Käyttöönottovirheet vaativat verkon hardforkin

Molemmilla PVRB:n käyttöönottomenetelmillä on oikeus elämään, mutta älykkäiden sopimusten toteutus nykyaikaisissa lohkoketjuissa on edelleen melko rajallista laskentaresurssien suhteen, ja siirtyminen vakavaan salaukseen on usein yksinkertaisesti mahdotonta. Ja tarvitsemme vakavaa kryptografiaa, kuten alla osoitetaan. Vaikka tämä ongelma on selvästi väliaikainen, monien ongelmien ratkaisemiseksi tarvitaan vakavaa salausta sopimuksissa, ja se ilmaantuu vähitellen (esimerkiksi järjestelmäsopimukset zkSNARK:ille Ethereumissa)

Blockchain, joka tarjoaa läpinäkyvän ja luotettavan protokollaviestikanavan, ei tee sitä ilmaiseksi. Kaikissa hajautetuissa protokollissa on otettava huomioon Sybil-hyökkäyksen mahdollisuus; kaikki toimet voidaan tehdä useiden tilien yhteisillä voimilla, joten suunnittelussa on otettava huomioon hyökkääjien kyky luoda mielivaltainen määrä protokollia salaisen yhteistyön osanottajat.

PVRB ja lohkomuuttujat.

En valehdellut sanoessani, että kukaan ei ole vielä ottanut käyttöön hyvää PVRB:tä, jota monet rahapelisovellukset on testannut, lohkoketjuissa. Mistä niin monet uhkapelisovellukset tulevat Ethereumista ja EOS:stä? Tämä hämmästyttää minua yhtä paljon kuin sinuakin, mistä he ovat saaneet niin monta "pysyvää" satunnaista täysin deterministisessä ympäristössä?

Suosituin tapa saada satunnaisuus lohkoketjussa on ottaa lohkosta jonkinlainen "ennustamaton" informaatio ja tehdä sen perusteella satunnainen - yksinkertaisesti hajauttamalla yksi tai useampi arvo. Hyvä artikkeli tällaisten järjestelmien ongelmista täällä. Voit ottaa minkä tahansa lohkon "ennustamattomista" arvoista, esimerkiksi lohkon hajautusarvon, tapahtumien määrän, verkon monimutkaisuuden ja muut arvot, joita ei tunneta etukäteen. Sitten tiivistetään ne, yksi tai useampi, ja teoriassa sinun pitäisi saada todellinen satunnainen. Voit jopa lisätä wihitepaperiin, että järjestelmäsi on "post-quantum-suojattu" (koska kvanttivarmoja hash-funktioita on :)).

Mutta edes kvanttiturvalliset tiivisteet eivät valitettavasti riitä. Salaisuus piilee PVRB:n vaatimuksissa, haluan muistuttaa niistä edellisestä artikkelista:

1. Tuloksen tulee olla todistetusti tasainen jakauma, eli sen tulee perustua todistetusti vahvaan kryptografiaan.
2. Mitään tuloksen bittejä ei ole mahdollista ohjata. Tämän seurauksena lopputulosta ei voida ennustaa etukäteen.
3. Et voi sabotoida sukupolviprotokollaa olemalla osallistumatta protokollaan tai ylikuormittamalla verkkoa hyökkäysviesteillä
4. Kaiken edellä mainitun on kestettävä sallitun määrän epärehellisiä protokollaan osallistuneita (esimerkiksi 1/3 osallistujista) yhteistoimintaa.

Tällöin vain vaatimus 1 täyttyy ja vaatimus 2 ei täyty. Hajauttamalla lohkosta arvaamattomat arvot saadaan tasainen jakauma ja hyvät satunnaiset. Mutta BP:llä on ainakin mahdollisuus "julkaista esto vai ei". Näin ollen BP voi valita ainakin kahdesta satunnaisesta vaihtoehdosta: "oma" ja se, joka selviää, jos joku muu tekee lohkon. BP voi "nuuskia" etukäteen, mitä tapahtuu, jos hän julkaisee lohkon, ja yksinkertaisesti päättää tehdä sen vai ei. Näin ollen, kun hän pelaa ruletissa esimerkiksi "pariton" tai "punainen/musta" -peliä, hän voi julkaista lohkon vain, jos hän näkee voiton. Tämä tekee myös strategiasta käyttää esimerkiksi lohkohajautusarvoa "tulevaisuudesta" mahdottomaksi. Tässä tapauksessa he sanovat, että "käytetään satunnaista, joka saadaan tiivistämällä nykyiset tiedot ja tulevan lohkon tiiviste, jonka korkeus on esimerkiksi N + 42, missä N on nykyinen lohkon korkeus. Tämä vahvistaa järjestelmää hieman, mutta antaa silti BP:lle mahdollisuuden, vaikkakin tulevaisuudessa, valita, pitääkö eston vai julkaiseeko.

BP-ohjelmisto on tässä tapauksessa monimutkaisempi, mutta ei paljon. Yksinkertaisesti, kun validoidaan ja sisällytetään tapahtuma lohkoon, on nopea tarkistus nähdäksesi, tuleeko voitto, ja mahdollisesti valitaan yksi tapahtumaparametri suuren voiton todennäköisyyden saavuttamiseksi. Samanaikaisesti on lähes mahdotonta saada älykästä BP:tä tällaisista manipulaatioista; joka kerta voit käyttää uusia osoitteita ja voittaa pikkuhiljaa herättämättä epäilyksiä.

Joten menetelmät, jotka käyttävät informaatiota lohkosta, eivät sovellu PVRB:n universaaliksi toteutukseksi. Rajoitetussa versiossa, panoskokorajoituksin, pelaajien lukumäärän ja/tai KYC-rekisteröinnin rajoituksin (jotta yksi pelaaja ei voi käyttää useita osoitteita), nämä järjestelmät voivat toimia pienissä peleissä, mutta ei sen enempää.

PVRB ja commit-reveal.

Okei, kiitos tiivistyksen ja ainakin lohkotiivisteen ja muiden muuttujien suhteellisen arvaamattomuuden. Jos ratkaiset eturintamassa olevien kaivostyöläisten ongelman, sinun pitäisi hankkia jotain sopivampaa. Lisätään tähän järjestelmään käyttäjiä - anna heidän myös vaikuttaa satunnaisuuteen: kuka tahansa teknisen tuen työntekijä kertoo, että IT-järjestelmissä satunnaisin asia on käyttäjien toiminta :)

Naiivi kaava, jossa käyttäjät lähettävät vain satunnaisia ​​lukuja ja tulos lasketaan esimerkiksi heidän summansa hashina, ei sovellu. Tässä tapauksessa viimeinen pelaaja voi valita oman satunnaisensa, mikä on lopputulos. Tästä syystä käytetään hyvin laajalti käytettyä commit-reveal -mallia. Osallistujat lähettävät ensin tiivisteet satunnaisistaan ​​(sitoumuksista) ja sitten avaavat satunnaiset itse (paljastavat). "Paljastus"-vaihe alkaa vasta, kun tarvittavat sitoumukset on kerätty, joten osallistujat voivat lähettää täsmälleen sen satunnaisen hashin, josta he lähettivät aiemmin. Laitetaan nyt kaikki tämä yhteen lohkon parametrien kanssa, ja paremmin kuin tulevaisuudesta otettu (satunnaisuus löytyy vain yhdestä tulevasta lohkosta), ja voila - satunnaisuus on valmis! Nyt kuka tahansa pelaaja vaikuttaa tuloksena olevaan satunnaisuuteen ja voi "päihittää" haitallisen BP:n ohittamalla sen omalla, etukäteen tuntemattomalla satunnaisuudellaan... Voit myös lisätä suojan protokollan sabotoimiselta jättämällä avaamatta sitä paljastamisvaiheessa - yksinkertaisesti vaatimalla, että tapahtumaan sitouduttaessa liitetään tietty summa — vakuus, joka palautetaan vasta paljastamismenettelyn aikana. Tässä tapauksessa sitoutuminen ja paljastamatta jättäminen on kannattamatonta.

Se oli hyvä yritys, ja tällaisia ​​​​järjestelmiä on myös pelien DAppeissa, mutta valitettavasti tämä ei taaskaan riitä. Nyt ei vain kaivosmies, vaan myös jokainen protokollaan osallistuva henkilö voi vaikuttaa tulokseen. Itse arvoa on edelleen mahdollista hallita pienemmällä vaihtelulla ja kustannuksin, mutta, kuten kaivostyöntekijän tapauksessa, jos piirtämisen tulokset ovat arvokkaampia kuin PVRB-protokollaan osallistumismaksu, niin satunnainen -producer(RP) voi päättää paljastaako se ja voi silti valita vähintään kahdesta satunnaisesta vaihtoehdosta.
Mutta tuli mahdolliseksi rangaista niitä, jotka sitoutuvat ja eivät paljasta, ja tämä järjestelmä on hyödyllinen. Sen yksinkertaisuus on vakava etu - vakavammat protokollat ​​vaativat paljon tehokkaampia laskelmia.

PVRB ja deterministiset allekirjoitukset.

On toinenkin tapa pakottaa RP antamaan näennäissatunnainen luku, johon se ei voi vaikuttaa, jos se on varustettu "esikuvalla" - tämä on deterministinen allekirjoitus. Tällainen allekirjoitus on esimerkiksi RSA, eikä se ole ECS. Jos RP:llä on avainpari: RSA ja ECC, ja hän allekirjoittaa tietyn arvon yksityisellä avaimellaan, niin RSA:n tapauksessa hän saa YKSI JA VAIN YKSI allekirjoituksen, ja ECS:n tapauksessa hän voi luoda minkä tahansa määrän avaimia. erilaisia ​​kelvollisia allekirjoituksia. Tämä johtuu siitä, että ECS-allekirjoitusta luotaessa käytetään satunnaislukua, jonka allekirjoittaja valitsee ja joka voidaan valita millä tahansa tavalla, jolloin allekirjoittaja voi valita yhden useista allekirjoituksista. RSA:n tapauksessa: "yksi syöttöarvo" + "yksi avainpari" = "yksi allekirjoitus". On mahdotonta ennustaa, minkä allekirjoituksen toinen RP saa, joten determinististen allekirjoitusten PVRB voidaan järjestää yhdistämällä useiden saman arvon allekirjoittaneiden osallistujien RSA-allekirjoitukset. Esimerkiksi edellinen satunnainen. Tämä järjestelmä säästää paljon resursseja, koska allekirjoitukset ovat sekä vahvistus protokollan mukaisesta oikeasta käyttäytymisestä että satunnaisuuden lähde.

Kuitenkin jopa deterministisilla allekirjoituksilla järjestelmä on edelleen haavoittuvainen "viimeisen toimijan" ongelmalle. Viimeinen osallistuja voi silti päättää, julkaiseeko hän allekirjoituksen vai ei, ja siten hallitsee lopputulosta. Voit muokata kaaviota, lisätä siihen lohkotiivisteitä, tehdä kierroksia niin, että tulosta ei voida ennustaa etukäteen, mutta kaikki nämä tekniikat, vaikka monet muutokset ottavat huomioon, jättävät silti ratkaisematta ongelman yhden osallistujan vaikutuksesta kollektiiviin. johtaa epäluotettavaan ympäristöön ja voi toimia vain taloudellisin ja aikarajoittein. Lisäksi RSA-avainten koko (1024 ja 2048 bittiä) on melko suuri, ja lohkoketjutapahtumien koko on erittäin tärkeä parametri. Ilmeisesti ei ole yksinkertaista tapaa ratkaista ongelma, jatketaan.

PVRB ja salaiset jakamisjärjestelmät

Salaustekniikassa on järjestelmiä, joiden avulla verkko voi sopia yhdestä ja vain yhdestä PVRB-arvosta, kun taas tällaiset järjestelmät kestävät joidenkin osallistujien haitallisia toimia. Yksi hyödyllinen protokolla, johon kannattaa tutustua, on Shamirin salainen jakamisjärjestelmä. Sen tarkoituksena on jakaa salaisuus (esimerkiksi salainen avain) useisiin osiin ja jakaa nämä osat N osallistujalle. Salaisuus jaetaan siten, että M osaa N:stä riittää palauttamaan sen, ja nämä voivat olla mitä tahansa M osaa. Jos sormilla, niin tuntemattoman funktion kuvaajalla osallistujat vaihtavat pisteitä kaaviossa, ja saatuaan M pistettä koko funktio voidaan palauttaa.
Hyvä selitys annetaan wiki mutta sillä pelaaminen käytännössä protokollan toistamiseksi päässäsi on hyödyllistä esittely sivu.

Jos FSSS-järjestelmää (Fiat-Shamir Secret Sharing) voitaisiin soveltaa puhtaassa muodossaan, se olisi tuhoutumaton PVRB. Yksinkertaisimmassa muodossaan protokolla voi näyttää tältä:

• Jokainen osallistuja luo oman satunnaisensa ja jakaa siitä osuuksia muille osallistujille
• Jokainen osallistuja paljastaa oman osan muiden osallistujien salaisuuksista
• Jos osallistujalla on enemmän kuin M osaketta, tämän osallistujan lukumäärä voidaan laskea, ja se on ainutlaatuinen riippumatta paljastettujen osallistujien joukosta
• Paljastettujen satunnaisten yhdistelmä on haluttu PVRB

Tässä yksittäinen osallistuja ei enää vaikuta protokollan tuloksiin, paitsi niissä tapauksissa, joissa satunnaisuuden paljastumisrajan saavuttaminen riippuu yksinomaan hänestä. Siksi tämä protokolla, jos vaadittu osuus protokollan parissa työskentelevistä ja käytettävissä on RP:itä, toimii toteuttaen kryptografisen vahvuuden vaatimukset ja vastustaen "viimeisen toimijan" ongelmaa.

Tämä voisi olla ihanteellinen vaihtoehto, tämä Fiat-Shamir-salaiseen jakamiseen perustuva PVRB-järjestelmä on kuvattu esim tämä artikla. Mutta kuten edellä mainittiin, jos yrität käyttää sitä suoraan lohkoketjussa, teknisiä rajoituksia ilmenee. Tässä on esimerkki protokollan testitoteutuksesta EOS-älysopimuksessa ja sen tärkein osa - julkaistun jako-osallistujan tarkistaminen: koodi. Koodista näkyy, että todisteiden validointi vaatii useita skalaarikertoja ja käytetyt luvut ovat erittäin suuria. On ymmärrettävä, että lohkoketjuissa varmistus tapahtuu sillä hetkellä, kun lohkotuottaja käsittelee tapahtuman, ja yleensä jokaisen osallistujan on helposti tarkistettava protokollan oikeellisuus, joten vahvistustoiminnon nopeuden vaatimukset ovat erittäin vakavat. . Tässä vaihtoehdossa vaihtoehto osoittautui tehottomaksi, koska vahvistus ei mahtunut tapahtumarajaan (0.5 sekuntia).

Varmennustehokkuus on yksi tärkeimmistä vaatimuksista yleisesti kaikkien kehittyneiden salausmenetelmien käytölle lohkoketjussa. Todisteiden luominen, viestien valmistelu - nämä toimenpiteet voidaan ottaa pois ketjusta ja suorittaa korkean suorituskyvyn tietokoneilla, mutta todentamista ei voida ohittaa - tämä on toinen tärkeä vaatimus PVRB:lle.

PVRB ja kynnysallekirjoitukset

Tutustuttuamme salaiseen jakamisjärjestelmään löysimme kokonaisen luokan protokollia, joita yhdistää avainsana "kynnys". Kun joidenkin tietojen paljastaminen edellyttää M:n rehellisen osallistujan osallistumista N:stä ja rehellisten osallistujien joukko voi olla mielivaltainen N:n osajoukko, puhutaan "kynnys"-skeemoista. He antavat meille mahdollisuuden käsitellä "viimeisen toimijan" ongelmaa, nyt jos hyökkääjä ei paljasta osaa salaisuudestaan, toinen, rehellinen osallistuja tekee sen hänen puolestaan. Nämä järjestelmät mahdollistavat sopimuksen yhdestä ja vain yhdestä merkityksestä, vaikka jotkut osallistujat sabotoivat protokollaa.

Determinististen allekirjoitusten ja kynnyskaavioiden yhdistelmä mahdollisti erittäin kätevän ja lupaavan järjestelmän kehittämisen PVRB:n toteuttamiseen - nämä ovat deterministisiä kynnysallekirjoituksia. Tässä artikkeli kynnys allekirjoitusten eri käyttötavoista, ja tässä on toinen hyvä longread Dashista.

Viimeinen artikkeli kuvaa BLS-allekirjoituksia (BLS tarkoittaa Boneh-Lynn-Shachamia, täällä artikkeli), joilla on erittäin tärkeä ja erittäin kätevä laatu ohjelmoijille - julkisia, salaisia, julkisia avaimia ja BLS-allekirjoituksia voidaan yhdistää toisiinsa yksinkertaisilla matemaattisilla operaatioilla, kun taas niiden yhdistelmät pysyvät kelvollisina avaimina ja allekirjoituksina, jolloin voit helposti koota monia allekirjoitukset yhdeksi ja monet julkiset avaimet yhdeksi. Ne ovat myös deterministisiä ja tuottavat saman tuloksen samalle syöttödatalle. Tämän laadun ansiosta BLS-allekirjoitusten yhdistelmät ovat itse kelvollisia avaimia, mikä mahdollistaa vaihtoehdon toteuttamisen, jossa M osallistujaa N:stä tuottaa yhden ja vain yhden allekirjoituksen, joka on deterministinen, julkisesti todennettavissa ja arvaamaton, kunnes Mth avaa sen. osallistuja.

Kynnys-BLS-allekirjoituksella varustetussa mallissa jokainen osallistuja allekirjoittaa jotain BLS:n avulla (esimerkiksi edellisen satunnaisen), ja yhteinen kynnysallekirjoitus on haluttu satunnainen. BLS-allekirjoitusten kryptografiset ominaisuudet täyttävät satunnaisen laadun vaatimukset, kynnysosa suojaa "viimeiseltä toimijalta" ja avaimien ainutlaatuinen yhdistettävyys mahdollistaa monia mielenkiintoisempia algoritmeja, jotka mahdollistavat esimerkiksi protokollaviestien tehokkaan yhdistämisen. .

Joten jos rakennat PVRB:tä lohkoketjullesi, päädyt todennäköisesti BLS-kynnysallekirjoitusjärjestelmään, useat projektit käyttävät sitä jo. Esimerkiksi DFinity (täällä vertailuarvo, joka toteuttaa piirin, ja täällä esimerkkinä varmennettavan salaisen jakamisen toteutus) tai Keep.network (tässä on niiden satunnainen majakka). keltainen paperi, Mutta esimerkki protokollaa palveleva älykäs sopimus).

PVRB:n käyttöönotto

Valitettavasti emme vieläkään näe PVRB-lohkoketjuissa toteutettua valmista protokollaa, joka olisi osoittanut turvallisuutensa ja vakautensa. Vaikka itse protokollat ​​ovat valmiita, niiden tekninen soveltaminen olemassa oleviin ratkaisuihin ei ole helppoa. Keskitetyissä järjestelmissä PVRB ei ole järkevää, ja hajautetut järjestelmät ovat tiukasti rajoitettuja kaikissa laskentaresursseissa: CPU, muisti, tallennus, I/O. PVRB:n suunnittelu on yhdistelmä erilaisia ​​protokollia, jotta voidaan luoda jotain, joka täyttää kaikki vaatimukset ainakin jollekin toimivalle lohkoketjulle. Toinen protokolla laskee tehokkaammin, mutta vaatii enemmän viestejä RP:iden välillä, kun taas toinen vaatii hyvin vähän viestejä, mutta todisteen luominen voi kestää kymmeniä minuutteja tai jopa tunteja.

Luettelon tekijät, jotka sinun on otettava huomioon valitessasi laadukasta PVRB: tä:

• Kryptografinen vahvuus. PVRB:n on oltava ehdottoman puolueeton, eikä siinä voi hallita yhtään bittiä. Joissakin järjestelmissä näin ei ole, joten soita kryptografille
• "Viimeisen näyttelijän" ongelma. PVRB:n on kestettävä hyökkäyksiä, joissa yhtä tai useampaa RP:tä hallitseva hyökkääjä voi valita yhden kahdesta tuloksesta.
• Protokollasabotaasiongelma. PVRB:n on oltava vastustuskykyinen hyökkäyksille, joissa yhtä tai useampaa RP:tä hallitseva hyökkääjä päättää, onko hän satunnainen vai ei, ja voidaan joko taata tai tietyllä todennäköisyydellä vaikuttaa tähän.
• Ongelma viestien määrässä. RP:n tulee lähettää mahdollisimman vähän viestejä lohkoketjuun ja välttää mahdollisimman paljon synkronisia toimia, kuten tilanteita, kuten "Lähetin tietoja, odotan vastausta tietystä osallistujasta". P2p-verkoissa, erityisesti maantieteellisesti hajallaan olevissa verkoissa, sinun ei pitäisi luottaa nopeaan vastaukseen
• Laskennallisen monimutkaisuuden ongelma. PVRB-ketjun minkä tahansa vaiheen todentamisen pitäisi olla erittäin helppoa, koska sen suorittavat kaikki verkon täydet asiakkaat. Jos toteutus tehdään älysopimuksella, nopeusvaatimukset ovat erittäin tiukat
• Saavutettavuuden ja elävyyden ongelma. PVRB:n tulee pyrkiä olemaan sietokykyinen tilanteissa, joissa osa verkosta on poissa käytöstä ja osa RP:stä yksinkertaisesti lakkaa toimimasta
• Luotetun asennuksen ja alkuperäisen avaimen jakelun ongelma. Jos PVRB käyttää protokollan ensisijaista asetusta, tämä on erillinen iso ja vakava tarina. Tässä esimerkki. Jos osallistujien on kerrottava avaimensa toisilleen ennen protokollan aloittamista, tämä on ongelma myös, jos osallistujien kokoonpano muuttuu
• Kehityskysymykset. Kirjastojen saatavuus vaadituilla kielillä, niiden turvallisuus ja suorituskyky, julkisuus, monimutkaiset testit jne.

Esimerkiksi kynnys-BLS-allekirjoituksissa on merkittävä ongelma - ennen työn aloittamista osallistujien on jaettava avaimet toisilleen ja järjestettävä ryhmä, jossa kynnys toimii. Tämä tarkoittaa, että ainakin yksi vaihtokierros hajautetussa verkossa joutuu odottamaan, ja koska esimerkiksi generoitu rand on välttämätön peleissä, lähes reaaliajassa, tämä tarkoittaa, että protokollan sabotointi on mahdollista tässä vaiheessa. , ja kynnysjärjestelmän edut menetetään . Tämä ongelma on jo yksinkertaisempi kuin aiemmat, mutta vaatii silti erillisen menettelyn kehittämistä kynnysryhmien muodostamiseksi, joita on suojeltava taloudellisesti talletusten ja varojen noston (slashing) avulla osallistujilta, jotka eivät noudata protokollaa. Myöskään hyväksyttävällä suojaustasolla oleva BLS-varmennus ei yksinkertaisesti sovi esimerkiksi tavalliseen EOS- tai Ethereum-tapahtumaan - todentamiseen ei yksinkertaisesti ole tarpeeksi aikaa. Sopimuskoodi on WebAssembly tai EVM, jonka suorittaa virtuaalikone. Salaustoimintoja ei ole toteutettu natiivisti (vielä), ja ne toimivat kymmeniä kertoja hitaammin kuin perinteiset kryptografiset kirjastot. Monet protokollat ​​eivät täytä vaatimuksia pelkästään avainmäärän perusteella, esimerkiksi 1024 ja 2048 bittiä RSA:lle, 4-8 kertaa suurempi kuin Bitcoinin ja Ethereumin tavallinen transaktioallekirjoitus.

Myös toteutusten läsnäolo eri ohjelmointikielillä vaikuttaa - joita on vähän, etenkin uusille protokollille. Konsensukseen integroituva vaihtoehto edellyttää protokollan kirjoittamista alustan kielellä, joten sinun on etsittävä koodia Go for gethistä, Rust for Paritysta, C++:sta EOS:lle. Kaikkien on etsittävä JavaScript-koodia, ja koska JavaScript ja kryptografia eivät ole erityisen läheisiä ystäviä, WebAssembly auttaa, joka nyt ehdottomasti väittää olevansa seuraava tärkeä Internet-standardi.

Johtopäätös

Toivottavasti edellisessä статье Onnistuin vakuuttamaan sinut siitä, että satunnaislukujen luominen lohkoketjussa on kriittistä monille hajautettujen verkkojen elämän osa-alueille, ja tällä artikkelilla osoitin, että tämä tehtävä on erittäin kunnianhimoinen ja vaikea, mutta hyviä ratkaisuja on jo olemassa. Yleensä protokollan lopullinen suunnittelu on mahdollista vasta massiivisten testien suorittamisen jälkeen, jotka ottavat huomioon kaikki näkökohdat asennuksesta vian emulointiin, joten et todennäköisesti löydä valmiita reseptejä tiimien julkaisuista ja artikkeleista, emmekä varmastikaan löydä. päätä seuraavan vuoden tai kahden sisällä kirjoittaa "tee se näin, aivan oikein".

Heippa, PVRB:llemme kehitettävissä olevassa lohkoketjussa Haya, päädyimme käyttämään kynnysarvoisia BLS-allekirjoituksia, aiomme ottaa PVRB:n käyttöön konsensustasolla, koska todentaminen älykkäissä sopimuksissa hyväksyttävällä tietoturvatasolla ei ole vielä mahdollista. On mahdollista, että käytämme kahta järjestelmää kerralla: ensin kallista salaista jakamista pitkän aikavälin random_seedin luomiseen, ja sitten käytämme sitä pohjana korkeataajuiselle satunnaiselle generoinnille käyttämällä deterministisiä kynnys-BLS-allekirjoituksia, ehkä rajoitamme vain yksi suunnitelmista. Valitettavasti on mahdotonta sanoa etukäteen, mikä protokolla tulee olemaan, ainoa hyvä asia on se, että kuten tieteessä, niin teknisissäkin ongelmissa, seurauksena on myös negatiivinen tulos, ja jokainen uusi ongelmanratkaisuyritys on askel eteenpäin. kaikkien ongelmaan osallistuneiden tutkimus. Liiketoiminnan vaatimusten täyttämiseksi ratkaisemme tietyn käytännön ongelman - tarjoamme pelisovelluksille luotettavan entropian lähteen, joten meidän on kiinnitettävä huomiota myös itse lohkoketjuun, erityisesti ketjun lopullisuuteen ja verkon hallintaan.

Ja vaikka emme vielä näe lohkoketjuissa todistetusti vastustuskykyistä PVRB:tä, jota olisi käytetty tarpeeksi pitkään todellisten sovellusten, useiden auditointien, kuormien ja tietysti todellisten hyökkäysten testaamiseen, mutta mahdollisten polkujen määrä vahvistaa, että ratkaisu on olemassa, ja mikä näistä algoritmeista lopulta ratkaisee ongelman. Jaamme mielellämme tulokset ja kiitämme muita tämän ongelman parissa työskenteleviä tiimejä artikkeleista ja koodista, joiden avulla insinöörit eivät astu kahdesti saman haravan päälle.

Joten kun tapaat ohjelmoijan, joka suunnittelee hajautettua satunnaista, ole tarkkaavainen ja välittävä ja anna tarvittaessa psykologista apua :)

Lähde: will.com